The previous lesson worked through the technical attacks and ended with one observation: most attack chains do not begin with an exploit, but with a person doing something reasonable at the wrong moment. This lesson deals with that vector. Social engineering does not attack systems: it attacks people's decision-making mechanisms, and it does so with techniques that have worked for centuries and that technology has merely made cheaper. You will see why the human factor is the dominant vector, which principles of influence attackers exploit, the complete catalogue of techniques — from mass phishing to CEO fraud aimed at Sara, taking in vishing, quishing and consent phishing —, how to take a malicious e-mail apart indicator by indicator by reading its headers, and the defences: the technical e-mail ones (SPF, DKIM and DMARC) and the process ones, which in fraud cases are what actually stops the money. All of it resting on a principle worth settling straight away: if your defence depends on 38 people getting it right every single time, you have no defence.

1. Why the human factor is the dominant vector
2. The principles of influence attackers exploit
3. Catalogue of social engineering techniques
4. Anatomy of a phishing e-mail aimed at Nimbus
5. Reading the headers: Received, SPF, DKIM and DMARC
6. Technical e-mail defences
7. Why Nimbus needs DMARC to protect its customers too
8. Process defences: verification, support and a reporting culture
9. Phishing simulations and their metrics

An attacker who wants to get into Nimbus has two routes:

The asymmetry is devastating and it explains everything else:

• The attacker has to get it right once; the defender, always. With 38 people, hundreds of e-mails a day and a cycle of decisions taken under pressure, the cumulative probability that somebody clicks at some point tends towards one.
• Nothing has to be breached. If Sara types her password into a fake page, there has been no intrusion: there has been a perfectly valid authentication as far as the system is concerned.
• It jumps over almost every technical control. The firewall sees nothing anomalous, the antivirus sees no file, the WAF sees normal HTTPS traffic. It is exactly myth 2 from 02-01.
• It scales. Sending a hundred thousand e-mails costs practically nothing; personalising ten for specific targets costs a few hours.

Three important clarifications that change the approach:

1. Social engineering does not exploit stupidity, it exploits the normal working of the human brain. Cooperating with someone who looks legitimate, responding quickly to what is urgent and obeying authority are adaptive behaviours, and necessary ones if a company is to function. A team trained to distrust everything does not get any work done.
2. The most frequent victims are not the least trained but the busiest and the most helpful. Rubén, who handles dozens of tickets a day and whose job is to help, is a structurally vulnerable target: his work consists of doing what strangers ask him to do.
3. Anyone falls for it on the wrong day. Experienced security professionals fall for internal tests when the e-mail arrives at exactly the right moment. This fact has a direct consequence for how defences are designed: you cannot build a system whose only control is human judgement.

The design conclusion: people are a valuable detection layer — often the first and the only one to see a new attack — but they must never be the only prevention layer. The defence against social engineering is the combination of technical filtering, processes that do not depend on individual judgement, and a culture that makes reporting easy.

Effective social engineering messages are not improvised: they systematically apply a handful of well-known psychological levers. Recognising them is the best individual defence, because it shifts the question from "does this look real?" to "why do I feel rushed?".

Effective attacks combine principles, and the classic combination is authority + urgency + confidentiality:

"It's Marta. We're closing the funding round and I need you to make a transfer to the law firm today. Don't mention it to anyone until it's announced. I'll send you the details."

Why this combination is so effective, taken apart piece by piece:

• Authority makes questioning the request feel like insubordination.
• Urgency removes the time to verify.
• Confidentiality — the most poisonous element — disables the one control that would work: asking a colleague. Nobody is going to confirm the request with Iván if they have been asked not to mention it.

The defensive rule that follows: when a message combines haste with secrecy, the probability of fraud is extremely high. A healthy organisation never requires a procedure to be skipped for reasons of confidentiality. And if it really did, that would be the problem. This rule, written down and circulated, is worth more than any amount of general training.

• At the end of the day or just before a holiday, when cognitive load is at its highest and tolerance for formalities at its lowest.
• When the request coincides with something that is being expected. If Sara really is processing a supplier's invoice, an e-mail about that invoice passes every mental filter. That is why OSINT and the prior compromise of a mailbox pay off so well for the attacker.
• In a new situation, where no procedure has been established: the first time a supplier is engaged, the first migration, an employee's first day.

BEC and bank account change fraud. This is the one that moves the most money and looks the least like a computer attack. The dangerous variant is not crude impersonation but the genuinely compromised mailbox: the attacker gets into the mail of a Nimbus supplier, reads the conversation for weeks, learns the tone, the amounts and the calendar, and at exactly the right moment replies inside the real thread with a genuine invoice in which only the IBAN has been changed. There is no lookalike domain to detect, there is no SPF failure: the e-mail comes from the real sender.

Only process works against this. No technical indicator saves Sara here. What saves her is a rule: every change of bank details is verified by telephone, using the number we already had on file, never the one that appears in the e-mail.

MFA fatigue. It attacks the weak point of push-notification second factors: the approval is a button with no context. The attacker, who already has the password, launches repeated attempts until the victim accepts to make it stop, or accepts half asleep believing it is a synchronisation glitch. The defence lies in the mechanism itself — number matching, attempt limits, context in the notification — and is detailed in 02-05.

Consent phishing. The most elegant and the worst understood. The attacker does not steal the password: they register an application with a plausible name and send a legitimate link from the identity provider. The victim sees their provider's real screen, with the right padlock, and grants permissions. Consequences:

• MFA does not protect, because the victim genuinely authenticates.
• Changing the password revokes nothing: the consent survives.
• Access is persistent through a refresh token, and it often goes unnoticed for months.

The defence is administrative: disable free user consent, require administrator approval for new applications, and periodically review the applications authorised in Nimbus's mail tenant.

This is the e-mail Sara receives at 17:40 on a Thursday. It is built out of everything in section 2. Analyse it before reading the breakdown.

This is the most cost-effective practical skill in the whole lesson, and hardly anybody teaches it well.

The rule: the real domain is the last two labels before the first slash. Everything in front of them is subdomains controlled by whoever owns the real domain. Anyone can create bank.yourcompany.example.mydomain.example.

Compare:

Operational tip: with a suspicious e-mail you do not click to check. You hover the mouse over the link and read the status bar, or better still: you type the address you know into the browser. If the message was legitimate, the notice will also be inside the application.

The headers are the part of an e-mail the attacker controls least well. Knowing how to read them turns a suspicion into a diagnosis.

Every server an e-mail passes through adds a Received header at the top. They are therefore read from the bottom up to follow the chronological journey.

What can be drawn from this:

• The e-mail originated at 203.0.113.99 (bottom line), not in the Nimbus infrastructure.
• ESMTPA on the first hop indicates that the sender authenticated to that outbound server: somebody has an account with that provider, a useful fact for a police report.
• unknown means the IP's reverse lookup does not match the declared name: a low reputation signal.
• Only the headers added by servers you control are trustworthy (the ones at the top). The lower ones can be forged by the attacker, so they are used as an indication, not as proof.

The key point almost everybody misses: SPF and DKIM, on their own, do not protect against spoofing of the visible From. An attacker can publish valid SPF and DKIM for their own domain and still put From: Marta <[email protected]>. What ties the three pieces together is DMARC, through the requirement of alignment: the From domain must match the SPF or the DKIM domain.

Line-by-line translation:

• spf=fail: the IP 198.51.100.203 is not among those authorised by the envelope domain.
• dkim=none: there is no signature at all. It is not that it is invalid: it does not exist.
• dmarc=none (p=NONE ... dis=NONE): the attacker's domain either publishes no DMARC or publishes it in passive mode; dis=NONE indicates that no disposition has been applied, that is, the mail was delivered.

And here is the uncomfortable lesson: the e-mail reached Sara's inbox anyway despite failing SPF and having no DKIM. For two reasons: the attacker's domain is theirs and they can configure it however they like, and Nimbus's filter was not configured to act on these failures. A reasonable compromise — quarantining what fails SPF and adding a visible warning — would have changed the outcome.

Compare it with a legitimate e-mail:

spf=pass, dkim=pass with the selector sel2026, and dmarc=pass with policy p=REJECT: the From domain is aligned and, if it were not, the recipient would have rejected the message.

Anatomy of the record, field by field:

The most common mistake: ending in ~all (softfail) "just in case" and leaving it that way forever. ~all tells the recipient "this is suspicious, but accept it anyway". Most mailboxes deliver it regardless. You start with ~all during roll-out and you finish at -all; otherwise SPF is decorative.

Two limitations worth knowing:

1. SPF breaks with forwarding. If a customer forwards an e-mail from Nimbus, the sending IP becomes their server's and SPF fails. That is why DKIM is essential: it survives forwarding.
2. The 10 DNS lookup limit. Chaining lots of include: entries exceeds the limit and the result becomes permerror, which is equivalent to having no SPF at all. It has to be reviewed every time a provider is added.

Nimbus signs every outbound e-mail with a private key; the recipient retrieves the public key from DNS and verifies it.

What DKIM adds that SPF cannot: it guarantees integrity (the body and the signed headers have not been altered) and it survives forwarding, because it does not depend on the IP. The signature appears in the message's DKIM-Signature header. The detail of how a digital signature works is studied in 03-03 and 03-04; here it is enough to be able to read the result.

The correct roll-out, in phases, which is where most implementations fail:

Why phase 1 cannot be skipped. Nimbus sends mail from at least five places: its own server, the transactional e-mail provider (appointment reminders), the invoicing tool, the marketing platform and perhaps the CRM. Going straight to p=reject blocks patients' appointment reminders, which would be a self-inflicted availability incident. The rua reports from phase 1 reveal exactly which senders exist — including the ones nobody remembered — before anything is tightened.

Up to here, DMARC has looked like a defence for Nimbus. That is half the story, and the less important half.

Nimbus sends appointment reminders to clinic patients every day. Those patients are used to receiving e-mail from nimbusreservas.example. If Nimbus does not publish DMARC with a reject policy, anyone can send e-mails that appear to come from Nimbus, and they will land in those patients' inboxes.

The concrete scenario:

1. An attacker sends ten thousand addresses an e-mail with From: [email protected].
2. The message says: "Your clinic has updated its payment policy. Confirm your bank details to keep your appointment."
3. Because Nimbus publishes no DMARC, the e-mail is delivered with no warning whatsoever.
4. The patients who fall for it, fall for it in Nimbus's name.

The consequences, ordered by seriousness:

• Direct reputational damage to asset A-20: the clinics will blame Nimbus, and rightly so.
• Deliverability deterioration: when a domain is used en masse for fraud, its reputation falls and the legitimate reminders start going to spam. Nimbus would lose its main operational channel.
• Contractual and regulatory exposure: customers will ask what measures were in place, and "none" is a hard answer to sustain when the measure costs one DNS record.

The formulation worth remembering: SPF, DKIM and DMARC do not protect your inbox; they protect your domain from being used against others. They are outward-facing hygiene measures, not inward-facing defence. And that is why they are especially important for a SaaS that sends e-mail on behalf of its customers.

Additional note for the Nimbus case: if in future customers want the reminders to go out from their domain ([email protected]), it will be necessary to document how they delegate sending — normally with a delegated subdomain and its own DKIM — without breaking their DMARC. It is a technical conversation worth having before the feature is sold.

Note on legal implications: a fraudulent e-mail sent in Nimbus's name to its customers' patients may have implications for data protection and for the contractual relationship with the customer. In a real case, assess it with the compliance owner and with legal advice; the handling is covered in 06-03.

Technical defences stop volume. What stops targeted fraud is process, because a process does not get tired, is never in a hurry and is not impressed by authority.

The golden rule, written to be pinned on the wall:

Every request for a payment, a change of bank details or credentials that arrives in writing is verified through a different channel, using a contact we already had, before it is carried out. No exceptions for urgency and no exceptions for hierarchy.

The four elements that make it work:

• A different channel: if it arrived by e-mail, it is verified by phone or in person. Replying to the e-mail does not count: it may be under someone else's control.
• A contact we already had: the number on the supplier's record or in the internal directory, never the one that appears in the message.
• Before it is carried out: verifying after transferring is a post-mortem.
• No exceptions: a rule with exceptions for urgency becomes a rule that only applies when it is not needed. And urgency is precisely the lever of the attack.

Concrete procedure for Nimbus (process owner: Sara):

One detail that prevents the most common failure: explicit written permission has to be given to say no to management. If Sara knows Marta will back her for holding up a payment in order to verify it, she will verify it. If she fears a telling-off, she will not. The rule does not protect her if the culture contradicts it.

Rubén is the structural target: he receives requests from strangers and his role is to help. He needs a procedure that lets him help without deciding under pressure.

Typical vishing scenario: a call to Nimbus support. "Hello, I'm Carlos, the new administrator at Turia Clinic. I'm in a consultation with patients waiting and I can't get into the panel. Can you reset my password or give me temporary access? It's urgent, the waiting room is full."

There you have authority (the practice administrator), urgency (patients waiting) and liking. And a request that sounds perfectly reasonable.

Three-level verification procedure:

The three rules that hold the procedure up:

1. The call back to the number on the record solves almost everything. It breaks the attack without Rubén having to judge whether the story is credible.
2. A verification code is never requested and never accepted. No legitimate support desk — not Nimbus's, not the bank's, not the cloud provider's — asks for the code the user has just received. If somebody asks for it, it is an attack, no further analysis required.
3. Pressure is an indicator, not a reason. The more the caller hurries you, the more slowly you should go. It helps to rehearse a specific sentence: "Of course, I'll call you right back on the number we have on file and we'll sort it out."

This section is the one that prevents the most incidents, because the time between the click and the alert determines the outcome.

Instructions for any Nimbus employee, in order:

1. Report immediately. A single, well-known channel: [email protected] or a direct message to Lucía. Before trying to fix it yourself.
2. If you typed in a password, change it on the real site — typing the address by hand — and report it anyway. If you were reusing it elsewhere, change it there too.
3. If you approved an MFA notification you had not requested, report it: it means somebody has your password.
4. If you opened an attachment, disconnect the machine from the network (wifi and cable) and do not switch it off: switching it off destroys useful evidence. Wait for instructions.
5. If you made a transfer, call the bank immediately: there is a window of a few hours in which a recall can be attempted.
6. Do not delete the e-mail. It is the evidence that makes it possible to find out who else received it.

And the cultural rule, which is the most important in the whole lesson:

Whoever reports is never blamed. Never. Under no circumstances.

The reasoning, which is worth being able to explain to management: if you punish the person who reports, the next one will not report. A click reported within 5 minutes is a contained incident; the same click reported three weeks later — or not reported at all — is a breach. The behaviour you want to reinforce is not "don't fall for it" (impossible to guarantee) but "tell us quickly" (perfectly achievable). An organisation that celebrates reports gets more reports, and with them early detection for free.

Practical corollary: individual simulation results are not published, not compared and do not go into performance reviews. They are used in aggregate to measure the programme, not the people.

A simulation is a controlled send of benign phishing e-mails to your own team, in order to measure and to train. Done well they are the most effective awareness tool there is; done badly they generate resentment and destroy trust. The complete training programme is developed in 06-05; here we cover only what is needed to understand them as a defence.

Why the report rate matters more than the click rate. The click rate measures something that will never reach zero: there will always be somebody busy at the wrong moment. The report rate measures something you can push a long way up and that delivers direct operational value: every report is an early warning. A team with a 12 % click rate and a 55 % report rate is far better defended than one with a 6 % click rate and a 3 % report rate, because in the second nobody finds out about anything.

Time to first report is equally critical: if the first alert arrives after 6 minutes, Lucía can look for the message in every mailbox, delete it and block the domain before most people open it. A single alert employee protects the other 37.

Good practice:

• Announce the programme, not the sends. Everybody must know there will be periodic simulations; nobody must know when.
• Progressive difficulty. Start with generic lures and gradually work up to the targeted scenario, so that improvement is measurable.
• Immediate training at the moment of the click, brief (two minutes) and without an accusatory tone: which indicators this particular e-mail had.
• Always measure the report rate, not just the click rate. If your platform does not measure it, change platform.
• Aggregate results, never individual ones and never tied to performance.
• Close the loop: share the indicators of the e-mail used with the whole team. What teaches is not the send, it is the explanation afterwards.

Practices that do damage and must be avoided:

• Using cruel lures: fake bonuses, fake redundancies, fake medical news. They achieve very high click rates and destroy trust in the programme and in HR for years.
• Publishing who fell for it. It turns the simulation into a public punishment and guarantees nobody reports anything ever again.
• Measuring only the click rate and presenting it to management as if it were the company's level of security.
• Running one simulation a year. That is a snapshot, not a programme. Quarterly is a sustainable rhythm for Nimbus.
• Impersonating real members of the team without prior agreement. Using Marta's name in a lure can damage internal trust; it can be done, but it must be agreed beforehand and explained afterwards.

Common mistakes:

• Believing training solves the problem. It reduces the click rate, it does not take it to zero. Training is one layer; process and filtering are the other two.
• Relying on "spotting the spelling mistakes". Today's targeted e-mails are well written, in correct language and with real context about the company. That advice is obsolete and gives false confidence.
• Blaming the person who reports. The most expensive mistake of all: it destroys the only source of early detection an SME has.
• Publishing DMARC at p=none and considering it done. Without a reject policy, DMARC only reports. Thousands of domains have been sitting at p=none for years.
• Verifying by replying to the same e-mail. If the mailbox is compromised, the attacker replies. The alternative channel is what defines verification.
• Asking a user in support for their verification code. It legitimises the most common vishing attack. Never, under any circumstances.
• Thinking MFA stops consent phishing. It does not: the victim genuinely authenticates and grants permissions voluntarily.
• Dismissing QR codes as a minor problem. Quishing moves the attack onto the personal mobile, beyond the reach of every corporate control.
• Designing the payments procedure without the person who makes the payments. A procedure Sara cannot follow in her day-to-day work does not get followed.

Tips:

• Teach the whole team one single technical skill: reading a domain from right to left. It stops more attacks per minute of training than anything else.
• Turn on the external e-mail banner this week. Zero cost, high effectiveness against CEO fraud.
• Write the payment verification rule on one page, with concrete thresholds, and get Sara and Marta to sign it. A procedure with no owner and no thresholds does not get applied.
• Give the team a rehearsed escape line for the phone: "I'll call you back on the number we have on file". Having the sentence ready prevents freezing under pressure.
• Review today the OAuth applications authorised in Nimbus's corporate mail and disable free user consent.
• Check your three records with dig right now: SPF (-all), DKIM (active selector) and DMARC (p= and rua=). It is a three-minute diagnosis.
• Measure the report rate from the very first simulation and present it to management as the main metric, ahead of the click rate.

Iván receives this message on a Tuesday morning:

Required: (a) list all the fraud indicators you find; (b) explain the most dangerous detail of this particular e-mail, the one that makes it harder to detect than Sara's; (c) state what Iván should do, step by step; (d) say which of the technical defences from section 6 would have flagged it and which would not.

Nimbus has come within a hair's breadth of losing 14,200 € to an IBAN change fraud. Marta asks you for a one-page procedure Sara can actually apply.

Required:

1. Write the general rule in a single sentence.
2. Define a table of thresholds and verifications for: a new supplier, an IBAN change for an existing supplier, a payment over 3,000 €, a change of salary account and a refund to a customer.
3. Specify what is recorded for each verification and where.
4. Give three concrete ways the procedure could fail in practice and how to prevent them.
5. Explain what Sara should do if Marta in person asks her to skip the procedure.

Nimbus runs its first quarterly simulation. All 38 employees are sent an e-mail impersonating the transactional e-mail provider and asking them to revalidate their credentials.

Required: (a) calculate and interpret the metrics from section 9.1; (b) say which is the most worrying figure in the table and why; (c) propose five concrete actions for the following quarter, ordered by expected impact; (d) explain what must not be done with these results, particularly with the Support figure.

Solution 1

(a) Indicators present:

1. Lookalike domain in the sender: github-security-alerts.example is not the provider's real domain. It is a domain of the attacker's own, with a corporate look.
2. Masked link: https://github.com.security-alerts.example/.... Read from right to left, the real domain is security-alerts.example; github.com is merely a subdomain. It is the same trick as in Sara's e-mail, more effective here because it incorporates a .com that induces you to misread it.
3. Urgency with a threat: "automatic suspension in 24 hours" — fear + urgency.
4. A technically credible and personalised pretext: it mentions the real repository, a commit and a file with a line number. Almost certainly obtained through OSINT if the repository was ever public, or simply invented with plausible names.
5. A request to log in from the link: legitimate notices ask you to go to the site, they do not offer you the door.
6. A lowercase greeting with no surname (Hello ivan): suggests a template generated from the local part of the e-mail address.
7. An inconsistent sending host: smtp7.envio-masivo.example is not the impersonated provider's infrastructure.

(b) The most dangerous detail: SPF, DKIM and DMARC all pass. And that is correct, because the attacker has properly configured their own domain. Here is the essential lesson:

E-mail authentication verifies that the message really does come from the domain the From says. It does not verify that the domain is trustworthy. A dmarc=pass from a domain registered yesterday by a fraudster is a perfectly valid pass.

Many users and not a few technical people read "authentication passed" as "legitimate e-mail". It is a category error, and this e-mail exploits it. Sara's e-mail failed SPF and was easy; this one passes everything and is hard.

(c) What Iván should do:

1. Do not click the link.
2. Open the browser and type in by hand the real provider's address. If there were an exposed secret alert, it would be there.
3. Report the e-mail through the official channel without deleting it, so that Lucía can look for it in the other mailboxes and block the domain.
4. Regardless of the e-mail being fake, check whether there really is a secret in config/settings.py. The pretext may be invented, but the problem could be real; and if it is, the credential must be rotated, not merely deleted from the code (it is still in the Git history).
5. If for any reason he did type in credentials: change the password on the real site, revoke active sessions and tokens, and report it immediately.

(d) Technical defences:

• Would have flagged it: the lookalike domain warning against a habitual provider; link rewriting and time-of-click checking (the destination is a recently registered domain with a poor reputation); domain reputation, by registration age; and the external e-mail banner, which at least reminds you it is not internal.
• Would not have flagged it: SPF, DKIM or DMARC, because the attacker complies with them for their own domain. Nor would the attachment filter: there is no attachment. And an antivirus sees nothing, because there is no file.

Solution 2

1. General rule:

"No payment instruction, change of bank details or creation of a payee is carried out on the strength of a written request alone. It is always verified through a different channel, with a contact that was already on our records, and a note is kept of who verified it, when and who they spoke to. Urgency is not an exemption; nor is hierarchy."

2. Table of thresholds:

3. Recording. In the management system, alongside the accounting entry: date and time of the verification, name of the person who verified, name and phone number of the other party, channel used, and result. Without a record, the verification did not happen as far as auditing is concerned (06-04).

4. Three ways it can fail and how to prevent them:

5. If Marta in person asks for the procedure to be skipped. Sara must apply it all the same, and that is precisely the reason the rule exists: the procedure protects Marta too, because it stops anyone impersonating her from obtaining a payment. The practical wording: "Of course, I'll process it right away; I just need the second signature confirmed, as with every payment." For this to be possible, Marta must have stated in writing and in front of the whole team that nobody will be reprimanded for applying the procedure to management. Without that explicit backing, no anti-fraud procedure survives first contact with the hierarchy.

Solution 3

(a) Metrics:

(b) The most worrying figure. It is not the 29 % click rate: it is the combination of an 11 % report rate and 47 minutes to the first alert. The reasoning: clicks will always happen, but in a real attack those 47 minutes are the difference between deleting the e-mail from 38 mailboxes before most people open it and discovering the incident weeks later through its consequences. Furthermore, six people submitted credentials and only one of those who interacted reported it: that means the other five knew or suspected something was wrong and did not say so. That points to a problem of culture, not of knowledge, and culture is what has to be fixed first.

(c) Five actions, by expected impact:

1. Communicate and make the reporting channel visible, with a "Report phishing" button in the mail client and an explicit message from management: reporting is always appreciated, falling for it is never sanctioned. It attacks the worst metric directly.
2. A 30-minute session analysing the real e-mail used, indicator by indicator, including reading the domain from right to left. Closing the loop is what turns a simulation into training.
3. Phishing-resistant MFA on every account, prioritising the administrative ones. With proper MFA, those six submitted credentials would not have been enough to get in. It is the measure that most reduces the impact regardless of the click rate (02-05).
4. Turn on the external e-mail banner and the lookalike domain warning, if they are not already on. Almost zero cost, immediate effect on recognition.
5. A specific, supportive session with the support team, not because of their click rate but because their exposure is structurally greater: alongside the session, equip them with the identity verification procedure from section 8.2, which takes the burden of deciding off their shoulders.

(d) What NOT to do:

• Do not publish or communicate who fell for it, neither aggregated by person nor in a list.
• Do not single out Support as "the problem department". Their three clicks out of four people reflect the fact that their job consists of opening messages from strangers and helping them: it is a fact about the design of the role, not about the people. Treating it as a personal failing guarantees that support never reports anything again — precisely the team that sees the most attacks.
• Do not link the results to performance reviews or to incentives.
• Do not present only the click rate to management. The headline indicator must be the report rate and the time to first alert, which are what measure the real capacity to react.
• Do not consider the problem solved with an informational e-mail. Without changes to MFA, to filtering and to the procedure, the next simulation will produce almost identical results.

You have studied the vector that heads almost every set of incident statistics. You know why the human factor is dominant: the asymmetry is overwhelming — the attacker has to get it right once, the defender always — and the attack breaches nothing, it simply gets somebody to do voluntarily what they are asked to do. You have seen that social engineering exploits not ignorance but the normal working of human judgement, and that the most frequent targets are the busiest and the most helpful, like Rubén, whose job literally consists of helping strangers. Hence the design conclusion that structures the whole lesson: people are an excellent detection layer and a terrible only prevention layer.

You have learned the principles of influence — authority, urgency, scarcity, reciprocity, social proof, liking, fear and consistency — and the most dangerous combination, authority plus urgency plus confidentiality, whose third ingredient exists to disable the one control that would work: asking a colleague. You have worked through the catalogue of techniques, from mass phishing to BEC from a genuinely compromised mailbox, the IBAN change fraud aimed at Sara, smishing, vishing, quishing, baiting, tailgating, MFA fatigue and the consent phishing that neither MFA nor a password change stops. You have taken a complete e-mail apart with its twelve indicators and you have learned the most cost-effective skill of all: reading a domain from right to left. And you have learned to read headers: the Received chain from the bottom up, and the exact meaning of spf=fail, dkim=none and dmarc=none, together with the lesson Iván's exercise teaches — that a dmarc=pass certifies the domain, not the honesty of whoever registered it.

In technical defences you have seen SPF with its decisive -all, DKIM with its selector and its ability to survive forwarding, and DMARC as the piece that ties the previous two together through alignment, with a phased roll-out that cannot be skipped without leaving the clinics' patients without reminders. And you have understood what hardly anybody explains: that these three records do not protect your inbox, they protect your domain from being used against others, which in the Nimbus case means protecting its customers' patients. In process defences you take away the rule of verification through an alternative channel with the contact on file, the three-level procedure for Rubén's support desk, what to do if you have fallen for it, and the cultural rule that holds all the rest up: whoever reports is never blamed, because the behaviour that can be guaranteed is not "don't fall for it" but "tell us quickly". The simulations have given you the right metrics, with the report rate and the time to first alert ahead of the click rate.

With the complete catalogue of attacks now known — technical in 02-02 and human here — it is time to organise the response. In the next lesson, Protection Measures in Cybersecurity (02-04), we will work through the catalogue of defences organised by the layers of defence in depth: perimeter and network, endpoint, data, application and development life cycle, and logging and observability; with an example CI workflow that scans dependencies and secrets, and with what is most useful for an SME: a table of the twelve highest-return measures for Nimbus and a phased 30, 90 and 180-day plan.