---
title: "Compliance monitoring: run a programme that keeps customer and audit promises"
canonical: https://www.grcmana.io/vault/compliance/compliance-monitoring
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "Compliance"
control: "Guide Compliance monitoring: run a programme that keeps customer and audit promises"
journeyStage: intermediate
---

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

## Key takeaways

Compliance monitoring is the planned, risk-based checking that a firm keeps its obligations in practice. For a UK tech supplier that covers SOC 2 and ISO 27001 controls and the commitments regulated customers flow down by contract. Build one register of commitments, rank them by risk, set a check, owner and frequency for each, record results and fixes, and report them.

- **PRA SS2/21 monitoring rights** — For material outsourcing, the PRA expects contracts to give the firm ongoing rights to monitor the provider, and to require notice of developments that could materially affect its ability to perform.
- **Certificates are not proof on their own** — Under PRA SS2/21, firms should use their negotiated audit and information rights when appropriate, and for material outsourcing should not treat a supplier's certificate as sufficient evidence simply because it exists.
- **DORA Article 30** — Under DORA Article 30, EU financial entities' ICT contracts must cover data locations, advance notice of location changes and incident assistance; critical or important functions add ongoing monitoring and unrestricted audit rights.
- **Processor breach notification** — Under UK GDPR Article 33(2), a processor must notify its controller customer without undue delay after becoming aware of a personal data breach. Contracts can set a firmer deadline on top.

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](https://www.grcmana.io/vault/iso-27001/clause-9-1-monitoring-measurement-analysis-and-evaluation) 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.

| Obligation | Where it comes from | Example of what to check |
| --- | --- | --- |
| Certification controls | Your [SOC 2](https://www.grcmana.io/vault/soc-2) scope or ISO 27001 Statement of Applicability | Access reviews ran on schedule and left a record |
| Contractual security schedules | Customer master service agreements and security annexes | Encryption, logging and retention commitments still match the platform |
| Data processing agreements | UK GDPR Article 28 contracts with each controller customer | Records exist to demonstrate compliance on request |
| Incident and breach notification deadlines | DPAs, security schedules and outsourcing clauses | The incident process names each customer's deadline and contact |
| Audit and information rights | Outsourcing and ICT clauses in regulated customers' contracts | You can respond to a request within the agreed notice period |
| Subprocessor and location commitments | DPAs and outsourcing clauses | New subprocessors and hosting regions were notified before the change |
| Questionnaire answers | Security questionnaires and due diligence packs | Stated frequencies and tools are still true |

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](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss) 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)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) 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](https://www.grcmana.io/vault/gdpr) [Article 28(3)(h)](https://www.legislation.gov.uk/eur/2016/679/article/28), 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.

| Check type | What it is | Best for | Watch out for |
| --- | --- | --- | --- |
| Automated control test | A scheduled query against a system that confirms a setting or event | Encryption, MFA, logging, backup completion | Tests that pass because they check the wrong thing |
| Configuration or log review | A person reviews settings or logs against the commitment | Hosting regions, retention periods, admin access | Reviews with no record of what was looked at |
| Sample test | Select a sample of occurrences and check each one | Joiners and leavers, change approvals, incident tickets | Samples chosen by the person who runs the control |
| Attestation | The control owner confirms in writing that it ran | Training completion, policy acknowledgement | Used where evidence exists but nobody collected it |
| Document review | Check a document is current, approved and matches practice | Policies, subprocessor list, business continuity plan | Approving the document without checking the practice |

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.

| Commitment | Source | Risk | Check | Frequency | Owner | Evidence |
| --- | --- | --- | --- | --- | --- | --- |
| Notify customers of a personal data breach within the agreed deadline | DPAs and security schedules | High | Sample test of incident tickets against each customer's deadline | Quarterly, and after every incident | Head of security | Incident log with notification timestamps |
| Give advance notice of new subprocessors | DPAs | High | Document review of the subprocessor list against notices sent | Monthly | Data protection lead | Subprocessor register and notice emails |
| Host customer data only in agreed regions | Security schedules, ICT contracts | High | Automated control test of storage regions | Continuous, reviewed monthly | Platform lead | Test results and exception log |
| Review privileged access | SOC 2 scope, ISO 27001 Statement of Applicability | Medium | Sample test of access review records | Quarterly | Engineering manager | Signed review records |
| Run vulnerability scans at the frequency stated in questionnaires | Questionnaire answers | Medium | Configuration review of scan schedule and last results | Monthly | Security engineer | Scan reports |
| Complete annual security awareness training | Security schedules | Low | Attestation backed by training records | Annually | People lead | Training completion report |

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](https://csrc.nist.gov/pubs/sp/800/137/final) 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](https://www.grcmana.io/vault/nist-800-137) 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](https://www.grcmana.io/vault/soc-2/type-1-vs-type-2) 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

### How often should compliance monitoring checks run?

Risk sets the baseline, but the commitment's own wording sets the floor. If a contract or questionnaire promises quarterly access reviews, checking them once a year lets a missed review stay hidden for months. Add event-driven checks too: after an incident, a new subprocessor or a hosting change, re-check the commitments it touches.

### What is contract compliance monitoring?

Contract compliance monitoring checks that you keep the specific terms agreed with each customer, such as notification deadlines, data locations and subprocessor notice. A certification audit tests your controls against its own criteria, not each customer's wording. Re-check these terms at every renewal, because a renegotiated contract can change what you have promised.

### Does a SOC 2 report or ISO 27001 certificate replace compliance monitoring?

No, but it gives you a head start. Map each row of your commitments register to the SOC 2 or ISO 27001 control that already covers it. The rows left unmapped, often customer-specific terms, are the ones your own monitoring has to cover.

### Do you need a tool to run compliance monitoring?

Not to start. A spreadsheet or the ticketing system your team already uses can hold the register, the plan and the results log, as long as all three are linked by commitment. Consider a dedicated tool when the number of checks or customers makes the spreadsheet hard to keep current.

### What should you do when a check shows a commitment was broken?

Log it as an exception and fix it, then check the contract for a duty to tell the customer. For material or critical services, SS2/21 and DORA both expect contracts to require suppliers to report developments that could materially affect their ability to deliver. Record when and how you told the customer: that record is evidence too.