Compliance · ISO/IEC 27001:2022
Does AI code review satisfy ISO 27001 segregation of duties?
No. Annex A.5.3 asks that conflicting duties be segregated, and writing a change and approving it for release are conflicting duties. An AI reviewer does not create a second accountable person. With PSCO the developer and the approver are different people in different organizations, recorded on every change, and A.8.32, A.8.25 and A.8.28 are addressed by the Security & Compliance Model that encodes your secure-coding rules and required gates.
The mapping rows
| Framework | Control | What it asks | How PSCO satisfies it |
|---|---|---|---|
| ISO/IEC 27001:2022 | A.5.3 Segregation of duties | Conflicting duties are segregated | Developer and approver are different people in different organizations, recorded on every change |
| ISO/IEC 27001:2022 | A.8.32 Change management; A.8.25 Secure development life cycle; A.8.28 Secure coding | Changes follow a controlled process; secure coding principles are applied | The model encodes the secure-coding rules and required gates; every change is checked against them before release |
Suggested control wording
Name the approver. Name the standard.
Paste this into your control description. The first sentence is the control; the second names the reviewer and the standard they review against, which is what an auditor needs to accept an outside approver.
All changes to production code require approval from a qualified reviewer who is not the author. Reviewers are PSCO Officers, background-checked US-based engineers contracted by the company, who review each change against the company’s Security & Compliance Model before approval.
The Security & Compliance Model is a versioned, customer-approved document; each version change is itself a controlled change, which gives the certification body a clean trail for A.8.32.
What a ISO 27001 auditor samples
Build the record so it is already there.
Auditors test change management by sampling. These are the facts they look for on each sampled change, and where PSCO puts them.
- 01Evidence that developer and approver are distinct for a sample of changes (A.5.3).
- 02The documented change process and evidence it was followed, including required checks (A.8.32).
- 03Secure-coding rules and evidence they were applied before release (A.8.25, A.8.28).
- 04The model version in force at each decision, which the attestation records.
Auditor Guide
Hand your auditor the design once. Then they recommend it.
Before public launch PSCO briefed audit firms that together cover most startup and mid-market SOC 2 reports on the control design, the Officer Dossier and the Evidence Pack. The Auditor Guide is their questions, answered, for your auditor to read before the first sample.
The control design, the Officer Dossier and the Evidence Pack, written for your auditor.
A short PDF that answers the questions audit firms asked when we briefed them: who the approver is, how they are qualified, what the attestation records, and how to sample it. Enter a work email and we send the guide.
See your exact price before you talk to anyone.
Connect GitHub, pick the repos in scope, and get a quote from your real PR history in two minutes.