What Auditors Actually Ask For in an Integration Review
Auditors ask for the same five things every year: a diagram showing how your systems integrate, an inventory of integrations per system, who owns each one, what data each handles, and evidence that changes were controlled. Most teams can produce two of these on demand.
I’ve been the person in the room for the integration section of an IT audit. The requests are remarkably consistent which is good news, because consistent requests can be automated.
1. A system diagram showing the integrations
Auditors don’t want a network topology. They want to see how business systems exchange data: ERP to payroll, order system to partner, HR to identity. Usually phrased as “a sketch illustrating the integrations between System X and other applications.”
What good looks like: a per-integration architecture diagram plus a message-flow diagram, generated from what’s actually deployed not a Visio file someone drew two years ago.
2. An inventory of integrations, per system
“An overview of integrations to and from [system].” They’ll ask this for each significant application in scope, and they’ll cross-check the answers against each other.
What good looks like: a single catalog listing every integration with its source, target, environment, criticality, data classification and owner. One table, always current.
3. Who owns each integration
Auditors need a named accountable person. “The integration team” is not an owner.
What good looks like: a business owner and a support contact recorded per integration, visible on its documentation page and a way to see instantly which integrations have no owner recorded at all.
4. What data each integration handles
This is where compliance and security overlap. Auditors want to know which flows carry sensitive or personal data, and increasingly whether logging is in place for them.
What good looks like: a classification per integration (Public / Internal / Confidential / Restricted), with the confidential and restricted ones listed individually because those are the ones anyone actually needs to look at.
5. Evidence that changes were controlled
The biggest item, and the one that consumes the most audit time. Auditors sample a handful of changes and trace each one end to end: who requested it, who authorised it, was it tested, who approved it before production, and was that a different person from the author?
What good looks like: for every change to an integration, the date, the author, the approver, the pull request, and a link to the ticket that requested it. Assembled automatically, not hunted for. I’ve written up how that chain works in practice in segregation of duties in Azure DevOps.
The two questions behind all five
Strip away the phrasing and auditors are asking two things: do you know what you have? and can you prove you control it?
The first is a discovery problem you cannot inventory what nobody registered, which is why the three-state model matters. The second is an evidence problem, and evidence is only credible if it was produced as a by-product of doing the work, not assembled afterwards by the person being audited.
Why the scramble happens anyway
Every organisation I’ve worked in could answer these questions. The information exists in Azure, in git, in people’s heads. It’s just never assembled in one place, so every audit cycle someone rebuilds it by hand. A week of senior time, every year, producing a document that’s out of date by the next deployment.
That’s what convinced me to build TrueStateRegistry: the artefacts an auditor asks for are derivable from what your pipeline already knows. Generate them on every deploy and they exist before anyone asks.
For the wider control context these artefacts sit inside, see IT general controls for Azure integration.
How does your team answer these five today — documented, or reconstructed each time? I’d genuinely like to know. Book a demo or just reply to the post.
