GDPR considerations for tax advisors

When this article is for you

You're a tax advisor and want to understand the GDPR framing of the three-way relationship (client + TaxItEasy + you). Specifically: who is responsible for what, where does YOUR DPA come from, what happens if there's a breach involving your access, and how to handle subject-rights requests cleanly.

This article is a practical primer, not a substitute for legal advice from your jurisdiction's professional body. For client-side GDPR rights, see your GDPR rights as a user. For TaxItEasy's overall data residency and processor stance, see where is my data stored and our sub-processors. For the read-only scope that limits your data access, see read-only scope.

The role triangle

Three parties, three roles under GDPR:

• Your client — the controller. They decide what personal data is collected and why. Every invoice in their TaxItEasy account is their data (about their suppliers, their customers, their team members where applicable, their own business). The controller's responsibilities are the central ones: legal basis for processing, transparency, response to subject-rights requests, breach notification to supervisory authorities.
• TaxItEasy — the processor. We process the data on the controller's behalf, strictly under their instructions, under our signed DPA with them. We do not decide what's collected or for what purpose; we provide the platform.
• You, the tax advisor — a sub-processor of the client. The legal basis for your access to the client's data is the engagement contract between you and the client (typically a Mandatsvertrag in DACH, a contrat d'engagement in France, a lettera d'incarico in Italy, etc.). TaxItEasy provides the technical access but doesn't establish the legal basis between you and the client.

In simpler language: your client owns their data, TaxItEasy stores + processes it under contract with the client, and you access it as the client's external accountant under contract with them. Three contracts, three roles, three responsibilities.

What this means in practice

A few concrete implications:

• Your DPA with TaxItEasy is not separate. You inherit access via the client's TaxItEasy account. There's no "advisor-side DPA with TaxItEasy" — your relationship to the data is through the client.
• Your DPA with the client matters most. Typically embedded in your engagement contract or as a separate annex. It governs what you do with their data — keep, store, copy, share with whom, for how long, for what purposes, and what happens at engagement end.
• A breach involving your access is your responsibility to report to the client. If your laptop is stolen with bulk-exports on it, or a colleague at your firm leaks something, you notify the client. The client then assesses their notification obligations (their supervisory authority within 72 hours if the breach meets the threshold of Article 33).
• Subject-rights requests (Articles 15–21) go to the client, not you. When a data subject (e.g. one of the client's customers whose name appears on an invoice) asks for access or erasure, they ask the client. The client routes the request to TaxItEasy's [email protected] via their controller channel. You don't field these requests yourself unless the engagement contract specifically delegates them.

Data minimisation — practical implications

GDPR's data-minimisation principle (Article 5(1)(c)) applies to your work. TaxItEasy's read-only scope already limits you a lot — no inbox, no billing details, no team-member personal data beyond what's on invoices (see read-only scope).

On top of that, you apply minimisation in your own work:

• Don't keep client data in your own systems beyond what your engagement requires. Export for active period work, delete from your local storage when the period is closed and your retention obligations are met. Bulk-export ZIPs sitting in your Downloads folder for 2 years are a liability.
• Don't share client data with other advisors at your firm without authorisation from the client. Internal sharing for staff training (e.g. anonymous case study) is fine if the data is anonymised. Sharing identifiable data sideways needs the client's nod.
• Don't use client data for purposes outside the engagement. No benchmarking ("compare your tax burden to other clients in your sector"), no aggregated analytics unless contractually agreed, no marketing-list-building from invoice contact data.
• Take only what you need. If you only need Q1 data for a Q1 filing, don't export 5 years of history "just in case."

Retention — when an engagement ends

When a client revokes your access (or you part ways amicably):

• Immediately: your TaxItEasy view of their data stops. You can't open the client in your cockpit; they no longer appear in your client list.
• Any local copies you have — bulk-export ZIPs, screenshots, private notes you exported, downloaded original PDFs — are still in your possession. Your engagement contract should specify retention.
• Statutory retention is jurisdiction-specific. For German Steuerberater, the BoSO retention rules typically apply (~6 years for general records, 10 years for tax-relevant ones; specific deadlines depend on the type of document). For French comptables, the relevant rules are in the CGI; for Italian commercialisti, the obblighi di conservazione; etc. Consult your jurisdiction's professional body for the exact obligations.
• A clean handover to the next advisor should include: any local exports you made (with the client's permission), your private notes that have ongoing relevance, and a written summary of any matching rules + per-client thresholds you'd configured (so the new advisor can recreate them).

After your retention period expires, you delete your local copies. This is your responsibility, not TaxItEasy's; we have no visibility into your local file system.

Cross-border clients (within and outside the EU)

Most TaxItEasy clients are EU-based, with EU-based tax advisors. A few less-common scenarios:

• Client in one EU country, you in another EU country: Same GDPR (it's an EU regulation, not national law). No additional complexity from one EU member state to another. The processor-controller-sub-processor framing applies identically.
• Client in EU, you outside the EU (UK / CH / US): Your country's data-protection law applies to your local processing. UK GDPR (post-Brexit), Swiss DPA, US state-level laws if applicable. For data transfers from the EU to you, the engagement contract typically includes SCCs or equivalent. Your firm's compliance officer can advise on the specific clauses needed.
• Client outside EU, you in EU: Your client is the controller under their local law, but you (as a sub-processor in the EU) may have specific obligations under GDPR for any processing you do in the EU. Talk to your professional body.
• Both you and client outside the EU: GDPR may still apply if your client's data subjects include EU residents. For instance, if your US-based client invoices EU customers, those EU customers' personal data on the invoices brings GDPR into scope. Consult a privacy lawyer if this applies.

Breach scenarios

A few realistic breach scenarios specific to the advisor role:

Your firm laptop is stolen

If the laptop has bulk-export ZIPs of client data on it, that's a personal-data-breach event under Article 32. Steps:

1. Within 24 hours: assess what was on the laptop. If full-disk encryption was active + the device was off (or encryption-at-rest is real), the breach risk is low. If not, treat as full exposure.
2. Notify the client immediately (within hours, not days). The client decides whether to notify their supervisory authority + affected data subjects.
3. Internally: rotate any credentials that were on the laptop (TaxItEasy login, password manager). Revoke active sessions from your Settings → Account → Active sessions → Revoke all — you can do this from any device with the password.

Bulk-export sent to wrong recipient

You meant to email the export to a junior colleague at your firm, but auto-complete sent it to a client of a different firm. Personal-data-breach event. Notify your client, ask the unintended recipient to delete (in writing), document everything for the client's potential supervisory-authority notification.

Colleague accesses a client they shouldn't

Each tax advisor needs their own invite from the client. If a colleague accessed a client outside the scope of their work via your login, that's both a breach (unauthorised processing) AND a firm-internal access-control failure. Notify the client; investigate internally; consider whether the colleague's TaxItEasy access needs to be revoked.

TaxItEasy-side breach

If we notify you of a security incident affecting one of your clients, we'll provide the details (what data was exposed, when, mitigation steps). Your role: forward to the client, coordinate on their response. We notify the controller (client), not the sub-processor (you), directly — but the client typically asks you to handle the operational follow-up.

Tax-authority requests

A specific kind of "third party asks for data" event for advisors:

• Tax authority asks YOU for client data: standard work — your engagement contract + your jurisdiction's professional duty rules apply. TaxItEasy's role doesn't change anything; you're the one being asked, not us. Provide what's lawfully required, no more.
• Tax authority asks TaxItEasy for client data: rare, but possible. Our DPA with the client says we comply with lawfully-binding orders. We notify the client (the controller) where legally permissible before responding. The order would route through our DPO at [email protected].

Edge cases

"Client asks me for a copy of their TaxItEasy data." Two ways: they self-export from their Settings → Account → Export my data, or you generate a bulk export for them. Either satisfies their Article 20 (portability) right. The self-export is faster and doesn't involve you.

"I need to share an invoice with another professional (lawyer, auditor)." Get written authorisation from the client first. The sharing happens off-platform — download the document, send via your normal secure channels (encrypted email, secure file-share). TaxItEasy doesn't have a built-in "share with third party" for the advisor role; not adding it is intentional (forces the explicit-authorisation step).

"Client has died or company has dissolved — what about their data?" Talk to the estate / liquidator. The TaxItEasy account is theirs (or their estate's) to close. We respond to dissolution-of-business requests via [email protected] with appropriate verification (death certificate / dissolution paperwork / probate authority). Your role: provide whatever the engagement-contract retention rules require, then close your local copies per your retention schedule.

"Authority requests data about a client (tax authority subpoena to me)." Same as any client-related authority request. Your engagement contract + your jurisdiction's professional duty rules apply. Inform the client where legally permitted (some subpoenas come with gag orders; some don't). TaxItEasy's role doesn't change anything — you're the one being asked.

"I want a copy of TaxItEasy's DPA." Available on request to [email protected] or via /dpa.html. Note: the client signs the DPA with TaxItEasy, not you. You can still review it for context.

"My firm has multiple advisors handling one client — does each need an invite?" Yes. One invite per advisor per client. The audit log attributes actions to individual advisors; sharing one login conflates attribution and creates compliance ambiguity ("who actually approved this invoice?").

"Client revoked my access in the middle of a flagged invoice — what happens?" Your access ends; the flag stays in the audit log. The next-assigned advisor (or the client themselves) sees the flag and decides how to proceed. Your contribution is preserved as historical record.

"Anonymised aggregate data for staff training — OK?" Generally OK if true anonymisation (not pseudonymisation). Test: would a reasonable person be able to re-identify the client or their suppliers from the data? If no, you're fine. If yes (e.g. small market, recognisable vendor name), you need pseudonymisation + client consent.

"Cross-firm referral with another advisor — share data?" Get explicit client consent. The other advisor needs their own invite from the client; you don't proxy the data to them.

Related

• Read-only scope — what I can and cannot see — the data-access boundary
• Our sub-processors at a glance — TaxItEasy's processor chain
• Where is my data stored? — EU residency + encryption context
• Your GDPR rights as a user — the controller-side view of the same triangle