Search every question across sub-FAQs

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.

Start by documenting the organizational context that should govern later control choices: mission, internal and external stakeholders, legal, regulatory, and contractual requirements, critical services, and external dependencies. Then establish the risk-management strategy, including objectives, risk appetite and tolerance, response options, communication paths, and a consistent method for prioritizing risk.

Assign and communicate leadership accountability, operational roles, authorities, and resources. Establish policy from the approved context and strategy, set oversight that uses performance results to adjust direction, and define the cybersecurity supply-chain risk management program. Controls can then be selected and mapped to specific outcomes and Target Profile priorities.

The Core does not prescribe a step-by-step implementation sequence, and all six Functions should be addressed concurrently. GOVERN sits at the center because it informs how the other five Functions are implemented and prioritized.

NIST published CSF 2.0 on February 26, 2024 as voluntary, sector-, country-, and technology-neutral guidance. GOVERN does not itself create a legal duty, board mandate, certification, control set, or universal review deadline. Applicable laws, regulations, contracts, and internal policies remain separate inputs under GV.OC-03 and may make particular actions or dates mandatory.

Evidence should show that governance decisions are established, communicated, used, and reviewed, not merely that a policy document exists. Match each record to a GOVERN Subcategory and state the boundary, owner, period, decision, exceptions, and next review trigger.

Typical records include approved risk objectives and appetite statements, requirement registers, role and authority matrices, budgets, policies and revision histories, risk committee minutes, performance reviews, supplier inventories and criticality decisions, contract requirements, due-diligence records, monitoring results, incident coordination plans, and exit provisions.

Set a recurring governance review cadence and event triggers. Reopen the relevant decision after a material change in mission, stakeholder expectations, requirements, threat environment, technology, organizational structure, suppliers, dependencies, performance, or risk estimates. Retain the inputs reviewed, decision authority, challenge or dissent, decision, action owner, due date, and closure evidence.

A CSF Organizational Profile describes an organization's current and/or target cybersecurity posture in terms of the CSF Core outcomes. A Current Profile specifies the Core outcomes that an organization is currently achieving (or attempting to achieve) and characterizes how or to what extent each outcome is being achieved.

Start by documenting the facts and assumptions that define scope. A Profile may cover the whole organization, a business unit, a system set, or a use case such as ransomware. For each selected outcome, state the current condition, supporting evidence, material exceptions, dependencies, and the risk implication of the result.

NIST does not call a Current Profile an audit opinion or certification. It is a scoped description used to assess posture, communicate capabilities and improvement opportunities, and compare the current state with a Target Profile.

CSF 2.0, published February 26, 2024, is voluntary and sector-, country-, and technology-neutral. It does not set a universal completion date or scoring method. If a law, contract, regulator, or internal policy makes a result mandatory, record that separate authority, its effective date, and its evidence requirement against the relevant outcome.

Compare the Current Profile with the Target Profile only when both use compatible boundaries and outcome identifiers. Analyze each difference, then place the chosen response in a prioritized action plan such as a risk register, risk detail report, or plan of action and milestones.

Update the Profile after actions change the current state and when requirements, threats, technology, mission objectives, stakeholders, dependencies, or scope change. NIST's five-step Profile process is iterative and may be repeated as often as needed; it does not prescribe an annual cycle. Keep the prior assessment date and evidence period visible so a reviewer can distinguish a new result from an old claim.

Report the measures that help executives decide whether to maintain or adjust risk strategy, priorities, resources, or risk responses. Pair each measure with its business or mission objective, scope, owner, trend, threshold, data period, and the decision or escalation it can trigger. Connect the threshold to the organization's approved risk appetite or tolerance statement.

Current-to-Target Profile gaps and action-plan status show whether priority outcomes are moving. Risk indicators show changes in exposure or impact. Performance indicators show whether a selected practice operates as intended. Control counts can supply detail, but they do not show business significance unless they are connected to a Core outcome and risk decision.

Use CSF Tiers only when the organization has chosen them to inform its Profiles. Report the supporting governance and risk-management observations; do not present Tier movement as a universal maturity score or imply that Tier 4 is always the required destination.

NIST published CSF 2.0 on February 26, 2024 as voluntary, outcome-based guidance for organizations of any size or sector. It does not create a universal reporting deadline, metric formula, certification, or legal safe harbor. A law, regulator, customer agreement, insurer, or internal policy may impose separate measures or reporting dates, so record those requirements beside the CSF outcome instead of presenting them as NIST requirements.