Security strategy on one page

Scope: objectives to approved page · Who: the officer asked for "the strategy" · Prerequisites: a risk picture and an obligations register · First result: one drafting cycle

1. Why this exists (the failure mode it prevents)#

Two documents get handed over when a board asks for the security strategy, and neither is one.

The first is the roadmap wearing a strategy's cover: tools to buy, projects to run, quarters to run them in. It states no objective and carries no measure, and never says what the organisation will be able to do at the end that it cannot do now. Asked what the money bought, the only answer available is what the money was spent on.

The second is a framework's table of contents. Every clause becomes a heading and every heading a workstream. The result is complete and inert: it describes a standard rather than an organisation, so nothing in it can be prioritised, because everything is equally required.

Both fail in the same three places.

They fail at ISO/IEC 27001:2022 clause 6.2, "Information security objectives and planning to achieve them" ¹. The clause asks for objectives. A Gantt chart is not one, and neither is a control list.

They fail in the financial sector at a named article. Regulation (EU) 2022/2554 requires the ICT risk management framework to include a digital operational resilience strategy setting out how the framework will be implemented ². That strategy explains how the framework supports the entity's business strategy and objectives, and sets out clear information security objectives with key performance indicators and key risk metrics ³. A project plan answers none of it.

And they fail at the board. Under Directive (EU) 2022/2555, the management bodies of essential and important entities approve the cybersecurity risk-management measures and oversee their implementation. They can be held liable for the entity's infringements of Article 21 ⁴. Approval is an act performed on something specific. A list of projects gives a body nothing to approve except the spending.

The three disciplines are one loop here, not three departments. The decision is governance's: which few things the organisation will be able to do in three years, who owns each, and what it will therefore not fund. The instrument is risk's: the risk picture and the approved criteria say which candidate objectives matter most, because an objective moving nothing above appetite is a preference rather than a priority. What compliance demonstrates comes later — that the objectives were pursued, the measures moved, and the regulatory dates were met inside the plan rather than instead of it. Governance decides, risk ranks, compliance evidences. A strategy assembled by one of the three alone reads as a wish list, a heat map, or a deadline calendar.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Strategy, plan, roadmap	A strategy states the objectives and the reasoning that selected them; a plan states the work pursuing them; a roadmap states when that work happens. Only the first is approved for the horizon.	Working distinction; not a clause of any standard cited here
Security objective	A stated end condition, owned by a role, with a measure and a target attached. Clause 6.2 is "Information security objectives and planning to achieve them"	1
Measure, baseline, target	A measure is the defined quantity; a baseline its value when the strategy is written; a target the value committed to, with a date. Set together, or none of them mean anything.	Clause 9.1, "Monitoring, measurement, analysis and evaluation" 5
Current Profile, Target Profile	A Current Profile specifies the outcomes an organisation is currently achieving, and how or to what extent. A Target Profile specifies the desired outcomes it has selected and prioritised.	Sec. 3.1 6
Constraint	A date or condition the strategy must satisfy but did not choose — a certification cycle, a regulatory application date. Constraints shape sequencing; they are not objectives.	Working distinction; obligations identified under ISO/IEC 27002:2022 control 5.31 7
Horizon	The period the objectives are set for. Three years is the working default, re-read yearly and rewritten when the risk picture or the obligations change materially.	Working default, not a requirement of any standard cited here

A Tier is not a target. Tiers characterise the rigour of an organisation's cybersecurity risk governance and management practices, from Partial through Risk Informed and Repeatable to Adaptive. They should complement a risk management methodology rather than replace it ⁸. Naming a Tier as the objective produces a strategy whose success condition is a self-assessment.

3. The method — numbered steps, each with input, activity, output and owner#

Nine steps in dependency order, read as a loop rather than a queue. Steps 3.1 and 3.2 establish what the organisation is for and what could stop it: risk work feeding a governance decision. Step 3.3 takes that decision — these objectives, these owners, this is what we will be able to do. Steps 3.6 and 3.9 are where compliance rejoins.

3.1 Start from the business objectives and the obligations register#

Two inputs open the work, and neither is a control list. The first is context. ISO/IEC 27001:2022 clause 4.1 is "Understanding the organization and its context" and clause 4.2 "Understanding the needs and expectations of interested parties" ⁹. ISO 31000:2018 is more explicit: examine externally the legal, regulatory, contractual, technological and economic factors, and internally the mission, governance and accountabilities, strategy, culture and capabilities ¹⁰.

The second is obligations. ISO/IEC 27002:2022 control 5.31 is "Legal, statutory, regulatory and contractual requirements". It asks that those requirements and the approach to meeting them be identified, documented and kept current, and reviewed regularly so new law is caught ⁷. CSF 2.0 states the outcome under GV.OC: those requirements are understood and managed, and the mission informs cybersecurity risk management ¹¹.

• Input: the business plan, the regulatory and customer commitments, the obligations register, the scope statement at clause 4.3 ¹².
• Activity: list three to five business objectives verbatim; attach the obligations bearing on each; mark those carrying a date; delete ambitions traceable to none.
• Output: the context and obligations sheet, one page, dated.
• Owner: the security officer drafts; each business owner confirms their line.

3.2 Read the risk picture: which risks the strategy exists to move#

Here the second discipline enters, as an instrument rather than an opinion. The risk picture and the approved criteria turn a list of worthy ambitions into a short list of objectives, because they say which exposures sit above what the organisation agreed to hold. ISO 31000:2018 puts that integration at the centre of its framework. Risk management should be part of, and not separate from, organisational purpose, governance, leadership, strategy, objectives and operations ¹³. Under GV.RM, risk management objectives are agreed by organisational stakeholders. Appetite and tolerance statements are established, communicated and maintained, and strategic direction describing risk response options is communicated ¹⁴.

Ask one question of each row beyond appetite: is the exposure structural or incidental. Structural exposure is an architecture, a dependency, or a capability the organisation lacks. It is what a three-year objective is for. Incidental exposure is a treatment plan and stays in the register, under criteria set in risk appetite and criteria.

• Input: the risk register, the approved criteria and appetite statement, the acceptance records with their expiry dates.
• Activity: filter to rows beyond appetite; classify each as structural or incidental; group the structural rows into three to six themes, carrying the identifiers.
• Output: the exposure themes, each naming the risk identifiers it covers.
• Owner: the security officer groups; risk owners confirm the grouping of their own rows.

3.3 Write five to seven security objectives, each with a measure, a target and an owner#

Five to seven is the number a body can hold and approve in one sitting. Each objective states an end condition rather than an activity. "Every production system authenticates through the central identity service" is an end condition; "roll out single sign-on" is a project. Only the first can be measured and missed.

Clause 6.2 is "Information security objectives and planning to achieve them" ¹. Clause 9.1, "Monitoring, measurement, analysis and evaluation", is where the measure has to hold ⁵. The financial-sector wording is direct: the resilience strategy sets out clear information security objectives, including key performance indicators and key risk metrics ¹⁵. Ownership is its own clause, 5.3, "Organizational roles, responsibilities and authorities" ¹⁶. An objective with no named owner role has no author when it slips.

Where AI systems run in production, an objective in that field belongs on the same page. Regulation (EU) 2024/1689 requires providers and deployers to take measures supporting the AI literacy of their staff and of others operating those systems on their behalf ¹⁷. Since no level is defined, the objective states what sufficient means per role.

• Input: the context and obligations sheet, the exposure themes, the current measurement set.
• Activity: draft eight to ten candidates in six fields: business objective, theme, measure, baseline, target with date, owner role. Keep only those that can be missed and would move their theme, then cut to five to seven.
• Output: the objectives register, five to seven rows, complete in all six fields.
• Owner: the security officer drafts; each owner role accepts their row before tabling.

3.4 State Current and Target as a gap, not as a score#

The gap statement is the part most strategies omit, and the part a board reads first. CSF 2.0 provides the shape. A Current Profile specifies the Core outcomes an organisation is currently achieving, or attempting to achieve, and how or to what extent. A Target Profile specifies the desired outcomes it has selected and prioritised, taking anticipated changes into account ⁶. The published sequence runs: scope the Profile, gather what is needed, create it, analyse the gaps between Current and Target into a prioritised action plan, then implement and update ⁶.

Scope is step one for a reason: a Profile scoped to everything says very little. Keep the statement to one paragraph per objective — what is true today, what must be true at the target date, and the capability separating them.

• Input: the objectives register, the control and capability inventory, the last assessment results.
• Activity: scope the Profile to the ISMS scope or narrower; state Current and Target per objective; write each gap as one paragraph.
• Output: the Profile gap statement, one paragraph per objective, dated and scoped.
• Owner: the security officer writes; the control owners confirm the Current position.

3.5 List the initiatives that close the gap, each tied to an objective and a risk#

Now, and only now, the roadmap. Each initiative carries the objective it serves, the risk identifiers it moves, a start, an end, the resource it needs and a status. An initiative serving no objective is a running cost or a preference, and both belong elsewhere.

Clause 6.2 covers planning to achieve the objectives as well as the objectives themselves ¹. Where an initiative implements a treatment decision, clause 6.1.3, "Information security risk treatment", is the clause that decision was taken under ¹⁸. Keeping both links explicit lets a body cut an initiative and see at once what it has left exposed. Delivery capacity is designed separately, in the security operating model.

• Input: the Profile gap statement, the current portfolio, the delivery capacity per team.
• Activity: propose initiatives against each gap; attach objective and risk identifiers; sequence against constraints; mark anything unfunded rather than deleting it.
• Output: the initiative list, each row tied to one objective and at least one risk identifier.
• Owner: the delivery owner per initiative; the security officer maintains the links.

3.6 Write the constraints row, and keep it out of the objectives#

Compliance dates belong on the page, not in the objective column. A regulatory application date says when something must already be true, not what the organisation is trying to become. Four instruments carry most of the dated pressure on a European security strategy. Member States adopted the NIS2 measures by 17 October 2024 and apply them from 18 October 2024 ¹⁹. Regulation (EU) 2022/2554 applies from 17 January 2025 ²⁰. Under the Cyber Resilience Act, Article 14 applies from 11 September 2026 and the rest of the Regulation from 11 December 2027 ²¹. The AI Act applies generally from 2 August 2026 ²². High-risk obligations follow for Article 6(2) systems from 2 December 2027 ²³, and for Article 6(1) systems from 2 August 2028 ²⁴.

Which of those bind a given organisation is a scoping question the obligations register answers. What matters here is the row's form: obligation, instrument, date, what must be true by then, and owner. The measures a body approves under Directive (EU) 2022/2555 are those Article 21 requires. They are appropriate and proportionate technical, operational and organisational measures for the risks posed to the network and information systems used ²⁵.

Here the loop closes visibly for a second time. Governance identified the obligation under control 5.31, and the risk picture weighed its urgency against everything else. What compliance demonstrates at the date is that the required condition holds, on evidence produced by work the objectives fund ⁷.

• Input: the obligations register, the certification cycle dates, the customer commitments carrying security terms.
• Activity: list each dated obligation; write what must be true by that date; name the owner; check the initiative list actually reaches it.
• Output: the constraints row, on the same page as the objectives.
• Owner: the compliance owner maintains it; the security officer checks it against the initiatives.

3.7 State the resources and the trade-offs#

A strategy that names no cost has been described rather than decided. ISO 31000:2018 asks top management and oversight bodies to ensure appropriate resources are allocated. Those resources cover people, skills and competence, processes, methods and tools, documented procedures, information and knowledge management systems, and professional development. The organisation should also consider the capabilities of, and constraints on, existing resources ²⁶. That last point is the honest one, and the one usually skipped.

ISO/IEC 27001:2022 clause 7 covers resources, competence, awareness, communication and documented information ²⁷. Together they turn funding into a specific conversation: which competences the organisation lacks, and whether it will hire them, buy them or do without.

• Input: the initiative list with its resource estimates, the current establishment and budget, the competence gaps.
• Activity: total the resource per objective; name in one line each what is deprioritised, what headcount is assumed but unapproved, and which themes stay as they are.
• Output: the resource and trade-off statement, one line per trade-off.
• Owner: the security officer prepares; the approving body decides.

3.8 Fit it on one page#

The page is a discipline, not a format. Everything above compresses onto one landscape sheet: per objective, the business objective served, the risk moved, the measure, the baseline, the target, the target date, the owner role and the initiative identifiers. The constraints row sits underneath; the gap statement, initiative list and resource detail become annexes. The workbook at one-page security strategy holds the same surfaces.

• Input: the objectives register, the initiative list, the constraints row, the resource statement.
• Activity: fill the columns above; version and date the sheet; move supporting tables to annexes.
• Output: the one-page strategy, versioned, with its annexes filed beside it.
• Owner: the security officer produces it; the approving body signs the version it approved.

3.9 Approve it, review it, and refresh it once a year#

An unapproved strategy is a draft with confidence. Approval is a dated act by a body with authority to take it, recorded where an assessor can find it. Three clauses hold the rhythm. Clause 5.1 is "Leadership and commitment" and clause 5.2 "Policy" ²⁸. Clause 9.3 is "Management review", with 9.3.2 "Management review inputs" and 9.3.3 "Management review results" ²⁹. Clause 10 has two parts, 10.1 "Continual improvement" and 10.2 "Nonconformity and corrective action" ³⁰. The strategy enters the review as an input and leaves it as a recorded result.

Two controls say what that looks like in practice. ISO/IEC 27002:2022 control 5.1 is "Policies for information security". It asks that the policy and topic-specific policies be approved by management, published, communicated and acknowledged, and reviewed at planned intervals and on significant change. Its guidance has the policy take business strategy, regulation, contracts and current and projected risks into account, and contain the objectives or the framework for setting them ³¹. Control 5.4, "Management responsibilities", asks management to require all personnel to apply information security in line with the established policies and procedures ³². A strategy nobody below the approving body has read is not yet in force.

ISO 31000:2018 asks top management and oversight bodies to articulate continual commitment through a policy or statement. It covers the links to the organisation's objectives and other policies, the authorities and accountabilities, and the resources made available. It also covers how conflicting objectives are dealt with, and measurement and reporting ³³. Leadership is also asked to align risk management with objectives, strategy and culture, and to address all obligations as well as voluntary commitments ³⁴.

An independent view belongs in the cycle. ISO/IEC 27002:2022 control 5.35 is "Independent review of information security". It asks that the approach and its implementation be reviewed independently at planned intervals or on significant change, by individuals independent of the area under review ³⁵.

Financial entities have the interval written for them. The ICT risk management framework is documented and reviewed at least once a year. It is reviewed again on major ICT-related incidents, and following supervisory instructions or conclusions from resilience testing or audit ³⁶. Elsewhere the annual refresh is a working default. CSF 2.0 states the expectation under GV.PO. Policy for managing cybersecurity risks is reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and mission ³⁷.

• Input: the one-page strategy, the resource statement, the previous review record, the year's results.
• Activity: table the page with the trade-offs visible; record the approval and its date; re-read it each year against the risk picture and the obligations; rewrite only what changed.
• Output: the approved strategy with its dated approval, and the review record each year.
• Owner: the approving body approves; the security officer convenes the review and holds the versions.

Rewriting the whole document annually is the failure this step prevents. Objectives set for three years should survive them, or the horizon was wrong.

4. Deliverables#

Deliverable	Format	Template	Retention
Context and obligations sheet	document	template pending	Current version plus one cycle
Exposure themes	register extract	/templates/one-page-risk-picture	As the register
Objectives register	xlsx	/templates/one-page-security-strategy	Horizon plus one cycle
Profile gap statement	document	template pending	Each version, three years
Initiative list	xlsx	/templates/one-page-security-strategy	Until every row closes
Constraints row	xlsx	/templates/one-page-security-strategy	Until the obligation lapses
One-page strategy, approved	xlsx	/templates/one-page-security-strategy	Every approved version
Review record	minutes with decisions	template pending	Whole certification cycle

Retention periods above are organisational choices, not requirements of any standard cited here.

5. What the auditor and the board will ask#

6. Failure modes and how they surface as findings#

7. Mapping to standards#

Clause titles come from the ISO/IEC 27001:2022 contents; ISO 31000:2018 and ISO/IEC 27002:2022 numbers and titles from licensed copies; CSF 2.0 identifiers from NIST CSWP 29.

Strategy element	ISO/IEC 27001:2022	ISO 31000:2018	NIST CSWP 29	Instrument	Evidence sampled	Verified
Business objectives and context	4.1, 4.2	5.4.1 context	GV.OC	—	Context sheet	38 10
Obligations register	4.2	5.4.1 external context	GV.OC	ISO/IEC 27002:2022 control 5.31	Register naming each instrument	7
Exposure themes from the risk picture	6.1.3	5.3 integration	GV.RM	—	Register rows per theme	13 14
Objectives with measures and targets	6.2, 9.1	—	GV.RM	Regulation (EU) 2022/2554 Art. 6(8)(c)	Objectives register, fields filled	1 15
Current to Target gap	—	—	Sec. 3.1 Profiles	—	Gap statement, scoped	6
Initiatives closing the gap	6.2, 6.1.3	—	Sec. 3.1 action plan	—	Initiative list, both links	18
Constraints and dated obligations	—	—	GV.OC	Directive (EU) 2022/2555 Art. 21(1)	Constraints row, owner and date	25
Resources and trade-offs	7	5.4.4 resources	—	—	Unfunded rows visible	26
Approval of the strategy	5.1, 5.2	5.4.2 commitment	GV.PO	Directive (EU) 2022/2555 Art. 20(1)	Dated minute naming the body	39 4
Review and refresh	9.3, 10	5.4.2 review	GV.PO	Regulation (EU) 2022/2554 Art. 6(5)	Review record, filed with inputs	29 36

8. Checklist#

• Three to five business objectives sit on the context sheet in the organisation's own words.
• Every obligation names its instrument, and every dated one names its date.
• Each exposure theme carries the risk identifiers it covers, taken from the register.
• The objectives register holds between five and seven rows.
• Every row carries a measure, a baseline measured before approval, a target and a date.
• Every row names an owner role that controls the resource, and that role accepted it.
• The Profile gap statement is scoped, dated and one paragraph per objective.
• Every initiative names one objective and at least one risk identifier.
• The constraints row states what must be true by each date, and who owns it.
• The approval records the body, the date and the version approved.
• The strategy entered a management review as an input, and the results are recorded.
• An independent review of the approach reported within the published interval.
• The annual re-read changed only what the risk picture or the obligations changed.

References#

1. ISO/IEC. Information security management systems — Requirements. ISO/IEC 27001:2022. Contents and clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁴⁰
2. ISO. Risk management — Guidelines. ISO 31000:2018. Clause numbers, titles and text read in a licensed single-user copy ⁴¹
3. ISO/IEC. Information security controls. ISO/IEC 27002:2022. Control numbers, titles and guidance read in a licensed single-user copy ⁴²
4. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 26 February 2024. https://doi.org/10.6028/NIST.CSWP.29 ⁴³
5. European Parliament and Council. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng ⁴⁴
6. European Parliament and Council. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng ⁴⁵
7. European Parliament and Council. Regulation (EU) 2024/2847 on products with digital elements (Cyber Resilience Act). https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng ²¹
8. European Parliament and Council. Regulation (EU) 2024/1689 on artificial intelligence (Artificial Intelligence Act), consolidated text of 27 July 2026. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727 ⁴⁶

The objective count, the horizon and the retention periods are organisational choices rather than requirements of any standard cited here.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication and is not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.