Data protection for Spanish law firms: a 2026 guide

By Ivor Padilla and Gabriel Naranjo, co-founders of Gradion · Published on 10 April 2026 · Last updated: 10 April 2026 · 15 min read

Data protection in a law firm is not the privacy notice on your website, and it is not the PDF that an external consultant signed back in 2018. It is the living file that a partner has to be able to open tomorrow if the Spanish data protection authority (AEPD) comes calling, if a client asks for everything the firm holds on them, or if someone finds out that a laptop with case files has been missing for two days. And most of the firms we work with believe they are up to date when in fact the record of processing activities on their shelf describes the firm as it was four years ago, not as it is today.

This post is the whole map. Which rules apply when you are a Spanish law firm (as opposed to an ordinary business), which obligations are non-negotiable, when you need a Data Protection Officer (DPO), which contracts you must sign with your suppliers before a single piece of client data flows through them, how to answer a subject access request without grinding the firm to a halt, and what happens in the 72 hours after a security breach. With links to the relevant laws in the BOE and to the AEPD's own tools so you can check the sources yourself.

TL;DR — Data protection in a law firm boils down to six non-negotiable obligations: (1) pick a lawful basis under art. 6 GDPR before each processing activity and document it; (2) keep the record of processing activities (art. 30 GDPR) alive and up to date; (3) sign a processor contract (DPA) with every supplier that handles client data (art. 28 GDPR); (4) put in place security measures proportionate to the risk (art. 32 GDPR); (5) notify breaches to the AEPD within 72 hours and, when the risk is high, to the data subject as well (arts. 33-34 GDPR); and (6) respond to data subject rights within one month (arts. 12 to 22 GDPR). The lawyer's professional secrecy sits on top of all of this without displacing it.

How "data protection" is different when you are a law firm

A Spanish law firm processes client data under conditions that no online shop or ordinary service business shares. On the one hand, professional secrecy is enshrined in the statute of the legal profession itself as both a duty and a right — not as an internal policy. On the other, case files typically contain special categories of data under art. 9 GDPR (health data, political opinions, biometric data, racial or ethnic origin), and often data relating to criminal convictions and offences under art. 10. That raises the compliance bar meaningfully above the baseline case.

A Spanish law firm is not an ordinary business from a data protection standpoint. Article 21 of Spain's General Statute of the Legal Profession — enacted by Royal Decree 135/2021 of 2 March, and in line with the 1985 Judicial Power Act — enshrines the duty and right of professional secrecy of the lawyer: the relationship of trust with the client obliges the lawyer to keep secret every fact or piece of information learned in the course of professional practice, and the lawyer cannot be compelled to disclose it in court. In practice, professional secrecy sits on top of data protection rules and, when the two appear to clash, it works as an added layer of confidentiality — not as an excuse to bypass the GDPR.

Article 22 of the General Statute of the Legal Profession defines the scope of professional secrecy broadly: it covers "all facts, communications, data, information, documents and proposals" learned, produced or received by the lawyer while practising. That breadth is deliberate, and it matters when you read it alongside the GDPR: the content of case files and client communications is covered by professional secrecy and is not disclosed when notifying a breach to the regulator. The notification describes the nature and scope of the breach — categories of data, number of individuals affected, timing, mitigation — not the substantive content of the files. Doing both at the same time is both technically possible and legally required.

The practical consequence: in a law firm, talking about data protection without talking about professional secrecy is pointless. The two frameworks travel together. The good news is that, in the vast majority of cases, they reinforce the same behaviour — they do not clash. The less good news is that when there is apparent tension, you have to think carefully about the specific case rather than reach for a generic template borrowed from another sector.

The legal framework that applies: GDPR, LOPD-GDD, and professional secrecy

The framework that a Spanish firm has to keep in its head is shorter than it looks. It is made of three pieces with a clear hierarchy: the European Regulation (GDPR), the Spanish organic law that implements it (LOPD-GDD), and the sectoral rules for the legal profession — the General Statute of the Legal Profession, the Code of Ethics of the General Council of Spanish Lawyers, and the Judicial Power Act where relevant. On top of that sit the guidance and tools published by the AEPD, which are not law in the strict sense but which an inspector will cite if they visit.

The GDPR (Regulation (EU) 2016/679) is the European regulation, directly applicable in every member state. It sets the principles (art. 5), the lawful bases (art. 6), the rights of the data subject (arts. 15-22), the obligations of the controller and the processor (arts. 24-30), security of processing (art. 32), breach management (arts. 33-34), the DPO role (arts. 37-39) and the general sanctions regime (art. 83). It is the core.

The LOPD-GDD (Organic Law 3/2018) complements the GDPR with national specificities: a Spanish list of sectors that must appoint a DPO (art. 34), its own sanctions regime (Title IX, arts. 70 to 78), recognition of digital rights (Title X), and other peculiarities that matter for the public sector and for specific categories of controllers.

And running through both of the above, as the sector-specific thread, are the General Statute of the Legal Profession (Royal Decree 135/2021), the Code of Ethics of Spanish lawyers, and the dimension of professional secrecy as set out in Organic Law 6/1985 on the Judicial Power — to which the Statute's art. 21(1) expressly refers. These are not "data protection" rules in the strict sense, but they are read together with the GDPR whenever the data controller is a law firm.

The six core obligations of any Spanish law firm

Distil the three pieces of the framework above into something operational and you end up with six concrete obligations. These are the ones an inspector will look at first if they visit your firm tomorrow, and they are the ones you need running from the first day of a new client.

1. A lawful basis before every processing activity

Article 6 of the GDPR is a closed list of lawful bases for processing: consent, performance of a contract, legal obligation, vital interests, public interest task and legitimate interests. Before a single piece of personal data flows through your firm — whether it is being processed automatically, manually, or just sitting in the office inbox — you have to know which of those six you are relying on. And you have to have it written down. If the basis is legitimate interests, you also need a balancing exercise on file. That is the one a regulator will ask to see first.

For most day-to-day processing in a law firm, the lawful basis is performance of a contract (the engagement letter the client signs when the file is opened) and, in parallel, legal obligation for everything to do with invoicing, document retention and tax compliance. Consent, contrary to what the market tends to assume, is used sparingly in a professional practice — mainly for marketing communications to former clients or for messages that do not flow directly from the engagement.

2. A live record of processing activities

Article 30 of the GDPR requires every controller to keep a record of processing activities with a fixed minimum content: contact details of the controller and DPO if any, the purposes of processing, a description of the categories of data subjects and personal data, categories of recipients, international transfers, retention periods, and a general description of the technical and organisational security measures in place. For a law firm, this record is not a PDF that gets signed once and filed away. It is the living map of everything that happens to personal data in the firm: when a new piece of software is installed, when the email provider changes, when a new trainee joins and gets access to client files, when something is automated — the record is updated. If it is not updated, within six months it no longer describes reality.

3. Transparency and the art. 5 principles

Article 5 of the GDPR sets out six principles that govern every processing activity — including everything your firm does with a client file: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; and integrity and confidentiality. And then a seventh that cuts across them all: accountability — the obligation of the controller to demonstrate, in writing, that all six are being met. Compliance is not enough on its own. You have to be able to show the paperwork when an inspector asks.

The transparency principle is the one the legal sector most often forgets. Articles 13 and 14 of the GDPR require the controller to inform the data subject who is processing their data, for which purposes, on which lawful basis, for how long, to whom the data will be disclosed, whether there are international transfers, what rights the data subject has, and how to exercise them. That information usually sits inside the engagement letter or in a clause annexed to it. If your firm's engagement letter does not include an information clause, you are breaching an article that any inspector will pick up in the first minute.

4. Contracts with processors

Every time your firm hires a third party to handle client data — the practice-management software, the corporate email provider, the e-signature platform, the cloud antivirus, the AI tool drafting the first pass of a brief — that third party is a processor under Article 28 of the GDPR. And Article 28(3) requires the relationship to be governed by a contract that binds the processor to the controller, and spells out — in writing — the subject matter, duration, nature and purpose of the processing, the types of personal data, the categories of data subjects, and the obligations and rights of the controller. The industry name for that document is DPA (Data Processing Agreement). Without it, the processing is unlawful. It is not a paperwork formality.

We come back to this point in its own section below, because it is where we most often find unpleasant surprises in firms: long-standing suppliers for whom nobody in the firm can produce the signed DPA. In the post on GDPR and AI automation in law firms we go into more detail on what a DPA should contain when the supplier is an AI provider (that post is written in Spanish — we are producing the English version next).

5. Security measures proportionate to risk

Article 32 of the GDPR does not prescribe specific products or encryption algorithms. It requires measures appropriate to the risk, and it lists the four that should almost always be in place: pseudonymisation or encryption of personal data, confidentiality, integrity, availability and resilience of systems, the ability to restore access quickly after an incident, and a regular process of testing and evaluating all of the above. Translated to a law firm: encrypted laptop and server drives, backups with a restoration plan that has actually been tested, role-based access control with reasonable passwords and MFA, and a yearly check that it all still works. The article does not prescribe tech. It prescribes outcomes.

6. Breach notification within 72 hours

The sixth obligation — breach management — has its own section below, because it is the one that generates the most operational uncertainty on the day an incident actually happens.

Do you need a Data Protection Officer (DPO)?

The short answer: most small and mid-sized Spanish law firms are not legally required to appoint a DPO, but many do so voluntarily out of caution and because having a single point of contact with the AEPD pays for itself. The longer answer is the one that matters, because the devil is in two very specific articles: art. 37(1) GDPR and art. 34 LOPD-GDD.

Article 37(1) of the GDPR sets three cases in which a data protection officer must be appointed: (a) when the processing is carried out by a public authority or body (except courts acting in their judicial capacity); (b) when the controller's core activities consist of regular and systematic monitoring of data subjects on a large scale; or (c) when the core activities involve large-scale processing of special categories (art. 9 GDPR: health, racial origin, political opinions, religious beliefs, biometrics...) or data relating to criminal convictions (art. 10). Most law firms do not fall into any of the three by default. A criminal-defence practice that routinely handles conviction data, on the other hand, can land squarely in category (c).

Article 34 of Spain's data protection act (LOPD-GDD, Ley Orgánica 3/2018) adds to the three GDPR cases a Spanish list of sectors that must appoint a DPO by default: professional associations and their general councils, educational institutions, electronic communications providers processing data at scale, information-society providers carrying out large-scale user profiling, credit institutions, financial establishments, insurance and reinsurance companies, investment firms, electricity and gas suppliers, credit-reference agencies, and a handful of others. Law firms are not on that list as such. The Bar Associations (letter a) are included, but not the individual practices that belong to them. That means a law firm is not required by law to appoint a DPO simply by being a law firm. The obligation only kicks in if it falls into one of the three GDPR scenarios (public authority, large-scale regular and systematic monitoring, or large-scale processing of special-category or criminal-conviction data).

Article 36 of the LOPD-GDD reinforces the DPO's position in three practical ways: (1) the DPO acts as interlocutor with the AEPD on behalf of the firm; (2) if the DPO is an individual integrated into the organisation, they cannot be dismissed or penalised for doing the job — that is an explicit independence guarantee; and (3) the DPO must have access to personal data and processing activities, and the controller cannot rely on any duty of confidentiality or secrecy to deny that access. In practice many firms appoint an external DPO precisely to avoid the tension that an internal one can create when investigating issues inside the firm itself.

The practical case for appointing a DPO even when you do not have to

Even when the law does not require it, in mid-sized firms that handle any serious volume of special-category data (employment cases with health records, family law with data on minors, criminal defence, immigration…) our recommendation is yes, appoint an external DPO. Three reasons:

1. Single point of contact with the AEPD. When a complaint, a query or an inspection lands, having a documented channel through an appointed DPO prevents improvised responses from different members of the firm.
2. Independent documentary review. The DPO audits the record of processing activities, the processor inventory, the signed DPAs, the security measures and the lawful-basis documentation. It is a cheap, recurring audit.
3. Mitigation of sanctions. In a sanctions procedure, the existence of an appointed DPO with a documented workload is one of the mitigating factors the AEPD considers when placing a fine within the art. 83 GDPR bands.

The cost of an external DPO for a small or mid-sized firm is manageable — it is normally billed by blocks of hours — and the first complaint it handles will usually pay for the year.

Contracts with processors: what to sign before any data moves

This is the section where firms most often get an unpleasant surprise. The rule is simple: every supplier that touches client data needs to have a signed DPA with your firm before the first piece of data lands in their system. Every one.

The typical list in an average Spanish mid-sized firm, as of 2026, includes at least:

• Practice-management software (Aranzadi, Lefebvre Jurisoft, LeTech, SLI, gescodex…). Yes, even if the data physically sits on your own server, if the supplier accesses it remotely for technical support they are processors.
• Corporate email (Microsoft 365, Google Workspace, Zoho, etc.). The DPA is usually available on the provider's portal and has to be expressly accepted.
• Cloud storage (OneDrive, Dropbox Business, Google Drive, owned cloud servers on Azure or AWS). Same treatment.
• External backups.
• E-signature (Docusign, Validated ID, Signaturit…).
• Video-conferencing platform when used for client meetings (Zoom, Meet, Teams).
• Cloud-managed antivirus and security.
• AI tools when used with real client data (first-draft briefs, case law summaries, contract data extraction…). In the AEPD and AI in law firms guide we go into what the regulator asks for these providers specifically.
• External accountant or tax adviser if they share payroll or billing data with you.
• Confidential document destruction (the company that takes your shredded bins away).

For each of these, there has to be a signed DPA (or express acceptance of the provider's standard terms, which has the same legal effect), and the date of signature has to be on the record of processing activities. If you find a supplier in the firm without a DPA, you have two things to do: sign one now, and annotate the record of processing activities noting that the processing has been going on without a contract for X time. The second is awkward but required: hiding it turns a minor breach into a more serious one the day it is discovered.

Data subject rights: how to answer within the deadline without grinding the firm to a halt

Articles 15 to 22 of the GDPR grant the data subject a bundle of rights that the industry summarises as ARCO-POL in Spanish and as "data subject rights" in English: access (art. 15), rectification (art. 16), erasure (art. 17, the "right to be forgotten"), restriction (art. 18), data portability (art. 20), objection (art. 21), and the right under art. 22 not to be subject to a decision based solely on automated processing when it produces legal or similarly significant effects. Article 12(3) sets the general response window at one month from receipt of the request, extendable by two further months when the complexity or the volume of requests justifies it — and provided the data subject is informed of the extension within the first month. In practice: the clock starts the moment the email arrives, not the moment someone in the firm reads it.

In a firm, the most frequent requests are access ("I want to know what data you hold on me"), erasure ("delete everything related to me") and rectification ("this fact is wrong, correct it"). For each one it helps to have an internal protocol that specifies:

• Who receives the request. Usually a central firm mailbox (for example dpd@firmname.es) handled by a single partner or by the DPO when there is one.
• How the requester's identity is verified. The firm cannot hand over client data to whoever asks without confirming they really are the client. Scanned ID, video call, electronic signature or an in-person visit are valid options.
• How wide the answer should be. The right of access covers a copy of the data being processed, not necessarily the complete original documents in which those data appear. Be careful: an unfiltered handover of case files can collide with professional secrecy in respect of third parties (the opposing party, for instance).
• How quickly you reply. Internal target: a week. Legal maximum: one month from receipt. Exceptional extension: two further months, notified within the first month.
• Free except in exceptional cases. Requests are free of charge unless they are "manifestly unfounded or excessive", in which case the controller can charge a reasonable fee or refuse on reasoned grounds. Do not use this exception as a default — it is only for genuinely abusive cases.

Security breaches: the 72 hours nobody wants to face

When an incident affects personal data — from a stolen laptop to unauthorised access to a case file or a lost client backup — Article 33(1) of the GDPR requires the controller to notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it". If the notification misses the 72-hour window, it must be accompanied by the reasons for the delay. The only exemption is when the breach is unlikely to result in a risk to the rights and freedoms of the data subjects — an exemption that has to be documented and that, in a law firm where files routinely include sensitive data, is very hard to rely on.

Notifying the supervisory authority is not always the end of it. Article 34 of the GDPR adds a second step: when the breach is likely to entail a high risk to the rights and freedoms of the individuals concerned, the controller must also communicate it directly to the data subject without undue delay. In a law firm that means getting on the phone to the client, in plain language, and explaining what happened, which data was affected, and what they can do to protect themselves. It is an awkward conversation that is easy to put off on commercial grounds; but the calculation changes when the alternative is the client finding out from a third party and filing a complaint.

The protocol you want in place before the breach happens

Six things need to be decided before anything happens:

1. Who learns about it. A single point of internal contact for security incidents. If there is a DPO, it is the DPO. If not, it is a designated partner.
2. How the risk is assessed. A simple template with criteria: volume of affected individuals, categories of data exposed, probability of malicious use, reversibility of the breach. The AEPD publishes guidance on how to run this assessment.
3. Who drafts the AEPD notification. A pre-drafted template that gets filled in with incident-specific data. The AEPD provides a form through its electronic portal.
4. Who talks to the client. A pre-drafted script, adapted to each case. Never by mass email or a standard letter: a personal phone call or an individual email.
5. How to separate "content" from "nature of the breach". This is the key to coexistence with professional secrecy: you describe what happened and who is affected, not the substantive content of the case files. The inspector does not need to read the files to assess the breach.
6. How the whole process is documented. Every decision is recorded with a date and a responsible person, including the ones where you decide not to notify because of the art. 33(1) in fine exemption.

The protocol has two uses: the obvious one, when a breach happens. And the less obvious one, when an inspector asks "show me your breach protocol". If it exists and it is up to date, the conversation goes very differently.

Frequently asked questions about data protection in Spanish law firms

Does my firm have to appoint a DPO?

Most firms do not, if you go strictly by the letter of art. 37(1) GDPR and art. 34 LOPD-GDD (law firms are not on the Spanish list as such). But if your practice processes health data, conviction data, biometric data or minors' data at scale, you can land in letter (c) of art. 37(1) GDPR and the appointment becomes mandatory. And even when it is not, appointing an external DPO is a sensible call for the operational reasons we explained above.

If the AEPD inspected me tomorrow, which documents would I need to have on the desk?

At least five: (1) an up-to-date record of processing activities; (2) the information clause delivered to the client (inside the engagement letter or annexed to it); (3) signed DPAs with every processor; (4) a security policy with documented technical and organisational measures, including a backup plan with evidence of the last successful restoration test; (5) a breach and data subject rights protocol. If you have a DPO, add the appointment document and the DPO's latest report. The post on what the AEPD looks for in AI-related inspections goes into more detail for the specific AI case.

Do I have to sign a contract with my practice-management software supplier? And with the email provider?

Yes to both. Any supplier accessing your clients' personal data — even only for technical support — is a processor under art. 28 GDPR and needs a signed DPA before any processing starts. For the big providers (Microsoft 365, Google Workspace, the main legal-sector vendors) the DPA is available on their compliance portal and can be accepted online; what matters is that you keep evidence of the acceptance with a date, in case you need to prove it later.

A client asks for everything I hold on them. Am I obliged to give it? How long do I have?

Yes. Article 15 GDPR recognises the right of access to the data subject's own data, and art. 12(3) sets the deadline at one month, extendable by two more. What you must provide is a copy of the personal data you process about them, not necessarily the full case file (because the file may contain third-party data covered by professional secrecy). In practice you prepare a structured response: purposes of processing, categories of data, origin, recipients, retention periods, and the actual content of the client's data.

We suspect someone has accessed a case file without authorisation. What should we do?

Trigger the breach protocol immediately. First, contain the incident: change passwords, revoke access, isolate the affected system. Second, document what happened with dates, times and the people who discovered it. Third, assess the risk to data subjects with your template. Fourth, if the risk is not unlikely, prepare the notification to the AEPD within 72 hours of the moment the firm became aware of the incident. Fifth, if the risk is high, communicate it to the affected client. The clock starts when someone in the firm becomes aware, not when the partner sees it.

Can we use ChatGPT, Copilot or similar tools with client data?

It depends on several things and deserves a post of its own. In short: you need a lawful basis to put the data into an AI provider (usually legitimate interests or contract performance with a prior balancing exercise), a signed DPA with the provider, confirmation that the data is processed inside the EU or under adequate transfer safeguards, tenant isolation, a setting that disables model training on your data, and an entry in your record of processing activities. The GDPR and AI automation in Spanish law firms guide (currently in Spanish, English version in the pipeline) walks through the five GDPR principles applied to this exact scenario.

What fine could we realistically face?

Article 83 of the GDPR sets the sanctions regime in two bands. Lower band (art. 83(4)): up to €10 million or up to 2 % of worldwide annual turnover of the previous financial year, whichever is higher. Upper band (art. 83(5)): up to €20 million or up to 4 % of the same turnover, whichever is higher. Those are theoretical ceilings: most real sanctions against small and medium-sized firms land far lower, and the final figure is modulated by the seriousness of the breach, intent, cooperation with the regulator, and remedial action taken afterwards. In other words, the same mistake can cost €3,000 or €60,000 depending on what happens in the 30 days that follow.

Title IX of the LOPD-GDD (arts. 70 to 78) completes the sanctions regime of the GDPR at Spanish level. It classifies infringements into very serious (art. 72, three-year limitation period), serious (art. 73, two-year period) and minor (art. 74, one-year period), and refers to the GDPR art. 83 bands for the caps. Examples explicitly listed as very serious include processing personal data in breach of the art. 5 principles, or without any art. 6 lawful basis. For a law firm, that is a reminder that getting the lawful basis wrong is not a minor slip: it can be classified as very serious, not minor.

How we are handling this at Gradion

The record of processing activities is the single most important document and the one we find out of date most often in the firms we work with. Not because it does not exist — most firms have the one their external consultant put together in 2018 or 2019 when the LOPD-GDD came into force — but because that record, as it stands, no longer describes the firm's operational reality in 2026. The practice-management software has changed at least once, e-signature has moved to a different provider, corporate email now lives on Microsoft 365 or Google Workspace with copies on a server that did not exist before, and a trainee has dropped an AI tool into the case-summary workflow without telling anyone. Meanwhile, the record still reads the way it did in 2019.

When the AEPD inspects a firm, the first question is "show me your record of processing activities". The second is "when did you last update it?". Both answers matter. In the firms we have worked with to date, the record of processing activities is the single document most frequently out of date — not because it does not exist, but because it was written once years ago and nobody has touched it when the software, the cloud provider or the internal workflow has changed.

We treat the record of processing activities as a living file that gets updated every time we touch the firm's workflow, not as a PDF that gets signed once and filed away. Every 10-day pilot we deliver comes with the update to the record for the processing activities it affects, signed with the date of the change. And when the automation involves a new supplier — an AI API, a cloud service, an e-signature platform — we make sure the DPA is signed before the first real piece of data passes through. Not after.

This turns the record into an operational tool, not a compliance formality. And it has an interesting side-effect: when the firm's partner opens the record at the next annual review, they find a document that describes the firm as it is today, not as it was four years ago. It is the first change most of the firms we work with notice, and it is the one that gives the most peace of mind. Gabriel Naranjo, co-founder of Gradion and a Microsoft Certified Trainer in cloud and security, leads this discipline from the first stand-up of every pilot: every processing activity we ship at Gradion has its living record in place before it goes into production.

Is your team losing 15 hours a week to paperwork?

We solve it in 10 days, with a fixed-price pilot. Every pilot we deliver ships with an updated and signed record of processing activities.

Tell us about your case →

This post is part of our series on data protection in Spanish law firms. For narrower angles, read what the AEPD requires when you automate with AI, and (in Spanish, English version coming next) how to apply the GDPR's five principles to AI automation.