Why the NIST Cybersecurity Framework Needs a Seventh Function: Validate

The NIST Cybersecurity Framework succeeds partly because its highest-level Functions are memorable verbs. They give executives, operators, auditors, suppliers, and risk owners a shared language for organizing cybersecurity outcomes without prescribing one implementation method.

CSF 2.0 currently defines six Functions: Govern, Identify, Protect, Detect, Respond, and Recover. PatientLock proposes a seventh: VALIDATE. The purpose of VALIDATE would be to establish, using current evidence, whether an action, remediation, recovery step, configuration change, automated response, or other intervention actually produced the state that was required.

The proposal is intentionally narrow. VALIDATE is not another word for audit. It is not an assertion that every security action requires an independent third party. It is the explicit lifecycle requirement to return to the environment after intervention, observe what is now true, compare the resulting state with the required state, keep ambiguity open when evidence is insufficient, and feed the validated result back into the next risk decision.

A serious case for VALIDATE has to begin by acknowledging what NIST already does. CSF 2.0 is not a six-step checklist, and NIST explicitly describes the Functions as concurrent and continuous. The framework also includes an Improvement category within Identify, while other NIST publications provide mature disciplines for control assessment, continuous monitoring, ongoing authorization, testing, and assurance.

NIST SP 800-53A Revision 5 provides assessment procedures for determining whether security and privacy controls are implemented correctly, operating as intended, and producing desired outcomes. NIST SP 800-137 addresses continuous monitoring and ongoing visibility into assets, threats, vulnerabilities, and the effectiveness of deployed controls. Those are substantial bodies of work and they matter to this proposal.

The gap is therefore not the absence of validation-related activity. The gap is abstraction. At the highest level of the CSF, no Function is named for the act of establishing that the state after intervention is the state that was required. Assessment, monitoring, testing, and improvement are distributed across the framework and its supporting publications rather than elevated as a top-level lifecycle responsibility.

Modern security systems are increasingly able to act. An endpoint agent can change a firewall rule. An EDR platform can isolate a host. An identity platform can revoke a session. A vulnerability workflow can launch a patch. A SOAR playbook can execute a sequence of changes. An autonomous agent can choose and carry out a remediation path.

None of those actions proves that the intended condition now exists. The command can fail. The target can be wrong. A dependency can prevent the change from taking effect. A compensating process can undo it. The system can report success before the underlying state converges. The intervention can fix one condition while creating another. A human can close the ticket while the environment remains unchanged.

Control systems distinguish actuation from state. Cybersecurity should make the same distinction explicit at the framework level. The relevant question after an action is not merely whether the command ran; it is whether the resulting observed state satisfies the requirement that justified the action.

DETECT asks whether a cybersecurity event, anomaly, or relevant condition is occurring or has occurred. VALIDATE asks whether a required condition is actually present after an intervention or at a decision point. Detection can initiate validation, but the two are not interchangeable.

RESPOND organizes outcomes for acting on a detected cybersecurity incident. VALIDATE asks whether the response produced the required security state. Containment, credential revocation, policy change, endpoint isolation, or remediation can all be response activities; validation establishes whether their intended effects are now observable.

RECOVER organizes outcomes for restoring assets and operations affected by a cybersecurity incident. VALIDATE asks whether the recovered environment satisfies the security, integrity, dependency, and operating conditions required to return it to service. A system can be online without being safe, complete, correctly authorized, or ready for patient care, production, or financial operations.

GOVERN, IDENTIFY, and PROTECT also benefit from the distinction. Governance establishes expectations and authority. Identify establishes understanding of risk and assets. Protect establishes safeguards. VALIDATE provides an explicit way to establish whether the safeguards and interventions continue to produce the required state in the environment that actually exists.

PatientLock uses a six-stage operational loop inside VitalSec: Observe, Decide, Act, Validate, Prove, Measure. That loop is not proposed as a replacement ordering for the NIST CSF Functions. NIST correctly treats its Functions as concurrent and continuous. The VitalSec loop is a control-system view of how a specific condition moves from observation through intervention into evidence and measurement.

The distinction matters because a loop that ends at Act is open with respect to state. A loop that moves from Act directly to Prove risks proving only that an action was attempted. A loop that moves from Act directly to Measure can quantify a state transition that was never established. VALIDATE is the point where the environment is re-observed and the required state is tested before downstream proof and measurement inherit the result.

This is also why PatientLock prefers Validate to Verify as the top-level verb. Verification is an important technique inside validation: verify a signature, verify a configuration value, verify a command receipt, verify a sensor reading. Validation is the broader determination that the resulting state, supported by those checks and observations, satisfies the requirement that matters to the decision.

A future VALIDATE Function would not need to prescribe one testing tool or one assurance method. It could remain consistent with the CSF's outcome-based design while making several outcomes explicit.

First, the organization re-observes the relevant system, control, asset, identity, exposure, or dependency after material intervention. Second, the observed state is compared with an explicit required or target condition. Third, the evidence supporting the conclusion has sufficient provenance, integrity, freshness, and completeness for the decision being made. Fourth, failed, conflicting, stale, or ambiguous evidence remains visible rather than being silently converted into a successful result.

Fifth, validation results feed improvement, governance, response, recovery, and risk decisions. Sixth, material automated actions are followed by state validation under the same authority boundary that governed the action. Seventh, organizations maintain enough continuity of validation to distinguish a state that remains supported from one that was observed only once.

Those outcomes can be implemented through automated re-observation, active control testing, configuration inspection, endpoint measurement, identity queries, recovery exercises, external probes, manual assessment, independent testing, or combinations of methods. The Function would define the outcome; organizations would choose the mechanism appropriate to risk and context.

The distinction between action and validated state becomes more important as remediation accelerates. Human-operated workflows often conceal the gap because a person informally checks the environment after making a change. Automation removes that implicit human step unless the system is designed to reproduce it deliberately.

An autonomous security system that can decide and act but cannot establish the resulting state is not closed-loop autonomy. It is automated actuation. Confidence scores, model reasoning, and tool success messages do not substitute for observation of the environment after the action.

The governance implication is significant. Organizations should be able to grant bounded authority to an automated actor while separately requiring evidence that the authorized change achieved the expected result. If validation fails, the system should fail visibly, preserve the evidence, and return the condition to the appropriate decision authority instead of escalating automation on the basis of its own unconfirmed action.

In healthcare, the difference between action and validated outcome can affect patient-care operations. Restoring a server does not by itself establish that clinical dependencies, identity paths, data integrity, endpoint protections, and required controls are ready for return to service. A recovery process needs evidence of the resulting operating state, not only evidence that restoration steps ran.

In cyber insurance, the difference affects underwriting, renewal, material-change review, and claims. A remediation representation is stronger when the organization can show the pre-action condition, the authorized intervention, the post-action observation, the evidence supporting the resulting state, and whether that state persisted. That chronology is more decision-useful than a closed ticket or annual attestation alone.

The same principle applies to boards, regulators, auditors, managed security providers, and counterparties. Each depends on claims about state. VALIDATE makes the question explicit: what evidence establishes that the condition being relied upon is true now, or was true at the decision time that matters?

Adding VALIDATE would not turn the CSF into a sequential seven-step process. The existing Functions are concurrent and continuous, and VALIDATE should be treated the same way. Validation can occur during protection, after response actions, during recovery, during routine operations, before a consequential decision, and whenever evidence becomes too old or incomplete to support a state claim.

It would not make every control continuously testable. Some outcomes require periodic exercises, manual review, physical inspection, third-party evidence, or other forms of assurance. The requirement should be evidence appropriate to the claim and decision, not automation for its own sake.

It would not imply that NIST endorses PatientLock, VitalSec, the Ford Model, or this proposal. NIST does not certify or endorse commercial CSF implementations. This paper is PatientLock research offered as a framework-design argument for discussion.

And it would not eliminate uncertainty. Validation can fail, evidence can conflict, and risk can remain. The purpose is not to manufacture certainty. The purpose is to stop treating unobserved outcomes as though they were established facts.

The evolution from CSF 1.1 to CSF 2.0 already demonstrated that elevating an important cross-cutting discipline can improve the framework. GOVERN was promoted to a top-level Function because governance deserved clearer visibility across the lifecycle. PatientLock believes validation now deserves the same design consideration.

Cybersecurity increasingly depends on systems that observe, recommend, decide, act, recover, and automate at machine speed. The framework language should make one principle impossible to skip: after material intervention, the environment has to answer back.

VALIDATE would give that responsibility a name at the highest level. Re-observe the state. Test it against what was required. Keep failures and ambiguity visible. Preserve the evidence. Then allow governance, proof, measurement, and the next decision to proceed from something the organization can actually support.