Questions and answers

Begin with a Subcategory and a plain current-state statement describing how or to what extent its outcome is achieved. Link each artifact to that statement and record the system or process in scope, artifact owner, evidence period, covered population, reviewer, and known limitations.

An Informative Reference only indicates a relationship between a Core outcome and another standard, guideline, regulation, or document. NIST notes that one reference may address only part of a Subcategory, so a crosswalk is neither proof of implementation nor proof that the full outcome is achieved.

CSF 2.0 is voluntary, outcome-based guidance and does not prescribe an audit evidence list, retention period, sample size, or assurance level. Those requirements may come from the mapped law, contract, regulator, assurance standard, or the organization's own method. Record that controlling source and do not attribute its legal force or deadline to NIST.

Use an evidence record only for the claim and period it can support. A policy can show an intended rule, a configuration export can show a setting at a point in time, and a sample of tickets can show operation for the sampled population. None of those artifacts alone proves continuous operation outside its stated scope.

When evidence is missing, stale, contradictory, or too narrow, record that limitation in the Current Profile and action plan. Do not replace the missing evidence with the wording of an Implementation Example or Informative Reference.

Retain enough provenance for another reviewer to reproduce the judgment: the artifact version or retrieval time, system of record, custodian, collection method, population and sample, integrity checks, reviewer, result, exceptions, and approval. Recollect or reassess after the evidence expires, a material change alters the covered population or control, a test fails, or the Profile boundary or mapped requirement changes.

Identify the Subcategory outcome and describe the desired condition for the applicable Target Profile. Review the associated examples as possible actions, then choose, adapt, combine, or replace them based on scope, architecture, threats, requirements, dependencies, resources, and existing practices.

NIST describes the examples as notional, concise, action-oriented steps. They are neither a minimum baseline nor a complete list. An organization may need several actions, a different action, and one or more Informative References to design a suitable practice.

CSF 2.0 and its Implementation Examples are voluntary guidance, not binding law, certification criteria, or an audit checklist. A mapped law, contract, regulator, or standard may separately require a specific action, scope, effective date, test, or record. Preserve that authority and legal force instead of describing the requirement as a NIST mandate.

Keep outcome assessment separate from action completion. Checking off an example only shows that an action was attempted; evidence must show whether the resulting practice achieves the outcome for the stated scope and period.

Preserve the decision trail from outcome to action to result. The record should show which outcome the team addressed, why the chosen action fit the scope, who approved and implemented it, how it was tested, what result was observed, and which limitations remain.

Examples of evidence depend on the action: an approved procedure may show design, a configuration export may show a setting, a test result may show technical behavior, and recurring logs or tickets may show operation. State the evidence period and population rather than using a generic compliance label.

NIST hosts supplemental resources online and can update them more often than CSWP 29. Record the example text or identifier and retrieval date used for the decision. Reassess when NIST changes the example or when a material change in requirements, threats, architecture, suppliers, processes, or Profile scope makes the chosen action or acceptance criteria unreliable.

Treat supplier risk as a governed life-cycle process, not a one-time questionnaire. Establish the C-SCRM program and roles, maintain supplier and service inventories, prioritize suppliers by criticality, set risk-based requirements, and perform due diligence before entering the relationship.

During the relationship, record and assess risks from the supplier and its products or services, monitor the agreed practices and changes in exposure, include relevant suppliers in incident planning and exercises, and track performance through the technology life cycle. Plan data return or destruction, access removal, transition support, continuing obligations, and other post-relationship activities before exit.

A supplier attestation, certification, or completed questionnaire can inform the assessment, but it does not by itself show that every applicable CSF outcome is achieved. Confirm its scope, period, exclusions, service coverage, and relevance to the organization's dependency.

CSF 2.0 is voluntary, sector-neutral guidance. It does not define a universal criticality score, contract clause, reassessment interval, breach-notification deadline, audit right, or certification. Applicable laws, regulatory rules, customer commitments, and contracts may impose binding duties; record their authority, jurisdiction, scope, and dates separately.

Maintain a relationship record that connects criticality, requirements, due diligence, approval, monitoring, incidents, exceptions, and exit. Evidence depth should match the potential business or mission impact and the organization's ability to verify the supplier's practices.

Useful evidence can include the service and data-flow inventory, criticality rationale, risk assessment, evaluation of assurance reports, contract terms, remediation commitments, monitoring results, material-change notices, incident exercise records, exception approvals, performance reviews, and offboarding confirmation. Record what each artifact covers and what it leaves unverified.

The business owner and C-SCRM or security owner should approve the relationship risk and any conditions; procurement and legal should place applicable expectations in the agreement; service, security, and resilience owners should monitor performance; and incident and exit owners should test coordination. Reassess on the set cadence and after material changes in service scope, data or connectivity, ownership, architecture, subcontractors, location or concentration, threats, incidents, requirements, assurance results, or contract status.

Use a boundary and outcome identifiers compatible with the Current Profile so each gap is intelligible. Select and prioritize desired outcomes using mission objectives, stakeholder expectations, the threat landscape, legal and contractual requirements, risk appetite and tolerance, anticipated technology changes, and available resources.

A Community Profile is a published baseline for shared sector, technology, threat, or use-case interests. It can seed a Target Profile, but the organization still decides which outcomes fit, what priority they have, and what additional outcomes its own risks and requirements call for.

A Target Profile describes desired outcomes. It does not show that controls are implemented or that the organization is compliant, certified, or at a particular Tier.

CSF 2.0 is voluntary, outcome-based guidance and does not prescribe a universal Target Profile, completion date, score, or certification. A law, regulator, contract, or internal policy may make an outcome or deadline mandatory; preserve that separate authority, effective date, jurisdiction, and scope in the rationale.

For each desired outcome, preserve the decision record: who approved it, which input drove it, what target condition is expected, and how the organization will know it has been achieved. Evidence of the current state belongs in the Current Profile; evidence in the action plan should show progress and eventual completion.

Treat accepted or deferred gaps as explicit risk decisions. Do not remove an outcome from the Target Profile merely to make the gap count look smaller unless the underlying objective, requirement, risk, or scope has genuinely changed.

NIST's Profile method is iterative and may be repeated as often as needed. Set a planning horizon and review date, then reassess when actions are completed or when requirements, threats, technology, suppliers, dependencies, objectives, resources, stakeholder expectations, or the Profile boundary materially change.

Select a Tier only after defining the Profile scope and reviewing both sides of NIST's notional illustration: cybersecurity risk governance and cybersecurity risk management. Consider how practices are approved and communicated, whether they operate organization-wide, how risk information is shared, how practices adjust to change, and how supplier risk is handled.

NIST encourages movement to a higher Tier when risks or mandates are greater or a cost-benefit analysis shows a feasible, cost-effective reduction in negative cybersecurity risk. A higher Tier is not automatically the right target for every scope, and a Tier should not be calculated by averaging unrelated control scores.

CSF 2.0 is voluntary guidance. It does not prescribe a Tier assessment formula, universal target, certification, effective date, or reassessment interval. A law, regulator, contract, or internal policy may set a separate expectation; record that authority and do not present it as a NIST requirement.

Support the Tier characterization with observations about strategy approval, policy, repeatability, information sharing, risk monitoring, executive involvement, workforce capability, supplier-risk practices, and adaptation to change. The evidence should match the scope and assessment period.

If practices fit different Tier descriptions, explain the variation. The framework does not prescribe a formula for collapsing mixed evidence into a single score. Do not round, average, or select the highest observed practice without a documented method and decision authority.

Set an assessment date and review cadence for the selected Profile boundary. Reassess after material changes in risk, mandates, governance, leadership, business or mission objectives, technology, suppliers, or the boundary, and after improvement work changes the underlying practices. Retain the evidence set, contrary observations, method, reviewers, approver, and rationale for any Current or Target Tier.