Your change-management evidence assumes a human. Claude does not sign commits.

An essay published on dev.to argues that ISO 27001, SOC 2 and NIST SP 800-53 rest on an assumption chain that no longer holds: a human made the decision, that human was authenticated and authorised to make it, the decision was documented in a ticket or comment or change record, and if something broke you could trace back to who decided what ^[1][2]. The reason this is a deadline and not a debate is that certification certifies a snapshot as of a date ^[12], and the artefact an auditor will ask for may already have been destroyed by the time they ask.

The author's version of the honest answer many teams would now give an auditor working through change management: "We described the problem to Claude, it suggested this implementation, we thought it looked right, and we merged it" ^[3]. According to the piece, that answer is not covered anywhere in ISO 27001, barely appears in SOC 2, and NIST is only now beginning to grapple with it, with the gap widening weekly against how teams actually work in 2026 ^[4][15].

At control level the problem is specific rather than philosophical. SOC 2 CC6.6 requires that changes to infrastructure and software are authorised, tested and documented before deployment, and most interpretations assume a human reviewer in the loop who exercised judgment ^[5][6]. The piece notes that "a developer approved the PR" remains technically true even when the review consisted of reading an AI-generated summary of the AI's own change, which leaves the question of what judgment was exercised and by whom ^[7]. The auditor's phrasing it anticipates is mundane: walk me through how this change was reviewed before it was approved ^[8].

The logging side is worse because it is not a matter of interpretation. NIST SP 800-53 AU-2 through AU-12 cover audit and accountability, including which events are logged, how records are retained, and how they can be reconstructed for investigation ^[9] - eleven numbered controls ^[1]. By default, the piece says, none of your AI coding sessions are covered by any of it, and they leave no audit record whatsoever despite producing real changes to production systems ^[10]. Commits are logged, database queries traced, API calls metered; the CI/CD pipeline has more observability than the sessions increasingly driving what goes through it ^[11]. AI coding tools are not authenticated, do not sign commits, and have no name in the issue tracker, and the conversation behind an architectural decision may exist for exactly as long as the browser tab stays open ^[13].

The data-handling exposure runs on the same missing log. GDPR Article 30 requires records of processing activities and ISO 27001 Annex A.15 covers supplier relationships ^[14], while in practice developers paste production schemas, error logs carrying user context and architecture details into prompts; some organisations forbid it, most do not, and enforcement is near zero because nothing records what was shared or when [c15b].

The operational consequence is retention, not policy. Session transcripts, prompt logs and a reviewer attestation that names what a human actually checked are cheap to start capturing today and impossible to backfill for a period that has already closed ^[13][10]. The author's view is that auditors are increasingly unable to assess whether existing controls account for the daily AI sessions in an engineering org ^[16], which means the finding, when it lands, will be about missing evidence rather than a bad decision.