ISO 27001, SOC 2, and NIST assume humans made decisions and left a paper trail. That assumption is breaking.
Imagine an auditor sitting across from your engineering team. They're working through your change management controls. They want to know: who approved this code change? What was the review process? Is there evidence that a qualified person made a deliberate decision?
Six months ago, the answer was straightforward: here's the pull request, here's the review, here are the approvals.
Today, the honest answer for many teams is: "We described the problem to Claude, it suggested this implementation, we thought it looked right, and we merged it."
That answer is not covered anywhere in ISO 27001. It barely appears in SOC 2. NIST is only now beginning to grapple with it. And the gap between those frameworks and how engineering teams actually work in 2026 is widening every week.
What compliance frameworks actually assume
ISO 27001, SOC 2 Type II, and NIST SP 800-53 were designed with a set of assumptions that seemed self-evident at the time:
- A human made a decision.
- That human was authenticated and authorized to make it.
- The decision was documented — a ticket, a comment, a change record, a signature.
- If something went wrong, you could trace back to who decided what.
These frameworks are not wrong. They describe exactly the kind of accountability that responsible engineering requires. The problem is not the principles — it's that they were operationalized around human workflows. Every control, every audit procedure, every evidence request assumes the actor was a person who left a recognizable trail.
AI coding tools are not authenticated. They don't sign commits. They don't have a name in your issue tracker. The conversation that produced a significant architectural decision might exist for exactly as long as the browser tab stays open.
When an organization gets ISO 27001 certified or completes a SOC 2 Type II audit, the auditors are certifying a snapshot: as of this date, these controls were in place. What they are increasingly unable to assess is whether those controls account for the AI sessions happening every day in the engineering org.
Three gaps that are already present
1. Change management evidence
SOC 2 CC6.6 requires that changes to infrastructure and software are authorized, tested, and documented before deployment. Most interpretations of this control assume a human reviewer in the loop who exercised judgment.
When an AI tool suggests and partially writes a change, the question becomes: what is the evidence of review? "A developer approved the PR" is technically true. But if that review consisted of reading an AI-generated summary of the AI's own change, is that the control your auditor is certifying? What judgment was actually exercised, and by whom?
The auditor question you'll face: "Can you walk me through how this change was reviewed before it was approved?" — and the honest answer involves an AI session that no longer exists.
2. Audit trails and session records
NIST SP 800-53 AU-2 through AU-12 cover audit and accountability: what events are logged, how records are retained, and how they can be reconstructed for investigation.
By default, none of your AI coding sessions are covered by any of this. The conversation where you asked your AI assistant to redesign the authentication flow, the session where you refactored database access patterns, the task that generated your API client library — these produced real changes to production systems, and they leave no audit record whatsoever.
Your git commits are logged. Your database queries are traced. Your API calls are metered. Your CI/CD pipeline has more observability than the AI sessions that increasingly drive what goes through it.
3. Data handling and third-party disclosure
GDPR Article 30 requires records of processing activities. ISO 27001 Annex A.15 covers supplier relationships and information security in them.
In practice, developers regularly paste production schemas, error logs with user context, and system architecture details into AI prompts to get better answers. Some organizations have explicit policies against this. Most do not. Even where policies exist, enforcement is near-zero because there is no log of what was shared and when.
If your organization is SOC 2 certified, your auditors have reviewed your data handling controls. The question is whether those controls — as written and as assessed — account for what your engineers are pasting into their AI sessions every day.
What organizations are doing — and what's missing
Prohibition. Some organizations have banned AI coding tools entirely, citing compliance risk. This is understandable and also losing ground. The productivity differential is real, and enforcement on personal devices is functionally impossible.
Policy without enforcement. More common: "Don't paste customer data into AI tools" lives in the acceptable use policy. There is no technical control, no session record, no way to verify. The policy exists; the assurance does not.
Output review. Some teams have added AI-specific code review steps. This is better than nothing. It partially addresses change management but doesn't touch data handling or audit trail requirements.
What's mostly absent: any systematic approach to capturing what AI tools did, what context they received, and what decisions they influenced. The record of AI involvement in engineering work is today almost entirely missing from compliance evidence packages.
What needs to change — at two speeds
The slow track: framework updates
ISO and NIST revision cycles are measured in years. The NIST AI Risk Management Framework is a meaningful step, but it is not yet integrated into how SP 800-53 controls are assessed in standard audits. Building your compliance strategy around waiting for it is not a viable approach.
The fast track: interim controls
Treat AI sessions as auditable activity. Decide — explicitly — whether AI coding sessions are in scope for your audit and accountability controls. If they are, log them. If they are not, document why not and what compensating controls exist.
Define AI involvement in your change management policy. What does adequate review of an AI-generated change look like? Does it differ from review of human-written code? Every team operating under SOC 2 or ISO 27001 needs a written answer before their next audit.
Update your data classification policy to cover AI context. Which data classifications may be used as prompt context? This belongs alongside your existing data handling controls — and should be technically enforced where possible.
Include AI providers in your vendor and subprocessor inventory. If your team uses an AI provider's API, that provider is a data processor under GDPR and potentially a subservice organization under SOC 2. Most compliance programs have not updated their vendor inventories to reflect this reality.
The question coming for every engineering org
Compliance frameworks will update. They always do, eventually. The organizations that will be best positioned are the ones that start treating AI tool usage as an auditable activity now, before they are formally required to.
The question an auditor will eventually ask is not complicated: "Show me what your AI tools did, what they had access to, and how you controlled it."
Most engineering teams cannot answer that today. Building the answer is not a compliance checkbox exercise — it is engineering discipline catching up to how the work actually happens.
The frameworks weren't wrong. They just couldn't see this coming. Neither could most of us.
If you found this useful, I'd be curious what your team's approach has been — especially if you've been through a SOC 2 or ISO audit recently. The practical experience is ahead of where the guidance is.
