The Essential Step Everyone Seems to Skip
Why establishing a defensible risk profile must come before controls—and how skipping it undermines due diligence.
“Risk assessment is hooey.”
— Donn Parker, SRI International
I remember how stunned we were when Donn—my colleague and a mentor—said this to the International Information Integrity Institute (I-4) consortium he founded.
The statement was deliberately provocative. And it was prescient.
Donn wasn’t rejecting risk management. He was calling out a pattern we still see today: risk assessments performed without an explicit risk profile. When that happens, assessments create the illusion of rigor without the substance of judgment.
Risk assessment becomes meaningless when it is performed without first deciding what the organization actually cares about.
That critical step is still being skipped.
Executive pull quotes (for skimmers)
Controls aren’t strategy. Without an explicit risk profile, you can’t explain why a control exists—or whether it’s sufficient for this business.
Framework alignment is not due diligence. Due diligence is the ability to show informed, business‑specific decisions about material cyber risk.
If you can’t trace controls to risk drivers, you can’t defend priorities. Budgets, exceptions, and trade‑offs become opinion contests instead of risk decisions.
Risk appetite belongs to executives. Security can recommend; leadership must explicitly decide what loss, disruption, and exposure the organization will accept.
“What would it take for this to be true?” is the leadership translation layer. Business goals + risk profile → security intent → controls that enable outcomes.
The Pattern I Keep Seeing
Across industries and maturity levels, I see security programs start in the same place: controls. Tool selection. Framework mapping. Gap assessments. Heat maps built from inherited assumptions. What’s missing is not effort or intent—it’s sequencing.
The most often skipped step is deliberately establishing an enterprise‑specific cybersecurity risk profile before defining or selecting security controls. When that step is skipped, organizations may still “implement NIST,” “align to ISO,” or “map to CIS,” but they struggle to demonstrate why those controls are appropriate, sufficient, or defensible for their business.
This matters—not just for program effectiveness, but for demonstrating due diligence to a defensible standard of care.
What a Risk Profile Actually Is (and Is Not)
A cybersecurity risk profile is not:
A generic risk register populated with boilerplate threats
A maturity score or color‑coded heat map
A list of framework categories marked high/medium/low
A one‑time artifact produced for audit or compliance purposes
A risk profile is a decision‑shaping construct that sits between business objectives and security execution. It makes explicit the assumptions, constraints, and trade‑offs that leadership is willing to accept in pursuit of those objectives.
At a minimum, a defensible cybersecurity risk profile captures:
Business objectives and critical outcomes cybersecurity is expected to enable or protect
Mission‑critical functions and services, and the constellation of assets, processes, and dependencies that support them
Threat exposure grounded in credible adversaries, not hypothetical worst cases
Impact tolerance and loss thresholds (financial, operational, safety, legal, and reputational)
Legal, regulatory, and contractual obligations that constrain acceptable risk
Risk appetite and tolerance statements articulated by leadership, not inferred by security teams
Assumptions and constraints, including resourcing realities and business velocity requirements
Risk ownership and accountability, including where risk is accepted, transferred, or avoided
At its core, a risk profile answers three foundational questions:
What must be true for the business to achieve its objectives?
What could credibly prevent that from being true?
How much residual risk is leadership willing to accept in pursuit of those objectives?
Without these elements, security teams are left to make implicit decisions on behalf of leadership—an arrangement that is neither scalable nor defensible.
How Frameworks Accidentally Encouraged Control‑First Thinking
Standardized frameworks—particularly NIST CSF—were designed to be flexible and risk‑based. In practice, their structure has often encouraged control‑first implementation.
Common failure modes include:
Starting with the CSF Core and treating it as a checklist
Performing “Current / Target Profile” exercises without first defining enterprise risk drivers
Selecting controls to improve maturity scores rather than reduce material risk
The irony is that NIST CSF explicitly expects organizations to establish a risk profile first. Framework Profiles were intended to be derived from business requirements, risk tolerance, and threat context. Instead, many organizations reverse the logic—creating profiles by averaging framework categories rather than anchoring them in business reality.
The result is a program that looks aligned but cannot clearly answer:
Why these controls exist
Why they are prioritized this way
Why they are sufficient—or insufficient—given the organization’s actual risk exposure
From a due‑diligence perspective, that gap is consequential.
Due Diligence Requires Intentionality, Not Just Alignment
Regulators, courts, and plaintiffs are not asking whether you “used a framework.” They are asking whether leadership:
Understood the organization’s specific risks
Made informed decisions about managing those risks
Acted reasonably given what was known—or should have been known
A control set that is not traceable to a clearly articulated risk profile is difficult to defend, especially after an incident.
Establishing the risk profile first creates the evidentiary chain that due diligence depends on:
Business Objectives → Risk Profile → Desired Outcomes → Control Selection → Implementation → Monitoring
Break that chain at the beginning, and everything downstream becomes harder to justify.
Translating Business Goals Into “What Would It Take for This to Be True?”
This is where security leadership earns its seat at the table.
Executives articulate goals in business terms:
Growth in regulated markets
Increased digital dependency
M&A velocity
Operational resilience
Brand trust
Security leadership must translate those goals—and the organization’s risk profile—through a lens I refer to as outcome‑based security:
For the business to achieve its objectives, given the stated risk profile, what would have to be true from a security and control perspective?
That translation requires:
A systems‑level view of internal controls and security, recognizing that siloed controls rarely protect end‑to‑end business outcomes
A clear understanding of the constellation of assets, processes, and dependencies that enable mission‑critical functions
A continuous understanding of the threat landscape relevant to those functions
Explicit clarity on legal, regulatory, and contractual obligations that shape acceptable risk
Recognition that risk transfer mechanisms (e.g., insurance) may share financial exposure but do not transfer accountability
Only then can controls be intentionally designed as enablers of business outcomes, rather than abstract technical safeguards.
Controls selected without this translation often:
Create friction where the business needs speed
Fail to address the threats that actually matter
Underestimate the compounded risk created by technical debt
Undervalue the contribution of basic cyber hygiene to achieving business objectives
Making the Risk Profile a First‑Class Artifact
To make the risk profile a durable part of the risk management process, it must be:
Executive‑owned: Security facilitates; leadership sets risk tolerance
Explicit: Assumptions, trade‑offs, and constraints are documented
Traceable: Control decisions map back to risk drivers
Revisitable: Updated as business strategy, threat landscape, or regulatory conditions change
Practically, this means:
Establishing the risk profile before control frameworks are mapped
Using the profile to constrain scope and prioritize effort
Treating deviations from the profile as conscious risk decisions—not accidents
Frameworks then become what they were meant to be: reference architectures, not substitutes for thinking.
Where This Fits in NIST CSF, ISO, and COSO ERM
NIST Cybersecurity Framework (CSF 1.1 and 2.0)
NIST CSF is frequently mischaracterized as a control framework. It is not. It is a risk‑based framework whose proper use depends on a clearly articulated risk profile.
Relevant elements include:
Framework Profiles: Intended to reflect business requirements, risk tolerance, and threat context before control selection
Implementation Tiers: Describe how risk management practices are institutionalized—not control completeness
CSF 2.0 Govern Function (and CSF 1.1 ID.GV elements): Explicitly anchor cybersecurity priorities in organizational context and risk management strategy
When organizations jump directly to Core mappings or maturity scoring, they invert this logic—treating Profiles as an output of controls rather than an input to control design.
ISO and the 27000 Family
ISO standards are unambiguous about sequencing: context and risk assessment precede control selection.
Key references include:
ISO/IEC 27001 Clause 4: Understanding the organization and its context
ISO/IEC 27001 Clause 6: Risk assessment and treatment before selecting controls
ISO/IEC 27005: Information security risk management, including risk context establishment
ISO 31000: Enterprise risk management principles emphasizing context, risk criteria, and decision‑making
Annex A controls in ISO/IEC 27001 are explicitly subordinate to risk assessment outcomes. Selecting controls without documented risk context and acceptance criteria is non‑conformant in spirit—and often in fact.
COSO Enterprise Risk Management (ERM)
COSO ERM makes the risk‑profile‑first logic board‑relevant by tying risk directly to strategy and performance:
Governance and Culture: Board and executive oversight of risk appetite
Strategy and Objective‑Setting: Risk considered alongside business strategy, not afterward
Performance: Identification and assessment of risks relative to objectives
Under COSO, risk is the possibility that events will occur and affect the achievement of objectives. Controls are a response—not the starting point.
The Bottom Line
Skipping the risk profile step doesn’t save time—it defers the hardest thinking until after decisions have already been made.
If your goal is to demonstrate due diligence to a defensible standard of care, the question is not:
“Are we aligned to a framework?”
It is:
“Can we clearly explain why these controls exist, for this business, given these risks?”
That explanation starts with a risk profile. Everything else is implementation detail.
If this resonates, future posts will go deeper into how to structure a defensible risk profile, how to operationalize it with ERM, and how this risk‑first logic becomes non‑negotiable in areas like agentic AI and autonomous systems.