Accountability usually sits with the teams that own access governance, logging, and incident response, but the broader obligation is organisational. For critical infrastructure, the business must be able to produce identity evidence fast enough to support reporting and investigation.
Who owns the evidence gap when a SOCI incident hits?
Accountability is rarely a single person’s problem. It sits with the function that owns access governance, the team that runs logging and retention, and the incident response lead who must turn partial records into a defensible timeline. In practice, the organisation is accountable for being able to produce evidence fast enough to support investigation and reporting.
Why missing identity evidence becomes an ownership issue
When identity evidence is missing, the first failure is usually not forensics, it is governance. Someone should have been able to show who had access, when that access changed, what authenticator or secret was used, and whether the event was traceable across systems. If those records do not exist, the gap often reflects weak ownership, weak logging design, or weak retention rather than a single bad incident response decision.
The practical question is not only who investigates after the fact, but who was responsible for making evidence available before the incident. That includes identity lifecycle controls, audit logging, privileged access review, and retention decisions that determine whether the organisation can reconstruct action after compromise. For identity-heavy environments, an identity security programme is often the only way to make that ownership explicit across teams.
Where the missing evidence involves service accounts, API keys, tokens, or workload identities, the ownership question extends beyond human users. The team running those identities must know how they are created, rotated, scoped, and traced. NHI lifecycle discipline is what turns a vague “we cannot find the evidence” complaint into a solvable control problem, especially when records need to support investigation of machine-to-machine access. The NHI Lifecycle Management Guide is useful here because it ties ownership to provisioning, rotation, offboarding, and visibility.
What good accountability looks like during an incident
Good accountability is observable. The organisation can name the control owner, explain which logs are authoritative, show how long evidence is retained, and demonstrate which team can retrieve it under pressure. If those answers are unclear, the incident becomes slower to contain and harder to defend to auditors, regulators, or customers.
The most useful operating model is usually a shared one: access governance owns entitlement evidence, logging or platform teams own collection and retention, and incident response owns the request and interpretation of evidence. That division works only if there is one agreed source of truth for identity events and a tested path to get the records quickly. In broader identity operations, regulatory and audit perspectives on NHIs help frame why evidence, ownership, and traceability need to be demonstrable, not assumed.
For incidents that touch logs, tokens, or privileged access, the team answering “who is accountable?” should also be able to answer “who can prove it?” If the answer requires multiple handoffs, the evidence model is too fragile for serious incidents. That is where identity threat detection and response practice becomes relevant, because it assumes the evidence path must support fast reconstruction of identity-based activity. Identity Threat Detection and Response is a good reference point for the kinds of logs and signals that matter most.
Risk and Threat Considerations
Missing identity evidence increases both response risk and accountability risk. If the organisation cannot show who accessed what, it may fail to prove scope, detect lateral movement, or meet reporting and audit obligations. In critical environments, that is not a documentation issue, it is a control failure that can widen operational impact.
Failure mechanism: Identity events are not retained, correlated, or owned clearly enough to reconstruct access after compromise. Gaps in logging, short retention, inconsistent account ownership, or unmanaged machine credentials can leave the incident team with no reliable evidence chain.
Impact: The organisation may be unable to substantiate timelines, confirm blast radius, support regulators, or assign responsibility cleanly. That weakens containment decisions, slows recovery, and can turn an incident into a governance and assurance problem as well as a security one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Incident accountability depends on reviewing and correlating logs during an investigation. |
| AU-11 — Audit Record Retention | Missing evidence is often a retention failure that prevents later investigation and reporting. | |
| IA-5 — Authenticator Management | Evidence gaps often involve missing visibility into credentials, tokens, and their lifecycle. | |
| Recommendation — Ensure identity events are reviewed and correlated quickly enough to support incident reconstruction. Retain identity and access logs long enough to support incident response and accountability. Manage authenticators so access evidence remains traceable across issuance, rotation, and revocation. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The question is about organisational accountability for evidence gaps affecting incident handling. |
| DE.CM-01 — Networks and network services are monitored to find anomalous events | Incident accountability depends on monitored and retrievable activity evidence. | |
| Recommendation — Assign ownership for identity evidence as part of enterprise risk management. Monitor identity-relevant activity so investigators can reconstruct incident timelines. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The core issue is whether logs exist, are retained, and are usable during an incident. |
| CIS-5 — Account Management | Accountability depends on knowing who owns accounts and access paths during an incident. | |
| Recommendation — Centralize and retain audit logs so identity evidence is available during incidents. Maintain accountable ownership for accounts and access paths that may be involved in incidents. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access governance ownership is central when evidence of identity actions is missing. |
| A.8.15 — Logging | The incident hinges on whether identity-related actions were logged and retrievable. | |
| Recommendation — Define and enforce access ownership so identity evidence can be produced on demand. Configure logging so identity evidence is preserved for investigation and reporting. | ||
| SOC 2 (AICPA) | CC7.2 — Communications of Internal Control Deficiencies | Missing identity evidence is a control deficiency that must be communicated and remediated. |
| Recommendation — Escalate identity evidence gaps as control deficiencies and track remediation to closure. | ||
Practitioner Guidance
What to verify: Confirm who owns entitlement records, who owns log retention, and who can produce evidence within the incident SLA. If those responsibilities sit in different teams, the handoff must be tested before an incident, not negotiated during one.
What good looks like: You should be able to trace a critical identity from provisioning to revocation, identify the log source that proves each access event, and name the accountable owner for each step. If you cannot do that for privileged or machine identities, treat the gap as a control defect, not an investigation inconvenience.
Practitioner takeaway: In a serious incident, accountability follows control ownership, but the organisation remains responsible for making identity evidence available quickly enough to prove what happened.
Related resources from NHI Mgmt Group
- Who is accountable when authorization evidence is missing during an incident?
- Who is accountable when identity resilience evidence is missing during a federal review?
- What breaks when identity evidence is missing during a NIS2 incident?
- Who is accountable when a government identity control fails during an incident?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org