ISO 27005 and ISO 27001: Information Security Risk Management Guidance

The Spreadsheet That Almost Cost Corvale Freight Systems a $3.2 Million Contract

Dana Okafor had been Corvale Freight Systems' network engineer for six years before her VP of Operations walked into her cubicle on a Tuesday morning in March and told her she was now, as of that afternoon, the company's Information Security Manager. Corvale had just signed a letter of intent with a European grocery retailer worth $3.2 million a year in freight and warehousing revenue, and the retailer's procurement team had made ISO 27001 certification a condition of the final contract, with a nine-month deadline attached.

Nobody at Corvale had done this before. Dana did what any good engineer does when handed an unfamiliar problem: she opened a blank spreadsheet.

Over three weeks, she built what she believed was a risk assessment. She listed every IT asset she could think of — the transportation management system (TMS), the warehouse control system, forty-odd laptops, the file server, the payroll system — and next to each one she typed a likelihood score from 1 to 5 and an impact score from 1 to 5, multiplied them, and called anything above 15 "high risk." She picked the numbers based on gut feel, mostly on a Thursday afternoon, mostly alone.

What Dana's spreadsheet did not contain: any scenario for what happens if a ransomware operator encrypts the warehouse control system three days before peak holiday shipping season. Any consideration of the operations manager who'd handed in her notice the week before and still had admin rights to the TMS. Any thought about what happens if the third-party routing software vendor gets compromised and pivots into Corvale's network. Dana had inventoried assets. She had not thought about how those assets actually get hurt.

The Stage 1 auditor found the gap in about twenty minutes. The finding wasn't dramatic — it never is. It read, in essence: the risk assessment lacks a consistent, defensible methodology; likelihood and impact criteria are undocumented; risk owners are not assigned; and there is no clear traceability from identified risks to the controls selected in the Statement of Applicability. Translation: this is not a repeatable process, it's one person's opinion on a Thursday.

The certification timeline slipped. The retailer's procurement team, watching the clock on their nine-month deadline, started asking pointed questions about whether Corvale could actually deliver. The $3.2 million was suddenly not a formality — it was at risk.

Here's the part that stung when Dana and I talked about it later, after I'd been brought in to help rebuild the assessment: the guidance she needed had been sitting in front of her the whole time, publicly available from ISO for the price of a PDF, and nobody on her team had opened it. They'd assumed that anything with "ISO/IEC 270-something" in the title required its own audit and its own certificate, the way ISO 27001 does. It doesn't. ISO/IEC 27005 — Guidance on managing information security risks — isn't a standard you get certified against. It's a manual for doing the thing ISO 27001 Clause 6 requires you to do, written by the same technical committee, aligned to the same terminology, and free of the guesswork Dana had been doing alone in a spreadsheet.

This is the story of nearly every ISO 27001 project I've walked into in fifteen years of doing this work across manufacturing floors, hospital IT departments, fintech back offices, and yes, freight companies: teams reinvent risk management from scratch, badly, because they don't realize there's a far better starting point than a blank spreadsheet and a gut feeling. This article is that starting point.

Who This Is For / What You'll Walk Away With

This article is for ISMS managers, risk owners, internal auditors, and consultants who are building or refining the risk assessment and risk treatment work required under ISO 27001 Clause 6, and who want more structure than the bare requirements text gives them. It's also for people, like Dana, three weeks into building a risk register from scratch with no idea a better map exists. You'll walk away knowing exactly what ISO/IEC 27005:2022 is and is not — including why it's guidance, not a certifiable standard — how its risk management process maps onto Clause 6.1.2 and 6.1.3, how to choose between asset-based and scenario/event-based risk identification (and when to blend them), what actually changed in the 2022 revision, and how to fold all of this into a real project plan without turning it into a copy-paste exercise an auditor will see through immediately.

What ISO 27005 Is (And Isn't)

ISO/IEC 27005:2022, currently in its third edition, carries the full title "Information security, cybersecurity and privacy protection — Guidance on managing information security risks." Note the word in that title that matters most: guidance. ISO 27005 is published by the same joint technical committee (ISO/IEC JTC 1/SC 27) responsible for ISO 27001, ISO 27002, and the rest of the ISO/IEC 27000 family, but it sits in a different category of document entirely. ISO 27001 is a requirements standard — it uses "shall" language, it has a formal Annex A of controls, and third-party certification bodies audit organizations against it. ISO 27005 is a guidance document. It has no "shall" statements defining organizational obligations, no accredited certification scheme, and no auditor checklist tied to its clause numbers.

That distinction is not a technicality — it changes how you should use the document. You do not "comply with ISO 27005." There is no certificate that says your organization is 27005-conformant, and no Stage 2 auditor will ever write a nonconformity that cites an ISO 27005 clause number as the broken requirement. What an auditor will cite, if your risk process is thin, is ISO 27001 Clause 6: Planning — risk assessment and objectives — the actual requirement. ISO 27005 exists to help you meet that requirement well, not to add a second layer of obligations on top of it.

What ISO 27005 actually gives you is a fully worked-out risk management process for information security specifically: how to establish context, how to identify risks (using more than one valid method), how to analyze and evaluate them, how to treat them, how to document risk acceptance, and how to keep the whole thing alive through communication and periodic review. ISO 27001 tells you that you must run a risk assessment and a risk treatment process and gives you the outcomes it expects — but it deliberately does not tell you how to structure the mechanics of getting there. That's a choice ISO 27001 leaves to each organization, and it's exactly the gap ISO 27005 was written to fill.

It's part of a broader family worth knowing by name even where this article can't cover it in full — a companion piece on the ISO/IEC 27000 family of standards (covering 27000 itself, 27002, 27005, 27006, 27017, 27018, and others) would be a useful map for placing 27005 among its siblings, though it's not one I can link to directly here. If some of the vocabulary in this article is new, our ISO 27001 terminology and glossary of key terms is a good companion reference to keep open alongside it.

"I've had clients hand me a Statement of Applicability and say, 'we're compliant with 27005 too.' There's no such thing. I tell them: 27005 isn't graded. Your risk assessment is — against Clause 6. Nobody fails an audit for skipping a page of 27005. They fail because their likelihood and impact criteria are undocumented and nobody can explain where a risk score came from." — Lena Kowalski, Lead Auditor, Meridian Assurance Group

The ISO 27001 / 27002 / 27005 / 31000 Relationship

If you're new to this corner of the ISO world, the four standards that keep coming up together can blur into alphabet soup. They shouldn't — each one answers a different question, and understanding the division of labor is what lets you use all four without wasting effort duplicating work across them.

Think of it as a nesting structure. ISO 31000 sits at the outermost layer: it's a generic risk management standard that applies to any kind of organizational risk — financial, operational, reputational, safety, strategic — and it's the source of the vocabulary and process shape (context, assessment, treatment, monitoring, communication) that both 27005 and, indirectly, 27001's Clause 6 borrow from. Our companion article on integrating ISO 31000 with ISO 27001 risk management covers that outer layer in depth.

ISO/IEC 27005 takes ISO 31000's generic shape and applies it specifically to information security risk — the risk that confidentiality, integrity, or availability of information gets compromised. It's the translation layer between "generic enterprise risk management" and "the specific risk assessment and treatment process an ISMS needs."

ISO/IEC 27001 is the certifiable management-system standard. Clause 6 requires an organization to have a risk assessment process and a risk treatment process with defined criteria, and it requires specific outputs (documented risk assessment results, a Statement of Applicability, a risk treatment plan, risk owner sign-off) — but, notably, it does not specify the mechanics of how you get there. That's a deliberate design choice in the standard, not an oversight, and it's exactly where 27005 is useful.

ISO/IEC 27002 answers a different question entirely: once your risk assessment and treatment process has told you which of the 93 Annex A controls are needed, 27002 tells you how to implement each one well. Our detailed comparison of ISO 27001 and ISO 27002 covers that relationship if you want the full picture; the short version relevant here is that 27002 has nothing to do with how you assess risk, only with how you build the controls that a good risk assessment tells you to prioritize.

"People ask me whether they need all four documents open at once. My answer: you need one requirement — 27001 — and you're free to borrow as much structure as you want from the other three. Nobody has ever failed an audit for reading too much good guidance." — Priya Ramanathan, Head of GRC, Kestrel Financial

The ISO 27005 Risk Management Process, Step by Step (Mapped to Clause 6)

ISO 27005 organizes its guidance around a process that will look immediately familiar if you've read Clause 6 of ISO 27001, because it's built from the same underlying logic: establish context, assess risk (identify, analyze, evaluate), treat risk, document acceptance, and keep the whole cycle alive with ongoing communication and review. The value 27005 adds isn't a new process — it's the detail ISO 27001 intentionally leaves out: worked techniques, example criteria structures, and practical discussion of trade-offs at each step. The diagram below shows how the pieces fit together and where each maps to the Clause 6 language your certification auditor will actually be checking.

Illustrative process flow — actual documentation structures vary by organization; this is not an audit checklist.

Context Establishment

This is the step Dana skipped entirely, and it's the one that would have prevented most of her problems downstream. Context establishment means deciding, before you identify a single risk, what your risk assessment criteria actually are: how you'll define and score likelihood, how you'll define and score impact (across confidentiality, integrity, and availability, not just "money lost"), what your risk acceptance threshold is, and who owns the whole process. ISO 27005 pushes you to write these criteria down as a standing methodology document before you touch the register — not to invent them fresh, informally, for each risk as you go, which is what Dana's Thursday-afternoon spreadsheet effectively did. Our step-by-step guide on ISO 27001 risk assessment methodology walks through building this criteria set in detail, and it's worth doing before you read another page of this article if you haven't got a documented methodology yet.

Risk Identification

Once criteria exist, you identify the risks themselves — the actual pairing of an asset (or scenario), a threat, and a vulnerability that could damage confidentiality, integrity, or availability. This is the step where ISO 27005:2022 gives you the most choice, and the most controversy: you can build your identification work around assets (what do we have, what could go wrong with each one), around scenarios or events (what bad things could happen to us, working backward to which assets and controls are implicated), or a deliberate hybrid of both. We cover this decision in depth in a dedicated comparison of asset-based and scenario-based risk assessment approaches — it's a big enough decision that it deserves its own treatment, and a short summary follows later in this article. If you haven't built the register itself yet, our guide on how to build an ISO 27001 risk register covers the practical document structure this whole process assumes.

Risk Analysis

Analysis is where you assign values to each identified risk — typically a likelihood rating and an impact rating, combined into an overall risk level, following whatever criteria you fixed at context establishment. None of the approaches below is mandated by 27001 or by 27005; the standard's value here is laying out the trade-offs so you pick deliberately instead of by accident. Our companion piece on qualitative vs quantitative risk assessment for ISO 27001 goes deeper on choosing between them.

Risk Evaluation

Evaluation compares the analyzed risk level against the acceptance criteria set during context establishment, sorting risks into "needs treatment" and "tolerable as-is." This sounds simple and is the step most teams shortchange, because it requires the acceptance criteria to actually exist and be applied consistently — not adjusted after the fact to make an uncomfortable risk look acceptable. ISO 27005 recommends evaluation also consider risk owners' input at this stage, not just the numbers, since a risk owner may have context (an existing compensating control, a planned system retirement) that changes the practical picture.

Risk Treatment

Treatment is where you decide what to do about each risk that fails evaluation — and ISO 27005, like ISO 31000 before it, frames the options consistently as four choices. This maps directly to Clause 6.1.3's requirement for a risk treatment plan and, from there, into Annex A control selection and your Statement of Applicability. If you haven't built a treatment plan yet, our guide to building an ISO 27001 risk treatment plan covers the mechanics of turning treatment decisions into a tracked, owned action plan.

Risk Acceptance

Every risk, treated or not, needs an explicit, documented acceptance decision from a named risk owner — this is true whether the residual risk after treatment is low or whether you're accepting a higher risk because treatment isn't yet feasible. ISO 27005 is explicit that acceptance is a decision, not a default: risks don't become "accepted" simply because nobody got around to treating them. Our article on defining ISO 27001 risk acceptance criteria and the companion piece on risk owners and accountability in ISO 27001 both dig into how to make this defensible rather than a rubber stamp.

Communication, Consultation, Monitoring & Review

These two activities run alongside every other step rather than after them. Communication and consultation means risk owners, control owners, management, and (where relevant) interested parties are kept in the loop and consulted as the assessment develops — not handed a finished register to sign. Monitoring and review means the whole cycle repeats: risk criteria, identified risks, and treatment decisions get revisited on a schedule and whenever the context changes materially (a new system, a merger, a new regulatory requirement, an actual incident). This is also where risk management connects back into ISO 27001's Clause 9 performance evaluation — internal audits and management review are natural triggers for reviewing whether the risk assessment still reflects reality.

"Context establishment is the step everyone wants to skip because it feels like paperwork before the 'real work.' It is the real work. Every defensible risk score I have ever reviewed traces back to criteria someone wrote down before they started scoring." — Tomás Rivera, CISO, Solandra Health Systems

Asset-Based vs Scenario/Event-Based Identification

One of the more meaningful updates in ISO 27005:2022 is how explicitly it accommodates two different starting points for risk identification, rather than assuming the older, asset-inventory-first approach is the only valid one.

The asset-based approach starts from what you have: build an inventory of information and other associated assets, then for each one work through relevant threats and vulnerabilities. It's thorough, it's easy to explain to an auditor, and it pairs naturally with an existing asset register. Its weakness shows up with cross-cutting events that don't sit neatly against one asset — a ransomware outbreak, a third-party breach, a natural disaster affecting a whole site — where an asset-by-asset walk can miss the compound scenario even after every individual asset has technically been reviewed.

The scenario/event-based approach starts from the other direction: define plausible bad events first (a ransomware encryption event, a business email compromise leading to fraudulent payment, a critical supplier outage), then work out which assets, threats, and existing controls are implicated by each scenario. It tends to surface exactly the multi-asset, multi-system risks the asset-based walk can miss, and it maps intuitively onto incident response and business continuity thinking. Its weakness is coverage — a purely scenario-driven exercise can leave gaps if nobody thought to write the scenario down in the first place.

ISO 27005:2022 doesn't pick a winner. It presents both as legitimate, and — notably for teams under time pressure — it explicitly supports combining them: use the asset inventory to make sure nothing is missed, and use scenario thinking to catch the compound, cross-system risks that asset-by-asset analysis tends to underweight. In my experience across manufacturing, healthcare, and financial services clients, the hybrid is what almost every mature ISMS ends up running by year two, even if year one started with a pure asset-based walk because it was faster to stand up. Our full comparison of asset-based vs scenario-based risk assessment approaches for ISO 27001 goes through the decision factors — team size, system complexity, audit history, available time — in much more detail than fits here.

"We started asset-based because it was the fastest way to get something on paper for Stage 1. By year two we'd layered in scenario workshops for ransomware and vendor compromise, because the asset list alone never would have surfaced 'what if our routing software vendor gets popped and pivots into us.'" — James Okonkwo, Information Security Manager, Vantage Steelworks

How to Actually Use ISO 27005 in an ISO 27001 Project

Knowing what 27005 contains is different from knowing how to use it without turning your ISMS project into an academic exercise. Here's the sequence I run with clients.

First, treat ISO 27005 as a reference you consult while writing your own risk assessment methodology document, not as a template you copy wholesale. Your methodology — the criteria for likelihood, impact, and acceptance, the roles, the process steps — needs to be written in your organization's own words, reflecting your own context, your own risk appetite, and your own asset landscape. An auditor reviewing a methodology that reads like a lightly reworded paraphrase of a generic guidance document, with no organization-specific criteria, will ask exactly the same "where did this number come from" question Dana got asked — paraphrasing doesn't fix the underlying gap.

Second, use 27005's process structure (context, identification, analysis, evaluation, treatment, acceptance, communication, monitoring) as your outline when building the methodology document and the risk register template, so nothing gets skipped. This is the single highest-value use of the standard for a first-time ISMS project: it's a checklist against your own methodology's completeness, not against the standard itself.

Third, decide early — during context establishment, not halfway through identification — whether you're running asset-based, scenario-based, or a hybrid, and document that decision with a reason. Changing horses midstream after twenty risks are already logged asset-by-asset creates rework and inconsistency an auditor will notice.

Fourth, build your risk register so every entry traces cleanly from identification through to treatment decision, control selection in the Statement of Applicability, and, where applicable, a line in the risk treatment plan. This traceability is what actually gets checked in a Stage 2 audit — not whether you cited 27005 anywhere.

Fifth, put monitoring and review on the calendar from day one, tied to a trigger list (new systems, mergers, incidents, regulatory changes) as well as a fixed interval (commonly annual, sometimes tied to management review). A risk register that's accurate on certification day and stale eighteen months later is a common source of Clause 9 findings on recertification audits.

"The projects that go sideways aren't the ones where the team never opened ISO 27005. They're the ones where the team opened it, copied three pages into their methodology document verbatim, and never adapted a single criterion to their own environment. An auditor can tell the difference in about five minutes." — Sarah Lindqvist, Principal Consultant, Northfield Risk Partners

What Changed in ISO 27005:2022

The 2022 edition is a meaningful rewrite, not a light refresh, and it's worth knowing the shape of the change if you're working from older training materials or an older copy of the standard.

The most visible shift is alignment: the 2022 edition was restructured to align its terminology and process language with both ISO 31000:2018 and ISO 27001:2022, closing gaps that used to exist between how the three documents described the same steps. Earlier editions predated ISO 27001:2022's current Annex A structure entirely, and predated some of ISO 31000's now-standard vocabulary.

The second major shift is the removal of the old prescriptive annexes. Earlier editions of 27005 shipped with detailed illustrative catalogs — long example lists of assets, threats, and vulnerabilities in annex tables. Those catalogs were popular precisely because they were copy-pasteable, and precisely because of that, they became a crutch: organizations lifted the example threat list wholesale instead of doing contextual identification work of their own. The 2022 edition drops most of that prescriptive annex material in favor of describing techniques and approaches at a higher level, pushing organizations toward doing the contextual thinking themselves rather than filling in someone else's example table.

The third shift, most relevant to this article, is the explicit, balanced treatment of both asset-based and event/scenario-based identification. Older editions leaned more heavily toward the asset-based tradition; the 2022 edition treats both as legitimate starting points and discusses combining them, reflecting how risk identification practice across the industry has actually evolved.

Limits: Guidance, Not Audit Criteria

It's worth stating plainly, one more time, because I still see it misunderstood in the field: ISO 27005 is not something you get audited against, and it should never appear in your documentation as though it were a compliance target in its own right. I've reviewed internal audit reports that included a line like "verified compliance with ISO 27005 clause 8.3" — written by a well-meaning internal auditor who'd absorbed the standard's structure without absorbing its status. That line doesn't mean anything to a certification body auditor, because there's no requirement in ISO 27005 to be compliant with. What that internal auditor almost certainly meant, and should have written, is that the organization's risk treatment approach reflects sound practice and satisfies ISO 27001 Clause 6.1.3.

This matters for two practical reasons. First, if your Statement of Applicability, methodology document, or internal audit reports cite ISO 27005 clause numbers as though they were binding requirements, you're building your defensibility on the wrong foundation — the actual requirement your Clause 6.1.2/6.1.3 process needs to satisfy comes from ISO 27001, and your certification body auditor will check it against ISO 27001, not against 27005. Second, and less obviously, over-relying on 27005 as a rulebook rather than a reference tends to produce risk assessments that are technically thorough but contextually shallow — every step is present, in order, matching the guidance's shape, but the actual criteria and risk content read like nobody in the room thought hard about Corvale Freight's actual business, or Solandra Health's actual patient data flows.

The right mental model: ISO 27005 is closer to a well-written textbook chapter than a regulation. You use it to learn the shape of good risk management, to borrow vocabulary and structure, and to avoid reinventing the wheel badly — the way Dana did. You don't cite it as your compliance basis, and you don't let its structure substitute for your own organization's judgment about what its real risks are.

Common Mistakes

Over fifteen years and several hundred ISMS engagements, the mistakes around ISO 27005 cluster into a fairly short, repeatable list.

1. Treating ISO 27005 as a certification requirement in disguise, then panicking when an internal reviewer can't find a "27005 compliance" line item anywhere in the audit scope.

2. Copying illustrative examples verbatim into the organization's own methodology or risk register without adapting them to actual assets, threats, or business context — producing a document that reads well and traces to nothing real.

3. Picking one identification method (usually asset-based, because it's easiest to start) and never revisiting the decision, missing the cross-system scenarios that only a scenario workshop tends to surface.

4. Skipping context establishment — jumping straight to listing risks without first documenting likelihood, impact, and acceptance criteria — which is exactly the mistake that cost Dana three lost weeks.

5. Confusing risk acceptance with risk neglect — letting risks sit untreated with no explicit owner sign-off, then discovering during audit that "acceptance" was never actually a documented decision.

6. Building a risk register once, for certification, and letting it go stale — no monitoring and review cadence, no trigger list for new systems or incidents, so the register that passed Stage 2 no longer reflects reality by the first surveillance audit.

7. Losing traceability between the risk register, the Statement of Applicability, and the risk treatment plan — three documents that should tell one consistent story but were built by different people at different times with no cross-referencing.

For a broader list of pitfalls beyond the ISO 27005-specific ones above, see our dedicated guide to common ISO 27001 risk assessment mistakes.

Case Studies

Case Study 1: Corvale Freight Systems — Closing the Gap

When I was brought in to help Corvale rebuild its risk assessment after the Stage 1 finding, the first thing we did was not touch the existing spreadsheet. We spent four days writing a one-page methodology document: a five-point likelihood scale with written definitions for each point, a five-point impact scale scored separately across confidentiality, integrity, and availability, and a documented risk acceptance threshold signed off by the COO as risk owner for enterprise-level risk. That's context establishment, done properly, in under a week — the step Dana's original three-week effort had skipped entirely.

From there, we ran a hybrid identification exercise: kept Dana's asset inventory (it was good, detailed work, just missing the next step), and layered on four scenario workshops covering ransomware against the warehouse control system, insider risk from privileged TMS access, third-party routing software compromise, and a regional service disruption affecting the main distribution hub. The scenario workshops alone surfaced eleven risks the asset-based list had missed entirely, including the departing operations manager's still-active admin credentials — which we flagged and had revoked within 48 hours, well before it became an actual incident rather than a hypothetical one in a workshop.

The full rebuild — methodology, hybrid identification, analysis, evaluation, treatment plan, and a Statement of Applicability with clean traceability back to every risk — took ten working days, compared to the six weeks Dana's team had originally budgeted (three weeks building the flawed version, plus an estimated three more to redo it from scratch without a structure to follow). Corvale passed its delayed Stage 2 audit with two minor observations, neither related to risk management, and retained the $3.2 million retailer contract with about five weeks of schedule slack against the original nine-month deadline.

"I felt embarrassed when the auditor's finding came back, honestly. Looking back, the embarrassing part wasn't that I didn't know risk management — it's that I didn't know a map existed before I started driving. I keep the methodology document from that rebuild pinned in our SharePoint. It's the thing I show every new hire now." — Dana Okafor, Information Security Manager, Corvale Freight Systems

Case Study 2: Kestrel Financial — Scenario-Based Risk Catches What Asset Lists Miss

Kestrel Financial, a mid-size payments fintech with roughly 180 employees, had already been through one ISO 27001 cycle using a purely asset-based risk assessment inherited from a prior compliance hire. It had passed certification cleanly two years earlier, which made the second-cycle team confident the approach didn't need to change.

Ahead of its recertification cycle, Kestrel's Head of GRC, Priya Ramanathan, pushed to add scenario-based workshops specifically for two event categories the asset-based register had never really engaged with: a ransomware event affecting core payment processing infrastructure, and a business email compromise scenario leading to fraudulent outbound payment authorization. Neither showed up clearly in the existing asset-by-asset risk list, because each one touched five or six different assets and several different control owners at once — exactly the pattern ISO 27005:2022's scenario/event-based guidance is designed to surface.

The ransomware scenario workshop identified that backup restoration testing had never actually been performed end-to-end, only backup completion had been verified — a gap the asset-based register had rated the backup system itself as "low risk" because the backups were, technically, running. The BEC scenario workshop identified that outbound payment changes above a threshold had no out-of-band verification step, a process gap no single asset entry would have flagged because it wasn't really about any one asset — it was about a business process spanning finance, IT, and a banking portal.

Kestrel treated both findings before its recertification audit: a quarterly backup restoration test was added to the operating procedure, and a callback verification step was added to the payment change process. Priya's team estimated — conservatively, and only for internal planning purposes, not as an external claim — that catching the backup restoration gap ahead of an actual ransomware event likely avoided somewhere in the range of $1.5–2 million in potential downtime and recovery costs, based on their own business continuity impact modeling for a payment-processing outage of several days. Kestrel passed recertification with zero major nonconformities and one minor observation unrelated to risk management.

"Two years of clean asset-based risk assessments made us complacent. The scenario workshops took three days and cost us almost nothing compared to what a real ransomware event touching payment processing would have cost. I don't run a cycle without them anymore." — Priya Ramanathan, Head of GRC, Kestrel Financial

Case Study 3: Solandra Health Systems — A Hybrid Approach for PHI

Solandra Health Systems, a regional outpatient network handling protected health information across six clinic locations, took a hybrid approach from the start of its first ISO 27001 project, under CISO Tomás Rivera's direction, specifically because healthcare risk rarely respects asset boundaries — a single patient record can flow through an EHR system, a billing vendor, a lab integration, and a patient portal, and a purely asset-by-asset walk tends to under-count risk that lives in the handoffs between systems rather than inside any one of them.

Solandra's team built its asset inventory first, covering the EHR, the billing platform, portal infrastructure, and clinic-level endpoint devices, satisfying the thoroughness that asset-based identification is good at. Then they ran four scenario workshops specifically built around patient data flows: a lab-integration data leakage scenario, a departing clinician's access retention scenario, a third-party billing vendor breach scenario, and a ransomware scenario affecting a single clinic's local systems with potential spread to the shared EHR backbone.

The combination mattered in a specific way during the actual Stage 2 audit: the auditor spent considerable time tracing several risks from the register through to Annex A control selection in the Statement of Applicability and into the risk treatment plan, testing exactly the kind of traceability this article has stressed throughout. Because Solandra's risk IDs were consistent across all three documents, and because each risk's origin (asset-based walk vs. named scenario) was documented rather than blended together anonymously, the auditor could follow the logic quickly rather than asking Tomás's team to reconstruct it live. Solandra passed with zero nonconformities, major or minor — a result Tomás attributes directly to the traceability discipline, not to the hybrid identification method alone.

"The auditor asked us, for three separate risks, 'walk me through how you got from this risk to that control.' We could, in about ninety seconds each, because the risk ID was the same string in the register, the treatment plan, and the SoA. That's not a 27005 requirement. That's just good bookkeeping the standard's structure nudged us toward." — Tomás Rivera, CISO, Solandra Health Systems

Strategic Close: Risk Management as a Business Opportunity, Not Just a Certification Line Item

Here's the reframe I try to leave every client with once the audit pressure is off and we're talking about what comes next. A risk assessment built to survive one Stage 2 audit and then left alone is a compliance cost. A risk assessment built the way ISO 27005 describes — with real context establishment, a deliberate identification strategy, honest analysis, and a monitoring cycle that actually runs — is a genuine decision-making tool, and organizations that treat it that way get more than a certificate out of it.

I've watched this play out concretely: cyber insurance underwriters increasingly ask pointed questions about risk assessment maturity, not just control checklists, before quoting premiums — a documented, traceable process with named risk owners is a materially easier conversation than a spreadsheet nobody can explain. Sales teams selling into enterprise and regulated customers use a mature risk register as proof of operational seriousness in due diligence questionnaires, well beyond whatever the certificate itself says. And boards, increasingly, want to see that risk decisions — what got treated, what got accepted, and why — are traceable to a named owner rather than buried in a spreadsheet from a Thursday afternoon three years ago.

None of that requires you to master ISO 27005 cover to cover before you touch your risk register. It requires using its structure deliberately, adapting it to your own context rather than copying it, and building in the monitoring and review discipline that keeps the whole thing honest past certification day.

If you're building or rebuilding your risk assessment right now, don't start from a blank spreadsheet the way Dana did. Start from our ISO 27001 Risk Register Template, which already reflects the identification-analysis-evaluation-treatment structure this article walked through, and pair it with our Risk Scoring Calculator if you're deciding between qualitative and semi-quantitative scoring approaches. If you want the full walkthrough from scope to Statement of Applicability, our Complete ISO 27001 Implementation Guide eBook covers the whole project, risk management included. And if you'd rather practice before it counts, our Build a Sample Risk Treatment Plan lab lets you work through a realistic scenario end to end before you touch your organization's actual register. If any of the terminology in this article was new to you, our ISO 27001 Glossary of Terms is worth bookmarking before your next risk workshop.

Dana's team didn't need a bigger budget or an outside consultant on day one — they needed to know a better starting point than a blank spreadsheet existed. Now you do.