The organisation operating the software is accountable for deployment, validation, and risk acceptance. A vendor release does not eliminate exposure until the update is applied and verified. Governance teams should assign clear ownership for patch adoption, especially where the software affects authentication, automation, or other privileged workflows.
Why This Matters for Security Teams
A patch that exists but is not deployed leaves the organisation carrying the operational risk, even if the flaw is already public and the vendor has issued remediation. That distinction matters because accountability is not the same as authorship: the software supplier may have created the fix, but the asset owner decides when exposure ends. For governance and audit teams, that is a control issue, not a procurement issue.
The gap becomes more serious when the affected component sits in authentication, access enforcement, secrets handling, or automation paths. A delayed update can preserve known attack paths, undermine change records, and complicate risk acceptance. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes it clear that patching is part of ongoing system maintenance and continuous risk management, not a one-time vendor obligation. In practice, many security teams encounter this as a reporting failure only after attackers have already tested the unpatched condition.
How It Works in Practice
Accountability usually follows control ownership. Infrastructure, application, or platform teams may execute the deployment, but the business owner, service owner, and security function share responsibility for ensuring the patch is assessed, scheduled, validated, and tracked to closure. If the software supports privileged access, identity flows, or machine-to-machine transactions, the owner should treat the patch as part of operational resilience rather than routine housekeeping.
Good practice separates four decisions:
Is the patch relevant to the deployed version and exposed environment?
What is the impact of installation on availability, integrations, and authentication flows?
Is a compensating control required while deployment is pending, such as segmentation, feature disablement, or tighter monitoring?
Who formally accepts residual risk if the patch cannot be applied immediately?
Security teams often anchor this process to vulnerability management and change management workflows, with clear service-level targets for critical fixes. Where identity systems are involved, validation should include login paths, federation, token issuance, session handling, and any privileged automation tied to the updated component. For broader response workflows, CISA’s Known Exploited Vulnerabilities Catalog is useful for prioritising patches that are already under active exploitation, while the MITRE ATT&CK framework helps map likely abuse paths if deployment slips. These controls tend to break down when legacy systems require manual change windows and there is no authoritative owner for production risk.
Common Variations and Edge Cases
Tighter patch governance often increases operational overhead, requiring organisations to balance speed against service stability, testing depth, and regulatory evidence. That tradeoff is especially visible in regulated environments, high-availability platforms, and vendor-managed services where the party issuing the patch is not the party operating the risk.
There is no universal standard for this yet, but current guidance suggests a few consistent exceptions. A vendor may be responsible for creating and distributing a fix, while the customer remains accountable for deployment unless the contract explicitly transfers operational control. In managed SaaS or outsourced environments, accountability can be shared, but the consuming organisation still needs proof that exposure is being reduced. In some cases, temporary compensating measures are the right answer, but they do not remove the obligation to track the unpatched state and set a deadline.
For systems that support authentication, secrets, or non-human identities, delayed patching can also become a governance problem: dormant service accounts, stale tokens, or privileged automations may continue to function against a known vulnerable component. That is why patch records should be linked to asset criticality, ownership, and exception handling. Teams looking for a more formal control mapping can also align this work to the broader security expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and use vulnerability intelligence from CISA’s Known Exploited Vulnerabilities Catalog to sharpen prioritisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.GV-1 | Governance defines who owns patch risk and exception approval. |
| MITRE ATT&CK | T1190 | Publicly known flaws are often exploited before patching is complete. |
| NIST SP 800-53 Rev 5 | SI-2 | Flaw remediation control directly addresses patching and update oversight. |
Implement a documented flaw remediation process with testing, deployment, and verification.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
