Who is accountable for infrastructure change records when an auditor asks for SOC 2 proof?

Why This Matters for Security Teams

When an auditor asks for SOC 2 proof, the real question is not whether a change happened, but whether the organisation can prove who approved it, who executed it, and what evidence ties the outcome back to policy. That accountability belongs to the cloud operator, because SOC 2 evaluates operating controls, not vendor promises or auditor recollections. This is why Ultimate Guide to NHIs — Regulatory and Audit Perspectives matters: it frames audits as evidence problems, not documentation exercises.

Security teams often get this wrong by treating change records as a ticketing artifact instead of a control record. The evidence needs to show governance over infrastructure identity, deployment authority, and post-change verification. NIST expects this kind of accountability through control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, while the operational picture in the Ultimate Guide to NHIs shows how often identity evidence is fragmented across tools. In practice, many security teams discover that their change history is incomplete only after the auditor has already asked for proof, rather than through intentional control testing.

How It Works in Practice

In practice, the accountable organisation should define a single chain of custody for infrastructure change records. That means the platform or infrastructure owner is responsible for approving the change, the deployment system or change pipeline records execution, and the security function verifies that the record is complete and retained. The record should answer five questions: what changed, who requested it, who approved it, what identity executed it, and what evidence shows the outcome matched the intended configuration.

For SOC 2, this usually means combining ticket metadata, pull request history, CI/CD logs, cloud control plane events, and post-deployment attestations. The control is strongest when the change record is bound to workload identity rather than a shared human credential. That aligns with the broader NHI lifecycle approach described in the NHI Lifecycle Management Guide. For identity and access governance, current guidance from the NIST Cybersecurity Framework 2.0 and NIST control practices supports traceability, least privilege, and accountability across the full change lifecycle.

• Use named approvers and deployment owners, not generic team queues.
• Record the exact infrastructure identity used to make the change.
• Retain immutable logs that connect the approval to the executed action.
• Show post-change validation, such as drift checks or monitoring evidence.

For auditors, the strongest proof is a reproducible trail that survives personnel turnover and tool changes. These controls tend to break down in highly automated environments where ephemeral pipelines, autoscaling infrastructure, and shared break-glass access make it hard to map a change back to one accountable owner.

Common Variations and Edge Cases

Tighter change control often increases operational overhead, requiring organisations to balance auditability against delivery speed. That tradeoff becomes sharper in environments with frequent ephemeral infrastructure, where records can disappear as quickly as the resources themselves. Current guidance suggests the answer is not to slow everything down, but to make evidence collection automatic and identity-bound.

There is no universal standard for this yet, but most mature programmes separate emergency change handling from normal change flow, and both require later review. In a break-glass event, the record should clearly show why the override was necessary, which identity used it, and when access was revoked. In multi-team environments, platform engineering may own the control design while security owns oversight, but the operating cloud organisation still carries accountability for the evidence. The Top 10 NHI Issues research is a useful reminder that excessive privilege and weak lifecycle discipline usually surface first as audit gaps, not as clean policy violations.

For teams managing shared clusters or managed services, the best practice is evolving toward machine-readable change attestations and continuous control monitoring. That approach reduces dependence on screenshots, manual exports, and after-the-fact reconstruction. When infrastructure is controlled by multiple vendors or service teams, the evidence model often breaks down because no single party owns the full chain of approvals, execution, and verification.

Related resources from NHI Mgmt Group

• Who is accountable when a non compliant infrastructure change reaches production?
• Who should be accountable when service desk workflows change access, asset status, or identity governance records?
• Who is accountable for maintaining SOC 2 evidence when cloud infrastructure changes frequently?
• Who should be accountable for keeping penetration tests aligned with application change?