Growing businesses meet the word ComplianceOps in sales calls, vendor questionnaires and board decks, usually without anyone stopping to explain it. Ten of the most frequent queries follow, each answered briefly and with care. This is general information rather than legal counsel, intended to give you vocabulary for sharper conversations with your own advisers and suppliers.
What does ComplianceOps actually mean?
It describes handling compliance as an ongoing operation rather than a yearly event. Under this approach an organisation keeps a single library of controls, links each control to every standard that cares about it, collects proof on a schedule, allows only time-limited exceptions, and answers audit requests from records it already holds. The Ops Atlas sets this out in its entry on ComplianceOps, where it adds that the name is a recent coinage, driven mainly by software sellers, even though the underlying habits are much older.
Is “SOC 2 certified” the right phrase?
Strictly, no. A SOC 2 report is an attestation issued by a licensed accounting professional after examining controls. It is not a certificate. A Type 2 report covers a window of time, which the Atlas says is generally six, nine or twelve months. ISO/IEC 27001, by contrast, is a certification, with a three-year cycle and annual surveillance visits in between. Using the right word in a contract or a sales page keeps you out of avoidable disputes.
Does passing an audit mean we are secure?
No, and the Atlas is direct about it. An assessment shows that agreed controls operated on the days that were sampled. It does not prove the controls were the right ones, or that they kept working in between. The Atlas points to a well-known 2013 retail breach where a recent card-industry assessment had been passed, yet payment data was still taken. Treat compliance as a floor you can demonstrate, not as a guarantee.
What counts as good evidence?
A record that states its origin, the time it was captured, how it was gathered, which test judged it and how long it remains valid. If that last clock runs out, the Atlas treats the evidence as absent. That feels harsh until you consider that an auditor will make the same call.
How often is “continuous” monitoring?
Not every second. The American standards agency NIST uses the word to mean often enough to support risk-based decisions. A control that changes weekly deserves weekly attention; one that changes once a year does not need a live feed.
What goes wrong most often?
- Cleaning up just before an audit and letting things slip afterwards.
- Having a separate team for each standard, all asking engineers the same thing.
- Renewing expired exceptions without adding any compensating safeguard.
- Editing old records instead of adding a labelled replacement.
- Writing tests that check whether a policy exists rather than whether it is enforced.
Where should a small company begin?
Appoint one owner, list the obligations you genuinely have, and choose a single framework to run properly before adding another. The Atlas suggests that by about day ninety you should have collection and tests running for your most important controls, plus a second framework mapped onto the same library. Before then, avoid starting any official evidence period until your collectors are connected and nothing is stale.
If you are building a services roadmap at the same time, the guidance in our overview of a digital services roadmap for new clients makes a useful companion, since compliance milestones fit naturally into any onboarding plan. For a broader look at structuring priorities, see our write-up on mapping out digital growth in stages.
Do automated tools replace the auditor?
They change what gets sampled rather than removing sampling. With automated collection, the auditor can look at a richer set of records and focus on the exceptions. The Atlas also cautions against saving a generated summary as proof that a control ran; a fluent paragraph is not evidence of an event.
Which tools exist?
The Atlas names several: commercial platforms such as Vanta and Drata for gathering evidence across frameworks, along with cloud-native policy services and open-source scanners. It also advises checking that your control library can be exported before you commit, so that you are not locked into one supplier’s data model.
Who should own all this inside a company?
One named person, ideally with a deputy, and a clear owner for every individual requirement. Ownership by committee tends to mean ownership by nobody. In smaller firms the role often sits alongside finance or engineering management at first, then grows into its own function once the number of frameworks and customer questionnaires starts to crowd out other work. What matters is that when a control fails, there is no debate about whose job it is to notice and respond.
It also helps to agree early where the boundaries lie. Deciding how much risk the company will accept, handling individual privacy requests, building the technical safeguards and giving legal opinions all sit with other people. The compliance owner’s job is the proving, and keeping that scope tight stops the role from turning into a catch-all.
One closing thought
The most useful single question to ask any team about a control is a plain one: how would we know if this stopped working? If the answer involves a dated record and a named owner, you are doing the work. If it involves hope, you have found your first task.
