GDPR-compliant client communication for tax firms

Which client data is especially sensitive

Tax advisory work involves some of the most personal data a professional will ever handle. Annual income statements, payroll records, business profit and loss accounts, property valuations, divorce settlements affecting asset splits, details of health-related deductions — all of this passes through the communication channel between firm and client. Much of it can reveal information about third parties too: a business owner's figures may expose employees' salary levels; an estate plan touches on family relationships and health histories.

Under the GDPR, personal data relating to a natural person's financial affairs is regulated personal data. While it does not fall within the explicitly "special category" list of Article 9 (which covers health, biometric, or political data), financial data routinely co-travels with data that does — medical expense deductions, disability-related allowances, and similar items frequently appear in tax files. The practical upshot is that the bar for secure handling should be treated as high throughout.

GDPR duties in communication

Three provisions of the GDPR are directly relevant to how a tax firm chooses its communication tools.

• Data minimisation (Art. 5(1)(c)): Only personal data that is adequate, relevant, and limited to what is necessary for the stated purpose should be collected or processed. Applied to communication infrastructure, this means a firm should not be operating systems that accumulate client data beyond what each individual exchange requires.
• Data protection by design and by default (Art. 25): Controllers must implement technical and organisational measures that give effect to data protection principles from the outset — not as an afterthought. Choosing communication tools with built-in privacy properties (such as end-to-end encryption) is a concrete expression of this obligation.
• Security of processing (Art. 32): Appropriate technical and organisational measures must be in place to ensure a level of security appropriate to the risk — including, where appropriate, encryption and ongoing confidentiality of processing systems.

Beyond the GDPR, most jurisdictions layer additional professional secrecy obligations onto tax advisers. The specifics vary — in Germany, for instance, tax consultants (Steuerberater) are bound by statutory confidentiality (§ 57 StBerG) that has criminal-law teeth. The interaction between GDPR obligations and professional secrecy rules is not always straightforward, and firms should consult their data protection officer or seek advice tailored to their local rules rather than relying on general summaries.

Where email and portals fall short

Standard email, even with transport-layer security, is not end-to-end encrypted by default. Messages sit on mail servers — potentially at both sender and recipient — in a readable form accessible to the platform operator, to anyone who compromises the server, or to law enforcement with the appropriate order. Attachments are stored on those servers unless actively deleted, and deletion policies are rarely configured with GDPR minimisation in mind.

Client portals address some of these concerns by providing a defined perimeter and access control, but they create their own data surface. Documents uploaded to a portal are stored centrally on the portal provider's servers. That storage creates a concentration of sensitive records — a target that grows more valuable the more clients use it. Providers' own security practices, their sub-processor chains, and their data-centre locations (all relevant to GDPR compliance) must be carefully audited via data processing agreements.

There is also a subtle tension with data minimisation. Both email servers and portals accumulate historical data: sent items, uploaded documents, conversation logs. The default behaviour of these systems is to retain, not to discard. A firm that wants to operate consistently with the minimisation principle has to actively work against its tools' defaults — configuring retention limits, enforcing deletion schedules, monitoring for drift.

Data minimisation as architecture: storing nothing

The most robust expression of the data minimisation principle is a system that does not store personal data in the first place. This is not merely a configuration choice — it is an architectural one, and it changes the risk calculus fundamentally.

Peer-to-peer communication tools take this approach. In a genuine P2P setup, the exchange of data — messages, files, audio, video — happens directly between the two devices involved, without a server in the middle holding a copy. The signaling infrastructure needed to set up the connection handles only transient routing information, not the content of the communication. Once the session ends, there is nothing stored on a server to breach, to subpoena, or to leak.

COVANAN operates on this model. Conversations use WebRTC, meaning data travels directly between participants' browsers. Encryption keys are generated on-device and shared only via the URL fragment — a part of the URL that browsers do not send to servers, so the key never leaves the participants' devices. There is no server-side message history, no contact list, no record of who spoke to whom. A guest joins by following a link; no account creation is required on their side.

From a GDPR standpoint, a system with no central data store has a materially smaller attack surface. There is nothing to breach on the server side, because there is nothing on the server side to find. This directly supports the Article 25 obligation to implement data protection by design: the architecture itself enforces minimisation, rather than relying on operational discipline to undo accumulation after the fact. Signaling servers — which handle only the initial connection handshake, not message content — are hosted in Germany, which is relevant for firms with clients whose data must remain within the EU.

For firms evaluating whether a communication tool is consistent with their GDPR obligations, relevant questions include: Where is data stored, and for how long? Who has access to stored content? Is there a data processing agreement in place? Does the tool implement end-to-end encryption, and is the key management verifiable? A peer-to-peer tool that stores no content sidesteps several of these questions structurally, rather than answering them with contractual assurances that must then be monitored.

Practical implications for a firm's workflow

A nothing-stored approach is not a fit for every use case. Archiving requirements — for instance, the obligation to retain certain tax documents for statutory periods — still need to be met through appropriate document management systems. The point is not that firms should abandon all record-keeping, but that the real-time communication channel itself — the conversation in which advice is given, questions are answered, and figures are discussed — need not be a retention system. Keeping that channel storage-free, while maintaining document archives separately, is a reasonable division of function.

• Use a peer-to-peer encrypted channel for real-time conversations, consultations, and file transfers that do not require long-term retention.
• Maintain separate, access-controlled document management for records subject to statutory retention obligations.
• Review any communication tool against Art. 25 and Art. 32 before adoption, and ensure a data processing agreement is in place for any processor that does handle personal data.
• Consult your data protection officer or a specialist in your jurisdiction before drawing compliance conclusions — the interaction of GDPR rules with local professional secrecy law requires case-by-case assessment.