ISO/IEC 27001 and SOC 2 audits: the change-management evidence auditors sample — and how to have it ready

Last reviewed 2026-08-21 · 8 min read

ISO/IEC 27001 certification audits and SOC 2 attestations test whether your change-management, review and release controls actually operate — by sampling changes across the period. A contemporaneous record of authorship, approval and test linkage per change is the evidence auditors pull; a policy document only says what should happen.

What it is

Two audit regimes dominate how software companies demonstrate security and operational discipline to customers. ISO/IEC 27001 is an international standard for an information security management system (ISMS): an organisation defines its risk treatment, selects controls — ISO/IEC 27002 is the catalogue most of them come from — and an accredited certification body audits that the system exists and operates, initially and then on a surveillance and recertification cycle. SOC 2 is an attestation framework from the AICPA: an independent service auditor examines a service organisation’s controls against the Trust Services Criteria (security always; availability, processing integrity, confidentiality and privacy optionally) and issues a report — Type I on design at a point in time, Type II on operating effectiveness over a period, typically six to twelve months.

They differ in form — a certificate versus a report, a standard versus criteria — but from an engineering team’s chair they ask the same thing about software development: show us that your change-management, review and release controls operate as described, every period, for any change we pick. That sampling is the part teams underestimate. An auditor does not read your policy and nod. They choose changes from the period and ask for the evidence trail of each: who authored it, who approved it, what tests ran, how it reached production. Evidence that exists for the changes you remember is not evidence that the control operates.

Neither regime is a law. They matter because customers, procurement teams and insurers treat them as the default proof of discipline — and increasingly ask, inside them, how AI-assisted development is controlled.

Who it applies to and when

ISO/IEC 27001 applies to any organisation that chooses to certify its ISMS — SaaS vendors, agencies, enterprises — and, once it holds the certificate, to an annual surveillance cycle with recertification every three years. SOC 2 applies to service organisations whose customers want assurance over the services they rely on; the reporting period is chosen with the auditor and repeats, usually annually. There is no statutory start date — the clock is set by the customer who asks, the contract that requires it or the tender that scores it.

What has changed recently is not the standards but the questions asked under them. Auditors now routinely probe how AI coding tools are governed: whether agent-authored changes are identifiable, whether a human reviews them before release, whether the organisation can say what share of a release an agent wrote. Those questions land in the same change-management and secure-development controls that have always been sampled — the sample just has a new failure mode.

Neither ISO/IEC 27001 nor SOC 2 is part of our regulatory mapping: they are voluntary assurance frameworks, not EU acts. This guide therefore describes the documentation value of a recorded chain in the same vocabulary as our mapping — and says plainly where it stops.

What it asks of your development process

The controls an auditor will sample in a software organisation cluster around a few questions:

Change management. Is every change to production authorised, reviewed and tested before release? Can you show it per change, not per policy? In ISO/IEC 27002 this is the change-management control and the secure development lifecycle controls; in SOC 2 it is the change-management criteria under the common criteria.
Segregation of duties. Did someone other than the author approve the change? With AI agents in the loop this becomes: did a human approve what the agent wrote — and can the record tell the two apart?
Secure development. Is there a defined process — code review, testing, dependency handling — and does the evidence show it running?
Release and deployment. Can you tie a production release to the set of changes it contained and the checks those changes passed?
Integrity of the evidence itself. Can the auditor rely on the records, or could they have been edited after the fact? Ticketing systems and spreadsheets are accepted every day, but an auditor will weigh a record they can independently verify more heavily than one they must take on trust.

What distinguishes a smooth audit from a painful one is rarely the existence of a process. It is whether the process leaves sampled-ready evidence as a by-product: contemporaneous (recorded when the change happened), attributable (author and approver named, human or agent), linked (change → review → tests → release) and tamper-evident. Teams without that assemble evidence packs in the audit week, from memory and from five tools, and discover the gaps under the auditor’s eye.

For AI-assisted teams the sharpest gap is attribution. “All changes are reviewed” is a policy statement; the sample needs to show, for an agent-authored change, the agent that wrote it and the person who approved it. Records that carry only a human committer name — because the agent worked in a human’s session — cannot show that, and an auditor probing AI governance will notice.

What OLOBOLO evidence supports

OLOBOLO records each change with its author (human or agent, with tool and model for agents), the review decision, the test evidence and the release it shipped in — in an append-only, hash-chained record with external RFC 3161 time anchors, exportable as a canonical file that an open-source verifier checks without trusting us. The table uses our mapping vocabulary; this is not a regulatory mapping — ISO/IEC 27001 and SOC 2 are assurance frameworks, and which controls a given sample satisfies is the auditor’s judgement.

Audit question	What you need to show	Chain evidence	Support
Change management — every production change authorised, reviewed, tested	Per-change trail: authorship, approval, test linkage, release	`change.authored` → `change.reviewed` → `test.evidenced` → `release.sealed`, exportable per repo and per period	Supports
Segregation of duties, incl. human review of agent output	Approver is not the author; agent-authored changes carry a human review	Actor type and identity on `change.authored`; reviewer identity and decision on `change.reviewed`	Supports
Secure development lifecycle operates	Evidence the defined process ran, release by release	Release evidence report (counts, coverage, AI share, review coverage) per sealed release	Partially supports
Evidence integrity	Records could not have been altered after the fact	Hash chain + RFC 3161 anchors; independent verification with the open-source verifier	Supports
ISMS scope, risk assessment, policies, access control, incident management, availability	Organisational and operational controls	—	Out of scope

“Partially supports” on the lifecycle line is deliberate: the chain shows that reviews and tests happened and how much of a release they covered; it does not judge whether your process design meets the standard. And the last line is most of an ISMS or a SOC 2 report — the chain is one evidence source for a handful of controls, not a management system.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your auditor decides what the controls require.

How to start

Record before the period starts. A Type II period or a certification cycle is sampled end to end; evidence that begins in month four is a finding. Install the recorder on in-scope repositories and let the period open with the record already running.
Make approvals and tests explicit. Ensure every merge carries a human review that lands as change.reviewed, and that CI records test.evidenced — the two entries an auditor will ask for next to any sampled change.
Seal releases. Each release.sealed segment and its evidence report are the “what did release X contain and pass” answer, ready before the auditor asks.
Hand the auditor the export and the verifier. Let them inspect the canonical export for the period and run the verifier themselves; the less they must trust you, the smoother the sample.

Evidence can't be reconstructed after the fact — it has to be recorded while you build. Start recording now, free, and every change from this moment is on the record.

Start recording

Frequently asked questions

Does OLOBOLO itself hold an ISO 27001 certificate or a SOC 2 report?

OLOBOLO is a recorder of development evidence, not a certification body and not (as of this writing) a holder of either report. We publish our own security posture page and evidence chain; whether and when we pursue a report is a company decision we will document openly.

Which controls does development evidence actually touch?

Mostly change management, secure development and release controls — in ISO/IEC 27002 terms the controls around change management and secure development lifecycle; in SOC 2 terms the change-management and logical-access criteria under the common criteria. The auditor maps; the record supplies samples.

Does an auditor accept a hash-chained export as evidence?

Auditors accept evidence they can tie to the control and the period, inspect and, ideally, corroborate. An append-only, time-anchored export that an open-source verifier can check is designed for exactly that inspection; acceptance is always the auditor's professional judgement.

We use AI coding agents — does that change the audit?

The controls are the same, but the question 'who approved this change?' gets sharper: if an agent authored it, the sample must show a human review. Records that cannot distinguish agent from human authorship are where AI-assisted teams most often fail a sample.

Sources

Last reviewed 2026-08-21. Dates are cross-checked against our regulatory mapping and radar.

A necessary honesty: OLOBOLO is evidence, not a legal opinion. This guide describes what our chain supports as documentation — Supports / Partially supports / Out of scope — and your counsel decides what compliance requires. No tool can promise the latter.