Make the Work Disappear
The goal isn’t to do more security work. It’s to make the necessary work efficient, well-timed, and distributed enough that it barely registers.
October. You know what’s coming.
The ISO surveillance audit is in six weeks. The management review is overdue. Half the access reviews that should have happened quarterly happened once, in February. The risk register hasn’t been touched since the last audit. Three policies are out of date — one references a system you decommissioned in March. Evidence folders are a mess of screenshots with names like final_v3_ACTUAL.png.
For the next six weeks, security will consume every spare hour. The security lead will work weekends. People across the business will get urgent requests they don’t understand. Corners will be cut. Evidence will be assembled retrospectively, with a hope that it will look like it was collected when it should have been. Everyone will be somewhat miserable. The audit will probably pass, because it usually does. And on January 2nd, the cycle will reset.
I described this in Chapter 1 as the annual panic. Here, I want to talk about what to build instead.
Because the annual panic isn’t inevitable. It’s the natural consequence of a programme that defers work until a deadline forces it. Change when and how the work happens, and the panic disappears — not because there’s less work, but because the work was already done by the time anyone thinks to ask for it.
The problem with “security work”
Many people — security professionals included — think of security as a category of work. There’s your real job, and then there’s the security stuff that sits alongside it. The risk assessments, the policy reviews, the access audits, the evidence collection, the vendor assessments. The security work.
This framing is the root of the problem. When security is a separate category, it competes with everything else for time and attention. And it loses, consistently.
So security work gets deferred. Not maliciously. Not lazily. Rationally. There’s always something more urgent, more visible, more consequential-right-now. The access review can wait until next week. Next week becomes next month. Next month becomes “we’ll catch up before the audit.”
The solution isn’t to make security work more important. You can’t out-prioritise product deadlines and customer commitments, and you shouldn’t try. The solution is to make security work so small and embedded in the operational rhythm that it doesn’t feel like a separate category anymore.
Make it disappear. Not the work itself — the friction.
The operational cadence
Here’s what a well-running security programme looks like, week by week.
Daily — almost nothing. Automated checks run: are backups completing? Are vulnerability scans finding anything critical? Has anyone’s access changed in a way that needs review? These produce alerts only when something needs attention. On most days, security produces zero tasks. That’s the goal.
Weekly — a handful of small tasks, distributed to the right people. One person reviews new vulnerability findings and prioritises them. Another completes an access review for a single system — not all systems at once, just the one that’s due this week. Someone else reviews and approves a change request. Each task takes 15–30 minutes. Each person does maybe one or two security tasks per week.
Monthly — slightly larger reviews. The security lead reviews the risk register — not a full reassessment, just a check that nothing has changed materially since last month. A policy or two comes up for review on its natural cycle. Bullet points prepped to brief management. Total time: maybe half a day for the security lead, an hour or two distributed across other staff.
Quarterly — the bigger exercises. A full risk review. An internal audit of a specific area. A vendor reassessment cycle. Management review inputs. These take more time, but they’re planned months in advance, and the data they need has been accumulating all quarter through the daily, weekly, and monthly work. The quarterly review isn’t starting from scratch — it’s summarising what’s already known.
Annually — the surveillance or certification audit. But because everything has been running continuously, “audit preparation” becomes “audit packaging.” The evidence exists. The reviews are current. The risk register is up to date. Instead of six weeks of panic, you need a few days to review and compile what’s already there.
This is the working security operational cadence. It’s not a new idea — anyone who’s run a mature quality management system or a manufacturing line recognises it. Small, frequent actions are more reliable than large, infrequent ones. Distributed work is more sustainable over time than concentrated work. Continuous processes produce better outcomes than batch processes.
The security industry knows this intellectually. The phrase “continuous compliance” appears in every GRC vendor’s marketing. But very few organisations actually operate this way, because building the cadence requires solving three hard problems that many programmes never address.
Hard problem one: generating the right tasks at the right time
The cadence only works if the right tasks appear at the right time, assigned to the right people.
This is harder than it sounds. A typical mid-size organisation might have 150 controls, each with a review cycle (some monthly, some quarterly, some annual). They might have 50 assets needing periodic risk reassessment. 30 vendors needing regular review. 20 policies with review commitments. Dozens of recurring operational tasks — access reviews, backup verification, log reviews, patching cycles, and so on.
That’s hundreds of recurring tasks, each with different frequencies, different owners, different dependencies. Keeping track of what’s due when, and making sure it lands on the right person’s desk at the right time, is itself a full-time job.
Many organisations solve this with calendar reminders and spreadsheet trackers. The security lead maintains a mental model of what’s due and chases people manually. This sort of works until it doesn’t — until the security lead is on holiday, or sick, or overwhelmed. Then tasks slip, and nobody notices until the auditor asks.
The structural solution is what I called in Chapter 6 the connected programme. When controls are connected to their review schedules, their owners, and their evidence requirements, defining actionable tasks becomes easier. The programme knows that Control 47 needs a quarterly review, that it’s owned by your infrastructure lead, and that the last review was 11 weeks ago. The person receiving the task knows what to review, why it matters, and what “done” looks like.
This isn’t about a specific tool. Almost any well-maintained project management system can do it. A calendar with recurring events and detailed descriptions can do it, though it’ll strain. The point is that task definition shouldn’t depend on one person’s memory. It should be a property of the programme itself.
Hard problem two: context-rich handoffs
Chapter 3 described the task assignment problem: a security task lands on someone’s desk and they don’t know what it means, why it matters, or what specifically to do. This is the problem that makes people defer security work. Not because they don’t care, but because figuring out what the task actually requires takes more effort than doing it.
The operational cadence only works if each task carries enough context to be completed without reverse-engineering the intent. This means every task that goes to a non-security person needs:
What to do — not “complete access review” but “review the list of 14 people with access to the production database. Confirm each person still needs access for their current role. Flag anyone who’s changed role, left the company, or whose access level seems excessive.”
Why it matters — not “it’s a security requirement” but “this database contains customer financial data. Incorrect access could expose us to a data breach and a GDPR non-conformity. This review also satisfies ISO 27001 control A.5.18, which the auditor will check in November.”
What “done” looks like — not “let us know when it’s complete” but “confirm or update each person’s access status in the list. Add a note for any changes. When you’re done, mark the task complete — this automatically generates the evidence record for the auditor.”
Who to ask — not silence, but “if you’re unsure whether someone needs access, check with their line manager. If you have questions about the process, contact [name].”
When the task is generated from connected data — linked to the asset, the control, the requirement, the owner — the context writes itself. When it’s generated from someone’s memory, the context is whatever they remember to include, which on a busy day is very little.
The difference in completion rates is dramatic. Add context to the tasks — nothing else — and on-time completion can nearly double. Same people, same workload, same programme. Just better handoffs.
Hard problem three: evidence as a byproduct
This is the one that changes everything, and it’s the least intuitive.
In many programmes, evidence collection is a separate activity from the security work itself. You do the access review. Then, separately, you document that you did the access review. You take a screenshot of the access list. You write a note about what you found. You save it in the evidence folder. You name it something that will make sense to an auditor in six months.
This means the evidence effort is roughly equal to the work effort. You do the thing, then you prove you did the thing. Twice the work, and the proof often looks different from the doing — because the documentation was created after the fact, from memory, under time pressure.
Now consider the alternative. You complete the access review inside a system that records what you did as you do it. The list of people you reviewed is captured. Your decisions for each person are captured. The date and time are captured. The control this review satisfies is captured. The evidence record is created by the act of completing the review, not as a separate step afterward.
The documentation is the doing.
This isn’t magic. It’s design. When the process through which you complete a security task also generates the evidence that you completed it, you eliminate an entire category of work. No more retrospective evidence assembly. No more screenshot folders. No more “I know we did this, I just need to find proof.”
And the evidence is better. It’s contemporaneous — created at the moment of the work, not reconstructed later. It’s consistent — same format every time, because the process defines the format. It’s complete — nothing gets forgotten, because the process captures everything it needs.
The annual panic is largely an evidence problem. The controls were mostly maintained. The reviews mostly happened. But the evidence wasn’t collected along the way, so now you need to prove retroactively that the work was done. That’s the scramble. When evidence is a byproduct, the scramble evaporates.
Policies are a case study in this. Every programme has them. But too many are dead. They describe an idealised process that drifted from reality years ago. They get “reviewed” annually — someone opens the document, changes the date, closes it. The auditor checks that the policy exists and was reviewed, not that it’s accurate.
A living policy is connected to the controls it describes. Your access control policy references your actual access review process, your joiner-mover-leaver process, your privileged access controls. When you change the review cadence — say, quarterly to monthly for critical systems — the policy is flagged for update, because the underlying control changed. The review isn’t fiction. The reviewer can see exactly what’s changed since last time.
That’s evidence as a byproduct applied to documentation. The policy stays alive not because someone remembered to check it before the audit, but because its connection to operational reality is maintained.
The annual wheel
Picture a wheel with twelve spokes, or a circle divided into twelve segments — one per month. On this wheel, plot every recurring security activity your programme requires. Policy reviews. Risk reassessments. Access audits. Vendor reviews. Internal audits. Management reviews. Penetration tests. Business continuity exercises. Training sessions.
Now distribute them. Don’t cluster everything in Q4 because that’s when the audit is. Spread the load. Maybe January is access reviews for critical systems. February is vendor reassessments for tier-1 suppliers. March is a policy review cycle. And so on.
When you can see the full year at once, several things become obvious.
First, the total volume of work is manageable — it just wasn’t being managed. When everything piles up in the three months before the audit, it feels overwhelming. When it’s distributed across twelve months, it’s a steady, predictable workload. Roughly the same total effort, dramatically different experience.
Second, you can anticipate bottlenecks. If the management review is in September and the surveillance audit is in November, you know Q3 is heavier. You can adjust — move some Q3 activities earlier, clear the decks for the things that can’t move.
Third, nothing surprises you. The policy review in March isn’t urgent because it was planned in January. The vendor reassessment in July isn’t a scramble because the questionnaires went out in June. Everything arrives when expected, with time to do it properly.
Fourth — and this matters more than it sounds — you can show the wheel to non-security people. “Here’s what the security programme looks like across the year. Here’s where your team’s contributions fit. Here’s when we’ll need your time and how much.” Clear communication with lead time breeds cooperation. Urgent last-minute requests breed resentment.
The annual wheel isn’t a plan. It’s a rhythm. Plans get abandoned under pressure. Rhythms, once established, sustain themselves.
What manageable feels like
It’s Tuesday. You open your security brief. Two access reviews are due this week — one for the CRM, one for the staging environment. A vulnerability from last week’s scan needs prioritisation. A policy review is coming up next week — you can see it on the horizon, no surprise. None of this is urgent because none of it was deferred. You’ll spend about two hours on security this week. That’s what manageable feels like.
This is the day-to-day reality of a programme built on the operational cadence. Not frantic. Not heroic. Not the kind of thing anyone writes a LinkedIn post about. Just steady, distributed, contextual work that adds up to a programme that mostly runs itself.
The difference between this and the October panic isn’t a different amount of total work. It’s the same work, distributed differently. The access reviews happen. The policies get reviewed. The evidence accumulates. But nobody had to miss their kid’s weekend football match to make it happen.
A note on “continuous compliance”
“Continuous compliance” has become a marketing term, and I want to be precise about what it means here — or at least what I mean by it.
It doesn’t mean automated. Risk assessments require human judgement. Access reviews require someone who understands the business context. Policy reviews require someone who knows both the regulation and the operational reality. The cadence doesn’t replace judgement — it creates conditions for good judgement by giving people the right information at the right time.
It doesn’t mean zero effort. Two hours a week is still two hours. A quarterly risk review still takes a day. What’s eliminated is the spikiness — the annual concentration of deferred work that makes security feel like a burden instead of a routine.
If someone promises you continuous compliance with zero effort, they’re selling you something. Less total effort and dramatically less pain? That’s real — because the effort you save is the retrospective evidence assembly, the duplicated work, the context recreation, and the panic overhead. The core security work stays the same, and actually gets done.
What to do Monday morning
Map your recurring security tasks and their actual frequency. List every review, assessment, and audit your programme requires. Next to each one, write how often it should happen and how often it actually happens. The gap between those two columns is your deferred work — the raw material for October panic. This could take an hour or two, but it can be refreshingly sobering.
Pick one recurring task and build the context into it. Take your next access review or vendor assessment. Before you assign it, write out: what specifically to do, why it matters, what “done” looks like, and who to ask for help. Send it to the person who’ll do it and ask if it’s clear enough. Iterate once. You’ve just built a template you can reuse for every future instance of that task. If you already did this after Chapter 3, take the next task on the list — the move bears repeating, one task at a time, until every recurring task carries its context.
Draw your annual wheel. Twelve months. Every recurring security activity, placed where it should happen — not where it currently clusters. Look at the distribution. If Q4 is twice as heavy as Q2, move what you can — and make sure the new dates land in the owners’ calendars and the owners agree to them, or the wheel is a drawing, not a rhythm.