Module 5 ended with an uncomfortable warning: nothing you have built maintains itself. The monthly scan stops running when Lucía has a bad week, the baseline degrades if nobody looks at the --check --diff, the CSP fills up with exceptions and the security.txt goes stale. This lesson deals with the problem that holds up all the others: how a one-off decision becomes a habit that survives holidays, sick leave, an urgent launch and staff turnover. There is no new tooling here. There are checklists by role, a calendar, automation that depends on nobody's memory, a ten-number dashboard and a twelve-month roadmap that fits into 18,000 € and 440 hours. It is the least spectacular lesson of the course and probably the one that prevents the most incidents.

1. The thesis: security is not achieved, it is sustained
2. Security hygiene: the little that prevents almost everything
3. Best practices by role: six checklists
4. Rhythms and cadences: the Nimbus security calendar
5. Automating the habit: let the system remember for you
6. Measuring so as not to fool yourself: the minimum dashboard
7. Continual improvement: PDCA and the rule of finishing before starting
8. Organisational anti-patterns
9. Culture: how you recognise the real thing
10. The Nimbus 12-month roadmap

There is one fact that ought to make anyone with experience in this field uncomfortable: in the vast majority of serious incidents, the affected organisation knew what needed to be done. It was not short of knowledge. Look again at the cases in 02-06 through that lens:

The conclusion is not that people are negligent. It is that knowing and doing are two different capabilities, and the second degrades over time unless some mechanism sustains it. A security project produces a good state on a particular date; from then on, that state degrades on its own. New servers are deployed, people are hired, ports are opened "temporarily", service accounts are created for a migration, dependencies are installed. This is what we called configuration drift in 01-04 and fought with Ansible in 05-06: entropy is the default condition.

A habit, by contrast, is an action executed without a prior decision because there is a trigger that fires it. The practical difference is this:

• Project: "let's put MFA on everybody". It finishes, it is celebrated, and six months later 30 % of new accounts do not have it.
• Habit: "no account is created without MFA because the identity provider will not allow it, and on the first Monday of the month a report of the exceptions goes out". It never finishes, and that is why it works.

The question that organises this whole lesson is not "have we done it?" but "what makes it keep being done a year from now, when nobody remembers this conversation?".

Security hygiene is the small set of basic practices whose absence explains the majority of incidents. The term is deliberate: like washing your hands, it is not glamorous, it requires no talent, and its aggregate effect beats any sophisticated intervention.

Eight practices. Not eight among many: the eight.

The argument for why this is enough for almost everything stands on two legs. The first is statistical: the industry's annual reports (Verizon DBIR, ENISA, INCIBE) agree year after year that the great majority of breaches begin with credentials, phishing, exploitation of a known vulnerability or a misconfiguration — the first four on the list. The second is economic: the attacker who goes after Nimbus is not an intelligence service, it is an opportunistic operator sweeping the Internet for easy targets, and hygiene turns Nimbus into an expensive one.

The rule worth committing to memory: the basics well maintained beat the advanced badly maintained. A high-end EDR with half the endpoints missing an agent and the alerts unreviewed protects less than universal MFA plus tested backups. And it costs twenty times as much.

Notice the detail that separates real hygiene from apparent hygiene: each of the eight carries a verification verb. It is not "make backups", it is "test the restore". It is not "have an inventory", it is "keep it updated". It is not "set up alerts", it is "review them". The verification verb is what turns an intention into a measurable habit.

A list of best practices addressed to "the company" is executed by nobody. Addressed to a person with a name, it is. These are the six Nimbus checklists, written to fit on a card.

• I allocate time, not just budget. Lucía's 440 h are in the plan like any product project; if they are not in it, they do not exist.
• I review monthly the privileged-change log (C-21) and sign the minutes. Fifteen minutes.
• I review quarterly the risk register from 04-01 and the exceptions register: what has changed, which exception is expiring.
• No exception without an expiry date. The consultancy's 2023 exception, with no expiry, is the reason the incident in 02-06 exists.
• Risk enters product decisions. When sales promises an integration for Friday, the question "what data does it touch and who sees it?" is one I ask, not one I wait for somebody else to ask.
• An incident reported late is my failure, not the reporter's. I say so out loud and act accordingly.
• I sign what I approve and keep the approval: policies, exceptions, budget. This is the evidence for 06-04.

• I trust no data that comes from the client, identifiers included: authorisation is decided on the server with current_tenant and require(), never with a parameter.
• No secret in the code, nor in a versioned .env, nor in a log. Secrets manager always; gitleaks blocks the commit if I slip.
• Dependencies pinned and audited: pip-audit in CI, monthly updates, and I do not add a library without looking at who maintains it.
• Authorisation tests are tests, not a manual review: every new endpoint carries a test that verifies tenant B cannot see tenant A.
• I log what is relevant and nothing more: who, what, when, on which resource; never passwords, tokens or the content of a clinical note.
• Before opening a pull request, I go through the review checklist from 05-05. If I touch authentication, authorisation, cryptography or file upload, I flag it so someone else looks at it.
• When I find a security flaw in our own code, I say so the same day. I do not fix it quietly.

• I review the day's alerts, all of them, and close each one with a sentence saying what it was. An alert left open is an alert that does not exist.
• I apply critical patches within 7 days and record the date; the rest go in the monthly window.
• Infrastructure change = code. Nothing by hand in the console: if it is not in Terraform or Ansible, it did not happen.
• I run --check --diff weekly and treat any drift as a minor incident: someone touched something outside the process.
• I test the restore every quarter with a stopwatch and keep the report. Without that report, the backups are a belief.
• No permanent access for third parties: the consultancy comes in just-in-time, with an 8-hour window and automatic revocation.
• I document while I work, not afterwards. A runbook written after the fact never gets written.
• When something urgent forces me to skip the process, I raise the exception with a closing date before I skip it.

• I verify identity before touching anything: never through the information the person gives me, but through a channel we already have on record.
• I never ask for or accept a password, not even "just to check". If someone insists, that is the signal.
• I access the minimum number of tenants: every access lands in the audit table and detection D-05 looks at exactly that.
• I do not export data to my e-mail or my laptop. If I need a report, it comes out of the system with a signed URL and it expires.
• An urgent, emotional request from a customer is a social-engineering pattern. Urgency is the tool, not the context.
• I report anything odd even if it seems trivial. Three clinics ringing to complain about slowness were, in 02-06, day 20.

• No change to a supplier's bank account without verification through an alternative channel, ringing the number we already had, not the one in the e-mail.
• No transfer outside the usual circuit because management says it is urgent. That is literally the script of CEO fraud.
• Joiners and leavers are communicated the same day: an exit triggers access revocation (02-05), and an exit communicated late is a live account with no owner.
• HR data (A-16) lives where it should live, not in a spreadsheet on the desktop or in a folder shared with the whole company.
• CVs and contracts are personal data. They are kept for the intended period and then deleted (06-03).
• Unexpected invoices and attachments are not opened: the real sender is checked, not the display name.

• Password manager for everything, unique passwords, MFA wherever it is offered.
• Encrypted laptop, automatic lock, no working as an administrator day to day.
• I update when the system asks, and I do not postpone indefinitely.
• When in doubt, I ask before clicking. Asking is never a nuisance.
• I report with the button, even if I have already fallen for it. Especially if I have already fallen for it.
• I do not install tools or connect external services to company data without going through Marta and Lucía.
• Guest wifi for personal devices, never the corporate network.

A habit needs a time-based trigger. This is the whole course translated into a calendar, expressed as data so that it can live in the repository and generate automatic reminders.

How to read this calendar. Adding up the recurring time gives roughly 300 hours a year of Lucía's and around 60 of Marta's, plus the pentest budget. That sits within the 440 h available and leaves about 140 for improvement projects. That sum — which almost nobody does — is what avoids the classic mistake of planning a year full of new projects with no room left to operate what has already been built.

Three design criteria behind the calendar are worth understanding:

• Daily work is short or it does not happen. Fifteen minutes are sustainable; an hour a day is not.
• Expensive work is spaced out and carries mandatory evidence. The restore test is quarterly because it costs half a day, and it produces a report because otherwise nobody will know whether it was done.
• Every task has a named owner. "The team" executes nothing.

A calendar still depends on somebody looking at it. The next step up is turning the practice into something the system enforces, so that skipping it takes a deliberate act rather than a lapse.

The cheapest and most overlooked example is the pull request template, which turns the 05-05 checklist into something that appears in front of your eyes at exactly the right moment:

And the general pattern behind all these examples: secure defaults. If the Terraform template used to create a bucket already comes with public-access blocking, encryption and versioning, nobody will have to remember. If the base image is already distroless and rootless, no developer will have to decide. The most effective way to sustain a good practice is to make the secure option also the most convenient one.

A warning: automating without reviewing produces a false sense of control. A CI that always fails ends with people using --no-verify. Practical rule: if an automated control produces more than one false positive a week, fix it or remove it, because before long it will be ignored anyway.

Without measurement, the perceived level of security rises with the effort invested, not with the actual risk. The antidote is a small set of indicators published every month, always the same ones, each with its target and its source. Ten numbers for Nimbus:

Four rules to keep the dashboard from becoming decoration:

• Every indicator has a target declared before it is measured. If the target is set afterwards, it is always met.
• Every indicator has an automatable source. If the figure needs someone to estimate it, it is an opinion.
• It is published even when it looks bad. A dashboard only shown when it is green informs nobody of anything.
• Look at the trend, not the absolute value. A rising 92 % is worth more than a falling 96 %.

An automated calculation, along the lines of the one in 04-03 but now as a complete dashboard:

Output:

Compare this with the dashboard in 04-03: back then MFA stood at 57 % and patching was over the deadline. The improvement is real and it is measurable, and that is exactly the point. The five indicators in red are not a failure: they are the month's work list, and two of them — the unencrypted laptop and the expired exceptions — can be closed in an afternoon.

The PDCA cycle (Plan, Do, Check, Act) is the formal engine of continual improvement, and it is the structure that ISO 27001 requires in its clause 10 (we will see this in 06-02). Applied to Nimbus, without the liturgy:

What makes the cycle useful is not drawing it, but two concrete disciplines:

How to prioritise when everything looks urgent. The Nimbus order, in this exact sequence:

1. What is on fire: an incident in progress, a critical vulnerability with an active exploit (KEV, in the terminology of 05-01).
2. What reduces the most risk per euro and per hour, according to the ALE in the register from 04-01. This remains the underlying criterion.
3. What is free and quick: closing a port, ticking a box, putting an expiry date on an exception. It gets done now, it does not get planned.
4. What sustains everything else: automation, calendar, documentation. Always underestimated, and it is what saves you from redoing the work.
5. What a customer or a rule requires with a date, even if it is not the most effective thing. It is a real business risk.
6. What is interesting. Last. Always last.

The rule of finishing before starting. Nimbus does not start a new initiative while more than two are in progress. It sounds bureaucratic and it is the opposite: half-done security does not protect proportionally. An MFA rollout at 60 % does not reduce risk by 60 %, because the attacker is looking for precisely the remaining 40 %. A half-done control is usually worth zero. That is why it is better to pick three things a quarter, finish them, verify them and only then open the next ones.

Five ways of having security on paper and not having it in practice. All five are cultural, not technical.

The case of Lucía and the bus factor deserves a paragraph, because it is the most common in SMEs and the worst understood. R-09 has a high impact and a far from negligible likelihood — a bout of sick leave or a better offer is all it takes. And it is not solved with a document: it is solved by reducing tacit knowledge. Three concrete measures, none of them expensive:

• Operational documentation (A-17) written during execution, to the standard that another technical person can follow it without asking.
• Minimum rotation: Iván runs the quarterly restore test at least once a year, with Lucía observing. The first time it will go badly, and that is precisely the finding.
• An external on-call retainer with the consultancy, now with just-in-time access, to cover holidays. And with the lesson of 02-06 properly learned: the retainer never again implies permanent access.

On buying without operating, the arithmetic of an SME is unforgiving: a commercial SIEM at 12,000 €/year consumes two thirds of the Nimbus budget and demands between 100 and 200 hours of operation a year that Lucía does not have. With those same 200 hours you can implement the twelve detections D-01…D-12 on open tooling, test them and automate the calendar. The question that must precede any purchase is who is going to operate it, with what hours, and who will find out if it stops working.

A security culture is not measured by posters or by the completion rate of the annual course — that is 06-05, and there we will see why it is a vanity metric. It is recognised by observable behaviours:

• People report their own mistakes without fear. Someone says "I clicked a strange link" five minutes later, not the next day and not never. This is the primary indicator: where the person who falls for it is punished, early detection disappears.
• People ask before acting. "Can I send this export to the customer by e-mail?" is a healthy question, and the answer must arrive the same day or people will stop asking.
• Risk is spoken about out loud in product decisions, not only in security meetings. "This exposes the tenant identifier in the URL" gets said in refinement, not in the pentest.
• You can say something is going wrong upwards. If Lucía can tell Marta "we are not going to get to this and the risk is X" without personal cost, the system works.
• Temporary things have a date. The test bucket, the one-day firewall rule, the access for a migration: if they are born with an expiry date, there is culture; if not, there is debt.
• When something fails, the question is what in the system allowed it, not who did it. It is the blameless post-mortem of 04-05 applied to everyday life.

Culture is not decreed; it is produced by what management rewards, tolerates and ignores. If Marta publicly thanks someone for a report that turned out to be a false alarm, she has bought more security than any tool at that price.

Everything above converges here: an annual plan integrating the whole course, with an owner, a cost and an expected result, within 18,000 € and 440 hours of Lucía's time (of which around 300 are already consumed by the recurring calendar in section 4, so the project margin is about 140 h, plus the time of Iván, Marta and Sara).

How this plan is defended to management, which is what will get it approved: it is not presented as fourteen technical tasks, but as coverage of the worst-scoring risks in the register from 04-01. R-01 (ransomware via a third party, ALE 96,000 €) is covered in Q1-Q2 by four initiatives totalling 1,100 €. R-02 (destruction of backups) falls in Q2 for 400 €. R-06 (secrets) in Q1 for 300 €. R-03 and R-07 in Q3. An 18,000 € plan that directly attacks a far larger expected annual loss is a business conversation, not a budget request.

• Confusing activity with progress. Ten initiatives at 40 % feel excellent and reduce risk by close to nothing. Finish three.
• Writing the calendar without an owner or evidence. A task without an owner does not get done; a task without evidence cannot be shown to have been done. Both are equally fatal.
• Planning the year with 100 % of the time on new projects. If the recurring calendar consumes 300 of the 440 hours, planning 400 hours of projects guarantees that either operations collapse or the projects never finish. Reserve the operating time first.
• Measuring the easy thing instead of the thing that matters. "Hours of training delivered" is comfortable and says nothing; "phishing report rate" is uncomfortable and says a great deal.
• Treating automation as an end in itself. Automating a control nobody reviews produces a log nobody reads. Automate the execution and the failure notification.
• Tip: start with the calendar, not with the tool. If tomorrow you could only do one thing from this lesson, create the fourteen recurring tasks in section 4 with an owner and a date. It costs an hour and it changes the most.
• Tip: put an expiry date on everything temporary, systematically and without exception: most of any company's security debt is "temporary" from three years ago. And publish the dashboard even when it is red: the first month hurts; by the third, people start competing to turn it green.

Exercise 1 — From project to habit

Nimbus has just finished an initiative: the 40 laptops have been verified as having an encrypted disk and the evidence has been stored. Marta considers it closed. Explain why this control will have degraded within twelve months if nothing else is done, and set out three concrete mechanisms — one calendar-based, one automated and one based on secure defaults — that turn it into a habit. For each one, say what evidence it produces.

Exercise 2 — Redesigning a fragile practice

This is the current Nimbus practice for onboarding a new employee, as Sara executes it: "When someone joins, I let Lucía know over chat and she creates whatever accounts they need." Identify four failings in this practice from the point of view of sustainability and access control, and rewrite it in a format that survives Sara being on holiday, Lucía having a bad day, and an auditor's question six months later.

Exercise 3 — Prioritising with the budget exhausted

It is October. There are 1,800 € and 35 hours of Lucía's time left. Four requests are on the table: (a) a large customer demands answers to a 90-question security questionnaire before renewing; (b) the dashboard shows 2 expired exceptions and 1 unencrypted laptop; (c) Iván wants to migrate to a distroless base image across all services; (d) a critical vulnerability with a public exploit has appeared in a library the API uses. Rank them, justifying your criteria, and say what you would do with the hours and the money.

Exercise 1

Why it degrades. The control was verified against a snapshot of 40 laptops on one date. Within twelve months the following will almost certainly have happened: new joiners with newly purchased laptops (which arrive with encryption switched off or with an unescrowed recovery key), reinstallations after a hardware fault, the odd personal machine used temporarily "while the new one arrives" and the odd operating-system change. None of those situations has a mechanism that reactivates the control. The stored evidence will remain valid as proof of what was true that day, but it says nothing about the current state, and that confusion — historical evidence read as present state — is the underlying error.

Three mechanisms:

1. Calendar: a monthly entry in security-calendar.yml with Lucía as owner, 10 minutes, "verify encryption coverage of the estate against the inventory of active machines". Evidence: a monthly report with a numerator (encrypted), a denominator (active machines) and a named list of exceptions. It feeds indicator 3 on the dashboard.
2. Automated: a scheduled osquery query that reports each machine's encryption status to the inventory, plus an alert — not a report — when an active machine appears with encryption switched off or with an unescrowed recovery key. The difference between a report and an alert is the difference between detecting in 30 days and detecting in 1. Evidence: query history and alert log with closures.
3. Secure default: the MDM policy requires active encryption and an escrowed key as a condition for accessing e-mail and corporate resources. An unencrypted laptop stops being useful, so non-compliance becomes visible within hours and without anyone intervening. Evidence: export of the MDM policy and list of compliant/non-compliant devices.

The three are complementary: the third prevents, the second detects fast and the first demonstrates to a customer or an auditor. A fourth element closes the loop: include "verify encryption and key escrow" in the equipment handover checklist of the onboarding process, so as to attack the cause at source.

Exercise 2

Four failings:

1. There is no prior definition of which accesses belong to the role. "Whatever accounts they need" means Lucía improvises, and when in doubt she grants too much, which is exactly how least privilege and control C-18 die.
2. The trigger is a chat message, an ephemeral channel with no traceability that depends on Sara working that day. If Sara is on holiday, the onboarding is not triggered, or somebody else triggers it differently.
3. There is no recorded approval. Nobody with authority has said in writing that this person should have those accesses. It is the first thing an auditor asks for (06-04) and it does not exist.
4. There is no symmetry with offboarding. The onboarding process creates no record of what was granted, so on exit nobody will know what to revoke. It is the origin of the orphaned accounts in 02-05.

Rewritten practice:

What makes this version resilient: the trigger is a persistent artefact rather than a person; accesses are versioned profiles rather than improvised decisions; the approval is recorded; MFA and encryption are enforced by the system; there is explicit cover; and the process itself produces the evidence that offboarding, the half-yearly recertification and the auditor are going to need. Cost of setting it up: one afternoon.

Exercise 3

Order: (d), (b), (a), (c).

• (d) The critical vulnerability with a public exploit goes first under criterion 1 in section 7: it is on fire. A public exploit in an API library means that third-party automated scanning will find it within days — it is exactly the Equifax pattern. It consumes 8 hours of Lucía's and Iván's time (update, test, deploy, verify) and 0 €. It is neither negotiated nor planned: it is done today.
• (b) The two expired exceptions and the unencrypted laptop come next under criterion 3: free and quick. Formally closing or renewing two exceptions is 2 hours of Marta's time; encrypting a laptop is 1 hour. 3 hours, 0 €, and it turns two dashboard indicators green. What is more, if the customer in (a) asks about exception management, the answer will already be a good one.
• (a) The customer questionnaire is a business risk with a date, criterion 5. It consumes 20 hours and probably 0 € if answered in-house. And there is an implicit investment worth doing properly: in answering it, you build the reusable security pack from 06-04, so that the next questionnaire costs 4 hours instead of 20. That is the difference between spending and investing.
• (c) The distroless migration is deferred to next year's plan. It is a real, structural improvement, but no risk in the register depends on it urgently, there is no external date and it would consume all the remaining hours, leaving (a) undone. It is documented in the Q1 plan of the following year so it does not get lost — deferring is not discarding, and the difference between the two is writing it down.

Final allocation: 31 hours out of 35, and 0 € out of the 1,800. The leftover money is not spent for the sake of spending it: it is held back. If another critical appears in November requiring external help, having 1,800 € free is worth more than a year's licence for a tool nobody is going to operate. And if December arrives without it being used, it strengthens next year's budget request: an organisation that does not spend for the sake of spending is an organisation that gets trusted with a budget.

You have seen the thesis that holds up this whole module: security is not achieved through projects, it is sustained through habits, and the proof is that in almost every major incident — Nimbus's included — the organisation knew perfectly well what needed to be done. What was missing was not knowledge but a mechanism guaranteeing it kept being done. Hence the question that organises the lesson: not "have we done it?" but "what makes it keep being done a year from now?".

You know the eight hygiene practices — MFA, patching with a deadline, tested backups, least privilege, inventory, training and reporting, logging and alerting, encryption by default — and why they are enough for almost everything: statistically, because they explain the great majority of breaches, and economically, because they turn Nimbus into an expensive target for an opportunistic attacker. Along with the rule that sums the section up: the basics well maintained beat the advanced badly maintained, and with the detail that distinguishes real hygiene from apparent hygiene, which is the verification verb attached to each practice.

You have the six checklists by role — Marta, Iván, Lucía, Rubén, Sara and any employee — written to fit on a card and so that each person knows what falls to them without translating anything. You have the Nimbus security calendar as data in yaml, with the daily, weekly, monthly, quarterly, half-yearly and annual work, each task with an owner, a time and an expected piece of evidence; and the sum almost nobody does: 300 of the 440 hours are already committed to operating what has been built, which leaves 140 for improvement. You know how to automate the habit, turning each fragile practice into something the system enforces — blocking gitleaks, MFA that cannot be skipped, a pull request template, an MDM that requires encryption, ACME that renews — with the underlying principle that the secure option must also be the most convenient, and with the warning that a noisy automated control ends up ignored.

You know how to measure so as not to fool yourself with a ten-indicator dashboard, its targets, its sources and its automated calculation, and with the four rules that keep it honest — target before measuring, automatable source, publication even when red, trend over absolute value. You can work the PDCA cycle, the priority order when everything looks urgent and the rule of finishing before starting, which rests on a counter-intuitive fact: a half-done control is usually worth zero. You recognise the five organisational anti-patterns — the department of no, the project that ends, compliance as a substitute, the single person and buying without the capacity to operate — with the case of Lucía and the bus factor, and the question that must precede any purchase: who operates it, and with how many hours. And you can recognise real culture by observable behaviours, starting with the most important one: that people report their own mistakes the same day and without fear. All of it crystallised in the 12-month roadmap, fourteen initiatives with an owner, a cost and a measurable result, fitting exactly into 18,000 € and 380 hours and defended to management as coverage of the worst-scoring risks, not as a list of technical tasks.

That said, this calendar and this roadmap were decided by Nimbus on its own, looking at its own risk. And that freedom has a limit: there are things you do not get to choose. When a clinic asks whether Nimbus complies with the GDPR, when an institutional customer demands the ENS (Spain's National Security Framework), when the transposition of NIS2 reaches suppliers in regulated sectors, or when a contract requires an ISO 27001 certification, the conversation stops being about your own priorities and becomes one about other people's obligations with consequences attached. In Security Regulations and Standards (06-02) we lay out that map: what is legally binding and what is voluntary, what genuinely applies to an SME like Nimbus and what does not, what an ISMS and a Statement of Applicability really are, how much certification costs and how long it takes, and — most usefully — how a written obligation in legal language is translated into concrete work: requirement, policy, control and evidence.