Why Cyber Risk Governance Depends Less on Choosing the “Right” Methodology—and More on the Quality of the Assessment It Produces
Introduction
Imagine sitting in a board meeting six months after a major cyber incident.
The immediate crisis has passed. Systems have been restored. Customers and other affected parties have been notified. Outside counsel has completed at least part of its investigation. Regulators have begun asking questions, and members of the board have gathered to understand what happened—and why.
No one begins by asking whether management followed National Institute of Standards and Technology (NIST) Special Publication 800-30, ISO/IEC 27005, FAIR, OCTAVE, or another recognized methodology.
Instead, the questions become more fundamental:
- Why did management believe the risk that led to the event was acceptable?
- What evidence supported that conclusion?
- What assumptions were made?
- What alternatives were considered?
- Who had the authority to make or accept the decision?
- What information was presented to senior management and members of the board?
- Would another reasonable management team, considering the same information at the same time, have reached a similar conclusion?
Notice what happened.
The conversation shifted from methodology to judgment.
More precisely, it shifted to whether management could explain and defend the assessment—and the decision that followed from it.
That shift matters because risk assessments are not merely analytical exercises. NIST describes them as part of an overall risk management process that provides senior leaders and executives with the information needed to determine appropriate courses of action in response to identified risks.[1]
A risk assessment is a decision-support instrument.
Its value does not depend merely on whether it was completed or which name appeared on the methodology. Its value depends on whether leaders can reasonably rely on what it says.
Over more than two decades advising healthcare organizations and working with executive leadership teams and members of boards, I have reviewed dozens of cybersecurity risk assessments prepared under different standards, by different consulting firms, and for organizations ranging from community healthcare providers to some of the nation’s largest health systems.
One observation kept resurfacing.
Organizations often believed they were using fundamentally different approaches to risk assessment.
In reality, the strongest assessments relied on remarkably similar foundations, even though:
- The terminology differed.
- The scoring models differed.
- The reports looked different.
- The software platforms certainly looked different.
Yet beneath those differences was a common architecture that consistently distinguished assessments capable of supporting executive decisions from those that merely satisfied an internal request or compliance obligation.
That observation became one of the foundations of Defensible Risk Assessment™ (DRA™).
Not because organizations need another methodology. DRA is not another risk assessment methodology. It is an assessment evaluation methodology.
Organizations need a better way to evaluate whether the assessment they already performed is sufficiently complete, evidence-based, methodologically sound, transparent, and decision-useful for the purpose it served.
That is a different problem. And solving it begins by asking a different question.
I (/We) Have Been Asking the Wrong Questions
At first, in my role as an executive and board member, and my consulting work, writing, and teaching, I began with the question: “Did you complete a risk assessment?” That seemed like a reasonable place to start.
Then I started asking, “Did you do it correctly?” That is, did the organization follow an open, industry-recognized standard? I found the answer to be “no” in many cases.
Then, if a risk assessment had been completed following an industry-recognized standard, I started asking “Can you defend it?”
I discovered that organizations devoted enormous energy to selecting the “right” risk assessment methodology. They were asking themselves:
- Should we adopt NIST?
- Should we align with ISO/IEC 27005?
- Would a quantitative approach provide better financial insight?
- Should we, as a healthcare organization or business associate, organize our work around specific Office for Civil Rights (OCR) risk analysis guidance?
- Should we use the methodology embedded in our governance, risk management, and compliance (GRC) software?
These are worthwhile questions.
Methodologies matter. They influence vocabulary, workflow, analytical techniques, scoring, documentation, and reporting. A disciplined method helps ensure that important elements are not omitted and that judgment is applied consistently.
NIST SP 800-30, for example, organizes risk assessment around preparing for the assessment, conducting it, communicating its results, and maintaining it. Its analytical factors include threat sources and events, vulnerabilities and predisposing conditions, likelihood, impact, and risk determination.[2]
ISO 31000 uses somewhat different language. It situates risk assessment within a broader process that includes defining scope, context, and criteria; identifying, analyzing, and evaluating risk; treating risk; monitoring and reviewing it; and recording and reporting results.[3] ISO/IEC 27005 applies comparable logic specifically to information security risk management.[4]
The vocabulary differs. The architecture is familiar.
That distinction matters because organizations frequently treat the selection of a methodology and the evaluation of the resulting assessment as though they are the same decision.
They are not.
Selecting a methodology is a design decision.
Evaluating whether the completed assessment is sufficiently strong to support reliance is a governance responsibility.
A recognized methodology may improve the odds of producing good work. It does not guarantee good work.
An organization can invoke NIST, ISO, or another respected source and still produce an assessment with an unclear scope, incomplete evidence, generic threats, untested controls, unexplained scores, undocumented assumptions, or conclusions that cannot be traced to the facts.
The methodology may be sound.
The completed assessment may not be.
Looking Beyond the Labels
Consider architecture in the literal sense.
Ask five architects to design an office building.
One may specify reinforced concrete. Another may favor structural steel. A third may use modular construction. They may use different software, drafting conventions, engineering methods, and units of measurement.
Yet every competent design must still account for foundations, structural integrity, utilities, fire protection, emergency exits, occupancy, environmental systems, and life safety.
A building inspector does not determine safety by asking which computer-aided design platform produced the drawings.
The inspector examines whether the structure satisfies the requirements necessary for its intended use.
Risk assessment deserves the same perspective.
Whether an organization follows NIST SP 800-30, ISO/IEC 27005, a quantitative model, a proprietary consulting methodology, or an internally developed approach, every credible assessment must ultimately answer a common set of questions:
- What are we assessing?
- What matters within that scope?
- What could happen?
- Why could it happen in this environment?
- What safeguards already exist?
- How likely or plausible is the event?
- What consequences could follow?
- What should the organization do?
- Who is responsible for the decision?
- What evidence supports the conclusions?
Different methodologies organize and label those questions differently.
None can responsibly ignore them.
The Common Architecture of Risk Assessment
The first architectural element is context and scope.
Every meaningful assessment must define what is being assessed, why it is being assessed, what is included, what is excluded, and what decision the assessment is intended to support.
The unit may be an enterprise, business unit, facility, system, application, product, data flow, business process, third-party relationship, or component of any of the aforementioned.
Scope determines the boundaries of evidence. It also determines what conclusions can fairly be drawn.
A narrow assessment may be entirely appropriate for a narrow decision. It becomes dangerous when leaders treat it as evidence about the whole organization.
The second element is risk identification.
A credible assessment must identify the assets or risk objects that matter, the threat sources or events that could cause harm, the vulnerabilities or conditions that make those events plausible, and the existing controls intended to prevent, detect, respond to, or recover from them.
Identification requires connection.
An asset inventory is not, by itself, a risk assessment.
A threat list is not a risk assessment.
A vulnerability scan is not a risk assessment.
A control checklist is not a risk assessment.
The assessment must connect what matters, what could happen to it, why the event is plausible in the organization’s environment, and what safeguards already exist.
The third element is risk determination.
This is where evidence and judgment meet.
The assessment moves from identified conditions to conclusions about likelihood, impact, inherent risk, residual risk, significance, or priority. The labels and scoring methods may vary, but the underlying requirement does not: a knowledgeable reviewer should be able to understand how the assessment moved from facts to conclusions.
A qualitative assessment can be defensible.
An unexplained qualitative rating is not.
A quantitative model can be valuable.
A precise-looking number built on unsupported assumptions does not become reliable merely because it includes decimal points.
The fourth element is risk evaluation.
Risk determination asks what the risk means.
Risk evaluation asks what the organization should do with that meaning.
This is where risk appetite, tolerance, legal and regulatory obligations, operational needs, available resources, stakeholder expectations, urgency, and business priorities become relevant.
A risk may be significant but tolerated temporarily because remediation would disrupt a critical operation. A moderate risk may demand immediate action because it affects patient safety, a strategic customer, a public commitment, or a regulated data set.
The defensibility question is not whether every reviewer would make the same choice.
The question is whether the choice can be explained as reasonable in light of the evidence, assumptions, alternatives, and circumstances that existed at the time.
The fifth element is risk treatment or response.
The organization must decide whether to accept, avoid, mitigate, transfer, or share the risk.
That decision should not float separately from the assessment.
The record should show what was decided, who had authority to decide, what alternatives were considered, what conditions or time limits apply, what residual risk remains, and what monitoring is required.
The sixth element is communication and governance use.
Technical analysis has limited value if the people who must act on it cannot understand it.
A credible assessment must communicate enough for leaders to understand what was assessed, what matters, what evidence supports the conclusions, what uncertainty remains, and what decisions are required. At the same time, it must preserve enough detail for a knowledgeable reviewer to test the reasoning.
NIST SP 800-39 reinforces this governance perspective by placing information security risk within an organization-wide context that includes mission, functions, image, reputation, assets, individuals, and other organizations.[5]
The seventh element is monitoring and maintenance.
A risk assessment is not timeless.
Systems change. Vendors change. Data moves. Controls degrade. Personnel leave. Threats evolve. Artificial intelligence is introduced. Regulations and contractual obligations change. Acquisitions add unfamiliar environments and inherited risk.
An assessment that was sufficient when completed may no longer be sufficient for the decision it is being used to support.
The final element is the record of reasoned judgment.
The assessment should preserve the path from context and scope, through evidence and analysis, to evaluation, treatment, communication, monitoring, and accountable decision-making.
The purpose of the record is not to prove that a form was completed.
It is to preserve why the conclusion was reasonable.
Two Assessments, Two Very Different Outcomes
Consider two regional healthcare organizations preparing enterprise cybersecurity risk assessments (a.k.a, risk analyses in HIPAA parlance) before their annual budget cycles.
Both engage experienced consultants.
Both use recognized methodologies.
Both identify ransomware as a significant enterprise risk. Both recommend investments in identity and access management, network segmentation, backup resilience, and incident preparedness.
On the surface, the assessments appear equally credible.
This is an illustrative composite, but the governance problem is real.
Several months later, each organization’s audit committee asks the same question before supporting a multimillion-dollar cybersecurity investment:
“Help us understand why these recommendations deserve priority over competing capital requests.”
The first organization opens its assessment and walks the committee through the defined scope, technology and information asset inventories, material business processes, threat intelligence, interviews with business owners, control evidence, likelihood rationale, potential business consequences, alternative treatment options, assumptions, and unresolved uncertainties.
Members of the committee challenge several assumptions. Management responds with supporting evidence. In one area, management acknowledges that the evidence is incomplete and explains how that uncertainty affected the recommendation.
The committee supports the investment with confidence because its members understand not only what management recommends, but why.
The second organization reaches similar conclusions but cannot explain how it reached them.
Risk scores appear on a colorful heat map, but no one can reconstruct the rationale behind them. The consultant’s underlying workpapers were not retained. Interview notes were discarded. Control effectiveness was assumed from policy documents. Several participants have moved to other roles. Likelihood and impact values reflected professional judgment, but the basis for that judgment was never recorded.
The committee is left asking reasonable questions that management can no longer answer.
Neither organization necessarily selected the wrong methodology.
One produced an assessment that could support reasonable reliance.
The other produced an artifact whose conclusions exceeded the surviving evidence.
The difference was not the name of the methodology.
The difference was defensibility.
Evidence Makes the Architecture Useful
Architecture tells us what elements should exist.
Evidence provides a basis for trusting how those elements were developed.
Evidence helps show that the scope reflects the environment claimed.
Evidence validates inventories.
Evidence supports threat and vulnerability conclusions.
Evidence shows whether existing controls were merely listed or meaningfully evaluated.
Evidence supports likelihood and impact judgments.
Evidence distinguishes facts from assumptions.
Evidence preserves the reasoning behind decisions after memories fade and personnel change.
The concept is familiar in other assurance settings. Public Company Accounting Oversight Board Auditing Standard 1105 explains that audit evidence must be sufficient and appropriate to provide a reasonable basis for conclusions.[6] A risk assessment is not an audit opinion, and Defensible Risk Assessment does not attempt to turn one into the other. But the underlying principle is useful: the quantity and quality of evidence should be appropriate for the conclusion being drawn and the weight being placed on it.
Without that discipline, risk assessment conclusions can become institutional folklore.
The report survives. The reasoning disappears.
When a regulator, auditor, insurer, customer, buyer, attorney, executive, or member of the board asks why management accepted a risk or prioritized one investment over another, the organization may discover that it documented the answer but not the basis for the answer.
That is more than a documentation weakness. It is a governance weakness.
Healthcare Shows Why Flexibility Does Not Eliminate Accountability
Healthcare provides a particularly clear example.
The HIPAA Security Rule requires regulated entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information.[7]
The U.S. Department of Health and Human Services Office for Civil Rights (OCR) does not prescribe one required risk analysis methodology. It recognizes that methods may vary based on an organization’s size, complexity, and capabilities. But OCR also makes clear that the chosen approach must accomplish the objectives of the Security Rule, and that risk analysis is the foundational step for identifying and implementing reasonable and appropriate safeguards.[8]
That is the larger lesson.
Flexibility in methodology does not eliminate accountability for sufficiency. The organization may choose its method.
It must still be able to demonstrate that the completed assessment was accurate and thorough enough, scope-appropriate, evidence-supported, and useful for making reasonable security decisions.
The same pattern appears beyond healthcare. Organizations increasingly operate in environments where regulators, insurers, customers, investors, auditors, and members of the board expect risk decisions to be documented, reviewable, and connected to evidence.
The assessment is no longer simply an internal work product. It is becoming part of the governance record.
From Methodology to Governance
Recognizing the common architecture fundamentally changed how I thought about risk assessment.
I stopped asking only whether an organization had performed a risk assessment using a recognized methodology.
I began asking a different set of questions that included:
- Can we evaluate the quality of the completed assessment itself?
- Can we determine whether the scope was sufficient for the purpose?
- Are the material risk objects, threats, vulnerabilities, and controls connected?
- Are analytical judgments supported and explained?
- Are assumptions, exclusions, and uncertainties visible?
- Does the treatment decision follow from the assessment?
- Can members of the board and executive leadership understand what they are being asked to rely on?
- Can a knowledgeable reviewer follow the assessment from scope to evidence to conclusion?
Those questions became part of the foundation for Defensible Risk Assessment.
DRA is not intended to replace NIST, ISO, OCR guidance, quantitative methods, or other recognized approaches. It is an evaluation-of-the-assessment discipline.
It asks whether a completed risk assessment—regardless of methodology—is sufficiently complete, evidence-based, methodologically sound, transparent, decision-useful, and governance-ready for the purpose it served.
That final phrase matters.
A limited assessment used to support a limited operational decision does not need the same record as an assessment supporting enterprisewide risk acceptance, a major capital investment, an insurance representation, a public disclosure, an acquisition, or a consequential decision by members of the board.
Defensibility does not demand perfection.
It demands sufficiency for the weight being placed on the assessment.
The Governance Takeaway
Organizations will continue debating methodologies. Standards will evolve. New frameworks will emerge.
Software vendors will offer increasingly sophisticated analytics, scoring engines, automation, and dashboards.
Those developments may improve the work. They do not change the fundamental governance challenge.
Members of the board do not perform the risk assessment, and they should not select every analytical technique. They oversee whether management has established a reasonable process, received reliable information, exercised informed judgment, and acted with appropriate accountability.
Management owns the decision.
The assessment supports the decision.
Its architecture determines whether the reasoning can be followed.
Its evidence determines whether the reasoning should be trusted.
Its record determines whether the decision can later be explained.
Because when regulators request the file, when auditors test the process, when insurers review prior representations, when customers ask for assurance, when litigation places earlier judgments under a microscope, or when members of the board simply ask, “Why did management make this decision?” the name of the methodology will not be enough.
The organization will need to show what it assessed, what it knew, what it assumed, what evidence it considered, what uncertainty remained, what it decided, and why the decision was reasonable at the time.
That is the enduring governance question every organization should ask before relying on a material risk assessment—not after:
Can you defend it?
Endnotes
[1] National Institute of Standards and Technology. Guide for Conducting Risk Assessments: NIST Special Publication 800-30, Revision 1.September 2012. Accessed June 4, 2026. Available at https://csrc.nist.gov/pubs/sp/800/30/r1/final.
[2] National Institute of Standards and Technology. Guide for Conducting Risk Assessments: NIST Special Publication 800-30, Revision 1.September 2012. Accessed June 4, 2026. Available at https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-30r1.pdf.
[3] International Organization for Standardization. ISO 31000:2018 Risk Management—Guidelines. 2018. Accessed June 3, 2026. Available at https://www.iso.org/standard/65694.html.
[4] International Organization for Standardization. ISO/IEC 27005:2022 Information Security, Cybersecurity and Privacy Protection—Guidance on Managing Information Security Risks. 2022. Accessed June 3, 2026. Available at https://www.iso.org/standard/80585.html.
[5] National Institute of Standards and Technology. Managing Information Security Risk: Organization, Mission, and Information System View: NIST Special Publication 800-39. March 2011. Accessed June 4, 2026. Available at https://csrc.nist.gov/pubs/sp/800/39/final.
[6] Public Company Accounting Oversight Board. “AS 1105: Audit Evidence.” Accessed June 3, 2026. Available at https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105.
[7] U.S. Department of Health and Human Services. 45 CFR § 164.308(a)(1)(ii)(A) – Risk Analysis (Required Implementation Specification). Electronic Code of Federal Regulations. Accessed July 13, 2026. Available at https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
[8] U.S. Department of Health and Human Services, Office for Civil Rights. “Guidance on Risk Analysis.” September 26, 2025. Accessed June 5, 2026. Available at https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html.
#riskmanagement #CISO #riskassessment #defensibleriskassessment #DRA #enterprisecyberriskmanagement #cyberriskilliteracy #boardcyberoversight #boardofdirectors