Compliance calendar

Compliance Calendar

Generate a 12-month recurring-task compliance calendar from the cadence catalog in cadence-catalog.yaml (same directory as this file). The calendar is a planning deliverable, not live workflow tracking. Read the catalog before building anything; it is the single source of truth for tasks, cadences, owners, and evidence expectations.

Step 1: Establish scope

Collect these facts from the user (or from documents they provide, such as an export from their GRC platform). Ask only for what is missing; never re-ask for information already given.

1. Frameworks in scope. One or more of SOC 2, ISO 27001, HIPAA. GDPR may also be noted; it activates the privacy tasks.
2. SOC 2 Trust Services Categories, if SOC 2 is in scope. Security is always included. Ask whether Availability, Confidentiality, Processing Integrity, or Privacy are also in scope.
3. Period start month. Anchor the calendar to the start of the audit observation period when one exists; otherwise the upcoming month. Month 1 of the calendar is this month.
4. Policy list, if available. Each policy becomes one annual review-and-reapprove task. If no list is supplied, use the default_policies set in the catalog (15 standard policies).
5. Adjustments. Any tasks the client already runs at a different cadence (for example monthly access reviews), tasks to add, or tasks to drop. Honor the stricter of the catalog default and the client's own policy; never schedule a task less often than their policy states.

Step 2: Filter the catalog

Include a task only when both conditions hold:

1. Its frameworks list intersects the frameworks in scope.
2. Its scope_gate is active:

Gate	Active when
always	always
availability	Availability category scoped (SOC 2)
confidentiality	Confidentiality category scoped (SOC 2)
processing_integrity	Processing Integrity category scoped (SOC 2)
privacy	Privacy category scoped, or GDPR in scope
phi	HIPAA in scope
eu_data	GDPR in scope

Then add one annual review task per policy from Step 1 (title: "Review and re-approve: [policy name]"), using each policy's month_offset from the catalog's default_policies block, or offset 1 if unknown. Apply any user adjustments last, and note every deviation from catalog defaults in the output's assumptions section.

Step 3: Place tasks on the 12-month grid

Months are numbered 1 to 12 from the period start. month_offset in the catalog is 0-based (offset 0 = month 1).

Frequency	Placement
monthly	every month
quarterly	4 occurrences starting at (month_offset % 3) + 1, then every 3 months
semiannual	month_offset + 1 and month_offset + 7
annual	once, at month_offset + 1
continuous	not on the grid; list in an "Always-on" section
event_driven	not on the grid; list in an "Event-driven" section

The offsets exist to spread annual load across the year: risk assessment early, penetration test around month 9 so there is runway to remediate and retest before the period ends, performance evaluations at year-end. Preserve that spread. If the user's audit window compresses things (for example a 6-month Type I runway), rebalance deliberately and say so.

Step 4: Render the calendar

Produce a single markdown document with these sections, in order.

1. Header. Organization name (if given), frameworks and categories in scope, period covered (month-year to month-year), generation date, and a short assumptions list (policy set used, any cadence adjustments, anything excluded and why).

2. By-cadence summary. One table per cadence tier (Monthly, Quarterly, Semiannual, Annual), columns: Task, Domain, Owner, Evidence to retain, Months. Example:

### Quarterly

| Task | Domain | Owner | Evidence to retain | Months |
|---|---|---|---|---|
| User access review (all in-scope systems) | Access | Client system owners | Signed review record per system + tickets for removals | Mar, Jun, Sep, Dec |

3. Month-by-month calendar. One ### Month N: [Month Year] heading per month, each with a table: Task, Cadence, Owner, Evidence to retain. Every occurrence from Step 3 appears under its month. A quarterly task therefore appears four times across the document. Keep months with only monthly tasks short rather than padding them.

4. Always-on obligations. Bullet list of continuous tasks with the evidence expectation (for example: monitoring and alerting operational throughout the period). These have no due date; the auditor tests that they ran the whole period.

5. Event-driven obligations. Bullet list of event_driven tasks with their trigger and deadline (for example: access revoked within the policy SLA per leaver; new-hire training within 30 days of start). Make clear these fire on the event, not the calendar.

6. Load check. A one-line-per-month count of scheduled tasks. If any month carries 3 or more annual tasks on top of the recurring base, flag it and suggest which offsets to shift.

Quality bar

• Use the catalog's control IDs and evidence descriptions as written. Never invent control IDs or framework citations.
• Owner labels stay generic: "Client", "Client engineering", "Consultant", "Joint", "third-party tester". Platform references stay generic: "your GRC platform" (Vanta, Drata, and similar tools are examples, never requirements).
• Evidence phrasing must name a retainable artifact (a signed record, a dated report, a ticket trail), not an activity. "Reviewed access" is not evidence; "signed access-review record per system" is.
• Carry the catalog's scheduling notes into the output where they matter: the penetration test needs remediation runway, access reviews are the most commonly failed control, the annual policy re-approval is the most commonly missed one.
• If the user asks for a format other than markdown (spreadsheet, calendar invites), build the markdown version first as the source of truth, then convert.

Related skills

• soc2-advisor for what a specific SOC 2 control requires
• hipaa-advisor for HIPAA Security Rule specifics
• gap-assessment to find the gaps before scheduling the routine
• evidence-reviewer to check the artifacts each task produces