Why security, privacy and access controls matter in MTD

Making Tax Digital (MTD) transforms how VAT, income tax and other tax obligations are reported: businesses and agents submit digital records and returns using software that often integrates directly with Her Majesty’s Revenue and Customs (HMRC) APIs. That creates efficiency but also concentrates sensitive personal and business financial data in connected systems. Weak controls can lead to data breaches, inaccurate submissions, financial loss, reputational damage, regulatory fines and loss of client trust.

This guide explains in practical detail the legal and technical considerations relevant to accountants, agents, software providers and small businesses that operate in MTD environments. It covers legal requirements (GDPR and the UK Data Protection Act), HMRC-specific integration considerations, and practical controls across identity & access management, encryption, logging, incident response and third‑party risk.

Legal & regulatory framework

Two UK legal frameworks are central to handling tax data:

• Data Protection Act 2018 and UK GDPR — these govern lawful processing of personal data, including financial details of individuals and sole traders. Organisations must have a lawful basis for processing, implement appropriate technical and organisational measures, and uphold data subject rights.
• HMRC requirements for MTD and API access — HMRC publishes developer and security guidance, including authentication models (e.g. OAuth-based flows for APIs), client-authorisation processes for agents and technical terms for software suppliers. Always consult the latest HMRC developer documentation when integrating.

Key legal obligations to bear in mind:

• Lawful basis: Most MTD processing will rely on the lawful bases of “legal obligation” (where processing is required to meet tax law) or “contract” (to provide services to clients).
• Data minimisation and purpose limitation: Keep only the data needed for tax reporting and for as long as necessary.
• Records retention: HMRC has statutory record-keeping rules (commonly 6 years for VAT and other obligations); ensure records are retained securely for the required period.
• Breach notification: Under UK GDPR, notify the ICO within 72 hours when a personal data breach poses a likely risk to individual rights and freedoms. Clients and HMRC may also need informing depending on the scale and consequence of a breach.
• Data Processing Agreements (DPAs): Where you use third parties or act as a processor for clients, put in place DPAs that define security, liability, sub-processing and data return/erasure procedures.

Common threats and risks in MTD environments

Understanding typical threats helps prioritise controls:

• Credential compromise: stolen agent/software credentials or API keys enabling unauthorised submissions.
• Insider risk: employees or contractors accessing client records beyond their role.
• Software vulnerabilities: unpatched web apps, insecure dependencies or injection flaws that expose data.
• Misconfiguration: insecure cloud storage, misrouted backups or open S3 buckets leaking financial records.
• Man-in-the-middle attacks: if TLS is misconfigured, data in transit could be intercepted.
• Supply chain and third-party SaaS risk: vendors or plugins with poor security practices can introduce risk.

Practical controls: Identity, Authentication and Access Management (IAM)

Strong IAM is foundational. Design access so only authorised people and systems can access tax data and HMRC APIs.

Role-Based Access Control (RBAC) and least privilege

Define clear roles and permissions that reflect job responsibilities. Example roles for an accounting practice:

• Admin: manages users, billing and integration settings (very limited number of people).
• Partner / Senior Accountant: full access to client tax records and submission history.
• Accountant / Bookkeeper: create and edit records but restricted from critical admin actions.
• Viewer / Read-only: access to view records without editing rights.
• Service/API Account: machine identity used for integrations; has narrow scopes and rotation policies.

Multi-factor Authentication (MFA)

Require MFA (preferably app-based TOTP or hardware tokens) for all interactive accounts with access to client tax data or to administration portals. For agent portals and dashboards, MFA reduces risk of credential theft leading to unauthorised filings.

Session Management & Passwords

• Enforce strong passwords or use single sign-on (SSO) with providers that support secure SSO protocols (SAML, OIDC).
• Implement session timeouts, device recognition, and risk-based authentication for high-risk operations.
• Block reuse of compromised passwords via known breach lists (e.g. Have I Been Pwned integration).

OAuth, Tokens and API Credentials

When integrating with HMRC APIs and other services, follow secure token lifecycle practices:

• Use short-lived access tokens and securely store long-lived refresh tokens in encrypted stores (e.g. KMS-backed secrets management).
• Rotate client secrets and API keys regularly and immediately revoke credentials on suspected compromise.
• Limit token scopes to the minimum required operations and implement consent tracking so clients can view and revoke authorisations.

Segregation of duties

Separate roles that could allow fraudulent submission and approval by a single individual. For example, the person preparing a return should not be the sole person with authority to submit or to alter client bank details without review.

Privileged Access Management (PAM)

Protect highly privileged accounts (e.g., system administrators, platform owners) using PAM solutions and just-in-time (JIT) access to minimise standing privileges.

Technical security controls and secure architecture

Encryption in transit and at rest

• Ensure TLS 1.2+ (ideally TLS 1.3) for all communication between clients, software, and HMRC APIs. Enforce HSTS and strong cipher suites.
• Encrypt sensitive fields at rest using strong algorithms (e.g. AES‑256). If possible, encrypt per-client or per-tenant data with separate keys.
• Protect secrets with a proven secrets management solution (KMS or HSM-backed) — never store API secrets, client credentials or private keys in plain text or in code repositories.

Tenant isolation and multi‑tenancy

For multi-tenant accounting platforms, ensure logical or physical isolation between clients:

• Use strict row-level access controls or separate databases/instances by tenant to prevent accidental or malicious cross-tenant access.
• Implement access control enforcement at the application layer and at the database layer to avoid privilege escalation through bypassed APIs.

Secure software development lifecycle (SSDLC)

Embed security into the development lifecycle:

• Threat modelling for new features that process tax or identity data.
• Static Application Security Testing (SAST), Dependency Scanning and Dynamic Application Security Testing (DAST).
• Regular third-party penetration testing and remediation tracking.
• Secure coding guidelines and developer training on common issues (injection, XSS, broken authentication).

Configuration and infrastructure hardening

Harden servers, containers and cloud instances:

• Use minimal base images, disable unnecessary services and close unused ports.
• Apply timely OS and dependency patches; use automated patch management.
• Harden databases with encryption, role separation and network segmentation.

Monitoring, logging and audit trails

Comprehensive logging and monitoring are crucial in MTD contexts to detect anomalous access and to provide evidence during audits:

• Log authentication events, API requests (with non-sensitive details), administrative changes and data exports.
• Use a centralised log store and integrate with a SIEM to create alerts on suspicious behaviours (e.g., bulk downloads, unusual submission patterns, repeated failed auth attempts).
• Maintain tamper-evident audit trails of who accessed or changed records, with timestamps, IPs and justification where applicable.

Backups and continuity

Ensure secure, tested backups exist and are encrypted. Regularly test restore procedures to ensure you can recover client records and submissions in a timely fashion in the event of data loss.

Privacy, data protection and client rights

Beyond technical security, privacy practices ensure compliance with UK GDPR and maintain client trust.

Lawful basis and transparency

Document the lawful basis for processing client data (commonly “legal obligation” or “contract”). Maintain a privacy notice that explains:

• What data is collected and why
• How long data is retained (linked to HMRC retention rules)
• Who data is shared with (HMRC, payroll providers, third‑party apps)
• Rights available to data subjects and how to exercise them

Data minimisation and purpose limitation

Collect and retain only what is necessary for tax reporting, invoicing and statutory obligations. Avoid storing extraneous personal data unless justified and documented.

Data Protection Impact Assessments (DPIAs)

Where new technologies, large-scale processing or high-risk processing of personal data is planned, conduct a DPIA per ICO guidance. MTD integrations that centralise large volumes of financial data often merit a DPIA to identify risks and mitigation strategies.

Data subject rights

Implement procedures to respond to requests from data subjects (access, rectification, restriction, erasure, portability) within statutory timeframes. Some erasure requests may be limited where retention is required by tax law — have processes to communicate this clearly and act on requests accordingly.

Special category data and sensitive workflows

Financial data can sometimes interact with special category data (e.g., health-related benefits). Treat any such data with heightened protections and ensure a separate lawful basis is documented.

Third-party and supply chain risk

Many MTD environments use third-party cloud providers, payroll systems, apps or plugins. Manage third-party risk with:

• Due diligence and security questionnaires
• Contracts and Data Processing Agreements that specify security measures, audit rights and sub-processor lists
• Regular supplier performance reviews and periodic audits for critical vendors
• Limitations on overseas transfers and use of adequate transfer mechanisms (SCCs, UK Addendum, or equivalent)

Incident response and breach management

Have a tested incident response plan (IRP) tailored to MTD operations. Key elements:

• Clear roles and escalation paths (technical, legal, communications, client liaison)
• Procedures for containment, eradication, recovery and root cause analysis
• Pre-defined templates for ICO notifications and client communications
• For serious breaches: notify the ICO within 72 hours if likely to result in risk to individual rights and freedoms; inform affected clients without undue delay where required
• Consider also notifying HMRC or other authorities if submissions could be affected

Run tabletop exercises at least annually to ensure the practice can respond quickly to a breach affecting client tax records or HMRC submissions.

Record retention and disposal

Follow statutory retention requirements (commonly 6 years for business records relevant to VAT and many taxes). Retention policy must include secure disposal procedures:

• Secure deletion for digital files (cryptographic erasure where appropriate)
• Shredding or secure destruction for paper files
• Retention schedule aligned with HMRC rules and documented in privacy notices

Practical security checklist for MTD-ready practices and businesses

Use this checklist as an actionable starting point:

1. Register with HMRC Developer Hub and review the latest API/authentication guidance before integrating.
2. Conduct a DPIA for new MTD integrations or when centralising client financial data.
3. Implement RBAC and least privilege across all systems that hold tax data.
4. Require MFA for all accounts with tax-data access and restrict admin privileges.
5. Use secure secrets management and rotate API credentials regularly.
6. Encrypt data in transit (TLS 1.2+/1.3) and at rest (AES‑256 or equivalent).
7. Log and monitor access, with alerts for anomalous behaviour; retain audit logs according to policy.
8. Have a tested incident response plan and templates for ICO/client notifications.
9. Ensure DPAs with all processors and maintain sub-processor lists.
10. Perform regular penetration tests and code security scans.
11. Train staff on phishing, social engineering, and secure handling of client data.
12. Document retention and secure disposal processes aligned with HMRC requirements.

Implementation examples and configuration guidance

Below are pragmatic technical approaches that many accounting practices and vendors can implement quickly.

Secrets storage example (high level)

Do not store HMRC client secrets or client authentication tokens in plain text. Use a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault):

// Pseudocode concept
storeSecret("hmrc/client/{clientId}/refreshToken", encryptedValue, {rotation: "30d", accessPolicy: ["service-account-1"]});
allowAccess("service-account-1", ["read"], "hmrc/client/{clientId}/refreshToken");
          

Sample RBAC matrix (concept)

Map operations to roles — a simple example:

• Prepare return: Accountant, Partner
• Submit return to HMRC: Partner (or requires 2-person approval)
• Manage client authorisations: Admin, Partner
• View logs and exports: Admin, Security Analyst

Logging retention and GDPR balance

Keep security logs long enough to investigate incidents (commonly 90–365 days). For audit trails required by tax law, retain the relevant submission and record logs for the statutory period. Anonymise or pseudonymise logs that are not needed for forensic purposes to reduce GDPR risk.

Frequently asked questions (FAQ)

Do I need a DPIA for MTD?

Possibly. If your processing is likely to result in a high risk to the rights and freedoms of individuals — for example, you are centralising large volumes of sensitive financial information or using new technologies — perform a DPIA. When in doubt, document the assessment and consult your Data Protection Officer (DPO) or legal counsel.

Who is responsible if an agent’s account is used to submit fraudulent returns?

Responsibility can be shared. Agents are responsible for securing their credentials and systems. Clients should ensure they only authorise trusted agents. Contractual terms, DPAs and professional indemnity insurance will shape liability — seek legal advice and inform HMRC promptly if fraud occurs.

How often should I test backups and recovery?

At least annually for full restores; more frequent testing (quarterly) for critical environments is best practice. Validate both data integrity and restoration procedures.

Conclusion

MTD delivers efficiency and modernisation, but also concentrates sensitive financial data into digitally connected systems. Accountants, agents, and software providers must treat security, privacy and access controls as core elements of service design and operations. Follow principles of least privilege, strong authentication, encryption, monitoring and documented privacy practices to meet legal obligations and protect clients.

Tax Digital combines Making Tax Digital expertise with qualified accountancy and technical experience to help practices and businesses design secure MTD implementations. If you need a security review, DPIA support, or practical implementation help, get in touch below.