ComplianceOps in Plain Language: What It Covers and What It Does Not

Clients increasingly arrive at a consulting engagement with a request that sounds simple: “we need to be compliant.” Underneath, the real need is rarely a single deliverable. It is a working arrangement in which someone owns the promises the company has made, someone proves they are kept, and the people who build the technology are not interrupted every quarter with duplicate questions. That arrangement is what practitioners call ComplianceOps, and this explainer sets out its boundaries in plain terms.

One sentence definition

ComplianceOps treats compliance as a continuing operation. A single library of controls is mapped to every framework the client cares about, evidence is collected and tested on a schedule, exceptions are time-limited, and an audit is answered from records that already exist. The Atlas entry for ComplianceOps sets the same picture out and adds that the term is still young and mostly promoted by software vendors, while the underlying discipline is older.

What sits inside the scope

The Atlas lists the responsibilities a ComplianceOps function holds:

• An inventory of obligations, meaning every contractual, regulatory and internal duty.
• A control library with mappings across frameworks.
• Evidence collection and testing.
• An exception process with owners and end dates.
• Policies, audit management and the governance tooling that holds it together.

For a consultant this list doubles as a statement-of-work outline. If a proposal does not mention each item, either it is intentionally leaving something out or it will discover the gap mid-project.

What sits outside the scope

Equally useful is the exclusion list. Deciding how much risk a company will accept belongs to risk management. Handling individual privacy requests belongs to privacy operations. Building the technical safeguards belongs to security and platform engineering. Anti-money-laundering programmes share a similar-sounding name but are an entirely separate field. Interpreting the law belongs with counsel.

The Atlas summarises the division of labour crisply: the neighbouring teams make a control true, and ComplianceOps proves that it stayed true. This framing prevents an awkward and common failure in engagements, where the compliance lead is expected to fix technical problems and the engineers are expected to produce paperwork.

Evidence is more than a screenshot

Precision matters here. Evidence in this discipline is data with a known source, a timestamp, a collection method, an associated test and a freshness rule. When evidence is older than its rule allows, it counts as missing, not as “nearly fine”. A control is also unproven if its supporting sign-off lapsed even when the export looks recent.

Where a failure is genuine, it can only be covered by a live exception that names the exact failing resources. Once the exception expires, the failure is back on the books. A client who renews the same exception without a compensating safeguard is, in the Atlas’s words, renewing to green, and a consultant should point that out politely and early.

The first-year workload

The Atlas highlights four recurring jobs that surprise new teams. First, reviewing the assurance reports that vendors provide, including the user-entity controls that a customer is expected to operate on its own side. Second, handling bridge letters, which are statements from a vendor’s management covering the gap between report periods and are never validated by the auditor. Third, completing security questionnaires so each answer cites a control and an evidence reference. Fourth, scoping for the payment card standard, where everything is treated as in scope until shown otherwise.

Planning for these in advance turns a stressful first year into an ordinary one. Our own guidance on structuring a consulting engagement from assessment to enablement applies directly: an assessment should surface these jobs, and enablement should leave the client able to run them alone.

Compliance is not security

A frequent client misconception is that a clean attestation means the environment is safe. The Atlas is firm that a certificate proves agreed controls operated on sampled days, nothing more. It cites the 2014 congressional testimony of a large retailer’s finance chief, who stated that the company had been certified against the payment card standard only months before card data was taken from its stores in late 2013. The point is not to criticise any company but to show why the two goals need separate measurement.

It follows that ComplianceOps and security engineering should work side by side. A reader weighing that relationship may find our consulting guide to integrating security into delivery pipelines useful as the other half of the picture.

Frameworks the client is likely to mention

The Atlas names several. ISO/IEC 27001 certificates last three years, with a lighter check each year in between. SOC 2 is an attestation by a licensed accountant rather than a certification, with observation periods commonly of six, nine or twelve months. Others include the payment card standard, NIST’s control catalogue, the European resilience regulation, NIS2 and a New York cybersecurity rule. A good consultant maps one control to many of these rather than creating a parallel programme for each.

A sensible engagement plan

A thirty, sixty, ninety schedule from the Atlas gives structure. Within thirty days: appoint an owner, draft the register of duties and pick a first framework to tackle. Within sixty: set up collectors and tests for the top ten controls and open the exception register. Within ninety: begin the observation period only when every item is fresh, run a deliberate break to confirm that tests catch problems, and map a second framework.

Throughout, avoid the pitfalls the Atlas lists: cleaning up only before audits, running one team per framework, editing evidence instead of replacing it, and tying the library to a single vendor’s format without confirming it can be exported.

None of this constitutes legal or audit advice, and no approach guarantees a favourable assessment. It does give a client something more durable than a binder: a repeatable way of knowing, on any given day, which promises are being kept.

Kabir Malhotra