How European Accounting Firms Can Protect Client Financial Data During Cross-Border Engagements
When European accounting firms conduct cross-border audits, every financial document flows through infrastructure that either satisfies professional secrecy obligations or creates criminal liability. Germany’s §203 StGB carries prison sentences. France’s secret professionnel carries imprisonment and €15,000 fines. Switzerland’s Article 321 extends beyond borders for international clients. These aren’t abstract legal risks—they attach directly to the technology choices firms make for storing and transmitting client data.
The structural problem is that professional secrecy frameworks were designed before cloud computing created foreign government access pathways. When a German auditing firm stores client working papers on a US-headquartered platform, US authorities can compel that provider to produce data without involving any European court, without notifying the firm, and without overriding anything in the firm’s engagement letter. This guide examines what compliant architecture looks like for cross-border accounting engagements, and why customer-managed encryption is the technical foundation that satisfies professional secrecy, GDPR, and DORA simultaneously.
Executive Summary
Main Idea: European accounting firms operate under criminal penalties for unauthorized client data disclosure, yet most store client financial data on US-headquartered platforms that create foreign government access pathways outside European legal frameworks—and unlike lawyers, accountants cannot rely on legal privilege to close that gap. The ECJ has ruled accountants receive weaker protections than lawyers, making sovereign architecture the only reliable mechanism for satisfying professional secrecy obligations.
Why You Should Care: Three Big Four firms were hit in the 2023 MOVEit breach, the UK’s Financial Reporting Council reported 127 enforcement cases in 2024 with technology failures representing a growing category of professional misconduct findings, and DORA now flows technology requirements directly from financial institution clients to the accounting firms they engage. Firms that cannot demonstrate sovereign architecture face both increasing enforcement exposure and systematic exclusion from regulated industry mandates.
5 Key Takeaways
- Professional secrecy carries criminal penalties across Europe, and technology choices directly affect compliance. Germany’s §203 StGB, France’s secret professionnel, Switzerland’s Article 321, Netherlands’ Article 272, and UK common law duties all impose obligations extending to cloud platforms. These aren’t IT decisions but professional responsibility questions affecting licensing and prosecution risk.
- Accountants lack lawyers’ privilege protections, requiring stronger sovereign architecture. The ECJ ruled accountants receive weaker safeguards than lawyers. While lawyers gained CCBE cloud guidance and 2025 treaty protections, accountants must rely on technical controls rather than legal privilege to prevent compelled disclosure—making architecture the primary defense rather than a supplement to legal protection.
- DORA mandates flow from financial institutions to their accounting service providers. Article 30 requires contracts addressing data sovereignty, encryption key management, and exit strategies. When banks engage accounting firms, these technology obligations extend to the platforms accountants use for client data—making vendor architecture a direct regulatory matter for accounting firms serving financial sector clients.
- Cross-border engagements create compliance gaps when client data crosses jurisdictions. A German firm auditing a French subsidiary of a Swiss parent processes data under three secrecy regimes, while CLOUD Act authority enables US access regardless of storage location. Standard Contractual Clauses cannot override sovereign legal authority—only technical architecture can.
- Major accounting firms face persistent threats despite substantial security investments. Three Big Four firms were hit by MOVEit. Sax LLP’s breach went undetected for 16 months. Deloitte paid $5 million after four months of undetected access. Professional liability insurers now scrutinize technology architecture and require sovereign deployment options, with some policies including exclusions for breaches where providers maintain encryption key control.
Professional Secrecy Obligations European Accountants Cannot Delegate
Professional secrecy for accountants carries criminal penalties across Europe, but these frameworks predate cloud computing’s foreign government access pathways. The result is a structural tension: obligations designed for a world of paper files now apply to infrastructure where the firm may not be the only entity with technical access to client data.
Germany’s §203 StGB and §43 WPO Create Criminal Liability That Extends to Technology Platform Choices
Germany’s §43 WPO establishes auditor secrecy as a professional obligation, while §203 StGB makes unauthorized disclosure a crime carrying prison sentences for the responsible individuals. Over 15,000 professionals hold these obligations. The Institut der Wirtschaftsprüfer has been explicit that §43 WPO professional secrecy extends to all technology systems, and that auditors cannot satisfy their obligations through platforms where providers hold decryption keys. When firms store client data on US-controlled infrastructure, they create disclosure pathways outside German legal control—pathways that exist independently of any contractual prohibition on unauthorized access.
France, Switzerland, and the Netherlands Each Impose Equivalent Criminal Secrecy Obligations on Accountants
France’s Article L. 822-15 Code de Commerce subjects commissaires aux comptes to secret professionnel, with Article 226-13 Criminal Code violations carrying imprisonment and €15,000 fines. CNIL guidance emphasizes accountants remain responsible for client data protection even when using third-party providers—the outsourcing relationship does not transfer the obligation. Switzerland’s Article 321 Criminal Code protects auditor and tax advisor secrecy extending beyond Swiss borders for international clients. The Netherlands’ Article 272 Criminal Code establishes NBA-registered accountant secrecy, with the Dutch DPA emphasizing professional secrecy extends to digital systems and cloud infrastructure.
The ECJ Ruling That Accountants Receive Weaker Protections Than Lawyers Makes Technical Architecture the Primary Defense
UK accounting operates under common law confidentiality duties reinforced by FRC and ICAEW standards. While lacking continental criminal statutes, breach creates civil liability, professional misconduct findings, and potential prosecution under Computer Misuse Act 1990 or Data Protection Act 2018—with the FRC’s 2024 report identifying 127 enforcement cases and technology failures representing an increasing category of misconduct findings. Critically, the ECJ’s Ordre des barreaux francophones ruling clarified that accountants receive less stringent legal protections than lawyers. This means firms cannot rely on legal privilege claims to resist compelled disclosure and must instead implement technical architecture that makes unauthorized infrastructure-level access impossible—customer-managed encryption where providers cannot technically access client data without firm cooperation.
A Complete Checklist of GDPR Compliance
GDPR and DORA Technology Requirements for Accounting Firms
GDPR establishes baseline security requirements, while DORA extends these with technology mandates that flow from financial institutions to accounting service providers. Together they create a compliance framework that contracts alone cannot satisfy.
GDPR Article 32 Requires Encryption That Provides Adequate Protection Only When the Controller Holds Exclusive Key Control
GDPR Article 32 requires “appropriate technical and organizational measures” including encryption, confidentiality, integrity, and availability. Article 5(1)(f)’s “integrity and confidentiality” principle requires protection against unauthorized processing—a requirement that conflicts with architectures where providers can access client data, since such systems cannot guarantee protection when providers face legal compulsion beyond the controller’s authority. The Article 29 Working Party guidance is explicit on this point: encryption provides adequate protection only when controllers maintain exclusive decryption key control. Provider-managed encryption satisfies the form of the requirement but not its substance.
Schrems II Established That SCCs Alone Cannot Satisfy Transfer Requirements When Third-Country Governments Can Access Data
Schrems II established that SCCs alone don’t provide adequate protection when data flows to jurisdictions with government surveillance lacking European-equivalent safeguards. The ECJ addressed situations where third-country obligations allow public authority access exceeding what’s necessary and proportionate—precisely the situation that applies to US-headquartered cloud providers subject to the CLOUD Act. The EDPB’s guidance requires controllers to assess whether third-country law or practice impinges on safeguard effectiveness, and to implement supplementary technical measures when it does. For accounting firms, this means SCCs must accompany customer-managed encryption rather than stand independently.
DORA Article 30 Flows Technology Obligations Directly From Financial Institution Clients to the Accounting Firms They Engage
DORA Article 28(5) requires financial entities to assess ICT third-party providers, while Article 30 mandates contracts ensuring security measures including data protection and encryption. When financial institutions engage accounting firms, these obligations extend to the platforms accountants use. Article 30(2)(j) requires addressing data processing location, while Article 30(2)(k) mandates provisions on data access, recovery, return, and deletion. Contracts stating EU data center storage don’t satisfy these obligations if operators maintain technical access from non-EU locations subject to foreign government authority. Article 28(3) requires exit strategies enabling complete data removal—mandating architectures that prevent vendor lock-in and allow migration without provider cooperation.
Cross-Border Engagements Amplify Data Sovereignty Risks
Cross-border audits create situations where client data subject to multiple professional secrecy regimes flows through infrastructure subject to entirely different sovereign authority. The compliance gap isn’t theoretical—it’s structural, and it widens with every jurisdiction an engagement spans.
Multi-Jurisdiction Engagements Subject Client Working Papers to Overlapping Secrecy Regimes Simultaneously
A German firm auditing a French subsidiary of a Swiss parent with Dutch operations generates working papers subject to German §43 WPO, French Code de Commerce, Swiss Article 321, and potentially Dutch professional secrecy. Each jurisdiction establishes authorized access the firm must enforce through technical architecture—not through engagement letter provisions, not through data processing agreements, but through controls that make unauthorized access technically impossible regardless of what orders arrive from which government.
The CLOUD Act Enables US Government Access to European Client Data Regardless of Where It Is Physically Stored
When firms store working papers on US-headquartered platforms, CLOUD Act authority enables US government agencies to compel disclosure regardless of physical data location. The Act applies to US persons and entities even if “not physically located in the United States.” Even with EU data centers and contracts specifying European storage, operators may face US orders overriding those provisions. The conflict isn’t theoretical—United States v. Microsoft addressed US government warrants seeking Irish-stored email before CLOUD Act passage, and the underlying principle persists: European data controlled by US companies becomes subject to US legal process regardless of physical location. National security letters and FISA orders prohibit disclosure to the subject and cannot be challenged through European legal processes.
Geolocation Controls Address Physical Data Location but Not Legal or Technical Data Control
Geolocation controls specify physical data location but don’t affect provider legal obligations or technical access capabilities. Physical server location differs fundamentally from legal and technical data control—only the latter determines sovereignty. The EDPB’s Schrems II guidance is explicit: controllers cannot rely on SCCs alone when technical measures cannot ensure protection against government access. Standard Contractual Clauses provide contractual obligations between parties, but they cannot override sovereign authority that operates unilaterally through the provider’s home jurisdiction. Customer-managed encryption with exclusive firm key control is the only mechanism that eliminates provider technical access regardless of which government issues orders, because it makes the provider technically incapable of compliance rather than legally prohibited from it.
Breach Incidents Demonstrate Third-Party Infrastructure Risks
Recent breaches at major accounting firms demonstrate that sophisticated cybersecurity programs do not eliminate the risks created by third-party infrastructure where providers maintain technical data access.
The MOVEit Breach and Subsequent Incidents Show That Even Big Four Security Investments Cannot Eliminate Third-Party Exposure
The 2023 MOVEit vulnerability affected three Big Four firms, exposing M&A client data through SQL injection in widely deployed file transfer software. This occurred despite sophisticated cybersecurity programs with substantial dedicated budgets. Sax LLP disclosed in late 2025 that a 2024 breach compromised 228,000 individuals’ information and remained undetected for 16 months. Deloitte paid Rhode Island $5 million for a breach where attackers accessed systems for four months despite hundreds of firewall alerts. If major firms face persistent threats on third-party infrastructure, smaller firms face proportionally greater risks with fewer resources to detect and respond.
Professional Liability Insurers and Regulators Are Now Scrutinizing Technology Architecture as a Compliance Matter
Professional liability insurers have responded to the breach pattern by increasing technology architecture scrutiny. Several carriers now require sovereign deployment options for cross-border engagements. Some policies include exclusions for breaches where providers maintain administrative access or encryption key control—treating provider key access as a known, manageable risk that firms have elected not to mitigate. The UK’s FRC now includes technology control failures as a specific enforcement category. Germany’s Wirtschaftsprüferkammer has emphasized that auditors’ §43 WPO obligations extend to technology choices and that firms cannot delegate these obligations to providers. When client data resides where providers maintain technical access, that access creates unauthorized disclosure pathways through both compromise and government compulsion—and the only architecture eliminating both risks is one where client data remains encrypted under keys controlled exclusively by the accounting firm.
Customer-Managed Encryption Architecture Satisfies Professional Secrecy
The technical architecture that satisfies professional secrecy obligations, GDPR requirements, and DORA mandates simultaneously centers on one principle: client data remains encrypted under keys controlled exclusively by the accounting firm. Everything else flows from that.
Firm-Controlled HSMs Ensure Providers Are Technically Incapable of Accessing Client Data Under Any Circumstances
Customer-managed encryption begins with key generation and storage under firm exclusive control. Keys generate within hardware security modules (HSMs) providing tamper-resistant protection that remains physically under firm control or deployed through European providers designed for key sovereignty. When client data enters through secure email, file sharing, or managed file transfer, it is immediately encrypted using firm HSM keys. Encrypted data can then reside on various infrastructure because providers cannot decrypt it—even if they face government orders or experience security incidents, client data remains protected. This directly addresses the structural problem that the ECJ’s ruling creates for accountants: legal privilege cannot substitute for technical architecture, but technical architecture that makes access impossible achieves the same practical result.
The Architecture Satisfies GDPR Article 32, DORA Article 30, and National Professional Secrecy Laws Through a Single Implementation
Customer-managed encryption satisfies the full compliance matrix simultaneously. It satisfies GDPR Article 32 encryption requirements while addressing Article 29 Working Party guidance that encryption provides adequate protection only when controllers maintain exclusive decryption key control. It addresses DORA requirements by ensuring only the firm accesses plaintext information—satisfying the technical architecture obligations that financial institution clients are contractually required to flow down to their service providers. It satisfies professional secrecy obligations across Germany, France, Switzerland, the Netherlands, and the UK by eliminating unauthorized disclosure pathways at the cryptographic level rather than relying on contractual prohibitions that cannot bind foreign governments.
Deployment Flexibility Lets Firms Match Sovereign Architecture to Their Operational Scale and Client Requirements
Deployment flexibility balances data sovereignty with operational needs. Complete on-premises deployment provides maximum control for firms handling the most sensitive mandates. Private cloud or hardened virtual appliances in European data centers provide equivalent sovereignty while reducing infrastructure management burden for firms that need the architecture without dedicated on-premises expertise. For cross-border engagements, data remains encrypted under firm keys throughout its lifecycle—access controls determine which individuals can decrypt specific documents, but encryption key control remains with the firm regardless of where engaged team members are located.
Implementation Considerations
Transitioning to sovereign architecture requires planning around technical migration, workflow integration, and regulatory documentation—but the sequencing matters as much as the technical decisions.
Mapping Current Data Flows Determines Which Systems Require Sovereign Architecture and Which Do Not
Technical assessment begins by mapping current data flows. Identify which flows involve client information subject to professional secrecy versus internal business data potentially allowing less stringent controls. Not all firm data requires customer-managed encryption—but all client financial data, engagement working papers, and communications containing confidential client information does. This scoping exercise determines the deployment scale and key management architecture required, and prevents the common mistake of applying sovereign architecture uniformly to all data flows rather than precisely to those that professional secrecy and GDPR require it for.
Key Management Architecture Is the Most Critical Decision and Should Match Each Jurisdiction’s Regulatory Expectations
Key management architecture represents the most critical implementation decision. Determine whether to use on-premises HSMs, cloud-based HSM services from European providers, or hardened virtual appliances. Larger firms often prefer on-premises HSMs for maximum control and because DORA-regulated financial institution clients may contractually require it. Smaller firms may prefer European HSM services with reduced operational complexity. The critical requirement across all options: keys remain under firm exclusive control and never become accessible to platform providers under any circumstances—including emergency support access, backup processes, or government orders directed at the provider.
Regulatory Documentation Should Demonstrate Architecture Compliance Proactively Rather Than Reactively
Regulatory documentation should demonstrate how technical architecture satisfies GDPR Article 32, DORA mandates, and national professional secrecy obligations. Include technical architecture diagrams, key management procedures, access control policies, incident response procedures, and contractual provisions confirming providers cannot access client data. Sophisticated clients—particularly financial institutions subject to DORA—increasingly request detailed technical appendices describing security architecture before engagement begins. Firms that can produce this documentation proactively gain competitive advantages in regulated industry mandates; firms that must assemble it reactively in response to client questionnaires face a harder sell.
Kiteworks Enables European Accounting Firms to Satisfy Professional Secrecy Through Sovereign Architecture
European accounting firms face a compliance requirement that contracts cannot satisfy and legal privilege cannot cover: professional secrecy obligations that extend to technology choices, combined with GDPR and DORA requirements that demand technical controls rather than contractual commitments. Customer-managed encryption is the architecture that closes this gap—ensuring providers are technically incapable of accessing client data regardless of what any government demands, and creating the documentary evidence trail that regulators, professional oversight bodies, and DORA-regulated clients increasingly require before engagement begins.
Kiteworks provides customer-managed encryption architecture enabling European accounting firms to satisfy professional secrecy obligations across Germany, France, Switzerland, the Netherlands, and the UK while meeting GDPR Article 32 and DORA technology mandates. The platform uses customer-controlled encryption keys that never leave firm infrastructure, meaning client financial data remains protected even if Kiteworks receives government orders or faces security incidents—we possess no technical means to access customer data.
Flexible deployment options include on-premises installation in firm data centers, private cloud deployment in European facilities under firm control, or hardened virtual appliances providing sovereign architecture benefits while reducing infrastructure management complexity. Firms can deploy in Germany to satisfy BfDI guidance, in France to meet CNIL requirements, in Switzerland for banking secrecy compliance, or in other European locations matching operational needs and client expectations.
The platform integrates secure email, file sharing, managed file transfer, and web forms into unified architecture, allowing accounting firms to manage all client data transmission through a single sovereign platform. This simplifies key management, reduces attack surface by eliminating multiple vendor relationships, and provides unified audit logging satisfying FRC, Wirtschaftsprüferkammer, and comparable oversight bodies.
To learn more, schedule a custom demo today.
Frequently Asked Questions
Hyperscale providers manage encryption keys themselves, maintaining technical capability to decrypt customer data when presented with government orders. Customer-managed encryption differs: accounting firms generate, control, and store encryption keys exclusively using hardware security modules that never expose key material to providers. This directly affects compliance because Germany’s §203 StGB, France’s secret professionnel, and Switzerland’s Article 321 require preventing technical capabilities for unauthorized access, not merely contractual prohibitions. When a provider manages keys, a government order directed at that provider produces readable client data. When the firm manages its encryption keys, the same order produces only ciphertext—technically satisfying the professional secrecy obligation that the legal privilege framework cannot provide.
Engagement letters should specify: deployment location (on-premises or specific European data centers), encryption methodology with explicit customer-managed key control confirmation, access restrictions specifying which personnel can access client data, data retention and secure deletion procedures, and incident notification obligations. For DORA-regulated financial institutions, reference specific Article 30 provisions satisfied. Include representations that architecture provides supplementary measures beyond standard contractual clauses as required by Schrems II. Sophisticated clients increasingly request detailed technical appendices describing security architecture—firms that have sovereign architecture already deployed can produce these proactively rather than assembling them under client pressure.
Establish sovereign architecture for client-facing communications while continuing existing platforms for internal communications during the transition. Deploy sovereign platforms for client communications, audit working papers, and financial materials first. Configure email routing to send client messages through sovereign platforms automatically. Implement policies requiring client documents use sovereign platforms. Migrate in phases: start with new engagements, transition active engagements at convenient points, then address historical data—ensuring that from the transition date forward, all new client data flows through infrastructure with exclusive firm encryption key control, which is where the professional secrecy obligation is most acute.
When customer-managed encryption is properly implemented, this scenario becomes technically impossible because providers cannot access plaintext data. However, if firms use platforms where providers manage keys, professional secrecy obligations continue regardless—creating criminal liability under Germany’s §203 StGB, France’s Article 226-13, or Switzerland’s Article 321 for the unauthorized disclosure that results. Firms in this situation should immediately consult legal counsel, notify affected clients where legally permissible, and treat the incident as grounds for urgent sovereign architecture migration. Professional liability insurers increasingly exclude coverage for provider disclosures where firms used platforms allowing provider access, treating it as a known risk the firm elected not to mitigate.
Standard contractual clauses establish contractual obligations between parties but cannot override sovereign legal authority or prevent government-compelled disclosure. The EDPB’s Schrems II guidance emphasizes SCCs alone don’t provide adequate protection when third-country laws allow public authority access exceeding necessary and proportionate levels. The recommended supplementary measures center on technical safeguards making data unintelligible to anyone without decryption keys—with encryption under customer-managed keys as the primary example the EDPB identifies as effective. SCCs should accompany customer-managed encryption rather than stand independently: the contract addresses what the parties have agreed, while the encryption architecture addresses what no contract can prevent—legally compelled disclosure to a foreign sovereign.
Additional Resources