The Verizon 2026 Data Breach Investigations Report found that only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalog were fully remediated by organizations in 2025, down from 38% the year before. The median time to full resolution rose to 43 days from 32, and the median organization had 50% more of these vulnerabilities to patch. Even the strongest performers fixed only 30% to 40% of instances in the first week after detection, which led Verizon to conclude that choosing the correct ones to patch is the key strategy. Meanwhile, IBM's 2026 Cost of a Data Breach Report put the global average breach at a record $4.99 million, with breaches that ran longer than 200 days costing $5.65 million against $4.32 million for those closed sooner.
Those two sets of numbers describe the problem that a cyber risk management framework exists to solve. Resources are finite, the list of things that could go wrong is longer than any budget, and time itself carries a price. Somebody has to decide what to fix first, what to insure, what to accept, and who answers for that choice. When that decision is made informally, it is made by whoever shouts loudest or whichever audit finding is newest. When it is made through a framework, it is made against agreed criteria, recorded, and open to challenge.
In India, the question has also reached the boardroom by regulation. SEBI's listing rules require the top 1,000 listed entities to constitute a Risk Management Committee whose role specifically covers cyber security. The RBI's July 2026 Directions for commercial banks include board and committee oversight and IT risk management within a single framework. NIST's Cybersecurity Framework 2.0 added a dedicated Govern function in 2024 to make the same point internationally: cybersecurity risk is a leadership responsibility before it is a technical one.
Talk to Our Security Experts →
A framework is not a certificate and it is not a spreadsheet. It is a repeatable cycle with owners, criteria, and a regular rhythm of review. This guide sets out that cycle in eight steps, explains how the main standards fit together, shows how to analyze and quantify risk without false precision, and covers what to report to a board. It is written for CISOs, risk and compliance heads, CFOs, and the board members and committee chairs who have to rely on the answer.
Which Frameworks Do What
Several standards cover overlapping ground, and confusion about which to use is a common reason programmes stall. They are best treated as parts of one toolkit.
| Framework | What it provides | Typical use |
|---|---|---|
| NIST Cybersecurity Framework 2.0 | Six functions (Govern, Identify, Protect, Detect, Respond, Recover) describing outcomes, with Govern covering context, strategy, roles, policy, oversight, and supply chain | Structuring the programme and talking to the board in common language |
| NIST IR 8286 Rev. 1 | Guidance, finalized in December 2025, on integrating cybersecurity risk into enterprise risk management, including the risk register | Connecting cyber risk to the enterprise risk process |
| ISO/IEC 27005:2022 | Guidance on information security risk management, with event-based and asset-based identification, aligned with ISO 31000 and ISO/IEC 27001 | Running the assessment and treatment cycle that an ISMS requires |
| ISO 31000:2018 | General enterprise risk management principles and process | Aligning cyber risk with how the organization manages all risk |
| NIST SP 800-37 Rev. 2 (Risk Management Framework) | A seven-step system-level lifecycle from Prepare to Monitor | Environments that need formal system authorization |
| FAIR (Factor Analysis of Information Risk) | A model for analyzing a defined loss scenario in financial terms | Prioritizing and justifying spend where numbers are needed |
The practical advice is to pick one backbone and borrow from the rest. An organization with an ISO/IEC 27001 management system will find ISO/IEC 27005 the natural process guide, with the CSF supplying the board vocabulary. One with United States federal customers will lean on the NIST family. FAIR-style analysis can sit on top of either for the handful of risks where a financial figure changes a decision.
The Eight Steps
Step 1: Establish governance and risk appetite
Everything else depends on this step, and it is the one most often skipped. CSF 2.0's Govern function asks for risk management objectives agreed by stakeholders (GV.RM-01), risk appetite and tolerance statements that are established, communicated, and maintained (GV.RM-02), and cybersecurity risk management activities included in enterprise risk management processes (GV.RM-03).
In practice that means a named executive owner, a committee with authority, a shared risk taxonomy with the enterprise risk function, and appetite statements stated as measurable limits. A statement that nobody can breach is a sentiment. A statement such as "no critical customer-facing service may be unavailable for more than four hours" or "estimated annual loss from any single cyber scenario must stay below a stated amount" can be tested.
| Governance element | What good looks like |
|---|---|
| Executive owner | One named person accountable for cyber risk, with a route to the board |
| Committee | A body with decision authority that meets on a fixed schedule |
| Risk taxonomy | Common categories and scales shared with the enterprise risk register |
| Appetite and tolerance | Measurable limits approved by the board |
| Escalation rules | Defined triggers for when a risk goes to a higher level |
Step 2: Define context and scope
A risk exists in relation to something the organization cares about. Start with the business services that must keep running, the data that must stay protected, the legal and contractual obligations that apply, and the systems and suppliers those depend on. A short business impact analysis identifies how long each critical service can be down and what that costs. Obligations to list include the CERT-In Directions and their six-hour reporting rule, the DPDP Act and Rules, sector rules from SEBI or the RBI where relevant, and, for organizations with European customers or operations, NIS2.
The output is a scoped inventory of what matters most, ranked by business consequence and not by technical convenience.
Step 3: Identify risks as scenarios
A risk register full of generic items such as "malware" or "data breach" cannot be analyzed or owned. ISO/IEC 27005:2022 describes two ways to identify risk: event-based, which starts from scenarios and their business consequences, and asset-based, which starts from assets, threats, and vulnerabilities. They work well together, with event-based thinking giving the strategic picture and asset-based analysis adding technical detail for privileged systems and sensitive data.
A good scenario names who or what acts, what is affected, how, and what the consequence is. For example: a stolen administrator credential is used to deploy ransomware on the order management system, causing several days of lost sales and a reportable data breach. Sources for scenarios include incident history, threat intelligence, vulnerability and penetration test results, attack simulation, audit findings, third-party assessments, and published data on how breaches actually begin. The 2026 DBIR reports exploitation of vulnerabilities as the most common initial access vector at 31%, the human element in 62% of breaches, ransomware in 48%, and third-party involvement in 48%. A scenario library that ignores those patterns is probably missing something.
Third-party risk deserves its own place in the register. CSF 2.0 gives it a dedicated category, GV.SC, and the DBIR reports third-party involvement in breaches rose 60% in a year.
Step 4: Analyze and evaluate
Analysis estimates how likely each scenario is and how bad it would be, and evaluation compares the result with appetite. Three approaches are in common use.
| Approach | How it works | Strength | Limitation |
|---|---|---|---|
| Qualitative | Likelihood and impact rated on scales such as low to high, plotted on a matrix | Fast and easy to explain | Scales are subjective, and a matrix compresses very different risks into the same cell |
| Semi-quantitative | Scales are given numeric values and combined into scores | Allows ranking and trend tracking | Scores can look more precise than they are |
| Quantitative | Frequency and loss are estimated as ranges and combined, often with simulation | Expresses risk in money and supports cost-benefit decisions | Needs data and expert estimates, and takes time per scenario |
Likelihood should draw on evidence, not intuition. Exposure, evidence of active exploitation, the strength of existing controls, and incident history all matter. Impact should be expressed in business terms: lost revenue, recovery cost, contractual penalties, and regulatory exposure, such as the DPDP Act's penalty of up to ₹250 crore for failing to implement reasonable security safeguards once it takes effect in May 2027. Time matters too, since IBM's data shows longer breaches cost materially more.
A simple illustration of quantitative thinking follows. The figures are invented for the example and are not benchmarks.
| Element | Estimate |
|---|---|
| Scenario | Ransomware on the order management system |
| Annual frequency range | 5% to 20% (central estimate 10%) |
| Loss per event range | ₹2 crore to ₹15 crore (central estimate ₹6 crore) |
| Central annual loss expectancy | 10% × ₹6 crore = ₹60 lakh |
| Possible control change | Tested offline backups and privileged access controls lower both ranges |
The value is less in the single figure than in the ranges and the comparison. If a control that costs ₹20 lakh a year is expected to reduce the loss expectancy by more than that, the case for funding it is clear, and if it is not, the organization can decide knowingly. ISO/IEC 27005 does not mandate a method, so the approach can start qualitative and add quantification for the top scenarios where it changes a decision.
Step 5: Decide on treatment
For each risk above appetite, the owner chooses a treatment and records why.
| Option | What it means | Example | Watch-out |
|---|---|---|---|
| Mitigate | Reduce likelihood or impact with controls | Multi-factor authentication, segmentation, tested backups | Needs funding, an owner, and a deadline |
| Transfer | Shift part of the financial impact | Cyber insurance or contractual terms | Does not transfer regulatory duties or reputational harm, and policies carry conditions |
| Avoid | Stop the activity that creates the risk | Retire a legacy system | May conflict with business goals |
| Accept | Knowingly retain the risk | A low risk within appetite, or a time-limited exception | Needs a named approver, a rationale, and an expiry date |
The output is a treatment plan with owners, deadlines, and an estimate of residual risk. Acceptance deserves the most discipline. Accepted risks that never expire turn the register into a record of problems nobody intends to fix.
Step 6: Select, implement, and fund controls
Controls are chosen because they reduce a specific risk, not because a framework lists them. They can be drawn from ISO/IEC 27001 Annex A, the NIST CSF categories, or NIST SP 800-53, and each should be traceable back to the scenarios it addresses. This traceability is what lets a CFO see what a given control buys, and it makes budget conversations specific. Where several risks depend on the same weakness, such as weak privileged access controls, a single investment can reduce many scenarios at once.
Step 7: Monitor with indicators and validate with testing
A framework that is reviewed once a year drifts. Key risk indicators track conditions that predict trouble, while performance indicators track whether controls work. Useful examples include the share of internet-facing systems with exploited vulnerabilities past their agreed fix time, multi-factor authentication coverage on privileged accounts, mean time to detect and contain incidents, backup restore test success rates, the rate at which staff report simulated phishing, and the number of critical suppliers assessed in the last year.
Indicators describe what the organization believes. Testing shows what is true. Vulnerability assessment and penetration testing check exposure, breach and attack simulation checks whether controls block and detect what they should, purple team exercises check detection and response, and social engineering testing checks people and procedures. Each produces evidence that updates likelihood estimates in the register.
Step 8: Report and review
Board reporting should answer four questions: what are the top risks, how do they compare with appetite, what is changing, and what decisions are needed. A dense list of vulnerabilities does not answer any of them. A one-page view of the top scenarios, their trend, the treatment status, and the investment requests does.
Cadence matters. For the top 1,000 listed entities, SEBI's rules require the Risk Management Committee to meet at least twice a year with no more than 180 days between meetings, and the risk management policy must cover internal and external risks including information and cyber security risks and a business continuity plan. Beyond the calendar, reviews should also be triggered by events: a major incident, a new critical system, an acquisition, a new regulation, or a significant change in the threat picture.
Where Indian Requirements Meet the Framework
| Requirement | What it asks | Where it lands in the framework |
|---|---|---|
| SEBI LODR, Regulation 21 | A Risk Management Committee for the top 1,000 listed entities, with a role that specifically covers cyber security | Steps 1 and 8 |
| RBI Directions, 2026 (commercial banks) | Board and committee oversight, a CISO, IT risk management, and a Cyber Security Operations Centre | Steps 1, 6, and 7 |
| DPDP Act and Rules | Reasonable security safeguards, and for Significant Data Fiduciaries an annual Data Protection Impact Assessment and audit | Steps 4, 6, and 7 |
| CERT-In Directions, 2022 | Incident reporting within six hours of noticing | Steps 7 and 8, through detection and reporting readiness |
| ISO/IEC 27001:2022 | A documented risk assessment and risk treatment process | Steps 3 to 5 |
| NIS2 (for organizations with EU exposure) | Risk analysis and information system security policies, approved by management | Steps 1 and 4 |
What a Weak Framework Costs
| Gap | Consequence |
|---|---|
| No risk appetite | Prioritization becomes arbitrary and disputes cannot be settled |
| Generic risks in the register | Nothing can be analyzed, owned, or funded |
| Risk scores with no evidence | Rankings that fall apart when challenged by an auditor or board member |
| Accepted risks with no expiry | A register of known problems that never gets fixed |
| No testing | Likelihood estimates drift away from reality |
| Reports that list findings, not decisions | Boards approve nothing, or approve the wrong things |
| Cyber risk held apart from enterprise risk | Competing priorities with no common currency |
A Maturity Model for Cyber Risk Management
Level 1: Risks are handled reactively, and priorities follow the latest incident or audit finding ↓ Level 2: A risk register exists, with qualitative scores and no agreed appetite ↓ Level 3: Governance, appetite, and a scenario-based register are in place, with owners and a regular review rhythm ↓ Level 4: Analysis uses evidence and ranges, treatment plans are funded and tracked, and testing feeds the register ↓ Level 5: Cyber risk is integrated with enterprise risk management, reported to the board in decision terms, and updated continuously as conditions change
The move from Level 2 to Level 3 matters most, because appetite and ownership turn a list of concerns into a system that makes decisions.
A 90-Day Plan to Stand the Framework Up
| Window | Focus | Outputs |
|---|---|---|
| Days 1 to 30 | Governance and scope | A named owner, a committee charter, a draft appetite statement, and a scoped list of critical services and data |
| Days 31 to 60 | Identification and analysis | A first scenario library, qualitative analysis of the top scenarios, and quantification for the top three to five |
| Days 61 to 90 | Treatment and reporting | Treatment plans with owners and deadlines, a first set of indicators, and a first board or committee report |
Common Mistakes and Edge Cases
Starting with the register. A register built before appetite and scope are agreed has no basis for ranking anything.
Confusing a score with a decision. A risk score is an input. The decision belongs to an accountable owner.
Treating compliance as risk management. A compliance checklist shows conformity with a rule, and the risks that matter most may sit outside it.
Quantifying everything. Precise-looking numbers for every risk waste effort and invite false confidence. Reserve quantification for decisions it can change.
Ignoring suppliers. Third-party involvement is rising, and a register without supplier scenarios is incomplete.
Forgetting new technology. AI systems and agents add risks that existing categories may not capture, and they need their own scenarios and owners.
Letting the framework go stale. A register that is not tied to incidents, testing, and change slowly stops describing the organization.
When to Use What: A Few Decision Points
Qualitative versus quantitative analysis. Begin qualitatively for breadth and add quantification for the largest or most contested risks, where a financial estimate changes the choice.
ISO/IEC 27005 versus the NIST family. Organizations running an ISO/IEC 27001 management system generally find ISO/IEC 27005 the more natural fit. Those serving United States federal customers, or that need formal system authorization, may prefer NIST. Both align with the CSF vocabulary.
A GRC platform versus a spreadsheet. A spreadsheet is enough to start. A platform becomes worthwhile when the number of risks, owners, and evidence items makes manual tracking unreliable.
One enterprise register versus separate registers. A single taxonomy with business-unit views usually works best, so risks roll up consistently without losing local detail.
In-house versus external support. Internal teams hold the context. An external party adds independence, benchmarks, and facilitation, which is useful for the first appetite discussion with a board.
How SecNinjaz Fits Into This
Cyber risk management sits in SecNinjaz's GRC and DPDP practice, which covers Risk Management, Regulatory Compliance, ISO Certification and Compliance, Audit and Gap Assessment, and AI Governance, with vCISO support for organizations that need senior security leadership guiding the programme without a full-time hire. The testing that keeps a risk register honest comes from SecNinjaz's Cybersecurity practice, including Vulnerability Assessment, Penetration Testing, Breach and Attack Simulation, Purple Teaming, and Social Engineering, whose findings can be fed directly into the likelihood estimates in the register.
SecNinjaz holds ISO/IEC 27001:2022 for information security, ISO/IEC 27701:2025 for privacy information management, and ISO/IEC 42001:2023 for AI management systems, which together cover the risk assessment discipline, the privacy dimension, and the newer AI risk category this guide describes. For enterprises trying to turn scattered findings into decisions a board can make and defend, that combination of governance practice and independent testing is the pairing worth looking for, whether the enterprise works with SecNinjaz or anyone else.
Talk to Our Security Experts →
Frequently Asked Questions
What is a cyber risk management framework?
A cyber risk management framework is a repeatable cycle for governing, identifying, analyzing, treating, monitoring, and reporting cyber risk, with defined owners, criteria, and review rhythm. It turns scattered security findings into prioritized decisions that leadership can make and defend.
Which framework should an enterprise choose?
Most organizations use one as a backbone and borrow from others. ISO/IEC 27005 suits those running an ISO/IEC 27001 management system, the NIST family suits those with United States federal customers, and NIST CSF 2.0 provides common language for the board. FAIR-style quantification can supplement any of them for high-stakes decisions.
What is the difference between a risk assessment and a risk management framework?
A risk assessment identifies and analyzes risks at a point in time. A framework surrounds it with governance, appetite, treatment, monitoring, and reporting, so the assessment is repeated, acted on, and tied to decisions.
What is risk appetite and why does it matter?
Risk appetite is the amount and type of risk an organization is willing to accept in pursuit of its goals, expressed as measurable limits. Without it, there is no basis for deciding whether a risk is acceptable, and prioritization turns into opinion.
Should cyber risk be quantified in financial terms?
For the largest or most contested risks, yes, using ranges and clear assumptions, because it supports cost-benefit decisions. Quantifying every risk adds effort and false precision, so most programmes start qualitative and add quantification where it changes a decision.
What does SEBI require on cyber risk for listed companies?
The top 1,000 listed entities by market capitalization must constitute a Risk Management Committee whose role, as defined by the board, specifically covers cyber security. The committee must meet at least twice a year with no more than 180 days between meetings, and the risk management policy must cover information and cyber security risks and a business continuity plan.
How often should the cyber risk register be reviewed?
Regularly on a fixed schedule, with the top risks reviewed at least as often as the board or committee meets, and also whenever a major incident, new critical system, acquisition, or regulatory change occurs. A register reviewed only annually tends to drift from reality.
Where should an organization start?
Start with governance: a named owner, a committee, and a draft risk appetite statement. Then scope the critical services and data, build a first library of risk scenarios, analyze the top ones, and produce a first short report for the board or committee within about 90 days.
