The previous lesson closed by pointing at a pattern: behind every control, every piece of evidence and every finding there is a person who does or does not do something. Lucía knew where everything was; the out-of-flow account creation happened because somebody was in a hurry on a Sunday; the runbook fails because only one person knows what is not written in it. No traceability matrix corrects that. This lesson deals with the factor that remains the main vector of incidents and, at the same time, the best defence there is when it works: people. And it does so from an uncomfortable premise: the objective is not for people to know. The objective is for them to do, and above all to report.

Validation note. This area has employment law and data protection implications: whether training is compulsory, the attendance register, the processing of data from phishing simulations and the disciplinary consequences all vary with the collective agreement, the contract and the applicable rules, and in many cases require prior information to staff or consultation with employee representatives. This is training material, not legal advice: validate it with employment counsel and with the Data Protection Officer before implementing it (see 06-03).

1. Why this is not "the compulsory annual talk"
2. Awareness, training and culture: three different things
3. What each Nimbus role needs to know and do
4. The annual programme, designed to fit an SME
5. Onboarding and offboarding: the person's life cycle
6. Channels and formats that work (and those that do not)
7. Phishing simulations done properly
8. The report button and the response loop
9. Just culture: why blaming destroys detection
10. Measuring the programme: behaviour versus vanity
11. Security champions and training for development
12. Management gets trained too

In 02-03 we looked at social engineering as an attack technique, and the conclusion was devastating: it does not exploit a technical flaw, it exploits the human disposition to help, to obey and to avoid trouble. Industry reports agree year after year that a very high proportion of breaches involve the human element — error, credential misuse, phishing or social engineering — and the 02-06 incident was no exception: the attacker came in through a third party's credential that nobody reviewed, and on day 16 an anomalous-cost alert landed in Lucía's inbox and was marked "review later" among two hundred other e-mails.

Against that, the usual organisational response is a four-hour annual course with a final test. And it does not work, for four reasons worth being clear about before designing anything:

• The forgetting curve. Without reinforcement, retention from a long session drops sharply within days. By month 11 of the year, January's training is indistinguishable from not having done it.
• Knowing is not doing. Everybody knows they should not reuse passwords. Half do it anyway. Knowledge does not change behaviour on its own, especially under pressure.
• The wrong moment. You train in January and the attack arrives in September, in the middle of a launch, in a hurry, from a mobile. Decontextualised learning does not activate at that instant.
• It teaches people to fear the mistake rather than report it. The graded final test, the list of who passed and the tone of "don't be the one who falls for it" produce the opposite of the intended effect: whoever falls for it will keep quiet.

The change of objective that organises the whole lesson. It is not about nobody ever falling for it — that is impossible: a well-made phishing e-mail fools anybody at the right moment — but about when somebody does fall for it, it being known within minutes. Compare the two scenarios at Nimbus:

The sentence that sums up the lesson and is worth repeating in every micro-lesson: the mistake is not the incident; the silence is.

They get used as synonyms and they are three layers with different objectives, formats and horizons. Confusing them explains why many programmes fail: training gets bought when what was needed was awareness, or culture is expected from a short course.

All three are necessary and none replaces another. Awareness without training produces frightened people who do not know what to do. Training without awareness produces knowledge that fades in three weeks. And both without culture produce people who know the right thing and do the opposite because the environment rewards speed and punishes questions. Culture, moreover, is not taught: it is inferred from what management rewards, tolerates and ignores — we will come back to this in section 9.

A programme aimed at "everyone" ends up generic and therefore forgettable. The starting point is a needs analysis: for each profile, which risks they face and what they must be able to do.

Two design criteria avoid the most common error. First: the learning path is defined by what the person must do, not by what it would be nice for them to know. Rubén does not need to know what a brute-force attack is; he needs to know that a contact e-mail address is never changed without verification through the registered channel. Second: the common baseline is genuinely common, and short. Four hours on joining plus a micro-lesson a month is all that is asked of somebody whose job is not security, and it is enough if those hours are well spent.

The budget and the time are the usual ones: part of the 18,000 € and a limited number of hours from each person. The programme is designed around that constraint from the start, not as an aspiration that is trimmed afterwards.

Why short, frequent micro-lessons instead of a four-hour annual course. It is not an aesthetic preference, it is spaced learning: repetition distributed over time retains far more than the same amount of content in one block. And there are three practical advantages for an SME: it costs less time in aggregate (10 minutes a month is 2 hours a year against 4 in one go), it allows you to react — if a phishing campaign targeting the sector appears, that month's micro-lesson is about it — and it keeps the subject alive, which is literally the definition of awareness.

The moment of greatest risk and greatest opportunity is joining. The new employee does not know the rules, cannot tell a legitimate internal e-mail from a fake one, does not know the faces or the voices and is keen to make a good impression — the perfect combination for social engineering. Picking up the identity life cycle of 02-05, now from the training angle:

Two day-0 details that change the outcome. The first: POL-04 is accepted and signed before the first access, not in month two. It is the disciplinary basis and the evidence for 06-04, and its date must precede any use of the systems. The second: MFA and the password manager are installed with someone alongside, not with a link to a manual. Adoption of a tool collapses if the first experience is frustrating, and the password manager is the only tool in this lesson whose use can be measured directly.

Leaving has a training element almost nobody does: the exit conversation. In addition to revoking access within 24 hours and returning equipment, it is worth reminding the person in writing, and in a non-threatening way, of the duty of confidentiality over what they know — customers, architecture, vulnerabilities — and asking what they know that is not written down. That last question, put to Lucía on the day she left, is the only real mitigation of R-09 that costs no money.

And the role change is the forgotten link. When Rubén moves from support to pre-sales, the usual thing is to add the new accesses and not remove the old ones: that is the privilege accumulation of 02-05, and it is corrected by treating a role change as a leaver followed by a joiner, with the corresponding training.

The contextual prompt is the format with the best return and the most underused. It costs little and it acts at the instant that matters: the [EXTERNAL] banner on e-mail from outside the domain, the warning when attaching a file containing personal data for an external recipient, the reminder in the panel when somebody is about to export more than 500 records, or the extra confirmation when changing a supplier's bank account. None of these teaches anything; all of them change behaviour, which was the point.

Why bought generic material usually fails. A video with actors in an office that looks nothing like yours, talking about an abstract threat, produces formal compliance and zero change. The eight-minute video in which Marta tells the story of the 02-06 incident — what the attacker did, which alert was ignored on day 16, what MFA would have changed — is worth ten bought courses, because it is their company, their data and their faces. The practical rule: buy the framework if it saves you time, but produce the examples yourself, and budget a couple of hours a month to do it.

It is the most powerful tool in the programme and the one that does the most damage when misused.

The objective, declared and communicated from the start: to measure and train reporting, not to hunt culprits. If staff perceive the simulation as a trap for singling out whoever fails, they will learn exactly one thing: not to say anything. That outcome is worse than running no simulations at all.

Campaign design by difficulty. You start easy and go up, so that people see progress and so that the figures are interpretable:

The ethical rule, which is not negotiable. Lures that exploit personal vulnerability or legitimate anxiety are not used. Prohibited: payslips, bonuses, redundancies or collective dismissals, welfare benefits, medical results, family matters, real emergencies and any impersonation of a colleague identifiable by name. The reason is not only ethical: a cruel lure always works — so it measures nothing — and it causes damage to trust that takes years to repair. A simulation announcing a non-existent pay rise may get an 80 % click rate and have destroyed the entire programme.

What happens with whoever falls for it. Immediate, brief training in the moment: on clicking, a page that explains in 60 seconds what the specific signals in that e-mail were and how to report next time. Nothing else. Never a public list, never an e-mail to their manager, never a note in their performance review. And if somebody falls for it repeatedly, the conversation is individual, private and helpful: it almost always reveals a contextual problem — they work under pressure, they receive hundreds of legitimate external e-mails, they hold a post that requires opening attachments from strangers — which is solved with a technical measure, not with a reproach.

Validation note. Simulations process staff personal data (who clicked, when, from which device) and have employment implications. They require a lawful basis, clear prior information that simulations will take place and for what purpose, minimisation — working with aggregated data wherever possible — a short retention period and, frequently, information to employee representatives. Check it with the DPO and with employment counsel (06-03).

The right metrics. Here is the sector's most widespread error: looking only at the click rate. Three Nimbus campaigns:

How to read this table, which is what separates a useful programme from theatre. A naive reading would say the programme got worse: the click rate went up from 21 % to 31 % in the last campaign. The correct reading is the opposite, for three reasons. First, the difficulty went up: the third campaign was a targeted, credible lure, and comparing its click rate with that of a crude lure makes no sense. Second, the report rate more than quadrupled, from 15.8 % to 69.2 %: two out of three people now raise the alarm. Third, and this is the decisive figure, the time to first report fell from 47 minutes to 4. That means that in a real attack Lucía would be alerted before the attacker had finished authenticating, and could revoke the session and force a credential change while the attack was still in progress. And the credentials entered — the only figure that measures real damage — fell from 4 to 0.

The conclusion, worth writing down before the first campaign: the click rate measures the difficulty of the lure; the report rate and the time to first report measure the health of the programme. If you can only track one number, track the time to first report.

Everything above rests on a mechanism that has to be trivial. If reporting takes more than two seconds or raises doubts about whether it is a nuisance, it will not be used.

Requirements for the reporting channel, in order of importance:

1. A single gesture: a button in the e-mail client that forwards with full headers and files the message. None of this "forward it to security@ with the subject in this format".
2. Available where the risk occurs: in e-mail, on the mobile and also for what is not e-mail — an odd phone call, a USB stick found on the floor, a suspicious website — with an equally simple alternative channel.
3. A response always, and the same day, even for a false alarm. A report with no response is a report that will not be repeated.
4. Explicit thanks, without exception. Including when it was clearly legitimate marketing.
5. No emotional friction: no forms asking "did you click?" in an interrogating tone. If they did click, that is the most valuable information of all and it must be made easy to give.

Two consequences of this loop usually come as a surprise. The first: false positives are a good sign, not a nuisance. Somebody who reports a legitimate newsletter is using the mechanism, and the right response is to thank them. An organisation with no false positives does not have a finely tuned channel: it has a channel nobody uses. The second: the volume of reports is an indicator of trust, not of threat. If reports halve, the most likely hypothesis is not that there is less phishing.

Just culture distinguishes between human error — which is met with reassurance and corrected by design — risky behaviour — which is coached — and reckless or deliberate conduct — which does have consequences. The distinction matters because 95 % of what happens in security is the first kind.

The economic argument for just culture, for anyone who needs one that is not moral. Punishing whoever falls for it marginally reduces the click rate — people become somewhat more cautious — but it drastically reduces the report rate, because the personal cost of admitting the mistake shoots up. And since the damage from an incident grows with the exposure time — the 20 days of 02-06 — the balance is clearly negative: you trade a few avoided clicks for an enormous increase in detection time. Blaming the person who falls for it is, literally, buying blindness in exchange for nothing.

This connects directly with the blameless post-mortem of 04-05: the same logic applied there to technical incidents — asking what in the system allowed the failure, not who committed it — applies here to everyday mistakes. And with the culture signal from 06-01: people report their own mistakes without fear. If that does not happen, no training programme is going to fix it, because the problem is not in what people know.

The ones on the left are not useless: they are compliance evidence for 06-04 and for article 32.4 of the GDPR, and they have to be kept. But they say nothing about whether the programme works. The ones on the right do, and three deserve comment:

• No. of preventive queries. It is the most ignored indicator and probably the best. When somebody asks "can I send this export by e-mail?" before doing it, the programme has won. It is trivially counted in the security inbox, and its growth is the earliest sign that the culture is shifting.
• Incidents caused by human error. It must be read carefully: early in the programme it rises, because more get reported. That rise is good. What you have to watch is the average severity and the detection time.
• Password manager usage. It is the only behaviour in this lesson that is measured objectively and continuously, with no surveys and no simulations.

Presented as a programme dashboard, feeding the one from 06-01:

Security champions. This is the cheapest way to scale without hiring: one person from each team who devotes a small percentage of their time to being the security point of contact for their area. At Nimbus, with 38 people, two are enough: Iván in development and somebody from support or administration.

What a champion does: they are the first person asked, they review PRs flagged as sensitive, they bring security news to their team in their own language and they pass the real friction upwards — which control is getting in the way and why people route around it — which is information Marta would not obtain any other way. What a champion is not: not the team's security lead, not the person who fixes everything, and not a title with no time allocated. They need explicit hours (2-4 h a month), additional training and visible recognition.

Training for development with our own code. Here lies the difference between a workshop people remember and one they forget. Compare:

The exercise in the last row is the most valuable in the whole technical programme and it costs half an hour: each developer deliberately breaks a control — removes the tenant filter, commits a secret, adds a vulnerable dependency — and checks that semgrep, gitleaks and pip-audit stop them. They learn two things at once: what real flaws look like and that the safety net exists and works. And along the way it generates evidence that the AppSec CI of 05-05 does what it says.

This is the most common gap: all staff get trained and management is assumed to know already. But Marta does not need to know what an IDOR is; she needs to decide well with incomplete information, and that is trained too.

What Marta needs:

• To read a risk register and decide: to understand ALE, residual risk and appetite well enough to choose between mitigating, transferring, avoiding and accepting, and to know that accepting is a legitimate option if it is documented.
• The legal framework that affects her personally: management liability under NIS2, GDPR obligations, the 72-hour deadline and the requirement for management bodies to be trained.
• To chair a crisis: the half-yearly tabletop is not for the technical team, it is above all for her. Deciding on incomplete information, authorising a service outage, talking to customers.
• To recognise when she is being sold hot air: knowing to ask "when was this last tested and where is the report?" of any supplier and of any internal report.
• Setting an example: if Marta asks for an MFA exception "because she is in a hurry", the whole programme loses credibility in a day. Management that skips its own controls teaches more than twelve micro-lessons.

How risk is presented to her so she decides well. Not with CVSS or vulnerability names, but in business terms and with a concrete decision on the table:

The rule: every report to management ends with a decision requested, its cost, its deadline and the consequence of doing nothing. A report with no decision requested is information; with one, it is management.

• Using the click rate as the headline indicator. It measures the difficulty of the lure, not the health of the programme. Look at the report rate and, above all, the time to first report.
• Using cruel lures. Payslips, redundancies, benefits or medical results always work — and that is why they measure nothing — and they destroy the trust that sustains the whole programme.
• Publishing who fell for it. It guarantees the next mistake is kept quiet. Immediate, private, brief training; never a public list.
• Buying a generic catalogue and calling it a programme. The video with actors in somebody else's office produces formal compliance and zero change. Buy the framework, produce the examples yourself.
• A four-hour annual course. The forgetting curve switches it off within weeks. Short, frequent micro-lessons retain far more for the same total time.
• Naming security champions with no hours allocated. It is a title with no effect and guaranteed frustration. Without an explicit 2-4 h a month, it does not exist.
• Not training management. They take the most decisions and, since NIS2, carry the most legal liability. And they do the most damage to the programme if they skip their own controls.
• Tip: if you can only do one thing, put in the report button and answer every report the same day with a thank you. It costs an afternoon of configuration and 10 minutes a day, and it is the best dwell-time reduction per euro there is.
• Tip: use your own incidents. The Nimbus case told by Marta in eight minutes is worth more than any bought material. Anonymise the protagonist, never the lesson.
• Tip: measure password manager usage. It is the only behaviour that can be observed continuously and objectively, with no surveys and no simulations.

Exercise 1 — Redesigning a badly framed simulation

Sara proposes the following campaign: an e-mail apparently from the payroll bureau with the subject "Payslip review: change to your January IRPF (income tax) withholding" and a link to a fake portal asking for corporate username and password. She proposes publishing in the general channel the list of those who entered credentials "so it serves as a warning", and measuring success by the reduction in click rate compared with the previous campaign.

Identify four problems — ethical, legal and design — and redesign the whole campaign: the lure, the prior communication, what happens on clicking, what is published and which metrics are used.

Exercise 2 — The programme for a new joiner

Nimbus hires a developer who starts in two weeks and will work remotely from another city. Design her plan for the first 30 days from a security point of view: what happens before the first access, what in the first week, what in the first month; who does each thing; what evidence is left; and what is done differently because she is remote and because she is in development.

Exercise 3 — Reading the data from three campaigns

Marta looks at the table in section 7 and says: "In 2027-Q1 we have got worse: the click rate has gone up from 21 % to 31 %. I propose making the course compulsory again and warning that the next person who falls for it will have a conversation with their manager."

Answer Marta with a correct analysis of the data, explain why her proposal would make the results worse and propose three concrete actions for the next quarter, with their cost and the indicator each one should move.

Exercise 1

Four problems:

1. A lure prohibited by the ethical rule. Payslips and income tax touch personal financial security. A lure like that works almost every time, so it does not discriminate between the attentive and the inattentive: it measures nothing. And it causes disproportionate damage to trust — people feel their employer has used their salary as bait.
2. Publishing the list is unacceptable on several levels at once. Ethically it is public humiliation. Legally it is processing of personal data with no adequate basis and with a very high risk of internal reputational harm, besides having obvious employment law implications. And operationally it is counterproductive: it guarantees that the next real mistake is hidden, which is exactly the opposite of the objective.
3. The metric is wrong. The click rate depends on the difficulty of the lure and says nothing about the ability to respond. The report rate and the time to first report are missing, and those are the ones that correlate with damage avoided.
4. The prior communication and the basis for processing the data are missing. There is no record that staff have been informed that simulations are run, for what purpose, what data is collected or how long it is kept; nor is there any record of consultation with employee representatives where applicable.

Redesigned campaign:

• Beforehand (once, at the start of the programme). A communication to all staff: periodic simulations will be run, their purpose is to measure and improve the collective ability to detect, individual results are not communicated to managers or used in performance reviews, the data is handled in aggregate and kept for a short, declared period. Validated with the DPO and with employment counsel, with whatever prior information is required.
• Lure (level 2, contextual). Impersonation of a real company supplier — for example, a notification from the invoicing platform asking you to review a document. It is plausible, it makes sense in a work context, it discriminates well between attention and carelessness, and it touches nothing personal.
• On clicking. An immediate 60-second page: "This was a Nimbus simulation. These were the three signals: the domain was facturacion-portal.example and not the usual one, the greeting was generic and the link did not match the text. There is nothing wrong with having clicked: what matters is reporting. Here is how, in two seconds: [button]". No record visible to the user, no note, no communication to anyone.
• If somebody enters credentials. The page says so clearly and adds an actionable instruction: change your password now and check your MFA. Plus an internal note for Lucía: if this had been real, this is the number of people whose session would have to be revoked, which is the figure that feeds the runbook.
• What is published. Only aggregated results, in the general channel and in a team tone: "69 % reported, first alert in 4 minutes, zero credentials. Thanks to the 27 of you who reported it." Public recognition goes to whoever reports first, never to whoever fell for it.
• Metrics. Report rate, time to first report, credentials entered and the trend against campaigns of the same difficulty level. The click rate is recorded but always read alongside the level of the lure.

Exercise 2

Before the first access (days −5 to 0), owned by Sara with Lucía:

• An onboarding ticket with the "development" profile approved by Marta — versioned profiles, not individual accesses (06-04).
• Laptop prepared and shipped with disk encryption active, the recovery key escrowed, enrolled in the MDM, no administrator account for daily use and the password manager pre-installed. Because she is remote, it is sent before the start date so there is not a single day of work from a personal machine.
• Reinforced identity verification for remote handover: account activation and second-factor registration are done on a video call with Sara and with the contract already signed. It is the most delicate point of remote onboarding: nobody has seen this person in an office, and an impersonation at this moment hands corporate credentials to a stranger.
• POL-04 acceptance signed before the first access. Evidence: a dated register entry.
• MFA mandatory: the SSO does not allow onboarding to complete without a second factor.

First week, owned by Sara (baseline) and Iván (role):

• A 2-hour onboarding session live on a video call, not a recorded video: remotely, the initial human contact is what makes her willing to ask questions later.
• Common baseline content: the password manager with guided migration, how to recognise a suspicious e-mail, how to report (with a real test: she reports a sample e-mail on day one and gets an answer), what customer data she can see and what she cannot export.
• Who to ask, with names and channels, and the explicit message that asking is never a nuisance. Remotely this has to be said out loud, because the barrier to interrupting is higher.
• No access to real customer data until onboarding is complete. She works against the pre-production environment with pseudonymised data (03-07, 06-03).
• Development-specific: repository access with CODEOWNERS, pre-commit configured with gitleaks, a walk-through of the 05-05 review checklist and of POL-07.

First month:

• The 02-06 incident told in 8 minutes by Marta. It is what gives meaning to all the preceding rules.
• OWASP workshop with the Nimbus codebase (section 11), including the exercise of breaking a control and checking that CI stops her.
• A first, unscored phishing simulation, explicitly presented as practice.
• Introduction of Iván as the security champion for her area.
• Access review at 30 days: check that the profile granted is the one she actually uses, and withdraw whatever is surplus. It is least privilege applied at the one moment when it is easy to do.

What is done differently because she is remote: reinforced handover and identity verification; access exclusively over WireGuard (05-04) with assisted installation; an explicit rule about home and public wifi, and about not sharing the machine with family; and a follow-up conversation after two weeks, because a remote person does not absorb by osmosis what gets said in the office and is the one most easily left outside the culture.

Evidence that remains (for 06-04): the onboarding ticket with approval and profile, signed acceptance of POL-04 dated before the first access, the record of MFA being enabled, the MDM report showing the machine encrypted with the key escrowed, the attendance register for the onboarding session and the workshop, and the minutes of the 30-day access review.

Exercise 3

Reply to Marta.

"The data says the opposite of what it looks like. The click rate is not comparable between campaigns of different difficulty: the one in Q1 2026 was a basic lure with an obvious domain and generic urgency; the one in Q1 2027 was a targeted lure, with no mistakes and referencing a real internal project. That only 31 % fell for a lure like that is a good result, not a bad one.

What is comparable, because it measures capability rather than difficulty, is the following. The report rate went from 15.8 % to 69.2 %: it has more than quadrupled and today two out of three people raise the alarm. The time to first report fell from 47 minutes to 4: in a real attack we would be alerted before the attacker had finished authenticating, with time to revoke the session and rotate the credential while the attack is still in progress. And the credentials entered went from 4 to 0, which is the only number that measures real damage.

Translated into what matters to us: in the 02-06 incident it took us 20 days to find out. Today, facing the same vector, we would be alerted in 4 minutes.

On your proposal, I would ask us not to do it, for three reasons. An extra compulsory course would not move these numbers, because the problem was never knowledge: people already know what phishing is and even so 31 % fall for a good lure — and they will keep falling for it, because a sufficiently good lure fools anybody. Announcing consequences for whoever falls for it would destroy precisely the number we have managed to move: today people report in 4 minutes because they are not afraid to say so; the moment there is a conversation with their manager involved, they will hesitate for a few minutes, then an hour, then keep quiet. We would trade a few avoided clicks for a return to blindness. And the risk that hurts us is not the click, it is the time until we know: that is what determined the severity of 02-06."

Three actions for the next quarter:

And one framing action that costs nothing: establishing that campaigns are always compared against others at the same difficulty level, and publishing the level alongside the result. Half the bad decisions about awareness programmes come from comparing numbers that are not comparable.

You have seen why security training is not "the compulsory annual talk" and why the four-hour course with a final test fails: the forgetting curve, the distance between knowing and doing, the wrong moment and — worst of all — that it teaches people to fear the mistake rather than report it. Hence the change of objective that organises the whole lesson: it is not about nobody ever falling for it, because a sufficiently good phishing e-mail fools anybody, but about when somebody does fall for it, it being known within minutes. With the sentence that sums it up: the mistake is not the incident; the silence is.

You can distinguish awareness, training and culture — sustained attention, capability and default behaviour — with their different formats, frequencies and horizons, and you know that none replaces the others. You have the needs analysis by role with what each Nimbus profile must do, not just know: Marta deciding with a risk register, Iván writing correct authorisation, Lucía running RB-01, Rubén verifying identity through a registered channel, Sara verifying a bank account change, and a short common baseline for everyone. And the complete annual programme in yaml, with twelve themed micro-lessons, four simulations, role-based workshops and a half-yearly tabletop, inside 1,400 € and 6 hours per person with no technical role, with the argument of spaced learning behind it.

You know how to set up onboarding — POL-04 accepted and MFA enabled before the first access, the password manager installed with someone alongside, no real data until it is complete — and offboarding, with revocation within 24 hours, the confidentiality reminder and the question that most mitigates R-09: what do you know that is not written down. And the forgotten link of the role change, treated as a leaver followed by a joiner so that privileges do not accumulate. You know the formats that work, with the contextual prompt as the best return — it teaches nothing and changes behaviour — and with the rule about bought material: buy the framework, produce the examples yourself, because Marta telling the 02-06 story in eight minutes is worth ten generic courses.

You know how to design phishing simulations done properly: a declared objective of measuring and training reporting, four difficulty levels, the ethical rule prohibiting lures about payslips, redundancies, benefits or health — because they always work and that is exactly why they measure nothing — immediate and private training for whoever falls for it and never a public list. And you know how to read the data: the table of three Nimbus campaigns, where the click rate rises and the programme has improved enormously because the report rate quadrupled, the time to first report fell from 47 minutes to 4 and the credentials entered went from 4 to 0. With the rule worth writing down before the first campaign: the click rate measures the difficulty of the lure; the report rate and the time to first report measure the health of the programme.

You have the report button with its five requirements — one gesture, available where the risk occurs, a response the same day, thanks without exception and no emotional friction — and its full loop through to the runbook, with the two consequences that surprise people: false positives are a good sign and the volume of reports measures trust, not threat. You understand just culture and its table of human error, risky behaviour, recklessness and deliberate conduct, with the economic argument that sustains it: blaming the person who falls for it buys blindness in exchange for nothing, because it trades a few avoided clicks for an enormous increase in detection time. You know how to measure the programme by separating vanity indicators from behaviour indicators, with the most ignored of all — preventive queries — as the best early signal of cultural change. And you know how to scale with security champions with explicit hours, how to train development with the real Nimbus codebase including the exercise of breaking a control to see that CI stops you, and how to train management, who take the most decisions, carry the most legal liability since NIS2 and do the most damage to the programme if they skip their own controls.

And one last piece remains. Everything we have built — controls, evidence, habits, programmes — presupposes that whoever wields this knowledge uses it well. But the same knowledge that allows you to defend allows you to attack; the same nmap that verifies your segmentation scans somebody else's network; the same person who finds a flaw in your API may find one in a third party's and not know what to do with it. Where exactly is the legal line? What makes an authorisation valid? What do you do if your employer asks you for something you should not do? And how do you report — and how do you receive — a vulnerability? In Ethics, Legal Aspects and Responsible Disclosure (06-06) we close the module and the taught part of the course with what 05-03 left pending: the Spanish Criminal Code applied to computing, the responsible disclosure framework, the policy Nimbus must publish in order to receive reports, and the responsibility of those who know how to do this.