Most security teams have a three-year strategy and a budget spreadsheet, but no operating calendar that tells them what has to happen in which month for the plan to be funded, reported, audited and renewed on time. The result is a scramble every year: budget bids written after finance has closed submissions, board papers drafted the week before the meeting, audits that collide with major rollouts, and tool contracts that auto-renew because nobody saw the notice period. This guide turns strategy into a twelve-month cycle: the planning, budget, board reporting, assurance, regulatory filing and renewal events, when each falls, who owns it and what it produces. It is written for CISOs, security programme managers and governance leads in organisations of any size. Strategy content lives in the Security Strategy and Roadmap Guide and budget method in the Security Budget and Investment Planning Guide; this page covers the calendar that connects them.
Key takeaways
- Anchor the calendar to the financial year. Work backwards from the finance submission deadline and the board meeting dates, not from the security team's own priorities.
- Run four repeating loops. Annual planning, quarterly reporting, monthly operations review and event-driven change each have a fixed slot, an owner and a defined output.
- Put external dates in first. Regulatory filings, certification audits, insurance renewals and major contract notice periods are immovable; schedule internal work around them.
- Plan capacity, not just projects. Audits, exercises, renewals and peak business periods consume the same people who deliver change, so the plan must show both on one timeline.
- Close the year with evidence. A year-end review that records what was delivered, what slipped and which risks were accepted becomes the first input to next year's plan.
What an annual security plan is and is not
The annual plan is the one-year slice of the strategy, sized to the approved budget and the team's real capacity. It is narrower than the strategy and more concrete than the roadmap.
| Artefact | Horizon | Answers | Owner | Refresh |
|---|---|---|---|---|
| Security strategy | Three years or more | Where are we going and why | CISO with executive sponsor | Annual re-baseline, or after major change |
| Roadmap | 12 to 36 months | Which initiatives, in which order | CISO and programme lead | Quarterly |
| Annual plan | One financial year | What we deliver this year, by quarter, with which money and people | Programme lead | Approved once; tracked monthly |
| Budget | One financial year | What it costs: run, mandatory change, discretionary change | CISO with finance partner | Annual submission; in-year reforecast |
| Operating calendar | Rolling twelve months | When each governance, assurance and renewal event happens | Security governance or PMO | Monthly |
A good annual plan fits on two pages: the outcomes for the year (tied to the risk register and the target profile), the initiatives that deliver them by quarter, the run commitments that must not slip, the assurance events, and the metrics the board will see. Everything else is supporting detail.
The four planning loops
- Annual loop: strategy re-baseline, risk assessment refresh, budget submission, plan approval and year-end review. Owner: CISO. Output: approved plan and budget. NIST CSF 2.0 GV.OV-01 expects strategy outcomes to be reviewed to inform and adjust direction, and GV.RR-03 expects resources to be allocated in proportion to the risk strategy.
- Quarterly loop: board or committee reporting, roadmap review, budget reforecast and risk register review. The UK Cyber Governance Code of Practice asks boards to require formal reporting on at least a quarterly basis, with suitable metrics and agreed tolerances (action E2).
- Monthly loop: operations review of metrics, project status, exceptions and upcoming calendar events in the next 90 days. Owner: programme lead. Output: decisions and escalations, not slide decks.
- Event-driven loop: major incidents, acquisitions, new regulation or a material change in threat trigger a plan change outside the cycle. Define in advance who can re-prioritise and how much budget can move without a new approval.
The governance forums that run these loops are covered in the Security Governance Committee Charter Template and Security Steering Committee vs Board Risk Committee.
The twelve-month operating calendar
The calendar below uses months relative to the start of the financial year (M1 is the first month). Shift it to match your organisation: many budget cycles require submissions three to five months before year start, so the planning work for next year sits in the second half of this year.
| Month | Planning and budget | Board and governance | Assurance and regulatory | Contracts and capacity |
|---|---|---|---|---|
| M1 | Publish the approved plan; set quarterly milestones and owners | Communicate the plan to executive stakeholders | Confirm the year's audit and testing schedule with auditors | Load renewal dates and notice periods into the calendar |
| M2 | Start Q1 initiatives; lock resourcing | Monthly operations review | Plan the annual risk assessment refresh | Review contracts with notice periods in the next six months |
| M3 | Q1 status and reforecast | Q1 board or committee report | Internal audit fieldwork window (if scheduled) | Check team capacity against Q2 peaks |
| M4 | Adjust Q2 scope from Q1 results | Monthly operations review | Regulatory filings that fall due (see the next section) | Tool overlap review for renewals due in M8 to M10 |
| M5 | Risk assessment refresh | Risk committee review of top risks and appetite | Penetration testing and red team scheduling | Recruitment for next year's approved roles begins |
| M6 | Half-year review; start strategy re-baseline | Q2 board report with half-year outcomes | Incident response exercise (one of at least one per year) | Cyber insurance renewal preparation, if renewal is in H2 |
| M7 | Draft next year's outcomes and initiative list | Executive workshop on priorities | Certification surveillance audit window (if scheduled) | Collect vendor pricing for next year |
| M8 | Cost run base, mandatory change and options | Monthly operations review | Business continuity and recovery testing | Renewal decisions for contracts with long notice periods |
| M9 | Budget submission to finance | Q3 board report; preview next year's ask | Third-party risk reassessments for critical suppliers | Capacity plan for audit season and year-end freeze |
| M10 | Budget challenge and negotiation | Monthly operations review | Awareness training completion push | Finalise renewals and terminations |
| M11 | Approved budget converted into next year's plan | Board approval of strategy refresh and plan | Policy and framework annual review | Change freeze windows agreed with the business |
| M12 | Year-end review: delivered, slipped, accepted risks | Q4 board report and annual summary | Evidence pack for annual attestations and filings | Roll forward the calendar for the next twelve months |
Two rules make the table work. First, nothing moves into a month that already holds an external deadline for the same team. Second, the half-year review in M6 is where next year's planning starts, so the budget submission in M9 is built on evidence rather than written in a fortnight.
Fixed external dates to load first
Before scheduling internal work, add every date the organisation does not control. Examples from primary sources, which apply only where the regulation or contract applies to you:
| Obligation | Who it applies to | Recurring event | Calendar implication |
|---|---|---|---|
| DORA, Regulation (EU) 2022/2554, Article 6(5) | EU financial entities in scope | ICT risk management framework documented and reviewed at least once a year | Schedule the framework review and its approval as a fixed annual event |
| DORA Article 11(6) | EU financial entities in scope | Test ICT business continuity and response and recovery plans at least yearly, and after substantive changes | Book continuity testing in a quiet business period with time to remediate |
| NYDFS 23 NYCRR Part 500 annual compliance notification | Covered Entities regulated by the New York State Department of Financial Services | Certification of Material Compliance or Acknowledgment of Noncompliance for the prior calendar year, filed between 1 January and 15 April, signed by the highest-ranking executive and the CISO | Evidence collection in Q4 and Q1; sign-off meeting before 15 April |
| SEC Form 10-K, Regulation S-K Item 106 | SEC registrants | Annual disclosure of cyber risk management, strategy and governance, including board oversight and management's role | Align the security year-end review with the annual report timetable |
| UK Cyber Governance Code of Practice, actions D2 and E2 | Boards adopting the voluntary Code | At least annual exercising of the incident response and recovery plan; formal cyber reporting at least quarterly | Board exercise once a year; quarterly board report slots |
| Certification and attestation cycles | Organisations holding ISO/IEC 27001 certification or SOC 2 reports | Surveillance or recertification audits and report periods agreed with the certification body or auditor | Fix audit windows at the start of the year and protect them from major change |
Event-driven obligations belong in the plan as capacity reserves rather than dates. For example, SEC registrants must file Form 8-K Item 1.05 generally within four business days of determining that a cyber incident is material, which needs a rehearsed decision process. Obligation detail is covered in the DORA Readiness Checklist, SOC 2 Guide and ISO 27001 Certification Guide. Check current status with the regulator before relying on any date: requirements and deadlines change.
Building the plan: a step-by-step approach
- Collect inputs (M6 to M7): the refreshed risk register, the strategy target profile, last year's delivery record, audit findings with due dates, regulatory changes and business plans for the coming year. See the Risk Register Template.
- Set three to five outcomes: state each as a risk reduced or a capability reached, with a metric and a target (for example, "privileged access for all production administrators through the PAM platform, 95 percent coverage by Q3").
- List run commitments: operations that must continue (monitoring, patching, access reviews, awareness, assurance). These are the floor and are costed first.
- Size change against capacity: estimate effort per initiative in team-weeks, subtract run load, audit support, exercises and leave, and cap the number of major changes landing on any business team per quarter.
- Cost and submit (M8 to M9): build the budget with run, mandatory and discretionary layers and funding options, using the Security Budget Template.
- Reconcile to the approved budget (M11): drop or defer what was not funded, record unfunded risks as accepted with an owner and a review date, and re-sequence the quarters.
- Publish and baseline (M12 to M1): one plan document, one milestone list, one metrics set. Changes after this point go through the event-driven loop.
- Track and adjust: monthly status, quarterly reforecast; if a quarter slips, move scope, not the external dates.
Testing the plan before approval matters as much as testing a control: walk the draft calendar with finance, internal audit, IT operations and the main business units to find collisions (year-end freezes, peak trading, system migrations). Roll back by keeping last year's run plan as the default if approval is delayed, so operations continue while change waits.
Decision guidance
- Calendar year or financial year: follow the financial year for planning and budget; keep calendar-year dates for filings that use them (the NYDFS notification covers the prior calendar year), and show both on the calendar.
- Annual or rolling plan: a fixed annual plan suits stable organisations and those with strict budget cycles; a rolling four-quarter plan suits fast-growing or project-funded organisations. Many combine both: fixed annual outcomes, rolling quarterly initiatives.
- Small organisations: one page, one quarterly review with the leadership team, and an annual risk review. Load the external dates and the main renewals; skip separate committees.
- Large and regulated organisations: separate plans per business unit or region rolled up into a group plan, with a central calendar that holds group-wide assurance and filing dates so units do not schedule over them.
- Multi-entity groups: align the security calendar to the group's slowest budget cycle, and allow local entities to add their own regulatory dates.
- When to re-plan in year: a material incident, an acquisition, a new regulation in scope or a budget cut of more than an agreed threshold. Below the threshold, absorb changes in the quarterly reforecast.
Where identity fits
Identity work has its own recurring dates that belong in the security calendar: access certification campaigns, privileged account reviews, certificate and key expiry, secrets rotation schedules and the clean-up of service accounts, API keys and AI agent credentials. Expiring certificates and forgotten credentials cause outages and incidents when nobody owns the date. Load campaign windows and expiry dates alongside audits and renewals, and give each a named owner. See the Identity Security Programme Guide and the Non-Human Identity (NHI) Guide.
Detection and measurement
- Plan delivery rate: committed milestones delivered in the quarter they were planned, as a percentage. A persistently low rate usually means the plan exceeded capacity.
- Budget variance: actual against approved spend by quarter, split into run and change.
- Calendar adherence: external deadlines met on time (filings, audits, exercises), target 100 percent.
- Renewal control: contracts renewed or terminated by decision before the notice date, rather than by auto-renewal.
- Outcome movement: movement of the three to five outcome metrics against their annual targets, reported quarterly.
- Accepted risk ageing: number of accepted risks past their review date.
Define each metric once and reuse it in every report. See the Security Metrics and KPIs Programme Guide and the Board Cyber Report Template.
Framework mapping
| Framework | Reference | Where the annual cycle supports it |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01, GV.RM-03 | Risk management objectives agreed; cyber risk included in enterprise risk processes |
| NIST CSF 2.0 | GV.RR-03 | Resources allocated in proportion to the risk strategy (budget cycle) |
| NIST CSF 2.0 | GV.OV-01, GV.OV-03 | Strategy outcomes and performance reviewed and adjusted (half-year and year-end reviews) |
| NIST CSF 2.0 | GV.PO-02, ID.IM-01, ID.IM-02 | Policy annual review; improvements from evaluations, tests and exercises |
| NIST SP 800-53 Rev 5 | PM-3, PM-9, PM-14 | Security resources; risk management strategy; testing, training and monitoring plans |
| NIST SP 800-53 Rev 5 | CA-2, CP-4, IR-3, AT-2 | Scheduled control assessments, contingency and incident response testing, awareness training |
| UK Cyber Governance Code of Practice | B3, B4, D2, E2 | Resources allocated; strategy delivering; annual exercising; quarterly reporting |
Common failure patterns
- Planning after the budget closes: the security bid arrives after finance has set envelopes, so the team gets last year's number plus inflation regardless of risk.
- A plan with no capacity model: every initiative is approved, audits and exercises are not counted, and half the milestones slip by Q2.
- Audit collisions: a certification audit lands in the same month as a major platform migration, and both suffer.
- Silent auto-renewals: tools that were due for consolidation renew for another term because the notice period passed unnoticed.
- Board reporting as a scramble: papers are assembled from scratch each quarter with changing metrics, so the board cannot see trends.
- No year-end review: slipped work and accepted risks are not recorded, so next year's plan repeats the same commitments.
Practitioner checklist
- Get the finance submission deadline and board meeting dates for the next eighteen months.
- Load every regulatory filing, certification audit, insurance renewal and contract notice date into one calendar.
- Start next year's planning at the half-year review, not after finance asks.
- Limit the annual plan to three to five outcomes with metrics and targets.
- Cost run commitments first, then mandatory change, then discretionary change with options.
- Model team capacity, including audit support, exercises and freezes, before committing milestones.
- Record unfunded risks as accepted with an owner and review date.
- Report the same defined metrics every quarter.
- Schedule at least one incident response exercise and one continuity test each year.
- Close the year with a written review that becomes the first input to the next plan.
Standards and references
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- UK Government: Cyber Governance Code of Practice
- NCSC: Cyber Security Board Toolkit
- EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act
- New York State Department of Financial Services: Cybersecurity submissions
- US SEC: Cybersecurity risk management, strategy, governance and incident disclosure rules
Related NHI Mgmt Group resources: Security Strategy and Roadmap Guide · Security Budget and Investment Planning Guide · Security Budget Template · Board Cyber Risk Reporting Guide