The question comes up as soon as a first enterprise deal reaches security review: does using AI to write our code create a compliance problem?
Short answer: no, not by itself. Longer answer: it changes what you have to be able to show, and the thing that trips teams up is almost never the AI. It is that the review step is inconsistent, and inconsistency is exactly what an auditor is trained to find.
What SOC 2 actually requires
SOC 2 is not a checklist of technologies. It is an attestation that you defined controls appropriate to the Trust Services Criteria and then operated them consistently over a period. Nothing in it mentions code generation tools, and nothing needs to.
The relevant criteria are the change-management ones: changes to production systems are authorised, reviewed, and tested before deployment. The control is agnostic about the author. Whether a line was typed by a senior engineer or generated by a model, the same question applies: what evidence exists that it was reviewed before it shipped?
The four questions to prepare for
1. How do you review code before it reaches production?
They want the mechanism, not the intention. Which step runs, what it checks, where it sits in the pipeline, and what happens when it fails. "Engineers review each other's pull requests" is an answer; it is just a weak one unless you can show it happened every time.
2. Can you produce the record for a specific change?
This is the question that decides the outcome. An auditor will select a sample of changes from your period and ask for the review evidence for each. If the review lives in a tool that stores a result per submission, this is a lookup. If it lived in a conversation, you have a problem, and it is not a problem you can fix retroactively, because the period has already closed.
3. What is your threshold for blocking a deployment?
Severity grading matters here for a reason that is not obvious. A documented rule (CRITICAL and HIGH findings block release, MEDIUM and LOW are tracked and scheduled) converts a judgement call into a control with a testable pass condition. Without a threshold, every release decision is discretionary, and discretion cannot be evidenced.
4. Where does your code go during review?
Your review tool is a sub-processor. If it stores your source code, that storage sits inside your compliance boundary and inherits your obligations: it appears in your vendor assessment, your data-flow documentation, and your breach analysis if that vendor is compromised.
A tool that never persists code shortens that conversation considerably, because there is no stored data to assess. The reasoning is set out in full in zero code retention.
How this maps to other frameworks
| Framework | Relevant requirement | What satisfies it |
|---|---|---|
| SOC 2 | Change management: review before deployment | Consistent review with a retrievable record per change |
| ISO 27001 | A.8.25 / A.8.28: secure development and coding | Documented secure-development process, evidenced as operating |
| GDPR / DPDP | Security of processing; breach notification | Demonstrable measures, plus a defensible position on sub-processors |
| PCI-DSS | Requirement 6: secure systems and software | Review covering the OWASP-style vulnerability classes before release |
The shared shape is worth noticing: every framework asks for a process that runs consistently and leaves a record. None asks who wrote the code.
Making this operational without a compliance team
- Put review in the pipeline rather than in a habit. A step in CI runs on every change by construction; a norm runs on every change until a deadline.
- Store the result per change, with a timestamp and an identifier you can search during fieldwork.
- Write the blocking threshold down and apply it without exception, so the control is testable.
- Record your business rules alongside the code they govern. The same context that lets a reviewer catch logic errors also documents intent for an auditor.
- Confirm in writing whether your review vendor retains code, and keep the answer with your vendor assessments.
None of this requires a compliance function. It requires the review step to be automatic rather than remembered, which is the same property that makes it useful in the first place. The API and CI/CD integration docs cover wiring it into a pipeline so the record is produced without anyone deciding to produce it.