Priya Nandakumar inherited the risk register on a Tuesday afternoon, in the same meeting where she inherited the title "ISMS Manager" for Fenwick Logistics, a 340-person freight brokerage with a Series C balance sheet and a certification deadline eleven weeks out. The register her predecessor left behind was a marvel of diligence and a monument to missing the point: 4,187 rows, one for every laptop, switch, SaaS subscription, filing cabinet, and printer Fenwick had ever inventoried, each one dutifully paired with a threat ("theft"), a vulnerability ("inadequate physical security"), and a likelihood/impact score copy-pasted so many times the formatting had fossilized. It had taken the previous risk owner four months to build. It had never once been discussed in a leadership meeting, because nobody at the executive level could sit through a 4,000-line spreadsheet, and nobody needed to — the real risk that nearly ended Fenwick's business that year wasn't sitting in any row of it.
The real risk was this: Fenwick's core transportation management system integrated with a third-party customs broker API, and if that integration went down for more than six hours during peak shipping season, the company would miss binding delivery windows on 40% of its active freight contracts, triggering penalty clauses worth an estimated $2.1 million and — worse — the kind of reputational damage that makes a customer never come back. That risk touched a dozen assets: the TMS server, the API gateway, the broker's infrastructure (which Fenwick didn't own or control), the on-call engineering rotation, the contractual penalty clauses themselves. It didn't live in any single row of a 4,000-line asset register. It lived in the interaction between systems, people, and business terms — and Priya's predecessor's methodology, built entirely around "list every asset, then list its threats," had no natural place to put it.
Priya's board wanted certification. Priya wanted a risk assessment that would actually prevent the $2.1 million outage. Those turned out to be solvable at the same time, but only once she stopped treating "asset-based risk assessment" as a synonym for "ISO 27001 risk assessment" and started asking a more useful question: which identification method — asset-based, scenario-based, or some blend of the two — would actually surface the risks that mattered to her business, and could she defend that choice to a certification auditor without flinching?
This article is that decision, worked through in full: what each method is, what it costs, where it breaks, how to combine them, and how to change lanes mid-flight without restarting your ISMS from zero.
Who This Is For
You're responsible for designing or overhauling the risk identification method inside an ISO 27001 ISMS — an ISMS manager, a CISO building the program from scratch, a consultant advising a client, or an internal auditor trying to work out whether the existing method is actually defensible. You've either inherited an asset-based register that has become unmanageable, or you're starting fresh and don't want to build 4,000 rows nobody will ever read, or you've heard "scenario-based" mentioned and want to know if it's a shortcut, a fad, or a genuinely better fit for your organization. You'll walk away knowing exactly what ISO 27001:2022 actually requires (it's less prescriptive than most people assume), how to run both methods end to end with worked examples, and how to pick — and defend — the one that fits your size, maturity, and environment.
Two Philosophies, One Clause
Every ISO 27001 risk assessment answers the same three questions eventually: what could happen, how likely is it, and how bad would it be. Asset-based and scenario-based methodologies are two different starting points for getting to those answers — two different ways of organizing the same underlying analytical work. They are not two different standards, and neither one is "the real ISO 27001 way." Both, done well, produce a risk register that satisfies Clause 6 Planning — Risk Assessment and Objectives and feeds a coherent risk treatment plan. Both, done badly, produce a document that exists to satisfy an auditor and nothing else.
The asset-based philosophy says: an organization's information security risk lives in its assets. Enumerate everything of value — hardware, software, data, people, facilities, services — and for each one, work out what could threaten it and what weaknesses would let that threat succeed. This is the model most practitioners over 40 learned first, because it's the model ISO 27001:2005 and ISO 27001:2013's supporting guidance implicitly pointed toward, with its language of "assets, threats, and vulnerabilities" baked into training courses and legacy tooling long after the clause text itself stopped requiring it.
The scenario-based philosophy says: information security risk lives in events — specific, describable things that could go wrong, stated as a narrative ("a ransomware operator encrypts the production database," "a departing sales engineer exfiltrates the customer contact list to a competitor," "a misconfigured storage bucket exposes claims data to the public internet"). You define plausible scenarios first, assess each one's likelihood and impact, and only pull in asset detail as supporting context for scoring, not as the primary organizing unit.
The methodology choice matters because it changes what shows up in your register, how much effort it takes to produce, how legible the result is to a board, and how well it scales as your estate grows or moves to the cloud. Get the choice wrong for your organization's profile and you either drown in irrelevant granularity or skate past risks that needed asset-level detail to catch.
What ISO 27001:2022 Actually Requires (And What It Doesn't)
This is the part almost every risk assessment training deck gets slightly wrong, so it's worth being precise. Clause 6.1.2 of ISO/IEC 27001:2022 requires the organization to define and apply an information security risk assessment process that: establishes and maintains risk criteria; ensures repeated assessments produce consistent, valid, and comparable results; identifies risks associated with the loss of confidentiality, integrity, and availability of information within the scope of the ISMS; identifies risk owners; analyzes the risks (assessing realistic likelihood and consequences, and determining risk levels); and evaluates the risks against the established criteria to prioritize them for treatment.
Read that list again. Nowhere does it say "identify assets." Nowhere does it say "threat" or "vulnerability." The 2013 edition's Annex language and the accompanying ISO 27005 guidance of that era leaned heavily on the classical asset-threat-vulnerability triad, and an entire generation of consultants, auditors, and templates absorbed that as gospel. The 2022 edition — and the 2022 revision of ISO 27005 alongside it — deliberately loosened that link. The requirement is method-agnostic: any risk identification process that reliably and repeatably surfaces confidentiality, integrity, and availability risks within your defined scope satisfies 6.1.2, whether you get there by walking asset by asset or by workshopping scenarios with business stakeholders.
This is not a loophole or a gray area open to aggressive interpretation — it's the plain, deliberate text of the standard. Certification bodies are well aware of it, and a competent auditor will not challenge a scenario-based methodology simply because it doesn't produce a threat/vulnerability pair for every asset. What an auditor will challenge, regardless of which method you pick, is inconsistency: a methodology description that says one thing and a register that does another, criteria that shift between assessment cycles without documented justification, or scope gaps where an obviously in-scope system has no corresponding risk coverage under either method. For the mechanics of building criteria, scales, and a defensible process end to end, see the companion piece on ISO 27001 risk assessment methodology.
Where ISO 27005:2022 Backs This Up
If Clause 6.1.2 is the requirement, ISO/IEC 27005:2022 is the supporting guidance most auditors and consultants actually reference when they explain how to satisfy it — and its 2022 revision is explicit about method plurality in a way its predecessor wasn't. The older 27005 leaned on an "asset-based approach" as its worked example throughout, which is a large part of why the asset-threat-vulnerability triad calcified into folklore. The 2022 revision restructures around "event-based" risk identification as an equally valid path, describing risk in terms of scenarios built from a risk source, an event, and consequences — language that maps almost exactly onto what this article calls scenario-based assessment. It also explicitly discusses combining the two, which is the closest thing to an official blessing of the hybrid model you'll find in the supporting standards literature.
Practically, this matters for one reason: if an auditor questions your scenario-based methodology, you are not defending an improvisation — you are describing an approach that the very guidance document written to support ISO 27001 now presents as a primary option, not a shortcut. Bring a copy of your methodology document that references this alignment explicitly, and the conversation tends to end quickly.
"I still meet ISMS managers who apologize to me for not doing 'proper' asset-based risk assessment, as if scenario-based is the discount version. I have to stop the meeting and show them the clause text. There is no discount version — there's a version that fits your organization and a version that doesn't." — Marcus Webb, Principal Auditor, Ironhold Certification Services
The Asset-Based Approach: Method
Asset-based risk assessment runs in a fixed sequence, and its discipline is exactly what makes it both thorough and, past a certain estate size, exhausting.
Step 1 — Build the asset inventory. Every information asset and associated asset within scope gets logged: hardware, software, data repositories, cloud services, physical media, key personnel functions, facilities. This inventory is not a risk-assessment-only artifact — it's the same inventory required by control 5.9, and in a mature ISMS the risk team should be consuming an inventory that asset owners already maintain, not building a parallel one from scratch.
Step 2 — Assign asset owners and values. Each asset gets an owner accountable for its protection and a value or criticality rating, usually derived from its importance to confidentiality, integrity, and availability of the business process it supports.
Step 3 — Identify threats per asset. For each asset, list the realistic threat sources that could act against it — malicious external actors, malicious insiders, accidental human error, environmental events, technical failure. Threat intelligence feeding into this step is itself a control area; see threat intelligence under control 5.7 for how organizations formalize threat-source input rather than guessing.
Step 4 — Identify vulnerabilities per asset. For each threat identified, determine what weakness in the asset, its configuration, or its surrounding controls would let that threat actually succeed.
Step 5 — Score and prioritize. Combine likelihood (how probable is it that the threat exploits the vulnerability) and impact (what happens to CIA if it does) into a risk score, using consistent criteria across the whole register, then rank for treatment.
Worked Mini-Example: Asset-Based Register Extract
Asset | Owner | Threat | Vulnerability | Likelihood (1–5) | Impact (1–5) | Risk Score | Risk Owner |
|---|---|---|---|---|---|---|---|
Customer database (PostgreSQL, prod) | Head of Engineering | External attacker exploits unpatched CVE | Patch cycle lags 45+ days behind vendor release | 3 | 5 | 15 | CTO |
HR file share (on-prem NAS) | HR Director | Insider copies files before resignation | No DLP monitoring on file share | 2 | 4 | 8 | HR Director |
Employee laptops (fleet of 340) | IT Manager | Device theft from vehicle/public location | Disk encryption not enforced fleet-wide | 3 | 3 | 9 | IT Manager |
Payroll SaaS provider | Finance Director | Vendor suffers a breach exposing PII | No contractual security review of vendor | 2 | 4 | 8 | Finance Director |
Office Wi-Fi access points | Facilities Manager | Rogue access point / eavesdropping | WPA2-PSK shared credential, rarely rotated | 3 | 2 | 6 | IT Manager |
This is legible at five rows. Fenwick's actual register had 4,187 of them, most scoring in the 4–9 range because most assets are, individually, moderately important and moderately protected — which is exactly the trap. A risk score distribution dominated by mid-range noise buries the handful of genuinely severe risks in a sea of laptops and printers, and nobody has the patience to sort 4,000 rows to find them.
Asset-Based: Pros and Cons
Dimension | Asset-Based Strength | Asset-Based Weakness |
|---|---|---|
Granularity | Every individual asset gets explicit consideration; nothing in the inventory is silently skipped | Granularity becomes a liability past a few hundred assets — signal drowns in volume |
Auditor familiarity | Extremely well understood by legacy auditors and ISO 27005:2013-era templates | Some auditors now expect to see business-risk framing even within an asset-based register, and a pure technical listing can look dated |
Traceability | Direct, obvious line from a specific asset to a specific control decision | Weak at surfacing risks that emerge from interactions between assets, or from business/contractual context |
Maintenance | Naturally stays synchronized with the asset inventory if that inventory is kept current | Every new asset (every new SaaS tool, every new laptop) technically requires new risk analysis — a heavy ongoing burden |
Cloud/SaaS fit | Works reasonably for a small, well-bounded server estate | Struggles badly where "the asset" is a shared multi-tenant service you don't control end to end |
The 5.9 Connection
Asset-based risk assessment and control 5.9 (inventory of information and other associated assets) are natural partners, which is exactly why the model persists — it reuses infrastructure you need anyway. If you're running asset-based risk identification, invest first in getting the underlying inventory right: consistent asset categories, a single source of truth (not a spreadsheet forked three ways), clear ownership, and a change process that adds risk review as a step whenever a new asset is provisioned. Organizations that skip this and build the risk register independently of the inventory end up maintaining two lists that drift apart within two quarters. Full detail on building that inventory correctly sits in the guide to asset management under controls 5.9 through 5.14.
"Asset-based only works as well as your inventory. I've seen risk registers that were internally gorgeous — perfect scoring, perfect formatting — sitting on top of an asset list that hadn't been updated in fourteen months. The register was lying to everyone who read it and nobody knew." — Sarah Okonkwo, Risk Manager, Corrigan Steel & Fabrication
The Scenario-Based Approach: Method
Scenario-based risk assessment inverts the starting point. Instead of asking "what assets do we have, and what could threaten each one," it asks "what are the plausible bad things that could happen to this business, and how would we know if one was unfolding."
Step 1 — Convene the right people. Scenario identification is a workshop discipline more than a spreadsheet discipline. It needs business process owners, technical leads, and risk facilitators in the same room (or call), because good scenarios come from people who understand both what the business depends on and how the technology underneath it can fail.
Step 2 — Brainstorm and validate scenarios. Scenarios are written as short narrative statements naming a threat actor or trigger, an action, and a consequence: "A ransomware affiliate gains initial access via a phished credential and encrypts production order-management data, halting fulfillment for 72+ hours." Each candidate scenario is checked against scope — is it actually plausible for this organization, this architecture, this threat landscape — and against redundancy, so you don't end up with six near-duplicate scenarios describing the same underlying event.
Step 3 — Attach context, not just narrative. Each retained scenario gets enriched with the assets, data classifications, and processes it would actually touch — this is where asset detail re-enters the picture, as supporting evidence rather than the organizing spine.
Step 4 — Assess likelihood and impact per scenario. Using the same criteria discipline as any other method, score each scenario for probability and business consequence — financial, operational, regulatory, reputational.
Step 5 — Prioritize and assign ownership. Because scenarios are inherently business-framed, ownership naturally lands with business or platform leaders rather than defaulting to IT for everything, which tends to produce sharper accountability.
Worked Scenario Examples
Scenario | Threat Source | Assets/Processes Touched | Likelihood (1–5) | Impact (1–5) | Risk Score | Risk Owner |
|---|---|---|---|---|---|---|
Ransomware encrypts production order-management data, halting fulfillment | Organized cybercrime affiliate | Order-management DB, fulfillment API, on-call engineering | 3 | 5 | 15 | COO |
Departing sales engineer exfiltrates customer contact and pricing data to a new employer | Malicious insider (voluntary leaver) | CRM export function, sales laptop, cloud storage sync | 3 | 4 | 12 | Head of Sales |
Misconfigured cloud storage bucket exposes customer claims documents publicly | Configuration error / no review gate | Cloud storage service, DevOps pipeline, customer PII | 2 | 5 | 10 | Head of Engineering |
Third-party customs broker API outage during peak season breaches contractual delivery windows | Vendor availability failure | Broker API integration, TMS, contractual penalty clauses | 3 | 5 | 15 | COO |
Business email compromise leads to fraudulent wire transfer to a fake supplier | External social engineering | Finance email accounts, payment approval workflow | 3 | 4 | 12 | CFO |
Notice what happened to Fenwick's actual $2.1 million exposure once it was framed as a scenario rather than as five disconnected asset rows (the API gateway, the TMS server, the contractual clauses, the on-call rotation, the broker relationship): it became a single, board-legible line with an obvious owner and an obvious next step — negotiate uptime guarantees into the broker contract, build a documented failover path, and rehearse the incident response plan against exactly that narrative.
Scenario-Based: Pros and Cons
Dimension | Scenario-Based Strength | Scenario-Based Weakness |
|---|---|---|
Business relevance | Naturally speaks the language of the leadership team; scenarios map to actual business consequences | Requires participants who understand the business well enough to write realistic scenarios — weak facilitation produces vague ones |
Efficiency | A well-run scenario workshop can produce a defensible register in days, not months | Depends entirely on coverage — a scenario nobody thought of is a risk nobody assessed |
Cloud/SaaS fit | Excellent — a scenario like "our SaaS payroll vendor suffers a breach" doesn't require you to model infrastructure you don't control | Can understate technical granularity where a specific, narrow technical control gap needs its own line item |
Cross-functional risk | Strong at catching risks that live in the interaction between systems, vendors, and people | Requires discipline to avoid scenario sprawl or scenarios so broad they can't be scored meaningfully |
Auditor familiarity | Increasingly well accepted, especially by auditors trained post-2022 revision | A minority of older-school auditors may ask more probing questions about how you assure completeness of coverage |
"The first time a client showed me a scenario-based register instead of an asset list, my honest first reaction was suspicion — where's the rest of it? Then I asked them to walk me from scope to coverage, and they could, cleanly, scenario by scenario. That's the actual test. Not the format. Coverage and traceability." — Marcus Webb, Principal Auditor, Ironhold Certification Services
Side-by-Side: How the Two Methods Actually Compare
Criterion | Asset-Based | Scenario-Based |
|---|---|---|
Coverage of technical detail | High — every asset gets explicit review | Moderate — depends on scenario granularity |
Coverage of cross-functional/business risk | Low to moderate — often missed unless explicitly modeled | High — scenarios are written at the business-consequence level |
Effort to build initially | High — proportional to asset count | Moderate — proportional to workshop quality, not estate size |
Effort to maintain | High — every new asset needs review | Moderate — new scenarios added as the threat landscape or business model shifts |
Scalability to large/complex estates | Poor past a few hundred assets without heavy tooling | Good — scenario count grows far slower than asset count |
Fit for cloud-native/SaaS organizations | Weak — "the asset" is often outside your control | Strong — scenario framing sidesteps needing to model infrastructure you don't own |
Fit for OT/ICS or hardware-heavy estates | Strong — physical and technical asset granularity matters | Moderate — scenarios can miss narrow technical vulnerabilities without asset-level supplementation |
Auditor familiarity | Very high — the historical default | Growing steadily; fully standard-compliant since the 2022 revision |
Board/executive legibility | Low — technical framing rarely lands with non-technical leadership | High — narrative framing maps directly to business consequences |
Best single failure mode | Volume drowns signal | Coverage gaps from unimagined scenarios |
Read this table as a diagnostic, not a scorecard — there is no overall "winner" here, and any attempt to declare one is itself a sign the method hasn't been matched to the organization it's being applied to.
Effort, Cost, and Tooling: What Each Method Actually Costs You
Every conversation about methodology eventually comes back to a budget question, so it's worth putting rough, illustrative numbers on the table rather than leaving effort as an abstraction. These figures come from patterns across the organizations profiled in this article and comparable engagements — they are illustrative planning inputs, not a quoted rate card, and your own numbers will vary with estate complexity and internal maturity.
Org Size | Asset-Based: Initial Build | Asset-Based: Annual Maintenance | Scenario-Based: Initial Build | Scenario-Based: Annual Maintenance |
|---|---|---|---|---|
<100 employees, cloud-native | 3–5 weeks (elapsed, part-time) | 1–2 weeks/year | 1–2 weeks (2–3 workshops) | 3–5 days/year |
100–500 employees | 8–14 weeks | 3–5 weeks/year | 3–5 weeks | 1–2 weeks/year |
500–2,000 employees, mixed estate | 4–6 months | 6–10 weeks/year | 6–8 weeks | 3–4 weeks/year |
2,000+ employees or OT/ICS-heavy | 6–12 months | 10–16 weeks/year | 10–14 weeks (plus ongoing asset sweep) | 5–7 weeks/year |
The maintenance column is where asset-based methodology quietly accumulates its real cost. Every new SaaS subscription, every new laptop model, every decommissioned server technically triggers a review cycle, and in organizations that grow headcount or tooling quickly, that maintenance burden compounds year over year until — as happened at Fenwick — nobody has capacity left to do anything with the register except keep it technically current.
Tooling choice interacts with this heavily. A spreadsheet-based asset register is viable up to a few hundred assets before version control and formula drift become their own risk. Past that point, organizations typically move to a dedicated GRC platform that can ingest asset data from a CMDB or cloud inventory API automatically, which reduces — but doesn't eliminate — the maintenance burden. Scenario-based registers are lighter-weight by nature and often survive comfortably in a well-structured spreadsheet or lightweight GRC module even at larger organizational scale, precisely because scenario count grows far more slowly than asset count.
A 12-Question Signals Checklist to Pick Your Starting Point
Before committing to a methodology, walk your leadership team through these questions. A "yes" majority in the left column points toward asset-based or hybrid; a "yes" majority in the right column points toward scenario-based or a scenario-led hybrid.
# | Signal Favoring Asset-Based | Signal Favoring Scenario-Based |
|---|---|---|
1 | We can enumerate our full asset inventory in under a day | Our asset inventory changes weekly and is hard to keep current |
2 | Most of our infrastructure is owned and on-premises | Most of our infrastructure is third-party SaaS or cloud-managed |
3 | We operate OT/ICS or specialized hardware | We are a pure software/services business |
4 | Our leadership team is technically fluent enough to read an asset-level register | Our leadership team needs risk framed in business/financial terms to act on it |
5 | Regulatory scrutiny explicitly expects asset-level technical granularity | Regulatory scrutiny is more concerned with business continuity and data protection outcomes |
6 | We have dedicated headcount to maintain a large register | Risk management is a part-time responsibility layered onto other roles |
7 | Our biggest historical incidents trace to specific technical assets | Our biggest historical incidents trace to vendor, contractual, or process failures |
8 | Our estate is largely static year over year | Our estate (headcount, tooling, architecture) changes substantially every quarter |
9 | We've never run a cross-functional risk workshop before | We already run cross-functional planning sessions regularly |
10 | Asset criticality varies enormously across our estate | Most of our risk is concentrated in a handful of core business processes |
11 | Auditors we've worked with previously expect an asset-based structure | We're building our ISMS methodology fresh, with no legacy register to reconcile |
12 | We need forensic-level traceability from control to specific hardware | We need board-level clarity more than granular traceability |
The Hybrid Approach: Scenario-Led With Asset Context
Most mature ISMS programs I've worked with over the last several years land somewhere in the middle, and for good reason — the hybrid model captures most of the upside of both parents and most of the downside of neither.
The hybrid approach is scenario-led: risk identification starts from business-relevant scenarios, workshopped with the same cross-functional participation as a pure scenario-based process. But each scenario, once retained, is explicitly decomposed into the assets, data classifications, and technical components it touches, and — critically — the asset inventory itself is periodically swept for any asset that isn't clearly covered by at least one existing scenario. That sweep is the safety net against the scenario method's core weakness (coverage gaps): if you find an asset with no scenario touching it, that's either evidence the asset is genuinely low-risk and can be explicitly noted as such, or it's a missing scenario that needs to be written.
In practice this looks like a two-column working document: scenarios on one axis, the asset inventory on the other, with a mapping showing which scenarios touch which assets. Gaps in that mapping are the agenda for the next risk workshop.
Hybrid Component | Source Discipline | Purpose |
|---|---|---|
Scenario narratives | Scenario-based | Business-legible framing, cross-functional risk capture |
Asset-to-scenario mapping | Both | Ensures scenario doesn't float free of technical reality |
Asset inventory coverage sweep | Asset-based | Catches gaps a workshop alone would miss |
Likelihood/impact scoring | Shared criteria | Keeps results consistent regardless of entry point |
Risk ownership | Scenario-based | Business owners, not default-to-IT |
Control mapping to Annex A | Both | Same downstream SoA regardless of identification method |
flowchart TD
A[Start: Define ISMS scope] --> B{What best describes your estate?}
B -->|Small/simple, well-bounded, on-prem heavy| C[Asset-Based]
B -->|Cloud-native, SaaS-first, or rapidly scaling| D[Scenario-Based]
B -->|Large, complex, mixed OT/IT, or high regulatory scrutiny| E[Hybrid]
C --> F[Build/confirm asset inventory 5.9]
F --> G[Identify threats + vulnerabilities per asset]
G --> H[Score, prioritize, treat]
D --> I[Workshop plausible risk scenarios]
I --> J[Attach asset/process context to each scenario]
J --> H
E --> K[Workshop scenarios AND sweep asset inventory for gaps]
K --> L[Map scenarios to assets; close coverage gaps]
L --> H
H --> M[Populate risk register]
M --> N[Feed risk treatment plan and SoA]"I don't ask clients to pick a religion. I ask them to pick a starting point that matches how their business actually thinks about risk, and then make sure the other perspective still gets checked somewhere in the process. That's the hybrid model, whether or not anyone calls it that." — Dr. Elena Cho, CISO, Meridian Health Analytics
How to Choose: Matching Method to Organizational Profile
The right starting point depends less on preference and more on a small set of concrete organizational signals: estate size and composition, cloud maturity, regulatory context, and the sophistication of the people who will actually use the output.
Organizational Profile | Recommended Starting Point | Why |
|---|---|---|
Early-stage SaaS startup, <100 employees, cloud-native | Scenario-based | Few owned physical/technical assets; risk lives in vendor dependencies, code, and access — scenarios capture this faster than an asset crawl |
Fast-growing mid-market SaaS, 100–500 employees | Scenario-based with periodic asset sweep (light hybrid) | Growth outpaces any asset register's ability to stay current; scenarios scale better with headcount and product surface area |
Large enterprise, mixed on-prem/cloud, multiple business units | Hybrid | Enough estate complexity that asset gaps are genuinely dangerous, but enough business complexity that pure asset lists won't reach leadership |
Manufacturing/OT-heavy, industrial control systems | Asset-based, supplemented with OT-specific scenarios | Physical and technical asset granularity is safety-critical; scenario framing alone can miss narrow OT vulnerabilities |
Heavily regulated financial services or healthcare | Hybrid, leaning asset-based for regulated data stores | Regulators and auditors often expect to see explicit technical granularity around regulated data, alongside business-scenario framing for board reporting |
Government/public sector with legacy infrastructure | Asset-based | Legacy estates are often large, poorly documented, and genuinely benefit from a forced enumeration exercise |
Managed service provider / MSSP | Hybrid, scenario-led per client engagement | Each client relationship is effectively its own risk scenario set layered on a shared internal asset base |
The honest failure mode to watch for is choosing a method because it's familiar rather than because it fits. Asset-based is what most legacy consultants were trained on, so it gets defaulted to even for organizations — like a 40-person cloud-native startup — where it produces a register nobody can maintain past the first audit cycle. Scenario-based is newer and sounds more sophisticated, so it sometimes gets adopted by organizations — like a 200-year-old manufacturer with a basement full of undocumented legacy servers — where a forced asset enumeration would actually have surfaced things nobody in the room knew existed.
"We picked scenario-based because it sounded modern, not because it fit. Eighteen months later we found out during an incident that we had a database nobody on the risk team knew existed, because nobody had ever been forced to walk the actual server room. The scenario workshop never would have surfaced it — nobody could write a scenario about a system they didn't know was there." — Tomas Reyes, Head of GRC, Vantage Cloud Works
Migrating From Asset-Based to Scenario-Based: A Practical Roadmap
Organizations rarely switch methods on a clean slate — almost always, someone like Priya inherits an asset-based register that has become unmanageable and needs to migrate to something leaner without losing certification continuity or the institutional knowledge embedded in years of existing risk data.
Phase | Activity | Typical Duration | Key Output |
|---|---|---|---|
1. Audit the existing register | Identify which existing asset-level risks are genuinely distinct vs. duplicative/noise | 2–3 weeks | Reduced, deduplicated risk inventory with clear signal |
2. Cluster surviving risks into scenarios | Group related asset-level risks under candidate scenario narratives | 1–2 weeks | Draft scenario list mapped back to legacy risk IDs |
3. Workshop gaps | Cross-functional session to identify business scenarios the old register never captured | 1 week | Net-new scenarios (cross-functional/vendor/contractual risks) |
4. Re-score under unified criteria | Apply one consistent likelihood/impact scale across old and new entries | 1–2 weeks | Fully re-scored, comparable register |
5. Retire the legacy structure | Formally document the methodology change and rationale in the risk assessment methodology document | 1 week | Updated methodology doc, ready for audit review |
6. Run one full cycle before certification/surveillance | Prove the new method produces consistent, repeatable results | One full review cycle (often quarterly) | Evidence of methodology maturity for the auditor |
The step organizations most often skip is Phase 5 — documenting why the change happened. An auditor doesn't need to approve your methodology choice, but they absolutely will ask why this year's register looks structurally different from last year's, and "we decided the old way wasn't working" is a fine answer only if it's written down in the methodology document itself, dated, and tied to a management decision — not improvised in the audit room.
What Carries Over and What Doesn't
Not every legacy asset-level risk deserves a scenario of its own, and deciding which ones do is the single most judgment-heavy part of a migration. As a working rule: a legacy risk earns its own dedicated scenario if it represents a genuinely distinct failure mode with its own consequence and its own owner. A legacy risk gets folded into a broader scenario if it's really one instance of a pattern already captured elsewhere — three different rows about three different unpatched servers, for instance, usually collapse into a single "unpatched internet-facing system exploited by an external attacker" scenario, with the specific servers listed as supporting context rather than as separate register entries.
What should never happen is silent deletion. Every legacy risk ID should resolve to one of three outcomes in the migration record: absorbed into a named scenario, explicitly retired with a documented rationale (the asset was decommissioned, the risk was accepted and formally signed off, or it was genuinely duplicative), or escalated into a new standalone scenario because it turned out to be more significant than its old asset-level framing suggested. That three-way disposition list is exactly what a skeptical auditor — or a skeptical new hire six months later — will want to see if they ask "where did the old register go."
"The migration itself is rarely the hard part. Explaining the migration to an auditor who remembers your old register is the hard part — and that's a five-minute conversation if you documented the decision when you made it, and a bad afternoon if you didn't." — James Fitzgerald, Lead Implementer, Fitzgerald Risk Partners
Common Mistakes (In Both Directions)
Mistake | Which Method It Afflicts | The Fix |
|---|---|---|
Building a 4,000-row register nobody reads past initial creation | Asset-based | Set a materiality threshold; don't score assets below a certain value/criticality individually — group them |
Treating "scenario-based" as an excuse to skip technical depth entirely | Scenario-based | Attach real asset/process context to every retained scenario; don't leave scenarios as vague narrative only |
Letting the asset inventory and risk register drift out of sync | Asset-based | Trigger risk review automatically whenever the 5.9 inventory changes, not on a fixed annual schedule |
Writing scenarios so broad they can't be meaningfully scored ("cyberattack happens") | Scenario-based | Require every scenario to name a specific threat source, action, and consequence before it's accepted |
Switching methods without documenting rationale | Both | Update the risk assessment methodology document at the moment of decision, not retroactively before an audit |
Copy-pasting the same likelihood/impact score across dozens of entries | Asset-based (most common) | Force distinct justification text per score, even briefly, to break the copy-paste habit |
Running scenario workshops with only technical staff in the room | Scenario-based | Mandate at least one business-process owner per workshop; technical-only scenarios miss business consequence |
No mechanism to catch assets untouched by any scenario | Scenario-based (if not hybridized) | Run a periodic coverage sweep against the 5.9 inventory, even lightweight and infrequent |
Confusing "quantity of risks identified" with "quality of risk identification" | Both | Judge the register by whether it changed a treatment decision, not by row count |
The Four Mistakes That Actually Fail Audits
Of the nine mistakes above, four account for the overwhelming majority of nonconformities I've seen raised against risk assessment methodology specifically, so they're worth calling out in prose rather than leaving buried in a table row.
The first is inconsistent criteria applied across assessment cycles — a likelihood scale that meant one thing last year and a subtly different thing this year, with no documented reason for the change. This directly violates the "consistent, valid, and comparable results" language in Clause 6.1.2, and it's the single most common finding auditors raise regardless of which identification method sits underneath it.
The second is scope drift — an asset or process that's clearly inside the ISMS boundary but has no corresponding entry in the risk register under either method. This is exactly what the hybrid coverage sweep exists to catch, and it's why pure scenario-based programs that skip that sweep step remain exposed to it indefinitely.
The third is stale risk ownership — a risk owner named in the register who left the organization eight months ago, or a generic "IT department" listed as owner for a risk that's really a business decision. Auditors increasingly probe risk ownership specifically, because a risk without a real, current, empowered owner is a risk that won't get treated regardless of how well it was identified.
The fourth is treating the risk assessment as a point-in-time compliance artifact rather than a living process — reviewed once before the certification audit, then left untouched until the year-three recertification. Both methodologies require periodic review under Clause 6.1.2's "at planned intervals," and a register with a single review date sitting alone in its history is a red flag regardless of how sophisticated the identification method looks.
Case Study One: Fenwick Logistics — From 4,000 Rows to a Board-Legible Register
Priya's fix wasn't a wholesale rip-and-replace. Over nine weeks, working alongside a two-person GRC contractor team and her existing IT lead, Fenwick clustered the 4,187-row asset register down to roughly 60 distinct risk scenarios, each explicitly mapped back to the assets it touched. The customs-broker-API scenario — the one that had never had a natural home in the old structure — became the single highest-scored item in the new register and drove a concrete treatment decision: a renegotiated contract with a 99.9% uptime SLA and financial penalties running the other direction, plus a documented failover procedure rehearsed twice a year.
Metric | Before | After (9 weeks later) |
|---|---|---|
Risk register line items | 4,187 | 62 scenarios (mapped to ~380 underlying assets) |
Time to review full register at leadership level | Never attempted | 45 minutes, quarterly |
Highest-scored, previously unidentified risk | Not captured | Customs broker API dependency (score 15) |
Estimated exposure addressed by top scenario | $2.1M penalty exposure | Contractual SLA + failover reduced residual exposure by an estimated 70% |
Certification outcome | N/A (pre-migration) | Certified on schedule, zero major nonconformities on risk assessment methodology |
The detail that made the difference wasn't the workshop technique — it was the discipline of forcing every one of the 4,187 legacy rows through the three-way disposition described earlier. Roughly 3,400 rows were absorbed into a small number of "commodity endpoint" and "standard SaaS vendor" scenarios covering routine, well-understood risk. Around 700 rows were formally retired with documented rationale — mostly decommissioned hardware nobody had removed from the register. The remaining rows escalated into the 62 final scenarios, and it was in that escalation step that the customs-broker dependency finally got named as a single, ownable risk instead of five disconnected asset entries nobody had ever looked at together.
Case Study Two: Corrigan Steel & Fabrication — Why Asset-Based Stayed the Right Call
Not every organization should migrate. Corrigan Steel, a 900-employee industrial fabricator running a mix of legacy programmable logic controllers, a modern ERP system, and a slowly-being-modernized OT network, considered switching to scenario-based after hearing about it at an industry conference. Sarah Okonkwo's team ran a pilot scenario workshop alongside the existing asset-based process and found that scenario framing consistently missed narrow, safety-relevant technical gaps — an unpatched HMI (human-machine interface) terminal on the factory floor, a legacy PLC still using a default vendor credential — because nobody in the workshop room thought to write a scenario about a specific piece of equipment they didn't think about day to day.
Metric | Asset-Based (Retained) | Scenario-Based Pilot (Discontinued) |
|---|---|---|
OT-specific technical gaps identified | 14, including 3 rated critical | 2 |
Time to build/maintain per cycle | ~6 weeks (heavy, but stable estate) | ~2 weeks |
Leadership engagement in review | Moderate — OT gaps clearly actionable to plant management | Higher — but missed items plant management most needed to see |
Decision | Retained asset-based, supplemented with light OT-specific scenario add-ons for supply-chain and ransomware narratives | — |
Corrigan's conclusion wasn't that scenario-based is inferior — it's that a hardware-dense, legacy-heavy OT estate needs the forced enumeration discipline that asset-based provides, and layering a handful of business-level scenarios on top (supply chain disruption, ransomware against the ERP) captured the cross-functional risks without abandoning the technical granularity that actually protects the factory floor.
Sarah's team kept the pilot's output rather than discarding it entirely — the two scenarios that did surface useful cross-functional framing (supply chain disruption and ransomware against the ERP) were retained permanently as a supplement to the asset-based core, which is precisely the light hybrid pattern described earlier in this article, arrived at independently through trial rather than by design.
Case Study Three: Vantage Cloud Works — A Clean Scenario-Based Build
Vantage Cloud Works, a 140-person B2B SaaS company that had never held any formal risk register before pursuing certification, skipped asset-based entirely. Tomas Reyes's team ran three half-day scenario workshops with engineering, sales, customer success, and finance leadership, producing 34 scenarios in total before the false start described earlier (the undiscovered database) forced them to add a lightweight asset-sweep step — converting their pure scenario approach into a light hybrid within the first year.
Metric | Initial Scenario-Based Build | After Adding Asset-Sweep Step |
|---|---|---|
Time to first complete register | 3 weeks | +1 week for sweep integration |
Scenarios identified | 34 | 34 (unchanged) plus 1 newly discovered legacy database flagged for decommission |
Executive engagement | High from day one — scenarios discussed directly in leadership meetings | Maintained |
Certification body feedback | Minor observation: request clearer scenario-to-asset traceability | Resolved before Stage 2 audit |
Vantage's experience is a useful counterpoint to Corrigan's: a pure scenario-based build is a genuinely viable path for a young, cloud-native company, provided the team stays honest about the method's blind spot and builds a lightweight check for it before an incident does it for them. The fix cost Vantage one additional week of effort against a three-week initial build — a small price for closing the exact gap that a forced asset enumeration would have caught for free, and evidence that the hybrid pattern tends to emerge naturally in mature programs regardless of which method they started from.
Who Owns What: A RACI for Risk Identification
Regardless of method, ambiguous ownership during the identification process itself is a common source of stalled risk assessments. This RACI baseline works for either method, with the "Contributes" and "Accountable" columns swapping emphasis depending on which philosophy leads.
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Maintain asset inventory (5.9 baseline) | IT/Asset Owners | ISMS Manager | Department Heads | Leadership Team |
Facilitate scenario workshops | ISMS Manager / GRC Lead | CISO or equivalent | Business Process Owners | Board/Executive Team |
Define risk criteria and scoring scale | ISMS Manager | Top Management | Internal Audit | All Risk Owners |
Identify threats/vulnerabilities (asset-based) | Technical Asset Owners | ISMS Manager | Threat Intelligence Function | CISO |
Write and validate scenario narratives | Cross-functional Workshop Participants | ISMS Manager | Legal, Finance, Engineering Leads | Leadership Team |
Score identified risks | ISMS Manager | Risk Owner (named per risk) | Subject Matter Experts | Top Management |
Approve final risk register for the cycle | ISMS Manager | Top Management | Internal Audit | Certification Body (on request) |
The row most often left blank in practice is "Approve final risk register for the cycle" — plenty of organizations produce a register nobody with actual management authority ever formally signs off on, which becomes an awkward gap the moment an auditor asks who approved this version and when.
Named Pull Quotes, Gathered
"Asset-based risk assessment isn't wrong. It's a tool that fits a certain shape of organization, and for the last decade it's been handed to organizations shaped completely differently, because it's what the training courses taught." — Priya Nandakumar, ISMS Manager, Fenwick Logistics
"I ask every new client one question before we pick a methodology: can your leadership team read your current risk register out loud and understand it in one sitting? If the answer is no, the method is wrong for the audience, whatever else is right about it." — Dr. Elena Cho, CISO, Meridian Health Analytics
What to Show an Auditor, Whichever Method You Pick
Auditors don't certify methodologies in the abstract — they sample evidence. Regardless of whether you land on asset-based, scenario-based, or hybrid, the underlying evidence trail an auditor will want to pull is broadly the same, and preparing it in advance turns a potentially tense conversation into a routine walkthrough.
Evidence Item | Asset-Based Version | Scenario-Based Version |
|---|---|---|
Documented methodology | Description of asset inventory scope, threat/vulnerability identification process, scoring criteria | Description of scenario workshop process, participant roles, validation criteria, scoring criteria |
Proof of scope coverage | Asset inventory reconciled against ISMS scope statement | Scenario-to-asset/process mapping reconciled against ISMS scope statement |
Consistency across cycles | Prior period's register, showing stable criteria applied | Prior period's scenario list, showing stable criteria and scenario evolution rationale |
Risk ownership evidence | Named, current owners per asset-level risk | Named, current owners per scenario, typically at business-leader level |
Link to treatment | Traceability from scored risk to Statement of Applicability control decision | Same traceability requirement, scenario as the unit instead of asset |
Management review evidence | Minutes or records showing leadership reviewed and acted on the register | Minutes or records showing leadership reviewed and acted on the register — usually easier to produce given scenario legibility |
The one item auditors ask about more with scenario-based programs specifically is the second row — proof of scope coverage — precisely because it isn't self-evident the way an asset list is. Keep the scenario-to-asset mapping current and be ready to walk an auditor through it live; that single artifact resolves the majority of scenario-based audit questions before they're even fully asked.
The Strategic Close: Method Choice as Competitive Signal
There's a version of this decision that treats it as a compliance chore — pick whichever method gets you through Stage 2 with the fewest questions, and move on. That version misses the actual opportunity sitting inside this choice. A risk identification method that your leadership team can actually read, discuss, and use to make resourcing decisions is not just easier to certify — it's a genuine operational asset that pays for itself independent of the certificate. Fenwick's board didn't just get a passing audit; they got, for the first time, a one-page view of their single largest unaddressed business exposure, and they funded the fix inside a quarter. That's the difference between a risk register that exists because ISO 27001 requires one, and a risk register that exists because the business needs one — ISO 27001 just happens to require it too.
Whichever method you land on — asset-based, scenario-based, or a deliberate hybrid — the test is the same one Marcus Webb applies in every audit: can you walk from your defined scope to full, consistent, comparable risk coverage, and can you explain, in plain language, why you built it the way you did. Get that right and the certificate follows. Get it right early, and you also get a document your executive team actually uses — which is the difference between an ISMS that survives one certification cycle and one that becomes how the business actually thinks about risk.
If you're mid-decision right now, don't try to resolve it in the abstract. Run both methods against your five highest-value processes for a week, side by side, and see which one surfaces the risk that would actually hurt you most — that's usually all the evidence you need.
Ready to put a number on where your ISMS stands before you commit to a methodology overhaul? PentesterWorld's ISO 27001 Gap Analysis Tool will show you exactly where your current risk identification approach is leaving coverage gaps, and our Risk Scoring Calculator lets you test asset-based and scenario-based scoring side by side on your own data before you rebuild anything. If you're starting the register itself, our ISO 27001 Risk Register Template is built to support either structure — or a hybrid of both — without forcing a rebuild later, and our hands-on lab to build a sample risk treatment plan walks you from a scored risk straight through to a defensible treatment decision. For teams building the whole ISMS from the ground up, the Complete ISO 27001 Implementation Guide eBook covers exactly where this methodology decision fits into your broader certification timeline. And if any of the terminology in this piece was new to you, our ISO 27001 glossary of terms is the fastest way to get everyone on the project team speaking the same language before your first risk workshop.
For organizations running parallel frameworks, this same identification question comes up under NIST SP 800-30's threat-event-based guidance and within a SOC 2 risk assessment approach — the underlying logic of choosing asset-based, event/scenario-based, or hybrid identification translates directly across all three, which is good news if you're managing more than one framework at once. And whichever method you choose, remember it's only step one of a longer chain — see how identification feeds scoring in the comparison of qualitative vs quantitative risk assessment, how the results get organized in the guide to building an ISO 27001 risk register, and how the whole risk process fits inside the broader planning requirements of Clause 6.