Writing & Governing a Policy (lifecycle, exceptions)¶
When a policy cannot be followed¶
Scaldimet has one inherited "standard" buried in an old IT document: all servers must run the latest vendor-supported operating system. It was reasonable when written. Today, Site Beta's SCADA runs on software the vendor stopped supporting years ago and cannot be replaced without re-engineering the line. So the standard is breached, permanently and without being addressed. Nobody raised it, nobody fixed it, and the real lesson staff have absorbed is that the security rules do not apply to reality, so they can be ignored. A policy that cannot be followed, with no way to formally address the gap, does more harm than no policy at all. Writing policy well, and governing it, is how you avoid that.
Writing a policy: intent, not configuration¶
A policy statement should be something the top can approve and the whole company can be held to, without naming a product or a setting. Compare two ways of writing the same intent:
- "All staff must use a 14-character password changed every 90 days." This is a standard, and it will be wrong within a year as advice and technology move on.
- "Access to Scaldimet systems must be controlled, individually attributable, and proportionate to the sensitivity of the system." This is a policy: it survives technology change and tells every owner what to aim at, while the exact password rule lives in a standard beneath it.
Write policy at the level of intent. A good statement is short, technology-neutral, and decidable: an owner can read it and tell whether a given situation complies. "Use systems responsibly" fails that test; "individually attributable" passes it.
The policy lifecycle¶
A policy is not a document you write once; it is a control you operate continuously. Like any control, it has a lifecycle, and skipping a stage is how policies stop working:
- Draft at the right altitude, with a named owner.
- Consult the people who will have to live with it (especially first-line owners, so it is realistic and partly theirs).
- Approve at the right level (board or ExCo for a policy; the CISO or system owner for a standard).
- Publish and communicate so people actually know it exists. An unpublished policy governs nothing.
- Enforce consistently. A rule enforced selectively teaches people which rules are optional.
- Review on a fixed cadence and on a trigger (a major incident, a new system, a regulatory change). A policy with no review date is already decaying.
- Update or retire. Rules that no longer serve are withdrawn deliberately, not left to contradict reality like Scaldimet's operating-system standard.
The single most neglected stage is review. The discipline that fixes it is simple: every policy carries an owner and a next-review date, and the governance committee (Chapter 2.4) checks them. Without that, your architecture from the last Lesson slowly becomes outdated.
Exceptions¶
No policy survives contact with the real world unbroken. The mature response is not to pretend, and not to weaken the policy until everyone complies on paper; it is a documented exception process. An exception is a deliberate, recorded, time-bound decision to consciously allow a specific breach of a standard. A workable exception has five parts:
- What it covers: the specific system and the specific requirement not being met.
- Why: the business or technical reason compliance is not possible now.
- Compensating controls: what reduces the risk in the meantime.
- Who accepts the risk: a named, accountable owner senior enough to carry it (this is risk acceptance, a governance act).
- Expiry and review: a date by which it is revisited, never open-ended.
Beta's unsupported SCADA is the textbook case. Instead of a permanent, unaddressed breach of the operating-system standard, you raise an exception: it covers the SCADA controllers, the reason is that the line cannot yet be re-engineered, the compensating controls are network segmentation and tightly monitored access, the accountable owner is the Beta operations director, and it expires in twelve months for review against the remediation plan. Now the breach is visible, owned, mitigated and time-bound instead of hidden. Exceptions are what let a policy remain strict while still reflecting reality: people stop having to choose between lying and ignoring it.
Scaldimet's SCADA exception, in one record
- Requirement not met: "Servers must run vendor-supported software" (the inherited standard).
- Scope: Site Beta SCADA controllers only.
- Reason: software is unsupported; the line cannot be re-engineered before the remediation plan completes.
- Compensating controls: OT network segmented from IT and the internet; remote access individually authenticated, logged and reviewed.
- Risk accepted by: Beta operations director.
- Expires: 12 months, reviewed by the security committee against the remediation milestones.
The same situation that was an invisible permanent breach is now a governed decision with a name and a deadline on it.
Application: write and govern one policy¶
By hand, produce three things for a single Scaldimet policy: (1) the policy statement at intent level; (2) its lifecycle data, meaning the owner, the approval level, and the review cadence; and (3) one exception drafted against a standard beneath it (use Beta's SCADA, with the five parts above). Then test the statement: could the board approve it, would it survive a technology change, and can an owner decide compliance from it?
Model answer (open after you've drafted yours)
A worked set for one policy:
- Policy statement (intent): "Scaldimet systems must run supported, maintained software, or else be covered by a recorded, time-bound risk acceptance with compensating controls."
- Lifecycle data: owner (the CISO); approved by (the ExCo, as a Policy); reviewed annually, and on any major incident, new system or regulatory change.
- Exception (against the standard beneath it): covers Site Beta's SCADA controllers; reason: the line cannot be re-engineered before the remediation plan completes; compensating controls: OT segmented from IT and the internet, remote access individually authenticated, logged and reviewed; risk accepted by: the Beta operations director; expires: 12 months, reviewed by the security committee against the remediation milestones.
Test the statement: the ExCo could approve it (short, intent-level), it survives technology change (it names no product), and an owner can decide compliance from it (supported, or a valid exception). Yours passes if the policy is technology-neutral and the exception has all five parts, with a named acceptor and an expiry.
Key takeaway
Write policy at the level of intent: short, technology-neutral and decidable. Operate each policy through a lifecycle of drafting, consultation, approval, publication, review and update or retirement. When reality cannot meet a requirement, use a documented, time-bound exception with compensating controls and a named risk owner. For Beta's unsupported SCADA, this turns a known gap into a governed decision.