Quantitative Cyber Risk Assessment for NIS2 and DORA
The board meeting where “high risk” stopped being enough
It is 08:15 on a Tuesday. The CISO of a fast-growing fintech is standing outside the boardroom with three versions of the same cyber risk story.
The first version is familiar: ransomware is “High,” cloud outage is “High,” supplier compromise is “Medium,” privileged access misuse is “High.” It is defensible, aligned with the current risk register and almost useless for the decision the board needs to make.
The second version is a technical roadmap: deploy immutable backups, improve identity controls, fund resilience testing, strengthen supplier monitoring and expand logging coverage. It is sensible, but the CFO asks the question that changes the meeting: “Which of these reduces the most business risk per euro?”
The third version changes the conversation.
A 12-hour outage of the payment orchestration platform is estimated at €620,000 in gross operational, contractual and revenue impact. The current annualized exposure is estimated at €186,000. A €74,000 resilience package can reduce expected annual loss to approximately €62,000. The remaining exposure is still above tolerance because the service supports a critical or important function, customer notification exposure remains material and third-party dependency is high.
Now the board is not debating colors. It is discussing financial exposure, risk tolerance, regulatory accountability and investment priorities.
That is quantitative cyber risk assessment in 2026. It is not mathematical theatre. It is not pretending that cyber events can be predicted with perfect precision. It is the disciplined translation of “this is red” into “this is the plausible financial exposure, this is the confidence level, this is the regulatory consequence, this is the treatment decision and this is the evidence trail.”
For CISOs, compliance managers, auditors and business owners, that shift is becoming mandatory in practice. ISO/IEC 27001:2022 requires a documented, consistent and comparable risk assessment and treatment process. NIS2 moves cybersecurity risk into management body approval, oversight, training and liability. DORA makes ICT risk governance, resilience testing, incident classification, third-party risk and management accountability central for financial entities. NIST CSF 2.0 gives leadership a governance language for risk appetite, prioritization and oversight. GDPR adds accountability when personal data is involved.
The gap is not that organizations lack risk registers. The gap is that many risk registers cannot explain money, priorities, board accountability or audit evidence.
Clarysec’s approach closes that gap by combining the Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec policies and Zenith Controls: The Cross-Compliance Guide Zenith Controls into one practical evidence model: quantify what matters, map it to controls, show who accepted it and prove the treatment worked.
Why qualitative risk registers are no longer enough
Qualitative risk assessment still matters. A clear likelihood and impact matrix helps teams prioritize when data is incomplete, especially across a broad ISMS scope. The problem starts when the organization stops there.
A board can understand that a risk is “High,” but it cannot easily compare three “High” risks competing for the same budget. Is the highest priority the ransomware scenario, the cloud outage, the supplier concentration risk or the privileged access weakness? The answer depends on financial exposure, regulatory severity, customer impact, contractual obligations, service criticality and residual risk after treatment.
That is why quantitative cyber risk assessment works best as a hybrid model. Do not quantify every minor issue. Use qualitative scoring across the full register, then add financial analysis for the risks that require management decisions, investment approval, contractual action, risk transfer or board oversight.
Clarysec’s Enterprise Risk Management Policy Risk Management Policy supports this explicitly. In section “Policy Implementation Requirements,” clause 6.2.3, it states:
“Both qualitative and quantitative methods may be applied depending on the risk category and the availability of information.”
That clause is important because it prevents a common failure: false precision. Mature organizations do not force financial modelling onto every small risk. They apply it where the decision needs it.
For SMEs, the foundation can stay simple. Clarysec’s SME Risk Management Policy Risk Management Policy - SME, section “Governance Requirements,” clause 5.1.2, states:
“Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.”
The improvement is not to replace that structure. The improvement is to enrich the most important entries with financial estimates, especially where downtime, regulated services, personal data, cloud dependency, ICT outsourcing or critical customer commitments are involved.
The governance shift: cyber risk is now a board artifact
Cyber risk quantification is not just a finance exercise. It is governance evidence.
Under ISO/IEC 27001:2022, the organization must determine context, interested parties, legal and contractual requirements, scope, interfaces and dependencies. It must define an information security risk assessment process that produces consistent, valid and comparable results. It must identify risks to confidentiality, integrity and availability, identify risk owners, assess consequences and likelihood, determine risk levels and prioritize risks. It must then select treatment options, determine controls, compare them with Annex A, produce a Statement of Applicability, obtain risk owner approval and retain documented information.
That means the risk register is not a private spreadsheet for the security team. It is an ISMS record that connects leadership, control selection, treatment accountability and management review.
NIS2 raises the expectation further. Management bodies of essential and important entities must approve cybersecurity risk-management measures, oversee implementation and receive training so they can understand risks and assess cybersecurity practices. NIS2 Article 21 requires appropriate and proportionate technical, operational and organizational measures, considering state of the art, implementation cost, risk exposure, entity size, likelihood, severity and societal and economic impact.
That phrase, “societal and economic impact,” is where financial cyber risk quantification becomes powerful. A provider supporting cloud, data centre, DNS, trust services, managed services, managed security services, digital infrastructure, online marketplaces or other covered sectors may need to show not only that controls exist, but why they are proportionate to exposure.
For financial entities, DORA applies from 17 January 2025 and becomes the sector-specific digital operational resilience regime. It covers ICT risk management, major ICT-related incident reporting, digital operational resilience testing, cyber threat information sharing, ICT third-party risk and oversight of critical ICT third-party service providers. For financial entities also identified under NIS2 national transposition, DORA operates as the sector-specific Union legal act for relevant ICT risk-management and incident reporting matters.
In practical terms, a fintech does not need five disconnected risk frameworks. It needs one integrated risk model that shows which regime applies, what dependencies exist, what financial exposure is plausible and how management approved and monitored treatment.
GDPR adds another layer. If personal data is involved, a cyber event may become a personal data breach, not merely an operational incident. The risk model should identify processing context, controller or processor role, data categories, special category data where relevant, security measures, breach assessment logic and notification implications.
From heat map to euros: the practical hybrid model
The right question is not, “Should we replace qualitative risk assessment?” The right question is, “Which risks deserve financial quantification?”
The Zenith Blueprint, Risk Management phase, Step 12, “Risk Assessment Methods: Qualitative & Quantitative,” gives a pragmatic answer:
“Quantitative risk assessment attempts to estimate risk in numerical terms (e.g. expected annual loss in currency). This often involves:
✓ Gathering historical incident data (e.g. how often does a breach occur, what is the average cost). ✓ Using models like Annualized Loss Expectancy (ALE = Single Loss Impact × Annual Rate of Occurrence) or frameworks like FAIR (Factor Analysis of Information Risk) for more complex analysis.”
The same step warns that pure quantitative analysis can be difficult for SMEs because historical data may be limited and the process can be resource-intensive. The practical answer is “light quantitative” analysis for top risks.
| Element | Practical meaning | Example |
|---|---|---|
| Single Loss Impact | Estimated impact if the scenario occurs once | €620,000 for a 12-hour payment platform outage |
| Annual Rate of Occurrence | Estimated frequency per year | 0.3, meaning roughly once every 3.3 years |
| Annualized Loss Expectancy | Single Loss Impact multiplied by Annual Rate of Occurrence | €186,000 expected annual exposure |
| Treatment Cost | Cost of control package | €74,000 for failover, monitoring and testing |
| Residual Annualized Loss | Estimated annual exposure after treatment | €62,000 |
| Decision | Treat, transfer, avoid or accept | Treat and review residual risk at management review |
The numbers do not need to be perfect. They need to be explained. Impact assumptions may include revenue loss, SLA credits, customer compensation, incident response, legal advice, forensic support, overtime, customer support, regulatory notification effort, churn and reputational impact. Frequency assumptions may come from internal incidents, supplier outage reports, threat intelligence, sector experience, vulnerability exposure, audit findings and control maturity.
The Zenith Blueprint, Risk Management phase, Step 10, “Establishing Risk Criteria and Impact Matrix,” explains why the model must be calibrated:
“When defining impact, it’s wise to relate levels to your specific business scale. For example, ‘Major financial impact = loss > $100k’ (adjust to your context). Also consider regulatory impact: for example, a data breach of personal data might automatically be ‘Major’ or ‘Severe’ due to GDPR fines and notification requirements, even if the direct financial loss is unclear.”
That is the bridge between qualitative and quantitative risk. “Major” becomes meaningful only when the organization defines what major means in financial, operational, legal and customer terms.
Worked example: quantifying supplier cloud outage risk
Imagine a SaaS provider serving financial-sector clients. It depends on a cloud hosting provider, a managed database platform, a payment gateway and a customer notification service. The team selects one scenario for quantitative analysis:
“Extended outage of managed database platform causes customer-facing service disruption and delayed transaction processing.”
Step 1: define the risk scenario and owner
The SME Risk Management Policy requires description, likelihood, impact, score, owner and treatment plan. The Enterprise Risk Management Policy, section “Governance Requirements,” clause 5.2.2, adds that the register:
“Includes risk owners, impact and likelihood scores, treatment plans, deadlines, and control references”
The owner is not “IT.” The accountable owner is the service owner, supported by the CISO, CTO, compliance manager, supplier manager and finance.
Step 2: estimate financial exposure
The team estimates:
- €35,000 per hour in lost transaction revenue and SLA credits
- €8,000 per hour in support, escalation and incident handling cost
- €60,000 in customer remediation and communications cost
- €120,000 in potential churn or commercial impact
- 10 hours as a plausible severe outage based on supplier history and architecture review
Single Loss Impact is:
10 × (€35,000 + €8,000) + €60,000 + €120,000 = €610,000
Current likelihood is estimated at 0.25 per year. Annualized Loss Expectancy is:
€610,000 × 0.25 = €152,500
The proposed treatment package includes multi-region failover design, tested backup restore, supplier SLA review, synthetic monitoring, a tabletop exercise and an exit-plan update. First-year cost is €82,000, with €34,000 recurring.
After treatment, residual likelihood is estimated at 0.10 per year and residual single loss impact at €350,000 due to faster restoration. Residual ALE is:
€350,000 × 0.10 = €35,000
The first-year reduction in expected annual exposure is approximately €117,500, before considering regulatory resilience, customer trust and contractual benefits.
Step 3: choose treatment and document rationale
Risk treatment is not always pure mitigation. Clarysec’s SME Risk Management Policy, section “Policy Implementation Requirements,” clause 6.1.3, states:
“Transfer: Use contracts, service level agreements, or insurance to transfer risk externally.”
For this scenario, the organization chooses a mixed treatment: reduce through technical resilience, transfer part through SLA and contractual remedies, and accept residual risk with management approval.
Step 4: map treatment to the Statement of Applicability
The Enterprise Risk Management Policy, section “Statement of Applicability (SoA) Alignment,” clause 6.5.1, states:
“Control decisions resulting from the risk treatment process shall be reflected in the SoA.”
This is where the financial model becomes audit-ready. The supplier outage scenario links to ISO/IEC 27001:2022 Annex A supplier, cloud, continuity, incident and disruption controls. It also links to NIS2 supply-chain security and business continuity, DORA ICT third-party risk and resilience testing, GDPR security and breach assessment if personal data is affected, and NIST CSF governance, supply chain, response and recovery outcomes.
The Zenith Blueprint, Risk Management phase, Step 13, “Risk Treatment Planning and Statement of Applicability,” explains the traceability:
“The SoA is effectively a bridging document: it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.”
A strong SoA justification might say: “Applicable because managed database outage affects critical customer service, ICT third-party dependency, customer contractual obligations, continuity commitments and potential personal data availability. Controls are selected to reduce a quantified €152,500 annualized exposure and support management-approved residual risk.”
Step 5: escalate based on thresholds
The Enterprise Risk Management Policy, section “Governance Requirements,” clause 5.6, requires:
“The Risk Authority Matrix shall clearly define thresholds for escalation to Top Management or the Board.”
A €152,500 annualized exposure may exceed local management tolerance. A lower-value risk may still require escalation if it affects a critical or important function, triggers DORA expectations, involves personal data, threatens customer commitments or creates NIS2 management body accountability.
Cross-compliance mapping: one quantified risk, many obligations
A quantified cyber risk should not be copied into five separate compliance spreadsheets. It should become one risk object with multiple compliance views.
| Compliance lens | What the quantified risk must show | Evidence artifact |
|---|---|---|
| ISO/IEC 27001:2022 | Risk criteria, owner, likelihood, consequence, treatment, residual acceptance, SoA mapping and operating evidence | Risk register, treatment plan, SoA, management review, audit records |
| NIS2 | Appropriate and proportionate measures, management body approval and oversight, incident and continuity considerations, supply-chain measures | Board minutes, training records, risk treatment approvals, incident workflow |
| DORA | ICT risk governance, critical or important functions, ICT third-party dependencies, testing, incident classification and resilience strategy | ICT risk framework, register of information, test results, incident classification, exit plan |
| GDPR | Personal data scope, security measures, breach implications, controller or processor accountability, lawful processing context | RoPA linkage, DPIA where applicable, breach assessment, security evidence |
| NIST CSF 2.0 | Risk appetite, standardized prioritization, governance, supplier risk, detection, response and recovery outcomes | Current and Target Profiles, action plan, POA&M, supplier risk records |
| COBIT 2019 | Governance objectives, performance monitoring, risk optimization, resource decisions and assurance | Governance reporting, control performance metrics, assurance reports |
NIS2 Article 21 is especially relevant because it includes risk analysis, security policies, incident handling, business continuity, backup, disaster recovery, crisis management, supply-chain security, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management and authentication.
DORA creates similar discipline for financial entities, but with sector-specific focus. It requires an internal governance and control framework for ICT risk, with the management body ultimately responsible. It expects approval and oversight of ICT policies, roles, digital operational resilience strategy, ICT risk tolerance, continuity and response plans, audit plans, budgets, training, ICT third-party policies and reporting channels.
DORA also gives quantitative risk assessment a direct operational trigger: incident classification. Major ICT-related incidents must be classified using criteria such as affected clients, counterparties and transactions, duration, downtime, geographic spread, data losses affecting availability, authenticity, integrity or confidentiality, criticality of affected services and economic impact. If the risk model already estimates downtime, client impact, data impact and economic loss, it supports incident classification when a real event occurs.
The control crosswalk that makes board accountability auditable
In Zenith Controls, Clarysec maps ISO/IEC 27002:2022 control 5.4, “Management responsibilities,” as a governance anchor for information security accountability. The guide treats it as preventive, supporting confidentiality, integrity and availability, aligned to the “Identify” cybersecurity concept, with governance as the operational capability and governance plus ecosystem as security domains.
That matters because financial cyber exposure belongs in management decision-making. Zenith Controls links ISO/IEC 27002:2022 control 5.4 to several supporting controls:
| ISO/IEC 27002:2022 control relationship | Why it matters for quantified risk |
|---|---|
| 5.2 Information security roles and responsibilities | Risk owners, control owners and escalation authorities must be defined |
| 5.1 Policies for information security | Quantified risk decisions must align with approved policy commitments |
| 5.35 Independent review of information security | Independent review gives management objective assurance over risk treatment |
| 5.36 Compliance with policies, rules and standards for information security | Compliance monitoring shows whether treatments are operating as intended |
| 5.8 Information security in project management | New products and changes must include cyber risk and financial exposure early |
Zenith Controls also maps management responsibilities to ISO/IEC 27001:2022 clauses 5.1, 5.2 and 9.3, connecting leadership, policy and management review. It further maps to ISO/IEC 27014:2020 clauses 6 and 7, which focus on governance frameworks and processes for evaluating, directing, monitoring and communicating information security.
The evidence chain is straightforward:
- Management defines appetite, tolerance and escalation thresholds.
- Risk owners quantify top cyber risks.
- Controls are selected and reflected in the SoA.
- Treatment actions are executed and monitored.
- Independent review and compliance monitoring test effectiveness.
- Management review evaluates performance, incidents, audit results, resources and improvement actions.
- The board receives financial exposure, residual risk and accountability evidence in business terms.
Clarysec’s SME Risk Management Policy, section “Roles and Responsibilities,” clause 4.1.1, reinforces this governance role:
“Sets the organization’s risk appetite and approves the risk management framework.”
For an SME, this may be the General Manager or owner. For a regulated financial entity, this may be the management body. The accountability principle is the same.
How auditors and regulators will test your numbers
Quantitative cyber risk assessment will not be audited as perfect actuarial science. It will be audited for method, consistency, traceability, governance and evidence.
| Auditor or assessor lens | What they will test | Evidence they will expect |
|---|---|---|
| ISO/IEC 27001:2022 | Clause 6.1.2 risk assessment, clause 6.1.3 risk treatment, SoA decisions, risk owner approval and clause 9.3 management review | Risk criteria, register, treatment plan, SoA, approvals, management review minutes |
| NIS2 competent authority | Management body approval and oversight, Article 21 measures, proportionality, incident readiness and training | Board packs, training records, risk approvals, incident procedures, continuity evidence |
| DORA supervisor or internal auditor | ICT risk framework, ICT risk tolerance, critical or important functions, testing, incident classification and ICT third-party risk | ICT risk register, resilience strategy, register of information, test results, exit plans |
| NIST CSF 2.0 assessor | GOVERN outcomes, including GV.RM-02 risk appetite and tolerance and GV.RM-06 standardized prioritization | Current Profile, Target Profile, action plan, enterprise risk linkage |
| COBIT 2019 assessor | Governance over enterprise IT, risk optimization, decision rights, resource allocation and assurance | Governance reporting, performance metrics, assurance reports |
The Clarysec Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy-sme - SME, section “Governance Requirements,” clause 5.4.3, makes the audit loop explicit:
“Audit findings and status updates must be included in the ISMS management review process.”
This is critical. If the risk model estimates €500,000 exposure but internal audit finds the restore test failed, the residual risk must change. If the supplier exit plan is untested, the organization should not accept residual risk as if the control were mature. If DORA testing identifies a critical gap, that finding must feed treatment, budget and management review.
The Zenith Blueprint, Audit, Review & Improvement phase, Step 28, “Management Review,” supports this by recommending management review inputs such as changes in internal and external issues, regulatory requirements, audit results, monitoring and measurement, objectives, incidents, nonconformities, opportunities for improvement and resource needs. In a quantified cyber risk program, the management review pack should include top financial exposures, trend since last review, treatment progress, overdue actions, residual risk above tolerance and decisions required.
Building a board-ready cyber risk pack
A board-ready cyber risk pack should not drown directors in vulnerability counts, FAIR variables or control IDs. It should translate cyber risk into decisions.
For each top quantified risk, include:
- Scenario name and business service affected
- Criticality of service or function
- Personal data, regulated service and supplier dependency flags
- Current Single Loss Impact estimate
- Current Annual Rate of Occurrence estimate
- Current Annualized Loss Expectancy
- Assumptions and confidence level
- Current controls and known gaps
- Treatment options and cost
- Expected residual exposure after treatment
- ISO/IEC 27001:2022, NIS2, DORA and GDPR relevance
- Risk owner and decision needed
- SoA and policy references
- Deadline and review date
A simplified board view may look like this:
| Risk scenario | Current ALE | Treatment cost | Residual ALE | Regulatory driver | Decision |
|---|---|---|---|---|---|
| Managed database outage affecting transaction processing | €152,500 | €82,000 | €35,000 | DORA ICT risk, ISO risk treatment, supplier continuity | Approve treatment |
| Ransomware affecting customer data platform | €372,000 | €100,000 | €95,000 | GDPR breach risk, NIS2 incident handling, ISO incident controls | Approve EDR and immutable backups |
| Privileged access compromise in cloud admin console | €260,000 | €58,000 | €72,000 | ISO access control, NIS2 authentication, DORA data integrity | Approve MFA and PAM uplift |
| Critical SaaS provider concentration risk | €190,000 | €45,000 | €95,000 | DORA third-party risk, NIS2 supply chain, ISO supplier controls | Approve exit plan testing |
The numbers are estimates, but the governance value is real. The board can compare priorities. The CISO can justify spend. Finance can validate assumptions. Compliance can link decisions to obligations. Auditors can follow the evidence trail.
Common mistakes when quantifying cyber risk
The first mistake is false precision. A model claiming a €487,239.17 loss without clear assumptions is less credible than a range with documented basis. Use ranges where appropriate and review assumptions after incidents, audits, supplier changes and major architecture decisions.
The second mistake is counting only technical cost. A major cyber incident may involve revenue loss, customer compensation, operational disruption, regulatory reporting, legal advice, forensic support, communication costs, contractual penalties, churn, management time and reputational impact.
The third mistake is ignoring regulatory severity. A personal data breach may be major even when direct operational loss appears modest. A DORA incident may be significant because of service criticality, downtime, data loss or affected clients. A NIS2 incident may be material because it causes severe operational disruption, financial loss or considerable damage to others.
The fourth mistake is failing to update the SoA. If treatment decisions select supplier monitoring, cloud exit planning, incident evidence collection, ICT readiness for business continuity or disruption controls, the SoA must reflect the applicable controls and implementation status.
The fifth mistake is leaving finance out. Quantitative cyber risk assessment is strongest when security, finance, legal, operations, product and compliance agree on impact assumptions. The CISO should not invent revenue loss numbers alone.
The sixth mistake is treating insurance as full risk transfer. Insurance may reduce financial impact, but it does not remove regulatory accountability, service disruption, customer trust damage or management responsibility.
Where Clarysec fits
Clarysec helps organizations build a cyber risk program that is practical enough for SMEs and rigorous enough for regulated environments.
The Zenith Blueprint guides the organization from scope and context through risk criteria, qualitative and quantitative assessment, treatment planning, SoA traceability, audit, management review and improvement. Zenith Controls helps map ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control expectations to other frameworks, audits and governance obligations. Clarysec policies provide the language auditors expect, including risk appetite, authority matrices, treatment options, compliance registers, SoA alignment and management review integration.
The SME Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy - SME, section “Governance Requirements,” clause 5.1.1, starts with a simple obligation:
“The GM must maintain a simple, structured Compliance Register listing:”
That simple register matters. Legal, regulatory and contractual obligations must be visible inside the ISMS. For quantitative risk, that means NIS2, DORA, GDPR, customer contracts, SLAs, outsourcing duties, incident reporting obligations and audit commitments shape impact, treatment priority and escalation.
The Enterprise Risk Management Policy, section “Reference Standards and Frameworks,” clause 11.9.1, also directly reflects DORA-style governance:
“Article 5: Mandates a documented ICT risk management framework, fully covered by this policy’s structure, including SoA mapping and KRIs.”
That is the Clarysec model in one sentence: documented ICT risk management, mapped to controls, measured through indicators, reviewed by management and evidenced for audit.
Next steps: make your 2026 cyber risk register financially defensible
If your current cyber risk register still says “High” without explaining financial exposure, treatment economics or regulatory impact, start with five actions this quarter:
- Select your top 5 to 10 cyber risk scenarios by business impact.
- Define financial impact thresholds for Minor, Moderate, Major and Severe.
- Estimate Single Loss Impact, Annual Rate of Occurrence and Annualized Loss Expectancy for each top scenario.
- Map each treatment decision to ISO/IEC 27001:2022 controls, the SoA, NIS2 or DORA obligations where applicable, GDPR implications and NIST CSF governance outcomes.
- Present residual risk, treatment cost and escalation thresholds at management review.
Clarysec can help you turn that into a repeatable evidence system using the Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, the Enterprise Risk Management Policy Risk Management Policy, the SME Risk Management Policy Risk Management Policy - SME and supporting audit and compliance templates.
The goal is not to make cyber risk perfectly predictable. The goal is to make it explainable, comparable, financially meaningful and auditable.
Download the Clarysec risk and compliance policy templates, explore the Zenith Blueprint, or book a Clarysec assessment to turn your 2026 cyber risk register into board-ready evidence for ISO/IEC 27001:2022, NIS2, DORA and GDPR.
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
