Who is accountable when a real attack succeeds despite testing?

Accountability usually sits with the organisation’s security and risk leadership, because testing is meant to reveal control gaps before an incident. If a breach occurs, the key question is whether the programme had appropriate scope, cadence, escalation, and remediation follow through. Compliance frameworks may require testing, but they do not remove operational accountability.

Why This Matters for Security Teams

When a real attack succeeds after testing, the failure is rarely the test itself. It usually means the programme did not translate findings into enforced controls, measurable remediation, and executive risk acceptance. For NHIs, that gap is especially dangerous because secrets, service accounts, and API keys are often used at machine speed and across systems that are difficult to inventory. NHI Mgmt Group notes that the Ultimate Guide to NHIs reports 80% of identity breaches involved compromised non-human identities.

Security leaders are accountable for whether testing covered the right assets, whether critical findings were escalated, and whether remediation actually reduced attack surface. Compliance can prove a test happened, but it cannot prove the environment was hardened. That is why attackers still succeed against exposed secrets, overprivileged service accounts, and stale credentials, even in organisations that can point to recent assessments. Current guidance from CISA cyber threat advisories consistently shows that exploitation follows visibility gaps and delayed response, not lack of policy documentation. In practice, many security teams discover accountability failures only after a control failure has already become an incident.

How It Works in Practice

Accountability should be treated as a chain, not a slogan. The board and executive risk owner set the risk appetite, security leadership defines the control programme, engineering teams remediate, and operations teams verify that fixes remain in place. For NHIs, that means testing must cover secret storage, rotation, revocation, privilege scope, third-party exposure, and service-to-service authentication, not just periodic scans.

Effective programmes tie each test finding to an owner, a due date, a severity rating, and a validation step. If a service account is found with excessive privileges, the question is not only whether the issue was logged, but whether access was reduced, whether the credential was rotated, and whether the account was monitored for misuse afterward. The control objective is to shrink the window between discovery and exposure. NHI Mgmt Group highlights in the Ultimate Guide to NHIs that 71% of NHIs are not rotated within recommended time frames, which shows how often remediation stalls.

• Assign each finding to a named control owner, not just a team.
• Track remediation SLAs separately for critical secrets, privileged accounts, and externally exposed tokens.
• Require retesting after fix implementation, not just ticket closure.
• Escalate unresolved high-risk items to risk leadership with explicit acceptance or funding decisions.

Good testing also uses real attacker behavior as the benchmark. Mapping findings to the MITRE ATT&CK Enterprise Matrix helps show how an exposed credential can become lateral movement, privilege escalation, or persistence. These controls tend to break down in organisations with unclear asset ownership and no enforced remediation workflow, because findings can sit open long after the original test has been signed off.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster remediation against change-control friction and distributed ownership. That tradeoff becomes sharper in cloud and SaaS environments, where a single secret may be embedded in code, CI/CD, or multiple connected services.

There is no universal standard for this yet, but current guidance suggests that accountability should shift with the failure mode. If testing missed a critical system, the control design is at fault. If testing found the issue but remediation stalled, execution and governance are at fault. If leadership accepted the risk, that acceptance should be explicit, time-bound, and reviewable. The same logic applies when third parties hold or process NHIs. A vendor exposure does not remove internal accountability for due diligence, monitoring, or contract enforcement. The 52 NHI Breaches Analysis is a useful reminder that repeat incidents often reflect recurring control gaps, not isolated mistakes.

For agentic AI and automated workloads, accountability also extends to how identity and privilege are issued at runtime. Static role assignments are often too blunt for autonomous systems, so teams should align testing with workload identity, short-lived secrets, and policy evaluation at request time. Standards such as NIST SP 800-53 Rev. 5 Security and Privacy Controls help structure the programme, but they do not replace leadership judgment about whether the residual risk is acceptable. The practical edge case is simple: accountability becomes contested when a team can show it tested something, but cannot show it changed the outcome.

Related resources from NHI Mgmt Group

• Who is accountable when an impersonation attack succeeds through a compromised supplier account or a lookalike domain?
• What is the difference between attack surface management and NHI governance?
• Why do application testing tools matter for NHI governance?
• Who is accountable when a prompt bombing attack succeeds?