DORA Register of Information: ISO 27001 Guide

It is 09:15 on a Tuesday. Sarah, the CISO of a rapidly growing fintech, is sitting in a readiness assessment with her compliance manager, legal counsel, procurement lead and cloud architect. The external consultant is playing the role of a DORA supervisor.

“Thank you for the presentation,” he says. “Please provide your Register of Information as required by DORA Article 28, including the ICT contractual arrangements supporting critical or important functions, subcontracting visibility, asset ownership and evidence that the register is maintained under your ICT risk management framework.”

The first answer sounds confident: “We have a supplier list.”

Then the questions start.

Which suppliers support payment authorization? Which contracts include audit rights, incident assistance, data location commitments, termination rights and exit support? Which SaaS platforms process customer personal data? Which cloud services support critical or important functions? Which subcontractors sit behind the managed security provider? Which internal asset owner approved the dependency? Which risks in the ISO/IEC 27001:2022 risk treatment plan are linked to these providers? Which Statement of Applicability entries justify the controls?

By 10:30, the team has opened four spreadsheets, a CMDB export, a SharePoint folder of PDF contracts, a privacy processor list, a cloud billing report and a manually maintained SaaS tracker. None of them agree.

That is the practical DORA Register of Information challenge in 2026. DORA implementation has moved from “we need a roadmap” to “show me the evidence.” For financial entities, ICT third-party service providers, CISOs, internal auditors and compliance teams, the register is no longer an administrative template. It is the connective tissue between ICT contracts, supplier risk, subcontracting chains, cloud services, ICT assets, critical functions, governance ownership and ISO/IEC 27001:2022 evidence.

Clarysec’s approach is simple: do not build the DORA Register of Information as a separate compliance artifact. Build it as a living evidence layer inside your ISMS, supported by asset management, supplier security, cloud usage governance, legal and regulatory obligation mapping, audit metadata and risk treatment traceability.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls identifies three ISO/IEC 27001:2022 Annex A anchor controls as especially relevant for this topic: A.5.9, inventory of information and other associated assets; A.5.19, information security in supplier relationships; and A.5.20, addressing information security within supplier agreements. These controls are not extra paperwork. They are the operational backbone for proving that the register is complete, owned, current and auditable.

What DORA expects from the Register of Information

DORA applies from 17 January 2025 and creates a financial-sector ICT resilience rulebook for ICT risk management, incident reporting, resilience testing, third-party risk, contractual arrangements, oversight of critical ICT third-party providers and supervisory enforcement. For financial entities also identified under national NIS2 transposition, DORA operates as the sector-specific Union legal act for corresponding cybersecurity risk-management and incident-reporting requirements.

The register obligation sits inside DORA’s ICT third-party risk management discipline. DORA Article 28 requires financial entities to manage ICT third-party risk as part of the ICT risk management framework, remain fully responsible for compliance even when using ICT providers, maintain a register of information for ICT service contractual arrangements and distinguish arrangements supporting critical or important functions.

DORA Article 29 adds concentration and subcontracting risk considerations. This includes substitutability, multiple dependencies on the same or connected providers, third-country subcontracting, insolvency constraints, data recovery, data protection compliance and long or complex subcontracting chains.

DORA Article 30 then defines the contract substance auditors will expect to see. This includes service descriptions, subcontracting conditions, data processing locations, data protection commitments, access and recovery obligations, service levels, incident support, cooperation with authorities, termination rights, training participation, audit rights and exit strategies for arrangements supporting critical or important functions.

A mature DORA Register of Information must answer four practical questions.

A weak register is a spreadsheet procurement updates once a year. A strong register is a governed dataset that connects supplier portfolio, asset inventory, cloud register, contract repository, privacy records, business continuity plans, incident playbooks, risk register and ISO/IEC 27001:2022 evidence.

Why ISO 27001 is the fastest route to a defensible DORA register

ISO/IEC 27001:2022 gives organizations the management-system structure DORA evidence often lacks. Clauses 4.1 to 4.4 require the organization to define context, interested parties, legal, regulatory and contractual obligations, scope, interfaces and dependencies. This is exactly where DORA belongs in the ISMS, because the register depends on knowing which financial services, ICT providers, customers, authorities, cloud platforms and outsourced processes fall inside scope.

Clauses 5.1 to 5.3 require leadership, policy alignment, resources, responsibilities and reporting to top management. That matters because DORA Article 5 places responsibility on the management body to define, approve, oversee and remain accountable for the ICT risk management framework, including ICT third-party service policies and reporting channels.

Clauses 6.1.1 to 6.1.3 are where the register becomes risk-based. ISO/IEC 27001:2022 requires a repeatable risk assessment process, risk owners, likelihood and consequence analysis, risk treatment, control selection, a Statement of Applicability and risk-owner approval of residual risk. A DORA register that is not linked to risk treatment becomes a static list. A register linked to risk scenarios, controls and owners becomes audit evidence.

Clauses 8.1 to 8.3 then turn planning into controlled operations. They support documented information, operational planning and control, control of changes, control of externally provided processes, planned risk reassessments, treatment implementation and evidence retention. This is critical for 2026 because supervisors are not only asking whether a register existed at a point in time. They are asking whether new contracts, changed services, new subcontractors, cloud migrations and exit events are captured in the governance cycle.

The Annex A control layer reinforces the same point. Supplier relationships, supplier agreements, ICT supply-chain risk, supplier service monitoring, cloud-service acquisition and exit, incident management, business continuity, legal and regulatory obligations, privacy, backups, logging, monitoring, cryptography and vulnerability management all contribute to the quality of the register.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint explains the asset foundation in the Controls in Action phase, Step 22:

In its most strategic form, an asset inventory serves as the central nervous system of your ISMS. It informs how access is provisioned (8.2), where encryption must be applied (8.24), which systems require backup (8.13), what logs are collected (8.15), and even how classification and retention policies are enforced (5.10, 8.10).

That quote captures the practical point. You cannot maintain a reliable DORA Register of Information unless the underlying asset inventory is reliable. If your register says “Core Banking SaaS,” but your asset inventory does not show APIs, service accounts, datasets, log sources, encryption keys, backup dependencies and owners, the register is incomplete from an audit perspective.

The Clarysec data model: one register, many evidence views

A DORA Register of Information should not replace your supplier register, asset register or cloud register. It should join them. Clarysec usually designs the register as a master evidence layer with controlled relationships to existing ISMS records.

The minimum viable model has seven linked objects.

This structure lets one register support multiple evidence requests. A DORA supervisor can view contractual arrangements supporting critical or important functions. An ISO auditor can trace supplier controls to Annex A references and risk treatment. A GDPR reviewer can see processors, data categories, locations and data protection commitments. A NIST-oriented assessor can review supply chain governance, supplier criticality, contract requirements and lifecycle monitoring.

The register becomes more than “who are our vendors?” It becomes a dependency graph.

Policy foundations that make the register auditable

Clarysec’s policy set gives the register an operational home. For SMEs, the Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME starts with a clear register requirement:

A Supplier Register must be maintained and updated by the administrative or procurement contact. It must include:

The same SME policy establishes that contracts must contain defined security obligations:

Contracts must include mandatory clauses covering:

Even though the quoted clauses introduce field lists and mandatory clause categories in the policy itself, the implementation message is direct: supplier governance must be documented, assigned and contractually enforced.

For enterprise environments, Clarysec’s Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy is even closer to DORA’s supervisory expectations:

Supplier Dependency Register: The VMO shall maintain an up-to-date register of all critical suppliers, including details such as services/products provided; whether the supplier is sole-source; available alternate suppliers or substitutability; current contract terms; and an assessment of the impact if the supplier were to fail or be compromised. The register shall clearly identify high-dependency suppliers (e.g., those for which no rapid alternative exists).

This maps neatly to DORA Article 29 concentration and substitutability risk. If a supplier is sole-source, supports a critical function, operates in a third country, uses a long subcontracting chain and has no tested exit path, the register should not hide that risk in a free-text note. It should flag it, assign an owner and connect it to risk treatment.

Clarysec’s enterprise Third party and supplier security policy Third party and supplier security policy makes scope explicit:

It covers both direct suppliers and, where applicable, their subcontractors, and includes third-party software, infrastructure, support, and managed services.

That sentence is a common DORA gap. Many organizations capture direct ICT providers but do not document subcontractors, sub-processors, managed service tooling, support platforms or third-party software embedded in a service.

Contract evidence matters too. The same enterprise policy includes:

Rights to audit, inspect, and request security evidence

That phrase should be visible in your contract review checklist. If a critical ICT provider contract lacks audit or evidence rights, the register should mark a remediation action.

Asset evidence is equally important. Clarysec’s SME Asset Management Policy Asset Management Policy - SME states:

The IT Lead must maintain a structured asset inventory that includes, at a minimum, the following fields:

The enterprise Asset Management Policy Asset Management Policy similarly states:

The Asset Inventory must contain, at a minimum:

The register does not need to duplicate every asset field, but it must reference the asset inventory. If a payment monitoring SaaS supports fraud detection, the DORA register should link to the application asset, dataset asset, service accounts, API integrations, log sources and business owner.

Cloud services deserve a dedicated view. Clarysec’s SME Cloud Usage Policy Cloud Usage Policy - SME requires:

A Cloud Service Register must be maintained by the IT provider or GM. It must record:

This is particularly valuable for shadow IT discovery. A DORA register that excludes cloud services bought outside procurement will fail the practical completeness test.

Finally, Clarysec’s Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy turns cross-compliance into an ISMS requirement:

All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).

That is the bridge from DORA register to ISO 27001 evidence. The register should not only show suppliers. It should show which policies, controls and owners satisfy the regulatory obligation.

Mapping DORA requirements to ISO 27001 and Clarysec evidence

The table below combines the key register expectations with ISO/IEC 27001:2022 Annex A controls and practical Clarysec evidence artifacts.

This mapping is where the register stops being a spreadsheet and becomes an evidence model. Each row should have a contract owner, supplier owner, service owner, business owner and compliance owner. Each critical relationship should have a risk record, a contract clause checklist, an asset link and a monitoring cadence.

Hands-on example: mapping one ICT contract to ISO 27001 evidence

Imagine a financial entity uses a cloud-based fraud analytics platform. The service ingests transaction metadata, supports real-time fraud scoring, integrates with the payment platform, stores pseudonymised customer identifiers, uses a cloud hosting subcontractor and provides managed support from an approved third-country location.

A weak register row says: “Vendor: FraudCloud. Service: Fraud analytics. Contract signed. Critical: yes.”

A supervisory-grade register row looks very different.

Now the compliance team can produce a coherent evidence pack. The supplier register proves the provider exists and has an owner. The asset inventory proves the internal systems, APIs, datasets and logs are known. The contract checklist proves mandatory DORA clauses were reviewed. The risk assessment proves concentration, subcontracting, data protection and operational resilience were considered. The Statement of Applicability shows which controls were selected. The monitoring review proves the arrangement is not forgotten after onboarding.

The Zenith Blueprint, Risk Management phase, Step 13, recommends exactly this kind of traceability:

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.

That is how the DORA register becomes ISO 27001 evidence instead of parallel bureaucracy.

The supplier and subcontractor chain is where register quality fails

The biggest register failures are not caused by missing top-level vendors. They are caused by hidden dependency chains.

A managed security provider may use a SIEM platform, endpoint telemetry agent, ticketing system and offshore triage team. A payment processor may depend on cloud hosting, identity services, fraud databases and settlement connectivity. A SaaS provider may rely on multiple sub-processors for analytics, email, observability, customer support and backups.

DORA Article 29 forces attention onto concentration and subcontracting risk. NIS2 Article 21 also requires supply chain security for direct suppliers and service providers and expects entities to consider vulnerabilities specific to each direct supplier, overall product quality, supplier cybersecurity practices and secure development procedures. For financial entities covered by DORA, DORA acts as the sector-specific rulebook for overlapping NIS2 cybersecurity risk-management and incident-reporting requirements, but the supply chain logic is aligned.

Clarysec’s Zenith Blueprint, Controls in Action phase, Step 23, gives practical instruction:

For every critical supplier, identify if they use subcontractors (sub-processors) who may access your data or systems. Document how your information security requirements are flowed down to these parties, either through your supplier’s contract terms or your own direct clauses.

This is where many organizations need remediation in 2026. Contracts signed before DORA readiness may not include subcontractor transparency, audit evidence rights, authority cooperation, incident assistance, exit support or location commitments. The register should therefore include a contract remediation status, such as complete, gap accepted, renegotiation underway or exit option required.

Cross-compliance: DORA, NIS2, GDPR and NIST need the same dependency truth

A well-designed DORA Register of Information supports more than DORA.

NIS2 Article 20 makes cybersecurity a management-body responsibility through approval, oversight and training. Article 21 requires risk analysis, policies, incident handling, continuity, supply chain security, secure acquisition and maintenance, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management and MFA where appropriate. These areas overlap strongly with ISO/IEC 27001:2022 and the register evidence model.

GDPR adds privacy accountability. Its territorial scope can apply to EU and non-EU organizations that process personal data in the context of EU establishments, offer goods or services to individuals in the EU, or monitor their behaviour. GDPR definitions of controller, processor, processing, pseudonymisation and personal data breach are directly relevant to ICT supplier mapping. If the DORA register identifies ICT providers and subcontractors but does not identify personal data processing roles, data categories, locations and safeguards, it will not support GDPR evidence.

NIST CSF 2.0 provides another useful lens. Its GOVERN function requires organizations to understand mission, stakeholder expectations, dependencies, legal and contractual requirements, services others depend on and services the organization depends on. Its GV.SC supply chain outcomes call for a supply chain risk management program, defined supplier roles, integration into enterprise risk management, supplier criticality, contract requirements, due diligence, lifecycle monitoring, incident coordination and post-relationship planning.

A practical cross-compliance view looks like this.

The point is not to create five compliance workstreams. The point is to create one evidence model that can be filtered for each framework.

Through the auditor’s eyes

A DORA supervisor will focus on completeness, critical or important functions, contractual arrangements, subcontracting, concentration risk, governance, reporting and whether the register is maintained. They may ask for a sample of critical providers and expect to see contract clauses, risk assessments, exit strategies, incident support terms and evidence of management oversight.

An ISO/IEC 27001:2022 auditor will start from ISMS scope, interested parties, regulatory obligations, risk assessment, Statement of Applicability, operational control and documented information. They will test whether supplier relationships and asset inventories are maintained, whether externally provided processes are controlled, whether changes trigger reassessment and whether evidence supports the claimed control implementation.

A NIST CSF 2.0 assessor will often ask for current and target profiles, governance expectations, dependency mapping, supplier criticality, contract integration, lifecycle monitoring and prioritized improvement actions.

A COBIT 2019-oriented auditor will typically examine governance ownership, process accountability, decision rights, performance monitoring, risk reporting and assurance. They will ask whether the register is embedded in enterprise governance, not just maintained by compliance.

Zenith Controls helps translate these perspectives by anchoring the topic in ISO/IEC 27001:2022 Annex A controls A.5.9, A.5.19 and A.5.20, then using cross-compliance interpretation to connect assets, supplier relationships and supplier agreements to regulatory, governance and audit expectations. This is the difference between “we have a register” and “we can defend the register.”

Clarysec’s SME Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy - SME also addresses evidence quality:

Metadata (e.g., who collected it, when, and from which system) must be documented.

That requirement is small but powerful. In a 2026 evidence request, a spreadsheet without collection metadata is weak. A register export showing source system, extraction date, responsible owner, approval status and review cadence is stronger.

Common DORA Register of Information findings in 2026

The most frequent findings are practical.

First, register incompleteness. Cloud services, support tools, monitoring platforms, developer tools, ticketing systems and data analytics platforms are often missing because they were not classified as ICT services by procurement.

Second, weak criticality logic. Some teams mark vendors as critical based on spend, not business impact. DORA cares whether the ICT service supports a critical or important function.

Third, contract evidence gaps. Older supplier agreements often lack DORA-ready clauses for audit rights, incident assistance, subcontracting, authority cooperation, service locations, data return, termination and exit support.

Fourth, poor asset linkage. Registers list vendors but do not link to applications, datasets, APIs, identities, logs, infrastructure or business services. This makes impact analysis difficult during incidents and supplier failures.

Fifth, subcontractor opacity. The organization knows the main provider but cannot explain which sub-processors or technical providers support the service.

Sixth, no change triggers. A provider adds a new sub-processor, changes hosting region, migrates architecture or modifies support access, but no one updates the register or reassesses risk.

Seventh, no evidence cadence. There is no defined frequency for supplier review, contract review, asset validation, cloud register reconciliation or management reporting.

These are solvable issues, but only if the register has owners and workflows.

A practical 30-day improvement plan

Start with scope. Identify all business functions that may be critical or important under DORA. For each function, list the ICT services it depends on. Do not begin with procurement spend. Begin with operational dependency.

Reconcile the core data sources: supplier register, contract repository, asset inventory and cloud service register. Add privacy processor records and incident response dependencies where relevant. The goal is not perfection on day one. The goal is a single register backbone with unknowns marked clearly.

Classify suppliers and services using criteria such as function supported, data sensitivity, operational substitutability, concentration, subcontracting, locations, incident impact, recovery time and regulatory relevance.

Review contracts for every critical or important ICT arrangement. Check whether the contract includes service descriptions, subcontracting conditions, locations, data protection commitments, access and recovery, service levels, incident support, audit rights, authority cooperation, termination, training participation and exit support.

Map ISO evidence for each critical arrangement. Link to asset records, risk assessment entries, SoA controls, supplier due diligence, monitoring reviews, continuity plans, incident playbooks and exit strategy evidence.

Assign cadence. Critical providers may require quarterly review, annual assurance, contract review before renewal and immediate reassessment on material change. Non-critical providers may be reviewed annually or on trigger events.

Use this checklist to turn the register into an operating process:

• Create a DORA register owner and backup owner.
• Link every register row to a contract ID and supplier owner.
• Link every critical or important ICT service to business function and asset records.
• Add subcontractor and sub-processor fields, even if initially marked unknown.
• Add contract clause status for DORA-critical terms.
• Add ISO/IEC 27001:2022 risk and SoA references.
• Add GDPR role, personal data and location fields where applicable.
• Add review cadence and last-reviewed metadata.
• Create escalation rules for missing clauses, unknown subcontractors and high concentration risk.
• Report register quality metrics to management.

This is where Clarysec’s 30-step implementation method, policy set and Zenith Controls work together. The Zenith Blueprint gives the implementation path, from risk treatment and SoA traceability in Step 13 to asset inventory in Step 22 and supplier controls in Step 23. The policies define who must maintain registers, what contractual and asset evidence must exist and how compliance metadata is captured. Zenith Controls provides the cross-compliance compass for mapping the same evidence across DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST and COBIT 19 audit expectations.

Turn the register into evidence before the supervisor asks

If your DORA Register of Information is still a spreadsheet disconnected from contracts, assets, suppliers, subcontractors and ISO 27001 evidence, 2026 is the year to fix it.

Start by using the Zenith Blueprint Zenith Blueprint to connect risk treatment, asset inventory and supplier governance. Use Zenith Controls Zenith Controls to map ISO/IEC 27001:2022 Annex A controls A.5.9, A.5.19 and A.5.20 into cross-compliance evidence. Then operationalize the requirements through Clarysec’s supplier, asset, cloud, legal compliance and audit monitoring policies, including Third-Party and Supplier Security Policy - SME, Supplier Dependency Risk Management Policy, Third party and supplier security policy, Asset Management Policy - SME, Asset Management Policy, Cloud Usage Policy - SME, Legal and Regulatory Compliance Policy and Audit and Compliance Monitoring Policy - SME.

The best time to repair register quality is before an authority request, internal audit, supplier outage or contract renewal. The next best time is now. Download the relevant Clarysec policies, map your current register against the evidence model above and book a DORA register assessment to turn scattered supplier data into supervisory-grade evidence.