Compliance automation: controls as code and continuous evidence

Three days before the SOC 2 renewal, the compliance lead is back through eight months of Slack messages looking for the access review that supposedly happened in March. It happened. Someone did it. But the evidence is a screenshot in a DM, half-cropped, and the auditor wants a dated, exportable record, not a memory. By Thursday night the team has rebuilt six months of controls evidence from email threads, ticket comments and one spreadsheet someone kept "just in case." The audit passes. Nobody wants to do that again, and everybody will, because nothing about how the controls actually ran has changed.

Compliance automation means using software to enforce a control at the moment it matters and to record that it happened, so the evidence already exists when someone asks for it. Instead of a policy saying access gets reviewed quarterly, a script runs the review and timestamps the result, which is what turns compliance from an annual scramble into an operating condition.

Compliance automation is the alternative: using software to enforce a control at the moment it matters and to record that it happened, so the evidence already exists when someone asks for it. Instead of a policy document saying access gets reviewed quarterly, a script runs the review, flags the exceptions, and timestamps the result. Instead of trusting that encryption is switched on everywhere, a monitor checks continuously and raises an alert the moment it isn't.

We build data and AI systems for clients at Shipshape Data, and the pattern we see is depressingly consistent: compliance treated as an annual event rather than an operating condition. A framework gets implemented, screenshots get taken, the auditor leaves, and the controls quietly drift out of shape until next year's fire drill. This guide covers what compliance automation means, how controls as code works, what continuous monitoring catches that a point-in-time check never will, why the evidence trail matters more than the control itself, and where none of this replaces a person who can use judgement.

Why the scramble happens every single time

Most compliance programmes are built around a single moment: the audit. Everything before that moment is preparation, and everything after it is relief. The trouble is that risk doesn't run on an annual cycle. A misconfigured storage bucket doesn't wait politely for renewal season. Neither does an employee who leaves the company and keeps their access for six weeks because offboarding is a manual checklist someone forgot to run.

Point-in-time checks tell you about one point in time

A control that gets verified once a quarter tells you the state of the world on the day it was checked. It says nothing about the eleven weeks either side of that day. We've sat with clients whose access review looked spotless in March and had four former employees still active in June, because the review was a snapshot and the world kept moving after the shutter clicked. Nobody had done anything wrong on paper. The review happened, it was signed off, the box was ticked. The gap between "compliant on paper" and "compliant right now" is where most real incidents live, and it's a gap that a calendar reminder can't close no matter how often you set it.

Evidence gathered after the fact is evidence you can't fully trust

When evidence is assembled retroactively, from memory, from someone's inbox, from a screenshot taken because an auditor asked, you're reconstructing a record rather than reading one. Reconstructed records have gaps, and the person filling the gaps has every incentive to fill them in the company's favour, through the ordinary human habit of assuming things were fine rather than through dishonesty. A control that logs itself doesn't have that problem. It either ran or it didn't, and the log says which. This is a smaller claim than it sounds: automated evidence isn't more honest because software is somehow more virtuous than people. It's more honest because it removes the opportunity to round the story up.

What compliance automation actually means

Strip away the vendor language and compliance automation is two things working together: controls that execute rather than get described, and a record of that execution that survives being asked about eighteen months later.

It's not the same as governance, and it's not a replacement for it

Data governance decides what the rules should be and who owns them. Compliance automation is the mechanism that makes those rules happen day to day, rather than existing only in a policy PDF nobody has opened since it was signed off. You still need someone to decide that customer data gets encrypted at rest, that access follows least privilege, that a data subject request gets actioned within a set number of days. Automation is what turns that decision into something that runs on a schedule, checks itself and tells you when it stops being true.

The three jobs it does

First, it enforces: a control gets applied automatically rather than relying on someone remembering to apply it. Second, it monitors: the state of the control gets checked continuously rather than at the next scheduled review. Third, it records: every check, pass, and failure gets logged somewhere an auditor, a regulator, or your own risk committee can read without asking anyone to reconstruct anything. Most tools on the market do all three to varying degrees. Few do all three well, and the honest starting point for most organisations is doing one of them properly before reaching for the rest. We'd rather see a client automate evidence collection for two controls thoroughly than buy a platform promising all three across forty controls and configure none of them past the default settings.

Controls as code: writing the policy so a machine can check it

The phrase sounds grander than the work. Controls as code means taking a requirement, "production databases must not be publicly accessible," and expressing it as a rule a system can evaluate, rather than a line in a document a person is meant to remember.

What this looks like in practice

A cloud security posture tool scans infrastructure configuration against a written policy and flags anything that violates it: an open port, a bucket without encryption, a role with more permissions than its job needs. Under GDPR, a rule might check that personal data fields carry the retention tag the policy requires and raise a flag the moment a new table skips it. None of this is exotic engineering. Most of it is a policy-as-code framework sitting on top of infrastructure that's already defined in code, because you can't automatically check a control against a system nobody described in a machine-readable way in the first place.

The catch nobody mentions in the sales deck

Writing a control as code forces a precision that the original policy document never had. "Access should be reviewed regularly" can't be turned into a rule until somebody decides what "regularly" means in days, who counts as a reviewer, and what happens when the review is late. That conversation is usually harder than the engineering, and it's exactly the conversation most organisations have been avoiding by leaving the policy vague. Doing this properly surfaces every ambiguity in your existing compliance documents, which is uncomfortable and also the entire point.

Continuous monitoring: catching drift before someone else does

A control that was correctly configured on Monday can be wrong by Wednesday. Someone patches a system and accidentally opens a port. A new employee gets added to a group with more access than their role needs, because the fastest way to unblock them was to copy an existing colleague's permissions. Configuration drifts. It always drifts. The question is whether you find out this week or during next year's audit.

What gets monitored

Access and permissions sit at the top of most lists, because privilege creep is the single most common finding in any audit we've sat through. Encryption status, on data at rest and in transit, is close behind. Logging coverage matters too: a system that stopped sending logs three weeks ago is a control failure even though nothing else about it changed, and it's the kind of failure a quarterly review reliably misses because nobody thinks to check that the checking itself is still working.

Alert fatigue is the actual failure mode, not the missing tool

The honest problem with continuous monitoring is behavioural, not technical. Turn every rule on at maximum sensitivity and the team gets three hundred alerts a day, learns to ignore the dashboard within a fortnight, and the one alert that mattered scrolls past unread with the rest. We'd rather see a client start with fifteen well-tuned rules that get acted on every time than two hundred rules nobody has the capacity to triage. Monitoring that generates noise nobody reads is functionally identical to not monitoring at all, except it costs more and creates a false sense of coverage.

Evidence collection and audit trails: the part that saves you

An auditor doesn't take your word that a control worked. They want to see it. Evidence collection is the discipline of capturing that proof automatically, at the moment the control runs, rather than reconstructing it under deadline pressure the week before the review.

What good evidence looks like

A timestamped log entry showing an access review ran, who it flagged, and what happened to each flagged account. A record of every configuration change to a production system, who made it and when. A trail showing a data subject access request came in, was actioned within the required window, and the response went to the right person. None of this is glamorous. All of it is the difference between an audit that takes an afternoon and one that eats a fortnight, with three people pulled off their actual jobs to go looking for proof that ought to have existed already.

Tracing where a piece of evidence actually came from matters as much as having it, which is where data lineage earns its keep in a compliance context: an auditor asking "how do you know this field was encrypted" needs a traceable answer, not an assurance.

An audit trail nobody built on purpose is a trail somebody will have to build under deadline, from memory, right when it matters most.

Where this gets genuinely difficult

Evidence is easy to collect for anything that already runs inside a system with logging built in. It gets much harder the moment a control depends on a human decision made outside any system: a verbal approval in a meeting, a judgement call in an email thread, an exception granted because the deadline was tight and nobody wanted to be the person who said no. Those decisions matter and they resist automation, which is precisely why they need a deliberate process for capturing them rather than being left to fall through the gap between the tooling and reality.

What still needs a human, and why the honest answer is quite a lot

None of this removes the need for judgement, and any vendor telling you otherwise is selling something. Automation is very good at checking whether a rule was followed. It's not good at deciding whether the rule was the right one, or whether an exception is reasonable.

Interpretation is still a person's job

Whether a specific data-sharing arrangement satisfies a regulator's expectation of "appropriate safeguards" under GDPR is a legal judgement, not a boolean. A tool can check that a data protection impact assessment exists and was signed off within the required timeframe. It can't tell you whether the assessment itself was any good, or whether the risk it accepted was acceptable. That still needs someone who understands both the regulation and the business well enough to weigh the two against each other, and it needs that person to have read the assessment rather than skimming the summary and signing where indicated.

Exceptions need a person who can say no

Every control regime eventually meets a situation the rule didn't anticipate. A vendor needs emergency access outside the normal approval window because a production system is down at 2am. The rule says no. The business says the outage is costing real money every minute. Someone has to weigh those two facts and take responsibility for the decision, and no monitoring platform should be making that call unsupervised, however tempting it is to let the system auto-approve anything under a certain risk score just to keep the pager quiet.

Where to start

Do not attempt to automate everything at once, and do not start with the framework that looks most impressive on a slide. Start with the control that already causes the most pain every audit cycle, the one everyone dreads gathering evidence for, because that's where automation pays for itself fastest and where the case for doing more of it becomes obvious to the people who hold the budget.

Pick one control, get it enforcing itself and logging its own evidence properly, and use that as the template for the next one. Access reviews and encryption checks are usually the easiest wins because the underlying systems already produce the signals a monitor needs, and because the pain of doing them manually is fresh in everyone's memory from the last audit. The controls that depend on a human judgement call, the ones that live in emails and meetings, need a different kind of process: a lightweight, deliberate way of capturing the decision and the reasoning, not a bigger dashboard. Writing that decision down at the time it was made, in one sentence, in a place someone can find it later, does more good than any tool that arrives afterwards trying to reconstruct why an exception was granted.

Compliance automation won't remove the need for people who understand the regulation, the business, and the difference between the two. It removes the part of the job that was never really compliance work in the first place: hunting through old messages for proof that something happened eight months ago. If you're tired of rebuilding evidence from scratch every audit cycle, or you're not sure which controls in your stack could already be enforcing and logging themselves, talk to us. We'd rather help you build the record once than watch you reconstruct it again next year.

Frequently asked questions