Audit-Ready ISO 27001 Risk Assessment for NIS2 and DORA
The coffee on Sarah’s desk was cold.
As CISO of a rapidly scaling fintech, she was used to pressure. The company had just won a major banking partner, and the due diligence questionnaire on her screen should have been a formality. The first questions were familiar: provide the ISO/IEC 27001:2022 Statement of Applicability, share the latest risk register, explain the risk assessment methodology.
Then the questionnaire shifted.
Demonstrate how your risk management program addresses DORA. Explain your preparedness for the NIS2 Directive, including management accountability and supply chain risk measures. Provide evidence that critical ICT suppliers are assessed, monitored, and covered by incident response and business continuity plans.
By Monday morning, the same issue was on the board risk committee agenda. ISO 27001 certification audit in eight weeks. DORA pressure from financial-sector customers. NIS2 classification questions for a cloud-hosted service line expanding into the EU. Procurement said supplier reviews existed, but evidence was split across email, contract folders, and a vendor spreadsheet. Legal said the regulatory mapping was still in progress. Engineering said the risk register was mostly done.
The board asked the only question that mattered:
Can we prove that our risk assessment and risk treatment plan are enough?
That is the real problem for SaaS, fintech, managed service, cloud, and digital platform companies. Not whether a risk register exists. Not whether Annex A controls have been copied into a spreadsheet. The issue is whether the organization can demonstrate, under audit and customer pressure, that its ISO 27001 risk assessment process is repeatable, risk-based, approved by risk owners, linked to treatment actions, mapped to legal obligations, and operationally alive.
Done well, one ISO 27001 risk assessment and one risk treatment plan can support ISO/IEC 27001:2022 certification, NIS2 Article 21 cybersecurity risk-management measures, DORA ICT risk-management requirements, GDPR accountability, supplier assurance, incident readiness, and board reporting.
Done poorly, it becomes a spreadsheet auditors will dismantle in thirty minutes.
This guide shows how Clarysec builds audit-ready ISO 27001 risk assessment and risk treatment evidence using the Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec policies, and Zenith Controls: The Cross-Compliance Guide.
Why ISO 27001 Risk Assessment Is Now a Compliance Hub
The EU regulatory landscape is converging around a simple principle: cybersecurity risk must be governed, documented, tested, and owned.
ISO/IEC 27001:2022 already works this way. Clauses 4.1 to 4.4 require the organization to understand its context, interested parties, ISMS scope, and process interactions before assessing risk. Clauses 6.1.2 and 6.1.3 require a defined information security risk assessment and treatment process. Clauses 8.2 and 8.3 require the organization to perform risk assessments and implement the treatment plan while retaining documented information.
NIS2 and DORA make the same risk-based logic more urgent.
NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation, and follow cybersecurity training. Article 21 requires appropriate and proportionate technical, operational, and organizational measures to manage risks to network and information systems. Those measures include risk analysis, incident handling, business continuity, supply chain security, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management, and multifactor authentication or secured communications where appropriate.
DORA applies similar pressure to financial entities. Articles 5 and 6 require the management body to define, approve, oversee, and remain responsible for ICT risk-management arrangements. DORA expects a documented ICT risk management framework integrated into overall risk management, supported by policies, procedures, protocols, tools, internal audit, remediation, continuity, testing, incident management, and ICT third-party governance.
The conclusion is practical and unavoidable: the risk register is no longer a technical team worksheet. It is governance evidence.
Clarysec’s Enterprise Risk Management Policy makes this expectation explicit:
A formal risk management process shall be maintained in accordance with ISO/IEC 27005 and ISO 31000, covering risk identification, analysis, evaluation, treatment, monitoring, and communication.
From Enterprise Risk Management Policy, section “Governance Requirements,” policy clause 5.1.
The same policy defines the audit-ready outcome:
To maintain a centralized, version-controlled Risk Register and Risk Treatment Plan reflecting current risk status, control coverage, and mitigation progress.
From Enterprise Risk Management Policy, section “Objectives,” policy clause 3.3.
That phrase, “current risk status, control coverage, and mitigation progress,” is the difference between a static compliance file and a defensible risk program.
Start With Scope, Obligations, and Risk Criteria
Many weak ISO 27001 risk assessments start with a control checklist. That is backwards.
ISO 27001 requires the organization to determine context, interested-party requirements, ISMS scope, leadership responsibilities, and risk planning before selecting controls. ISO/IEC 27005:2022 reinforces this by advising organizations to identify the basic requirements of interested parties before assessing risk. Those requirements may come from ISO standards, sector regulations, national laws, customer contracts, internal policies, previous treatment activities, and supplier obligations.
For an EU-facing SaaS or fintech company, the risk process should begin with a compliance and obligation inventory.
| Requirement source | Why it affects ISO 27001 risk assessment | Evidence artifact |
|---|---|---|
| ISO/IEC 27001:2022 Clauses 4, 5, 6, 8, 9, and 10 | Defines context, leadership, risk assessment, risk treatment, operational control, performance evaluation, and improvement | ISMS scope, risk methodology, risk register, treatment plan, SoA, management review records |
| NIS2 Articles 20, 21, and 23 | Adds management accountability, all-hazards cybersecurity measures, and incident reporting expectations | Board approval, Article 21 mapping, incident reporting playbook, continuity evidence |
| DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30 | Requires ICT risk governance, continuity, backup and restoration, incident lifecycle, testing, and ICT third-party risk controls | ICT risk framework, BCP tests, incident register, resilience test records, ICT supplier register |
| GDPR Articles 3, 4, 5, 6, 9, 10, 25, 32, 33, and 34 | Requires accountability, lawful processing, data protection by design, appropriate security, and breach assessment | Data inventory, legal basis mapping, privacy risk entries, DPIA links, breach assessment records |
| Supplier and customer contracts | Converts commercial promises into risk criteria, controls, evidence, and deadlines | Contract register, due diligence records, audit rights, SLAs, exit clauses |
For SMEs, Clarysec’s Legal and Regulatory Compliance Policy - SME sets the starting point:
The GM must maintain a simple, structured Compliance Register listing:
From SME Legal and Regulatory Compliance Policy, section “Governance Requirements,” policy clause 5.1.1.
That simple register is a bridge between compliance and risk management. If it says GDPR applies because EU personal data is processed, NIS2 may apply because the organization provides digital or managed services, or DORA is relevant through financial-sector customers, those obligations must influence risk criteria and treatment priorities.
The Zenith Blueprint is direct on this point in the Risk Management phase, Step 10, “Establishing Risk Criteria and Impact Matrix”:
Also consider legal/regulatory requirements in your acceptance criteria. Some risks might be unacceptable regardless of likelihood due to laws.
From Zenith Blueprint, Risk Management phase, Step 10.
It also gives a practical rule for workshops:
“Any risk that could lead to non-compliance with applicable laws (GDPR, etc.) is not acceptable and must be mitigated.”
From Zenith Blueprint, Risk Management phase, Step 10.
For Sarah’s fintech, that changes the scoring model. A supplier API vulnerability may have low likelihood, but if exploitation could trigger a DORA major ICT-related incident, a NIS2 significant incident, GDPR breach assessment, customer SLA failure, or board-level escalation, the impact is high or critical. Compliance exposure becomes part of the risk logic, not a separate spreadsheet.
Build a Risk Register Auditors Can Test
Auditors do not only ask what your top risks are. They test whether your method is defined, repeatable, traceable, and followed.
They will ask:
- How did you identify these risks?
- Which assets, services, suppliers, data types, and processes were in scope?
- Which criteria were used for likelihood and impact?
- Who owns each risk?
- Which existing controls reduce the risk?
- Why was the treatment decision selected?
- Where is the evidence that treatment happened?
- Who approved the residual risk?
- When will the risk be reassessed?
Clarysec’s Risk Management Policy - SME captures the minimum audit-ready risk entry:
Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.
From SME Risk Management Policy, section “Governance Requirements,” policy clause 5.1.2.
For enterprise programs, the Zenith Blueprint Risk Management phase, Step 11, “Building and Documenting the Risk Register,” expands the structure. It recommends columns such as Risk ID, Asset, Threat, Vulnerability, Risk Description, Likelihood, Impact, Risk Level, Current Controls, Risk Owner, Treatment Decision, Treatment Plan or Controls, and Status.
A strong risk entry looks like this:
| Field | Example entry |
|---|---|
| Risk ID | R-042 |
| Asset or process | Client data processing through third-party payment API and production database |
| Threat | Exploitation of a critical vulnerability in supplier API or supporting cloud database service |
| Vulnerability | Limited visibility into supplier vulnerability management, incomplete restoration testing, and no tested supplier breach playbook |
| Risk description | A supplier or cloud service compromise could expose financial data, disrupt service, trigger regulatory reporting, and breach customer contracts |
| Current controls | SSO, role-based access, supplier contract, production logging, daily backups, quarterly access review |
| Likelihood | Medium |
| Impact | Critical |
| Risk level | Critical |
| Risk owner | CTO and Head of Platform Engineering |
| Treatment decision | Mitigate |
| Regulatory mapping | ISO 27001 Annex A supplier, cloud, incident, logging, access, continuity, backup, and legal compliance controls; NIS2 Articles 20, 21, and 23; DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28, and 30; GDPR Articles 32, 33, and 34 |
| Evidence | Supplier due diligence, audit rights request, restoration test report, SIEM monitoring rule, incident tabletop, updated SoA, management review minutes |
This is materially different from “Third-party risk, High, mitigate.” The audit-ready version links asset, threat, vulnerability, consequence, current controls, owner, regulation, evidence, and governance.
Turn Risk Treatment Into an Evidence Plan
A risk treatment plan must answer four operational questions:
- What will we do?
- Who owns it?
- When will it be done?
- How will we prove it reduced risk?
ISO/IEC 27001:2022 Clause 6.1.3 requires the organization to select treatment options, determine necessary controls, compare them with Annex A to avoid omissions, produce a Statement of Applicability, formulate a treatment plan, and obtain risk-owner approval for the plan and residual risks. Clause 8.3 then requires implementation of the treatment plan and retained documented information on results.
The Enterprise Risk Management Policy makes this practical:
The Risk Officer shall ensure that treatments are realistic, time-bound, and mapped to ISO/IEC 27001 Annex A controls.
From Enterprise Risk Management Policy, section “Policy Implementation Requirements,” policy clause 6.4.2.
The SME policy also clarifies that acceptance is not a shortcut:
Accept: Justify why no further action is required and record the residual risk.
From SME Risk Management Policy, section “Policy Implementation Requirements,” policy clause 6.1.1.
Acceptance must be justified against criteria, approved by the right owner, and monitored. Under NIS2 and DORA, unapproved residual risk can become a governance failure.
A complete treatment plan should contain these fields:
| Treatment field | Audit purpose |
|---|---|
| Risk ID | Links treatment back to the assessed risk |
| Treatment option | Shows rationale: mitigate, avoid, transfer, or accept |
| Selected controls | Connects risk to Annex A, policies, and technical safeguards |
| Regulatory driver | Shows NIS2, DORA, GDPR, contract, or customer relevance |
| Action owner | Proves accountability |
| Due date | Makes treatment time-bound |
| Implementation evidence | Shows that action was completed |
| Effectiveness measure | Shows whether likelihood or impact was reduced |
| Residual risk | Shows remaining exposure |
| Risk-owner approval | Proves acceptance and governance |
For Sarah’s R-042, the treatment plan becomes a cross-compliance action list.
| Risk ID | Treatment action | ISO/IEC 27001:2022 Annex A reference | NIS2 relevance | DORA relevance | Owner | Evidence |
|---|---|---|---|---|---|---|
| R-042 | Exercise supplier audit rights and request vulnerability management evidence | 5.19, 5.20, 5.21, 5.22, 5.31 | Article 21(2)(d) supply chain security | Articles 28 and 30 ICT third-party risk and contracts | CTO and Procurement Lead | Audit request, supplier response, contract review |
| R-042 | Implement enhanced monitoring for anomalous API and privileged activity | 8.15, 8.16, 5.16, 5.17, 5.18 | Article 21(2)(i) access control and asset management | Articles 6 and 17 ICT risk and incident management | SOC Manager | SIEM rule, alert test, access review |
| R-042 | Test backup restoration and define service-level RTO and RPO | 5.30, 8.13, 8.14 | Article 21(2)(c) business continuity and backup | Articles 11 and 12 response, recovery, backup, and restoration | Head of Platform Engineering | Restoration report, RTO and RPO approval |
| R-042 | Run a supplier breach tabletop exercise | 5.24, 5.26, 5.27, 5.29 | Articles 21(2)(b) and 23 incident handling and reporting | Articles 17, 18, 19, and 24 incident management, classification, reporting, and testing | CISO | Tabletop record, lessons learned, remediation tracker |
| R-042 | Update SoA and residual risk approval | 5.4, 5.31, 5.35 | Article 20 management accountability | Articles 5 and 6 governance and ICT risk framework | CISO and Risk Owner | Updated SoA, approval record, management review minutes |
This plan is powerful because it creates a direct line from one risk scenario to ISO 27001 controls, NIS2 obligations, DORA articles, owners, and evidence.
Make the Statement of Applicability Work Harder
The Statement of Applicability is often treated as a certification artifact. It should be more than that.
ISO/IEC 27001:2022 Clause 6.1.3 requires the SoA to include necessary controls, justification for inclusion, implementation status, and justification for exclusions. ISO/IEC 27005:2022 guidance reinforces the need to compare selected controls with ISO/IEC 27001 Annex A to avoid omissions.
In an audit-ready program, the SoA becomes the bridge between risk treatment and cross-compliance evidence. If a treatment plan requires MFA, logging, supplier monitoring, backup restoration, secure development, incident escalation, or cloud exit planning, the SoA should show that the relevant Annex A controls are included, justified, implemented or planned, and evidenced.
This also helps avoid a common audit failure: the risk register says one thing, the treatment plan says another, and the SoA is silent. When those artifacts disagree, auditors lose confidence quickly.
Mapping ISO 27001 Risk Treatment to NIS2, DORA, and GDPR
ISO 27001 does not replace NIS2, DORA, or GDPR. It gives you a structured mechanism to produce evidence for them.
The key is to build mapping into the risk process rather than bolt it on later.
| ISO 27001 risk treatment evidence | NIS2 relevance | DORA relevance | GDPR relevance |
|---|---|---|---|
| Risk criteria with regulatory impact scoring | Supports Article 21 proportionate cybersecurity risk-management measures | Supports Articles 4, 5, and 6 proportionality, governance, and ICT risk framework | Supports accountability and appropriate security |
| Risk register with owners and CIA impact | Supports Article 20 management oversight and Article 21 risk analysis | Supports documented ICT risk management and ownership | Supports demonstration of personal data risk awareness |
| Treatment plan mapped to Annex A | Supports Article 21 measures across incident, continuity, supplier, access, vulnerability, and secure development areas | Supports ICT controls, incident management, continuity, testing, and third-party resilience | Supports technical and organizational measures under Article 32 |
| Supplier risk entries and contract controls | Supports Article 21(2)(d) supply chain security | Supports Articles 28 and 30 ICT third-party risk and contract requirements | Supports processor and transfer safeguards where applicable |
| Incident scenarios and reporting playbooks | Supports Article 23 significant incident reporting workflow | Supports Articles 17, 18, and 19 incident management, classification, and reporting | Supports Articles 33 and 34 breach notification assessment |
| BCP, backup, and recovery treatments | Supports Article 21(2)(c) continuity, backup, disaster recovery, and crisis management | Supports Articles 11 and 12 response, recovery, backup, and restoration | Supports availability and resilience where personal data is involved |
| Control effectiveness reviews | Supports Article 21(2)(f) effectiveness assessment | Supports Article 24 testing and remediation expectations | Supports ongoing accountability |
This mapping is especially important where regulations overlap. DORA is the sector-specific ICT resilience regime for many financial entities, while NIS2 may remain directly relevant for certain providers, coordination, or entities outside DORA’s scope. A fintech may need DORA as its primary ICT resilience framework, while a managed service provider supporting that fintech may face NIS2 obligations directly.
The risk register must be able to show both sides of that dependency.
Use Zenith Controls as the Cross-Compliance Compass
Clarysec uses Zenith Controls as a cross-compliance guide to prevent the common failure where ISO controls, regulatory articles, and audit questions live in separate universes. It does not create a separate control framework. It maps ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control areas to other standards, audit expectations, and compliance perspectives.
For ISO 27001 risk assessment and treatment, these references are especially important:
| ISO/IEC 27001:2022 Annex A reference used in Zenith Controls | Why it matters for risk assessment and treatment | Attributes captured in Zenith Controls |
|---|---|---|
| 5.4 Management responsibilities | Connects risk treatment ownership to governance, role clarity, and accountability | Preventive control, supports confidentiality, integrity, and availability, maps to Identify, Governance, Governance and Ecosystem |
| 5.31 Legal, statutory, regulatory and contractual requirements | Connects the compliance register to risk criteria, treatment decisions, and SoA inclusion | Preventive control, supports confidentiality, integrity, and availability, maps to Identify, Legal and Compliance, Governance, Ecosystem, and Protection |
| 5.35 Independent review of information security | Connects internal audit, external audit, and management assurance to treatment effectiveness | Preventive and corrective control, supports confidentiality, integrity, and availability, maps to Identify and Protect, Information Security Assurance, Governance and Ecosystem |
The cross-compliance lesson is simple. If legal obligations are not in the risk assessment method, your scoring is incomplete. If scoring is incomplete, treatment priorities may be wrong. If priorities are wrong, the SoA and board reporting become unreliable.
The Zenith Blueprint makes the same point in Risk Management phase, Step 14, “Risk Treatment Policies and Regulatory Cross-References.” It advises organizations to create a mapping table listing key regulatory security requirements and corresponding controls or policies in the ISMS. This is not mandatory for ISO 27001 certification, but it is highly useful for demonstrating that security is being managed in legal and contractual context.
What Different Auditors Will Ask
A certification auditor, NIS2 reviewer, DORA-oriented customer, GDPR reviewer, NIST assessor, or COBIT practitioner may examine the same evidence but ask different questions.
| Auditor lens | Typical audit question | Evidence they expect |
|---|---|---|
| ISO 27001 auditor | Is the risk assessment method defined, repeatable, applied, and linked to treatment and the SoA? | Risk methodology, criteria, register, SoA, treatment plan, residual approvals |
| NIS2-oriented reviewer | Do cybersecurity measures cover Article 21 areas and management accountability? | Board approvals, Article 21 mapping, incident playbook, continuity evidence, supplier risk evidence |
| DORA-oriented reviewer | Is ICT risk management documented, governed, tested, and extended to ICT third parties? | ICT risk framework, incident classification process, BCP tests, resilience testing, ICT supplier register |
| GDPR reviewer | Can the organization demonstrate appropriate security and accountability for personal data risks? | Data inventory, legal basis mapping, breach assessment procedure, privacy risk treatment evidence |
| NIST-oriented assessor | Are risks identified, protected against, detected, responded to, and recovered from through measurable controls? | Risk scenarios, asset inventory, control implementation, monitoring, response and recovery records |
| COBIT or ISACA auditor | Is risk governance aligned to enterprise objectives, roles, performance, assurance, and management reporting? | Governance minutes, RACI, KRIs, internal audit findings, remediation tracking, management dashboards |
This is why evidence architecture matters. The same risk entry should be traceable from business objective to asset, threat, vulnerability, control, owner, regulatory driver, treatment action, test result, and management decision.
Clarysec policies are designed to support that architecture. The Enterprise Risk Management Policy states under the section “Reference Standards and Frameworks”:
Article 5: Mandates a documented ICT risk management framework, fully covered by this policy’s structure, including SoA mapping and KRIs.
This turns the policy from a static document into audit evidence showing that ICT risk governance has been intentionally designed with DORA in mind.
Common Findings That Break Risk Programs
When Clarysec reviews ISO 27001 risk assessment and risk treatment evidence, the same findings appear repeatedly.
First, risk criteria ignore legal, regulatory, contractual, supplier, and privacy impact. This causes weak scoring. A personal data breach or critical supplier failure may be rated Medium because likelihood is low, even though GDPR, NIS2, DORA, or customer impact should make it High or Critical.
Second, risk owners are generic. “IT” is not a risk owner. A risk owner should be a role or person accountable for treatment decisions, budget, timing, and residual risk.
Third, treatment plans are not time-bound. “Improve monitoring” is not a plan. “Deploy privileged session alerts in the SIEM for production admin accounts by 30 June, owned by the SOC Manager, tested through simulated admin login, with alert evidence attached” is a plan.
Fourth, the SoA is disconnected from treatment. If the treatment plan requires supplier monitoring, backup testing, incident escalation, MFA, or logging, the SoA should reflect the relevant controls and implementation status.
Fifth, residual risk is not approved. ISO 27001 requires risk-owner approval of the treatment plan and residual risks. NIS2 and DORA make this even more important because management accountability is explicit.
Sixth, supplier risk is treated as procurement administration. Under NIS2 Article 21(2)(d) and DORA Articles 28 and 30, supplier and ICT third-party risk must be part of risk management, not an annual questionnaire stored in isolation.
Seventh, there is no evidence of effectiveness. ISO 27001 Clause 6.1.1 requires planned actions to be evaluated for effectiveness. NIS2 includes effectiveness assessment in Article 21(2)(f). DORA expects testing and remediation. A control that exists but is never tested is weak evidence.
The SME Risk Management Policy - SME sets the expectation plainly:
The General Manager and Risk Coordinator must ensure that risk management activities are audit-ready. The Risk Register and related actions are subject to internal and external audit.
From SME Risk Management Policy, section “Enforcement and Compliance,” policy clause 8.2.1.
Board Reporting Without Drowning Executives
NIS2, DORA, and ISO 27001 all point toward management accountability, but boards do not need every risk row. They need decision-useful reporting.
A good board risk pack should show:
- High and Critical risks by domain
- Overdue treatment actions
- Regulatory risks involving NIS2, DORA, GDPR, or contracts
- Supplier risks affecting critical or important services
- Incident and near-miss trends
- Residual risks awaiting acceptance
- Control effectiveness test results
- Material changes to scope, suppliers, technology, or law
- Internal audit findings and corrective actions
Clarysec usually recommends monthly operational risk reviews and quarterly management reviews. Monthly reviews focus on treatment delivery. Quarterly reviews focus on acceptance, funding, prioritization, regulatory exposure, and strategic risk decisions.
This rhythm also supports continual improvement. Risk assessments should be updated when incidents occur, vulnerabilities emerge, new assets are introduced, technology changes, suppliers change, laws change, customer obligations change, or risk appetite changes.
The Clarysec Implementation Path
A unified risk program avoids disconnected ISO, NIS2, DORA, GDPR, and customer assurance spreadsheets. The practical path is:
- Confirm ISMS scope, services, assets, suppliers, jurisdictions, and customer obligations.
- Build or update the compliance register using the Legal and Regulatory Compliance Policy - SME where appropriate.
- Define risk methodology, acceptance criteria, likelihood scales, impact scales, and regulatory impact rules.
- Build the risk register using the Zenith Blueprint Risk Management phase and Clarysec’s Risk Register and SoA Builder approach.
- Identify asset-based and scenario-based risks, including supplier, cloud, privacy, continuity, incident, vulnerability, secure development, and access scenarios.
- Score risks using criteria that include legal, regulatory, contractual, operational, privacy, supplier, and financial impact.
- Select treatment options: mitigate, avoid, transfer, or accept.
- Map necessary controls to ISO/IEC 27001:2022 Annex A and ISO/IEC 27002:2022 guidance.
- Create or update the Statement of Applicability.
- Map treatments to NIS2 Article 21, DORA ICT risk management and third-party expectations, GDPR accountability, and customer contractual obligations.
- Collect evidence, validate control effectiveness, and obtain residual-risk approval.
- Prepare an audit pack organized by risk, control, regulation, and evidence artifact.
- Feed results into management review, internal audit, corrective action, and continual improvement.
This is not paperwork for its own sake. It is the operating system for defensible cyber governance.
Build an Audit-Ready Risk Treatment Pack
Sarah’s story ends well because she stopped treating ISO 27001, NIS2, and DORA as separate compliance projects. She used ISO 27001 risk assessment as the central engine, embedded regulatory obligations into risk criteria, mapped treatment actions to Annex A and EU requirements, and collected evidence that customers, auditors, and the board could understand.
Your organization can do the same.
Use Zenith Blueprint: An Auditor’s 30-Step Roadmap to define risk criteria, build the risk register, create the risk treatment plan, and cross-reference regulatory requirements.
Use Zenith Controls: The Cross-Compliance Guide to connect ISO/IEC 27001:2022 Annex A control areas with governance, legal compliance, assurance, and audit perspectives.
Use Clarysec’s Risk Management Policy, Risk Management Policy - SME, and Legal and Regulatory Compliance Policy - SME to standardize ownership, registers, treatment decisions, and audit-ready evidence.
The fastest practical next step is to take your top ten risks and test them against five questions:
- Is the regulatory impact visible?
- Is the treatment plan time-bound and owned?
- Is each treatment mapped to Annex A and the SoA?
- Is NIS2, DORA, GDPR, or customer relevance documented where applicable?
- Is there evidence that the control works?
If the answer is no, Clarysec can help turn your risk register into a defensible, cross-compliance risk treatment program that auditors, regulators, customers, and boards can trust.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
