Compliance monitoring: run a programme that keeps customer and audit promises

Your bank customer's annual supplier review lands. It asks three things. Did you give notice before adding a new subprocessor? When was your last access review? Did the "quarterly" vulnerability scans in your questionnaire answer really run quarterly? Somebody signed those commitments. Nobody has checked them since.

Compliance monitoring closes that gap. This guide is for founders, CTOs and security leads at UK B2B tech firms of 25 to 150 people selling into banks, insurers or the public sector. It shows how to build a lean compliance monitoring programme. That means one register of what you have promised and to whom, a risk-ranked plan of what to check, and results that stand up to the next audit or customer review.

What is compliance monitoring?

Compliance monitoring is the planned, risk-based checking that a firm keeps its obligations in practice. For a tech supplier that means certification controls and customer contract commitments alike. You list the obligations, rank them by risk, set a check, owner and frequency for each, record results and fixes, and report what you find.

Monitoring is different from an audit. An audit is a point-in-time examination, often by someone independent. Monitoring is the routine checking you do yourself between audits, so the audit holds no surprises and a customer review has evidence waiting for it.

ISO 27001 already asks for this inside the management system. Clause 9.1 requires you to decide what needs monitoring, how, when and by whom. A compliance monitoring programme applies the same discipline to everything you have promised, not only to your information security controls.

Which obligations does a tech supplier need to monitor?

A tech supplier needs to monitor six kinds of obligation: certification controls, contractual security schedules, data processing agreements, incident and breach notification deadlines, audit and information rights, and subprocessor and location commitments. Questionnaire answers already given count as a seventh, because customers file them and treat them as commitments.

The last row is the easiest to miss. A questionnaire answer is a commitment, whether or not anyone filed it.

Why are regulated customers checking their suppliers now?

Regulated customers check because their own rules require them to. UK banks and insurers follow the PRA's outsourcing expectations, and EU financial entities must put specific terms into ICT contracts under DORA. Both push monitoring rights and reporting duties down to suppliers by contract, so the customer's obligation becomes your commitment.

The PRA's supervisory statement SS2/21 on outsourcing and third-party risk management applies to UK banks, building societies, PRA-designated investment firms and Solvency II insurers. For material outsourcing it expects written agreements to give the firm the right to monitor the provider's performance on an ongoing basis. They must also oblige the provider to report developments that could materially affect its ability to perform.

SS2/21 goes further. The PRA says it is not enough for firms to negotiate access, audit and information rights; they must also use them when appropriate. For material outsourcing, it also tells firms not to assume a certificate or report proves the service meets their obligations simply because it exists. Your SOC 2 report helps, but the customer is expected to look behind it.

For EU-regulated customers, Article 30 of the Digital Operational Resilience Act (DORA) lists what ICT contracts must contain. All contracts must cover data locations, with advance notice of changes, and assistance when an ICT incident occurs. Contracts for critical or important functions add performance targets, reporting duties and unrestricted rights of access, inspection and audit. DORA binds the financial entity; it reaches most suppliers through the contract.

Data protection adds its own layer. Under UK GDPR Article 28(3)(h), a processor must give the controller the information needed to show it meets its Article 28 duties, and allow for and contribute to audits, including inspections. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a personal data breach.

How do you build a compliance monitoring programme?

Build a compliance monitoring programme in six steps: register every commitment, rank each one by risk, choose a check type, set a frequency and owner, record results and fixes to closure, and report. The register is the foundation. Without it, monitoring defaults to whatever the last auditor asked about.

Step 1: Build the commitments register

Pull every promise into one list. Start with your SOC 2 scope or ISO 27001 Statement of Applicability. Then work through signed customer contracts, security schedules, DPAs and the questionnaires you have answered in the last two years. Record each commitment with its source, the customers it applies to, and any deadline or frequency it states.

Expect duplicates. Ten customers may hold ten versions of the same breach notification clause with different deadlines. The register should show the strictest version, because that is the one your incident process has to meet.

Step 2: Rank each commitment by risk

Rank commitments by two questions: how likely is it to drift, and what happens if it does? A missed notification deadline in a bank contract can cost the account. A stale policy review date rarely costs anything. If you have a compliance risk assessment, use its ratings; if not, a simple high, medium and low scale is enough to start.

Commitments that depend on a person remembering are the most likely to drift. Commitments enforced by your platform, such as encryption at rest, drift less but fail silently when they do.

Step 3: Choose a check type for each commitment

Match each commitment to the cheapest check that produces real evidence. Five check types cover almost everything a supplier promises; the next section sets out which suits which. The rule is simple: a check must leave a record someone else could inspect.

Step 4: Set the frequency and owner

Set frequency by risk, not by habit. High-risk commitments get monthly or continuous checks; low-risk ones may need only an annual review. NIST SP 800-137 makes the same point for security monitoring: frequencies are neither static nor uniform, and are adjusted as systems, their environments and threats change.

Give every check a named owner. A check with no owner is a wish.

Step 5: Record results and fix exceptions to closure

Record every check, including the ones that pass. A passing result with a date is the evidence a customer or auditor will ask for. For each exception, log the cause, the fix, the owner and a target date, and keep it open until the fix is verified.

Track repeat exceptions separately. A control that fails the same check twice is telling you its design is wrong, not that someone forgot.

Step 6: Report what you find

Report results on a fixed cycle to whoever owns the risk: usually the leadership team or board monthly or quarterly, and the auditor and customers when they ask. Keep the report short: status by obligation area, open exceptions, commitments at risk and decisions needed. One evidence base should feed every report, so the numbers agree.

Which compliance check suits which obligation?

Five check types cover most supplier commitments: an automated control test, a configuration or log review, a sample test, an attestation and a document review. Use automated tests where a system holds the evidence, sample tests where people perform the control, and attestations only where nothing better exists.

Attestations are the weakest check. Use one only where the control leaves no other trace, and say so when you report the result.

What does a compliance monitoring plan look like?

A compliance monitoring plan is a table with one row per commitment: the obligation, its source, the risk rating, the check type, the frequency, the owner and where the evidence lives. For a 25 to 150-person supplier, a working plan can fit on one page per obligation area. The excerpt below shows the shape.

Notice what drives the frequency: the cost of drifting, not the effort of checking. The automated row is continuous because the test is cheap. The training row is annual because the risk is low.

Who should own compliance monitoring in a firm without a compliance function?

In a firm without a compliance function, one named person should own the programme: usually the security lead, the CTO or the COO. Each check is owned by whoever runs the control. The programme owner keeps the register and plan, chases exceptions and reports. Control owners perform checks and record results.

Separate the person who runs a control from the person who checks it where you can. In a small team that may mean engineers checking each other's areas, or the programme owner sampling records directly. Full independence is the auditor's job; your aim is that nobody marks their own homework on high-risk commitments.

Most of the effort sits in building the register once. After that, the work is a steady rhythm of small checks spread across control owners, with the programme owner's time going on exceptions and reporting.

Where does automation fit in compliance monitoring?

Automation fits where a system already holds the evidence: configuration settings, logs, identity records and scan results. Automate those checks first and keep human judgement for contract interpretation, sample testing and exception decisions. Automation is one technique inside the programme, not the programme itself.

NIST's SP 800-137 on information security continuous monitoring defines that discipline as maintaining ongoing awareness of information security, vulnerabilities and threats to support risk management decisions. It says organisation-wide monitoring cannot be achieved efficiently through manual processes alone or automated processes alone. Our NIST SP 800-137 overview explains the framework.

Engineering automated control tests, thresholds and alerting is a separate subject. For a SOC 2 Type 2 or ISO 27001 surveillance cycle, the question this page answers is which commitments deserve an automated check. The register and risk ranking decide that, not the tooling.

What are the common mistakes in compliance monitoring?

The most common compliance monitoring mistakes are monitoring only certification controls, planning from the last audit, checking what is easy rather than what is risky, and closing exceptions before the fix is verified. Each one leaves a commitment unchecked until a customer or auditor finds it first.

• Monitoring the certificate, not the contract. Your SOC 2 Type 2 report tests the controls in its scope over its period. It says nothing about the notification deadline you agreed with one bank.
• Planning from the last audit. Last year's findings tell you where you were weak, not where you are now. Build the plan from the register.
• Checking what is easy to check. Automated tests on low-risk settings can crowd out the manual sample test on the commitment that could lose an account.
• Closing exceptions on a promise. An exception is closed when the fix is verified, not when someone says it is done.

A monitoring plan that only tests what the auditor tests is an audit rehearsal, not a monitoring plan.

How do you keep a compliance monitoring programme lean?

Keep a compliance monitoring programme lean by monitoring commitments, not documents. Register once, rank by risk and automate where systems hold the evidence. Review the plan whenever a new contract or certification changes what you have promised. Done that way, compliance monitoring becomes the evidence base for every customer review rather than a scramble before each one.

The payoff is commercial. When the next supplier review arrives, the evidence already exists, and the answer to "can you show us?" is yes.

Frequently asked questions