GDPR for Accounting Software Providers: Client Financial Data, Multi-Tenancy, and Audit Trail Requirements
Accounting SaaS is one of the highest-risk categories under GDPR. Your platform processes financial data for hundreds or thousands of businesses — and by extension, their employees, customers, and suppliers. You hold bank details, salary records, tax filings, and invoices. You integrate with banks, HMRC, payroll bureaus, and third-party platforms. And you do all of this in a multi-tenant architecture where the same codebase, database cluster, and cloud region handles dozens of client organisations simultaneously.
This is not a low-risk SaaS operation. The ICO has investigated accounting software providers. Regulators across the EU have levied fines for inadequate data processor controls. And as open banking integrations deepen, the volume of personal financial data flowing through accounting platforms is growing fast.
This guide covers the GDPR framework that applies specifically to accounting software providers — not to accountants using your software, but to you, the SaaS company building and operating it.
Data Controller vs Data Processor: Getting the Distinction Right
The single most important question for any accounting software provider is: are you a data controller or a data processor?
The answer is almost always: both, for different processing activities.
As a data processor, you process client data strictly on behalf of your subscribers (the accounting firms or businesses). When Acme Ltd uploads its supplier invoices into your platform, Acme Ltd is the controller. They decided to collect that data, determined the purpose, and instructed you (implicitly or explicitly) to store and process it. You are their data processor.
As a data controller, you make independent decisions about personal data. Your own user accounts (the accountants logging into your platform), your marketing database, your product analytics — all of these involve you making decisions about purpose and means of processing. You are the controller for this data.
This distinction matters enormously in practice. For data you process as a processor, you need:
- A written Data Processing Agreement (DPA) with every subscriber
- The ability to act only on documented instructions from the controller
- Sub-processor notification requirements when you use third parties
For data you control, you need your own lawful basis, your own privacy notice, and your own compliance posture.
Many accounting software providers have inadequate DPAs — generic terms buried in the subscription agreement, with no specificity about the nature of processing, data subjects, or sub-processors. This is a direct compliance gap.
What Financial Data Counts as Personal Data Under GDPR
GDPR applies to personal data — information relating to an identified or identifiable natural person. In accounting software, this includes more than you might expect:
Clearly personal data:
- Employee names, addresses, National Insurance numbers, salaries, bank account details (payroll data)
- Sole trader details (their personal finances are indistinguishable from business finances)
- Individual supplier or customer contact information — names, emails, phone numbers on invoices
- Director and officer information in company accounts
Often overlooked personal data:
- IP addresses and session tokens in your audit logs
- Bank account sort codes and account numbers where the account holder is an individual
- Transaction descriptions that reveal personal information (rent payments, medical expenses, charitable donations)
- Communication metadata between accountants and clients within your platform
Special category data that may appear:
- Trade union subscriptions visible in payroll deductions
- Medical-related expenses or sick pay records
- Religious organisation payments identifiable from transaction data
The presence of special category data (Article 9 GDPR) requires explicit consent or another specific legal basis, and typically requires higher security measures. Accounting platforms processing payroll data should specifically assess whether they process any Article 9 data and document the legal basis.
Multi-Tenancy Architecture and Data Segregation Obligations
Multi-tenant SaaS creates specific GDPR obligations that single-tenant deployments avoid. When Firm A and Firm B both use your platform, a data breach affecting your shared infrastructure could expose both clients' data simultaneously. This is a material concern for regulators.
Database-level segregation: You should be able to demonstrate that each tenant's data is logically or physically isolated. This means either separate database schemas per tenant, row-level security with enforced tenant IDs, or separate database instances for higher-tier clients. If your architecture uses a flat database with shared tables and tenant IDs as the only segregation, you need robust access controls and regular penetration testing to validate that those controls work.
Application-level segregation: Every API call and database query should be tenant-scoped. A missing tenant filter in a query returning financial records is a personal data breach under GDPR Article 4(12) — not just a bug. Implement systematic controls: middleware that enforces tenant context, automated testing that verifies cross-tenant data cannot be accessed, and code review practices focused on multi-tenancy boundaries.
Backup and disaster recovery segregation: Backups are often where multi-tenancy breaks down. If your backup strategy produces a full-database dump, a restore would require exposing all tenants' data to restore one. Can you perform a per-tenant restore? Can you delete one tenant's data from backups without affecting others? GDPR's right to erasure requires you to be able to answer yes.
Breach notification implications: Under GDPR Article 33, a breach must be reported to the supervisory authority within 72 hours. In a multi-tenant architecture, a single breach may require you to notify your own DPA and support each affected tenant controller in notifying their own DPA. The notification burden scales with the number of affected tenants.
Accountant Access to Client Data: Sub-Processor Chains
When an accounting firm subscribes to your platform and accesses their clients' financial data, a chain of data processing relationships is created. Understanding this chain is essential for compliance.
The typical chain:
- Business (data controller) → Accounting Firm (data processor to the business, data controller to you) → Your Platform (data processor to the firm)
Your sub-processors: You use third-party services to operate your platform — cloud infrastructure (AWS, Azure, GCP), support tools, payment processors, analytics platforms, security monitoring services. Each of these is a sub-processor when they process personal data on your behalf.
GDPR Article 28 requires that you:
- Only use sub-processors with your clients' prior authorisation (general or specific)
- Impose the same data protection obligations on sub-processors as those in your own DPA
- Notify your clients of any intended changes to sub-processors and give them the opportunity to object
Most SaaS companies use general authorisation — a list of approved sub-processors that subscribers agree to when signing up, with a commitment to notify before adding new ones. Maintain a public sub-processor list and send change notifications. This is both a legal requirement and a commercial differentiator for enterprise clients.
Bank Feed Integrations: Open Banking and GDPR
Open Banking integrations (via Plaid, TrueLayer, Yapily, or direct bank APIs) are one of the most complex GDPR areas for accounting software providers.
Consent-based access: Open Banking relies on the bank account holder's explicit consent to share transaction data with your platform. This consent is separate from your platform's own consent mechanisms. Ensure you have clear documentation of what consent was granted, when, and for what scope.
Data minimisation in practice: Bank feeds typically return more data than accounting software needs. Transaction amounts, dates, and descriptions are necessary. Geolocation metadata, merchant category codes, or account relationship data may not be. Configure your bank feed integrations to receive and retain only what is necessary for the stated accounting purpose.
Token storage: OAuth tokens that grant access to bank feeds are personal data in themselves — they represent an authorisation linked to an individual. These tokens must be stored securely (encrypted at rest), audited for access, and revoked when the account connection is terminated. Lingering tokens that retain access to financial data after a user has disconnected their account are a significant compliance and security risk.
Third-country transfers: Plaid is US-headquartered. TrueLayer operates from the UK and EU. Where your bank feed provider processes data outside the EEA, you need a valid transfer mechanism — Standard Contractual Clauses, an adequacy decision, or another Article 46 safeguard. Review your agreements with every Open Banking provider.
Payroll Modules: Salary Data and National Insurance Numbers
Payroll is the highest-risk module in any accounting platform. Salary data and National Insurance (or Social Security) numbers are deeply personal — they reveal income levels, employer relationships, and in some cases sensitive personal circumstances like statutory sick pay or maternity leave.
Lawfulness of processing: The legal basis for processing payroll data is typically Article 6(1)(c) — legal obligation (employers must operate PAYE) — combined with Article 9(2)(b) for special category data where applicable. Document this explicitly in your Records of Processing Activities (ROPA).
Access controls within tenants: Even within a single tenant, not all users should have access to payroll data. Your permission system should support payroll-specific roles. A bookkeeper who needs to reconcile bank statements does not need to see the payroll ledger. Implement and enforce granular access controls at the module level.
Data minimisation in exports: Payroll exports — to HMRC, to pension providers, to benefit platforms — should export only the data fields required by the recipient. Don't bundle full employee records when only name, NI number, and contribution amounts are needed.
Subject access requests in payroll context: Employees have the right to access personal data held about them under GDPR Article 15. This includes payroll records. Your platform needs a mechanism for the employer-subscriber to extract and provide individual employee data in response to a DSAR. This is often poorly supported in accounting SaaS — build it as a feature, not an afterthought.
Data Retention: HMRC's 6-Year Rule vs GDPR's Storage Limitation Principle
This is one of the most frequently misunderstood conflicts in accounting software GDPR compliance.
HMRC requires businesses to retain accounting records for at least six years from the end of the accounting period. Companies House may require longer for statutory accounts. PAYE records require retention for three years after the tax year they relate to, though most advisors recommend six years for employment records.
GDPR's storage limitation principle (Article 5(1)(e)) says personal data should not be kept longer than necessary for the purpose for which it was collected.
There is no conflict — if you handle it correctly.
The key is documentation. Retention of accounting records for tax and legal compliance purposes is legitimate under GDPR Article 6(1)(c) (legal obligation) and 6(1)(f) (legitimate interest where no specific legal obligation exists but there is a regulatory expectation). Document in your ROPA:
- What categories of data are retained
- For how long
- The legal basis for retention
- When and how data is deleted after the retention period expires
The most common mistake is indefinite retention — keeping data "just in case" with no defined deletion schedule. Your platform should have automated data lifecycle management: after the retention period, data should be deleted or anonymised, not just archived and forgotten.
Deletion conflicts with multi-tenancy: If a subscriber cancels, you need a contractual commitment and technical capability to delete their data within a defined period — typically 30-90 days. This deletion must extend to backups, replicas, and any sub-processor copies. Log the deletion with evidence, as subscribers may request proof.
Right to Erasure vs Accounting Record Obligations
Article 17 GDPR gives individuals the right to erasure. But Article 17(3)(b) creates an explicit exception: erasure does not apply where processing is necessary for compliance with a legal obligation.
For accounting software, this means:
- You cannot erase accounting records within the statutory retention period simply because an individual requests it
- You must communicate clearly why the erasure request is refused and on what legal basis
- Once the legal retention period expires, erasure obligations resume in full
Where it gets complicated: Not all data in an accounting system is within the legal retention exception. Personal data in your marketing database, in support ticket logs, in onboarding records, in user activity analytics — none of this falls under the accounting record retention exemption. Erasure requests for this data must be honoured.
Build your erasure workflow to distinguish between data categories: accounting records (refuse with explanation), user account data (erase promptly), marketing data (erase promptly), support communications (erase unless there is a specific legal hold).
Audit Trails as a Privacy Risk
Audit logs are good security practice and, in financial contexts, often mandatory. But audit trails are also personal data — they record who accessed what data, when, and sometimes what actions they took. This creates a compliance obligation of its own.
Audit logs must be proportionate: Log what is necessary for security monitoring and compliance, not everything. Logging every mouse click and keypress generates enormous volumes of behavioural data about your users with limited security value.
Audit log retention: Define and document a retention period for audit logs. Many platforms retain logs indefinitely as a default. 12 months is a reasonable starting point for most access logs; security incident logs may justify longer retention.
Audit log access controls: Your audit logs may be the most sensitive data in your system — they reveal the full activity history of every user. Access to audit logs should be restricted to authorised personnel and logged itself (meta-logging for security-critical access).
DSAR implications: A user who submits a DSAR is entitled to the personal data held about them in your system — which may include their own audit trail entries. Ensure your DSAR response process can extract and provide individual user audit data.
International Data Transfers in Cloud Accounting
Most accounting SaaS runs on AWS, Azure, or GCP. These platforms operate globally — and by default, data may transit or be processed in regions outside the EEA.
Establish your data residency position: Know where your data is stored and processed. AWS eu-west-1 (Ireland) and eu-central-1 (Frankfurt) are within the EEA. US-east-1 (Virginia) is not. Configure your infrastructure to use EEA regions as the primary processing location for EEA clients.
Sub-processor transfers: Even if your primary infrastructure is EEA-based, your sub-processors may transfer data internationally. Your support ticketing tool, your error monitoring platform, your CRM — check each sub-processor's data transfer position.
Standard Contractual Clauses: For transfers to non-EEA countries without an adequacy decision, SCCs are the standard mechanism. The 2021 SCCs (updated by the European Commission) should be in place with any relevant sub-processor. Audit your DPAs annually.
UK vs EU: Post-Brexit, the UK and EU have separate data transfer frameworks. EU-to-UK transfers are covered by the UK adequacy decision (currently in place). UK-to-EU is not a transfer requiring special measures under UK GDPR. But if you operate in both markets, document your position clearly.
Subject Access Requests That Span Multiple Clients
This is an operational complexity that catches accounting software providers unprepared. An individual — a contractor, an employee, a sole trader client — submits a DSAR to your platform. Their data may exist across multiple of your subscriber tenants.
The challenge: You are a data processor for each of those tenants. The obligation to respond to DSARs rests with the data controller — not with you. But the individual may not know which accounting firm holds their data, and may contact you directly.
Your obligations as processor: You should redirect DSARs to the relevant controller (the accounting firm or business). But you must also have a mechanism to search your platform for the requesting individual's data and support the controller in responding.
Cross-tenant search: Build a capability to search across your platform for all data relating to a named individual — not just within a single tenant. This is a technical requirement that must be designed in, not retrofitted.
Response timelines: Whether you handle the DSAR directly or route it to the controller, the 30-day clock for the controller to respond is not extended by the multi-tenant complexity. Plan for fast internal SLAs.
Security Requirements: Encryption, Access Controls, and Breach Notification
GDPR Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk. For accounting software processing financial data, the minimum expectations are high.
Encryption:
- Encryption in transit (TLS 1.2 minimum, TLS 1.3 preferred) for all data transmission
- Encryption at rest for all stored personal data, including backups
- Encryption key management: who controls the keys, rotation policy, key separation between tenants
Access controls:
- Principle of least privilege: internal staff access only the data needed for their role
- MFA for all internal access to production systems
- Just-in-time access for database access rather than standing permissions
- Regular access reviews (quarterly) to revoke unnecessary privileges
Breach notification:
- Internal detection and escalation process: how does a potential breach get identified and reach the DPO within hours, not days?
- 72-hour notification to your supervisory authority under Article 33
- Notification to affected subscriber controllers who must then assess notification to their own DPA and potentially to individuals
- Incident response playbook specifically for financial data breaches
10 Common GDPR Mistakes Accounting Software Companies Make
No DPA with subscribers. Using generic terms of service without a compliant Article 28 DPA is the most common gap.
Outdated sub-processor list. Adding new third-party tools without notifying subscribers or updating the sub-processor register.
No data retention automation. Retaining deleted accounts' data indefinitely in backups because there is no automated deletion process.
Inadequate tenant isolation testing. Testing functionality within a tenant but not cross-tenant boundary violations.
Bank feed tokens not revoked on disconnection. Active OAuth tokens remaining in storage after a user removes a bank connection.
Payroll access controls too broad. All users within a subscriber tenant having access to payroll data regardless of role.
DSAR process missing audit log data. Responding to DSARs from the main application database but failing to include the requesting user's entries in audit and access logs.
No transfer impact assessment for US sub-processors. Using US-headquartered support or analytics tools without documenting the transfer mechanism.
Right to erasure applied mechanically. Either refusing all erasure requests citing accounting records (incorrect — only record data is exempt) or deleting everything including records within the HMRC retention period (also incorrect).
No ROPA maintained. Records of Processing Activities (Article 30) are a legal requirement for most processors. Many accounting SaaS companies either have no ROPA or maintain one that bears no relationship to actual processing.
Get a Compliance Baseline in 60 Seconds
Before you tackle the frameworks above, start by understanding what your marketing site and application landing pages are actually doing with visitor data. Custodia's free website scanner identifies trackers, third-party connections, and missing consent mechanisms — the first layer of compliance that regulators and prospective enterprise clients will check.
Scan your website free at https://app.custodia-privacy.com/scan →
Last updated: March 2026
Top comments (0)