You have decided to modernize the system the business runs on. Somewhere in the first month, your auditor, your risk committee or a customer's due-diligence questionnaire asks the question you were hoping to defer: "How is this controlled?" If the answer is "a vendor and some AI agents are rebuilding our billing system", the meeting goes badly.
The good news is that auditors already have a vocabulary for what you are doing. A modernization program is a stream of changes to a production system, and change management is one of the most tested areas in any control framework. Describe the program in that vocabulary and most of the hard questions answer themselves.
This article covers what the common frameworks ask for, how locked specifications and gated releases map onto them, and what a control narrative for one workflow looks like. It comes from experience with audited clients, not from a law firm. Your auditor's reading is the one that counts.
What the frameworks actually ask
Four frameworks come up most often. They use different words and want the same five things.
- SOC 2. Criterion CC8.1 of the AICPA Trust Services Criteria says the entity "authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes". Every verb is a place an auditor can ask for proof.
- ISO/IEC 27001:2022. Annex A control 8.32 puts changes to information systems under change management procedures. Control 8.31 asks for separate development, test and production environments, and 5.3 for segregation of duties.
- SOX. For US-listed companies, IT general controls are tested in four domains: access to programs and data, program changes, program development and computer operations, following PCAOB AS 2201. A rebuilt invoicing system touches at least three.
- DORA. In the EU, Regulation (EU) 2022/2554 has applied to financial entities since January 17, 2025. Article 9(4)(e) requires that all ICT changes are "recorded, tested, assessed, approved, implemented and verified in a controlled manner". Article 30 adds contractual access and audit rights over providers supporting critical or important functions.
The five things are: who authorized each change, separation between those who build and those who release, testing before production, an evidence trail someone else can follow, and a way back. Let's take them in turn.
Approvals: a locked specification is an approved baseline
The weakest point in most modernization programs is not the code. It is the absence of a written statement of what the new system must do, approved by someone accountable for the outcome. Without it, "tested" has no meaning, because there is nothing to test against.
A specification derived from the running system solves this if it is treated as a controlled document. Owners and engineers review the observed behavior, confirm the rules and sign off a version. That version is locked. Any later change creates a new version with its own approval. To an auditor, that is a change request with a named approver and a date.
The same logic applies at code and release. Each pull request is approved by one of your engineers, not by the agent that wrote it. Each step that moves customer traffic has acceptance criteria agreed in advance and an approver recorded. Three layers, each with a record: specification, code, release.
Segregation of duties: the builder is not the deployer
"The person who builds a change is not the one who deploys it" is the heart of the program-changes domain in SOX and the point of ISO controls 5.3 and 8.31. Boards ask the same thing about AI agents: can the thing that writes the code push it to production? The answer has to be no, demonstrably. That means three separations.
- Environments. The rebuilt workflow runs alongside the current system with isolated data and controlled side effects. No customer traffic reaches it until release.
- Roles. Agents and the vendor's engineers propose changes. Your engineers approve merges, configuration and budget, and your technical team decides when a cohort moves. The vendor never holds write access to production.
- Release mechanics. Traffic moves by a routing change made by your team, in steps such as 1%, 10%, 50% and 100%, each gated on evidence. Rollback is the same change in reverse, tested before it is needed.
One client, a European insurer, brought internal audit into the program in week two instead of the last month. Their single request was that every release step carry a named approver and a timestamp. Cheap to give from the start, expensive to reconstruct later.
Evidence trails: the chain from rule to release
Auditors do not take your word for it, and they should not. Protiviti's 2023 SOX compliance survey found that 75% of the 564 organizations surveyed reported at least one control deficiency at year-end. In our experience many of those are controls that operated but left no evidence.
The useful test is whether an auditor can start from any rule in the new system and walk, unaided, to the release that put it live. That needs an unbroken chain:
- An evidence map of observed production behavior, with provenance and a record of what has not yet been observed.
- Requirements with stable IDs, each linked back to its evidence and forward to the work that implements it.
- The locked specification version containing the requirement, with owner sign-off.
- The pull request in your repository, with reviewer and date.
- A proof report comparing both implementations on outcomes, data, reports, permissions and performance, and how each difference was resolved.
- A release log with acceptance criteria, cohort, approver and timestamp for each step, including any rollback.
Agent actions belong in the chain too. The board that tracks the work is a control artefact. Keep it, export it, and make sure it survives the vendor relationship.
Data protection: read-only, redacted, in your infrastructure
Change controls answer "how do we know the new system is right?" Data-protection questions ask "who saw what, and where does it live?" Under GDPR Article 28, a processor acts only on your documented instructions and must allow for audits. DORA Article 30 adds access and audit rights for critical or important functions. Your data protection officer will also ask about sub-processors, including model providers. Three design choices keep these conversations short.
- Read-only access for observation and analysis, agreed with your engineers and revocable by them. Nobody outside can change the running system.
- Payload redaction before analysis, with collection kept off the request path so a collection failure cannot affect a customer.
- Your repository, your infrastructure. Code is committed to a repository you own and runs where you choose. If the engagement ends, you keep everything.
Data cutover needs its own approved plan, covering mappings, backfill and reconciliation, because it is the one step where "rollback is a routing change" is not the whole story.
A sample control narrative: invoicing, from capture to release
Auditors read control narratives, so write one. Here is an illustrative example for a single workflow.
Scope. The invoicing workflow of the order-management system: invoice-line creation, rate-card lookup and month-end totals.
Capture. Production requests, jobs, queries and report runs observed through read-only instrumentation agreed with the Head of Platform. Sensitive fields redacted before storage. Unobserved paths listed as gaps.
Lock. Requirements derived from observation and owner review, each with a stable ID and evidence link. Example: REQ-c3d4, "While an allocation has no rate card, the system shall flag the invoice line as unbillable rather than invoicing at zero." Specification v12 approved and locked by the Finance Operations lead and the Engineering lead.
Engineer. Changes implemented against v12 as pull requests to the company repository, each reviewed and merged by a company engineer. Agents hold no production credentials.
Attest. Representative workloads replayed through both implementations with side effects controlled. Outcomes, invoice totals, reports, permissions and response times compared. Differences logged as fixes with an owner and closed before release.
Release. Traffic moved by the platform team in steps of 1%, 10%, 50% and 100%, each gated on acceptance criteria and approved by the Engineering lead. Rollback tested before the first step. Each transition logged with approver and timestamp.
Evidence retained. Evidence map, specification versions, pull requests, proof report, release log and board export, all in company-controlled systems.
Notice what the narrative does not claim: zero risk, or that every rule was found. It says what was observed, approved and tested, and who decided.
Where Fabrica stands
Fabrica's CLEAR method is built around these gates. Capture uses read-only access with payloads redacted; Lock produces a versioned System Specification your owners approve; Engineer submits reviewed pull requests to your repository; Attest produces a proof report against the running system; Release moves cohorts behind acceptance criteria and a tested rollback, with each transition logged. The IT and risk page covers the controls in more detail.
Bring the auditor in before the first release
The cheapest time to agree what evidence an auditor will want is before any of it exists. Share the control narrative for your first workflow with internal audit and ask what they would test. Then build the program so the evidence falls out of the work. Modernization is a change program. Treated as one, it is something your auditor already knows how to examine.
Questions to ask before you start
- Which frameworks apply to this system, and which workflows are in scope for financial reporting or critical functions?
- Who approves each specification version, each merge and each release step, and where is that recorded?
- Can anyone outside our team write to production, and how would we prove they cannot?
- If the engagement ended tomorrow, would we still hold the code, the specification and the evidence?
