Accountability should sit with the security and infrastructure owners who control the affected assets, supported by governance that requires change tracking, remediation ownership, and retesting. Pentest results are only a starting point. If exposure grows after the test, teams need clear ownership for drift detection and for closing the gap before the next assessment.
Why This Matters for Security Teams
exposure drift after a pentest is not a testing problem, it is an ownership problem. Once the assessment ends, asset changes, new integrations, emergency patches, and credential sprawl can all reopen the attack path that the test just closed. NHI Mgmt Group data shows 91.6% of secrets remain valid five days after notification, which is why post-test state must be treated as a living risk surface rather than a frozen report.
This becomes especially important for NHI-heavy environments where service accounts, API keys, and automation tokens keep working long after the humans who created them have moved on. Guidance from Ultimate Guide to NHIs and NIST SP 800-53 Rev 5 Security and Privacy Controls points to the same operational reality: if changes are not tracked, exposure returns between assessments. In practice, many security teams discover drift only after a compensating control fails or a second test confirms the same weakness persisted or reappeared.
How It Works in Practice
Accountability for post-pentest drift should sit with the asset owner and the platform or infrastructure owner, not with the tester. The tester identifies exposure at a moment in time. The owner is responsible for keeping the control effective after code changes, configuration updates, secret rotations, and permission changes. That means drift detection must be part of the operating model, not a separate follow-up task.
A practical workflow usually includes:
- Assigning a named remediation owner for every finding, with an explicit due date and retest trigger.
- Tracking the exact assets, secrets, and identities in scope so later changes can be compared against the original exposure.
- Using change-management records to verify whether a fix still exists after deployment, not just when the ticket was closed.
- Revalidating secrets and NHI permissions after infrastructure changes, especially for service accounts and API keys.
This is where NHI governance becomes operationally useful. The 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both reinforce that exposure often persists because secrets and identities are not continuously inventoried. When a pentest finds an issue, the right response is not simply to mark it remediated. It is to tie the finding to an owner, a control, and a verification step that proves the exposure did not drift back. These controls tend to break down when ownership is split across app, cloud, and IAM teams because each team assumes another team is watching the post-change state.
Common Variations and Edge Cases
Tighter ownership often increases coordination overhead, requiring organisations to balance faster remediation against clearer accountability. That tradeoff is real in complex environments where one team manages the application, another owns the cloud landing zone, and a third controls secrets or CI/CD pipelines.
Current guidance suggests the same rule still applies: whoever can change the exposure should be accountable for keeping it from drifting. In shared-service models, that may mean joint ownership with one named operational lead. In outsourced or platform-managed environments, accountability still remains with the customer organisation for risk acceptance and verification, even if execution is delegated.
There is no universal standard for this yet, but best practice is evolving toward continuous validation rather than point-in-time sign-off. This is especially true for NHI-heavy estates where exposure can reappear through rotated tokens, copied credentials, inherited permissions, or missed offboarding. The risk is not just stale findings, it is silent re-expansion of access after the pentest report is closed. Teams that use Salesloft OAuth token breach as a reference case usually see why drift ownership must extend beyond the test window.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Post-test drift often comes from unmanaged secret and identity sprawl. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is required to spot when exposure changes after testing. |
| NIST AI RMF | Accountability for evolving risk maps to AI RMF governance and monitoring. | |
| NIST Zero Trust (SP 800-207) | PA-3 | Drift reflects broken continuous verification across changing environments. |
Keep asset and identity inventories current so drift can be detected and reconciled quickly.
Related resources from NHI Mgmt Group
- Who is accountable when unsigned webhooks or legacy OAuth connections are left in place after a security alert?
- Who is accountable when insecure app-to-app connections create a supply chain exposure?
- Who is accountable when identity drift or excessive access affects regulated aviation operations?
- Who is accountable when high-risk access is approved after a weak identity check?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
