Control Self-Assessment for ISO 27001 Evidence

The 2026 audit problem is not missing controls, it is weak evidence

The video call blinked to life at 09:10 on a Monday. Sarah, CISO of a fast-growing FinTech SaaS company, looked at three stressed faces on her screen: the Head of GRC, the DPO and the Head of IT Operations.

The company had an ISO/IEC 27001:2022 surveillance audit approaching. The board wanted a NIS2 readiness briefing by Friday. A financial-services customer had added DORA-style ICT supplier questions to a contract renewal. The DPO was preparing evidence for GDPR accountability.

On paper, the organization looked mature. There was a risk register, a Statement of Applicability, access control procedures, incident response playbooks, backup policies, supplier due diligence forms and training records.

Then the evidence review began.

The access review spreadsheet had no named reviewer. A vulnerability scan report was current, but nobody could prove whether critical findings were remediated, accepted or still open. Supplier due diligence existed, but it predated a major cloud architecture change. Backup test screenshots were buried in a chat thread. Incident tabletop notes were useful, but not attributable. Engineers were forwarding configuration screenshots without context. Control owners were marking quarterly checks as “done,” but the evidence was inconsistent and difficult to reuse.

Sarah knew the problem was not the absence of controls. It was the absence of defensible, repeatable evidence.

That is the 2026 control self-assessment gap.

Organizations have documented controls, dashboards and sometimes continuous monitoring tools. But they often cannot prove that control owners test controls consistently, that evidence is complete and current, and that exceptions flow into corrective actions, management review and regulatory reporting.

Control self-assessment, or CSA, solves this operational gap. Done well, CSA creates a disciplined workflow where control owners periodically test control design and operating effectiveness, attach evidence that meets audit-quality criteria, record exceptions, assign corrective actions and provide management with a reliable view of control health.

At Clarysec, CSA is treated as the bridge between the ISMS, legal obligations and audit evidence. The Zenith Blueprint: An Auditor’s 30-Step Roadmap places this discipline in the Audit, Review & Improvement phase. Step 26, Audit Execution, says evidence gathering should include interviews, documentation review, observation, sampling and spot-checks:

✓ Interview relevant personnel: Ask people responsible for processes to explain how they meet the requirements.
✓ Review documentation: Check that documents and records exist and are current.
✓ Observe practices: If possible, do a direct observation.
✓ Sample and spot-check: You can’t check everything, so use sampling.

That thinking should not wait for the formal internal audit. CSA moves it upstream, into the hands of control owners, so the organization can prove every month or quarter that controls are not only written, but operating.

Why manual self-assessments fail under NIS2, DORA and GDPR

The old spreadsheet-and-email model of control self-assessment is broken because it rewards completion instead of evidence quality.

A control owner uploads a screenshot. Another writes “confirmed as per policy.” A third attaches a log export with no explanation of the system, period, reviewer or conclusion. The GRC team spends days rebuilding the story for auditors, customers and regulators.

This creates four recurring failures:

• Inconsistent evidence, where every owner has a different idea of valid proof.
• Weak attribution, where files do not show who collected evidence, when and from which source.
• Pencil-whipping, where overwhelmed teams attest that a control works without testing it.
• No reusability, where evidence collected for ISO/IEC 27001:2022 cannot easily support NIS2, DORA or GDPR without manual reinterpretation.

Modern regulation is unforgiving of that model.

NIS2 Article 20 makes cybersecurity risk management a management-body responsibility. Management must approve measures, oversee implementation and follow training. Article 21 requires appropriate and proportionate technical, operational and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, vulnerability handling, effectiveness assessment, cyber hygiene, access control, asset management and authentication.

The phrase “effectiveness assessment” is where CSA becomes essential. A NIS2 entity cannot credibly tell management that cybersecurity measures are effective if control owners are not testing them and documenting results.

DORA has raised the bar for financial entities since 17 January 2025. It creates a digital operational resilience regime covering ICT risk management, incident reporting, resilience testing, information sharing and ICT third-party risk. DORA Article 5 requires management-body responsibility for ICT risk arrangements, policies, roles, strategy, continuity plans, audit plans, third-party policies and corrective measures. Article 6 requires a documented ICT risk-management framework, regular review, internal audit for non-microenterprises and remediation of critical ICT audit findings. Articles 24 to 26 make resilience testing a recurring validation programme, including appropriate independence and, for certain entities, threat-led penetration testing.

CSA is not a replacement for DORA testing. It is the control-owner layer that makes DORA testing sustainable.

GDPR adds a related accountability pressure. Article 5(2) requires controllers to demonstrate compliance with the data protection principles. Article 32 requires appropriate security of processing, including confidentiality, integrity, availability, resilience, restoration and regular testing or evaluation where appropriate. For a DPO, CSA evidence is a practical way to demonstrate that access reviews, encryption, logging, retention, vendor oversight and incident handling are actually operating around personal data.

The Clarysec CSA model, from policy to proof

A defensible CSA programme starts with three questions:

1. Is the control designed correctly for the risk and obligation?
2. Did the control operate during the assessment period?
3. Is the evidence complete, current, attributable and reusable?

Clarysec anchors that model in policies, audit workflow and control mapping.

The Information Security Policy sets the expectation in clause 6.6.1:

All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.

Clause 6.6.2 adds:

Control Owners shall maintain test results, logs, and review records to support periodic audits.

That turns controls from static statements into active, measurable processes.

The Audit and Compliance Monitoring Policy - SME establishes the review discipline:

This policy establishes the organization’s approach to conducting internal audits, security control reviews, and compliance monitoring. It ensures that all controls, policies, systems, and service providers are subject to regular and structured review.

Clause 5.2.3 requires structure:

Each audit must include a defined scope, objectives, responsible personnel, and required evidence.

For CSA, that same logic applies at control-owner level. Every self-assessment should have scope, objective, responsible person, period, evidence and conclusion.

The Zenith Controls: The Cross-Compliance Guide then gives the mapping lens. For CSA, the most important ISO/IEC 27001:2022 Annex A control references include 5.2, Information security roles and responsibilities, 5.35, Independent review of information security, and 5.36, Compliance with policies, rules and standards for information security.

Together, these controls tell the CSA story. Someone must own the control. The organization must check whether policies and standards are followed. Independent review must challenge the system. CSA sits between ownership and independent review. It is not internal audit, but it prepares the evidence that makes internal audit faster and more reliable.

Test of design versus test of operating effectiveness

A common CSA mistake is asking control owners, “Is this control working?” without defining what “working” means.

Every credible assessment should separate test of design from test of operating effectiveness.

A test of design asks whether the control, if performed as described, would address the risk or requirement. For an access review, the design test checks whether the procedure defines scope, reviewer role, frequency, systems covered, exception handling, evidence retention and escalation.

A test of operating effectiveness asks whether the control actually operated during the period. For the same access review, the operating test checks whether the review occurred, who performed it, whether all in-scope systems were included, whether exceptions were resolved and whether records prove completion.

Both tests matter. A well-written backup policy is weak if no restoration tests occurred. A vulnerability scan that runs weekly is incomplete if critical findings do not flow into remediation or formal risk acceptance. A supplier review that happened once is no longer reliable if the supplier now supports a critical process and has changed subcontractors.

This distinction directly supports ISO/IEC 27001:2022 clauses 8.1 for operational planning and control, 9.1 for monitoring, measurement, analysis and evaluation, 9.2 for internal audit, 9.3 for management review and 10.2 for nonconformity and corrective action.

Evidence quality criteria for 2026 audits

Evidence is not audit-ready just because it exists. Evidence must be usable.

For CSA, evidence should be assessed against seven criteria.

The SME policy reinforces metadata discipline:

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

For higher-integrity investigations and digital evidence, the Evidence Collection and Forensics Policy - SME is more precise:

Each item of digital evidence must be logged with:
5.2.1.1. Collector’s name
5.2.1.2. Source system/device
5.2.1.3. Timestamp of collection
5.2.1.4. Storage location
5.2.1.5. Access history (who viewed or copied it)

A routine CSA record does not always need forensic chain-of-custody treatment. But every evidence item should be traceable enough that an auditor can understand who produced it, when, from where and why it proves the control.

The Legal and Regulatory Compliance Policy adds the cross-compliance requirement by calling for:

Required artifacts or records to demonstrate compliance (e.g., audit logs, encryption settings, consent documentation)

That is the key to reusable evidence. One encryption configuration export can support ISO/IEC 27001:2022 risk treatment, NIS2 Article 21 security measures, DORA protection of ICT assets and GDPR Article 32 security of processing, if the record is complete, attributable and mapped.

A hands-on CSA workflow using Clarysec’s toolkit

A control owner should be able to run a meaningful CSA session in a structured, repeatable way. The workflow below can be applied to privileged access, backup recovery, supplier monitoring, incident readiness, vulnerability management or independent review.

Step 1, select the control and obligation mapping

Start with the Statement of Applicability, risk treatment plan and legal obligation register. Choose one control, for example privileged access review for production systems.

Map it to relevant ISO/IEC 27001:2022 Annex A controls, such as 5.15 Access control, 5.16 Identity management and 5.18 Access rights. In Zenith Controls, connect it to 5.2 for roles and responsibilities and 5.36 for compliance with policies, rules and standards, because the review proves the access policy is being followed.

If the organization is under NIS2, map the evidence to Article 21 measures for access control, asset management, human resources security and authentication. If it is a DORA financial entity, map it to ICT risk governance, protection, monitoring and third-party requirements where relevant. If personal data is involved, map it to GDPR Article 5 integrity and confidentiality and Article 32 security of processing.

Step 2, define the test of design

Ask practical design questions:

• Does the procedure identify all in-scope systems?
• Does it cover privileged accounts, service accounts and emergency access?
• Is the reviewer independent from day-to-day provisioning where practical?
• Are frequency, escalation and exception rules defined?
• Is evidence retention defined?
• Are GDPR, DORA, NIS2 or customer-specific obligations included where relevant?

If the answer is no, record a design exception.

Step 3, perform the test of operating effectiveness

Select a sample and test actual operation. For a quarterly privileged access review, sample the latest completed review and high-risk users across critical systems. If the environment is small, test all privileged accounts. If it is large, use risk-based sampling with higher coverage for administrators, production systems, personal data systems and externally exposed platforms.

The enterprise Audit and Compliance Monitoring Policy supports:

Evidence collection through interviews, walkthroughs, and sampling

It also requires:

Documentation of the sampling strategy, audit scope, and limitations

Do not just attach evidence. Record why the sample was chosen, what population it represents and what was excluded.

A strong sample statement might read:

“Population: 42 privileged production accounts across cloud console, CI/CD platform and database administration. Sample: all 7 break-glass accounts, all 5 production database administrator accounts and 10 randomly selected privileged engineering accounts. Period: Q1 2026. Exclusions: third-party managed firewall accounts assessed under supplier access review CSA-TPR-04.”

That sentence gives an auditor population, risk logic, period and limitation.

Step 4, evaluate evidence quality

For each evidence item, capture:

• Evidence ID
• Control ID and control owner
• Assessment period
• Source system
• Collection date
• Collector
• Reviewer or approver
• Linked obligation
• Storage location
• Retention period
• Exceptions found
• Remediation ticket or CAPA reference

This transforms CSA from a subjective questionnaire into an evidence-based control test.

Step 5, record exceptions and corrective actions

If two privileged accounts lack documented business justification, do not hide the issue in notes. Create a finding, assign a risk rating, define an action, set an owner and agree a target date.

The SME policy requires:

All audit findings must be documented with risk ratings and proposed actions.

Then apply Zenith Blueprint Step 27, Audit Findings. The Blueprint recommends major nonconformity, minor nonconformity or observation categories, followed by root cause analysis. If service accounts were missed because the identity inventory excludes them, the root cause is not “reviewer error.” It is incomplete access inventory or unclear procedure scope.

Step 6, close through CAPA and verify effectiveness

Zenith Blueprint Step 29 recommends using a CAPA Log with issue description, root cause, corrective action, responsible owner, target date and status. It also emphasizes verifying effectiveness after completion.

If the corrective action is “update access review procedure to include service accounts,” the verification method should be practical: review the next access cycle and confirm service accounts are included, exceptions are resolved and evidence is retained.

That is how CSA becomes continual improvement instead of compliance theatre.

Cross-compliance mapping without four separate control programmes

The biggest efficiency gain is “test once, map many.”

Building separate testing processes for ISO/IEC 27001:2022, NIS2, DORA and GDPR creates duplicated evidence, inconsistent answers and exhausted control owners. A better approach is to use ISO/IEC 27001:2022 as the management system, CSA as the testing workflow and Zenith Controls as the cross-compliance guide.

NIST Cybersecurity Framework 2.0 is useful as an integration layer. Its GOVERN Function addresses legal, regulatory and contractual requirements, risk appetite, leadership accountability, policy governance and oversight. Its Organizational Profiles help organizations define current and target cybersecurity outcomes, analyse gaps and turn them into prioritized action plans.

COBIT 2019 and ISACA-style assurance thinking add another useful lens. They focus on governance objectives, process capability, accountability, metrics and management oversight. A COBIT-oriented reviewer will ask whether the process is defined, measured and improved, not just whether an artifact exists.

How different auditors will scrutinize your CSA evidence

The same CSA record will be interpreted differently depending on the auditor’s background. Designing evidence for those perspectives makes the programme more resilient.

For independent review, an ISO/IEC 27001:2022 auditor will look for the internal audit programme under clause 9.2, management review inputs under clause 9.3 and corrective action under clause 10.2. A DORA reviewer will look for risk-based testing, independence, remediation and management oversight. A NIS2 regulator will focus on whether management can prove the effectiveness of cybersecurity measures. A GDPR reviewer will ask whether evidence shows appropriate technical and organisational measures around real processing activities.

The point is not to rewrite evidence for each audience. The point is to collect it once with enough context to satisfy multiple lenses.

Management reporting that creates action, not noise

CSA results should not remain in control-owner spreadsheets. They should flow into management review.

In Step 28, Management Review, the Zenith Blueprint recommends inputs on changes in internal and external issues, changes in interested-party requirements, ISMS performance, audit results, monitoring and measurement, incidents, nonconformities, improvement opportunities and resource needs.

That is exactly where CSA belongs.

A useful CSA dashboard for executives should include:

• Control coverage by domain and critical process.
• Percentage of controls tested on schedule.
• Evidence quality score by control owner.
• Open exceptions by risk rating.
• Overdue corrective actions.
• Repeated findings and root causes.
• High-risk mappings for NIS2, DORA, GDPR and customer obligations.
• Supplier-related control exceptions.
• Incident, backup and resilience testing findings.
• Resource decisions needed from management.

Management does not need every screenshot. It needs to know whether the control environment is reliable, where risk is increasing, whether obligations are covered and where decisions are required.

This supports NIS2 Article 20 management accountability and DORA Article 5 management-body oversight. For GDPR, it helps the controller demonstrate that accountability is not a one-time document, but a living governance process.

Common CSA pitfalls and how to avoid them

The first pitfall is questionnaire-only CSA. A yes-or-no answer without evidence produces comfort, not assurance. Every material assertion should be supported by evidence.

The second pitfall is evidence without control context. A log export is meaningless unless it is tied to a control objective, period, source, owner and conclusion.

The third pitfall is weak exception discipline. If findings do not have risk ratings, owners, target dates and verification methods, CSA becomes a storage exercise. Zenith Blueprint Step 29 prevents this by linking nonconformities to root cause, corrective action, owner, target date and effectiveness verification.

The fourth pitfall is ignoring externally provided services. ISO/IEC 27001:2022 requires control over externally provided processes, products or services relevant to the ISMS. NIS2 includes supply-chain security. DORA requires ICT third-party risk management, registers, due diligence, contractual safeguards, concentration-risk assessment, audit rights and exit plans. NIST CSF 2.0 GV.SC outcomes similarly cover supplier roles, due diligence, contracts, monitoring, incident planning and termination. CSA must include supplier evidence, not just internal IT evidence.

The fifth pitfall is treating GDPR as a legal annex. If personal data is processed in a system, CSA should test whether security controls support integrity, confidentiality, availability, retention, access limitation and breach readiness.

The 2026 control owner checklist

Before submitting a CSA result, every control owner should be able to confirm the following:

• I know the control objective and linked risks.
• I know which ISO/IEC 27001:2022, NIS2, DORA, GDPR or contractual obligations the control supports.
• I tested design and operating effectiveness separately.
• I documented the population and sampling method.
• I attached evidence that is complete, current, attributable, authentic, relevant, retained and reusable.
• I recorded metadata for who collected evidence, when and from which system.
• I documented exceptions with risk rating and proposed actions.
• I identified root cause for material exceptions.
• I created or updated CAPA records with owner, due date and verification method.
• I escalated material issues for management review.

If a control owner cannot complete this checklist, the issue is not only a CSA weakness. It may be an ISMS monitoring weakness, a NIS2 effectiveness-assessment gap, a DORA ICT risk governance issue or a GDPR accountability weakness.

Make CSA part of your assurance operating model

Control self-assessment is not a replacement for internal audit, penetration testing, DORA resilience testing or GDPR legal review. It is the operational layer that makes all of them more reliable.

In 2026, organizations that pass audits with less disruption will not be the ones with the most policies. They will be the ones whose control owners can prove, with quality evidence, that controls are designed, operating, monitored, corrected and reported.

Clarysec helps organizations build that capability using the Zenith Blueprint, policy templates such as the Information Security Policy, Audit and Compliance Monitoring Policy, Audit and Compliance Monitoring Policy - SME, Evidence Collection and Forensics Policy - SME, Legal and Regulatory Compliance Policy, and the cross-compliance mapping power of Zenith Controls.

If your ISO/IEC 27001:2022 controls are documented but your evidence is scattered, inconsistent or not reusable for NIS2, DORA and GDPR, start with one high-risk domain this week. Run a CSA on privileged access, supplier security, incident readiness, vulnerability remediation or backup recovery. Test design, test operating effectiveness, score evidence quality, log exceptions and feed the result into management review.

Ready to turn control self-assessment into audit-ready assurance? Download the Zenith Blueprint, explore Zenith Controls, or request a Clarysec evidence readiness assessment to see where your control evidence will stand up and where it needs to improve.