Who Owns Compliance After the Readiness Project Ends?

Direct answer: Somebody has to own the programme by name after the report is issued, with time protected for it. The realistic options are an internal owner with the job written into their role, a security hire once headcount justifies it, or an external retainer. What fails, reliably, is distributed ownership: compliance assigned to everybody, which means the calendar entries have no name on them and the first busy quarter clears them.

Why this is the decision that matters

Readiness has structure. There is a deadline, a scope, a project plan and usually somebody senior asking about it weekly. Every one of those disappears the day the report lands, and what remains is a set of recurring obligations with no forcing function attached.

The failure is not that people are lazy. It is that the work has no natural deadline until an audit is eight weeks away, and anything without a deadline loses to anything with one. Given a choice between a customer escalation and a quarterly access review, every reasonable person picks the escalation, every time.

Option one: an internal owner

Usually a technical operations lead, an engineering manager, or a founder in smaller companies. This works when three things are true: the responsibility is written into the role rather than assumed, time is genuinely protected for it, and the person has enough authority to make other teams produce evidence.

The honest cost is not zero. Expect somewhere between two and five hours a week outside audit periods, considerably more during fieldwork. If that time is not visibly taken from something else, it is not real, and the programme is being run on the assumption that someone will find slack that does not exist.

The main risk is concentration. When the owner leaves, everything they carried in their head leaves with them, and drift starts immediately. Documenting the cadence rather than living it is the mitigation.

Option two: a hire

A dedicated security or compliance hire is the right answer at a certain size, and companies usually reach it later than they expect. The signals are reasonably clear: more than two frameworks live, a continuous rather than periodic cycle, an enterprise customer base that generates constant security review traffic, and a security roadmap that is genuinely a full-time job rather than a quarterly project.

Before those signals, a full-time hire is usually underemployed on compliance and ends up doing adjacent engineering work, which is fine until the audit arrives and the compliance work has been deprioritised by the same person who owns it.

The other consideration is that a first hire into this role, at a company with no existing security function, has nobody to learn from. They spend their first quarter working out what auditors accept, which is exactly the knowledge that experience buys.

Option three: an external retainer

This is the option we sell, so treat the following with appropriate scepticism, but the argument is straightforward. The work is periodic rather than continuous, it requires knowing what auditors accept rather than knowing your codebase, and it competes badly for attention internally.

It works well when the retainer has a named counterpart inside the company, even a light one. Somebody has to be able to say who owns the vendor list and get an engineer to produce a configuration export. It works badly when it is bought so nobody internally has to think about compliance at all, because evidence requests then sit unanswered and the retainer becomes a chase.

It is the wrong purchase if you have one framework, no audit for two quarters, and someone internal who has done this before. A few hours of advice a quarter is a better fit, and any firm worth hiring will say so.

The hybrid that usually wins

In practice the arrangement that holds up is an internal owner who owns the relationship and the internal chasing, with an external retainer doing the specialist work and holding the calendar. The internal person knows who has the answer. The external one knows what the answer needs to look like.

What that means concretely: your person owns getting the engineer to produce the export, and the retainer owns knowing which export, in what form, against which control, and whether it will survive sampling.

Writing it down

Whichever option you pick, write the ownership into three places. The role description, so it survives a person leaving. The calendar, with a name against every recurring item rather than a team. And the system description, which already names roles and is the document an auditor will hold you to.

The test for whether ownership is real is uncomfortable and useful: name the person who will notice, within a week, that last month's access review did not happen. If you cannot name them, nobody will notice, and you will find out during fieldwork.

If the answer for your company is external, our retainers are scoped from a call and come with a written plan of approach before anything is signed, including where we think work should stay in-house.

The handover is the part everyone skips

Most readiness engagements end with a report, a folder of evidence and a handshake. What they rarely end with is a handover that would survive the readiness firm being unreachable. If you are the internal owner inheriting the programme, the handover you want is not a summary deck. It is a working set: the control matrix with the evidence source named for each control, the actual queries or console paths used to produce each artefact, the naming convention the evidence was filed under, the list of systems that were in scope and, importantly, the ones that were deliberately excluded and why.

That last item causes more trouble than any other. A readiness project makes dozens of small scoping calls: this internal admin tool is out because it holds no customer data, that legacy reporting database is out because it is being decommissioned in Q3. Nobody writes them down, because at the time they were obvious. Nine months later the decommission slipped, the tool now holds exported customer records, and the person who made the call has left. The auditor asks why the system is not in the asset inventory and the honest answer is that nobody remembered there was a decision.

Ask for the exclusion log explicitly. If your readiness partner cannot produce one, reconstruct it yourself in the first fortnight while the reasoning is still recoverable, and put a review date on it.

What the recurring calendar actually contains

Ownership is abstract until you write down the items. For a single-framework SOC 2 programme, the recurring load is roughly this. Quarterly user access reviews across your identity provider, production infrastructure, code repositories, and any system holding customer data, each producing a dated artefact showing who reviewed it and what changed as a result. Quarterly or semi-annual vendor reviews, with the subprocessor list refreshed and any new SOC 2 reports or security questionnaires collected. An annual risk assessment that produces a register with owners and treatment decisions, not a spreadsheet of generic threats. Annual security awareness training with completion records, including for people who joined mid-year. Annual policy review with evidence of approval, which means a date and an approver, not a document with a version number nobody incremented. An annual incident response tabletop with notes on what you learned. Backup restoration testing, at whatever frequency your own policy commits you to, which is the frequency you will be held to.

Add ISO 27001 and you inherit the management system clauses on top: internal audit on a programme, management review with the clause 9.3 inputs, and a corrective action log that shows effectiveness checks. Add HIPAA or PCI DSS and the list grows again, with the added complication that the evidence formats differ even where the underlying control is the same.

The reason to itemise is that the total is what tells you which ownership option you need. Six to eight recurring items is genuinely a few hours a month for someone who has done it before. Twenty-five items across three frameworks with overlapping but non-identical evidence expectations is a job.

Evidence has to live somewhere a stranger can find it

The single most common cause of a painful audit at a company that genuinely did the work is that the evidence is scattered. Access review screenshots in one person's Slack DMs, the vendor list in a spreadsheet on someone's drive, incident notes in a ticket system with no consistent tag, policy approvals in email threads. All of it exists. None of it can be produced in the twenty minutes an auditor is willing to wait during a call.

Set the structure before you need it. One location, one folder per control or per framework requirement, a file naming convention that includes the date and the period covered, and a rule that anything produced for compliance goes there at the moment it is produced rather than being gathered later. Our Workspace is free and does this if you want a purpose-built place, but a well-disciplined shared drive works. What does not work is deciding the structure retroactively, because reconstructing four quarters of access reviews from memory and screenshots is how a genuinely compliant company ends up with an exception.

The test is the same one that applies to ownership: could a competent person who joined last month produce the Q2 access review for production without asking anyone? If not, the evidence is not really filed, it is remembered.

The automation platform is not an owner

Compliance automation tools are useful and we recommend them for most companies at this stage. They are also the most common false answer to the ownership question. A platform monitors configuration, collects some evidence automatically, and produces a dashboard of green and red. What it does not do is decide whether a red item matters, chase the engineer who needs to fix it, write the justification for a control that is intentionally implemented differently, or notice that the vendor list has drifted from reality because nobody has been adding new tools to it.

The specific failure pattern is worth naming. The dashboard shows ninety-something percent compliant for months. Everyone reads that as healthy. During fieldwork it turns out that the remaining items were the ones requiring human judgement, several of them have been red since implementation, and the platform was faithfully reporting that fact to an audience that had stopped reading. Alert fatigue applies to compliance dashboards exactly as it applies to security alerts.

If you buy a platform, someone still has to hold the account, act on what it says, and produce the evidence it cannot collect. Budget for that person. The tooling reduces the hours, it does not remove the name.

What it costs, honestly, in each direction

An internal owner is not free even though the cost does not appear as an invoice. Two to five hours a week outside audit periods, rising to something closer to half-time during fieldwork, is real capacity taken from whatever that person was hired to do. If that person is an engineering manager, you are paying senior engineering rates for work that is mostly coordination and evidence assembly, which is a poor use of the salary but often the right call anyway because they have the authority to make things happen.

A dedicated hire is the most expensive option and the most durable one, and the argument for it strengthens sharply once the security roadmap has work in it beyond compliance: vulnerability management, security review of new features, customer security reviews, incident response readiness.

An external retainer sits between the two. Our fractional CISO engagements start at $3,000 per month, and that number is only meaningful next to what it replaces. If the alternative is a founder losing five hours a week and the programme still slipping, it is straightforward. If the alternative is a competent internal owner who has run two audits already, it is a waste of money and we will say so on the call.

When you should not buy any of this

There are companies for whom the honest answer is to do very little. If you hold one framework, your next audit window opens in more than six months, your environment is small enough that the access review is three systems, and someone internal has been through fieldwork before, then a documented calendar and two hours a month is a complete answer. Buying a retainer at that point purchases reassurance rather than capability.

Similarly, if your report is issued and the deal it was blocking has closed, and you have no pipeline that requires the report to stay current, it is worth asking out loud whether you are recertifying out of momentum. Letting a SOC 2 lapse deliberately, with a decision recorded and a plan to restart when a buyer asks, is a legitimate choice for a company that overbought compliance ahead of demand. It is not a choice we make money from, and it is occasionally the right one.

The case where you should not buy from us specifically is when the work is mostly internal chasing rather than specialist judgement. If your gaps are that three engineers owe you exports and nobody has asked them firmly, an external party makes that worse, not better, because we have no standing to escalate. Fix the internal authority problem first.

Failure modes to watch for in the first year

The quiet quarter. A busy release cycle, a funding round, or an outage absorbs the owner for six weeks and two recurring items slip. Nothing visible happens. The next quarter it is four items, because the missed ones now need catching up alongside the current ones. The mitigation is a monthly ten-minute check that asks only one question: which items were due since we last spoke, and where is the artefact.

The departing owner. Ownership concentrated in one person leaves with that person, and the gap is usually discovered eight weeks before fieldwork. The mitigation is documentation of the cadence and a nominated deputy who has actually run one cycle, not one who has been told they are the deputy.

The reorganisation. Ownership written into a role survives a person leaving but not always a restructure, because the role itself dissolves. Naming the accountability in the system description gives it a second anchor that someone has to consciously change.

Silent scope drift. A new product line, a new cloud region, a new subprocessor handling customer data. Each one is a normal business decision that quietly expands what the report has to cover, and none of them route through compliance by default. The mitigation is a standing item in whatever forum approves new vendors and new infrastructure, asking whether this changes scope.

How auditors probe ownership without asking about it

No auditor asks who owns compliance. They test it indirectly, and the tells are consistent. They ask who performed a specific access review and then check whether that person is the same one named in the system description. They ask for the four quarterly artefacts and look at the dates on them, because three produced in the same week in month eleven tells its own story. They ask what happened after the last incident and whether the risk register changed as a result. They ask who approved the current version of the access control policy and when, then compare that to the review frequency the policy itself commits you to.

Each of those is a question about whether a named person was operating a process across the period, which is precisely what a report is asserting. Companies that fail these are usually companies where the work happened but the accountability floated, so nobody can say with confidence who did what in March.

The practical preparation is to be able to answer, for any recurring control, three plain facts: who did it, when, and where the artefact sits. If you can produce those on a call without going to look, ownership is real. If the answer starts with someone checking a shared drive, you have a filing problem masquerading as a compliance one, and it is worth fixing before fieldwork rather than during it.

If you want the calendar built and operated rather than just described, that is what our retainers cover, and the scoping call includes an honest read on which parts should stay with your own people.