Accountability should sit with the supplier’s security leadership, operations owners, and the business unit that approved the exception. If the system supports sensitive clients or critical services, governance must also include customer-facing risk review. Shared responsibility does not remove ownership. Someone must approve exposure, document compensating controls, and ensure the exception is time limited and continually reviewed.
What accountability means when the supplier keeps the system internet-reachable
Accountability should be assigned to named owners, not left to a vague shared-services model. If a supplier keeps an unsupported system reachable from the internet, the supplier must own the technical and operational risk, while the customer side must own the decision to tolerate that exposure, including any business justification, compensating controls, and expiry date for the exception.
The key distinction is between operating the system and accepting the risk. The supplier security lead and operations owner are accountable for hardening, monitoring, and decommission planning. The approving business owner is accountable for whether the exposure is acceptable, especially when the system touches sensitive data, regulated workflows, or critical services.
When the supplier is not the legal owner but is still the effective operator, accountability should follow the party that can actually change the state of the system. That means the organization with authority over patching, network exposure, logging, and retirement must be able to explain why the unsupported asset remains exposed and who signed off on that choice.
Why unsupported and internet-reachable is a governance problem, not just a technical one
An unsupported system connected to the public internet creates a gap between residual risk and ownership. Unsupported software may not receive security fixes, but the more important issue is that internet reachability makes exploitation, scanning, and opportunistic abuse far more likely. That turns the exception into a governance decision, not a routine maintenance issue.
Shared responsibility does not remove ownership, it often makes ownership harder to see. In practice, the failure mode is that each party assumes the other is tracking patch status, service criticality, or exposure review. That is why accountable ownership must be explicit, documented, and tied to a control that can force action when the exception ages out.
If the system supports sensitive clients or critical services, the approval process should include a customer-facing risk review. The decision is no longer only about internal tolerance for technical debt, it also affects downstream confidentiality, availability, contractual assurances, and incident response obligations.
What should be documented before the exception is allowed to stand
Any exception should record who approved it, what business need justifies it, which compensating controls are in place, and when it will be reassessed. That includes network restriction, monitoring, and an explicit retirement plan. If those details do not exist, the organisation has not really approved the risk, it has simply deferred it.
The approval record should also state whether the system is internet-facing by necessity or by convenience. That matters because the tolerance for an unsupported asset is very different when remote access is unavoidable versus when exposure persists only because no one has forced a closure date or migration plan.
Where the system handles production workloads, the owner should be able to show a named remediation path, not just a ticket number. A credible exception is time-limited, reviewed at a fixed cadence, and linked to a measurable control objective such as removal of public access, replacement of the platform, or full service retirement.
Risk and Threat Considerations
An unsupported system that remains reachable from the internet has a clear exposure profile: it is easier to find, easier to probe, and harder to defend over time. The longer the exception remains open, the more likely it is that known weaknesses, weak configuration, or abandoned access paths become practical attack opportunities.
Failure mechanism: Public reachability expands the attack surface while unsupported status removes the normal patch-and-fix path. If the supplier has not imposed compensating controls, an attacker can exploit scanning, old vulnerabilities, weak administration paths, or inherited trust in the exposed service.
Impact: The result can be unauthorized access, service disruption, data exposure, or a wider compromise of connected environments. If the asset supports critical services or sensitive clients, the consequence is not just a technical incident, it is a governance failure that can cascade into contractual, operational, and reputational damage.
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 NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Supports assigning ownership for accepted supplier exposure risk. |
| GV.OC-03 — Roles, Responsibilities, and Authorities | Applies because the question is about who is accountable for the exception. | |
| PR.AA-05 — Identity Management, Authentication, and Access Control | Relevant where internet reachability depends on access control and exposure management. | |
| Recommendation — Define who can accept, track, and time-limit supplier exposure exceptions. Document named owners for technical remediation and business risk acceptance. Restrict public access paths and remove unnecessary exposure for unsupported systems. | ||
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | Fits the need to assess and justify the residual risk of an unsupported internet-facing system. |
| CA-5 — Plan of Action and Milestones | Applies because exceptions need tracked remediation and expiry discipline. | |
| Recommendation — Assess residual risk before approving any internet-facing unsupported-system exception. Track the exception as a time-bound remediation item with clear ownership. | ||
| ISO/IEC 27001:2022 | A.5.8 — Information security in project management | Relevant when unsupported exposure requires formal approval and change control. |
| A.5.24 — Information security incident management planning and preparation | Supports readiness when exposed unsupported systems may be targeted or compromised. | |
| Recommendation — Embed exception approval and retirement planning into the change process. Prepare response ownership and escalation paths for externally reachable unsupported assets. | ||
Practitioner Guidance
What to prioritise: Assign one accountable owner for the risk acceptance decision and a separate operational owner for remediation. If those roles are not explicit, the exception will survive by ambiguity rather than by judgment.
What to verify: Confirm that the system’s public exposure is intentional, the compensating controls are active, and the exception has a review date. If the record cannot show who can shut the exposure down, the approval is incomplete.
Decision rule: If the system is unsupported and internet-reachable, treat it as a time-bound risk acceptance, not a steady state. If it supports sensitive clients or critical services, require a higher level of review and a tighter remediation deadline.
Practitioner takeaway: Accountability follows authority over both the exposure and the exception, and the approval must be specific enough that someone is clearly responsible when the risk is still open next month.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
