Compliance automation: what to automate first, and what never to

Your second SOC 2 or ISO 27001 audit is three months away. The evidence from the first one lives in a shared drive of screenshots, and the person who took them has moved on. Meanwhile an enterprise prospect's security review is waiting on proof that your controls still work.

Compliance automation is the use of software to collect evidence, test controls and track compliance tasks without manual effort. Start with the high-frequency, machine-readable controls (access, MFA, patching, backups and logging), keep judgement controls such as risk acceptance human, and expand one workflow at a time.

This guide is for heads of engineering, CTOs and first compliance hires at UK B2B tech firms with 25 to 250 staff. It gives you a scoring method, a worked ranking of ten common controls, the decisions that must stay human, and a rollout plan a lean team can run.

What is compliance automation?

Compliance automation hands the repeatable work of compliance to software. It covers four jobs: pulling evidence from your systems, checking controls against a rule, sending reminders and routing tasks, and reporting status. It does not replace the people who decide what the results mean, approve the exceptions and answer to the auditor.

That last point matters more than it sounds. NIST's guidance on information security continuous monitoring (SP 800-137) says plainly that "it is not possible to fully automate all of an organization's information security program functions". The same document notes that monitoring across an organisation cannot be done efficiently through manual processes alone, or through automated ones alone.

So compliance automation is not a choice between people and tools. It is a decision about which work goes to which. Our NIST SP 800-137 page covers the monitoring model behind it.

Automation that nobody reads is just faster filing.

What should you automate first in compliance automation?

Automate first the controls that need evidence often, are tested often, already have a machine-readable data source, carry real weight with auditors, and are cheap to wire up. Score each control on those five factors, sort the list, and start at the top. The scoring takes an afternoon and saves you from automating what impresses rather than what pays.

We recommend scoring each factor from 1 (low) to 3 (high):

1. Evidence frequency. How often does an auditor or customer ask for proof? Monthly or per sample scores 3; once a year scores 1.
2. Test frequency. How often should the control be checked? NIST SP 800-137 makes the same point about volatility: controls that change often, such as system configuration, need checking more often than stable ones, such as personnel screening.
3. Data source. Does an API, log or export already hold the answer? A cloud console or identity provider scores 3; a conversation in someone's head scores 1.
4. Audit weight. How much does the control matter to the opinion or certificate? Access, change and backup controls usually score high.
5. Ease. How little effort will it take? An existing export scores 3; a custom integration across three systems scores 1.

Add the five scores for a total out of 15. A control scoring 12 or more is a strong first candidate. A control below 8 usually belongs to people, with automation limited to reminders.

How do common ISO 27001 and SOC 2 controls rank?

Applied to a typical cloud-hosted SaaS firm, the scoring puts identity and infrastructure controls at the top and supplier and judgement work at the bottom. Multi-factor authentication, leaver access removal and patching score highest, because the evidence already sits in an identity provider or cloud console and auditors sample it heavily.

The ranking below is our illustration for a firm of 25 to 250 staff running on a major cloud platform. Your scores will shift with your stack, so treat it as a worked example, not a verdict.

Two rows deserve a note. The quarterly access review scores well, but only part of it should be automated: the access list, the reminders and the record. The reviewer's decision to keep or remove each account stays human. Supplier reviews score lowest because the evidence arrives as documents and the judgement is the point.

What should you never automate in compliance?

Never automate a decision that needs someone accountable to own it. Risk acceptance, management review, policy approval and incident severity calls all need a named person to weigh context and answer for the result. A workflow can gather their inputs and record their decision. It should never make the decision for them.

ISO 27001 clause 9.3 is the clearest example. It asks top management to review the management system at planned intervals and decide whether it is still suitable, adequate and effective. You can automate the review pack: the metrics, the open actions and the audit findings. An automated "approval" of the review itself would show an auditor that leadership was never in the room.

The same logic applies elsewhere:

• Risk acceptance. ISO 27001 expects risk owners to approve treatment plans and accept residual risk. A rule that auto-accepts anything below a score hides the owner the standard asks for.
• Policy approval. Management approves policies. A workflow can route the draft and store the sign-off, but the sign-off must be a person.
• Incident severity. The first severity call shapes who gets woken up and whether a regulator or customer hears about it. Let alerts suggest a severity; let a person confirm it.

This is the split we use for our own ISO 27001, ISO 9001 and ISO 42001 management systems:

A rule that accepts risk on your behalf is not a control. It is a missing owner.

How do you roll out compliance automation with a lean team?

Roll out compliance automation one workflow at a time. Pick the task your team dreads most, map how it works today, choose the simplest tool that fits, automate that one task end to end, measure the hours saved and exceptions caught, then use the result to fund the next one. Each cycle makes the next one easier.

We call this the GRC automation flywheel. In plain form, it has six steps:

1. Find the pain. Ask the team which recurring compliance task costs the most time for the least value. Check it against your scoring.
2. Map the workflow as it runs today. Write down each step, who does it and where it stalls. Most broken steps show up here, before any tool is involved.
3. Choose the simplest tool that fits. Start with what you already run: your identity provider, cloud console, ticketing system or a scheduled script.
4. Automate one task end to end. Collection, check, record and alert, all working, for a single control.
5. Measure the result. Record hours spent before and after, and how many exceptions the automation caught that a person would have missed.
6. Expand. Use the numbers to choose and justify the next workflow.

The tools at step 3 can be modest. One SaaS firm we worked with automated its quarterly access reviews with forms, a spreadsheet and chat reminders, with no platform at all. At a fintech we worked with, the CISO spent about 30 hours a month gathering screenshots for SOC 2 evidence. One automation rule and a shared folder turned that into a two-hour monthly check-in.

The measurement at step 5 is what keeps the flywheel turning. "It feels faster" will not win budget. A before and after count of hours and exceptions will.

Should you build or buy compliance automation tools?

Build when your controls live in a few systems you already script against, and your team can own the code. Buy a platform when the number of frameworks, systems and evidence requests outgrows what your team can maintain. Either way, map your workflows first, because a tool chosen before the process is known rarely fits it.

Building usually means scheduled scripts, cloud-native policy checks and your existing ticketing system. It costs engineering time and gives you exact control over what is collected. Buying gives you integrations and a dashboard faster, at a recurring cost, with a data model you adopt rather than design.

We have seen teams buy a platform, find it did not match how they actually worked, and drift back to spreadsheets. That is a sign the mapping step was skipped, not a sign the platform was wrong. Our guide to GRC tools covers the options in more depth.

Where does AI fit in compliance automation?

AI fits in the drafting and suggesting layer of compliance automation: first drafts of policies, suggested mappings between controls and frameworks, and summaries of findings. Every output needs human review before it becomes a record. Using AI this way also brings its own governance duties, under ISO 42001 and the EU AI Act.

Two points are worth planning for early:

• ISO 42001. If you hold or are working towards ISO 42001, we recommend recording any AI tool that drafts compliance content in your AI system inventory, with an owner and a review step. Do it even before you are certified.
• The EU AI Act. Article 4 of the EU AI Act places an AI literacy duty on providers and deployers of AI systems, which includes a firm using AI tools in its own compliance work. The Act can reach UK firms whose AI outputs are used in the EU. Our EU AI Act page explains when it applies.

AI should never be the layer that collects audit evidence or decides a control has passed. Those jobs need the same answer every time, which is what deterministic workflows are for.

How do continuous control monitoring and evidence collection fit in?

Continuous control monitoring and automated evidence collection are the two engines inside compliance automation. Evidence collection gathers proof that a control ran. Continuous monitoring tests that the control is still working between audits. Both feed the human evaluation that ISO 27001 clause 9.1 and the SOC 2 monitoring criteria expect.

NIST SP 800-137 defines continuous monitoring as "maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions". The last four words are the point: monitoring exists to inform a decision.

That is how ISO 27001 clause 9.1 works in practice. Automated collection supplies the data, and a dated evaluation by a person turns it into evidence. The CC4 monitoring activities in the AICPA Trust Services Criteria ask the same question for SOC 2: does someone check that controls work, and fix what does not?

Regulated customers raise the bar further. Financial entities under DORA must continuously monitor and control the security of their ICT systems, and DORA's rules on ICT third-party risk mean their due diligence may ask suppliers how they do the same. Test design and the full evidence catalogue each have their own guides in this cluster.

What are the common mistakes with compliance automation?

The common mistakes with compliance automation are automating a broken process, buying a platform before mapping workflows, creating alerts nobody owns, and calling scheduled screenshots automation. Each one adds activity without adding assurance, and each one surfaces at the worst time: during the audit or the customer review.

• Automating a broken process. If the manual access review never removed anyone, the automated one will not either. Fix the process, then automate it.
• Buying before mapping. A platform cannot tell you how your workflows should run. Map them first, then judge any tool against the map.
• Alert noise nobody owns. Every automated check needs a named owner and a response time. A queue of unread alerts is worse evidence than none, because it proves the failures were seen and ignored.
• Screenshots dressed up as automation. A script that takes a screenshot on a schedule is still a screenshot. It shows a moment, not a state. Prefer exports, API results and logs that show configuration over time.
• No exception path. Automation will find failures. Decide in advance who triages them, how quickly, and where the decision is recorded.

Frequently asked questions