IT General Controls for Azure Integration: A Practical Guide
Short answer: IT General Controls (ITGC) are the foundational controls auditors test to decide whether they can trust your systems at all. For an Azure integration estate, four things matter most: knowing what integrations exist, who owns them, what data they move, and proving that every change to them was authorised, reviewed and approved before it reached production. Most teams can produce two of those on demand. The rest gets assembled by hand the week before the audit.
I’ve spent fourteen years building integrations on Azure and Oracle middleware, and I’ve sat on the wrong side of that table. This is what I wish someone had explained to me the first time.
What ITGC actually covers
ITGC is usually grouped into four domains: access to programs and data, program changes, program development, and computer operations. Auditors test them because they underpin everything else if your change control is weak, no application-level control can be relied upon.
For an integration estate, two of those domains carry almost all the weight:
Access controls. Who can change an integration, and which identities do the integrations themselves run as? Auditors care a great deal about non-personal accounts, service principals, managed identities, system accounts because they’re the ones nobody reviews when an employee leaves.
Change management. This is where most audit time goes. For a sample of changes, the auditor traces the full chain: it was requested, it was authorised, it was tested, it was approved by someone other than the author, and only then did it reach production.
Why integrations are the hardest part of an ITGC audit
An ERP has a change process. A payroll system has a vendor and a release cycle. Integrations have neither. They’re built quickly, often by one person, frequently under deadline, and they connect systems that each have their own owner which usually means the integration itself has none.
So when the auditor asks “which integrations move customer data to third parties, and who owns them?”, the honest answer in most organisations is: we’d have to go and find out. That finding-out is the scramble a week of reconstructing reality from memory, spreadsheets and old chat threads. It’s expensive, it’s stressful, and “we reconstructed it” is exactly the phrase that gets written up.
The deeper problem is that you can’t govern what you can’t see. An estate always contains integrations nobody registered — and increasingly, ones that exist only as code in a repository and were never formally deployed. I wrote about that discovery problem and how to classify it in the three-state governance model.
The four artefacts that carry an integration ITGC audit
Across every audit I’ve been part of, the same artefacts get requested:
- A diagram of how your systems integrate – the systemskisse, in Norwegian audit language. Auditors want to see the flows, not just a list.
- An inventory of integrations per system – what talks to your ERP, your HR system, your finance platform.
- Ownership and data classification – who is accountable, and what sensitivity of data each integration handles.
- Change evidence – for sampled changes: the request, the approval, the reviewer, and the deployment.
I’ve broken down exactly how auditors phrase these requests, and what “good” looks like for each, in what auditors actually ask for in an integration review.
The control that trips teams up most: segregation of duties
Of all ITGC requirements, the one that causes the most audit findings in integration work is segregation of duties the principle that the person who makes a change is not the person who approves it. It’s a core control in ISO 27001, SOC 2 and ISAE 3402.
The good news is that if your team uses pull requests, you’re already doing it. The bad news is that the evidence is scattered across git, your pull requests, and your ticketing system so proving it takes hours of manual assembly per sampled change. I’ve written up how to make that evidence produce itself in segregation of duties in Azure DevOps.
Continuous, not annual
Here’s the shift that actually solves this. Most teams treat audit evidence as an annual project. It isn’t, it’s a by-product of how your team already works. Every deployment already knows which resources changed. Every pull request already records who approved it. Every ticket already records who asked for it. The information exists; it’s just never assembled.
If the assembly happens automatically on every deploy, the audit stops being an event you brace for. The evidence is simply there, current, on any day someone asks including the day an auditor picks a change from eight months ago at random.
That’s the principle TrueStateRegistry is built on: a registry of your Azure integrations that regenerates itself on every deployment, in your own tenant, so what runs, who owns it, what data it moves and how it changed is always current.
If audit-readiness for your Azure integrations is a live problem where you work, I’d like to hear how you handle it today — I’m onboarding a small number of founding customers and learning from every conversation. Book a demo.
