A Compliance Calendar That Reflects What Actually Recurs

Direct answer: Roughly fifteen things recur in a mature compliance programme, and each one is only useful if it produces a dated artefact with a named owner. Monthly items are access and vulnerability work. Quarterly items are reviews: vendors, policies, risk. Annual items are the expensive ones: penetration test, training, recovery testing, risk assessment refresh, and the audit itself. A calendar without owners and artefacts is a list of intentions.

Why most compliance calendars fail

The usual version is a spreadsheet with dates, built during readiness, never opened again. It fails for a specific reason: it records when something is due but not who does it, what it produces, or where that artefact goes. When the date arrives, nobody is accountable and there is nothing to file, so the entry gets moved rather than done.

A calendar entry that works has four parts. What the activity is, who owns it by name, what artefact it produces, and which controls that artefact evidences. The last part is what turns a chore into evidence.

Monthly

Access review of privileged systems. Not every system every month, but production, cloud console and identity provider are worth a monthly pass at most companies, with the full review quarterly. Produces: a dated record naming the reviewer, the accounts examined, and what changed.

Joiner and leaver evidence. Produced per event rather than on a schedule, but reviewed monthly to catch anything missed. Produces: provisioning and deprovisioning records with timestamps.

Vulnerability scan triage. The scan may be continuous. The triage is the control. Produces: findings with severity, owner, and either a fix with a date or an accepted risk with a rationale.

Backup verification. Confirming backups completed is monthly. Confirming they restore is annual and different. Produces: backup job records with failures explained.

Quarterly

Full user access review. Every system in scope, including the ones nobody thinks of, like the billing platform and the analytics tool with customer data in it. Produces: the review record, plus the tickets for revocations that came out of it.

Vendor and subprocessor review. Which vendors touch what data, tiered by that rather than by spend. Reports collected where the vendor claims one. Produces: an updated register with report expiry dates.

Policy review. Not every policy every quarter, but on a rotation so each is reviewed annually and the reviews are spread. Produces: version history and a re-approval record.

Risk register review. Owners confirmed, treatments progressed, new risks added from incidents and changes. Produces: an updated register showing movement rather than an identical copy of last quarter.

An exercise. A tabletop, a failover test, or a restore. Rotating the type across the year covers more ground than repeating one. Produces: an after-action record with what broke.

Annual

Penetration test. Scoped to what customers ask about, with retesting of the findings. The retest is the part that turns a report into evidence of remediation. Produces: the report, the remediation record, and the retest.

Security awareness training. Everyone, with completion tracking, including the people who joined mid-year. Produces: completion records by person and date.

Risk assessment refresh. The full methodology, not the quarterly register review. Produces: the assessment document and whatever it changes in the register.

Business continuity and disaster recovery test. An actual restore into an actual environment. Produces: the test record, the recovery time achieved, and the gaps found.

Internal audit. Required for ISO 27001, and a good idea regardless. Produces: findings and corrective actions, which the certification body will look at.

Management review. Also an ISO requirement, and the one most often faked. Produces: minutes showing leadership actually considered the ISMS and made decisions.

The audit or surveillance cycle itself. Fieldwork, sampling, evidence requests, and the report. Produces: the report, and the exception list that becomes next year's first priority.

Framework-specific additions

ISO 27001 adds the internal audit and management review above, plus Statement of Applicability maintenance whenever scope changes. PCI DSS adds quarterly external scanning by an approved vendor and annual attestation. HIPAA and PHIPA add workforce training with specific content and a documented risk analysis. Quebec Law 25 and PIPEDA add privacy impact assessments triggered by projects rather than dates, which is why they get missed.

Making it survive contact with a real year

Put the artefact, not the activity, in the calendar entry. "Q3 access review" is a task. "Q3 access review record filed against CC6.2 and A.5.18, owner Priya, due 30 September" is an obligation with a shape.

Schedule the annual items early in the cycle rather than late. A penetration test in month eleven leaves no room to remediate and retest before the period ends, and the finding you cannot close becomes an exception.

Review the calendar itself quarterly. Cadences drift as the company changes, and a calendar that no longer matches your system description is worse than none, because the description is what the auditor holds you to.

If nobody internally has the calendar as an actual job, it will slip, and it will slip invisibly. That is the specific gap an ongoing retainer exists to close: the cadence is operated on a schedule that is somebody's responsibility, and the artefacts land against the controls as they are produced.

One activity, several controls

Companies running two frameworks often build two calendars, and then perform the same activity twice with slightly different paperwork. That is a waste, and it is also a risk, because two access review records from the same quarter that disagree with each other is a worse position than one.

The fix is to make the artefact the unit rather than the framework. A single quarterly access review, performed once across every in-scope system, with a dated record naming the reviewer and the changes made, satisfies SOC 2 CC6.2 and CC6.3, ISO 27001 A.5.18, and the PCI DSS requirement for reviewing access at least every six months. You produce it once and reference it three times. The same logic applies to the annual penetration test, the training completion records, the vendor register, and the incident response exercise.

Where it does not apply is anywhere the frameworks disagree on frequency or content. PCI DSS wants quarterly external scanning by an approved scanning vendor, which your internal tooling does not satisfy. ISO 27001 wants a management review with decisions recorded, and no SOC 2 activity produces that. Build the shared calendar first, then add the framework-specific items on top.

The items no calendar catches

Date-driven items are the easy half. The obligations that get missed are the ones triggered by an event, because nothing on a calendar fires when the event happens.

A new subprocessor with access to customer data triggers a vendor assessment, a register update, a system description change, and under some contracts a customer notification with a notice period attached. A significant infrastructure migration triggers a system description review and often a scope conversation with your auditor. A new product handling customer data triggers a scoping decision that has to be made deliberately rather than by default. A new jurisdiction, whether that is a hire in another country or a customer in Quebec, triggers a privacy assessment. An incident triggers the response process, a post-incident record, and a risk register entry.

The way to catch these is not another calendar entry. It is a trigger list attached to processes that already exist: a question in the vendor procurement flow, a checkbox in the architecture review template, an item in the new-hire-in-a-new-country checklist that HR already runs. Compliance work that lives inside a process somebody already performs gets done. Compliance work that depends on somebody remembering an obligation does not.

What happens when you miss one

Not all misses are equal, and treating them as equal wastes effort on the recoverable ones and panic on the rest.

Some are genuinely recoverable. A policy review performed a fortnight late is still a policy review. A vendor register updated in the following month is fine, and a backup verification run on the eighth rather than the first is not a finding.

Some are not recoverable at all, and this is the category worth understanding before you need it. A quarterly access review that was never performed cannot be performed retroactively, because the point of the control is that somebody looked at the access position as it stood at that time. Running it in December for the quarter that ended in June produces a document with a December date and an obvious story. Log data that has aged past your retention window is gone. Training that somebody left the company without completing cannot be completed.

When you find an unrecoverable miss, the correct move is to document it honestly: what was missed, when it was discovered, why it happened, and what changed so it does not recur. Auditors see missed control instances constantly. What separates a mild exception from a serious one is whether management found it themselves and responded, or whether the auditor found it and management had no idea. Backdating is the one response that turns an exception into a genuine problem, and it is easier to detect than people assume, because document metadata, ticket timestamps, and log records rarely agree with a fabricated date.

How much time this actually takes

Budgeting the calendar in hours makes it real. For a company of thirty to eighty people running one framework, the monthly items are usually two to four hours in total, most of it access and vulnerability triage. The quarterly block is a day to a day and a half, because the full access review is genuinely tedious and the vendor review requires chasing people. The annual items are the lumpy ones: coordinating a penetration test and its retest, running a restore test properly, and refreshing the risk assessment together consume a couple of weeks of somebody's attention spread across the year, plus the audit itself.

Averaged out, that is roughly two to five hours a week outside audit periods. It is not a full-time job and it is not nothing, and the reason it slips is that it sits in the gap between too small to hire for and too large to absorb invisibly.

When you do not need us for this

Plenty of companies should run their own calendar, and we will say so on the call.

If you have somebody internal who owns security as a named part of their role, with the seniority to make an engineering lead produce evidence, you do not need an outside party operating your cadence. Buy a couple of hours of review a quarter if you want a second pair of eyes, or nothing at all. The calendar is not difficult work, it is work that requires a specific person to be accountable for it, and if you have that person the main value we could add is redundancy.

If you are pre-audit and building the programme for the first time, the calendar is not the thing to buy either. Get the controls designed so that they produce evidence, and the cadence follows from the design. A calendar built before the controls exist is a list of intentions, which is where this article started.

If you are running one framework, have fewer than twenty people, and the whole environment is one cloud account and one identity provider, a spreadsheet with owners and a shared folder is genuinely sufficient. Tooling and retainers both start earning their keep when the number of systems, people, and frameworks makes the tracking itself the hard part rather than the work. Our free Workspace will hold the register and the artefacts in the meantime, and if you later want the cadence operated by somebody whose job it is, that is what the compliance engagements cover.