Cloud Shared Responsibility Matrix for ISO, NIS2, DORA

A fintech COO calls the CISO at 07:15 on a Monday.

A European banking customer is asking for proof that the company’s SaaS platform can satisfy DORA ICT third-party risk requirements. The sales team has already sent the familiar supplier security pack: ISO certificate, penetration test executive summary, cyber insurance certificate, privacy notice and a cloud provider assurance report.

The bank comes back with a sharper question:

“Show us who owns each control in your cloud environment. You, your cloud provider, your managed database provider, your identity provider, your logging vendor and any subprocessors. Then show the evidence.”

Later that morning, the CISO has a board meeting. The CEO will ask the same question in business language: “Are we sure this platform is secure, and who is responsible if something goes wrong?”

That is where many cloud compliance programs stall.

The organization may have a strong cloud provider, good tooling, reasonable policies and a risk register. But when asked to prove responsibility boundaries, the evidence is scattered. Procurement has the contracts. Legal has the DPA. Engineering has architecture diagrams. Security has logs and cloud configurations. Privacy has the subprocessor list. Compliance has the Statement of Applicability. Nobody has one controlled artefact that says, control by control, what the provider does, what the customer must configure, which subprocessor is involved, which clause makes the obligation enforceable and what evidence an auditor should expect.

That artefact is the cloud shared responsibility matrix.

Not the generic hyperscaler slide that says the provider secures the cloud and the customer secures what is in the cloud. A real cloud shared responsibility matrix for ISO/IEC 27001:2022, NIS2, DORA and GDPR is a governance record. It survives customer due diligence, an ISO audit, a DORA review, a GDPR accountability challenge and an incident investigation.

Why cloud shared responsibility becomes an audit problem

The shared responsibility model is usually taught as a technical boundary. In IaaS, the provider manages physical facilities, hardware, virtualization and core infrastructure. The customer manages identities, data, workloads, network rules, encryption choices and configurations. In SaaS, the provider takes more operational responsibility, but the customer still owns user access, data governance, lawful basis, configuration, monitoring expectations and incident escalation.

That explanation is useful, but incomplete.

Auditors, regulators and enterprise customers are asking more than “who operates the control?” They want to know:

• Who is accountable for the risk?
• Which contract clause makes that accountability enforceable?
• Which policy requires the control?
• Which cloud service, SaaS platform or subprocessor is in scope?
• Which evidence proves the control operated during the review period?
• Which framework requirement does the evidence satisfy?
• What happens if the provider changes its service, location, subcontractor or control posture?

ISO/IEC 27001:2022 ISO/IEC 27001:2022 makes this a management system issue. Clauses 4.1 to 4.4 require the organization to understand internal and external issues, interested parties, legal and contractual obligations, ISMS scope, interfaces and dependencies. Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, risk owner approval, residual risk acceptance and a Statement of Applicability. Clause 8.1 requires operational planning and control, including control of externally provided processes, products and services relevant to the ISMS.

In plain language, if a cloud provider, SaaS vendor or subprocessor supports an in-scope business process, it cannot sit outside the ISMS. It must be visible in scope, risk, treatment, contractual control and evidence.

NIS2 raises the stakes. Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, continuity, supply-chain security, secure acquisition, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management and multi-factor authentication or continuous authentication where appropriate. Article 20 places governance responsibility on management bodies.

DORA is even more explicit for financial entities. It applies from 17 January 2025 and requires financial entities to manage ICT risk, major ICT-related incident reporting, digital operational resilience testing and ICT third-party risk. Articles 28 to 30 require ICT third-party risk management, preliminary concentration risk assessment, contractual safeguards, audit and access rights, subcontracting visibility, termination rights and exit strategies.

GDPR adds the accountability test. Article 5 requires personal data to be processed with integrity and confidentiality, and Article 5(2) requires the controller to be able to demonstrate compliance. Article 28 governs processor contracts and subprocessors. Article 32 requires security of processing. Articles 33 and 34 require personal data breach notification where applicable.

The cloud shared responsibility matrix becomes the bridge between these obligations.

The Clarysec definition: a governance artefact, not a diagram

In Clarysec engagements, a cloud shared responsibility matrix is a controlled ISMS record that links cloud services, suppliers, subprocessors, controls, policies, contractual obligations, evidence and audit expectations.

The strongest explanation appears in Zenith Blueprint Zenith Blueprint, in the Controls in Action phase, Step 23:

“Cloud providers secure the infrastructure, but you are still accountable for your data, your configurations, your access policies, and your incident response readiness.”

The same step explains that cloud use must be treated as part of the ISMS, including classification of cloud services, understanding data processed or stored, provider evaluation, contractual clauses and management of service changes. That converts shared responsibility from a concept into a traceable control structure.

Zenith Controls Zenith Controls treats ISO/IEC 27001:2022 Annex A controls and ISO/IEC 27002:2022 guidance 5.20, 5.21 and 5.23 as central anchors:

• 5.20, Addressing information security within supplier agreements.
• 5.21, Managing information security in the ICT supply chain.
• 5.23, Information security for use of cloud services.

These are not isolated checklist items. They define the spine of the matrix.

Supporting standards can strengthen the matrix. ISO/IEC 27017 helps with cloud-specific security practices. ISO/IEC 27018 and ISO/IEC 27701 support PII and privacy governance. ISO/IEC 27005 supports risk assessment. ISO 22301 supports continuity and resilience. ISO/IEC 27035 supports incident management. ISO/IEC 20000-1 can help where cloud services are part of managed service delivery.

The minimum viable shared responsibility matrix

A mature matrix does not start with 200 rows. It starts with the cloud services that matter most.

For a SaaS, fintech or regulated SME, Clarysec usually begins with:

1. Customer-facing production cloud environment.
2. Identity provider.
3. Managed database or storage service.
4. Logging, monitoring and SIEM platform.
5. Payment, KYC, analytics or customer support SaaS.
6. Backup and disaster recovery service.
7. Managed service provider or managed security service provider.
8. Subprocessors that access, store or process customer data.

The first matrix should include the following columns.

A practical logging row might look like this.

That row is not just documentation. It tells security what to configure, procurement what contract language to check, privacy what data flow to record and auditors what evidence to request.

Policy foundation: turning the matrix into an enforceable requirement

A cloud shared responsibility matrix without policy backing is only a spreadsheet. Clarysec policies make it enforceable.

For SMEs, Cloud Usage Policy - SME Cloud Usage Policy - SME, section “Governance Requirements”, clause 5.3 requires:

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

The same SME policy, clause 5.2.3, ties cloud governance to privacy and location risk:

“Data residency and privacy practices comply with applicable legal requirements (e.g., GDPR)”

For enterprise environments, Cloud Usage Policy Cloud Usage Policy, section “Governance Requirements”, clause 5.1 states:

“The organization shall maintain a centralized Cloud Services Register, owned by the CISO, containing:”

Clause 5.4 then makes cloud responsibilities contractually enforceable:

“All CSP (Cloud Service Provider) contracts must include enforceable provisions for:”

Supplier governance extends the matrix beyond the immediate provider. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME, section “Governance Requirements”, clause 5.3.5 requires:

“Restrictions on further subcontracting without approval”

The same SME supplier policy, section “Policy Implementation Requirements”, clause 6.3.1 adds periodic review:

“Critical or high-risk suppliers must be reviewed at least annually. The review must verify:”

At enterprise level, Third party and supplier security policy Third party and supplier security policy, section “Governance Requirements”, clause 5.3 states:

“Contracts with suppliers must include:”

For personal data, Data Protection and Privacy Policy Data Protection and Privacy Policy, section “Enforcement and Compliance”, clause 8.5.1 requires:

“Contracts with processors shall include:”

For dependency visibility, Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, clause 6.5.4 requires:

“Leveraging the supplier relationship to obtain updates on subcontractors or supply chain dependencies one level downstream where they could affect us (for example, if a critical software supplier relies heavily on a third-party library, this shall be recorded).”

For logs, Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME, section “Governance Requirements”, clause 5.5.1.3 provides a concrete contractual requirement:

“Contracts must require providers to retain logs for at least 12 months and provide access upon request”

Together, these policies make the matrix a required governance record that supports supplier approval, cloud onboarding, privacy accountability, annual review and audit evidence.

Mapping the matrix across ISO/IEC 27001:2022, NIS2, DORA and GDPR

The classic mistake is creating four separate compliance workbooks. One control can satisfy several obligations if the responsibility and evidence are traceable.

ISO/IEC 27001:2022 provides the ISMS engine: context, interested parties, scope, leadership, risk treatment, objectives, operational control, performance evaluation and improvement. Annex A provides the practical control structure.

NIS2 Article 21 maps naturally to the same matrix through supply-chain security, incident handling, continuity, access control, asset management and secure acquisition. Article 20 makes the matrix board-relevant because management bodies must approve and oversee cybersecurity risk-management measures.

DORA turns the matrix into an ICT third-party risk tool. Articles 5, 6 and 8 require governance, documented ICT risk management and identification of assets, functions and dependencies. Articles 17 to 19 require incident detection, classification, escalation, communication and reporting. Articles 28 to 30 require third-party risk management, concentration risk analysis, contractual clauses, subcontracting controls, audit rights, termination rights and exit strategies.

GDPR contributes the personal data lens. Each cloud service row should identify whether personal data is processed, whether the provider is a processor or subprocessor, whether data location matters and what contract or DPA evidence exists.

NIST CSF 2.0 helps communicate the same matrix in outcome language. The GOVERN function addresses organizational context, legal and regulatory requirements, dependencies, risk management, roles, policies and oversight. GV.SC outcomes are especially useful for supplier cyber risk, including supplier roles, criticality, contractual requirements, due diligence, monitoring, incident coordination and termination planning.

COBIT 2019 adds an assurance and governance lens. It asks whether accountability, management practices, ownership, monitoring and issue remediation are repeatable and evidenced.

Building the matrix from register to proof

Imagine a SaaS company using a hyperscale IaaS platform, a managed database, a third-party identity provider, a customer support SaaS platform and an external SIEM. The implementation flow is straightforward.

Step 1: Start with the Cloud Services Register

Use Cloud Usage Policy or Cloud Usage Policy - SME as the trigger. Record each cloud service, owner, purpose, data categories, location, business function, supplier tier, contract owner and review date.

If the service stores customer records, authentication logs or support tickets, mark it as privacy relevant. If it supports production availability, mark it as operationally critical. If it supports a financial customer’s critical or important function, mark it as DORA relevant.

Step 2: Add shared responsibility domains

For each service, define responsibilities across core domains.

Step 3: Link controls to risk and the Statement of Applicability

Zenith Blueprint, Risk Management phase, Step 13, explains the traceability requirement:

“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.”

For example, the risk “unauthorised access to customer production data through cloud misconfiguration” may map to access control, cloud use, logging, cryptography, vulnerability management and supplier agreements. The SoA can reference ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 and 8.24, with notes for GDPR Article 32, NIS2 Article 21 and DORA ICT risk management where applicable.

Step 4: Attach evidence before audit season

Evidence should be designed into the matrix, not collected in panic.

The evidence list turns responsibility into proof. It also helps commercial teams answer enterprise due diligence faster because they can show not only certifications, but control ownership and operating evidence.

Subprocessors: the blind spot in most matrices

Subprocessors are where shared responsibility becomes real supply-chain risk.

A SaaS provider may be your processor under GDPR. That provider may rely on a cloud hosting provider, CDN, analytics service, support platform, email delivery service, managed database, observability provider and payment processor. Some may access personal data. Some may support critical service delivery without directly viewing data. Some may be outside the EU. Some may be replaceable. Others may create concentration risk.

DORA Article 29 requires concentration risk assessment for critical or important ICT services, including substitutability, multiple arrangements with the same or connected providers, subcontracting chains, third-country subcontractors, insolvency law, data recovery constraints and Union data protection enforceability. DORA Article 30 requires contractual provisions around subcontracting conditions, locations, data processing and storage, access and recovery, incident assistance, cooperation with authorities, audit rights, termination and exit.

NIS2 Article 21 similarly requires supply-chain security for direct suppliers and service providers, plus consideration of supplier-specific vulnerabilities, supplier cybersecurity practices and secure development procedures.

That is why Clarysec treats subprocessor mapping as a required extension of supplier governance, not a privacy-only list. The subprocessor register should show which supplier uses the subprocessor, which service depends on it, whether personal data is processed, whether it supports a critical function, processing region where relevant, contractual flow-down, approval or objection rights, available assurance, monitoring method and exit option.

Zenith Blueprint, Controls in Action phase, Step 23 states:

“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.”

That is the level of proof auditors expect when they ask whether cloud responsibilities are controlled downstream.

How auditors test the same matrix

A strong cloud shared responsibility matrix survives multiple audit styles because it is built around ownership, enforceability and evidence.

The matrix is not the end goal. It is the map auditors use to test whether the governance system is real.

An ISO auditor may select a high-impact cloud access risk and trace it from risk register to SoA, then to access reviews, MFA evidence and monitoring alerts. A DORA assessor may select a critical ICT provider and ask for the exit test, subcontracting analysis and contractual audit rights. A GDPR reviewer may focus on deletion, data residency, breach notification and subprocessor transparency.

Common failure patterns

The most frequent shared responsibility failures are not exotic.

First, organizations rely on provider assurance reports without mapping them to customer responsibilities. A cloud provider may prove physical security, infrastructure resilience and platform controls, but not whether your storage bucket was private, IAM roles were least privilege or logs were enabled.

Second, contracts contain generic security language but no incident timelines, log access rights, audit rights, subcontracting limits, data return provisions or exit support. Zenith Blueprint, Controls in Action phase, Step 23 highlights typical supplier agreement areas such as confidentiality, access control, technical and organizational measures, incident timelines, right to audit, subcontractor controls and end-of-contract provisions.

Third, subprocessors are listed for privacy purposes but not linked to security, continuity or concentration risk. A downstream observability or support provider may never appear in the risk register even though its outage or breach could affect customer service delivery.

Fourth, the SoA says a control is applicable, but no one can produce operating evidence. Cloud logging may be marked implemented, but the organization cannot prove retention settings, access reviews, alert handling or provider log access commitments.

Fifth, incident response plans do not reflect provider dependency. If the provider notifies a platform incident, who assesses customer impact? Who determines whether NIS2, DORA or GDPR notification is required? Who contacts affected customers? What if the root cause is with a subprocessor?

Management accountability: why the board should care

NIS2 Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation and receive training. DORA Article 5 requires the management body to define, approve, oversee and be responsible for ICT risk management arrangements, including ICT third-party policies, continuity and recovery plans, audit plans, training and reporting channels.

This changes the purpose of the matrix. It is no longer only a security worksheet. It becomes evidence that management knows:

• Which cloud services support critical operations.
• Which third parties and subprocessors are material.
• Which obligations apply under customer contracts, GDPR, NIS2 and DORA.
• Which responsibilities are retained by the organization.
• Which provider commitments are contractually enforceable.
• Which gaps require funding, remediation or risk acceptance.

For SMEs, proportionality matters. A smaller entity does not need a heavyweight bureaucracy, but it still needs documentation, monitoring, resilient systems, detection of ICT risk sources, key third-party dependency identification, continuity measures, testing, lessons learned and periodic review where in scope.

The matrix is one of the most efficient proportional tools because it consolidates obligations instead of multiplying them.

A 30-day sprint to make your cloud model audit-ready

If you cannot answer who owns each cloud control, what evidence proves it and which subprocessor could affect it, your shared responsibility model is still a diagram, not a governance artefact.

A practical 30-day sprint looks like this:

1. Create or update the Cloud Services Register using Cloud Usage Policy or Cloud Usage Policy - SME.
2. Identify critical services, personal data processing, customer-facing systems and DORA or NIS2 relevance.
3. Build the first matrix around ISO/IEC 27001:2022 Annex A controls 5.20, 5.21 and 5.23 using Zenith Controls.
4. Link each row to the risk register and Statement of Applicability using Step 13 of Zenith Blueprint.
5. Validate supplier and processor clauses using Third party and supplier security policy, Third-Party and Supplier Security Policy - SME and Data Protection and Privacy Policy.
6. Add log retention, incident escalation, subprocessor approval, audit rights and exit evidence.
7. Review critical suppliers annually, and after major changes, incidents, new subprocessors or audit findings.

The goal is simple. When the customer, auditor, regulator or board asks “who owns this control?”, you do not search across contracts, tickets and folders. You open the matrix, show the owner, show the clause, show the evidence and show the trail downstream.

Clarysec can help you turn cloud provider assurance packs into an integrated shared responsibility matrix for ISO/IEC 27001:2022 audits, NIS2 readiness, DORA ICT third-party risk, GDPR accountability and enterprise customer due diligence.

Start with the register. Build the matrix. Attach the evidence. Then use it as your board-ready proof that cloud risk is not outsourced, it is governed.