Ownership is usually split. Security engineering or cloud security should own discovery, inventory accuracy, and prioritisation. The workload or platform team should own remediation because only they can retire a subdomain, close a trust policy, or remove an exposed endpoint. Clear accountability prevents the common failure mode where security produces findings but nobody can act on them.
How Ownership Should Be Split Across Security and Platform Teams
attack surface management works best when ownership follows the work, not the finding. Security should own the system that discovers exposure, normalises inventory, and decides what is most urgent. Platform or workload teams should own the systems and configurations that actually remove exposure, because they control the service, DNS record, trust relationship, or endpoint that must change.
This split is more than a RACI exercise. It reflects who can verify reality, who can execute safely, and who can prove that an exposed asset is no longer reachable. When those responsibilities are blurred, organisations usually get stalled findings, duplicate remediation, or a false sense that a report is action.
Why Security Owns Visibility and Prioritisation
Security is the right owner for discovery quality because attack surface data is only useful if it is complete, deduplicated, and comparable over time. That means maintaining the inventory source, resolving ambiguity across scanners and cloud accounts, and prioritising by exposure, reachability, and business impact rather than by whoever shouts loudest.
Security also needs enough authority to challenge bad assumptions. A subdomain may look benign in one scanner but still resolve publicly, a stale endpoint may still accept traffic, and a third-party hosted asset may be forgotten long after the project ended. Discovery ownership sits with the team best positioned to see the whole picture, not the team closest to any one service.
Security teams should use CISA cyber threat advisories to help tune prioritisation when exposed services line up with active exploitation patterns, and they should keep the discovery process tied to the actual attack surface rather than to a static asset list. Where exposed machine or service credentials are part of the surface, NHIMG’s The 52 NHI Breaches Report is a useful reminder that leaked access material often turns inventory errors into real compromise.
Why Platform Teams Own Remediation
Platform teams should own remediation because they can make the change that removes the exposure. In practice, that may mean deleting a forgotten subdomain, tightening an ingress rule, rotating a secret, closing a trust policy, revoking a certificate, or shutting down an endpoint that security can only flag. If the team operating the service does not own the fix, the work often becomes a ticket with no natural executor.
The cleanest operating model is to give security the power to identify and escalate, while giving platform teams clear authority to remediate within their service boundary. That keeps accountability with the people who understand change risk, deployment timing, and dependencies. It also reduces the common failure mode where remediation is delayed because no one wants to touch production without the right context.
For cloud and platform environments, the remediation owner should also own the proof of closure. That means validating that the exposed route no longer resolves, the policy is no longer permissive, or the secret can no longer be used. If the fix cannot be verified from outside the service boundary, the asset is not really closed yet.
How to Prevent the Findings Without the Fix Problem
The practical failure mode is split accountability without a handoff rule. Security finds exposure, platform teams assume it is a monitoring issue, and the finding lives in a queue until the next review cycle. The better model is a single owner for each remediation item, a clear service boundary, and an explicit closure test that the receiving team must satisfy.
Ownership works best when it is mapped to the control point. If the problem is exposure discovery, deduplication, or risk ranking, security owns it. If the problem is changing the service, infrastructure, DNS, certificate, or trust relationship, platform owns it. If a finding crosses both boundaries, security should coordinate, but the service team must still be the accountable fixer.
Teams should also watch for ownership drift at scale. As the number of cloud accounts, service accounts, and ephemeral endpoints grows, discovery becomes centralised by necessity, but remediation must remain decentralised to the teams that can change the system safely. The moment those teams lose clarity on who closes what, attack surface management turns into reporting rather than reduction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Attack surface ownership depends on finding and removing exposed configuration weaknesses. |
| CIS-5 — Account Management | Exposure often persists through stale accounts, service accounts, and credentials tied to the attack surface. | |
| Recommendation — Assign platform teams to remediate exposed configurations and verify closure. Track ownership for accounts and credentials that can create or remove exposure. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Attack surface includes access paths and trust relationships that must be governed and removed by the right owner. |
| GV.RM-01 — Risk Management Roles and Responsibilities | The question is fundamentally about who is accountable for managing exposure risk across teams. | |
| Recommendation — Map responsibility for access-path removal to the team that controls the platform. Define explicit accountability for discovery, prioritisation, and remediation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud attack surfaces often persist through excessive access and trust configurations. |
| Recommendation — Make the platform owner responsible for closing trust and access paths. | ||
Practitioner Guidance
What to prioritise: Define one owner for discovery and one accountable owner for remediation on every finding. If a team cannot directly remove the exposure, it should not be the final remediation owner.
What to verify: Require an observable closure check, not just a ticket update. The exposed asset should stop responding, the trust path should be removed, or the secret should be invalidated before the finding is marked closed.
Common mistake: Treating attack surface management as a security-only programme. That usually produces good dashboards and poor reduction, because the teams who can actually change the surface were never made accountable for the fix.
Practitioner takeaway: Security should own visibility and decisioning, platform should own removal and verification. If one team owns both without the other’s cooperation, the process usually becomes either noisy or ineffective.
Related resources from NHI Mgmt Group
- How should security teams evaluate external attack surface management across both security and IT priorities?
- How should security teams implement attack surface management across digital, physical, and human risk domains?
- What is the difference between attack surface management and NHI governance?
- How should security teams make NHI best practices usable across the business?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
