GDPR Article 32 TOMs Evidence with ISO, NIS2 and DORA

The email lands in the CISO’s inbox with the familiar weight of a deal that could change the company’s quarter.

A major enterprise prospect wants evidence of “GDPR Article 32 technical and organisational measures, mapped to ISO 27001:2022, NIS2 and DORA where applicable.” At the same time, legal has briefed the board on NIS2 management liability and DORA operational resilience expectations. The board’s instruction sounds simple: prove compliance, avoid duplicated work, and do not turn this into three separate projects.

The company has controls. MFA is enabled. Backups run. Developers review code. The privacy team maintains records of processing. The infrastructure team scans for vulnerabilities. Suppliers are reviewed during procurement. But when the prospect asks for evidence, the answer fragments.

The identity provider report is in one place. Backup logs are in another. The risk register has not been updated since the last product release. Supplier security evidence lives in procurement emails. Incident response tabletop notes exist, but no one can prove lessons learned were fed back into risk treatment. The board approved security spending, but the approval is not linked to an ICT risk or a documented control decision.

That is the real problem with GDPR Article 32 technical and organisational measures, commonly called TOMs. Most organisations do not fail because they have no controls. They fail because they cannot demonstrate that controls are risk-based, approved, implemented, monitored and improved.

GDPR accountability makes that expectation explicit. GDPR Article 5 requires personal data to be protected with appropriate security against unauthorised or unlawful processing and accidental loss, destruction or damage. Article 5(2) makes the controller responsible for demonstrating compliance. GDPR definitions also matter. Personal data is broad, processing covers nearly every operation on data, pseudonymisation is a recognised safeguard, and a personal data breach includes accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access.

An Article 32 evidence file therefore cannot be a folder of random screenshots. It has to be a living control system.

Clarysec’s approach is to turn GDPR Article 32 TOMs into a traceable evidence engine built on ISO/IEC 27001:2022 ISO/IEC 27001:2022, reinforced by ISO/IEC 27005:2022 risk management, and cross-referenced to NIS2 and DORA obligations where they apply. The goal is not paperwork for its own sake. The goal is to make the organisation audit-ready before a customer, auditor, regulator or board member asks the difficult question.

Why GDPR Article 32 TOMs fail in practice

Article 32 is often misunderstood as a list of security tools: encryption, backups, logging, access control and incident response. Those measures matter, but they are only defensible when they are appropriate to the risk and connected to the personal data lifecycle.

For a SaaS company processing customer employee data, “we use encryption” is not enough. An auditor may ask what data encryption protects, where encryption is required, how keys are managed, whether backups are encrypted, whether production data is masked in testing, who can bypass controls, and how exceptions are approved.

Clarysec’s enterprise Data Protection and Privacy Policy captures the operating principle:

“Implement technical and organizational measures (TOMs) that protect the Confidentiality, Integrity, and Availability of personal information (PII) throughout its lifecycle.”

Source: Data Protection and Privacy Policy, Objectives, policy clause 3.3. Data Protection and Privacy Policy

The phrase “throughout its lifecycle” is where many TOM programs become weak. Personal data may be protected in production but copied into analytics systems, logs, support exports, test environments, backups, vendor platforms and employee devices. Each location creates security and privacy risk.

GDPR Article 6 requires a lawful basis for processing, including consent, contract, legal obligation, vital interests, public task or legitimate interests. When data is reused for a further purpose, compatibility and safeguards such as encryption or pseudonymisation must be considered. For higher-risk data, the evidence burden increases. GDPR Article 9 places strict limits on special categories of personal data such as health data, biometric data used for identification and other sensitive information. Article 10 restricts criminal conviction and offence data.

For SMEs, Clarysec expresses risk treatment in practical language:

“Controls must be implemented to reduce identified risks, including encryption, anonymization, secure disposal, and access restrictions”

Source: Data Protection and Privacy Policy-sme, Risk Treatment and Exceptions, policy clause 7.2.1. Data Protection and Privacy Policy - SME

That is a strong TOMs baseline. To become audit-ready, each control must also be linked to a risk, owner, policy requirement, evidence item and review cadence.

ISO 27001:2022 is the backbone for Article 32 evidence

ISO 27001:2022 works well for GDPR Article 32 because it treats security as a management system, not a disconnected control checklist. It requires an information security management system, or ISMS, designed to preserve confidentiality, integrity and availability through risk management.

The first critical move is scope. ISO 27001:2022 clauses 4.1 to 4.4 require the organisation to understand internal and external issues, identify interested parties and requirements, determine which requirements will be addressed by the ISMS, and define the ISMS scope, including interfaces and dependencies with external organisations. For Article 32 TOMs, the ISMS scope should reflect personal data processing, customer obligations, processors, subprocessors, cloud platforms, remote work, support functions and product environments.

The second move is leadership. Clauses 5.1 to 5.3 require top management commitment, an information security policy, resources, roles and responsibilities, and performance reporting. This matters because GDPR Article 32, NIS2 and DORA all rely on governance. A control without ownership, funding or review is weak evidence.

Clarysec’s enterprise Information Security Policy makes this explicit:

“The ISMS shall include defined scope boundaries, a risk assessment methodology, measurable objectives, and documented controls justified in the Statement of Applicability (SoA).”

Source: Information Security Policy, Policy Implementation Requirements, policy clause 6.1.2. Information Security Policy

The same policy sets the evidence expectation:

“All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.”

Source: Information Security Policy, Policy Implementation Requirements, policy clause 6.6.1.

ISO 27001:2022 clauses 6.1.1 to 6.1.3 then require risk assessment, risk treatment, a Statement of Applicability, residual risk approval and risk owner accountability. Clause 6.2 requires measurable objectives. Clauses 7.5, 9.1, 9.2, 9.3 and 10.2 require documented information, monitoring, internal audit, management review and corrective action.

For GDPR Article 32, this creates a defensible structure.

ISO/IEC 27005:2022 strengthens this structure. It advises organisations to identify requirements from ISO 27001:2022 Annex A, regulations, contracts, sector standards, internal rules and existing controls, then feed them into risk assessment and treatment. It also requires risk criteria and acceptance criteria that consider legal, regulatory, operational, supplier, technology and human factors, including privacy.

Clarysec’s Risk Management Policy aligns directly:

“A formal risk management process shall be maintained in accordance with ISO/IEC 27005 and ISO 31000, covering risk identification, analysis, evaluation, treatment, monitoring, and communication.”

Source: Risk Management Policy, Governance Requirements, policy clause 5.1. Risk Management Policy

For SMEs, the same requirement becomes simple and actionable:

“Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.”

Source: Risk Management Policy-sme, Governance Requirements, policy clause 5.1.2. Risk Management Policy - SME

That sentence is a fast audit-readiness test. If a risk has no owner or treatment plan, it is not yet an evidence-ready risk.

The Clarysec bridge: risk, SoA, controls and regulations

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint treats compliance as traceability work. In the Risk Management phase, Step 13 focuses on risk treatment planning and the Statement of Applicability. It explains that organisations should map controls to risks, add Annex A control references to risk treatment entries, cross-reference external regulations, and obtain management approval.

The Zenith Blueprint is direct about the SoA’s role:

“The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.”

Source: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability (SoA). Zenith Blueprint

Step 14 of the Zenith Blueprint adds the regulatory cross-reference layer. It advises organisations to document how GDPR, NIS2 and DORA requirements are covered by policies and controls. For GDPR, it emphasises personal data protection in risk assessments and treatments, including encryption as a technical measure and breach response as part of the control environment. For NIS2, it highlights risk assessment, network security, access control, incident handling and business continuity. For DORA, it points to ICT risk management, incident response, reporting and ICT third-party oversight.

That is the core of the Clarysec method: one ISMS, one risk register, one SoA, one evidence library, multiple compliance outcomes.

Zenith Controls: The Cross-Compliance Guide Zenith Controls supports this by helping organisations use ISO/IEC 27002:2022 ISO/IEC 27002:2022 control topics as cross-compliance anchors. For GDPR Article 32, the most important anchors often include Privacy and Protection of PII, control 5.34; Independent Review of Information Security, control 5.35; and Use of Cryptography, control 8.24.

NIS2 turns TOMs into a board-level cybersecurity issue

Many organisations treat GDPR TOMs as a privacy team responsibility. NIS2 changes the conversation.

NIS2 applies to many medium and large entities in listed sectors, and in some cases regardless of size. Covered digital and technology sectors include cloud computing providers, data centre providers, content delivery networks, DNS service providers, TLD registries, trust service providers, public electronic communications providers, managed service providers, managed security service providers, online marketplaces, search engines and social networking platforms. Applicability for SaaS and technology SMEs depends on sector, size, Member State designation and systemic or cross-border impact.

NIS2 Article 20 places cybersecurity responsibility on management bodies. They must approve cybersecurity risk management measures, oversee implementation and undertake training. Essential entities can face administrative fines of at least EUR 10 million or at least 2 percent of worldwide annual turnover. Important entities can face fines of at least EUR 7 million or at least 1.4 percent.

NIS2 Article 21 is directly relevant to Article 32 TOMs because it requires appropriate and proportionate technical, operational and organisational measures. These measures must consider state of the art, European and international standards, cost, exposure, size, likelihood, severity and societal or economic impact. Required areas include risk analysis, security policies, incident handling, business continuity, supply chain security, secure acquisition and development, vulnerability handling, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, MFA or continuous authentication, and secure communications where appropriate.

NIS2 Article 23 adds staged incident reporting: early warning within 24 hours, incident notification within 72 hours, intermediate updates where requested, and a final report no later than one month after the 72-hour notification. If a personal data breach also qualifies as a NIS2 significant incident, your evidence file must support both privacy and cybersecurity reporting decisions.

DORA raises the bar for financial resilience and ICT providers

DORA applies from 17 January 2025 and creates a financial-sector rulebook for digital operational resilience. It covers ICT risk management, major ICT-related incident reporting, operational resilience testing, cyber threat and vulnerability information sharing, ICT third-party risk, contractual requirements for ICT providers, oversight of critical ICT third-party service providers, and supervision.

For financial entities also identified under national NIS2 rules, DORA operates as the sector-specific Union legal act for overlapping cybersecurity risk management and incident reporting duties. In practice, covered financial entities should prioritise DORA for those overlapping areas while maintaining coordination with NIS2 competent authorities and CSIRTs where relevant.

For GDPR Article 32 evidence, DORA matters in two ways. First, fintech firms may be directly in scope as financial entities, including credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers, trading venues and crowdfunding service providers. Second, SaaS, cloud, data, software and managed service providers may be treated by financial customers as ICT third-party service providers because DORA defines ICT services broadly.

DORA Article 5 requires governance and internal controls for ICT risk management, with the management body defining, approving, overseeing and remaining responsible for ICT risk arrangements. Article 6 requires a documented ICT risk management framework, including strategies, policies, procedures, ICT protocols and tools to protect information and ICT assets. Article 17 requires an ICT-related incident management process covering detection, management, notification, recording, root cause, early warning indicators, classification, roles, communications, escalation and response. Article 19 requires major ICT-related incidents to be reported to competent authorities.

DORA Articles 28 and 30 make ICT third-party risk a regulated control domain. Financial entities remain responsible for compliance when using ICT services. They need a third-party risk strategy, contractual registers, criticality assessments, due diligence, concentration risk review, audit and inspection rights, termination triggers, exit strategies and contractual provisions covering data locations, availability, authenticity, integrity, confidentiality, incident assistance, recovery, service levels and cooperation with authorities.

For Article 32, this means suppliers are part of the TOMs file. You cannot prove security of processing if critical processors, cloud platforms, analytics providers, support tools and ICT providers are not controlled.

A practical one-week Article 32 evidence build

A strong evidence file starts with one clear risk scenario.

Use this example: “Unauthorised access to customer personal data in the production application.”

Create or refresh the risk entry. Include description, likelihood, impact, score, owner and treatment plan. Assign the owner to the Head of Engineering, Security Manager or equivalent accountable role. Rate likelihood based on the access model, exposed attack surface, known vulnerabilities and prior incidents. Rate impact based on personal data volume, sensitivity, customer contracts, GDPR consequences and possible NIS2 or DORA service impact.

Select treatments such as MFA for privileged access, role-based access control, quarterly access reviews, encryption at rest, TLS, vulnerability scanning, logging, alerting, secure backup, incident response procedures and data masking in non-production environments.

Then map the risk to the SoA. Add ISO/IEC 27002:2022 references such as 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle and 8.10 Information Deletion where applicable. Add notes showing how these controls support GDPR Article 32, NIS2 Article 21 and DORA ICT risk management where relevant.

For regulatory mapping, keep the control names accurate and avoid forcing false equivalence.

Now build the evidence folder. Clarysec’s SME Audit and Compliance Monitoring Policy gives a simple rule:

“All evidence must be stored in a centralized audit folder.”

Source: Audit and Compliance Monitoring Policy-sme, Policy Implementation Requirements, policy clause 6.2.1. Audit and Compliance Monitoring Policy - SME

For this one risk scenario, the folder should contain:

Access evidence should not stop at screenshots. The Access Control Policy-sme adds a useful operational requirement:

“The IT Manager must document review results and corrective actions.”

Source: Access Control Policy-sme, Governance Requirements, policy clause 5.5.3. Access Control Policy - SME

Backup evidence must prove recoverability, not just successful jobs. The Backup and Restore Policy-sme states:

“Restore tests are conducted at least quarterly, and the results are documented to verify recoverability”

Source: Backup and Restore Policy-sme, Governance Requirements, policy clause 5.3.3. Backup and Restore Policy - SME

This gives you a complete evidence loop: regulation creates the requirement, risk explains why it matters, the SoA selects the control, the policy defines operation, and retained evidence proves the control works.

Controls in action: turning policy into operating proof

The Zenith Blueprint Controls in Action phase, Step 19, focuses on technical verification. It recommends reviewing endpoint security compliance, identity and access management, authentication configurations, source control security, capacity and availability, vulnerability and patch management, secure baselines, malware protection, deletion and data minimisation, masking and test data, DLP, backup and restore, redundancy, logging and monitoring, and time synchronisation.

For GDPR Article 32 TOMs, Step 19 is where abstract control language becomes proof. A strong evidence file should show that:

• Endpoint encryption is enabled and monitored.
• Privileged users have MFA.
• Joiner, mover and leaver processes are reconciled against HR records.
• Service accounts are documented and restricted.
• Code repositories are access controlled and secrets scanning is performed.
• Vulnerability scans are conducted and tracked to remediation.
• Production data is not casually copied into test environments.
• Secure deletion and retention policies are enforced.
• DLP alerts are reviewed.
• Backup restore tests prove recoverability.
• Logs are centralised, retained and reviewable.
• Time synchronisation supports reliable incident investigation.

The key is linkage. A patch report without a risk, policy and SoA reference is an IT artefact. A patch report linked to GDPR Article 32, NIS2 Article 21, DORA ICT risk management and an ISO 27001:2022 risk treatment plan is audit-ready evidence.

One evidence file, multiple audit lenses

The same TOMs evidence will be read differently by different stakeholders. A privacy reviewer may focus on personal data, necessity, proportionality and accountability. An ISO 27001 auditor may focus on scope, risk treatment, SoA and evidence of operation. A NIS2 authority may focus on management oversight, Article 21 measures and Article 23 reporting readiness. A DORA supervisor or financial customer may focus on ICT risk governance, resilience testing and third-party dependencies.

Clarysec uses Zenith Controls as the cross-compliance guide for this translation.

This prevents duplicated compliance work. Instead of building separate evidence packs for GDPR, NIS2 and DORA, build one control evidence file and tag each item for the obligations it supports.

Common gaps in Article 32 TOMs programs

The most common gap is control orphaning. A company has a control, such as encryption, but cannot explain which risk it treats, which policy requires it, who owns it or how it is reviewed.

The second gap is weak supplier evidence. Under GDPR, processors and subprocessors matter. Under NIS2, supply chain security is part of cybersecurity risk management. Under DORA, ICT third-party risk is a regulated domain with registers, due diligence, contractual safeguards, audit rights and exit planning. A vendor spreadsheet is not enough if critical dependencies are not risk assessed and controlled.

The third gap is incident evidence. Organisations often have an incident response plan but no proof that classification, escalation, authority reporting and customer communication have been tested. NIS2 and DORA raise expectations here, and GDPR personal data breach assessment must be integrated into the same workflow.

The fourth gap is backup proof. A successful backup job does not prove recoverability. A documented restore test does.

The fifth gap is management review. Article 32 TOMs must be proportionate to risk. If management never reviews risks, incidents, supplier issues, budget, audit findings and residual risk, proportionality becomes difficult to prove.

The final audit-ready toolkit

The Zenith Blueprint Audit, Review and Improvement phase, Step 30, provides the final readiness checklist. It includes the ISMS scope and context, signed information security policy, risk assessment and treatment documents, SoA, Annex A policies and procedures, training records, operational records, internal audit report, corrective action log, management review minutes, continual improvement evidence and compliance obligations records.

Clarysec’s enterprise Audit and Compliance Monitoring Policy states the purpose of this discipline:

“To generate defensible evidence and an audit trail in support of regulatory inquiries, legal proceedings, or customer assurance requests.”

Source: Audit and Compliance Monitoring Policy, Objectives, policy clause 3.4. Audit and Compliance Monitoring Policy

A mature Article 32 TOMs evidence file should include:

Next steps: build Article 32 TOMs evidence with Clarysec

If you need to prove GDPR Article 32 technical and organisational measures, do not begin by collecting random screenshots. Begin with traceability.

1. Define the ISMS scope and personal data processing boundaries.
2. Identify GDPR, NIS2, DORA, contractual and customer requirements.
3. Build risk criteria using ISO/IEC 27005:2022 and management-approved risk appetite.
4. Create or refresh the risk register.
5. Map each treatment to ISO 27001:2022 controls and the SoA.
6. Use Zenith Controls to cross-reference privacy, cryptography, supplier, incident and independent review controls across compliance expectations.
7. Follow Zenith Blueprint Step 13 and Step 14 to connect risks, controls and regulatory obligations.
8. Use Zenith Blueprint Step 19 to verify technical controls in operation.
9. Use Zenith Blueprint Step 30 to assemble the final audit-ready evidence file.
10. Store all evidence centrally, label it by risk and control theme, and keep corrective actions visible.

Clarysec can help you convert GDPR Article 32 from a vague compliance obligation into a defensible, risk-based evidence system aligned with ISO 27001:2022, NIS2 and DORA.

Start with the Zenith Blueprint, strengthen it with Clarysec policies, and use Zenith Controls to make every TOM traceable, testable and audit-ready.