2026 Cybersecurity Compliance Obligations Register Guide

Maria, the CISO of a fast-growing fintech platform, had twenty minutes before the quarterly board pack locked. The CEO’s message was short and uncomfortable:

“Maria, I need a single slide showing we are on top of our cybersecurity legal obligations for 2026. Not just ISO 27001. I mean everything. NIS2, DORA, GDPR, our client contracts. Are we compliant? Where’s the proof? Who owns it?”

At 08:15, three more requests landed. Legal wanted to know whether the company was an important entity under a Member State’s NIS2 transposition rules. The DPO wanted to know whether a suspicious database export should be handled as a GDPR personal data breach, a DORA major ICT-related incident, both, or neither. Procurement wanted approval for a fraud analytics vendor that would process EU personal data, support a critical service and use a cloud subprocessor outside the EU.

None of these questions are unusual in 2026. What is dangerous is when the organization cannot answer them from one maintained source of truth.

Most companies have policies. Many have risk registers, supplier files, privacy records, incident playbooks and a Statement of Applicability. But the gap appears when a board member, auditor, regulator or major customer asks a simple question:

“Show me each applicable legal, regulatory and contractual cybersecurity obligation, who owns it, how often it is reviewed, what control implements it, what evidence proves it and how exceptions reach management.”

That is the cybersecurity compliance obligations register.

For CISOs, compliance managers, auditors and business owners, this register is no longer an administrative spreadsheet. It is the operating mechanism that connects NIS2 national obligations, DORA supervisory expectations, GDPR accountability, ISO/IEC 27001:2022 requirements, customer contracts and internal policies into a working governance system.

Clarysec treats the register as a living ISMS artifact, not a legal appendix. In Legal and Regulatory Compliance Policy, the compliance function:

“Maintains the Compliance Obligations Register, listing all applicable laws, standards, certifications, and contractual clauses.”
From Legal and Regulatory Compliance Policy, Roles and Responsibilities, clause 4.2.1.

The important word is “maintains.” A register created for certification and ignored until the next audit is not a compliance mechanism. It is evidence of historical optimism.

What a cybersecurity compliance obligations register must do in 2026

A useful obligations register does five jobs.

First, it identifies obligations. These include laws, regulations, standards, certifications and contractual clauses. In 2026, common sources include NIS2 for essential and important entities, DORA for covered financial entities and ICT third-party service providers, GDPR for controllers and processors handling EU personal data, ISO/IEC 27001:2022 requirements for the ISMS, cloud security commitments, customer breach notification clauses, outsourcing rules and supplier security requirements.

Second, it classifies applicability. NIS2 may apply because the organization is in an Annex I or Annex II sector, provides digital infrastructure, acts as a managed service provider, provides cloud computing services or falls into a size-independent category such as DNS, TLD or trust services. DORA may apply because the organization is a financial entity or an ICT third-party service provider supporting financial entities. GDPR may apply because the organization processes EU personal data, offers services to individuals in the EU or monitors behavior in the EU.

Third, it maps obligations to internal controls, policies, processes and systems. This is where the register becomes operational. NIS2 Article 21 risk-management measures map to risk assessment, incident handling, business continuity, supply-chain security, secure development, control effectiveness reviews, training, cryptography, access control, asset management and MFA where appropriate. DORA maps to management body accountability, ICT risk management, incident classification, resilience testing, third-party registers and exit strategies. GDPR maps to records of processing, lawful basis, data minimization, retention, security of processing, breach assessment and evidence of accountability.

Fourth, it assigns owners and review cadence. Without ownership, compliance becomes a meeting topic. With ownership, it becomes a managed process.

Fifth, it defines evidence. The register should answer what artifact proves this obligation is met today. Evidence may include board minutes, risk assessment records, incident tickets, supplier due diligence, contract clauses, encryption configurations, vulnerability reports, access reviews, backup test records, privacy notices, DPIAs, breach assessments and internal audit findings.

Clarysec’s policy makes this traceability explicit:

“All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).”
From Legal and Regulatory Compliance Policy, Policy Implementation Requirements, clause 6.2.1.

It also defines evidence as part of the same mechanism:

“Required artifacts or records to demonstrate compliance (e.g., audit logs, encryption settings, consent documentation)”
From Legal and Regulatory Compliance Policy, Policy Implementation Requirements, clause 6.2.2.3.

This is the difference between compliance awareness and compliance assurance.

Why ISO/IEC 27001:2022 is the backbone

ISO/IEC 27001:2022 is often treated as a certification target, but for obligations management its value is stronger. It gives the register a management-system home.

Clauses 4.1 to 4.4 require the organization to understand internal and external issues, identify interested parties and determine legal, regulatory and contractual requirements relevant to the ISMS. Clauses 5.1 to 5.3 require leadership commitment, policy alignment, resources and assigned responsibilities. Clauses 6.1 to 6.2 require risk assessment, risk treatment, the Statement of Applicability and measurable objectives informed by applicable requirements. Clauses 8, 9 and 10 create the operating cycle: implement controls, reassess risks, monitor performance, conduct internal audits, review at management level and correct nonconformities.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec places this early in the ISMS Foundation and Leadership phase, Step 2: Stakeholder Needs and ISMS Scope. The Blueprint advises teams to identify stakeholder requirements by reviewing legal and regulatory requirements, extracting contractual security clauses, interviewing stakeholders and considering industry standards expected by partners.

“Clause 4.2 doesn’t require a specific document, but in practice it’s useful to create a Stakeholder Analysis table. This can be a simple table with columns: Interested Party, Needs/Expectations, How we address it.”
From Zenith Blueprint, ISMS Foundation & Leadership phase, Step 2.

That stakeholder analysis becomes the upstream input to the obligations register. The register then becomes the bridge to risk treatment.

In the Risk Management phase, Step 13, Zenith Blueprint tells teams to map controls to risks, clauses and external regulations:

“Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register (as part of risk impact justification) or in the SoA notes.”
From Zenith Blueprint, Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability.

That is the traceability auditors want. If GDPR drives encryption, retention and breach assessment controls, say so. If NIS2 drives incident reporting escalation and supplier security measures, say so. If DORA drives ICT third-party risk registers and exit testing, say so.

The three ISO/IEC 27002:2022 control anchors

The central ISO/IEC 27002:2022 control for obligations management is 5.31, Legal, statutory, regulatory and contractual requirements. Clarysec’s Zenith Controls: The Cross-Compliance Guide classifies 5.31 as a preventive control tied to confidentiality, integrity and availability, aligned to the Identify cybersecurity concept and operating in the Legal and Compliance capability across governance, ecosystem and protection domains.

The Zenith Controls narrative is direct:

“Security doesn’t exist in a vacuum. It operates within a web of obligations, some defined by law, others by contract, and still others by sector-specific regulation.”
From Zenith Controls, treatment of ISO/IEC 27002:2022 control 5.31.

Control 5.31 does not work alone. Two supporting controls are essential.

Control 5.2, Information security roles and responsibilities, ensures that obligations are not assigned to “the business” or “IT” in the abstract. The Zenith Controls mapping ties 5.2 to policy ownership, compliance monitoring, incident management, awareness, independent review, evidence handling and privileged access governance.

Control 5.36, Compliance with policies, rules and standards for information security, closes the loop. It ensures documented requirements are followed, monitored, reported and corrected. The Zenith Controls mapping links 5.36 to policies for information security, disciplinary process, independent review, roles and responsibilities, event assessment, logging, monitoring and protected records.

Together, these controls answer the auditor’s core questions.

For smaller organizations, the same structure can be lighter. Clarysec’s Legal and Regulatory Compliance Policy - SME states:

“The GM must maintain a simple, structured Compliance Register listing:”
From Legal and Regulatory Compliance Policy - SME, Governance Requirements, clause 5.1.1.

It also requires routine review:

“The Compliance Register must be reviewed quarterly and updated when:”
From Legal and Regulatory Compliance Policy - SME, Governance Requirements, clause 5.1.2.

For SMEs, the register can start simple. It still needs ownership, cadence and evidence.

Build the register around obligations, not frameworks

The most common mistake is creating one tracker for NIS2, another for DORA, another for GDPR, another for ISO/IEC 27001:2022 and another for customer contracts. That creates duplicate evidence requests, conflicting owners and exhausted teams.

A better approach is obligation-to-control mapping. One security capability can satisfy multiple legal drivers if the register preserves the differences in trigger, scope, timeline and authority.

For example, incident response supports NIS2 significant incident reporting, DORA major ICT-related incident reporting and GDPR personal data breach assessment. Supplier due diligence supports NIS2 supply-chain security, DORA ICT third-party risk and GDPR processor governance. Logging and monitoring support incident detection, control effectiveness and accountability. Asset and data inventories support NIS2, DORA, GDPR and ISO/IEC 27001:2022 risk assessment.

The goal is not to hide legal differences. The goal is to avoid implementing the same capability three times.

A practical register model you can implement this week

A Clarysec-style obligations register should be simple enough to maintain and detailed enough to survive audit sampling. The minimum fields are:

1. Obligation ID.
2. Source, such as NIS2, DORA, GDPR, ISO/IEC 27001:2022, customer contract or internal policy.
3. Specific article, clause or contract reference.
4. Requirement summary.
5. Applicability rationale.
6. Business process or service affected.
7. Risk scenario if unmet.
8. Control mapping, including ISO/IEC 27002:2022 controls and internal policy references.
9. Control owner.
10. Evidence owner.
11. Review cadence.
12. Evidence location.
13. Exceptions or open gaps.
14. Management review escalation flag.
15. Last reviewed date and next review date.
16. Status.

Here is a practical example for a SaaS fintech provider operating in the EU.

| Obligation ID | Source and requirement | Internal mapping | Owner | Review cadence | Evidence | |—|—|—|—|—| | OBL-001 | NIS2 applicability and entity classification for digital infrastructure or managed service activities | Legal and Regulatory Compliance Policy, control 5.31, ISMS scope | Compliance Manager | Quarterly and on service change | Applicability memo, entity registration data, board briefing | | OBL-002 | DORA ICT third-party risk management for critical or important ICT services | Supplier security procedure, controls 5.19 to 5.23, DORA supplier register | Vendor Risk Owner | Quarterly and before new critical supplier | Supplier register, due diligence, contract clauses, exit test | | OBL-003 | GDPR personal data breach assessment and accountability | Incident response plan, privacy procedure, controls 5.24 to 5.28 and 5.34 | DPO and Incident Manager | Per incident, quarterly trend review | Breach assessment, incident ticket, notification decision, lessons learned | | OBL-004 | ISO/IEC 27001:2022 monitoring, internal audit and management review | Audit and compliance monitoring process, control 5.36 | ISMS Manager | Annual audit plan, quarterly monitoring | Internal audit report, KPI dashboard, corrective action log | | OBL-005 | Customer contract requires notification of security incident within 24 hours | Contract register, incident communications playbook | Customer Success and Legal | On contract change and per incident | Contract clause extract, incident communications record |

Notice how each row is actionable. It does not merely say “comply with DORA.” It identifies the requirement, internal mapping, owner, review rhythm and evidence.

Clarysec’s Governance Roles and Responsibilities Policy - SME reinforces this ownership discipline:

“Governance responsibilities (e.g. policy review, exception approval, provider oversight) must be assigned to specific individuals or roles.”
From Governance Roles and Responsibilities Policy - SME, Governance Requirements, clause 5.3.

For enterprise environments, the same concept should be reflected in a RACI matrix, control ownership register and management reporting pack.

Incident reporting example: one playbook, multiple obligations

A SaaS provider determines it may fall within NIS2 scope because it provides cloud or managed service activities in the EU and meets relevant size or sector criteria. The organization already has an incident response plan, but it has not mapped NIS2 reporting into escalation procedures.

The register entry should capture the obligation precisely:

• Source: NIS2 Article 23.
• Requirement: notify the CSIRT or competent authority without undue delay for significant incidents, with early warning within 24 hours, notification within 72 hours and a final report within one month.
• Applicability: potentially applicable due to service category and Member State operations.
• Risk if unmet: regulatory breach, delayed stakeholder notification, loss of customer trust.

Then map it to controls. ISO/IEC 27002:2022 controls 5.24 to 5.28 cover incident management planning, assessment, response, learning and evidence collection. Control 5.31 covers legal obligation tracking. Control 5.2 covers role assignment. Control 5.36 covers monitoring whether the process is followed.

Ownership should be explicit. The Incident Manager owns classification and escalation. Legal or Compliance owns regulator interpretation and notification authorization. Communications owns customer communication. The evidence owner maintains the incident file.

Evidence should include the incident classification record, timeline, awareness time, triage time, escalation time, notification decision, regulator submission if applicable, customer communication decision, lessons learned and corrective actions.

A tabletop exercise then makes the register real. Use a scenario where a cloud misconfiguration causes potential customer data exposure and service disruption. Test whether the team can identify the 24-hour NIS2 clock, determine whether GDPR breach assessment is required, classify potential DORA impact if financial services are affected and produce a complete evidence file.

This is how the obligations register becomes a control. It changes operational behavior.

Evidence management is where audits often fail

Many organizations can show a register. Fewer can show that evidence is complete, current, protected and linked.

Clarysec’s Audit and Compliance Monitoring Policy - SME gives the basic requirement:

“All evidence must be stored in a centralized audit folder.”
From Audit and Compliance Monitoring Policy - SME, Policy Implementation Requirements, clause 6.2.1.

That sentence solves a common audit failure. Evidence scattered across email, Jira tickets, SharePoint folders, vendor portals and personal drives is not audit-ready. The centralized folder does not need to be one literal folder for every file, but there must be a controlled evidence repository or index that tells an auditor where the authoritative artifact lives.

For each obligation, evidence should be named consistently, mapped to the obligation ID and control ID, owned by a named person or role, protected against unauthorized modification, retained according to legal and contractual requirements, reviewed at a defined cadence and linked to exceptions and corrective actions.

The Zenith Controls treatment of control 5.31 ties legal requirements to records retention through control 5.33, privacy and protection of PII through control 5.34, independent review through control 5.35 and internal compliance through control 5.36. This matters because evidence itself can contain regulated information, such as personal data, forensic indicators, privileged access logs or customer confidential data.

The audit lens: how different reviewers will test the register

A strong register survives multiple audit perspectives.

An ISO/IEC 27001:2022 auditor will start with context, interested parties, scope, risk treatment, the Statement of Applicability, monitoring, internal audit and management review. For control 5.31, the auditor will expect to see that applicable legal and contractual requirements are identified, kept current and reflected in controls. For control 5.2, they will test whether responsibilities are assigned and understood. For control 5.36, they will look for monitoring, nonconformities and corrective actions.

A NIST-aligned assessor will focus on governance outcomes. NIST Cybersecurity Framework 2.0 GOVERN includes GV.OC-03, which expects legal, regulatory and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, to be understood and managed. The assessor may ask for an organizational profile, gap analysis and prioritized action plan, then sample whether obligations translate into asset management, access control, data protection, logging, response and recovery.

A COBIT 2019 or ISACA auditor will look through governance and management objectives. MEA03, Managed Compliance With External Requirements, is especially relevant. The auditor may test whether external requirements are identified through MEA03.01, whether responses are optimized through MEA03.02, whether compliance is confirmed through MEA03.03 and whether assurance is obtained through MEA03.04.

An ISACA ITAF-based auditor will emphasize sufficient and appropriate evidence. They may select a GDPR breach notification requirement, a DORA supplier register requirement and a NIS2 incident reporting requirement, then ask for the end-to-end evidence trail.

A technical assessor may validate control 5.36 through configuration evidence. If the register says NIS2 and customer contracts require MFA for privileged access, they may check identity provider settings. If it says GDPR and contracts require encryption, they may inspect database encryption, key management records and data flow diagrams. If DORA requires monitoring of ICT third-party services, they may inspect service reviews, SLA reports and exit-test records.

The register needs governance evidence and technical evidence.

Management review closes the accountability loop

A compliance obligations register should not be owned silently by compliance. It must reach management review because NIS2, DORA, GDPR and ISO/IEC 27001:2022 all rely on accountability.

NIS2 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. DORA places ultimate accountability for ICT risk management on the management body. GDPR requires controllers to demonstrate compliance. ISO/IEC 27001:2022 requires management review to consider changes in context, interested-party needs, audit results, monitoring results, risk assessment results, treatment status and improvement opportunities.

Clarysec’s Information Security Policy aligns with this expectation:

“Management review activities (per ISO/IEC 27001 Clause 9.3) shall be conducted at least annually and shall include:”
From Information Security Policy, Governance Requirements, clause 5.3.

The SME audit policy adds the operational link:

“Audit findings and status updates must be included in the ISMS management review process.”
From Audit and Compliance Monitoring Policy - SME, Governance Requirements, clause 5.4.3.

Management review does not need every row. It needs trends, risk decisions, exceptions, resources and accountability.

This converts the register from a compliance file into a leadership tool.

Common failure patterns and how to avoid them

The first failure pattern is that legal owns the law, security owns the controls and nobody owns the mapping. Clarysec prevents this by requiring obligations to be mapped to policies, controls and owners in the ISMS.

The second is tracking frameworks instead of obligations. A register entry that says “DORA” is not actionable. A register entry that says “DORA Article 28 ICT third-party risk management requires due diligence, contractual provisions, monitoring and exit strategies” is actionable.

The third is missing cadence. Quarterly review is a practical baseline for many organizations, with event-based updates for new services, new countries, new suppliers, incidents, audits and contract changes.

The fourth is evidence that exists but cannot be found. The centralized audit folder principle addresses this directly.

The fifth is informal exceptions. If a control cannot meet an obligation temporarily, the exception must be documented, risk-assessed, approved, time-bound and reviewed.

The sixth is ceremonial management review. The register should drive decisions about budget, staffing, supplier remediation, contract negotiation, risk acceptance and corrective actions.

How Clarysec turns the register into an operating mechanism

Clarysec’s 30-step approach makes obligations management practical.

In Zenith Blueprint, Step 2 identifies stakeholder needs and applicable requirements. Step 13 maps controls to risks, clauses and the Statement of Applicability. Step 23 addresses organizational controls, including the requirement to build and maintain a legal and regulatory requirements register.

The Blueprint states:

“Work with Legal, Compliance, or external counsel to build a register of applicable laws, regulations, and contractual obligations related to information security (5.31). This should include data protection laws (e.g., GDPR), sector-specific requirements, and certification mandates. Ensure the ISMS team knows where to reference this and that changes are reviewed at least quarterly.”
From Zenith Blueprint, Controls in Action phase, Step 23.

Clarysec policies provide the governance rules: maintain the register, assign responsibilities, centralize evidence, review findings and include status in management review.

Zenith Controls provides the cross-compliance compass. For control 5.31, it maps obligations management to GDPR accountability, NIS2 cybersecurity duties, DORA ICT risk management, NIST CSF governance, NIST SP 800-53 program management and continuous monitoring, and COBIT 2019 external compliance monitoring. For control 5.2, it connects role accountability to GDPR, NIS2, DORA, NIST and COBIT. For control 5.36, it connects policy compliance monitoring to GDPR accountability, NIS2 cyber hygiene and access control expectations, DORA operational resilience, NIST continuous monitoring and COBIT conformance monitoring.

The value is simple: one register, one control architecture, many compliance outcomes.

Next steps: make your obligations register audit-ready

The organizations that handle 2026 compliance well will not be the ones with the most spreadsheets. They will be the ones with traceability: obligation to owner, owner to control, control to evidence, evidence to review, review to improvement.

Start with these actions:

1. Create or refresh your cybersecurity compliance obligations register.
2. Add NIS2, DORA, GDPR, ISO/IEC 27001:2022 and key customer contractual obligations.
3. Map each obligation to policies, ISO/IEC 27002:2022 controls, owners, review cadence and evidence.
4. Identify gaps, exceptions and expired evidence.
5. Add register status to the next ISMS management review.
6. Use Clarysec’s Zenith Blueprint to place the register into the 30-step ISMS roadmap.
7. Use Zenith Controls to cross-map obligations to ISO, NIST, COBIT, GDPR, NIS2 and DORA expectations.
8. Use Clarysec’s Legal and Regulatory Compliance Policy, Legal and Regulatory Compliance Policy - SME, Governance Roles and Responsibilities Policy - SME, Audit and Compliance Monitoring Policy - SME and Information Security Policy to formalize ownership, review, evidence storage and management accountability.

Clarysec can help you build that traceability into your ISMS before the auditor, regulator, board member or customer asks for it. Download the relevant Clarysec policy templates, map your first ten obligations this week and turn compliance from a scramble into an operating system.