The board receives two diagrams: a current profile and a target profile. The second looks cleaner, so the gap appears to be a project plan waiting for budget.
The consequential question sits behind the colours: whose evidence defines the current state, who owns the target, which trade-offs were accepted and what would cause the decision to change?
Fact: the issue in 30 seconds
Direct answer. NIST Cybersecurity Framework 2.0 describes high-level cybersecurity outcomes and supports Organizational Profiles. It does not prescribe one implementation. A profile can help a board and operating team discuss current and target outcomes in a shared structure. It does not certify the organization, establish legal compliance or decide whether the chosen target is adequate.
The profile is most useful when each material difference becomes an owned question rather than a coloured cell.
Why the profile feels like an answer
A structured profile gives people common labels. It can replace a presentation built from disconnected control names, incidents and technical metrics with a more coherent view.
That clarity creates a temptation: treat the completed document as completed governance. A profile may describe an outcome while leaving evidence quality, dependencies, exceptions and resource choices outside the page.
PARAVEILUX inference. The hidden variable is not the existence of a target. It is the decision record connecting that target to evidence, responsibility and trade-offs.
What the source record supports
The US National Institute of Standards and Technology publishes CSF 2.0 and related quick-start guides. The framework describes high-level outcomes and is designed for varied organizations rather than prescribing one control implementation.
That source layer supports organizing a conversation. It does not support a claim that a completed profile proves maturity, adequacy, certification or legal protection. Any sector-specific or legal proposition requires a selected jurisdiction and separate review.
Action: ask what connects current and target
Place the current and target descriptions side by side, then ask:
- What evidence supports the current description, and when was it checked?
- Who may accept, reduce or defer each material difference?
- Which people, suppliers, systems and resources sit behind the target?
- What contrary evidence could make either description unreliable?
- Which event would trigger review before the next routine cycle?
These questions keep the board at the level of ownership and consequence without turning it into the control operator.
A bounded evidence register
For each material difference, record the stated outcome, evidence, target rationale, accountable owner, dependencies, open uncertainty, interim position and review trigger.
The counter-signal matters. The current state may already match a bounded need, and another control project may add complexity without changing the relevant outcome. That is not a reason to stop asking questions. It is a reason to test the target rather than assume that more is always better.
Signal: signals and counter-signals
Investigate when a current state is supported only by self-report; the target has no named owner or resource assumption; exceptions are hidden outside the profile; a colour is treated as a maturity score; or a later incident does not reopen the description.
Counter-signals include dated evidence, versioned profiles, explicit trade-offs, named owners, recorded dependencies and event-based review. These strengthen the conversation. They do not prove adequacy or effective operation.
The hidden variable
The hidden variable is translation. The board speaks in consequence, allocation and accountability. Operating teams speak in configurations, process steps, evidence and exceptions. The profile helps those views meet without pretending they are identical.
The owner’s task is to make the unresolved decisions visible and assign them to the people qualified to test them.
Limitations: what this does not prove
A profile does not prove cybersecurity adequacy, compliance, certification, resilience or maturity. It does not show that a particular control operates effectively or establish a regulated entity’s duties.
A difference does not automatically mean failure. It may reflect timing, scope, a deliberate choice, incomplete evidence or a target that needs reconsideration. Organizational scope, evidence quality, legal duties and sector requirements remain Not assessed.
Owner Q&A
Should the board review every outcome?
Not necessarily. Materiality, the organization’s governance model and the evidence needed for the decision can shape reporting depth.
Can the profile become a score?
This draft does not recommend that. Turning a descriptive structure into a maturity or adequacy score introduces assumptions that require separate definition and validation.
What should remain after the meeting?
Preserve the profile version, evidence dates, material questions, accepted trade-offs, owners and triggers. Distinguish what was presented from what was decided.
Next verification
Compare the profile with the evidence, owners, resources and trade-offs behind it. Ask whether a comparable gap could arise in your organization, while checking current sector, contractual and local requirements before treating the profile as more than a voluntary planning tool.
Sources and limitations
- NIST Cybersecurity Framework 2.0 — voluntary US institutional framework describing high-level outcomes without prescribing how they must be achieved.
- NIST SP 1301, Organizational Profiles Quick-Start Guide — guidance on current and target profiles, evidence, gaps, action planning and updating.
This is general risk education, not professional or certified advice. NIST provides voluntary US institutional guidance, not certification; applicability and adequacy can vary with current local rules, sector, role, systems and evidence.