Accountability should be shared, but not blurred. The asset owner remains responsible for risk acceptance and oversight, while the managed services provider is responsible for timely remediation and clear reporting. In critical infrastructure, that division must be explicit in contracts and governance, because a patching miss can leave an attacker undetected for months and expose public services to disruption.
Why accountability has to be explicit, not implied
This question is really about governance failure, not just a missed maintenance task. In a managed services model, patching is operationally outsourced, but accountability for the risk does not disappear. The organisation that owns the infrastructure must still define the control objective, approve risk acceptance, and verify that the provider’s work is actually completed on time.
That distinction matters because infrastructure firewalls sit on a high-consequence trust boundary. If ownership is vague, the patch can be deferred by one party while assumed complete by the other, and the resulting exposure may persist until an external event forces discovery.
A useful way to frame this is shared execution with retained accountability. The provider performs the patching duty, but the asset owner remains accountable for whether the control outcome is achieved and evidenced. That is the same principle behind explicit control ownership in NIST Cybersecurity Framework 2.0: one party can operate the control, but someone must own the outcome.
In practice, this also means the contract needs more than a service description. It should define patch windows, emergency change handling, reporting cadence, escalation triggers, and what constitutes overdue remediation. Without those details, accountability becomes a post-incident argument instead of an operating model.
What “shared” really means in critical infrastructure
Shared accountability does not mean shared blame in equal proportions. It means each party has a different duty that must be auditable. The provider is accountable for timely remediation, accurate status reporting, and preserving change evidence. The asset owner is accountable for oversight, risk acceptance, and making sure exceptions are visible to operational leadership.
That division is especially important in critical infrastructure because delayed patching can turn a known vulnerability into a prolonged exposure. The longer the firewall remains unpatched, the more opportunity exists for exploitation, reconnaissance, and lateral movement across segments that were supposed to be protected.
For infrastructure teams, the question is not only whether a patch was scheduled. It is whether the provider can prove the patch was applied, whether the owner can prove it was reviewed, and whether unresolved exceptions were escalated quickly enough to prevent silent exposure. Federal and sector advisories regularly stress timely remediation for exposed vulnerabilities, particularly in critical environments like those covered by CISA cyber threat advisories and CISA Industrial Control Systems guidance.
When the asset is part of essential services, governance also needs to recognize that a missed patch is not just a configuration issue. It is a resilience issue, because the firewall may be the last control preventing service disruption, downtime, or broader operational impact.
How to assign accountability so the gap does not repeat
The cleanest model is to separate responsibility from accountability and document both in the governance record. The managed services provider should own patch execution, change validation, and notification of completion or exception. The asset owner should own risk acceptance, service-level oversight, and the decision to escalate when remediation slips.
What to verify: confirm that the contract names the firewall service owner, the provider’s remediation SLA, the escalation path for missed patches, and the evidence required for closure. If any of those are missing, accountability is still ambiguous even if the provider is technically “responsible” for patching.
Decision rule: if a critical firewall patch is overdue, treat it as a governance exception first and a vendor performance issue second. The owner should demand an exception record, a revised remediation date, and a clear statement of residual exposure until the patch is complete.
Practitioner takeaway: accountability is strongest when the owner retains risk authority and the provider retains execution duty, with documented proof that the control outcome was achieved, not merely promised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while NIS2 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV — Oversight | Ownership and vendor oversight are central to accountability for missed remediation. |
| PR.IP — Information Protection Processes and Procedures | Patch windows, exception handling, and change tracking depend on documented procedures. | |
| Recommendation — Assign oversight for outsourced patching and verify that control outcomes are evidenced, not assumed. Define patching procedures, escalation paths, and exception handling for critical infrastructure assets. | ||
| CIS Controls v8 | 7 — Continuous Vulnerability Management | A missed critical firewall patch is a vulnerability management failure requiring tracking and remediation. |
| 17 — Incident Response Management | Overdue patching of a critical firewall can require escalation and response coordination if exposure is active. | |
| Recommendation — Track, prioritise, and remediate critical vulnerabilities within defined service-level expectations. Escalate overdue critical patch exceptions through incident response and exception management workflows. | ||
| NIS2 | 2 — Risk management measures | Critical infrastructure operators must govern security measures and supplier performance for essential services. |
| Recommendation — Formalise supplier patch obligations, accountability, and risk acceptance for essential service assets. | ||
| DORA | 3 — ICT third-party risk management | Managed services accountability and oversight are core third-party risk issues in outsourced operations. |
| Recommendation — Contractually require measurable patch SLAs, reporting, and escalation for third-party ICT services. | ||
Related resources from NHI Mgmt Group
- Who should be accountable for coordinating response when a critical infrastructure attack affects public services?
- Who is accountable when machine identity controls fail in critical infrastructure?
- Who should be accountable when an identity failure affects critical infrastructure or delegated AI access?
- Who is accountable when a container escape affects managed Kubernetes services?
