Three weeks before an audit, many companies start the same ritual. Someone sends around an email listing the documents that need to be produced. IT starts taking screenshots of settings, HR digs up who signed which policy and when, finance exports approval lists, and somebody tries to reconstruct why an external consultant was granted access to the production database eight months ago. The result is a folder of evidence that looks convincing — and cost dozens of hours of work from people who were supposed to be doing something else.
The paradox is that the controls usually did work. Access really was revoked, invoices really were approved, backups really did run. Only the evidence is missing. And evidence gathered after the fact is the most expensive kind there is: it is produced under time pressure, it ties up senior people, and it comes across as less credible than a record created automatically at the moment the thing actually happened. The scope of your specific obligations depends on your sector, jurisdiction and company size — a technical solution will never replace a consultation with a specialist in the regulation that applies to you. This article is about the mechanics, not about interpreting the rules.
Why evidence always appears at the last minute
This is not negligence. It is a consequence of how the processes are built.
In the vast majority of companies, evidence of a control is a by-product. It is in nobody's job description, nobody tracks it, and the systems the process runs in often do not retain it long enough anyway. The ticketing tool archives history after a year, an email approval disappears when the employee leaves, the access overview spreadsheet stopped being updated after a reorganisation. Until an audit arrives, nobody minds, because missing evidence causes no immediate pain.
The second reason is economic, just hidden. The cost of retroactive collection never shows up in any budget — it is paid in the time of the IT manager, the operations director and the accountant, people whose hours are not billed anywhere. Continuous evidence collection is cheaper precisely because it spreads the cost across thousands of micro-actions performed by software, instead of one spike performed by people.
An audit does not test whether you acted responsibly. It tests whether you can prove it. Those are two different questions, and companies confuse them.
The control and the evidence are two different things
This is the most useful concept in this article and also the one most often overlooked in practice. A control is a measure that reduces risk. Evidence is a record showing that the measure genuinely ran at a specific time and with what outcome. Design only the control and you get a working process with no audit trail. Design only the evidence and you get pretty documentation with no real effect.
| Control (what actually happens) | Evidence (what remains of it) |
|---|---|
| A manager reviews their team's access once a quarter | A record with a date, a name, a list of accounts and a decision on each |
| Backups run every night | A log of a successful run plus a record of the last restore test |
| A new employee is briefed on the rules | A timestamp confirming a specific version of the document |
| A supplier holds a valid contract and insurance | A register with validity dates and an alert before expiry |
| A system change went through approval | A link between the request, the approver and the deployed change |
When you write these two columns out for your ten most important controls, it usually turns out that the left side is fine and the right side is half empty. That is the brief for automation — not a rebuild of your entire risk management.
What is worth automating in compliance
Compliance automation does not work as one big system. It works as a set of narrow, boring, repetitive tasks that software handles more reliably than a person who also has another job to do.
Access rights and permission drift
Permissions have a natural tendency to accumulate. Someone changes role, receives new access, and nobody removes the old. After two years half the company holds rights it does not need. An automated export of accounts and roles, a comparison against the last known state, and a list of changes sent to the relevant manager for confirmation turns a multi-day review into a twenty-minute task. What matters is that the decision "yes, this access stays" is stored as a record with a name and a date, not as a reply in an email thread.
Logs, retention and the audit trail
If systems do not retain records long enough, and in a place the person whose activity they document cannot alter, the evidence is weak. Centralised log collection with a defined retention period and restricted access answers a large share of the questions an auditor will ask before they are even asked. This is also the area where compliance and practical cybersecurity work overlap almost entirely.
Policy and internal rule acknowledgements
Distributing a document, tracking who has acknowledged it, chasing those who have not, and tying the acknowledgement to a specific version of the document is pure administration with no professional content in it. It belongs in software.
Suppliers, contracts and expiries
The list of suppliers with the validity dates of contracts, certificates or insurance policies is in practice kept in a spreadsheet nobody opens until it is too late. An alert with enough lead time and the name of the responsible person is a simple piece of automation with a disproportionately large payoff.
Recurring checks with the result captured automatically
A check that is supposed to happen monthly in reality happens when someone remembers it. A scheduled task that triggers itself, asks the responsible person for input and stores the outcome removes the most common cause of failure — human memory. Where such checks include approval steps, it is worth handling them together with automating approval processes in a company.
The exception register
Every company has exceptions: temporarily granted access, a deferred fix, a system that does not yet meet an internal standard. The difference between a mature and an immature organisation is not whether it has exceptions, but whether it knows about them. A register with an owner, a reason, a deadline and an automatic reminder when that deadline passes is one of the cheapest things you can introduce.
Continuous monitoring instead of an annual sample
The classic internal audit model runs on samples: once a year you pick twenty transactions or ten employees and verify on them that the process works. It is a method that emerged when checking every single item was physically impossible. But if the data passes through systems you can read via interfaces anyway — which is the subject of connecting company systems through APIs — there is no reason to limit yourself to a sample.
| Criterion | Annual sampling | Continuous control monitoring |
|---|---|---|
| When a problem surfaces | At the audit, retroactively for the whole period | Continuously, within days |
| Coverage | A small sample, the rest unverified | Every case that passes through the systems |
| Who carries the load | The team in a spike, usually on top of normal work | Spread out, most of it handled by software |
| Nature of the evidence | Reconstructed after the fact | Created at the time of the event |
| Suitable for | Qualitative and judgement-based areas | Structured, repeatable controls |
| Main risk | Findings arrive too late to fix | A flood of alerts with no triage |
Take that last row seriously. Poorly configured continuous monitoring generates hundreds of alerts nobody reads and creates a false sense of control. Thresholds, an owner for each type of finding and a way to close it need to be defined before the first rule is switched on. Overview screens help with management — we covered the principles in dashboards instead of manual Excel spreadsheets — but a dashboard by itself is not evidence.
What an auditor expects from evidence
A dashboard full of green squares shows the current state. An auditor asks about the past: what was the state in March, who approved it then, on what basis, and can that conclusion be reproduced. That is why a reproducible trail is worth more to them than any visualisation, however attractive.
In practice this means four things. Evidence should have a clear origin — which system it came from and how it was obtained. It should have a time — when it was created, not when it was exported. It should have an author or a mechanism — the name of a person, or the identification of the job that produced it. And it should be immutable to the extent that the person it concerns cannot alter it afterwards. If it meets that, the format is secondary; a PDF export with a letterhead is not better evidence than a database row with a timestamp.
Where automation does not belong
There is a line automation should not cross, and it is not a technical one — it is about accountability.
Risk assessment is professional judgement. Whether a specific shortcoming is critical or acceptable depends on context a machine does not have. A tool can tell you that three former employees still have active accounts; whether that is an incident or an administrative slip is decided by a person. Sign-off must likewise carry a name — if an exception is "approved by the system", it was in fact approved by nobody, and that becomes obvious at the first serious question.
Interpreting the rules belongs here too. Whether a given obligation applies to you and to what extent is a question for a lawyer or a specialist in that field, not for a software vendor. At INTERFASE we build the technical part — collection, records and the trail — and leave the interpretation of requirements to those who are accountable for it.
Personal data deserves particular care. Collecting evidence means collecting data about employees, and that has rules of its own — we summarised the related considerations in our piece on automation and personal data protection.
How to start without a large project
Do not start by buying a platform. Start by writing down the ten controls you were asked about at your last audit and noting, for each, what evidence actually exists today. Then pick the three that are the most mechanical and the worst documented — typically access rights, expiries and document acknowledgements — and automate only those, even if it comes down to a scheduled script and a shared register. If that holds up after one cycle, add another three. Companies that start with a large platform usually return to spreadsheets within a year, because the tool never received real data.
Summary
Compliance automation is not about having more documentation. It is about evidence being created at the moment the thing happens, rather than eight months later in a spreadsheet. Separate the control from the evidence, automate what is repetitive and mechanical, monitor continuously whatever passes through your systems, and make sure the trail is reproducible. Leave judgement, risk assessment and sign-off to people — with a name and a date. And if your audit preparation feels more expensive every year than the audit itself, get in touch and let us go through what can be collected automatically in your environment.