In the previous lesson you built Nimbus's risk register and took concrete decisions: mandatory MFA, just-in-time access for the consultancy, a ban on public links, secrets in a manager and not in .env. Every one of those decisions has the same problem today: it lives in the heads of three people and in a YAML file that nobody outside the technical team reads. When Marta moves on, when a new employee joins or when a customer asks "what rules do you have?", that knowledge disappears or cannot be taught. This lesson is about the artefact that solves exactly that: the security policy, which is the mechanism by which a decision outlives whoever took it. You will finish with a reusable template, two Nimbus policies written out in full and an exceptions register with mandatory expiry.

1. What a policy is and why it exists
2. The document hierarchy: policy, standard, procedure and guideline
3. One topic across all four levels: passwords and MFA
4. Anatomy of a policy and a reusable template
5. The minimum set of policies for an SME
6. Nimbus's Access Control Policy, written out in full
7. Nimbus's Acceptable Use Policy, written out in full
8. The life cycle of a policy
9. Exceptions: request, approval and mandatory expiry
10. Why policies fail
11. Policies and compliance frameworks: the bridge only

A security policy is a document approved by management that states what is required and why, and is mandatory for the people within its scope. It does not explain how something is done — that is a procedure — nor does it list products, nor does it expire when the technology changes. It does things no other artefact covers:

Enforceability deserves a clarification. If Nimbus wants to be able to act when someone installs unauthorised software on a corporate laptop, it needs to have communicated beforehand that this is not permitted, and to be able to prove it did so. A rule that is neither written down nor communicated is not a rule: it is a preference.

And a policy is not an instruction manual, which is the most frequent drafting mistake. The policy says "access to production data requires phishing-resistant multi-factor authentication"; the procedure says "go into the identity console, click Add method, choose Security key…". The first sentence will still be valid in five years' time; the second will be obsolete with the next redesign of the console.

Notice the cycle the diagram closes: the risk register justifies the policy, the policy is made concrete in standards, the standards are executed through procedures and take shape as controls, and the controls reduce the residual risk in the register that started it all. A policy that cannot be traced back to a specific risk is surplus; a Critical risk with no policy behind it is left at the mercy of the memory of whoever spotted it. Two very common level mistakes: putting parameters in the policy — if it says "passwords will have 12 characters", moving to 14 forces a fresh approval by management; the numbers belong in the standard — and writing guidelines in policy language — if something is a recommendation it has to say "it is recommended"; if it says "MUST", it is mandatory and somebody will audit it.

Nothing clarifies the hierarchy like watching a single topic travel the whole way down it. Level 1 — Password and Authentication Policy (extract):

Level 2 — Authentication Standard (extract): this is where the numbers live, and that is why it can be updated without troubling management.

Level 3 — Procedure "Registering a passkey" (extract):

Level 4 — Guideline "How to choose a memorable master password": passphrases, using the manager and what to do if the physical key is lost. It is not mandatory and nobody audits it. The practical consequence of the four levels is best seen like this:

That table is the practical reason for the hierarchy: each thing at its own level changes at its own frequency and is approved by the right person, and that way the document system neither seizes up nor runs out of control.

A policy that is missing any of these sections will generate an argument on the day it matters. This is the skeleton and the template you will reuse in the final project:

Three sections people leave out and which are exactly the ones you miss later: the purpose with traceability to the risk — without it, in two years' time nobody will know why the rule exists and the first person it inconveniences will delete it; what is out of scope — writing "this policy does not apply to personal devices that only check e-mail" avoids the endless argument about whether it applies; and the exceptions, because a policy with no exception route is breached in silence, whereas with one the breach becomes a visible decision with an expiry date.

Nimbus does not need the 40 policies of a multinational: it needs these eleven, and the ordering in the "Priority" column comes straight out of the risk register in 04-01.

Two SME criteria worth applying without embarrassment. Start with the five at priority 1 and publish the rest over the following six months: eleven mediocre policies published all at once are worth less than five good ones people have actually read. And merge where it makes sense: in a company of 38 people POL-03 can be a chapter of POL-02 and POL-06 can live inside POL-04. What must never be merged is anything with a different audience: POL-08 is read by a supplier, and a supplier cannot receive the entire internal document.

Read section 5.4 carefully: it is an entire lesson compressed into four statements, and each one eliminates a specific failure from the 02-06 timeline. 5.4.1 kills the shared account with no MFA; 5.4.2, the permanent access that was sitting there at 22:14 on an ordinary day; 5.4.3, the blindness of 20 days without detection; and 5.4.4, the access nobody ever looked at again. That is what it means for a policy to be traceable to a risk.

The Acceptable Use Policy is the one everybody in the company reads, including the non-technical people, so its wording has to be understandable with no prior knowledge. Its sections 1 to 3 follow the template — purpose: to protect the company, its customers and the users themselves, treating R-05 and R-08; scope: every person and every device, account or service provided by Nimbus, inside or outside the office; roles: each person is answerable for the use of their accounts, Lucía maintains the configuration of the estate and Marta resolves any queries. This is its body:

Two statements deserve comment because they run against many people's instincts. 5.3.1 ("over-reporting will never be held against anyone") and the closing paragraph of section 7 are not woolly kindness: they are incentive design, because a policy that punishes the click makes people hide the click, and hiding it multiplies the time to detect, the variable that most determines the harm (02-06). And 5.6.2 exists because a policy that affects employees' privacy without saying what is logged and why is, as well as unfair, legally fragile.

Validation note. The sections on personal use, monitoring, the disciplinary regime and the right to disconnect have employment-law and data protection implications that vary with the applicable collective agreement and legislation, and in many cases require prior information to staff or consultation with employee representatives. Before approving POL-04, review it with employment law advisers and with the compliance lead or the Data Protection Officer. The regulatory detail is covered in 06-03.

The three steps almost everyone skips, and which decide whether the policy is any use. Consultation (3): showing the draft to Lucía, Iván, Rubén and Sara before approving it is what catches the statement nobody can comply with; if Rubén says "with that rule I can't help a customer who has lost their access", it has to be fixed beforehand, not after he invents his own workaround. Communicating the why (6): publishing in a shared folder is not communicating; the version that works is a 20-minute meeting where you explain which risk each rule treats, with the 02-06 case as the argument. And recorded acceptance (7), without which there is no enforceability, repeated at every onboarding and at every major version.

One operational detail that saves a lot of noise: the policy lives in a single place with a visible version, because when three PDFs coexist in three folders, the one people comply with is the oldest, which is the one they downloaded.

An exception is the formal acknowledgement that, in one specific case, a rule is not going to be complied with, and it is essential that the route exists: the alternative to a documented exception is not compliance, it is silent non-compliance. Its four non-negotiable requirements are a business justification, a compensating measure, approval at the right level and an expiry, the last of which is the key one, because an exception with no end date is simply a different policy that nobody approved.

The second entry is the origin of the incident in 02-06. There was no decision to run a risk: there was a reasonable operational concession in 2023 — "give them access so they can help out overnight" — that nobody ever looked at again, with no compensating measure, no identifiable approver and no end date. Compare it with EXC-2026-004: the same exception against the same statement, but with named accounts, MFA, session recording, an out-of-window alert, management approval and six weeks of validity. The difference is not technical: it is documentary, and it is exactly the value this lesson adds.

Four rules for managing the register: a monthly review of those about to expire; automatic renewal is prohibited (renewing requires redoing the justification); if an exception has been renewed three times the problem is the policy and the policy has to change; and open exceptions are counted as a health indicator, because a register with 30 active exceptions describes a policy the organisation cannot comply with.

And above all of them, the criterion that sums up the lesson: a policy nobody can comply with makes security worse. It does not leave it unchanged: it makes it worse, in three ways. It normalises non-compliance, because when a rule is breached daily with no consequence, every other rule loses its authority. It hides the real risk, because on paper it is treated and in practice it is not, and the risk register from 04-01 becomes false. And it destroys trust in the document system, so the next policy, which may genuinely have been important, is stillborn. That is why, when torn between an ambitious statement nobody will comply with and a modest one everybody will, write the modest one and raise it next year.

Policies are not written in a vacuum: the frameworks you saw in 02-01 expect to find them, and under fairly specific names.

That is the whole of the bridge that belongs in this lesson: the detail of the frameworks and of certification is the subject of 06-02, and how effective compliance is audited belongs to 06-04.

• Writing the policy before you have the risk register. What comes out is a generic document that protects nothing in particular. Tip: every policy starts by citing the risks it treats; if you cannot cite any, do not write it yet. And do not put technical parameters in the policy: every change to a number would force a fresh approval, and "12 characters, FIDO2, 8-hour session" lives in the standard.
• Using "MUST" and "SHOULD" at random. If everything is "SHOULD", nothing is mandatory; if everything is "MUST", the policy cannot be complied with. Tip: go through the document marking every normative verb and ask yourself whether you are prepared to audit it. And do not approve without consulting the people who will have to comply: it is the number one cause of ornamental policies, and the consultation round takes a week and saves a year of silent non-compliance.
• Having no exception route, or having one with no expiry. Without a formal exception people breach the rule in silence; with exceptions that have no date you reproduce the very mistake that produced the 02-06 incident. Tip: publish the exceptions register at the same time as the policy, with expires as a mandatory field.
• Confusing publishing with communicating, and not versioning. A shared folder trains nobody, and when several copies coexist it is the oldest one that gets complied with. Tip: 20 minutes explaining the why, a single location and a visible version in the header.

Classify each statement as a policy, standard, procedure or guideline, and correct it if it is badly worded for its level:

1. "Backups will run at 03:00 using the backup.sh script held in /opt/nimbus/bin."
2. "Nimbus's information must be protected in accordance with its classification throughout its life cycle."
3. "Full backups will be retained for 90 days and incremental backups for 30, with at least one immutable copy outside the production account."
4. "It is advisable to check the backup alert e-mail each morning before starting."
5. "Employees should use passwords of at least 12 characters where possible."

Risk R-06 in the 04-01 register says that an attacker who finds credentials in clear text escalates to the A-05 cloud account. Draft three normative statements for POL-07 (Secure Development) that treat that risk, at the right level and in normative language. For each one, state: which standard or procedure would develop it, what evidence would demonstrate compliance, and one legitimate possible exception with its compensating measure.

You are presented with this request:

Identify everything that is wrong with it, decide whether you would approve it and on what conditions, and propose an alternative that solves Iván's problem without needing the exception at all.

Exercise 1

1. Procedure, well worded: it contains a time, a tool and a path, so it changes with the infrastructure.
2. Policy, correct: it states the what and the why with no parameters, and it will outlive any technical change.
3. Standard, correct: specific numbers, mandatory and auditable — you can check whether or not there is an immutable copy outside the account.
4. Guideline ("it is advisable" = not mandatory). Correct for its level, although it is worth asking whether checking the backup alert ought not to be mandatory: if it should, it has to be rewritten as a standard with a "MUST".
5. Badly worded in two ways: "should" and "where possible" make it unenforceable, and at the same time it contains a parameter (12 characters) that belongs in the standard. Correction: in the policy, "Access to systems MUST be authenticated with strong credentials in accordance with the Authentication Standard"; in the standard, "Minimum length 12 characters; mandatory check against breached-password lists".

Exercise 2

Notice that all three statements are policy level because none of them contains any parameter that will change with the tool — except the 4-hour deadline in 7.3, which is a deliberate risk decision and is therefore accepted at this level.

Exercise 3

What is wrong: (a) the requester approves his own request, which destroys separation of duties (01-03); (b) there is no compensating measure; (c) there is no expiry, so the exception is permanent by omission, exactly like the consultancy's in 2023; (d) the justification bounds nothing — it does not say what data, from which customer, where it is copied to or when it is destroyed; (e) it cites neither the related risk nor the residual risk; and (f), most seriously, it probably cannot be granted at all, because copying data that reveals health information into a development environment has data protection implications that go well beyond an internal exception.

Would you approve it? Not in that form. If there were no alternative, the minimum acceptable version would be: approval by Marta and not by Iván; scope limited to a single customer and with that customer's knowledge; a pseudonymised copy (03-07) with the clinical notes removed, not decrypted; an isolated environment with the same controls as production; a 7-day expiry with verified deletion; and access recorded.

The alternative that removes the exception — and which is the right answer — is to attack the cause: generate a synthetic data set that reproduces the volume and shape of the real data without containing any of it, or an automated anonymisation procedure that produces the pre-production copy with no personal data. It costs more the first time and removes the exception for good. Remember that in the 01-04 inventory the pre-production environment (A-22) appears with a classification of "to be reviewed" precisely because nobody was sure whether it contained real data: this exercise is that doubt made flesh.

You have delivered on the promise module 3 left open and that 04-01 reinforced: a policy is the mechanism by which a decision outlives whoever took it. It provides what no other artefact does — persistence, uniformity, enforceability, delegation and demonstrability — and a rule that is neither written down nor communicated is not a rule, it is a preference. You have the document hierarchy precisely: the policy says what and why and is approved by management; the standard says what is mandatory and measurable, and that is where the parameters go; the procedure says how, step by step, and changes with the tool; the guideline recommends and does not oblige. You have watched a single topic — passwords and MFA — travel all four levels, with the table that explains the practical reason for the whole system: each level changes at its own frequency and is approved by the right person.

You have the full anatomy of a policy and its reusable template, with the three sections everyone leaves out: the purpose traced to the risk, what is expressly out of scope, and the exception route. You have the minimum set of eleven policies for an SME with its priority order derived from the risk register, and two of them written out in full: the Access Control Policy, whose section 5.4 kills off one by one the four failures in the consultancy's access in 02-06, and the Acceptable Use Policy, where incentive design — reporting is never held against you, concealing is — matters as much as the rules.

You know the life cycle of a policy with the three steps that decide whether it is any use: the prior consultation that catches what cannot be complied with, the communication of the why that is not publishing to a folder, and the recorded acceptance without which there is no enforceability. And you take away the artefact that prevents the most damage: the exceptions register, with its four non-negotiable requirements — justification, compensating measure, approval at the right level and expiry — illustrated by the comparison between a well-made six-week exception and the undated 2023 exception that is the origin of the incident in 02-06. The lesson closes with the criterion that sums it up: a policy nobody can comply with makes security worse, because it normalises non-compliance, hides the real risk and leaves the next policy stillborn.

But look at what you have written. POL-02 says third-party access "must be named, with MFA and just-in-time"; POL-04 says devices "must keep disk encryption active". Those are statements of intent until something makes them true: somebody has to configure the MFA, verify that all 40 laptops really are encrypted, check it periodically and leave evidence that they checked. That "something" has a name and it is the third vertex of the triangle. In the next lesson, Security Controls (04-03), you will close the risk → policy → control triangle: the two classifications you have to master — by nature and by function — why every relevant risk needs controls from more than one function, the CIS v8 and ISO 27002 reference catalogues, how a control is selected by counting its recurring operational load, Nimbus's control catalogue as an artefact, the difference between an implemented control and an effective one, the metrics that measure it and the traceability matrix that saves an audit.