Compliance Calendar Template: Tracking Recurring Security and Regulatory Deadlines

Security and compliance teams miss recurring deadlines not because the obligations are hard but because they are scattered across regulators, auditors, contracts and internal policies with nobody holding the whole list. A compliance calendar puts every recurring obligation, its owner, its evidence and its lead time in one governed place. This template gives you policy statements for running the calendar and a fill-in calendar table seeded with illustrative entries, from SWIFT CSP attestation and PCI DSS activities to SEC disclosure, NIS2 incident reporting windows and non-human identity (NHI) credential rotation and access review cycles. It is written for GRC leads, compliance managers and CISOs. Confirm every date against the current primary source and your own contracts before relying on it.

How to use this template

• Replace text in square brackets, such as [Organisation], [GRC team] and [calendar tool], with your own terms.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where exceptions may be justified.
• Delete the illustrative calendar rows in section 4.3 that do not apply to you and add your own. The rows show the shape of an entry, not a complete list of your obligations.
• Dates and frequencies change: regulators update rules, standards are reissued and contracts are renegotiated. Every row needs a source and a "last verified" date.
• Link this policy to your policy lifecycle process so that the calendar itself is reviewed and approved like any other governed document. See the Policy Lifecycle Management Guide.

1. Purpose

This policy establishes the compliance calendar as [Organisation]'s single register of recurring security, privacy and regulatory obligations. It ensures that each obligation has an owner, a due date, a lead time and defined evidence, so that attestations, assessments, filings, reviews and rotations are completed on time and can be proven to auditors, regulators, customers and the [board or risk committee].

2. Scope

This policy applies to all recurring obligations that arise from:

• Laws and regulations that apply to [Organisation] or its regulated entities, including incident reporting and disclosure requirements.
• Industry schemes and standards [Organisation] participates in, such as PCI DSS or the SWIFT Customer Security Programme.
• Assurance reports and certifications, such as SOC 2 and ISO/IEC 27001.
• Contracts with customers, suppliers, insurers and financial counterparties that impose security reporting, testing or notification duties.
• Internal policies that set review, testing, training, access review and credential rotation frequencies, including those covering non-human identities.

It applies to all [Organisation] entities, functions and individuals assigned as owners of calendar obligations.

3. Roles and responsibilities

• [Board or risk committee]: approves this policy and receives quarterly reporting on upcoming and missed obligations.
• [Chief Information Security Officer / Head of Compliance]: owns this policy and is accountable for the completeness of the calendar.
• [GRC team]: maintains the calendar, issues reminders, tracks status, verifies sources and reports metrics.
• Obligation owners: complete each obligation by its due date, provide evidence and flag risks of delay.
• [Legal and regulatory affairs]: identifies new and changed legal obligations and confirms dates and interpretations.
• [IAM team]: owns access review and NHI credential rotation entries and the evidence for them.
• [Procurement and contract management]: supplies contractual security obligations for inclusion.

4. Policy statements

4.1 Maintaining the calendar

1. [Organisation] must maintain one compliance calendar in [calendar tool or GRC platform]. Local calendars may exist but must be synchronised with it.
2. Each entry must record: obligation, source (law, standard, contract or policy with clause), frequency, due date or trigger, lead time, owner, deputy, evidence required, recipient (regulator, auditor, customer, internal), status and last verified date.
3. Event-driven obligations, such as incident notification windows, must be recorded as triggers with their clock-start condition and deadlines, and linked to the [incident response plan].
4. New or changed obligations identified through regulatory change management, contract review or policy updates must be added within [10 working days].
5. The source for every fixed date must be checked against the primary source at least [annually] and whenever the source is updated.

4.2 Planning and execution

1. Owners must receive reminders at [90, 30 and 7 days] before each due date, or at the lead time set for the entry if longer.
2. Obligations requiring external parties, such as independent assessors or auditors, must be scheduled at least [one quarter] before the due date.
3. Evidence must be stored in [evidence repository], linked to the calendar entry and retained for [retention period].
4. Owners must report any expected delay to [GRC team] as soon as it is known; [GRC team] must escalate expected misses on regulatory obligations to [CISO / Head of Compliance] within [2 working days].

4.3 Calendar entries (fill-in table with illustrative examples)

The rows below are examples to show the level of detail expected. Keep the ones that apply, confirm them against the source, and set your own owners and lead times.

4.4 Non-human identity cycles

1. Access review and rotation entries must cover non-human identities as well as people, including service accounts, API keys, tokens, certificates, OAuth integrations and AI agents.
2. Where a platform supports short-lived or federated credentials, the calendar entry should track migration away from static secrets rather than a rotation date.
3. Each NHI review must confirm owner, purpose, permissions and last use, and must revoke credentials that are unused for [X] days. See the Secrets Rotation Runbook Template and the Access Reviews Guide.

5. Exceptions

A missed or deferred obligation is an exception. Owners must request it before the due date where possible, stating the reason, the risk, any compensating controls and a new completion date. Exceptions must be approved by [approver] and recorded against the calendar entry. Exceptions cannot defer regulatory deadlines set in law; for those, [Legal] must be consulted immediately. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

[GRC team] must report monthly to [CISO / Head of Compliance] and quarterly to [board or risk committee] on:

• Obligations completed on time as a percentage of those due (target [100 per cent] for regulatory items).
• Obligations due in the next 90 days and their status.
• Missed or deferred obligations, with reasons and remediation.
• Entries whose source has not been verified within the required period.
• NHI access review completion and the number of credentials past their rotation date.

Internal audit should test the completeness of the calendar against regulatory, contractual and policy sources at least [annually]. Failure by owners to meet obligations may be handled under [performance or disciplinary procedure].

7. Review and approval

This policy is owned by [policy owner], approved by [board or risk committee] and reviewed at least annually, or sooner after a change in applicable regulation, a new certification or scheme, a merger or acquisition, or a missed regulatory deadline.

Implementation guidance

1. Collect sources first: list the regulations, schemes, certifications, contracts and internal policies in scope before adding any dates. Regulatory change management feeds this list; see the Regulatory Change Management Guide.
2. Verify each date at the primary source: for example, Swift's own CSP pages for the attestation window, the SEC's adopting release for Item 1.05 and Item 106, and the EU Official Journal plus national transposition law for NIS2. Record the URL and date checked in the entry.
3. Separate fixed dates from triggers: annual and quarterly items go on the calendar; incident reporting clocks belong in the incident response plan with a link from the calendar, because they start on an event, not a date.
4. Set lead times backwards from the due date: SWIFT independent assessments, PCI assessments and SOC 2 fieldwork need assessor availability months in advance.
5. Spread internal reviews: avoid bunching policy reviews and access reviews into December alongside SWIFT attestation and year-end audit work.
6. Automate NHI entries: drive rotation and expiry reminders from your secrets manager and certificate inventory rather than manual dates, so the calendar shows exceptions instead of thousands of rows. See the Machine Identity, PKI and Certificate Lifecycle Guide.
7. Pilot, then scale: run the calendar for one quarter with a single regulated entity, check that reminders, evidence links and reporting work, then add other entities.

Framework anchors: NIST CSF 2.0 GV.OC-03 (legal, regulatory and contractual requirements are understood and managed) and NIST SP 800-53 PM-14 (testing, training and monitoring plans are developed and executed). For scheme detail see the SWIFT Customer Security Programme (CSP) Guide, the PCI DSS Readiness Checklist, the NIS2 Directive Guide and the SEC Cybersecurity Disclosure Rules Guide.

Sources for the illustrative dates: Swift: CSP security controls and attestation; SEC: cybersecurity disclosure rules adopting release; EUR-Lex: Directive (EU) 2022/2555 (NIS2); EUR-Lex: Regulation (EU) 2022/2554 (DORA); NIST: SP 800-53 Rev. 5.

This template is provided for guidance and must be adapted to your organisation. It summarises recurring obligations as illustrative examples and is not legal advice. Related NHI Mgmt Group resources: Policy Lifecycle Management Guide · Security Policy Framework Guide · Compliance Automation Guide · DORA and NIS2 Overlap Mapping Guide