Policy architecture people can find

Scope: one organisation's policy set · Who: the officer accountable for it · Prerequisites: a risk register and an obligations list · First result: a policy map in three weeks

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

An officer inherits sixty documents. All are called policy. A delivery lead asks which one governs access to a production database, and four of them say something while none agrees.

Two shapes produce that pile. The first is flat: everything sits at one level, so nothing outranks anything and a conflict has no resolution route. The second is framework-shaped: one document per reference control, written so a mapping spreadsheet looks complete. Neither was designed around a decision.

It surfaces predictably. ISO/IEC 27001:2022 clause 5.2 is titled "Policy", and clause 7.5.3 is Control of documented information ^{1 2}. An assessor asks which version is current and who approved it. A shared folder is not an answer.

Control level is sharper. ISO/IEC 27002:2022 control 5.1 is Policies for information security. It asks that the policy and topic-specific policies be defined, approved by management and published. It asks that they be communicated to and acknowledged by relevant personnel and relevant interested parties. Review follows at planned intervals and on significant change ³. Six verbs, six records. Most piles produce one. A quieter symptom: an awareness programme teaches a rule and cannot point at the sentence stating it, which is treated in Security awareness that changes behaviour.

Policy is where the three disciplines meet on one page, and it reads badly when they are kept apart. Governance makes the decision: what the organisation requires, who may approve it, and who answers when it is not met. Risk supplies the instrument: each topic policy exists because a treatment decision or a legal obligation put it there, and its scope is that decision's scope. Compliance demonstrates the loop afterwards, from the approval record, the acknowledgement record, the review date and the exception that expired on time. One loop, not three document sets.

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

Two competent people read the words below differently, and the disagreement surfaces halfway through an audit. Guidance is paraphrased; titles are quoted.

Term	Working definition	Source
Information security policy	The single top document: general or high-level, approved by top management, setting out the approach to managing information security.	ISO/IEC 27002:2022 control 5.1 and its Table 1 3
Topic-specific policy	A lower-level document that further mandates control implementation. Specific and detailed, approved at an appropriate level of management, addressed to a target group or security area.	ISO/IEC 27002:2022 control 5.1 and its Table 1 3
Standard	Working definition: the mandatory, testable rules under a policy. The guidance lets an organisation name topic-specific policies standards, directives or policies, so the label is a local choice.	ISO/IEC 27002:2022 control 5.1 guidance 3
Procedure	The documented sequence for an operational activity, naming the responsible individuals. Written where an activity is done the same way by many people, or rarely enough to be forgotten.	ISO/IEC 27002:2022 control 5.37 4
Guideline	Working definition: advice stating expectations without creating a testable obligation. Nothing in a guideline is auditable, which is why the tier exists.	Working term; management provides guidelines stating role expectations 5
Owner and approver	Working distinction: the owner drafts the document and keeps it current; the approver's decision makes it binding. Development, review and approval are allocated by authority and technical competency.	ISO/IEC 27002:2022 control 5.1 and Table 1 3
Exception	A recorded, time-limited departure from a stated rule. The policy is expected to state the procedures for handling exemptions and exceptions.	ISO/IEC 27002:2022 control 5.1 guidance 3
Documented information	The management-system term covering the documents and the records they produce.	ISO/IEC 27001:2022 clause 7.5.3 Control of documented information 2
Control versus policy	A control is a measure in the reference set; a policy is the instrument mandating it. Annex A is Information security controls reference.	ISO/IEC 27001:2022 Annex A 6

Because the standard leaves naming to the organisation, the tier model is a local decision that must be written down. Otherwise every author picks a label and the pile returns.

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

Nine steps: the first three build the architecture, the next three make it usable, the last three keep it alive.

3.1 Decide the tiers and write down what each may say#

Before any document is rewritten, fix the shape of the set. Four tiers cover most organisations, and the value is in the constraint on each: a tier that may say anything is not a tier.

The policy states intent and accountability, and the guidance is unusually specific about its contents. It should carry a definition of information security, and the objectives or the framework for setting them. It should state the principles guiding security activity, and a commitment to satisfy applicable requirements. It should commit to continual improvement, assign security management responsibilities to defined roles, and set the procedures for handling exemptions and exceptions ³. That list is a drafting checklist.

The standard tier states mandatory rules that can be tested. The procedure tier states how a task is performed and by whom. The guideline tier gives advice and creates no obligation. Keep the boundary hard: a "should" in a standard is a defect, and a testable rule buried in a guideline is unenforceable.

Naming is deliberately free. The guidance says an organisation may name its topic-specific policies as standards, directives, policies or others. It adds that the policy and topic-specific policies can sit in a single document ³. Choose once and record the choice. The four document layers in Building an ISMS people actually use are the same architecture from the management-system side; this playbook names the mandatory-rules layer explicitly, so rules and advice stop sharing a document.

• Input: the current document inventory; the naming conventions already in use.
• Activity: define each tier, what it may state, who approves it and how often it is reviewed; publish the definitions with the set.
• Output: tier definitions, one page, approved with the policy.
• Owner: the officer accountable for the policy set.

3.2 Derive the topic list from risks and obligations, not from a framework's contents#

A set built by walking a control list produces a document per control and a decision for none. Build the list from two inputs instead.

The first is the risk register. Every treatment decision that depends on people behaving in a stated way needs a rule somewhere, and the register already names those decisions. This is where the risk instrument becomes a governance one, and the reasoning belongs in the register entry rather than the policy preamble. The treatment side is covered in The risk register other people trust, the acceptance side in Risk acceptance and residual risk.

The second is the obligations list. ISO/IEC 27002:2022 control 5.31 asks that legal, statutory, regulatory and contractual requirements relevant to information security, and the approach to meeting them, be identified, documented and kept up to date. Its guidance names the development of policies and procedures as one of the moments those requirements are taken into account ⁷. Read the obligations before the topic list, not after.

Reference topics remain useful as a completeness check rather than a table of contents. Control 5.1 gives example topics: access control, physical and environmental security, asset management, information transfer, and secure configuration and handling of user endpoint devices. The list continues with networking security, information security incident management, backup, cryptography and key management, information classification and handling, management of technical vulnerabilities, and secure development ³. Use it to find gaps, then delete the topics no risk and no obligation supports.

Where a regulation names policy subject matter, the topic is not optional. Article 21(1) of Directive (EU) 2022/2555 requires appropriate and proportionate technical, operational and organisational measures. Article 21(2)(a) then lists policies on risk analysis and information system security among the measures entities must at least take. Point (f) adds policies and procedures to assess the effectiveness of those measures, and point (i) human resources security, access control policies and asset management ⁸.

The financial sector is the clearest published case of a regulator naming a policy set. Article 6(1) of Regulation (EU) 2022/2554 requires a sound, comprehensive and well-documented ICT risk management framework. Article 6(2) states that the framework includes at least strategies, policies, procedures, ICT protocols and tools ⁹. Commission Delegated Regulation (EU) 2024/1774 titles its articles after the documents. Article 4 is the ICT asset management policy, Article 8 policies and procedures for ICT operations, and Article 19 the human resources policy. Article 22 is the ICT-related incident management policy, Article 24 the ICT business continuity policy components, and Article 29 information security policy and measures ¹⁰. Article 1 frames the set against overall risk profile and complexity, which is the proportionality hook ¹¹.

• Input: risk register; obligations list; reference topic examples; current inventory.
• Activity: list candidate topics from risk decisions and obligations; check against the reference examples; merge duplicates; delete topics nothing supports.
• Output: topic list, each entry naming the risk decision or obligation behind it.
• Owner: the officer accountable for the policy set, with the risk owner per entry.

3.3 Build the policy map#

The map makes the set searchable, and is the deliverable an assessor can be handed first. One row per document: tier, topic, owner role, approver role, audience, the requirement served, the controls the document mandates, version, approval date, next review date, status and location.

Two columns do most of the work. Requirement served is where the three disciplines meet in one cell: it names the instrument and clause, or the risk decision, that put the document there. Controls driven names what the document is meant to make happen, which turns a policy into evidence when an auditor asks how a control is mandated rather than merely described.

The map is also the fastest way to find documents nothing supports. A row with an empty requirement column is a retirement candidate. A control appearing in no row is one nobody has been told to apply. Where a forum decides who may approve what, that belongs with the decision rights model; see The security operating model.

• Input: topic list; tier definitions; the current inventory with its owners.
• Activity: create one row per document; fill owner, approver, audience and requirement; record version, approval and next review; mark rows with no requirement as retirement candidates.
• Output: policy map (template).
• Owner: the officer accountable for the policy set.

3.4 Write for the reader who has to act#

A policy nobody finishes is not communicated, whatever the distribution log says. The guidance is direct about the target: policies should reach their readers in a form those readers can find, follow and act on ³.

Three drafting constraints carry most of that. Keep a topic policy to one page for its audience, moving anything longer into a standard or a procedure. Write rules as statements: who must do what, when, and with whose approval. End with the route to follow when the rule cannot be met, and the role to ask.

The audience column decides tone. A rule for every employee and a rule for a platform team are different documents even when they concern the same control. Merging them produces a document neither audience reads.

• Input: topic list; audience per topic; the tier definitions.
• Activity: draft each document to its tier and audience; move testable rules up into standards; move advice down into guidelines; add the exception route.
• Output: drafted policy set, one document per map row.
• Owner: the document owner named on the map.

3.5 Approval, communication and acknowledgement#

These are three separate records, and most sets produce only the first. The control asks that policies be approved by management, published, and communicated to relevant personnel and relevant interested parties. Recipients should be required to acknowledge that they understand and agree to comply, where applicable ³.

Approval is not uniform. Top management approves the policy and any change to it; topic-specific policies are formally approved at an appropriate level of management ³. The management-system counterpart is clause 5.2, read with clause 5.3, Organizational roles, responsibilities and authorities ¹².

The risk side states the same duty in its own language. ISO 31000:2018 clause 5.4.2 asks top management and oversight bodies to demonstrate and articulate continual commitment to risk management. The vehicle is a policy, a statement or another form. The commitment covers purpose, links to objectives and other policies, authorities and accountabilities, and resources. It also covers conflicting objectives, measurement and reporting, and review and improvement. It should be communicated within the organisation and to stakeholders as appropriate ¹³.

Line management is part of the mechanism, not an audience for it. Control 5.4 asks management to require all personnel to apply information security in accordance with the established policy, topic-specific policies and procedures. Its guidance covers briefing people on their responsibilities before access is granted, and a confidential channel for reporting violations ⁵.

Acknowledgement and awareness are related and not the same. Clause 7.3 of ISO/IEC 27001:2022 is titled "Awareness" ¹⁴. A signature records that a rule was received; the awareness programme is what makes it act on behaviour.

• Input: drafted set; approval routes per tier; the personnel and interested-party lists.
• Activity: obtain approval at the tier's level; publish; communicate to each named audience; capture acknowledgement where applicable; brief line managers on their duty.
• Output: approval records, distribution record, acknowledgement register.
• Owner: the approver named on the map, with the document owner running the process.

3.6 Exceptions: the route, the record and the expiry#

Every organisation breaks its own rules somewhere. An architecture without an exception route hides that; one with a route turns it into a managed queue.

The route belongs in the policy itself, because the guidance expects the policy to state the procedures for handling exemptions and exceptions ³. Three fields make the record usable: the rule departed from, the approver, and the expiry date. An exception without an expiry is an undocumented policy change.

The compliance side is control 5.36, Compliance with policies, rules and standards for information security. It asks that compliance with the policy, topic-specific policies, rules and standards be reviewed regularly. Where non-compliance is found, managers identify the causes and evaluate the need for corrective action. They implement it and review its effectiveness, and the results are recorded and maintained ¹⁵. Corrective actions should be completed in a timely manner appropriate to the risk, and progress addressed at the next scheduled review otherwise ¹⁵.

An exception is a risk acceptance wearing document-control clothing, so the accepting role and the record should be the ones the risk process already uses; see Risk acceptance and residual risk. A departure that turns out to be a nonconformity goes to clause 10.2 ¹⁶.

• Input: the published set; the risk acceptance route and its authority levels.
• Activity: register each exception against a policy ID with an owner, approver and expiry; review the queue on the compliance-review cadence; close, renew or escalate at expiry.
• Output: exception register, one row per exception, expiries enforced.
• Owner: the risk owner accepting the exception, with the policy owner keeping the register.

3.7 Review cycles and change triggers#

A calendar alone produces reviews that change nothing. Pair a cycle per tier with a trigger list, so a document is reviewed when something moves too.

The trigger list is given almost intact by the guidance. The review considers changes to business strategy, technical environment, regulations, statutes, legislation and contracts. It also considers information security risks, the projected threat environment, and lessons learned from security events and incidents. Reviews take management review and audit results into account, and one policy changing prompts consideration of the related ones ³.

Where a regulation sets a floor, use it. Article 6(5) of Regulation (EU) 2022/2554 requires the ICT risk management framework to be documented. Review follows at least once a year, and on the occurrence of major ICT-related incidents ¹⁷. Version and status handling is clause 7.5.3. That is why the map carries version, approval date and status columns rather than a file name ².

• Input: the map with review dates; audit and management review results; the trigger list.
• Activity: review each document on cycle or on trigger; record the outcome even when nothing changes; update related documents flagged by the change.
• Output: review record per document; updated review dates on the map.
• Owner: the document owner, with the approver re-approving material change.

3.8 Retiring documents#

Retirement is the step most sets never take, which is how sixty documents become ninety. Retire on three conditions: the requirement behind the row is gone, the content has moved elsewhere, or the document has no owner and no audience.

Retiring means marking the map row retired, removing the document from where readers look, and keeping the withdrawn version where records are kept. A retired document still reachable by search is worse than a wrong one, because the reader cannot tell. The guidance also warns against improperly disclosing confidential information when a policy is distributed outside the organisation, and that applies to superseded copies ³.

• Input: the map, with rows lacking a requirement or an owner.
• Activity: decide retire, merge or keep per candidate; withdraw the document from the reader-facing location; archive it under document control; record the decision.
• Output: retirement decisions; archived versions; map rows marked retired.
• Owner: the document owner, with the approver confirming retirement.

3.9 Measuring the architecture#

Four measures cover the failure modes above, and none of them counts documents.

Findability. Take ten real questions asked last quarter, and time how long a reader outside the security function needs to reach the sentence answering each. Report the median and the misses.

Acknowledgement coverage. The share of each named audience that has acknowledged the current version, by document, taken from the acknowledgement register rather than the distribution list.

Exceptions per policy. A document carrying many exceptions is usually wrong rather than widely broken, so treat the count as a signal to redraft. Track expired exceptions separately; that number should be zero.

Overdue reviews. Documents past their next review date, by tier, reported beside the review outcomes so a review that changed nothing stays visible.

The framework language is the Policy category of the NIST Cybersecurity Framework. GV.PO-01 asks that policy for managing cybersecurity risks be established from organisational context, strategy and priorities, and be communicated and enforced. GV.PO-02 asks that it be reviewed, updated, communicated and enforced to reflect changes in requirements, threats, technology and mission ¹⁸.

• Input: acknowledgement register; exception register; the map; real reader questions.
• Activity: measure the four each quarter; report them with the review outcomes; decide one change per measure.
• Output: policy architecture measures, quarterly, with a decision recorded against each.
• Owner: the officer accountable for the policy set.

4. Deliverables (with template links)#

Deliverable	Format	Template	Retention
Tier definitions	markdown or document	Described in section 3.1; no separate file	Current plus one cycle
Policy map	xlsx or markdown	/templates/policy-map	Living register; versions kept
Policy page template	document	Section 3.4: title, audience, owner, approver, version, rules as statements, exception route	Current version only
Exception register	xlsx or markdown	Exceptions sheet of the policy map, with the acceptance record per Risk acceptance and residual risk	Until expiry plus one cycle
Approval and acknowledgement records	records	No template	Per the records schedule

Retention periods above are organisational choices; no instrument cited here sets them.

5. What the auditor or authority will ask [Callout: auditor-asks]#

• "Show the current version of this policy and the record of its approval." — evidence: the map row plus the approval record for that version.
• "Who approved this topic-specific policy, and were they the right level?" — evidence: tier definitions naming the approval level, plus the approval record.
• "How do people know this rule applies to them?" — evidence: the audience column, the distribution record and the acknowledgement register.
• "Which requirement made this document necessary?" — evidence: the requirement-served column, tracing to a clause, an article or a risk decision.
• "When was this last reviewed, and what did the review conclude?" — evidence: the review date on the map and the review record, including reviews that changed nothing.
• "What happens when a team cannot meet this rule?" — evidence: the exception route stated in the document, plus the register with owners and expiries.
• "How is compliance with these policies reviewed?" — evidence: the compliance review record, with causes, corrective actions and their verification.

6. Failure modes we see and how they show up in findings [Callout: failure-mode]#

• The flat pile. Sixty documents at one level, no tier, no precedence. Surfaces as: the current version of a policy could not be identified, and two documents state conflicting requirements. Smallest fix: publish tier definitions, then assign every document to a tier before rewriting anything.
• The framework-shaped set. One document per reference control, mapped completely and read by nobody. Surfaces as: personnel could not identify the rules applicable to their role. Smallest fix: rebuild the topic list from risk decisions and obligations.
• Distribution mistaken for communication. A publication log with no acknowledgement and no audience definition. Surfaces as: policies were not acknowledged by relevant personnel. Smallest fix: name the audience per document, and capture acknowledgement against the current version.
• Exceptions as email. Departures agreed in conversation, with no expiry and no owner. Surfaces as: controls were not applied and no documented exception existed. Smallest fix: one register, three mandatory fields, a monthly expiry sweep.
• Reviews with no record. Dates pass, documents are read, nothing is written down. Surfaces as: policies were not reviewed at planned intervals. Smallest fix: record every review outcome, including "reviewed, no change", against the map row.

7. Mapping to standards (clause table, verified)#

Element	ISO/IEC 27001:2022	ISO/IEC 27002:2022	NIST CSWP 29	Instrument	Evidence
Tier definitions and naming	5.2 Policy	5.1, naming left to the organisation	GV.PO-01	—	Approved tier sheet
Topic list from obligations	4.2	5.31	GV.OC-03	Dir. (EU) 2022/2555 Art. 21(2)(a)	Obligations list with a policy column
Policy set named by a regulator	5.2	5.1	GV.PO-01	Reg. (EU) 2022/2554 Art. 6(2); Reg. (EU) 2024/1774 Arts. 4, 8, 19, 22, 24, 29	Map rows citing each article
Ownership and approval level	5.3	5.1 and its Table 1	GV.RR-02	Dir. (EU) 2022/2555 Art. 20(1)	Approval records per tier
Communication and acknowledgement	7.3 Awareness	5.1 and 5.4	GV.PO-01	—	Distribution and acknowledgement registers
Commitment articulated at the top	5.1	5.1 policy statements	GV.RR-01	ISO 31000:2018 clause 5.4.2	Approved policy or statement
Exceptions and their expiry	6.1.3	5.1 exemption procedures	GV.RM-04	—	Exception register with expiries
Compliance review of the set	9.2	5.36	GV.OV-03	Dir. (EU) 2022/2555 Art. 21(2)(f)	Review results and corrective actions
Review cycle and change triggers	7.5.3	5.1 review triggers	GV.PO-02	Reg. (EU) 2022/2554 Art. 6(5)	Review records and updated dates
Procedures under the policy	7.5	5.37	GV.PO-01	Reg. (EU) 2024/1774 Art. 8	Procedures on the map

Sources, cited once rather than per cell. The ISO/IEC 27001:2022 references are clause titles from the publisher's contents listing: 4.2, 5.1, 5.2, 5.3, 6.1.3, 7.3, 7.5, 7.5.3 and 9.2 ¹⁹. The controls are ISO/IEC 27002:2022 5.1, 5.4, 5.31, 5.36 and 5.37 ²⁰. ISO 31000:2018 clause 5.4.2 supplies the risk-side row ¹³. The Subcategories are GV.PO-01, GV.PO-02, GV.RR-01, GV.RR-02, GV.RM-04, GV.OC-03 and GV.OV-03 ²¹. The instrument column cites Directive (EU) 2022/2555 Articles 20(1), 21(2)(a) and 21(2)(f) ²², Regulation (EU) 2022/2554 Article 6 ²³ and article titles of Commission Delegated Regulation (EU) 2024/1774 ¹⁰.

8. Checklist#

• Tier definitions exist as one approved page, stating what each tier may say.
• Every document in the set is assigned to exactly one tier.
• Every map row names an owner role and an approver role, not a person.
• Every map row names the requirement or risk decision behind the document.
• Every reference topic is either covered or recorded as deliberately out of scope.
• Each document names its audience, and that audience is narrower than "everyone" wherever the rule is.
• The approval record for the current version exists at the level the tier requires.
• Acknowledgement is captured against the current version, not the document title.
• Every document states the route to follow when its rule cannot be met.
• Every exception carries a rule reference, an approver and an expiry date.
• No exception is past its expiry without a decision recorded.
• Every document has a next review date, and reviews with no change are still recorded.
• Retired documents are unreachable from the reader-facing location and kept under document control.

References#

Primary sources only, read at the EU Publications Office, at the publishers, and in licensed copies.

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ¹⁹
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Controls 5.1, 5.4, 5.31, 5.36 and 5.37 read in a licensed copy; catalogue entry at https://www.iso.org/standard/75652.html ²⁰
3. ISO. Risk management — Guidelines. ISO 31000:2018. Clause 5.4.2 read in a licensed copy; catalogue entry at https://www.iso.org/standard/65694.html ¹³
4. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29. Appendix A, the CSF Core, read at https://doi.org/10.6028/NIST.CSWP.29 ²⁴
5. European Parliament and Council. Directive (EU) 2022/2555 (NIS 2). OJ L 333, 27.12.2022, p. 80. Articles 20 and 21 at https://publications.europa.eu/resource/celex/32022L2555 ²⁵
6. European Parliament and Council. Regulation (EU) 2022/2554 (DORA). OJ L 333, 27.12.2022, p. 1. Article 6 at https://publications.europa.eu/resource/celex/32022R2554 ²³
7. European Commission. Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk RTS). OJ L, 2024/1774, 25.6.2024. Article titles read at https://publications.europa.eu/resource/celex/32024R1774 ²⁶

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.