CISO Due Diligence File: ISO 27001 Evidence for 2026

It is 08:17 on a Monday morning. Maria, the CISO of a fast-growing fintech SaaS provider, opens an email from the CEO: “Regulator request. Need evidence by Friday that we escalated the supplier risk before the outage, that the board understood the residual risk, and that our incident reporting decision was documented.”

Six weeks earlier, a critical cloud service provider suffered regional degradation. No customer funds were lost. No personal data exfiltration was confirmed. But clients lost access to dashboards for hours, support tickets spiked, and one enterprise customer now wants proof that the company complied with NIS2, DORA and GDPR Article 32 security obligations.

Maria knows the team acted responsibly. They warned management about concentration risk. They raised an exception when backup region testing slipped. They classified the event, consulted legal, updated customers, and opened corrective actions. But the question in 2026 is no longer only whether security acted responsibly.

The question is whether the CISO can prove, with timestamped evidence, that risks were identified, communicated, tracked, accepted by the right owner, and followed through.

That proof is the CISO due diligence file.

For CISOs, compliance managers, auditors and business owners, the due diligence file is not a private paperwork bunker. It is the operational evidence layer that connects ISO/IEC 27001:2022, NIS2 management accountability, DORA governance and ICT risk management, and GDPR Article 32 security of processing into one coherent story. Done well, it shows that the security leader gave clear advice, management made informed decisions, and the organization’s controls were not merely declared, but operated, reviewed and improved.

Why CISO due diligence matters in 2026

The regulatory landscape has shifted from policy statements to demonstrable accountability. Vague assurances are no longer enough. Regulators, boards, customers and insurers increasingly ask for evidence of governance.

NIS2 places explicit responsibility on management bodies. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk management measures, oversee their implementation and complete cybersecurity training. Article 21 then expects appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene, training, cryptography, access control, asset management and authentication.

For covered financial entities, DORA raises the bar further. Article 5 makes the management body ultimately responsible for ICT risk management. Article 6 requires a sound, comprehensive and well-documented ICT risk management framework. DORA also requires incident classification and reporting, digital operational resilience testing, internal audit for non-microenterprises, remediation tracking and ICT third-party governance. DORA applies from 17 January 2025 and, for covered financial entities, operates as the sector-specific Union legal act for overlapping NIS2 risk management and reporting obligations.

GDPR adds a separate but connected accountability lens. Article 5(2) requires controllers to be responsible for, and able to demonstrate, compliance with data protection principles. Article 32 requires appropriate technical and organizational measures to ensure a level of security appropriate to risk. For SaaS, fintech and managed service organizations processing EU personal data, this means evidence must show how risks to confidentiality, integrity, availability and resilience were assessed and treated.

The personal concern for CISOs is understandable. If management accountability, regulator scrutiny, customer due diligence and litigation exposure converge after an outage or breach, a risk register alone will not be enough. The CISO needs a structured evidence file showing professional judgment, timely escalations, clear recommendations, dissent where needed, accepted risks and control assurance.

The due diligence file is not a shadow ISMS

A common audit mistake is treating the CISO due diligence file as a private archive separate from the ISMS. That creates two risks. First, evidence becomes inconsistent. Second, it can look like the CISO knew about risks but failed to integrate them into governance.

Clarysec’s approach is different. The CISO due diligence file is a curated view of ISMS evidence that matters for management accountability. It does not replace the risk register, Statement of Applicability, incident register, supplier register, audit reports or management review minutes. It indexes them, links them and makes them defensible.

The Zenith Blueprint: An Auditor’s 30-Step Roadmap provides the practical foundation. In the ISMS Foundation and Leadership phase, Step 4 emphasizes that the ISMS Manager or Security Officer coordinates implementation, audits and awareness, and “must have direct access to top management to escalate issues.” It also notes that risk owners should be designated for major risks and that the organization should define who signs off risk treatment decisions.

That is the first principle of CISO due diligence: the security leader advises and escalates, but risk ownership and acceptance must be explicit.

In the Risk Management phase, Step 13 of Zenith Blueprint makes this operational:

Risk treatment decisions and the SoA should be reviewed and approved by top management. It’s often done in a meeting or at least via sign-off. Ensure to brief management on:

✓ The key risks and proposed treatments, ✓ Any risks you suggest to accept (they should formally accept them), ✓ The list of controls you plan to implement (SoA highlights). Management’s approval shows that the organization is aware of and committing to the needed actions (this will also be documented evidence for the audit).

For a CISO, that guidance is not just ISO audit preparation. It is due diligence architecture. If a high risk is accepted, deferred or underfunded, the file should show the risk, recommendation, business decision, approving role, risk appetite reference and review date.

ISO 27001:2022 is the evidence engine

ISO 27001 is more than a certification target. It is an operating model for governance, risk treatment, assurance and continual improvement. Clause 0.1 states that an ISMS is intended to be integrated into the organization’s processes and overall management structure. That integration is what turns routine security work into a reliable evidence-generation engine.

The core ISO 27001:2022 clauses that feed the CISO due diligence file are:

• Clauses 4.1 to 4.2, context and interested parties, which document legal, regulatory, contractual and stakeholder obligations.
• Clause 4.3, ISMS scope, which defines the services, locations, systems and boundaries covered.
• Clause 5.1, leadership and commitment, which requires top management to support the ISMS and ensure it achieves intended outcomes.
• Clause 5.3, organizational roles, responsibilities and authorities, which supports clear risk ownership and escalation paths.
• Clauses 6.1.2 and 6.1.3, information security risk assessment and risk treatment, which require consistent risk criteria, risk owner approval, treatment plans, residual risk acceptance and the Statement of Applicability.
• Clause 8.1, operational planning and control, which requires the organization to plan, implement and control processes needed to meet ISMS requirements.
• Clauses 9.2 and 9.3, internal audit and management review, which generate independent assurance and leadership oversight evidence.
• Clause 10.1, continual improvement, and clause 10.2, nonconformity and corrective action, which show follow-through.

This systematic approach ensures that the evidence Maria’s CEO needs is not created in panic. It already exists, if the ISMS has been designed to produce and preserve decision-grade records.

What belongs in a CISO due diligence file

A good due diligence file answers seven questions an auditor, regulator, board member or customer may ask after a disruption:

1. What did the CISO know?
2. When did they know it?
3. What advice did they give?
4. Who owned the risk?
5. What did management approve, reject, defer or accept?
6. How were controls tested or monitored?
7. What changed after incidents, audits, supplier warnings or exceptions?

The following structure works for SaaS providers, fintech firms, managed service providers, managed security service providers, digital infrastructure operators and technology suppliers supporting regulated customers.

This file is especially important for NIS2 sectors such as cloud computing, data centres, content delivery networks, managed service providers, managed security service providers, public communications providers and certain financial infrastructure entities. NIS2 scope depends on sector, entity type and size, with Member States required to establish lists of essential and important entities. Even organizations outside direct scope may face contractual flow-down from customers that are in scope.

For DORA, the file should distinguish whether the organization is the regulated financial entity, an ICT third-party service provider, or both in different relationships. Financial entities must maintain governance, ICT risk management, incident reporting, resilience testing and third-party risk controls. ICT providers will increasingly be asked to support evidence, audit rights, incident assistance, testing and exit planning.

The Clarysec policy backbone for defensible records

The due diligence file lives or dies by record quality. Clarysec policies are written to make that record trail normal business practice, not an emergency response to a regulator letter.

For SMEs, [P02S] Governance Roles and Responsibilities Policy-sme - SME states in clause 5.5:

All significant security decisions, exceptions, and escalations must be recorded and traceable.

For enterprises, [P02] Governance Roles and Responsibilities Policy states in clause 6.5:

All escalations shall be logged and tracked, with evidence of resolution or formal acceptance.

Together, those clauses define the evidentiary standard. A material vulnerability, supplier dependency, control delay or repeated exception should not live only in chat messages or memory. It must be recorded, assigned, tracked and closed through resolution or formal acceptance.

Risk acceptance requires the same discipline. [P06S] Risk Management Policy-sme - SME requires in clause 5.1.2:

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

The same SME policy adds in clause 7.2.1:

Any decision to accept or defer treatment of a high or medium risk must be documented in the Risk Register. This documentation must include:

For larger organizations, [P06] Risk Management Policy states in clause 6.3.4:

Risks accepted without treatment shall be justified in writing, linked to the organization’s risk appetite, and approved at the appropriate level.

In a NIS2 or DORA context, this matters because management bodies are expected to approve, oversee and understand cybersecurity and ICT risk decisions. In a GDPR Article 32 context, it helps demonstrate that security measures were selected, deferred or adjusted through a documented risk-based process.

Incident evidence must be equally structured. [P30S] Incident Response Policy-sme - SME requires:

All incident investigations, findings, and corrective actions must be recorded in an incident register maintained by the General Manager.

[P30] Incident Response Policy requires:

All incidents must be recorded in the Security Incident Management System (SIMS), including:

These clauses support NIS2 staged reporting and DORA ICT incident governance. NIS2 requires early warning within 24 hours for significant incidents, notification within 72 hours, and a final report within one month after the incident notification. DORA requires formal ICT incident management, classification by severity and impacted service criticality, escalation to senior management, management body awareness, client communication where required and staged reporting for major ICT-related incidents.

Audit evidence also needs integrity. [P33S] Audit and Compliance Monitoring Policy-sme - SME states:

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

[P33] Audit and Compliance Monitoring Policy states:

All audit activities shall be documented and retained in the ISMS repository.

Finally, [P01] Information Security Policy gives leadership reporting a practical home. Clause 4.2.4 states:

Reports ISMS status, incidents, audit results, and metrics to Top Management.

That clause supports the due diligence principle that incident status, metrics, audit outcomes and unresolved risks must reach top management in a form that supports oversight.

Zenith Controls as a cross-compliance compass

Clarysec’s Zenith Controls: The Cross-Compliance Guide helps CISOs connect ISO/IEC 27002:2022 controls to broader compliance expectations. It is not a separate control framework. It is Clarysec’s cross-compliance guide for understanding how ISO/IEC 27001:2022 Annex A and ISO/IEC 27002:2022 controls support other obligations, audits and evidence requests.

For the CISO due diligence file, three control areas are central.

ISO/IEC 27002:2022 control 5.4, Management responsibilities, is a preventive governance control supporting confidentiality, integrity and availability. Zenith Controls places it in the Identify concept, with governance as the operational capability and governance plus ecosystem as security domains. The practical message is clear: management accountability is not symbolic. It requires assigned roles, resources, policy leadership, oversight and follow-up.

Zenith Controls ties 5.4 directly to 5.2 Information security roles and responsibilities, 5.1 Policies for information security, 5.35 Independent review of information security, 5.36 Compliance with policies, rules and standards for information security, and 5.8 Information security in project management. A due diligence file that contains escalations but no evidence of role assignment, policy approval, independent review or project integration will look incomplete.

Control 5.35, Independent review of information security, is also central. Zenith Controls describes it as preventive and corrective, tied to information security assurance. It connects to 5.36 compliance monitoring, 5.4 management responsibilities, 5.27 learning from information security incidents, 5.33 protection of records, and technical evidence such as 8.15 logging and 8.16 monitoring activities. In due diligence terms, independent review proves management did not rely only on self-attestation from the security team.

Control 5.36, Compliance with policies, rules and standards for information security, provides the enforcement layer. Zenith Controls ties it to policies, disciplinary process, independent review, roles, event assessment, logging, monitoring, protection of records and contact with special interest groups. For a CISO, this means the file should not only show that a policy exists. It should show adherence monitoring, non-compliance reporting and corrective action.

Cross-compliance mapping: one evidence file, many lenses

The most efficient due diligence file maps the same evidence to multiple obligations. This avoids duplicate compliance programs and reduces the risk of contradictory narratives.

NIST CSF 2.0 is useful because it gives a common language for governance, supply chain risk, operational resilience, incident management and recovery. Its GOVERN function covers organizational context, legal and regulatory obligations, risk appetite, roles, policy and oversight. Its CSF Profiles method supports current-state assessment, target-state definition, gap analysis and prioritized action planning. This aligns naturally with the Clarysec due diligence approach: scope the file, gather evidence, map obligations, identify gaps, implement actions and update continuously.

A practical risk escalation packet

Consider a SaaS provider whose authentication service depends on a single cloud identity provider. The CISO identifies a high-impact availability and access control risk: if the identity provider suffers a major outage, customers cannot log in, privileged access workflows may be delayed, and incident response may be impaired.

A defensible risk escalation packet should contain five parts.

First, create the risk entry. Use the Risk Management Policy-sme - SME requirement that each risk entry include description, likelihood, impact, score, owner and treatment plan. The entry should identify affected assets and services, including the customer portal, admin console, support tooling and emergency access process. It should record CIA impact, likelihood, impact, risk score, risk owner, proposed treatment, residual risk, target date and budget.

Second, link the treatment to the Statement of Applicability. Relevant controls may include supplier security, cloud service management, identity and access control, privileged access, monitoring, incident planning, business continuity readiness, backup and logging. This follows Zenith Blueprint Step 13, where risk treatment decisions and the SoA are reviewed and approved by top management.

Third, prepare the CISO advisory memo. The memo should answer what can go wrong, which regulated services or customer commitments may be affected, what the NIS2, DORA and GDPR implications are, what treatment is recommended, what the cost and timeline are, and what residual risk remains if management defers.

Fourth, record the management decision. If management approves treatment, retain the signed decision, budget approval and implementation plan. If management defers, the enterprise Risk Management Policy requires written justification linked to risk appetite and approval at the appropriate level. The file should show the CISO recommendation and the management decision as separate artifacts.

Fifth, add assurance evidence. Include break-glass account test results, supplier incident communication plan, contract review, SLA evidence, monitoring alert tests, tabletop exercise notes, corrective actions and internal audit findings. In Zenith Blueprint Step 23, Clarysec advises validating incident management capabilities by selecting a recent event or conducting a tabletop exercise, capturing and logging decisions, roles and communications, updating the plan with lessons learned, and confirming forensic evidence preservation procedures. That is exactly the evidence the file should preserve.

Incident decisions: proving the why behind reporting choices

After a cyber event, the most contested issue is often not the technical timeline. It is the reporting decision.

Was it significant under NIS2? Was it major under DORA? Was it a personal data breach under GDPR? Were customers or recipients notified? Who decided? Based on which facts?

The CISO due diligence file should include an incident decision record for every material event, even if the final decision is “not reportable.” That record should include:

• Date and time of awareness.
• Event summary and affected systems.
• Initial severity and business impact.
• Known or suspected malicious cause.
• Cross-border impact indicators.
• Personal data assessment.
• Client or service recipient impact.
• DORA major incident criteria analysis, if applicable.
• NIS2 significant incident criteria analysis, if applicable.
• Legal, DPO, compliance and management participants.
• Decision, rationale and approval.
• Follow-up triggers if facts change.

NIS2 defines significant incidents by severe operational disruption, financial loss or considerable material or non-material damage to other persons. DORA requires financial entities to record ICT-related incidents and significant cyber threats, classify incidents using criteria such as affected clients, downtime, geographic spread, data loss, criticality and economic impact, and escalate major incidents to senior management while informing the management body.

The due diligence file should preserve both the facts known at the decision point and the rationale for action or non-reporting. If facts later change, the file should show the reassessment.

Supplier warnings are where diligence is tested

Supply chain evidence is becoming one of the most important sections of the CISO file. NIS2 Article 21 requires supply chain security and expects organizations to consider supplier-specific vulnerabilities, product quality, cybersecurity practices and secure development procedures. Recital guidance encourages cybersecurity risk management measures in contracts with direct suppliers and service providers.

DORA is more prescriptive for financial entities. ICT third-party risk must be part of the ICT risk framework. Organizations must maintain a register of contractual arrangements, conduct pre-contract due diligence, assess concentration risk, consider subcontracting chains and third-country dependencies, include audit and access rights, define incident assistance, test exit strategies and maintain termination rights.

For the CISO, supplier warnings must be documented before the supplier fails. The file should include:

• Critical supplier inventory and service mapping.
• Supplier risk rating and rationale.
• Security questionnaires and evidence reviews.
• Contract gap analysis covering audit rights, incident notice, data location, subcontracting and exit.
• Concentration risk assessment.
• Known vulnerabilities or public advisories affecting the supplier.
• CISO recommendations to legal, procurement and management.
• Accepted gaps and compensating controls.
• Exit strategy test evidence for critical suppliers.

This aligns closely with NIST CSF 2.0 GV.SC, which covers supply chain risk management strategy, supplier roles, prioritization by criticality, contractual requirements, due diligence, ongoing monitoring, incident planning and end-of-relationship activities.

How auditors and regulators will read the file

Different reviewers approach the same evidence from different angles. A strong due diligence file anticipates those angles.

An ISO 27001 auditor will pay close attention to documented information supporting the risk assessment and treatment process. Clauses 6.1.2 and 6.1.3 require risk acceptance criteria, consistent assessments, risk owners, risk levels, prioritization, treatment plans, SoA comparison and residual risk acceptance. Clauses 8.1 to 8.3 require operational control, planned risk reassessment or reassessment after significant changes, and retention of results.

A NIS2 authority or customer assessor will look at management accountability and proportionality. They will ask whether measures were appropriate given risk exposure, size, likelihood, severity, societal or economic impact, state of the art and applicable standards.

A DORA-focused reviewer will look for governance traceability. Did the management body set ICT risk tolerance? Did it approve continuity and response plans? Were major incidents escalated? Was resilience testing risk-based and remediated? Were ICT third-party contracts and concentration risks managed?

A GDPR authority will focus on accountability and security of processing. It will ask whether personal data was classified, whether processing roles were understood, whether appropriate technical and organizational measures were implemented, and whether breach decisions were evidence-based.

Metrics that protect the organization and the CISO

Metrics are not decoration. In a due diligence file, they show whether the CISO gave management enough visibility to act.

Useful metrics include:

• High and medium risks accepted, overdue or without owner.
• Critical vulnerabilities outside SLA.
• Exceptions by age, business unit and approving role.
• Supplier risks by criticality and unresolved contract gaps.
• Incident mean time to detect, respond and recover.
• Reportability assessments completed within required decision windows.
• Backup and recovery test success rates.
• Access review completion and privileged access exceptions.
• Internal audit findings by severity and overdue corrective actions.
• Security awareness completion for management and staff.

These metrics support ISO 27001 leadership reporting, NIS2 training and oversight, DORA ICT risk reporting and GDPR accountability. They also protect the CISO by showing whether resource constraints, unresolved exceptions or repeated control failures were visible to management.

The due diligence file should preserve monthly or quarterly snapshots. Do not overwrite old dashboards without retaining evidence. If management saw a red metric and deferred treatment, that decision belongs in the file.

From audit-ready toolkit to CISO-ready evidence

In the Audit, Review and Improvement phase, Step 30 of Zenith Blueprint recommends compiling an Audit Ready Toolkit:

Bring together all key ISMS documents and records into a single repository or folder. This makes it easy during the certification audit to quickly retrieve whatever the auditor asks for.

The checklist includes the ISMS scope statement, policies, risk assessment report, risk register, risk treatment plan, Statement of Applicability, asset inventory, training records, operational records such as incident logs and access requests, internal audit reports, management review minutes, corrective actions and compliance obligation records.

The CISO due diligence file is a specialized layer inside that toolkit. It should not duplicate everything. It should index the evidence most relevant to professional judgment and management accountability.

A practical folder structure is:

• 00 Read Me and evidence index.
• 01 Role, authority and reporting line.
• 02 Compliance obligations and scope.
• 03 Management reports and advice.
• 04 Risk acceptances and exceptions.
• 05 Incident decisions and communications.
• 06 Supplier warnings and contract risks.
• 07 Control assurance and independent reviews.
• 08 Metrics and unresolved issues.
• 09 Management review and CAPA follow-up.
• 10 Legal hold, evidence integrity and metadata.

Each entry should have an owner, date, source system, related risk ID, related control, decision status and retention requirement. This implements the Clarysec evidence principle from the Audit and Compliance Monitoring Policy-sme - SME: metadata matters.

Start before the next incident

A CISO due diligence file is most valuable when it exists before the outage, breach, audit or regulator letter. Start with three actions this week.

First, create a CISO due diligence evidence index and map it to your ISO 27001 risk register, SoA, incident register, supplier register and management review pack.

Second, review your last three high or medium risks. Confirm that each has an owner, treatment plan, residual risk decision, risk appetite reference and approval evidence. If not, reopen the governance record.

Third, run a 90-minute tabletop exercise around a supplier outage or suspected data breach. Use Zenith Blueprint Step 23 to capture decisions, roles, communications and lessons learned, then file the evidence in your incident decision section.

Clarysec can help you operationalize this quickly. Our 30-step implementation method, policy suite and Zenith Controls cross-compliance mapping give you a defensible, audit-ready structure for ISO 27001 evidence, NIS2 management accountability, DORA governance and GDPR Article 32 security accountability.

To build your CISO due diligence file with confidence, start with the Zenith Blueprint, align your governance and risk records with Clarysec policies, and use Zenith Controls as your cross-compliance compass.