When the whole firm logs into one shared CRM account, every lawyer and assistant sees every client's case — including one closed three years ago. That is not just inconvenient: GDPR requires the controller to keep control over who has access and to what extent, instead of leaving it to whoever knows the shared password. For a small firm with a few lawyers and assistants, the question comes back with every new hire and every audit: who gets access, when it should be narrowed, and when client data from a long-closed case may actually be deleted.
Below: what Article 29 and Article 17 GDPR actually say about access control and data deletion, where the firm's responsibility ends and the CRM provider's begins, and what closing a case looks like in practice — from narrowing access to a reminder to review it.
One shared CRM login sees everything
In many firms the CRM has one account for the whole team, or everyone signs in under the same administrative access. The result: an assistant who joined this month sees, in the very same view, a case from three years ago that was closed and settled long since. Nobody planned it that way — nobody ever turned the access off, because there was no such switch and no such procedure.
Example on assumed numbers — substitute your own: if a firm handles 40 cases a year on paper, and access to a closed case is never deliberately narrowed, then after 3 years about 120 closed cases sit visible to the whole team under one shared account, including people who never worked on them at all.
The problem is not theoretical: the more people who can see a case that no longer needs to be shared, the harder it is to answer a regulator's question about who could see that data and why. "Everyone, because it was convenient" is not an answer that holds up.
Article 29 GDPR: authorization and access control
What Article 29 GDPR actually says
Article 29 GDPR, in short: the processor and anyone acting under the controller's authority who has access to data must process it only on the controller's instructions (UODO — authorizations to process data). In other words, access to a firm's client data is not an employee's entitlement — it's an instruction that the controller, the firm itself, deliberately gives and can withdraw at any time.
Authorization as an organizational measure, not paperwork
UODO states plainly that issuing authorizations can be one of the organizational measures aimed at controlling who has access to data and to what extent (same source). In a CRM that translates directly into roles: the lawyer running a case sees its file, someone outside the team doesn't see it at all until someone deliberately changes that setting. An authorization on paper that isn't reflected in the system's settings is fiction that won't survive a regulator's question about how it actually works.
Who is the controller, who is the processor in a CRM
A firm that collects client data is the controller of that data. If an outside vendor runs the CRM, that vendor usually acts as a processor — it processes data on the firm's instructions, not on its own account. That distinction isn't paperwork for a contract; it's a real split of responsibility.
When an outside vendor runs the CRM
In its notice about fines against McDonald's Polska and its processor, UODO restates the general rule: both the controller and the processor are responsible for the protection of personal data (UODO, 21 July 2025). For a firm, that means choosing a CRM vendor and checking how it secures access to data isn't something to sign once and forget — it's a share of responsibility that can't be handed over entirely to the vendor. Before signing such a contract, it's worth checking what the system even exposes externally — sometimes the answer is "nothing," and it's better to know that upfront than after an incident, the same way it gets checked before any Integrations between two systems. We cover where customer data physically ends up in such connections in a separate piece on automation and GDPR.
Article 17 GDPR: the duty to delete data and the claims exception
Article 17 GDPR requires the controller to delete data, among other cases, once it's no longer needed for the purpose it was collected for (UODO — the right to erasure in practice). For a closed client case, the question is direct: does the firm still need anything from that case's data?
The right to erasure isn't absolute, though. A controller can refuse to delete data if it's needed, among other reasons, to establish, exercise or defend legal claims (same source) — and for a law firm that's an everyday situation: a case closed today can resurface as the basis of a claim by the client or the other side a year or two later.
If a client asks to have their data deleted, the controller should respond without undue delay, at the latest within a month; for a complex request the deadline can be extended by another two months, provided the person is told before the first month is up (same source). That is a real deadline the firm needs a set procedure for, not something to improvise on the first such request.
Access by case, not to the whole client base
The practical rule that follows directly from Article 29 GDPR is simpler than the article itself: access is granted per case, not to the firm's entire client base. A lawyer handling a payment dispute doesn't need visibility into a divorce case handled by a colleague on the same team.
Access is granted and revoked on the permissions side, not by sending someone a password — that's exactly the mechanism behind API in systems that split data access by role rather than by who happens to know the login. The scope is defined directly: what a given person sees, and what stays out of their reach, instead of a default "sees everything because they're on the team."
What the system doesn't decide for the lawyer
No CRM can judge whether data from a closed client case is still needed to defend the firm's interests. That takes an assessment of the specific case — who the parties were, what the dispute was about, whether there's still a reasonable basis to expect a claim — and that assessment is made by a lawyer, not an automated system.
At most, the system can remind someone that this assessment is due by a set date after the case closes; it doesn't make the decision to delete or retain the data for anyone. That distinction is worth writing clearly into the firm's internal procedure, so nobody assumes "the system would have blocked it if something were wrong."
What closing a case in the CRM looks like, step by step
In practice, closing a case in a CRM breaks down into a few states that differ in who sees what:
| Case status | Who has access | What they can do |
|---|---|---|
| Case open | the whole team assigned to it | views and edits the file day to day |
| Closed, less than a year | the team that handled it | views without edit rights |
| Closed, over a year | archive role only | has view access, no editing |
| Flagged for legal review | the person assigned to review it | decides: keep or delete the data |
Moving between these states doesn't happen on its own with the passage of time — it's a setting the firm chooses deliberately, and the system only makes sure it never gets skipped for a given case.
Check it yourself: cases closed a year ago or longer
- Pull from the CRM every case closed more than a year ago — not just by closing date, but by whether anyone has touched it since.
- For each one, answer in one sentence: is there a reason the data should still be visible to the whole team, for example an open dispute where the case could serve as evidence.
- Where there's no such reason, narrow access to whoever actually owns the archive, instead of leaving it open to the whole team.
- Note a date against the case for when someone will come back and decide for good: keep the data longer, or delete it.
This review is easier to keep on track once it becomes an actual task with a deadline and a named owner, rather than good intentions that get lost under the day's caseload (Tasks). Doing this kind of review often turns up the same client sitting in two separate CRM records — one from the old case, one from the new. Customer Data merges such records by what actually identifies the person, by phone or email, so two independent profiles of the same person don't live side by side. More generally, on what this kind of clean-up can realistically be handed to a system versus what always stays with the team, see what can realistically be handed over to a system and what cannot.
What it looks like once a system manages access
- 01Case closed
- →02access narrowed to archive
- →03reminder to review
Aura doesn't decide what happens to the data in this scenario — that stays with the lawyer either way. The system only makes sure closing a case actually narrows access, and that the reminder to review the deadline doesn't depend on someone remembering it. It's the same role-and-permission mechanism behind Admin panels — one shared access structure instead of separate settings for every case. A similar reminder mechanism sits behind reporting automation, which makes sure numbers reach the owner instead of waiting for someone to open a dashboard.
If you want to see what this kind of access narrowing and reminders looks like in practice, it's worth looking at Integrations, or at how the whole client-data structure works in Customer Data. If this is the firm's first step toward automation, four thresholds instead of general analysis is a reasonable place to start; before asking for a quote, it's worth checking the 2026 ranges for process automation cost.
Frequently asked questions
Does a law firm's CRM access have to be one shared account for the whole team?
No, and under Article 29 GDPR it shouldn't be — the controller is meant to control who has access to data and to what extent (UODO). A single shared account means that control doesn't really exist in practice, because nobody can tell who actually opened a given case.
Who is responsible for data security if an outside vendor runs the CRM?
Both the controller — the firm — and the processor — the CRM vendor — are responsible for the protection of personal data (UODO, 21 July 2025). Choosing a vendor and checking its safeguards is not something that can be handed over to the vendor entirely.
Does client data have to be deleted right after a case closes?
Not automatically. The controller must delete data once it's no longer needed, but can retain it if it's necessary to establish, exercise or defend legal claims (UODO) — and for a law firm that's a very common situation.
How long does a firm have to respond if a client asks to have their data deleted?
The response should come without undue delay, at the latest within a month; for a complex request the deadline can be extended by another two months, provided the person is told before the first month runs out (UODO).
Can a CRM decide on its own to delete a client's data?
No — at most the system can remind someone that a case review is due. The decision on whether the data is still needed to defend the firm's interests belongs to a lawyer, not to automation.
What should a new employee see in the CRM on their first day?
Only the cases they've been formally assigned to, not the firm's entire history. That's a direct application of Article 29 GDPR: access follows from an authorization to a specific scope of data, not from the mere fact of being employed (UODO).