Compliance Calendar: How to Build and Run One (With Template)

A compliance calendar is a dated schedule of every recurring compliance obligation your company owes, with a named owner, a cadence, and the evidence each one produces. You build one by listing your obligations from your frameworks and contracts, assigning each a cadence and a single owner, then scheduling the task so it fires before the deadline instead of after it. It is the difference between a program that runs all year and one that panics for six weeks before an audit.

What is a compliance calendar?

A compliance calendar is a single schedule of recurring compliance work: access reviews, policy reviews, risk assessments, vendor reassessments, training, backup tests, and evidence refreshes. Each entry carries a cadence, a due date, an owner, and a defined output. Its job is to convert framework requirements that say "periodically" into specific dates somebody is accountable for.

The word calendar is doing real work here. Most compliance obligations are not one-time projects; they are recurring duties that decay quietly. A policy approved in March 2025 is stale by March 2027 whether or not anyone noticed. An access review you ran once proves nothing about the eleven months since. The calendar exists because the requirement is not "do this," it is "do this, repeatedly, and be able to show you did."

What should be on a compliance calendar?

Put anything on the calendar that recurs and produces evidence: access reviews, policy review and staff acknowledgment, risk assessment, vendor reassessments, backup restore tests, security awareness training, incident response tabletops, penetration testing, and evidence refresh cycles. Add contractual and regulatory dates too, like customer security reviews, insurance renewals, and audit windows.

What should not be on it: one-time remediation tasks, anything that belongs in your ticketing system, and vague aspirations with no output. If an item cannot name what artifact it produces when it completes, it is not a calendar item yet. It is a wish.

A worked annual compliance calendar

Here is a realistic recurring set for a 5 to 200 person company running SOC 2, ISO 27001, or HIPAA. Cadences are the common defaults, not a rule handed down by any framework: most requirements say "periodically" and leave the interval to your risk assessment, which means you pick the cadence, write it down, and then actually hold to it. An auditor will hold you to your own stated frequency far more literally than to any external one.

Copy that table into a doc and you have a usable compliance calendar template. Fill in real names in the owner column before you fill in anything else. The names are the part that makes it work.

How do you create a compliance calendar?

Create a compliance calendar in five passes: list your obligations from framework requirements and customer contracts, set a cadence for each based on risk, assign exactly one owner per item, define the evidence each item must produce, then schedule the reminder to land early enough that the work can actually get done before the due date.

The obligation list is the hard part, and it is where most teams underestimate. Your frameworks give you the bulk of it, but contracts add more: a customer MSA may commit you to an annual pen test or a 24-hour breach notice, and those obligations are just as binding as anything in the Trust Services Criteria. Read your top ten customer contracts for security exhibits before you call the list complete. This is the same discipline as obligation tracking: an obligation nobody wrote down is an obligation nobody owns.

On cadence, resist the urge to make everything quarterly because quarterly feels rigorous. A cadence you miss is worse than a slower cadence you hit, because now you have documented evidence of your own noncompliance. Pick intervals you will genuinely sustain with the headcount you have, tie the tighter ones to the systems that actually carry risk, and revisit the whole set once a year.

The scheduling pass has a detail people skip: due date is not reminder date. A quarterly access review across six systems is a day of work for someone who has a real job. If the reminder fires on the due date, the review is already late. Set the trigger two weeks out for anything that takes more than an hour.

Who owns the compliance calendar?

One person owns the calendar itself, usually a compliance lead, head of security, or in smaller companies an ops or finance leader wearing a second hat. That person does not do all the work. They own the schedule, chase the owners, and escalate when items slip. Every individual item then has its own single named owner who does the work and produces the evidence.

The classic failure mode is a calendar nobody owns. It gets built during audit prep by an enthusiastic person, lives in a shared spreadsheet, and is accurate for about ten weeks. Then the enthusiastic person changes roles, the reminders go to a distribution list, and a distribution list is a synonym for nobody. Six months later the access reviews stopped in Q2, the vendor reports expired in Q3, and the evidence in the folder is all from last year's audit period, which means it is worthless for this one.

Two rules prevent most of this. First, a group is never an owner. "Engineering" does not do access reviews; a person does. If your calendar has team names in the owner column, you have a list of intentions. Second, ownership transfers explicitly when people leave. Add it to your offboarding checklist alongside revoking access. If you need a general mechanism for pushing recurring work to a specific human rather than a channel, routing each task to a named owner automatically solves the same problem outside compliance too.

Can you run a compliance calendar in Excel?

Yes, and for a company of fifteen people with one framework, a spreadsheet is often the right call. Excel or Sheets handles a compliance calendar template fine: columns for obligation, cadence, owner, due date, status, and evidence link. It breaks down when the calendar has to prove things, not just list them.

The specific limits show up in order. First, a spreadsheet does not remind anyone, so you bolt on calendar invites, and now you have two systems that drift. Second, it does not hold evidence, so the link column points to a Drive folder where nobody can tell which screenshot came from which quarter. Third, it has no history: when you mark an item complete, the previous state is gone, and "we did this last quarter" becomes an assertion instead of a record. Fourth, cross-framework work gets duplicated, because one quarterly access review satisfies SOC 2 and ISO 27001 at once, but a spreadsheet will happily list it twice and let the two rows disagree.

That third point is the one that costs you in an audit. Auditors sample. They will ask for the Q2 access review specifically, and a spreadsheet cell that says "Done" with no artifact and no date is not evidence. Purpose-built compliance tracking software keeps the schedule, the owner, the completion record, and the artifact in one object with a timestamp, which is what makes an item auditable rather than merely tracked.

How do you make calendar items auditable?

An item is auditable when it produces a dated artifact, tied to a named person, that falls inside the period being examined. Three fields carry it: what was done, who did it, and when. Miss the date and the artifact is unusable; miss the person and you cannot show accountability; miss the artifact and the whole item is just a claim.

Screenshots need visible dates. Exports need to state their generation time. Approvals need a name, not a checkbox. And the artifact has to land inside the audit window, which is the trap in a SOC 2 Type 2: a control tested over a twelve-month period needs evidence spread across that period, so a folder of screenshots all taken in the final week tells the auditor exactly the wrong story. Our guide to audit evidence examples covers what each control type actually needs to show.

The other half of auditable is the link back to controls. A completed quarterly access review is worth more when it is attached to the specific control it satisfies across every framework you run, so one piece of work counts once and is credited everywhere. Automated evidence collection from your cloud and identity systems removes most of the screenshot problem for infrastructure controls, though the human items (policy approvals, training, tabletops) still need a person to close the loop.

Monthly, quarterly, annual: how the rhythm actually feels

A working annual compliance calendar has a shape. Monthly items are light and mostly automated: log reviews, evidence checks, new hire onboarding records. Quarterly is where the real recurring effort sits, mainly access reviews and evidence refresh, and it deserves a scheduled block, not a reminder somebody snoozes. Annual items are the heavyweights (risk assessment, policy review, training, vendor reassessments, internal audit) and the mistake is stacking them all in the same month. Spread them: risk assessment in one quarter, vendor reviews in another, policy review timed so it lands before your audit window opens rather than during it.

Then check the calendar itself once a year. Cadences that never get hit should be honestly lengthened or resourced. Items that produce evidence nobody has ever asked for can go. New obligations from new contracts or a second framework get added. A SOC 2 program that adds ISO 27001 does not double the calendar, because most of the recurring work overlaps; what changes is the internal audit and management review rhythm ISO expects.

None of this certifies you or guarantees an audit outcome. What a calendar does is narrower and more valuable than that: it turns "periodically" into a date, a name, and an artifact, so that when someone asks what you did in Q2, you have an answer instead of an argument.