Cloud Audit Evidence for ISO 27001, NIS2 and DORA

Maria, the CISO at a fast-growing financial analytics company, had six weeks before three deadlines converged. Her ISO 27001:2022 surveillance audit was already scheduled. NIS2 had pushed the company into a new level of management accountability as an important entity. DORA was about to test whether her fintech operations could prove digital operational resilience. At the same time, a major enterprise client was holding a contract until her team could pass a detailed security assurance review.

The company was not insecure. It ran production workloads in AWS and Azure, used Microsoft 365 and several critical SaaS platforms, enforced MFA, backed up data, scanned vulnerabilities and collected cloud logs. The problem was proof.

Evidence was scattered across Slack screenshots, developer wiki pages, cloud console exports, procurement folders, legal contracts and verbal assurances from platform owners. When an auditor asked, “Show me how you control your cloud environment,” a link to a cloud provider’s compliance page would not be enough. The provider’s certificates proved the provider’s controls. They did not prove Maria’s side of the shared responsibility model.

That is where many cloud security audit evidence programs fail. Not because controls are absent, but because the organization cannot prove, in a structured and traceable way, which responsibilities belong to the provider, which belong to the customer, how SaaS and IaaS controls are configured, how supplier commitments are enforced, and how evidence is retained for auditors, regulators and customers.

Cloud compliance is no longer a technical appendix. For a SaaS provider under NIS2, a financial entity under DORA, or any ISO 27001:2022 organization using IaaS, PaaS and SaaS, cloud governance is part of the ISMS scope, risk treatment plan, supplier lifecycle, incident process, privacy accountability and management review.

The practical goal is simple: build one regulator-ready cloud evidence architecture that answers ISO 27001:2022, NIS2, DORA, GDPR, customer assurance and internal audit questions without rebuilding evidence for every framework.

Cloud is always in scope, even when infrastructure is outsourced

The first audit trap is assuming that outsourced infrastructure is outside the ISMS. It is not. Outsourcing changes the control boundary, it does not remove accountability.

ISO/IEC 27001:2022 requires the organization to define its context, interested parties, ISMS scope, interfaces, dependencies and processes. In a cloud-first business, the identity provider, cloud hosting account, CRM, email platform, data warehouse, CI/CD pipeline, ticketing tool and backup service are often core business infrastructure.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint makes this point in the ISMS Foundation & Leadership phase, Step 2, Stakeholder Needs and ISMS Scope:

“If you outsource your IT infrastructure to a cloud provider, that doesn’t exclude it from scope; rather, you include the management of that relationship and the cloud assets as part of scope (because security of your data on the cloud is your concern).”

That statement is an audit anchor. Your scope should not say, “AWS is excluded because Amazon manages it.” It should say that information assets and processes related to services hosted on AWS are in scope, including management of cloud security controls, identity, logging, encryption, backup, supplier assurance and incident response.

For ISO 27001:2022, this supports clauses 4.1 to 4.4 on context, interested parties, scope and ISMS processes. For NIS2, it supports Article 21 expectations for risk analysis, incident handling, business continuity, supply chain security, secure acquisition and maintenance, access control, asset management, cryptography, control effectiveness and MFA where appropriate. For DORA, it supports the principle that financial entities remain responsible for ICT risk even when ICT services are outsourced.

The question is not whether your cloud provider is secure. The question is whether you govern your use of the provider, configure your side correctly, monitor the service, manage supplier commitments and retain evidence.

Shared responsibility must become shared evidence

Cloud providers explain shared responsibility. Auditors test whether you operationalized it.

In IaaS, the provider usually secures physical facilities, core infrastructure and the hypervisor. The customer controls identity, workload configuration, operating system hardening, application security, data classification, encryption settings, network rules, logging, backups, patching and incident response.

In SaaS, the provider controls most platform operations, but the customer still controls tenant configuration, users, admin roles, integrations, data sharing, retention, logging options and escalation procedures.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls treats ISO/IEC 27002:2022 control 5.23, Information security for use of cloud services, as a central cloud governance control with preventive intent across confidentiality, integrity and availability. It links cloud services to supplier relationships, secure information transfer, asset inventory, data leakage prevention, endpoint and network security, and secure development practices.

A key Zenith Controls interpretation states:

“Cloud service providers (CSPs) function as critical suppliers, and thus all controls regarding supplier selection, contracting, and risk management under 5.19 apply. However, 5.23 goes further by addressing cloud-specific risks, such as multi-tenancy, data location transparency, and shared responsibility models.”

That distinction is critical. Supplier certificates alone do not satisfy Annex A.5.23. You need customer-side evidence that proves the cloud service is governed, configured, monitored and reviewed.

This is the difference between having cloud controls and having audit-ready cloud controls.

Start with a Cloud Services Register that auditors can use

The fastest way to improve cloud audit readiness is to create a complete Cloud Services Register. It should not be a procurement list or finance export. It must connect cloud services to data, owners, regions, access, contracts, criticality, regulatory relevance and evidence.

Clarysec’s SME Cloud Usage Policy-sme Cloud Usage Policy-sme gives a compact and audit-friendly baseline in clause 5.3:

“A Cloud Service Register must be maintained by the IT provider or GM. It must record: 5.3.1 The name and purpose of each approved cloud service 5.3.2 The responsible person or team (Application Owner) 5.3.3 The types of data stored or processed 5.3.4 The country or region where data is stored 5.3.5 User access permissions and administrative accounts 5.3.6 Contract details, renewal dates, and support contacts”

For enterprise environments, Clarysec’s Cloud Usage Policy Cloud Usage Policy establishes the broader mandate:

“This policy establishes the organization’s mandatory requirements for the secure, compliant, and responsible use of cloud computing services across Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) delivery models.”

The Cloud Usage Policy requires a centralized register owned by the CISO and approved baseline configurations for cloud environments. That register becomes the evidence foundation for several obligations at once.

For ISO 27001:2022, it supports asset inventory, cloud usage governance, supplier relationships, access control, legal and contractual requirements, risk treatment and documented information. For NIS2, it supports supply chain security, asset management, risk analysis, incident handling and continuity. For DORA, it supports ICT asset and dependency mapping, ICT third-party registers, critical or important function mapping and concentration risk analysis. For GDPR, it identifies whether personal data is processed, where it is located, which provider acts as processor, and which transfer or data processing terms apply.

If the register does not identify data categories and regions, privacy and resilience evidence will be incomplete. If it does not identify application owners, access reviews will be orphaned. If it does not identify contracts and renewal dates, supplier security clauses cannot be tested.

Turn ISO 27001:2022 into a cloud evidence spine

ISO 27001:2022 is the best spine for cloud evidence because it links business context, risk, controls, operational proof, monitoring and improvement.

Key cloud-relevant ISO 27001:2022 requirements include:

• Clauses 4.1 to 4.4 for context, interested parties, ISMS scope, interfaces, dependencies and processes.
• Clauses 5.1 to 5.3 for leadership, policy, roles, responsibilities and accountability.
• Clauses 6.1.1 to 6.1.3 for risk assessment, risk treatment, Annex A comparison, Statement of Applicability and residual risk acceptance.
• Clause 7.5 for controlled documented information.
• Clauses 8.1 to 8.3 for operational planning, risk assessment execution and risk treatment execution.
• Clauses 9.1 to 9.3 for monitoring, measurement, internal audit and management review.
• Clause 10 for nonconformity, corrective action and continual improvement.

The Annex A controls that carry the most cloud evidence weight include A.5.19 Information security in supplier relationships, A.5.20 Addressing information security within supplier agreements, A.5.21 Managing information security in the ICT supply chain, A.5.22 Monitoring, review and change management of supplier services, A.5.23 Information security for use of cloud services, A.5.24 to A.5.27 incident management, A.5.29 Information security during disruption, A.5.30 ICT readiness for business continuity, A.5.31 Legal, statutory, regulatory and contractual requirements, A.5.34 Privacy and protection of PII, A.5.36 Compliance with policies, rules and standards for information security, A.8.8 Management of technical vulnerabilities, A.8.9 Configuration management, A.8.13 Information backup, A.8.15 Logging, A.8.16 Monitoring activities, A.8.24 Use of cryptography, A.8.25 Secure development life cycle, A.8.29 Security testing in development and acceptance, and A.8.32 Change management.

In Zenith Blueprint, the Controls in Action phase, Step 23, explains cloud services in language that resonates with auditors:

“The shift to cloud services introduces profound changes to the trust model. You no longer control the server, the network perimeter, or the hypervisor. Often, you don’t even know where the data physically resides. What you do control, and what this control enforces, is the governance of that relationship, the visibility into what you’re using, and the security expectations you place on your providers.”

A strong Statement of Applicability entry for A.5.23 should not say only “Applicable, cloud provider certified.” It should explain why the control applies, which risks it treats, how it is implemented and where evidence is stored.

Add an evidence location column to the SoA or control tracker. Auditors should not need to search email, ticketing systems and shared drives to find proof.

Use one evidence model for ISO 27001:2022, NIS2 and DORA

NIS2 and DORA both require documented, risk-based, management-led cybersecurity. The overlap is substantial, but the supervisory pressure is different.

NIS2 applies to many essential and important entities in the EU, including digital infrastructure providers, managed service providers, managed security service providers, banking, financial market infrastructures and digital providers. Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure acquisition and maintenance, vulnerability handling, control effectiveness assessment, cyber hygiene, training, cryptography, access control, asset management and MFA or secured communications where appropriate.

For cloud security audit evidence, NIS2 asks whether cloud and supplier risks are managed as part of service delivery risk. It also brings structured significant incident reporting, including early warning within 24 hours, incident notification within 72 hours and a final report within one month.

DORA applies from 17 January 2025 to many EU financial entities and creates uniform requirements for ICT risk management, major ICT incident reporting, digital operational resilience testing, information sharing and ICT third-party risk. For financial entities also identified under NIS2, DORA is treated as the sector-specific Union legal act for overlapping operational obligations.

For cloud, DORA is direct. Financial entities remain responsible for ICT risk when services are outsourced. They need ICT third-party strategies, contract registers, pre-contract assessments, due diligence, audit and access rights, termination triggers, concentration risk analysis, subcontracting controls and tested exit strategies.

Zenith Controls maps ISO/IEC 27002:2022 control 5.23 to EU NIS2 Article 21 and DORA Articles 28 to 31. It also points to supporting standards such as ISO/IEC 27017 for cloud security roles and monitoring, ISO/IEC 27018 for protection of PII in public cloud, ISO/IEC 27701 for privacy management in cloud processor relationships, ISO/IEC 27036-4 for cloud service monitoring and supplier agreements, and ISO/IEC 27005 for cloud risk assessment.

The practical implication is simple. Do not build separate evidence packs for ISO 27001:2022, NIS2, DORA and GDPR. Build one cloud evidence architecture with framework-specific mappings.

Supplier contracts are control evidence, not legal archives

Cloud audit evidence often breaks at the contract layer. Security has a vendor questionnaire. Legal has the MSA. Procurement has the renewal date. The DPO has the DPA. Nobody has a single view of whether the agreement includes the security clauses required by ISO 27001:2022, NIS2, DORA and GDPR.

Clarysec’s SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme states in clause 5.3:

“Contracts must include mandatory clauses covering: 5.3.1 Confidentiality and non-disclosure 5.3.2 Information security obligations 5.3.3 Data breach notification timelines (e.g., within 24–72 hours) 5.3.4 Audit rights or the availability of compliance evidence 5.3.5 Restrictions on further subcontracting without approval 5.3.6 Termination terms, including secure data return or destruction”

For audit consistency, translate those clauses into a contract review matrix. ISO 27001:2022 Annex A.5.20 expects security requirements to be agreed with suppliers. GDPR Article 28 requires processor terms covering confidentiality, security measures, assistance, sub-processors, deletion or return of data, and audit support. DORA Article 30 requires detailed contractual provisions for ICT third-party providers, including service descriptions, data location, security, incident assistance, cooperation with authorities, audit rights, access rights, termination and transition arrangements. NIS2 supply chain security also needs enforceable supplier cooperation.

Zenith Controls maps ISO/IEC 27002:2022 control 5.20 to supplier agreements and notes ties to 5.19 supplier relationships, 5.14 information transfer, 5.22 supplier monitoring, 5.11 return of assets and 5.36 compliance.

The key point is operationalization. If a cloud contract grants access to SOC 2 reports, auditors may ask whether you obtained the report, reviewed exceptions, tracked remediation and reassessed risk. If the contract promises breach notification, they may ask whether your incident playbook includes the supplier contact path and regulatory decision points. If subcontractor changes require approval or notice, they may ask whether sub-processor notifications are reviewed before acceptance.

A contract without review evidence is an archive. A contract linked to supplier risk, monitoring records and incident workflows is a control.

SaaS logging and configuration are common audit blind spots

Cloud findings often come from SaaS, not IaaS. Infrastructure teams usually have engineering owners, logging pipelines, baseline controls and change records. SaaS platforms are fragmented across sales, HR, finance, customer success, marketing and operations. Each can process sensitive or regulated data.

Clarysec’s Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme addresses this directly in clause 5.5:

“5.5 Cloud Services and Third-Party Logging 5.5.1 For platforms where logging is not under direct IT control (e.g., SaaS email), the following requirements apply: 5.5.1.1 Logging must be enabled and configured where available 5.5.1.2 Alerts must be routed to the IT Support Provider 5.5.1.3 Contracts must require providers to retain logs for at least 12 months and provide access upon request”

For enterprises, Cloud Usage Policy adds:

“Cloud services must be integrated into the organization’s SIEM for continuous monitoring.”

This requirement moves SaaS from “business tool” to “monitored information system.” Evidence should include logging setting exports, SIEM connector proof, alert rules, triage tickets, retention settings and administrative access reviews.

For critical SaaS, prepare evidence for admin account creation, suspicious logins, mass downloads, public sharing, MFA disabling, API token creation, external guest activity and privilege escalation. For IaaS, prepare CloudTrail or equivalent control plane logging, storage access logs, IAM changes, flow logs where appropriate, CSPM findings, vulnerability scans, patch evidence, encryption settings, backup status, network security group reviews and change tickets.

Zenith Controls audit methodology for control 5.23 notes that an ISO/IEC 27007-style audit may inspect AWS S3 bucket permissions, encryption, IAM policies and CloudTrail logging. A COBIT-oriented auditor may review alert configurations, DLP controls, Microsoft 365 Secure Score usage and change management logs. A NIST SP 800-53A perspective may test account management and monitoring, including whether cloud workloads are patched, scanned and monitored with the same rigor as internal systems.

Different auditors speak different dialects. Your evidence should be the same.

Build a regulator-ready evidence pack for one SaaS and one IaaS service

A practical workflow starts with one critical SaaS platform and one critical IaaS environment. For example, Microsoft 365 for collaboration and AWS for production hosting.

Step 1: Update the Cloud Services Register

For Microsoft 365, record purpose, owner, data types, region, admin accounts, contract, DPA, support contact, renewal date and criticality. For AWS, record the production account, regions, data categories, workloads, account owner, root account status, support plan, contract terms and linked business services.

Use the Cloud Usage Policy-sme fields as the minimum dataset. Add criticality, regulatory relevance and evidence location.

Step 2: Document shared responsibility

For Microsoft 365, customer responsibilities include user lifecycle, MFA, conditional access, guest sharing, retention labels, DLP where used, logging and incident escalation. For AWS, customer responsibilities include IAM, network rules, workload hardening, encryption configuration, backup, logging, patching and application security.

Attach provider shared responsibility documentation, then map each customer responsibility to a control owner and evidence source.

Step 3: Capture configuration evidence

For Microsoft 365, export or screenshot MFA and conditional access policies, admin roles, external sharing settings, audit logging, retention configuration and security score actions. For AWS, export IAM password policy, privileged MFA status, CloudTrail configuration, S3 public access block, encryption status, security group review, backup jobs and vulnerability scan status.

The Cloud Usage Policy requires cloud environments to comply with a documented baseline configuration approved by the Cloud Security Architect. Your evidence pack should include both the baseline and proof of alignment.

Step 4: Link supplier and privacy evidence

Attach the contract, DPA, sub-processor list, breach notification terms, audit assurance reports and data location evidence. If personal data is processed, record whether the provider acts as processor, how deletion is handled, how data subject request support works, and which transfer safeguards apply.

For DORA, identify whether the cloud service supports a critical or important function. If yes, link the evidence to the ICT third-party register, due diligence file, audit rights, exit plan and concentration risk review.

Step 5: Connect logging to incident response

Show that logs are enabled, routed, reviewed and used. Attach SIEM dashboards, alert rules and at least one closed alert ticket. Then map the workflow to NIS2 and DORA reporting decision points.

For NIS2, the incident process must support 24-hour early warning, 72-hour incident notification and a one-month final report for significant incidents. For DORA, the ICT incident process should classify incidents by affected clients, transactions, duration, downtime, geographic spread, data impact, service criticality and economic impact.

Step 6: Store evidence with discipline

Clarysec’s Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme clause 6.2 defines practical evidence discipline:

“6.2 Evidence Collection and Documentation 6.2.1 All evidence must be stored in a centralized audit folder. 6.2.2 File names must clearly reference the audit topic and date. 6.2.3 Metadata (e.g., who collected it, when, and from which system) must be documented. 6.2.4 Evidence must be retained for at least two years, or longer where required by certification or client agreements.”

The enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy states the objective:

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

A screenshot called “screenshot1.png” is weak evidence. A file named “AWS-Prod-CloudTrail-Enabled-2026-05-10-CollectedBy-JSmith.png” is stronger because it describes the system, control, date and collector. Metadata matters because auditors need to trust when evidence was collected, who collected it and from which system.

How auditors test the same cloud control

The strongest cloud evidence packs are designed for multiple audit lenses. ISO 27001:2022 auditors test whether the control is in the ISMS, risk assessment, risk treatment and SoA. NIST-oriented assessors test technical implementation. COBIT 2019 auditors test governance, supplier performance and process integration. Privacy auditors focus on processor obligations, data residency, breach readiness and data subject rights. DORA supervisory reviews focus on ICT third-party risk and resilience.

Zenith Controls includes these audit methodology differences for cloud services, supplier agreements and supplier monitoring. For 5.22, Monitoring, review and change management of supplier services, it highlights that auditors may inspect quarterly supplier review minutes, KPI reports, SOC report evaluations, change logs, risk assessments, supplier incidents and issue tracking. For 5.20, Addressing information security within supplier agreements, it highlights contract sampling for confidentiality, security obligations, breach notification, audit rights, subcontractor approval and termination terms.

Cross-compliance controls that carry the cloud audit load

A regulator-ready cloud evidence model is built around a small number of high-leverage controls. These controls carry much of the compliance load across ISO 27001:2022, NIS2, DORA, GDPR, NIST and COBIT 2019.

NIST SP 800-53 Rev.5 adds technical depth through account management, external system services, continuous monitoring, system monitoring and boundary protection. COBIT 2019 adds governance depth through supplier relationship management, supplier risk, data exchange, network security and change readiness.

Supporting ISO standards sharpen the evidence model. ISO/IEC 27017 provides cloud-specific guidance on shared roles, virtual machine configuration and customer activity monitoring. ISO/IEC 27018 focuses on protection of PII in public cloud. ISO/IEC 27701 extends privacy obligations into processor and controller operations. ISO/IEC 27036-4 supports cloud supplier agreements and monitoring. ISO/IEC 27005 for cloud risk assessment.

Management review must see cloud risk, not just cloud uptime

One of the most overlooked audit artifacts is management review. ISO 27001:2022 expects management review to consider changes, interested-party needs, performance trends, audit results, risk treatment status and improvement opportunities. NIS2 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. DORA requires the management body to define, approve, oversee and remain accountable for ICT risk management.

A quarterly cloud security and supplier dashboard should show:

• Number of approved cloud services.
• Critical cloud services and owners.
• Services processing personal data.
• Services supporting critical or important functions.
• Open high-risk cloud misconfigurations.
• MFA and privileged access review status.
• Logging coverage for critical SaaS and IaaS platforms.
• Supplier assurance reports received and reviewed.
• Contract exceptions and accepted risks.
• Cloud incidents, near misses and lessons learned.
• Backup and recovery test results.
• Concentration risk and exit plan status.

This dashboard becomes evidence for ISO 27001:2022 leadership and performance evaluation, NIS2 governance, and DORA management accountability.

Zenith Blueprint, in the Risk Management phase, Step 14, recommends cross-referencing regulatory requirements when implementing risk treatments and policies. It states that mapping key regulation requirements to ISMS controls is a useful internal exercise and “also impresses auditors/assessors that you’re not managing security in a vacuum but aware of legal context.”

That is the maturity regulators and enterprise customers expect.

Common cloud audit findings and how to avoid them

Across cloud audit readiness work, recurring findings are predictable:

1. The Cloud Services Register exists, but SaaS tools are missing.
2. Data location is not recorded or is copied from marketing pages rather than contract evidence.
3. MFA is enforced for employees but not all administrative or break-glass accounts.
4. Cloud logs are enabled but not reviewed, retained or connected to incident response.
5. Supplier SOC reports are archived but not assessed.
6. Contract clauses exist for new suppliers but not legacy critical services.
7. Sub-processor notifications are received by email but not risk assessed.
8. Backup jobs run successfully, but recovery tests are not evidenced.
9. Shared responsibility is understood by engineers but not documented for auditors.
10. The SoA marks cloud controls applicable but does not link to risk entries, evidence or owners.

These are traceability problems. The fix is to connect policy, risk, control, owner, evidence and review.

When Maria reached audit day, she no longer relied on scattered screenshots. She opened a central dashboard showing the Cloud Services Register, risk assessments, SoA entries, baseline configuration evidence, supplier review files, logging proof and DORA concentration risk review. When the auditor asked how cloud risks were governed, she showed the ISMS. When the auditor asked how services were configured securely, she showed the baseline and CSPM evidence. When the auditor asked about ICT third-party risk, she showed the contract review, supplier monitoring and exit planning.

The result was not a perfect environment. No cloud environment is perfect. The difference was that risk decisions were documented, evidence was defensible and accountability was visible.

Build your cloud evidence pack before the auditor asks

If your organization relies on SaaS, IaaS or PaaS, your next audit will not accept “the provider handles it” as a sufficient answer. You need to prove shared responsibility, customer-side configuration, supplier clauses, logging, incident readiness, resilience and management oversight.

Start with three practical actions this week:

1. Create or refresh your Cloud Services Register using Clarysec’s Cloud Usage Policy Cloud Usage Policy or Cloud Usage Policy-sme Cloud Usage Policy-sme.
2. Map your top five cloud services to ISO 27001:2022 Annex A controls, NIS2 Article 21, DORA ICT third-party obligations where applicable, and GDPR processor requirements.
3. Build a centralized evidence folder using the retention and metadata discipline from Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy or Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme.

Then use Zenith Blueprint Zenith Blueprint to place the work into the 30-step ISMS audit roadmap, and Zenith Controls Zenith Controls to validate cross-compliance mappings, supporting ISO standards and audit methodology expectations.

Clarysec can help you turn scattered cloud screenshots, supplier files and SaaS settings into a regulator-ready evidence pack that stands up to ISO 27001:2022 certification audits, NIS2 supervisory questions, DORA ICT third-party reviews and enterprise customer assurance demands.