The previous lesson ended with an uncomfortable observation: POL-02 says third-party access "must be named, with MFA and just-in-time" and POL-04 says devices "must keep disk encryption active", but neither sentence protects anything on its own. Somebody has to configure the MFA, check that the 40 laptops really are encrypted, verify it periodically and leave a record that they verified it. That "somebody doing something checkable" is the control, the third vertex of the triangle you close here: the risk says what can happen, the policy says what we require, and the control is what makes it true. You will finish with the two classifications you have to master, Nimbus's control catalogue as a reusable artefact, the metrics that distinguish an implemented control from an effective one, and the traceability matrix that saves an audit.

1. What exactly a control is and how it closes the triangle
2. Classification by nature: administrative, technical and physical
3. Classification by function: from preventive to compensating
4. Why a risk needs controls from several functions
5. Reference catalogues: CIS v8, ISO 27002 and NIST SP 800-53
6. How a control is selected, and the cost everyone forgets
7. Compensating controls: legitimate ones and excuses
8. Nimbus's control catalogue
9. Implemented is not effective: evidence, tests and metrics
10. The risk → control → evidence traceability matrix
11. Control drift: why controls degrade on their own

A security control is a specific measure, with an owner, that reduces the likelihood or the impact of a risk and whose operation can be checked. All three elements of that definition are equally mandatory: with no owner it is not maintained; if it reduces no identified risk it is decoration; and if it cannot be checked, you will never know whether it is still working.

And one point of vocabulary that avoids confusion: control, measure and safeguard are synonyms in practice. ISO 27002 says "control", CIS says "safeguard" and NIST says "control". What is worth distinguishing is a control from a tool: antivirus is a tool; "malware detected and contained on the endpoint, with the alert handled in under 4 hours" is a control. The tool without the process around it is not a control, it is a paid licence.

Three observations worth more than the table. The administrative ones are usually free and are the ones most often forgotten: of the 12 highest-return measures in 02-04, several of the zero-cost ones are administrative — the payment verification procedure, the quarterly review of third-party access or the written response plan. A technical control does not hold up without its administrative counterpart: installing MFA is technical, but deciding which accounts it is mandatory on, who authorises exceptions and who reviews coverage is administrative, and without that the coverage drops on its own with every new joiner. And Nimbus has little physical surface, not none: with half the staff remote, the relevant physical control is not the office door, but whether Iván's laptop is encrypted and locked in a café in Valencia.

This is the classification that genuinely changes decisions, because it describes at which moment of the incident the control acts.

Two points people get wrong. First: deterrent and preventive are not the same. A "CCTV in operation" sign deters; the lock prevents. In systems, the notice that the session is being recorded deters the consultancy's engineer from doing what they should not, but it does not stop them. Second: corrective and recovery are not the same either. The corrective removes the cause — you rotate the leaked credential; the recovery restores the state — you restore the database. Recovering without correcting leaves you restoring the same system over and over for the same attacker.

If you only prevent, you do not find out when prevention fails. And prevention always fails eventually: that is the premise of the "assume breach" principle from 01-03. Applied to the ransomware incident in 02-06, the breakdown by function shows exactly where Nimbus's hole was:

Nimbus had zero controls in five of the six functions, and that is the complete explanation of why an avoidable incident turned catastrophic. Notice the pattern: each function buys a different kind of time or harm. Prevention avoids the incident; detection reduces its duration — the variable that most determines the harm, according to the conclusion of 02-06; recovery decides whether the company survives. Hence the practical rule: every High or Critical band risk in the 04-01 register must have, as a minimum, one preventive control, one detective control and one recovery control. If, while filling in the catalogue, one of those three boxes is left empty for a Critical risk, you have found your next task with no further analysis.

Using a catalogue rather than inventing controls has three advantages: you do not forget whole categories, the vocabulary matches that of your customers and auditors, and each control comes with its written rationale. The drawback is that none of them is designed for 38 people, so you have to select.

The CIS implementation groups are the most useful contribution for an SME:

For Nimbus to set itself complete IG1 is a defensible, measurable and achievable decision, and it sounds far better to a customer than "we have various measures". Its 18 controls, with the ones that apply to Nimbus highlighted: asset inventory (1) and software inventory (2), data protection (3), secure configuration (4), account management (5) and access management (6), vulnerability management (7), audit logs (8), e-mail and browser protections (9), malware defence (10), data recovery (11), network infrastructure management (12), monitoring (13), training and awareness (14), supplier management (15), software security (16), incident management (17) and penetration testing (18).

And a warning: the catalogue does not replace your risk assessment. CIS orders by what happens to most people; your register orders by what happens to you. Start from the risk and use the catalogue so you forget nothing, not the other way round.

Step 4 is where almost every SME goes wrong, because they only count the licence. The real cost of a control has four components:

Those 150 hours a year are a third of the 440 Lucía has available for security. That is the cost that sinks security projects in SMEs: not the money, but the fact that the person who was supposed to do the other eleven measures spends the year reading alerts. The honest comparison is not "9,600 € against 900 € for MFA", but "9,600 € plus a third of the team's capacity, against 900 € plus two hours a month". Hence the derived rule: prefer the control that, once implemented, consumes no time. MFA, closing a security group, making a bucket immutable or WHERE tenant_id are controls that work on their own. Manual log review or case-by-case approval consume attention for ever, and attention is Nimbus's scarcest resource.

A compensating control replaces a required control that cannot be implemented, providing equivalent protection by another route. It is legitimate when the impossibility is real and documented, the alternative protection is comparable in effectiveness, it is approved at the right level with an expiry — it is an exception under 04-02 — and it is verified like any other control. The Nimbus case: separation of duties is impossible. The principle from 01-03 requires that whoever develops does not deploy to production unsupervised, and that whoever administers the systems is not the same person who reviews their own access. With a single systems administrator, that cannot be met: Lucía creates accounts, assigns them to herself, reviews the log and approves her own changes.

And the contrast, because half the compensating controls you see in practice are excuses:

The difference is that the legitimate one names the specific impossibility, describes a specific protection and has a date; the excuse invokes an inconvenience and offers a generic control that already existed anyway.

The module's second reusable artefact. Field template:

Four controls written out in full, one from each main function:

The rest of the catalogue, in summary form:

Three readings of the catalogue as a whole, which is where its value lies. First: counting statuses, only 7 of the 22 controls are implemented, so any residual risk in the 04-01 register that assumes the other 15 is miscalculated — remember the rule from 04-01: the residual is scored against the verified state. Second: there are 8 controls with a detective function and only 2 implemented (C-07 and C-21), which is exactly the blindness that produced the 20 days in 02-06. Third: the administrative controls are almost all free and almost all "planned", which confirms the conclusion of 02-04 that Nimbus is not short of budget, it is short of allocated time.

The difference is not academic: MFA enabled on 9 of 14 privileged accounts does not reduce the risk by 64 %, it reduces it almost not at all, because the attacker will go for one of the remaining 5. Controls are measured by coverage, not by existence.

Evidence is something you can show and that has a date: the export of the list of accounts with MFA, the restore test report, the minute of the monthly review. A test is the deliberate exercise of checking that the control acts: injecting a large transfer to see whether C-08 fires, or genuinely restoring the database to see whether C-14 works and how long it takes. Hence the rule that sums up this section: a control that has never been tested is in "planned" status, whatever those responsible for it say, and that is why C-08 appears with last_verified: null.

A KPI measures whether the control works; a KRI warns that the risk is growing. Nimbus's four minimum indicators:

Three details of the code that are measurement decisions, not programming ones. The encryption denominator excludes decommissioned devices, because including them flatters the indicator — and choosing the denominator is where almost every security metric gets falsified. MFA is measured including service and third-party accounts: it is precisely ci-deploy, consultora-01 and backup-svc that are missing, which is to say exactly the 02-06 vector. And patching uses the mean, which hides the 14-day case; on a real dashboard it is worth showing the 90th percentile or the worst case alongside it, because the attacker exploits the worst case, not the mean.

The append-only audit table from the previous modules lets you check that C-07 is still recording what it should:

The first query is the most important and the one almost nobody writes: watch the watchman. A detective control that stops emitting events fails in silence, and silence gets read as calm. The third measures the coverage of the control, which is the difference between implemented and effective applied to logging.

This table is what you show in an audit, and it is what saves it (06-04). Not because it impresses, but because it answers on one page the three questions any auditor or customer asks: which risks have you identified, what do you do about each one and how do you prove it. Read it as a diagnostic tool too. The "Gap" column fills itself in by applying the rule from section 4 — preventive, detective and recovery for every High or Critical risk — and produces the quarter's work list with no further discussion: R-02 has no way of finding out that the backups are being deleted, R-05 has no way of knowing that somebody has fallen for a fraud, and R-06 has a control nobody has ever tested.

A control implemented and verified today will not still be working a year from now if nobody looks at it. No attacker is needed: the company's normal activity is enough.

Conclusion number 2 of the case studies in 02-06 said that in almost every incident the control existed and did not work: Target had alerts, Equifax had traffic inspection, Colonial had a VPN. Drift is the mechanism by which that happens, and the antidote is the frequency field in the catalogue. A control with no verification frequency is not a control: it is a memory of having done something.

• Confusing a tool with a control. Buying an EDR is not having malware defence; it is having a licence. Tip: define each control by its observable outcome, not by the product.
• Implementing with no owner. Orphan controls are the first to drift. Tip: the owner field is a person, and if there is no candidate, the control is not ready to be implemented.
• Scoring the residual risk with unverified controls. This is the direct link to the equivalent mistake in 04-01. Tip: status: Implemented requires a dated last_verified.
• Accumulating only preventive controls. This is Nimbus's imbalance, with 8 detective controls of which only 2 are implemented, and the cause of the 20 days of blindness in 02-06. Tip: review the catalogue by function, not by risk.
• Forgetting the operational load. A control that consumes 150 hours a year is abandoned in month four and stays in the catalogue as implemented. Tip: include the recurring cost in the decision and prefer what works on its own.
• Metrics with a convenient denominator. Measuring encryption over "the laptops we manage" rather than over all of them is make-up. Tip: define the denominator before calculating the numerator, and write it down.
• Confusing completing the catalogue with being secure. Covering the whole of IG1 is excellent and does not mean your main risk is treated. Tip: the catalogue prevents oversights; the risk register sets priorities.
• Compensating controls with no expiry. A permanent compensating control is a permanent exception. Tip: apply the same rules as the exceptions register in 04-02.

For each control, state its nature and its main function, and say which risk from the 04-01 register it treats:

1. A banner marking e-mails that come from outside.
2. Restoring the database from the immutable backup.
3. A six-monthly review in which each lead confirms their team's access.
4. Automatically blocking a code merge if the scanner finds a secret.
5. Immediate rotation of an API key published by mistake in the repository.
6. An alert when an administrative account connects outside the 08:00-20:00 window.

Then take risk R-05 (BEC fraud) and propose the detective and recovery controls it is missing according to the matrix in section 10.

Nimbus is torn between two investments to treat R-04 (attachment leak):

Calculate the total annual cost of each option valuing an internal hour at 35 €, calculate the ROSI of each with the method from 04-01 and recommend one. Also state which function each option covers and whether, with it, R-04 would meet the rule in section 4.

You review another company's control catalogue and find: 34 controls, all with status: Implemented; none with a last_verified; 28 preventive, 6 detective, 0 recovery; the owner of 30 of them is "IT"; and there are 4 compensating controls with no expiry, one of them justified with "the manufacturer does not support MFA". State what each symptom reveals, what you would ask to confirm it and in what order you would correct it.

Exercise 1

Note number 3: it is the classic example of a control with two functions, which is why the catalogue's function field is a list. And number 1: many people would classify it as preventive, but the banner stops nothing — the user can still click; its effect is to change behaviour, which is the definition of a deterrent.

R-05 is missing: a detective control — an automatic alert on any change to a supplier's or customer's bank details in the invoicing system, plus a monthly review by Sara of bank account changes — and a recovery one: a documented procedure for recovering a fraudulent transfer, with the bank's direct contact, the real claim deadline and the police report, all of it written before you need it. That last one costs nothing and is exactly the kind of control nobody has until the day they need it.

Exercise 2

Total annual cost:

• Option A: 7,200 € + (15 h × 35 €) = 7,725 € in the first year; recurring = 7,200 € + (3 h/week × 48 weeks × 35 €) = 7,200 + 5,040 = 12,240 €/year.
• Option B: (40 h × 35 €) = 1,400 € in the first year; recurring = (12 h × 35 €) = 420 €/year.

ROSI against the ALE of 19,200 €, using the recurring cost:

• A: saving = 19,200 × 0.45 = 8,640 €. ROSI = (8,640 − 12,240) / 12,240 × 100 = −29 %. The control costs more than it saves.
• B: saving = 19,200 × 0.60 = 11,520 €. ROSI = (11,520 − 420) / 420 × 100 = +2,643 %.

Recommendation: option B, and the margin is so large that no reasonable correction of the estimates changes it. Notice where the difference lies: not in the licence, but in option A's 3 hours a week, which add up to 5,040 € a year of Lucía's time — and, worse, 144 hours out of her 440 available. It is exactly the mistake in section 6.

Functions: option A is mainly detective (it sees data leaving and warns); option B is mixed, because the authorisation tests in CI are preventive and the SQL alert over the audit table is detective. With B, R-04 would have preventive (C-05, C-06 and the new tests) and detective (C-07 plus the alert), but it would still have no recovery control, and in a data leak the recovery is not restoring anything: it is the response and notification plan in 04-05. So the complete answer is "B, and you also have to write the notification procedure".

Exercise 3

Order of correction: 1 → 2 → 3 → 4 → 5. First verify a sample, because until you know what is true everything else is speculation — and you will probably discover that several "implemented" controls do not exist. Then cover recovery, which is what decides whether the company survives an incident. Then detection, which reduces its duration. Then assign owners, without whom everything above will drift within a year. And finally, formalise the compensating controls with an expiry. On the one that says "the manufacturer does not support MFA": it may be legitimate, but only if it comes with short-lived credentials with minimal scope, an alert on anomalous use and a replacement date for the system; without that, it is the excuse from section 7.

You have closed the triangle. You know that a control is a specific measure, with an owner, that reduces likelihood or impact and whose operation can be checked, and that without all three elements at once what you have is decoration. You also know how to tell a control from a tool: antivirus is a licence; "malware contained with the alert handled in under 4 hours" is a control.

You have the two classifications. By nature — administrative, technical and physical — with the observation that the administrative ones are usually free, are the ones most often forgotten and are what holds the technical ones up. And by function — deterrent, preventive, detective, corrective, recovery and compensating — with the two distinctions almost everyone confuses: deterring is not preventing, and correcting the cause is not restoring the state. Hence the rule that reorganises Nimbus's work: every High or Critical risk needs at least one preventive, one detective and one recovery control, because each function buys something different — avoiding the incident, shortening its duration or surviving it — and because the breakdown of the 02-06 ransomware showed zero controls in five of the six functions.

You know the reference catalogues and what using one is for: CIS v8 with its implementation groups and IG1 as a realistic and sufficient target for Nimbus this year; ISO 27002 with its four themes when certification comes into play; NIST SP 800-53 as a disproportionate option for an SME. And the warning that goes with them: the catalogue prevents oversights, but it is your risk register that sets priorities. You know how to select a control weighing effectiveness, user impact, dependencies and above all total cost, including the recurring operational load that is what really sinks security projects in an SME: 150 hours of alerts a year are a third of Lucía's capacity. Hence the preference for controls that, once in place, work on their own. And you know when a compensating control is legitimate — real impossibility, comparable protection, approval with an expiry and verification — and when it is an excuse, with Nimbus's honest case: separation of duties is impossible with a single administrator, and it is compensated with Marta's monthly review, approval of privileged grants, deployment exclusively through CI and an annual external audit.

You take away Nimbus's control catalogue with its 22 entries mapped to CIS IG1, whose three whole-catalogue readings are worth more than any single entry: only 7 are implemented, of the 8 detective ones only 2 are, and the administrative ones are free and almost all still pending. And you take away the decisive distinction between an implemented control and an effective one, with its metrics calculated — 57 % MFA, 92 % encryption, 7.3 days to patch, 23 days since the last restore — with the three measurement decisions the code hides (the honest denominator, including the service accounts that are precisely the 02-06 vector, and the fact that the patching mean hides the worst case which is the one the attacker exploits), and with the SQL query that watches the watchman, because a detective control that stops emitting events fails in silence and silence reads as calm. The lesson closes with the risk → control → evidence traceability matrix, which is what you show and what saves an audit because it answers any auditor's three questions on one page, and with drift: an implemented control degrades on its own through growth, technical change, forgotten exceptions, turnover, fatigue or silent failure, and the only antidote is the verification frequency.

But go through the catalogue once more and you will see there are controls whose effectiveness does not depend on Nimbus. C-03 requires just-in-time access from a consultancy that has its own processes and its own security. C-19 replicates backups to a region belonging to a provider whose decisions nobody at Nimbus controls. The code the CI deploys drags in hundreds of dependencies written by strangers. And the vector of the incident in 02-06 was not a Nimbus failure: it was a breach at the consultancy that Nimbus never even got to hear about.

In the next lesson, Third-Party and Supply Chain Risk (04-04), you will see why the perimeter includes companies you do not control and why execution can be outsourced but responsibility never can: Nimbus's third-party map, the return of the consultancy from 02-06 with a full analysis of what should have existed and what it really costs, the supplier life cycle including the exit phase everybody forgets, a due diligence questionnaire proportionate to the size of the supplier, the essential contractual clauses, the shared responsibility model in the cloud and the software supply chain with SBOM and dependency pinning.