Gartner predicts that by 2028, 90% of enterprise software engineers will use AI code assistants, up from less than 14% in early 2024. SOC 2 and ISO 27001 change management controls were written before that shift, and both rest on an assumption that AI-generated code breaks outright: the person who approved a change wrote it, or at least fully understood it.
Neither the AICPA nor ISO has published AI-specific change management requirements, so auditors apply the existing controls, SOC 2 CC8.1 and ISO 27001 Annex A 8.32, to commits no human authored. Most teams discover the mismatch mid-audit, when a sample pulls up a 2,000-line agent-generated pull request that was approved in four minutes. This guide maps AI code generation to both frameworks: what each one requires, the risks AI coding assistants introduce, the workflow that satisfies auditors, and the evidence they request when GitHub Copilot, Cursor, or Claude Code shows up in your SDLC.
Why AI-Generated Code Breaks Traditional Change Management
Change management controls assume a human bottleneck. AI removes it in three places at once.
The Volume Problem: AI Commits at Machine Speed
A single developer running an agentic coding tool can open more pull requests in a day than a small team used to produce in a sprint. Controls designed around weekly release trains and change tickets now face dozens of daily changes, and every one of them is technically in scope for CC8.1 and A.8.32. The control does not scale by adding reviewers. It scales by automating the parts of change management that never needed human judgment, and reserving humans for the parts that do.
The Attribution Problem: Who “Authored” the Change?
Git records the committer, not the author in any meaningful sense. When an engineer prompts an assistant and accepts a 400-line diff, the commit metadata says a human wrote it. When an autonomous agent opens a pull request from a service account, the metadata says a bot wrote it, with no record of which model, which version, or which prompt produced the change. Code provenance, the ability to trace a change back to its true origin, is shifting from an advanced practice to a baseline audit expectation, and most repositories cannot answer the question today.
The Review Problem: Human Approval in an AI-Driven Pipeline
Approval only means something if the approver engaged with the change. AI output arrives faster than humans can read it, and review depth degrades accordingly. The control on paper says reviewed and approved. The control in operation is often a reflexive click on a diff nobody read end to end.
Insider Note: Approval timestamps give this away immediately. When an auditor samples pull requests and finds a 1,500-line AI-generated diff approved three minutes after it was opened, with no reviewer comments and no requested changes, they treat the review control as not operating, regardless of what the policy document says.
What SOC 2 CC8.1 Requires for Change Management
CC8.1 is the change management criterion in the AICPA’s Trust Services Criteria. The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures. Auditors translate that language into four practical expectations, and none of them carves out an exception for AI.
Documented Change Request and Authorization
Every production change traces back to an authorized request: a ticket, an issue, or an approved pull request tied to a business reason. A prompt typed into a coding assistant is not a change request. The output of that prompt still needs to land inside your normal authorization flow.
Segregation of Duties Between Developer and Approver
The party that writes a change cannot be the only party that approves it. Translated to AI-assisted development: the model that generated the code cannot also be the control that approves it, and the engineer who prompted the agent counts as the developer for segregation purposes.
Testing and Rollback Procedures
Auditors expect evidence that changes were tested before deployment and can be reverted when they fail. AI complicates this in one specific way: when the same model writes both the implementation and its tests, the tests reflect the model’s reading of the requirement, not an independent verification of it. A human still needs to own test coverage intent.
Evidence of Operating Effectiveness Over Time
A SOC 2 Type II report tests whether controls operated across the entire review period, typically 3 to 12 months. One quarter of enforced branch protection does not cover a 12-month window. If you adopted agentic coding mid-period without updating controls, expect the auditor to test both regimes and flag the uncontrolled months. That timing problem is why this work belongs before the audit window opens, not during it.
What ISO 27001 Requires for Change Management
ISO/IEC 27001:2022 handles change management through three Annex A controls that interlock, plus clause 6.3 of the management system itself, which governs planned changes to the ISMS. Adopting an AI coding tool touches all of them.
Annex A 8.32 (Change Management) Explained
A.8.32 requires that changes to information processing facilities and information systems follow change management procedures. The accompanying ISO 27002 guidance expects changes to be planned, risk-assessed, tested, approved by an authorized party, logged, and reversible through a documented fallback. Two things matter for AI-assisted teams. First, the control covers the development pipeline itself, so the configuration of your AI tooling, agent permissions, and CI/CD gates is in scope, not just application code. Second, certification bodies audit against the 2022 revision, so documentation written for the 2013 version will not hold up.
Annex A 8.28 (Secure Coding) and AI-Assisted Development
A.8.28 is new in the 2022 revision and requires secure coding principles applied before, during, and after development, including for externally sourced components. AI-generated code is, functionally, externally sourced code of unknown provenance: trained on public repositories, reproduced probabilistically, and capable of importing insecure patterns or unvetted dependencies. Your secure coding standard needs to say explicitly how AI output is vetted, which usually means mandatory static analysis, software composition analysis, and license checks before merge.
Annex A 5.37 Documented Operating Procedures
A.5.37 requires operating procedures to be documented and available to the people who need them. If AI tools are part of how your team builds software, and your procedures do not mention them, the auditor reads that as a documentation gap at best and an unmanaged process at worst. The fix is cheap: write down which tools are sanctioned, how their output is reviewed, and who owns the configuration.
Mapping AI Code Generation to SOC 2 and ISO 27001 Change Controls
The two frameworks ask overlapping questions in different dialects. Design the controls once and both audits draw from the same evidence pool.
Shared Evidence You Can Reuse Across Both Audits
Branch protection configurations, pull request approval logs, CI/CD pipeline results, linked change tickets, and your updated development policies serve both frameworks without duplication. This is one of the few places where running SOC 2 and ISO 27001 together costs less than the sum of the parts, because AI change controls are tooling-enforced and generate their own evidence continuously.
Framework-Specific Gaps When AI Tools Are in Scope
SOC 2 is an attestation, so the auditor exercises judgment on whether your controls address the risks your system description discloses, including AI tooling. ISO 27001 is a management system, so the exposure is structural: your risk assessment and Statement of Applicability must reflect AI tools, and an SoA that predates their adoption is a finding waiting to be written. Neither framework certifies AI governance itself. That is the job of ISO 42001 certification, which governs how AI is developed and used across the organization.
Important: Your AI coding tool’s own SOC 2 report covers the vendor’s controls, not yours. It says nothing about how your team reviews, approves, and deploys the code the tool generates. Attaching Copilot’s attestation to your evidence folder does not close a single change management requirement on your side.
Worth Knowing: ISO/IEC 42001 Management System
ISO/IEC 42001 is the management system standard built for AI governance. Companies using AI heavily in development increasingly pair it with ISO 27001, since the two share the same Annex SL structure and much of the same evidence base.
Change Management Risks Introduced by AI Coding Assistants
Unreviewed Autonomous Agent Commits
Agentic tools can commit directly, open pull requests, and, in some configurations, merge on a green pipeline with no human in the loop. Each of those is a production change with no approver, which is an exception under CC8.1 and a nonconformity under A.8.32. The risk compounds in repositories where administrators can bypass branch protection, because the agent often runs under an account with elevated rights.
AI-Suggested Dependency Changes and Supply Chain Drift
Assistants add and bump packages casually, and they occasionally hallucinate package names that attackers have learned to register in advance. Every AI-suggested dependency is a supply chain decision that nobody consciously made. Without software composition analysis in the pipeline, your Software Bill of Materials drifts away from what was ever reviewed, and the drift only surfaces when a vulnerability scan or an auditor finds it.
Prompt-Driven Infrastructure-as-Code Changes
A prompt that rewrites Terraform or Kubernetes manifests can open a security group, widen an IAM role, or disable logging, and the blast radius exceeds anything in application code. Infrastructure changes sit squarely inside both frameworks’ definition of a change to information processing facilities. Treat AI-touched IaC as the highest-risk change class in the repository, with the strictest review requirements rather than the loosest.
Shadow AI Pull Requests from Personal Accounts
Engineers who hit the limits of sanctioned tooling route around it with personal subscriptions, and the resulting code enters your repository with no record that an AI tool was involved at all. That breaks your tool inventory, your attribution scheme, and potentially your confidentiality commitments, since proprietary code pasted into a consumer AI tool may leave your control entirely. Shadow AI is the risk auditors are least equipped to detect and the one most likely to surface through an incident instead of an audit.
Building a Compliant Change Management Workflow for AI-Generated Code
None of this requires a change advisory board meeting for every commit. It requires making five things systematic, all of them enforceable in GitHub, GitLab, or Bitbucket configuration rather than in policy prose. The structure aligns with the NIST Secure Software Development Framework, which auditors on both sides recognize as good practice.
Tagging and Labeling AI-Authored Commits
Attribution has to be machine-readable or it does not exist at audit time. Use commit trailers (a Co-authored-by line naming the tool), pull request labels applied automatically by the tool’s integration, or both. The goal is a repository where “show me every AI-assisted change in Q2” is a query, not an archaeology project.
Pro Tip: Marker Standards
Standardize one marker now and enforce it in CI, for example a required "ai-assisted" label whenever a known agent account or tool integration touches the branch. When the auditor requests their sample, you pull the full AI-assisted population in seconds, and you control the narrative instead of reconstructing attribution by hand under deadline.
Mandatory Human-in-the-Loop Pull Request Review
Require at least one human approval on every pull request, with CODEOWNERS routing sensitive paths (auth, crypto, IaC, payment logic) to named senior reviewers. Pair the rule with a practical constraint: cap pull request size. A reviewer can be accountable for a 300-line AI-generated diff; nobody is accountable for a 3,000-line one, and auditors know it.
Branch Protection Rules That Treat AI Commits as Untrusted
Block direct pushes to protected branches, prohibit self-approval, dismiss stale approvals on new commits, and apply the rules to administrators. Run agents under dedicated service accounts that can open pull requests but hold no merge rights. This single configuration choice converts “the agent deployed to production” from a possible incident into an impossibility, which is exactly the kind of design auditors reward.
Automated Policy Checks in CI/CD for AI-Generated Code
Make SAST, software composition analysis, secret scanning, and license checks required status checks that gate merge. Automated gates do double duty: they catch the classes of defect AI most commonly introduces, and they generate timestamped evidence of operation on every single change, which is the cheapest Type II evidence you will ever produce.
Linking Tickets, Commits, and Approvals for Audit Traceability
Enforce ticket references in branch names or pull request titles, so every deploy traces backward: production release to merged PR, PR to approval, approval to ticket, ticket to business justification. Auditors walk this chain in reverse from a deployment sample, and a broken link anywhere in the chain becomes an exception in the report.
Evidence Auditors Will Request for AI Code Changes
Auditors test change management by sampling, so one unexplained pull request in the sample can become an exception in the report. For AI-assisted development, expect requests for the following.
- Pull request approval logs with AI attribution. The approval record for sampled changes, plus whatever marker identifies the change as AI-assisted. If attribution does not exist, the auditor cannot distinguish AI changes from human ones, and neither can you.
- Code review checklists covering AI-specific risks. Evidence that reviewers are instructed to check AI output for hallucinated dependencies, insecure defaults, and license contamination, not just logic errors.
- Change Advisory Board minutes referencing AI tools. Where a CAB or equivalent forum exists, minutes showing the adoption and configuration of AI coding tools went through it. The tool’s rollout was itself a significant change.
- Automated test results and security scan outputs. CI logs for sampled changes showing required checks ran and passed before merge, with the configuration proving the checks were mandatory rather than advisory.
- Rollback and incident records tied to AI-generated changes. Where an AI-assisted change caused an incident, the incident record, the rollback evidence, and any corrective action. Auditors read a well-documented failure as a working control, not a weakness.
The pattern across all five: tooling-generated evidence beats manually assembled evidence every time, because it is complete, timestamped, and impossible to backfill.
Policy Updates Required to Cover AI-Generated Code
Policy updates take a day or two. Evidence that the policies operate takes a full audit period, which is the strongest argument for doing this before your observation window opens rather than during it.
Updating Your Change Management Policy
Define what counts as an AI-generated or AI-assisted change, name the approval path it follows (the same one as human changes, with human approval mandatory), and state how agent service accounts are provisioned and restricted. One paragraph each is enough; auditors want clarity, not volume.
Updating Your Secure Development Policy
Classify AI output as untrusted input to the SDLC. Require static analysis, composition analysis, and human review before merge, and reference your pull request size limits and CODEOWNERS routing so the policy matches the tooling configuration an auditor will inspect.
Updating Your Acceptable Use Policy for AI Tools
List sanctioned tools and approved account types, prohibit personal AI accounts for company code, and state what data classes may never enter a prompt. This is the policy that addresses shadow AI, and it only works if the sanctioned tools are good enough that engineers stop wanting the unsanctioned ones.
Vendor Risk Language for AI Coding Assistants
Add AI coding tools to your vendor risk process under CC9.2 and Annex A 5.19 to 5.22. Assess where prompts and code travel, whether the vendor trains on your data, what attestation the vendor holds, and how you would off-board the tool. The assessment itself becomes audit evidence that you treated the tool as the supplier it is.
Common Audit Findings When AI Code Lacks Change Controls
Four findings repeat across audits of AI-assisted teams, and all four are preventable with configuration rather than heroics.
- Missing approver on agent-generated pull requests. An agent merged, or a human rubber-stamped a merge the agent initiated, and the record shows no meaningful review. This is the most common exception and the easiest to prevent with branch protection.
- Insufficient testing of AI-suggested changes. Sampled changes shipped with failing, skipped, or absent checks, or with AI-written tests that no human validated against the requirement. Auditors increasingly ask who verified coverage, not just whether tests passed.
- No inventory of AI tools used in the SDLC. The auditor asks which AI tools touch the codebase and gets three different answers from three engineers. An unmanaged tool population undermines every other control, because scope cannot be assessed for tools nobody listed.
- Weak segregation of duties in agentic workflows. The same engineer prompts the agent, approves its output, and deploys it, or the agent account holds merge rights. Either way, one party controls the entire change path, which both frameworks exist to prevent.
Each of these is visible in a half-day repository review long before an auditor arrives, which is precisely what a pre-certification internal audit is for.
Implementation Checklist: Change Management for AI-Generated Code
Pre-audit readiness checks
- Inventory every AI tool with repository access, including IDE plugins and agent accounts
- Confirm your risk assessment and (for ISO 27001) Statement of Applicability reference AI tooling
- Sample 10 recent AI-assisted pull requests and walk the ticket-to-deploy chain yourself
Tooling configuration (GitHub, GitLab, Bitbucket)
- Branch protection on all production branches, applied to administrators
- Required human approval, no self-approval, stale approvals dismissed on new commits
- Agent service accounts with pull request rights only, no merge rights
- SAST, SCA, secret scanning, and license checks as required status checks
- AI attribution enforced via commit trailers or automatic labels
Documentation and policy artifacts
- Change management, secure development, and acceptable use policies updated for AI
- Vendor risk assessments completed for each AI coding tool
- Operating procedures document sanctioned tools and review requirements
Continuous monitoring controls
- Alerts on direct pushes, protection bypasses, and agent account anomalies
- Periodic review of AI-assisted change volume against review throughput
- Quarterly re-check of the AI tool inventory against actual repository activity
AI-generated code does not break SOC 2 or ISO 27001. It breaks the informal version of change management many teams passed audits with: trust the reviewer, trust the pipeline, keep the evidence light. Both frameworks already contain everything needed to govern AI-assisted development; the work is enforcing attribution and human review in tooling, updating four policies, and letting the pipeline generate its own evidence.
Teams that do this before the observation window opens experience it as a few weeks of configuration and policy work. Teams that wait usually meet it as a finding, whether on a first SOC 2 report or an ISO 27001 certification audit.
Frequently Asked Questions
Do AI-generated commits need the same approval workflow as human commits under SOC 2?
Yes. CC8.1 governs changes, not authors, so an AI-generated change needs the same documented authorization, testing, and approval as a human one. The practical difference is that the human approval requirement becomes stricter, because the AI cannot be a party to its own approval.
Can an AI coding assistant act as an "approver" in a change management workflow?
Not as the only one. AI review tools are useful as an additional automated check, and auditors generally welcome them in that role. But an approval chain where no human is accountable for the change fails segregation of duties under both frameworks, and no major certification body or CPA firm currently accepts AI-only approval for production changes.
Do we need to re-scope our SOC 2 audit when we adopt an AI coding tool?
Usually you do not need a formal re-scope, but you do need to update your system description to disclose the tool, add it to your vendor list, and show the auditor how existing change controls cover its output. Tell your auditor before the audit, not during it; surprises in fieldwork read as unmanaged change.
Does Copilot, Cursor, or Claude Code need its own vendor risk assessment under CC9.2?
Yes. Any tool that reads your source code and injects code into your products is a material supplier. Assess data handling, retention, whether your code trains the vendor’s models, the vendor’s own attestations, and your exit path, the same as you would for any subprocessor with production access.
What happens if auditors find untracked AI-generated changes in production?
Under SOC 2 it becomes a testing exception, which can qualify the opinion if pervasive; under ISO 27001 it becomes a nonconformity requiring corrective action before or after certification, depending on severity. The remediation is the same either way: establish attribution, close the approval gap in tooling, and document the corrective action, because a well-handled finding damages you far less than a disputed one.
