The questions a framework makes an auditor ask

Nothing on this page is a conformity claim. The product is not certified and cannot make you compliant; the mapping below is ours to describe and the verdict is your auditor's.

What the page is for is narrower and more practical. Every framework reduces, in the room, to a handful of concrete questions somebody has to answer with an artefact. This page names those questions and says which artefact answers each one — and, where the honest answer is ask for it by name and expect to be shown something else, it says that instead.

Read it with tracing one change backward open, because most of these answers are one walk of that chain.

The reason this mapping is easier than it looks

The strongest mapping is not to anything new. An agent is an outsourced developer in the sense the norms already use — work you commission, from a party you must supervise, whose output you must verify before it ships. Adopting agents is a material change to a process your management system already covers, and it has to be reflected there or it gets written up.

That framing matters because it means the controls your auditor already knows how to check are the controls that apply. The requirement predates AI. What is new is only whether you can produce the evidence per change instead of reconstructing it for the audit.

ISO/IEC 27001 — change management

The question. Who changed what, on whose approval, and with what evidence?

Where the answer is. One walk of the chain, per change. The gate row carries the actor, the decision, the time and the evidence the decision rested on; the order carries the exact bytes of what was commissioned; the run record carries what actually executed; your own version control carries the merge. An approval without evidence attached is not representable, so the absence of evidence is not a thing you can find on an existing decision.

Ask for this by name. Whether the implementer, the reviewer and the approver of a given change were distinct people. The record gives you the actor names to establish it, and it is a property of your roster and your process rather than a claim this section makes on your behalf.

ISO/IEC 42001 — governed use of AI, with oversight you can demonstrate

The question. Is there human oversight of the AI, and can you show it rather than describe it?

Where the answer is. In the shape of the record itself. Advice and decision are separate recorded events, so what was recommended and what the human decided are two entries that cannot blur into one. An override of the advice is itself recorded. A refusal is durable data with its class and its reason. Oversight here is not a policy paragraph you point at — it is rows.

Ask for this by name. A period report of overrides. The overrides are recorded; a defined report over them is not documented in what this section holds.

SOC 2 — change management and processing integrity

The question. Does every change carry evidence and a recorded human decision, for every change in the period?

Where the answer is. The gate rows and the evidence attached to them, for the period. The engine cannot approve, cannot merge and cannot treat a timeout as consent, so there is no route by which a change advanced without a human act.

Ask for this by name — and expect to negotiate it. A rendered trail for the audit period, in a format your working papers accept. The record is complete enough to produce one and lives in a store you control, but this section does not document an export artefact or the command that produces it. Agree with your operator, before the audit rather than during it, exactly which query or surface produces your period evidence.

EU AI Act — record-keeping and human oversight

The question. Article 12 asks for records. Article 14 asks for human oversight.

Where the answer is. The same mechanism answers both, which is the point worth making to an auditor: the record is how the work happens rather than something kept about it, and oversight is an act by a named actor rather than a claim about culture. The engineers producing the records are not doing anything extra to produce them.

Ask for this by name. Which of your uses are in scope of the Act at all. That is a determination about your system and your deployment, and no vendor artefact settles it.

NIST AI RMF — govern, measure, manage

The question. Are the governing policies named and owned? Do measurements exist next to the work? Can you query what the system declined to do?

Where the answer is. The documents that govern how work is done are signed into a serial-numbered manifest, any document verifies back to your root, and each run's record states which standing instructions were injected — so an agent worked under rules it can be shown to have received. That is the govern function as an artefact rather than an aspiration, and checks you can run yourself has the walk. Cost and timing land on the run's own row, beside the work they measure. Refusals and overrides are ordinary data.

Ask for this by name. Deviation tracking as a distinct artefact. Refusals and overrides are recorded; deviation as a first-class, queryable category is not something this section documents.

Logging and traceability

The question. Does the trail exist, is it protected, and is it complete?

Where the answer is, for the first two. It exists and it is append-only — nothing is edited in place, a status change is a new entry, and a later edit of a gate decision breaks verification, which is re-checked at merge rather than only at write time. Losing an export invalidates nothing, because exports are views over the record rather than the record.

On the third, the honest answer is a qualified no, and you should have it from us rather than find it. The trail is complete for the work the product carried out. It is not a complete log of every time the product said no: a refusal raised before a run exists — a policy document that is absent or unreadable at the moment of dispatch, for instance — ends on the operator's terminal and writes no row at all. If your control depends on every refusal is evidence, that is the sentence to test, and what this does not prove states the rest of it.

Ask for this by name. The access log on the management surface, and its retention. Access to that surface being itself logged is a control an auditor will ask about directly, and it belongs to the identity material rather than to this section.

What to take away

The record answers who changed what, on whose approval, with what evidence per change, and it answers it from artefacts that existed before the question was asked. Where this section says to ask for something by name, that is not a hedge — it means the artefact is not documented here, and a documentation page that implied otherwise would cost you the finding rather than save you one.