GDPR and Client Document Storage for Accounting Firms: How to Stay Compliant in 2026

Quick answer: An accounting firm handling client documents is processing personal and financial data, which makes it a data controller (and often a processor for its clients) under the GDPR. Article 32 requires "appropriate technical and organisational measures" and explicitly names encryption as one of them. But compliance is never a single tool: it covers where the files live, who can read them, how long you keep them, which subcontractors touch them, and how you react to a breach. Encrypting client files at rest, ideally with a system where the storage provider itself cannot read them, materially lowers both your breach risk and, in many cases, your notification burden. Encryption alone does not make a firm compliant, but its absence is one of the fastest ways to be found negligent.

This article is written for accountants and bookkeepers who want a practical, honest picture of their obligations. It is general information, not legal advice. For a binding assessment, consult your data protection officer or a lawyer familiar with your jurisdiction.

Why this question keeps accountants awake

An accounting practice is one of the densest concentrations of sensitive data a small business will ever hold. In a single client folder you may have payslips, bank statements, tax IDs, health-insurance contributions, dividend records, sometimes health data for sick-leave accounting, and the personal details of every employee your client pays. Multiply that by dozens or hundreds of clients and you are, in practical terms, a high-value target running on a laptop and a cloud drive.

Three pressures collide here. First, a legal duty: the GDPR treats the confidentiality and integrity of personal data as a core principle, and your professional-secrecy obligations sit on top of it. Second, a retention duty that pulls the other way: accounting records must be kept for years (commonly ten years for commercial accounting documents in France under the Code de commerce, six years for many tax records), so you cannot simply delete your way out of risk. Third, a supply-chain reality: the moment you drop a client's balance sheet into a mainstream cloud tool, you have added a subcontractor to your processing chain, whether you documented it or not.

The uncomfortable part is that most firms are technically exposed not because they were careless, but because the default tools make the readable-copy-on-someone-else's-server the path of least resistance.

What the GDPR actually requires (and what it does not)

It helps to separate the myth from the text. The GDPR does not say "thou shalt use AES-256." It sets an outcome-based standard and lists encryption as a recognised way to reach it.

Article 5(1)(f), integrity and confidentiality. Personal data must be processed "in a manner that ensures appropriate security," including protection against unauthorised access. This is a principle, and you must be able to demonstrate you meet it (accountability, Article 5(2)).

Article 32, security of processing. This is the operative one. It requires measures appropriate to the risk and gives examples, including "the pseudonymisation and encryption of personal data" and the ability to restore availability after an incident. Encryption is named explicitly. It is not mandatory in the absolute, but if you hold highly sensitive financial data and choose not to encrypt it, you will struggle to argue your measures were "appropriate to the risk."

Articles 33 and 34, breach notification. A personal-data breach must generally be notified to the supervisory authority within 72 hours. Crucially, if the breached data was rendered unintelligible to unauthorised parties (for example, strongly encrypted with keys that were not compromised), you may not need to notify the affected individuals at all under Article 34(3)(a). This is the single most concrete, bottom-line reason encryption matters to a firm: it can turn a reportable catastrophe into a non-event. The mechanics of that difference are worth understanding in detail, and I walk through exactly what changes between a classic cloud leak and a local-encryption leak in a dedicated piece.

Article 28, processors. If you store client files with a cloud provider, that provider is your processor (and you are your clients' processor). You need a data processing agreement, and you must use processors offering "sufficient guarantees."

Chapter V, international transfers. If your storage provider processes or stores data outside the EU (or on infrastructure controlled by a non-EU company), you inherit a transfer problem that standard contractual clauses only partially solve. This is where "we use a big US cloud" quietly becomes a compliance question.

The French supervisory authority, the CNIL, reinforces all of this in its guidance: it recommends encryption for sensitive and confidential data, both at rest and in transit, and treats it as a baseline expectation rather than a luxury.

The real choice: who can read the file

Most storage debates get lost in features. The question that actually decides your risk is simpler: when your data sits on someone else's server, can that server read it? Everything else follows from the answer.

Storage model	Provider can read your files?	Breach exposes readable client data?	Non-EU transfer risk	Fits 10-year retention
Classic cloud (Google Drive, Dropbox, Notion)	Yes (encrypted at rest, but they hold the keys)	Yes	Often yes	Yes, but readable
Local drive, no encryption	N/A (no cloud)	Yes if laptop stolen	No	Yes, but fragile
Full-disk encryption only (BitLocker, FileVault)	N/A	Protects a powered-off stolen device only	No	Partial
Zero-knowledge cloud (provider cannot decrypt)	No	No (only unreadable blobs leak)	Reduced (blobs are opaque)	Yes
Local-first + per-file encryption	No cloud unless you opt in	No	You control it	Yes

A point that trips people up: "encrypted at rest" on a mainstream cloud is real, but the provider holds the keys, so it protects against a stolen disk in their datacenter, not against the provider itself, a rogue employee, a subpoena, or a breach of their access layer. That is the difference between encryption and zero-knowledge encryption, where the host genuinely cannot read your data. The two are constantly confused in marketing copy, and the distinction is exactly the one an auditor will care about.

Another frequent gap: full-disk encryption like BitLocker or FileVault protects a laptop that is switched off and stolen. It does nothing once the machine is unlocked and running, and nothing for the copy you synced to a shared drive. It is necessary but not sufficient.

What this means concretely for your firm

Here is a practical checklist you can act on without a security team.

1. Map where client documents actually live. Not where policy says, where they are. Email attachments, a personal Dropbox, a shared drive, the intern's laptop. You cannot protect what you have not located.
2. Encrypt at the file level, not just the disk. File-level or client-side encryption protects data in use and in transit, not only a powered-off device. If you want the reasoning behind this, a practical guide to encrypting your documents and notes covers the threat models in plain language.
3. Prefer a model where the storage host cannot read the files. If your provider cannot decrypt, a breach on their side leaks noise, and your Article 34 notification duty to clients may fall away.
4. Document your processors and check where data physically sits. One line per tool: what it stores, where, under what agreement. This is your Article 28 and Chapter V paper trail.
5. Control access and enforce strong authentication. Separate profiles per user, no shared logins, a real password behind the encryption.
6. Have a recovery plan that is not "hope." Retention duties mean you must be able to restore data for years. Test your backups and know how key recovery works before you need it.
7. Write down your breach procedure. Who assesses, who notifies, within 72 hours. Encryption reduces the odds you ever run it, but you still need it on paper.
8. Match retention to the law, then delete. Keep accounting records for the legally required period, and have a defensible process to purge personal data once no obligation justifies keeping it.

Do not oversell any of this to your own clients. Encryption strengthens security-of-processing; it does not by itself make your practice "GDPR compliant," because compliance also depends on lawful basis, retention, transparency, and your organisational measures.

Where Filarr can help (and where it cannot)

Full disclosure: I build Filarr, so treat this section as context, not a sales pitch. Filarr is a local-first, encrypted workspace for notes and files. It fits the accounting use case on a few specific points:

• Every file is encrypted individually with AES-256-GCM, using a separate key per file (the file key is wrapped by a key derived from your password). One compromised file does not expose the others. If you want the design rationale, why per-file keys beat one global key explains the two-layer hierarchy.
• The password is stretched with PBKDF2-SHA512 at 600,000 iterations (the OWASP 2024 recommendation), with Argon2id available as an option, and a 24-word BIP-39 recovery phrase so you are not one forgotten password away from losing a decade of records.
• It works 100% offline. Cloud sync is optional, and when you enable it, files upload already encrypted: the server stores opaque blobs it cannot read, which is the zero-knowledge model applied to sync. You can also bring your own S3-compatible storage.
• It handles 51+ file formats, so scanned PDFs, spreadsheets and images live alongside your notes.

What Filarr does not do, honestly: it is not a GDPR certification, not a substitute for a data processing agreement, and not legal advice. It is younger than Obsidian or Notion, its mobile app is still in progress, and its ecosystem is smaller. It reduces the confidentiality risk on your documents. It does not manage your lawful basis, your retention schedule, or your client transparency obligations. Those remain your job, whatever tool you use.

FAQ

Does the GDPR legally require me to encrypt client files? Not in absolute terms. Article 32 requires measures "appropriate to the risk" and names encryption as a recognised example. Given how sensitive accounting data is, choosing not to encrypt is hard to defend as appropriate, and the CNIL recommends it for confidential data.

If my encrypted cloud gets breached, do I still have to notify my clients? Often no. Article 34(3)(a) says notification to individuals is not required if the data was rendered unintelligible to unauthorised parties, for example strongly encrypted with keys that were not compromised. You may still need to notify the supervisory authority within 72 hours, so document the incident and your assessment.

Is storing client documents on Google Drive or Dropbox a GDPR problem? Not automatically, but you must have a data processing agreement, verify where the data is stored (Chapter V transfer rules), and understand that the provider holds the decryption keys. For high-sensitivity financial data, a model where the host cannot read the files is a stronger position.

How long must I keep client accounting documents, and does encryption change that? Retention periods are set by law, commonly ten years for commercial accounting records in France and six years for many tax documents. Encryption does not change how long you keep data; it protects the data during that long retention window. Verify the exact periods for your jurisdiction.

Is full-disk encryption like BitLocker enough? It helps but is not enough on its own. Full-disk encryption protects a powered-off stolen device. It does not protect a running machine, a synced copy on a shared drive, or files sent by email. File-level or client-side encryption addresses those gaps.