In most migration practices, everyone can see everything. Not by decision — by default. The shared drive was set up when there were three people, the case management system was configured to get everyone working, and nobody has revisited either since.
Two Code duties and one of the Essential Eight strategies all point the other way, and one of them is considerably stricter than practices expect.
The Code names client money specifically
Section 35 is the broad duty: an agent must not disclose, or allow to be disclosed, personal information about a client or former client, or their affairs, to a third person without written consent, except as required by law.
"Allow to be disclosed" is the operative phrase for access control. Configuring a system so that anyone in the practice can read any file is not a disclosure in itself, but it removes every barrier to one.
OMARA's practice management guidance is more specific about money. Among the things an agent must do to discharge the duty to ensure the quality of work performed by others, it lists that "effective control of client accounts is maintained, to ensure that unauthorised staff do not have access to client monies".
That is an access-control instruction in a professional conduct document. Read it alongside section 50, which restricts what may be paid out of the account holding client money and requires you to demonstrate compliance to the Authority on request, and the position is clear: who can move client money is a Code question, not an office preference.
The Essential Eight is stricter than you expect
"Restrict administrative privileges" is one of the eight mitigation strategies in the ASD's Essential Eight, and the maturity model's baseline is more demanding than "not everyone is an admin".
At Maturity Level One it requires that:
- requests for privileged access to systems, applications and data repositories are validated when first requested
- privileged users are assigned a dedicated privileged account used solely for duties requiring it
- privileged accounts (other than those explicitly authorised) are prevented from accessing the internet, email and web services
- privileged accounts explicitly authorised for online services are strictly limited to what is required
- privileged users use separate privileged and unprivileged operating environments
- unprivileged accounts cannot log on to privileged environments, and privileged accounts (excluding local administrator accounts) cannot log on to unprivileged ones
The third of those is the one that surprises people: the account with administrative rights should not be the account reading email. That is a direct answer to how compromise actually spreads — a phishing email opened under an administrative account gives an attacker the practice, not a mailbox.
For a small practice this does not require enterprise tooling. It requires that the person who administers the systems has two accounts and uses the powerful one only when administering.
Designing roles for a migration practice
Start from tasks rather than seniority. Four dimensions matter, and they are independent of one another.
Matter access. Who can open which files. The honest default for most practices is everyone, and the honest question is whether that is necessary. A paralegal working on skilled matters does not need the protection files. A bookkeeper does not need the relationship evidence.
Financial access. Distinct from matter access and generally narrower. Separate the ability to raise an invoice from the ability to move money, and require two people for anything leaving the account holding client money.
Administrative access. User creation, permission changes, integration keys, export. This is the privileged tier the Essential Eight is describing, and it should be small enough to name.
Client-facing identity. Who can send correspondence, and under whose name. This connects back to the MARN duties: work that appears to come from an agent should have come from that agent.
Sensitive matters deserve their own tier
Some files justify tighter access than the practice default, and it is worth naming them rather than deciding case by case:
- Protection matters, where exposure can create physical risk to people offshore
- Matters involving family violence, where an ex-partner may know someone at the practice
- Matters where a staff member has a personal connection to the client, sponsor or employer
- Complaints and disputes, where the person complained about should not be reading the file
A system that can restrict a matter to a named list, rather than to a role, is what makes this practical.
Access is not only what a person can open
Two other categories carry the same risk and are usually invisible.
Integrations. An automation tool, a document generator, an accounting connector or an AI assistant with an API key is a user with permissions. Those keys are frequently created once, scoped broadly because it was easier, and never reviewed. Under the Privacy Act, where it applies, an entity holds information beyond what it physically possesses — extending to any record it has the right or power to deal with. Data reachable through an integration is data you hold.
Contractors and offshore teams. The Code's definition of an agent's business takes in consultants, independent contractors and volunteers, and OMARA's guidance says the obligations apply whether staff are onshore or offshore. A contractor with full access is inside every duty in this article.
Reviewing it without it becoming a project
Quarterly, and it should take under an hour:
- List every account with access to client information, including integrations and contractors.
- Confirm each belongs to someone who still works here. This is where most findings appear.
- Check the privileged tier — is it still the smallest set that works, and does each of those people have a separate unprivileged account?
- Check financial access against who actually handles money now.
- Check exceptions. Temporary access granted for a matter in March should not still exist in September.
- Record that you did it. Under section 32 you must respond to Authority requests completely, and a dated access review is a document you would rather have.
The access test
- Could a new paralegal open a protection matter on their first day?
- Can one person move money out of the client account alone?
- Does the person who administers your systems read email from an administrative account?
- How many integrations hold an API key, and when were their permissions last reviewed?
- Can you restrict a single matter to named people, or only by role?
- Does a contractor have less access than an employee, or the same?
- If someone left last month, is their access gone — including from integrations?
Where a system helps
Access control fails at the seams. A practice running on a shared drive plus email plus a case management system has three permission models that do not know about each other, so a role removed in one place persists in the other two.
Consolidation makes least privilege achievable rather than aspirational: one place where a person exists, one set of permissions, one removal when they leave, and a log of who opened what. Our guides to moving off legacy tools and growing from solo to a team cover the transition.
LodgeHQ supports per-role and per-matter access with individual accounts and an access log. Our Code compliance checklist covers the duties this supports.
Verify before you rely on it
The Essential Eight maturity model changes between revisions and the requirements quoted here should be read in the current version before you set a target. Whether the Privacy Act binds your practice depends on your structure and turnover.
This is general information for migration practices, not security or legal advice. Where you hold protection matters, take advice on access controls proportionate to the risk to those clients.