The Twelve Month GRC Calendar

Illustration for: The Twelve Month GRC Calendar

Governance, risk and compliance work has a distinctive failure pattern. Nothing much happens for ten months, then a certification audit, a customer assurance questionnaire, a board report and a policy review cycle all arrive in the same fortnight, and a team that was comfortably underemployed in June is working weekends in October.

The work did not increase. It was simply never scheduled, so it arrived when somebody else’s deadline demanded it rather than when the team had capacity. A twelve month calendar is the cheapest intervention available in this discipline and it is the one most consistently skipped, usually because it feels like administration rather than security.

Why the calendar is a control and not a diary

Three things happen when the year is laid out in advance, and none of them are about tidiness.

The work becomes visible as a volume. A team that can see eleven recurring commitments across a year can have an honest conversation about whether it has the capacity for a twelfth. A team that discovers each one as it arrives cannot, and will simply absorb the overload until something is done badly.

Evidence gets produced as a by-product rather than as a scramble. Most audit findings about operating effectiveness are not findings that a control failed, they are findings that nobody can show it ran. A scheduled activity with a scheduled output produces the record automatically.

And dependencies surface early. A penetration test booked three weeks before a certification audit leaves no time to remediate anything it finds, which converts a useful exercise into a list of open findings presented to an auditor. On a calendar, that collision is obvious in January.

What actually belongs on it

The temptation is to list everything, which produces a document nobody maintains. The workable version holds the recurring commitments that have an external deadline, a required output, or a dependency on somebody else’s time.

Assurance and certification

Certification surveillance and recertification audits, with their preparation windows marked separately from the audit dates themselves. Internal audit activity, whether performed in house or bought in. Supplier assurance reviews for the small number of suppliers that genuinely warrant an annual look, which is a different and much shorter list than the one that gets sent a questionnaire.

Testing

Penetration testing, scheduled far enough ahead of any audit or major release that findings can be treated rather than merely recorded. Vulnerability scanning cadence, which is continuous rather than an event but still needs a scheduled review of what the scanning found. Disaster recovery and backup restoration tests, which this series has argued repeatedly are worthless as documents and valuable only as exercises. And at least one incident response exercise, which needs diary commitment from people senior enough that six weeks of notice is the minimum.

Governance

Risk register review at whatever cadence you have committed to, and the honest version of that cadence rather than the one in the policy. Policy review, staggered across the year rather than all in one month, because twenty policies reviewed simultaneously get reviewed by nobody. Board and committee reporting, driven by the dates those bodies actually meet. Management review, if you hold a management system certification, which has specific required inputs that take time to assemble.

Operational rhythm

Access reviews, which are more effective quarterly and by exception than annually and by list. Business continuity plan updates following any significant organisational change. Awareness and phishing simulation activity, spread rather than clustered. And the training obligations that carry individual consequences, including professional continuing development where the team holds registrations.

Diagram of a twelve month cycle showing where the recurring commitments sit

A workable shape for the year. The point is not these exact months, it is that the load is deliberately spread and the dependencies run in the right order.

Sequencing matters more than distribution

Spreading the work evenly is the obvious goal and it is the lesser one. The more valuable property is that activities happen in an order where each one has something to feed on.

The risk register review should precede the audit planning, because what you assess should follow what you are worried about. Penetration testing should precede any certification audit by a clear quarter, so that findings have a remediation window. Business impact analysis should precede recovery testing, because you cannot test against objectives that have not been set. Supplier reviews should precede contract renewal dates, which sounds obvious and is almost never true in practice, because renewal dates live with procurement and review dates live with security.

Getting the order right converts a calendar from a workload spreader into something that improves the quality of each activity.

Building one that survives the year

The version that lasts has four properties, and they are all about lowering maintenance cost.

Every entry has a named owner rather than a team name. A calendar owned by security is a calendar owned by nobody in particular.

Every entry has a defined output. Not an activity but an artefact, because an activity without an artefact cannot be evidenced and will quietly stop happening.

Preparation time is scheduled separately from the event. An audit on 14 October is not a diary entry on 14 October, it is a preparation block in September and an event in October. This single change removes most of the panic.

And it lives somewhere the team already looks. A calendar in a document nobody opens is a plan, not a calendar. Whatever your team uses for actual scheduling is where it belongs, with reminders that fire early enough to act on.

What to do when the calendar is already impossible

Occasionally the exercise of building it produces the conclusion that the committed work does not fit the available people. That is not a failure of the calendar, it is the calendar doing the most useful thing it can do.

The honest responses are to reduce the commitments, to buy capacity for the peaks, or to accept a lower assurance level in a documented way. All three are legitimate. What is not legitimate is keeping the commitments, keeping the resourcing, and hoping, because that resolves itself as a missed deadline or a control that ran on paper only.

Take that conclusion to whoever owns the budget with the calendar attached. A capacity argument backed by a dated list of commitments is considerably more persuasive than one backed by a general sense of pressure.

The honest counterarguments

Annual planning is obsolete in a fast-moving environment

The objection has force against detailed annual project plans and much less against recurring obligations. Certification audits, policy reviews and regulatory reporting dates do not move because the threat landscape did. The calendar covers the predictable portion of the work precisely so the unpredictable portion has room, which is the opposite of rigidity.

It encourages compliance theatre

It can, if the calendar becomes the objective. The mitigation is that every entry produces a decision or a change rather than a document. A risk review that changes no ratings and an access review that removes no access are both signals that the activity has become ceremonial, and both are visible precisely because they are scheduled and observed.

The team already knows what is coming

Some do. The test is not whether the knowledge exists but whether it exists in more than one person’s head and whether the preparation time is protected. Knowledge in one head is a continuity risk, and unprotected preparation time is the mechanism by which everything ends up in the fortnight before the audit.

Common mistakes

Scheduling the audit and not the preparation, which is the single most common version of this failure.

Reviewing every policy in the same month, which guarantees superficial review.

Booking penetration testing after the audit is scheduled rather than before, leaving no remediation window.

Building the calendar in a spreadsheet that is never opened again after February.

Treating the calendar as the security programme. It is the recurring portion of it, and the improvement work sits alongside rather than inside it.

Where to start

List every commitment in the last twelve months that had an external deadline, then mark which ones you knew about more than a month in advance. The gap between those two lists is the size of the problem.

Then put next year’s known dates in the shared calendar, with a preparation block ahead of each, before anything else is booked. It takes an afternoon, it costs nothing, and it is the difference between a programme that runs to a plan and one that runs to whoever shouted most recently.