Five bookkeepers and one shared login to the client system — that's how data access works at more than one small accounting office. Anyone on the team can open any client's file, even one they've never worked on, and nobody can say for certain who looked at what, or when. This isn't a question of trusting your team — it's a gap in how the office meets the obligation set out in GDPR Article 29.
Here's what you'll get from this page: what Article 29 actually requires from the controller and from anyone with access to the data, how the controller role differs from the processor role in an accounting office's daily work, how to limit access to "my" clients instead of the whole database, and when the list of authorizations needs a fresh review.
One shared login to every client's file
A team of 3–8 bookkeepers usually outgrows its permission system faster than anyone notices. At the start there's one accounting program and two people who know every case. Then more bookkeepers join, clients get split between them, but the login into the system stays one shared account — or everyone gets full access "just in case", so anyone can cover a colleague on leave.
The result: a bookkeeper who has handled nothing but construction companies for two years technically also has access to HR files of a client in a completely different industry she's never touched. Nobody planned this as a violation — it's simply the easiest way to make sure no one ever gets stuck without access. The problem is that GDPR doesn't ask about intentions, only whether the controller genuinely controls who has access to the data, and to what extent. It's the same idea behind what can realistically be handed over to a system, and what cannot — access to a client's data is one of the things you can't hand over to convenience.
What GDPR Article 29 requires: authorization isn't paperwork for a drawer
Article 29 GDPR states that the processor, and any person acting under the authority of the controller or of the processor who has access to personal data, shall not process that data except on instructions from the controller — Poland's data protection authority (UODO) makes exactly this point when answering whether controllers should still be issuing authorizations under GDPR (UODO on controller obligations). Its answer: yes, because it's one of the concrete ways to show that access is actually controlled, not that everyone simply holds a key to everything.
What "authorization" actually means
UODO points out a language nuance: in Polish, "upoważnienie" formally means a written power of attorney, but the English text of GDPR speaks of a person "acting under the authority of the controller". In other words, this is less about a piece of paper and more about the controller genuinely being in control of who processes data, to what extent, and on what terms. Authorization is one of the tools that can demonstrate this control.
Who the obligation covers: not just full-time staff
UODO's guidance also makes clear that this isn't limited to permanent employees — it covers anyone the controller has assigned work that requires access to personal data, including interns and trainees. The exception is people who are themselves a processor, or its employees — there, the obligation is covered by a data processing agreement, not an internal authorization.
The controller must be in control of who has access, and to what extent
UODO puts it directly: the point is to ensure the controller has control over who has access to personal data, to what extent, and under what rules and manner they process it. The measures a controller adopts for this purpose should prevent unauthorized entry, viewing, altering or deleting of data, and authorized people should only have access to the data covered by their specific authorization — not the whole database by default.
Issuing authorizations is one such organizational measure. On that basis, an office then applies access-control mechanisms inside the IT system itself: a specific person gets a specific scope, not an administrator login shared by everyone.
Controller and processor: two roles inside the same office
An accounting office is rarely only one or the other. For its own employees' data — HR, payroll, working-time records — the office is the controller and decides the purposes and means of processing itself. For client data it processes under a bookkeeping engagement, the office is usually a processor — carrying out the instructions of a controller who is, in this case, the client.
Why the distinction matters in practice
If the office is a processor for client data, access rules inside the team still have to meet the same requirement of Article 29 — every bookkeeper acting under the office's authority may process a client's data only on that client's instructions, within a scope defined by the agreement. Being a controller or a processor doesn't excuse anyone from watching who actually sees what.
Responsibility doesn't disappear once you sign a contract
One UODO announcement shows the mechanism well, even though it concerns a completely different industry than bookkeeping: in the case of fines against McDonald's Polska, the President of UODO stated plainly that both the controller and the processor are responsible for protecting personal data (UODO announcement, 21 July 2025). Among other issues, that case lacked a proper data processing agreement, even though the obligation to conclude one already followed from Article 28(4) and (9) GDPR before any inspection took place.
The fine amounts in that case, and the food-service sector itself, have nothing to do with an accounting office — transplanting them here would be dishonest. But the mechanism is universal: the fact that a subcontractor or a single employee processes the data doesn't remove responsibility from the controller, and the reverse is also true. Internal authorizations and the data processing agreement with the client are two separate obligations you have to meet both of, not either one.
Access by client, not access to the whole database
The practical consequence of all this is simple: access should be tied to the specific clients a person actually works with, not to the database as a whole. In a larger accounting system this is usually configurable at the role level — a bookkeeper sees her own clients, a team lead sees the team, an owner sees everything, instead of everyone holding the same account with full access.
Limiting access to the clients a person actually works with is, in practice, the data-minimisation principle from Article 5 GDPR: data must be adequate, relevant and limited to what is necessary for the purpose of processing (UODO guide citing Article 5 GDPR). In an accounting office, one bookkeeper's "purpose" is serving her own clients — not browsing the whole database in case it's ever useful.
Example on assumed numbers — substitute your own: an office with 5 bookkeepers and 60 active clients, where every bookkeeper technically has access to every file, has 5 × 60 = 300 possible "employee–client" combinations, even though only a fraction of those are actually justified. Splitting the clients evenly across the bookkeepers (60 ÷ 5 = 12 clients per person) brings the number of justified combinations down to 5 × 12 = 60 — the rest is access with no reason anyone could explain to an inspector.
What this looks like at the level of roles in the system
In practice that means three levels: a bookkeeper has access to her assigned clients, someone covering for a colleague on leave gets temporary access with an expiry date, and an owner or team lead has full visibility because that follows from their role, not from login convenience. The more people share one account "just in case", the harder it becomes for anyone to show who actually processed a given client's data.
What authorization alone does not solve
Authorization puts order into what happens inside the office's own team. It doesn't replace the data processing agreement the office must have signed with each client whose data it processes on that client's behalf. These are two different documents, two different obligations, and two different counterparts — one governs the office–employee relationship, the other the office–client relationship. We cover where client data physically ends up once several systems and subcontractors are involved separately, in automation and GDPR.
When to review the list of authorizations
A list of authorizations isn't something you sign once and file away. The natural moments to review it are: the end of an employment contract or engagement, a change of role in the team — for example a promotion to team lead that requires broader visibility — and the end of a working relationship with a specific client, after which access to that client's file should disappear, not stay "for later".
| Situation | What to do with access |
|---|---|
| A new bookkeeper joins the team | Grant access only to the clients assigned to them |
| An intern or trainee works on a specific case | Authorization limited to the internship period and that case |
| An employee changes role (e.g. gets promoted) | Update the scope of authorization to match the new role |
| An employee's contract ends | Revoke access on the last day, not "at some point" |
| A client ends the relationship with the office | Close the team's access to that client's file |
Do it yourself in a week: an access list
- List everyone who has any access to the system holding client data — including interns and people covering for colleagues.
- Next to each person, mark which clients they actually have assigned cases for this month.
- Compare that with what they actually have access to in the system — the gap is access with no justification.
- Check whether each of these people has a written or electronic authorization, rather than just a login passed on verbally.
- Mark in your calendar when contracts, internships and client relationships end — these are the natural moments to revoke access.
For an eight-person team, this list takes one afternoon, and it shows exactly the cases that are hard to explain during an inspection: "why does this person even see this". If this is the first clean-up you're doing in your data, four thresholds instead of a general analysis shows where to start in a small company.
What this looks like when a system manages access
Keeping the authorization list up to date in a spreadsheet works fine until the team grows, or someone forgets to update an entry. A system where access is tied to the client, not to a general account, does the bookkeeping for you:
- 01employee
- →02assigned clients
- →03file-open log
- →04an alert on a stranger's file
Who exactly has access to which clients is a decision the office owner makes — Aura's system doesn't decide that on its own, it only enforces the rules once they're set. In CRM and automations, client data and the people responsible for them are kept in one place instead of scattered files, and system integrations (Integrations) keep track of which data source is the real one and which is just a copy, so nobody has to guess where a client's file was last updated. Programmatic access to the data itself — for offices that build their own tools — is granted and revoked on the permissions side in the API, not by emailing someone a password. Reviewing authorizations after a contract ends or a role changes can become an ordinary task with a deadline (Tasks) and a responsible person, instead of depending on someone's memory. Access sits alongside other things the same system keeps in order: dashboards with sales numbers (Dashboards) and finance figures, and weekly AI Reports, similar to what we describe under reporting automation, that reach the team on their own instead of waiting for someone to open a panel.
Frequently asked questions
Does an intern at an accounting office also need an authorization?
Yes. UODO states plainly that the obligation covers not only permanent employees but anyone the controller has assigned work requiring access to personal data — including interns and trainees. The exception is people who are themselves a processor or its employees, for whom the obligation is covered by a data processing agreement instead.
How is an authorization different from a data processing agreement?
An authorization governs access inside the office's own team — which employees, and to what extent, may process data. A data processing agreement is a separate document between the office and the client, required among other things by Article 28 GDPR, and it's an entirely different obligation — neither replaces the other.
Is the controller responsible if the processor makes a mistake?
Yes. In the case UODO cited involving fines against McDonald's Polska, the authority confirmed that both the controller and the processor are responsible for protecting personal data — one side doesn't take on all the responsibility for the other.
What exactly does it mean that the controller must be "in control" of access?
According to UODO, it means genuinely controlling who has access to the data, to what extent, and under what rules it's processed — not simply holding a document. Authorization is one of the tools that can demonstrate this control, alongside access-control mechanisms inside the system itself.
Does an authorization have to be in writing?
It depends on which rule creates the obligation in your case. UODO notes that many sector-specific laws — the Polish Labour Code, for instance — explicitly require a written authorization. Which form applies to your particular office is worth checking with a lawyer or a data protection officer, since it depends on the industry and the legal basis for processing.
When should someone's access to client data be revoked?
The natural moments are the end of an employment contract or engagement, a change of role within the team, and the end of the relationship with a specific client. In none of these cases should access stay "just in case" — those are exactly the forgotten accounts that are hardest to explain during an inspection.