Which teams should be accountable for external attack surface management?

Why This Matters for Security Teams

External attack surface management is not a single-team exercise because exposures rarely stay confined to one platform or one owner. Public DNS records, cloud assets, exposed APIs, abandoned SaaS tenants, and forgotten development environments often sit at the boundary between security, IT, cloud engineering, application teams, and business units. NHI Management Group’s 52 NHI Breaches Analysis shows how quickly exposed credentials and service paths become usable once they are visible to attackers, which is why discovery without remediation authority is only half a control. The right accountability model is one where security drives visibility and prioritisation, while asset owners are required to remove, harden, or accept the risk for what they operate. That division aligns with the intent of the NIST Cybersecurity Framework 2.0, which treats external exposure management as an ongoing governance process rather than a periodic scan result. In practice, many security teams encounter the gap only after a third-party service, shadow cloud account, or stale certificate has already been exploited.

How It Works in Practice

Accountability works best when it is mapped to the asset, not just the finding. Security teams typically own continuous discovery, external validation, risk scoring, and escalation paths. They should define what counts as an exposure, who receives it, and what timeframes apply for remediation. IT, cloud, application, and business owners then own the systems in scope and must close the issue or document an exception with an approver.

A workable operating model usually includes:

• an inventory of internet-facing assets tied to business or technical ownership;
• automated detection for domains, IPs, cloud services, certificates, and APIs;
• clear severity criteria for what must be fixed immediately versus scheduled;
• named remediation owners with SLA-based deadlines;
• exception handling for assets that are intentionally exposed and compensated elsewhere.

This is where external guidance helps. NIST SP 800-53 Rev 5 Security and Privacy Controls supports ongoing monitoring and configuration management, while MITRE ATT&CK Enterprise Matrix helps teams understand how exposed systems are commonly discovered and abused after reconnaissance. NHIMG’s NHI Lifecycle Management Guide is especially relevant where attack surface includes service accounts, tokens, or integrations that outlive the systems that created them. These controls tend to break down when ownership is split across subsidiaries or unmanaged SaaS environments because remediation authority is not matched to operational control.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance fast remediation against fragmented ownership structures. That tradeoff becomes most visible in subsidiaries, mergers, and product lines run by semi-independent teams, where a central security function can see the exposure but cannot directly change the asset. In those cases, current guidance suggests using a federated model: central security sets policy, tracking, and escalation, while local teams own actual fixes.

There is no universal standard for this yet, but the most effective programmes treat business owners as accountable for risk acceptance, not just technical teams. A marketing-owned domain, a finance SaaS tenant, or an engineering test environment may each expose different risks, so the accountable party should be the group that can stop the exposure and absorb the business impact. For exposures tied to identities and credentials, the same principle applies: the team operating the system that issued the secret must own revocation and rotation. That is consistent with the patterns described in Top 10 NHI Issues and with the external exposure realities highlighted in Anthropic's first AI-orchestrated cyber espionage campaign report. The model breaks down when remediation paths are undefined for shadow IT, because findings accumulate faster than any one team can close them.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• How should security teams combine XDR with identity attack surface management?
• How can teams tell whether identity attack surface management is working?
• How should security teams use attack surface management to improve control over exposed systems?