Policy Hierarchy & Document Architecture¶
Two common policy-design failures¶
Scaldimet's only "security policy" is a single line in the staff handbook: employees must use computers responsibly. It directs nothing; no one can be held to it. The opposite failure is just as common: a 120-page policy copied from a template, full of controls for technologies Scaldimet does not own, that nobody reads and no one at Site Beta has heard of. Direction that is too vague is no direction; direction that is too voluminous is ignored, which is also no direction. How to fix this? Write at the right level, and connect the levels deliberately. That structure is what this Lesson builds.
The hierarchy: four levels at four altitudes¶
Direction is set through a small hierarchy of documents, each at a different levels of abstraction. Keeping them separate is what lets the top stay short and stable while the detail below can change freely.
| Level | What it is | Changes | Approved by | Scaldimet example |
|---|---|---|---|---|
| Policy | Short statements of intent and rule: what we will do and require, and why | Rarely | Board / ExCo | "Scaldimet protects the confidentiality, integrity and availability of its information and production systems." |
| Standard | Specific, mandatory requirements that implement a policy: the measurable bar | Occasionally | CISO / owner | "All remote access to production systems must be individually authenticated, logged and reviewed monthly." |
| Procedure | Step-by-step how-to for a task | Often | The doers | "How to grant and revoke a contractor's access." |
| Guideline | Recommended, non-mandatory good practice | Freely | The doers | "Tips for spotting a phishing email." |
The value comes from keeping these levels separate. A policy owned at the top (Board or ExCo) must be short and stable, or that owner cannot meaningfully own it. The specifics that change with technology belong below, in standards and procedures, where they can be revised without re-approving the policy. A frequent Scaldimet-style mistake is to combine all four levels into one document, which is then either too rigid to follow or out of date the moment a system changes. (The Compliance Module's baseline will live largely at the standard level: the concrete, mandatory bar that implements the directions you set here.)
Document architecture: how the documents connect¶
The hierarchy is the levels; the architecture is the map of how individual documents connect across them. A coherent architecture has three properties:
- Every standard implements a policy. If a standard cannot be traced to a policy statement, either the standard is unjustified or the policy is incomplete. Either way, the gap is worth finding.
- Every document has an owner, a version and a review date. A document nobody owns is a document nobody maintains. Versioning and a review date are what stop the architecture rotting (the subject of the next Lesson).
- No duplication, no orphans. The same rule should live in exactly one place, referenced from elsewhere, never copied. Copies drift out of step. Orphan documents (a procedure that implements no standard, a standard under no policy) signal that the architecture has gaps or clutter.
The documents form a hierarchy. Policies define intent, standards define requirements, and procedures describe how those requirements are implemented. This structure lets readers trace a requirement back to the policy and forward to its implementation. That traceability is the point of having an architecture rather than a drawer of unrelated documents.
A slice of Scaldimet's architecture
One policy statement, traced down through the levels:
- Policy: "No system is connected to a network or a third party without its named owner's explicit, recorded decision."
- Standard (implements it): "All third-party remote access must be individually authenticated, logged, and reviewed monthly; no unsupported system may be exposed to the internet without a recorded, time-bound risk acceptance."
- Procedure (realises the standard): "How to request, approve, grant, review and revoke contractor access at Site Beta."
Three documents, three levels of detail, one clear line of descent. The contractor problem you inherited now has a place in the architecture instead of existing in a gap between documents that were never written.
Application: build a slice of the architecture¶
Take one of Scaldimet's policy statements (use the one above, or write your own at intent level) and build the slice beneath it by hand: name the standard that would implement it and the procedure that would realise that standard. Then check the three properties: does the standard trace to the policy, does each document have an obvious owner, and is anything duplicated or orphaned?
A useful discipline as you do it: write each level only once and reference rather than repeat. If you find yourself restating the policy's wording inside the standard, stop and link instead. The moment a rule exists in two documents, you have created two things to maintain and a future contradiction.
Model answer (open after you've drafted yours)
Using a different policy statement than the architecture box above, so the two don't overlap:
- Policy (intent): "Access to Scaldimet systems is granted only to identified individuals, at the least privilege needed, and is removed when no longer required."
- Standard (implements it): "Every account is attributable to one named owner; access is reviewed quarterly; a leaver's access is revoked within one working day of departure."
- Procedure (realises it): "How to create, review and revoke an account when someone joins, changes role, or leaves."
Checked against the three properties: the standard traces up to the policy (least privilege, removed when not needed); each document has an obvious owner (policy: CISO / ExCo; standard: CISO; procedure: IT operations); and nothing is duplicated. The quarterly-review rule lives only in the standard, referenced from the procedure, never restated. Yours passes if the standard clearly implements the policy and each level is written once.
Key takeaway
Set direction through a hierarchy of four levels at four altitudes: short, stable policies the board/ExCo owns; specific, mandatory standards beneath them; procedures and guidelines below that. The document architecture is how individual documents connect: every standard implements a policy, every document has an owner, a version and a review date, and there are no duplications or orphans. Built as a small tree, it lets anyone trace upward to the business reason and downward to the concrete requirement, which is the whole point of an architecture rather than a drawer of unrelated files.