The previous lesson closed with a piece still pending: everything we have built presupposes that whoever wields this knowledge uses it well. But the same nmap that verifies your segmentation scans a third party's network, and the same person capable of finding an IDOR in the Nimbus API may find one in somebody else's and not know what to do with it. This is the lesson 05-03 explicitly deferred: where the legal line lies, what makes an authorisation valid, what you do when your employer asks you for something you should not do, and how a vulnerability is reported — and how it is received. It is the lesson that turns a competent technician into a professional.

⚠️ Validation note — read it before going on

This material is training material and does not constitute legal advice. Criminal offences, their wording, their penalties and their judicial interpretation change, and the classification of any particular conduct depends on circumstances no lesson can anticipate. Always verify the wording in force of the Spanish Criminal Code and of the rules cited, in the BOE (Spain's official gazette), and consult a lawyer before taking any decision with legal implications — a security test, a report to a third party, a refusal of an instruction from your employer. When in doubt as to whether something is lawful: do not do it, and ask.

1. The legal line: what the Spanish Criminal Code says
2. Why authorisation changes everything, and what makes it valid
3. What people believe is lawful and is not
4. Professional ethics: confidentiality, limits and pressure
5. White, black and grey hats
6. Responsible disclosure: what it is and what the options are
7. How to report somebody else's vulnerability properly
8. How to receive a report properly: security.txt and a disclosure policy
9. The internal loop when a report arrives
10. Bug bounty programmes: when they make sense
11. CVE and coordination: what a CNA is
12. The publication dilemma and the ethics of AI in security

The Spanish Criminal Code deals with computer crime mainly in articles 197 and following — within offences against privacy — and 264 and following — criminal damage. What follows is an explanation in plain language and for guidance only, not a transcription; verify the wording in force, which has been amended several times to transpose European directives.

Five clarifications that avoid frequent misunderstandings. Unlawful access does not require damage: getting in where you should not by circumventing a security measure is enough, and "I did not break anything" is not a defence. Nor does it require great skill: trying a default password circumvents a security measure just as much as exploiting a buffer overflow. Remaining counts: if you get in by accident and stay there looking around, the conduct may still fall within the offence. Aggravated forms exist where circumstances such as organised crime, effects on critical infrastructure or profit motive are present. And criminal liability is not the only kind: there may be civil liability, employment consequences and — where personal data is involved — action by the data protection authority, along independent tracks that stack up.

And there is something the law does not say: Spanish law contains no general defence of "I did it with good intentions" or "it was to warn them". Intention may influence how a case is assessed, but it does not make unauthorised access lawful. This is the asymmetry that makes the rest of the lesson matter.

The same technical action — scanning ports, trying credentials, exploiting an IDOR — is a crime or a professional job depending on a single variable: whether a valid authorisation exists. In 05-03 we looked at the rules of engagement operationally; here we look at them legally.

What makes an authorisation valid. Five conditions, and failing one invalidates the whole thing:

The case most people skip: you cannot authorise testing against third-party systems. If Nimbus commissions a pentest, Marta can authorise testing of the Nimbus API and SPA. She cannot authorise testing against the cloud provider (A-05), against the payment gateway (A-12), against the e-mail provider (A-11) or against a customer clinic's systems, because they are not hers. A pentester who attacks the cloud provider's infrastructure relying on Nimbus's authorisation is committing unauthorised access, and Marta's authorisation does not protect them. That is why the template in 05-03 included express clauses on excluded assets and cloud provider authorisation.

The same thing, in its everyday and frequent version: an employee's permission does not authorise testing of their employer's systems. A friend who works at a company telling you "try our website, see if it holds up" is not a valid authorisation unless that person has capacity to bind the organisation, which is almost never the case.

Six behaviours seen every day, defended in good faith, that cross the line:

The case of the account that still works deserves a paragraph, because it is the one seen most often and the one most people believe is legitimate. Somebody leaves Nimbus, and three months later discovers their VPN is still active. Logging in "to check whether it is still open" is unauthorised access, however much the failure is Nimbus's. The right thing is to warn without logging in: an e-mail to seguridad@nimbusreservas.example saying "my access is still active, please revoke it" is a favour; using it is a crime. The difference between the two is one click and several years of consequences.

The law sets the floor. Professional ethics sets what is expected of somebody who knows how to do this, and it begins where the law falls silent.

The duty of confidentiality about what you discover. Anyone doing security work sees things: passwords in a file, personal data in a log, a director's e-mails, the real state of a customer's security. Four non-negotiable rules: what you see at work is not told outside, not even anonymised in a talk, without express permission; what you find is not used for your own benefit, neither to win a contract nor to be right in an argument; you do not access more than you need — the pentester who finds an IDOR pulls one record and stops, the administrator debugging does not read the messages; and you destroy what you collected when you finish — screenshots, dumps, test credentials, exports — leaving a record of that destruction.

The conflict between what is technically possible and what is acceptable. Almost everything you can do in security can also be done in the wrong direction. Nimbus can read its employees' e-mail, log every keystroke, geolocate the laptops and record support calls. That it is technically trivial does not make it lawful or acceptable: workplace monitoring has strict legal limits, requires prior information, proportionality and a legitimate purpose, and in many cases consultation with employee representatives. The professional question is not "can I?", it is "should I, on what basis and within what limit?".

The responsibility of whoever writes tools. Publishing a script that automates a defensive check is useful; publishing one that automates mass exploitation of a freshly disclosed vulnerability puts a weapon in thousands of hands before anybody has been able to patch. There is no single answer — we will come back to it in section 12 — but there is a criterion: think about who will use it on day one and what defence becomes possible that was not before. If the answer to the second question is "none", the publication is hard to justify.

What to do when your employer asks you for something you should not do. It is the hardest situation in this lesson because there is an employment contract involved. Three real cases in the Nimbus world:

Four practical principles for these situations. Leave a trail: ask for and give instructions in writing, because the memory of a conversation protects nobody. Escalate along the intended path: management, the DPO, the compliance lead, and if there is one, the internal whistleblowing channel. Distinguish professional disagreement from illegality: disagreeing with a risk decision is legitimate and you comply; taking part in a breach of the law is not. And know your limits: if you are asked for something that may be unlawful, the right answer is to refuse and seek advice, because the fact that your employer asks you for it does not relieve you of liability.

Validation note. The protection of a worker who refuses an instruction, internal whistleblowing channels and the protection of reporting persons are regulated and vary case by case. Check with an employment lawyer before acting, and document everything in writing from the outset.

Why grey is a problem even when the intention is good, and it is worth understanding because many people believe they are in a safe zone. Legally there is no grey zone: the access was unauthorised and the rest are mitigating factors; the grey hat is a cultural category, not a legal one. Whoever receives the warning cannot tell you apart from an attacker: from the other side they see an unauthorised access and an e-mail from somebody saying they got in, and the defensive reaction — reporting you — is predictable and reasonable from their point of view. Cases that end badly do exist: researchers have been reported to the police for disclosing flaws found without authorisation, even without extracting data and giving immediate notice, because the outcome does not depend on your conduct alone. And there is a frequent slide towards black: asking for a reward for a flaw found without authorisation may be construed as extortion.

The alternative that almost always exists. If you want to research the security of a third party's product without risk: look for their disclosure policy or their security.txt, and if they have one, act within its scope and its safe harbour. If they have none, ask for authorisation first. And if you want to practise exploitation, do it where it is allowed: your own lab, Juice Shop, DVWA, TryHackMe, HackTheBox — the same ones 05-03 pointed to as the only place to practise it.

Responsible disclosure — or coordinated disclosure — is the set of practices by which whoever discovers a vulnerability communicates it to the party responsible for the product, gives them a reasonable period to fix it and only then makes it public, if appropriate.

It exists because the two pure alternatives are bad. Staying silent forever leaves users exposed if somebody else finds the same flaw, and removes the vendor's incentive to fix it. Publishing immediately hands the flaw to attackers before a patch exists. Coordinated disclosure seeks the balance: whoever can fix it finds out first, and whoever can protect themselves finds out when they are able to do so.

The role of CERTs as intermediaries. When direct contact fails — there is no channel, they do not reply, or there is a conflict — an incident response team can coordinate. In Spain:

• INCIBE-CERT, for citizens and private-sector companies. It is the reference point for reporting when you do not know who to approach.
• CCN-CERT, for the public sector and organisations under the ENS.
• ESPDEF-CERT, for the defence sphere.

Their value is twofold: they lend legitimacy to the report and the ability to make contact with organisations that publish no channel. There are also international coordinators for cases affecting many vendors at once.

The deadlines and their rationale. The de facto standard is 90 days from report to publication, with variants: 7 days if the flaw is already being actively exploited, an extension if the vendor shows real progress and the fix is structurally complex, and publication immediately after the patch if it comes out sooner. The reasoning: 90 days are enough for a reasonable organisation to fix and deploy, and few enough for the pressure to work; without a deadline, many fixes never arrive. And the deadline is announced from the first contact, so there are no surprises.

What to include, in order of usefulness to the recipient: (1) a one-sentence summary and the impact in business terms — what an attacker can do and over what data; (2) the exact product, version and environment where it was reproduced; (3) minimal, deterministic reproduction steps, with the smallest possible evidence; (4) the scope of what you did and — very importantly — of what you did NOT do; (5) a suggested mitigation, if you have one; and (6) your contact details, your disclosure deadline and your credit preferences.

What never to do. Do not exfiltrate data "to prove it": somebody else's identifier visible in a response demonstrates the flaw; downloading 10,000 records turns it into a crime and destroys your position. Do not pivot or escalate: finding a door does not authorise you to walk through the house. Do not ask for money: reporting and then requesting compensation may be construed as extortion, especially if it comes with a deadline or a mention of publishing — if a bug bounty exists you claim within its process; if not, you report unconditionally and accept whatever they voluntarily offer. Do not publish early or post screenshots on social media. And do not threaten: announcing an agreed deadline is legitimate, "either you answer me or I publish tomorrow" is not.

Notice that sections 5 and 8 are the ones that protect the researcher legally: they put in writing, from the first minute, that there was no exfiltration and no further exploration, and that there is no financial request. Writing them takes two minutes and completely changes how the e-mail reads at the other end.

This is Nimbus's side of it, and where 05-03 left the task pending: publish your security.txt today, it costs half an hour. The reasoning is simple: somebody is going to find a flaw in your product. The only question is whether they will know who to write to and whether they will dare. With no channel and no safe harbour, the flaw ends up somewhere else.

The three most common mistakes with this file: letting Expires lapse — which invalidates it and signals abandonment — putting in a mailbox nobody reads, and publishing it without a disclosure policy behind it, which is what actually gives a researcher the confidence to act.

The three clauses that make this policy useful: the safe harbour in point 2, which is what lets somebody research without fear; the excluded scope in point 3, which protects Nimbus from being responsible for testing against third parties and protects the researcher from believing they are authorised where they are not; and the committed deadlines in point 6, which turn a statement of intent into a verifiable obligation. Without all three, the document is decorative.

Publishing the channel without the capacity to respond is worse than not publishing it: the researcher who gets no reply in two weeks publishes, and rightly so.

Two decisions make the difference. The first: step 3 can turn into an incident. If triage reveals that the flaw was already exploited by others, it stops being a report and becomes a breach, with the GDPR's 72-hour clock running (06-03). The second: step 9 is what gives lasting value. An external report is a free audit that also points at a gap in your own defences; asking why the AppSec CI did not catch it turns one flaw into a new rule that prevents the next hundred.

And how you treat people matters more than it seems. The researcher who gets a reply within a day, regular updates, public credit and a T-shirt becomes somebody who looks at your product again for free and speaks well of you. The one who gets silence and then a letter from a lawyer becomes a public case that other companies will use as an example of what not to do. The cost of handling a report well is an hour's work; the cost of handling it badly is your reputation (A-20).

A bug bounty is a programme that offers a financial reward for reported vulnerabilities, run directly or through specialist platforms (HackerOne, Bugcrowd, Intigriti, YesWeHack).

Why Nimbus should not open one yet, picking up the warning from 05-03: a bug bounty with no capacity to respond is worse than not having one. If forty reports arrive and nobody triages them within 48 hours, the community publishes and the reputational damage exceeds that of the original flaw. And there is a cash-flow problem: rewards are unpredictable — one critical flaw can cost thousands of euros — and they do not fit well into an 18,000 €/year budget that is already committed.

The four prerequisites before considering it, in order: (1) a VDP published and working for at least a year with its deadlines met; (2) demonstrated ability to fix a critical within 30 days; (3) a specific budget separate from operational security, with a declared annual ceiling; (4) a person with time allocated to triage. If any is missing, wait. The intermediate step that does make sense today: a private, invitation-only programme with three or four known researchers, a narrow scope and a fixed budget; it delivers most of the value with a fraction of the noise and serves as a rehearsal of the process.

The CVE system (Common Vulnerabilities and Exposures), which we saw in 01-02, assigns a unique public identifier to each vulnerability so that everybody is talking about the same thing: CVE-YYYY-NNNNN.

A CNA (CVE Numbering Authority) is an organisation authorised to assign CVE identifiers within its scope. There are three kinds: vendors that assign CVEs to their own products, coordinators — such as CERT/CC or INCIBE within its sphere — that assign them to third-party products when the vendor is not a CNA or does not respond, and the programme's root authority.

How you request a CVE, in practice: if the vendor is a CNA, you ask them during coordinated disclosure and they assign it. If they are not, you request it from a coordinating CNA, providing a description, affected versions, the vulnerability type (CWE), the impact and proof that you tried to contact the vendor. It is free of charge.

What role the researcher plays and why it is worth it. A CVE turns a finding into something trackable, citable and actionable by thousands of organisations at once: it enters the feeds, scanners pick it up, and suddenly Nimbus's trivy detects it automatically in its dependency chain. There is the course coming full circle: the work of an unknown researcher ends up, weeks later, protecting an SME in Valencia without anybody having to do anything. That is the public good responsible disclosure produces, and the underlying reason for doing things properly.

Two clarifications: not everything deserves a CVE — a misconfiguration of one particular instance is not a product vulnerability — and having a CVE does not mean being exploitable in your environment, which is exactly why in 05-01 we prioritised with EPSS and KEV as well as CVSS.

The dilemma of publishing exploits. It is probably the oldest and least settled debate in the field, and it has solid arguments on both sides:

Reasonable criteria that practice has distilled, without closing the debate: publish after the patch wherever possible; publish the analysis — what fails and why — rather than the ready-to-use weapon; grade the level of detail according to how critical the affected system is, with particular care in health, industry and infrastructure; and always accompany it with mitigations for those who cannot patch yet. The question that orders the decision is the one from section 4: what defence becomes possible that was not before. If the answer is "none, but attacking gets easier", the publication is hard to justify.

The ethics of AI applied to security. AI assistants have become everyday tools, and they bring three new questions Nimbus must resolve by policy, not case by case:

• Leakage through the prompt. Pasting into an assistant a code fragment containing credentials, a log with customer data or an extract of a contract is a disclosure of data to a third party, with everything that implies: it may be an international transfer (06-03), it may breach the article 28 contract with the clinics and it may be a breach of confidentiality. That it is convenient does not make it lawful.
• Generated code that is not reviewed. An assistant produces plausible code that may carry insecure patterns — concatenated queries, missing authorisation, invented or abandoned dependencies. Responsibility remains with whoever integrates it, and the review checklist from 05-05 applies just as much, or more.
• Offensive use. The same models write immaculate phishing e-mails with no mistakes — hence the January micro-lesson in 06-05 — which raises the baseline quality of attacks and reinforces the conclusion of this whole lesson: defence cannot depend on people spotting spelling mistakes, it has to depend on reporting and on technical controls.

The organisational answer is an AI usage policy, short and clear, forming part of POL-04 and of the training in 06-05: which tools are approved, what is never pasted into an assistant — secrets, personal data, customer data, proprietary code as decided — what review generated code requires, and who authorises a new tool. It is a three-paragraph policy that prevents an entire incident.

• Believing that good intentions make it lawful. There is no defence of "I did it to warn them". Unauthorised access remains unauthorised even if you break nothing and give immediate notice.
• Accepting an invalid authorisation. Verbal, with no scope, with no date, or given by somebody who cannot give it. And above all: nobody can authorise you over third-party systems, not even their own customer.
• Downloading data "to prove the flaw". It turns a finding into a crime and destroys any claim of good faith. Somebody else's identifier being visible is enough.
• Asking for money for a flaw found without authorisation. It may be construed as extortion, especially if it comes with a deadline or a mention of publishing.
• Logging in "just to check" with an account that is still active after leaving the company. The right of access ended with the relationship; a control failing does not restore it. Warn without logging in.
• Publishing security.txt and not monitoring the mailbox. Or letting Expires lapse. Both signal abandonment and the researcher will look for another route.
• Opening a bug bounty with no process. Forty untriaged reports in 48 hours do more reputational damage than the original flaw.
• Tip: publish your security.txt and your disclosure policy today. It costs half a day, it is free, and it decides whether the next flaw somebody finds in your product reaches your mailbox or somewhere else. It is what 05-03 left pending for you.
• Tip: always write in the report what you did and what you did NOT do. Two sentences that protect you legally and completely change how your e-mail reads at the other end.
• Tip: when in doubt, do not do it and ask. The cost of waiting for an answer is a day; the cost of getting it wrong is years.

Exercise 1 — Four situations, four decisions

For each situation, decide what you would do, justify it legally and ethically, and state what you would not do under any circumstances.

1. Iván, browsing a customer clinic's website, sees that the URL of a downloadable report contains a sequential identifier. He suspects there is an IDOR. The clinic is a Nimbus customer and Marta has a good relationship with its director.
2. Lucía discovers that her VPN account at the company where she worked a year ago is still active. She finds out because her password manager auto-filled it when she opened the site by mistake.
3. Rubén finds on a public forum a file with thousands of e-mail addresses and passwords, and sees that three belong to Nimbus customers.
4. Sara receives an e-mail from somebody claiming to have found a serious flaw in the Nimbus app, attaching a convincing screenshot and asking for 3,000 € for the details, stating that if there is no answer within 72 hours they will publish it.

Exercise 2 — The instruction you must not carry out

Marta asks Lucía, over chat: "I need you to go through [employee]'s e-mail for the last three months. We suspect he is passing information to a competitor and I don't want to tell anybody yet, not even Sara. It's urgent and confidential."

Analyse the request: what problems it raises, on which levels, and draft Lucía's reply — the literal message she would send. Also state what she would do afterwards and what she would document, and what would happen if Marta insisted.

Exercise 3 — Nimbus receives its first report

An e-mail arrives at security@nimbusreservas.example from a researcher: she has found that the API's export endpoint does not verify the tenant when a mobile app token is used, and she attaches a request and a response with somebody else's identifier visible but the content redacted. She says she has not accessed any further data, proposes 90 days and asks for public credit.

Design Nimbus's complete response: what happens in the first 48 hours, who does what, how it is decided whether this is also a GDPR breach, what is written back to her (draft the e-mail) and what is done after fixing it.

Exercise 1

1. The suspected IDOR on a customer's website. He does not test it. The system belongs to the clinic, not to Nimbus, and neither Iván nor Marta can authorise testing against it. Modifying the identifier to confirm the suspicion would be unauthorised access, however good the commercial relationship and however much he only intends to warn them. The right thing: Iván tells Marta about the observation, without having verified it, and Marta writes to the clinic's director describing what was observed — "the report identifier appears to be sequential, which sometimes indicates an authorisation problem" — and offering formal help. If the clinic wants Nimbus to verify it, that is done with written, prior, scoped authorisation. What he would not do under any circumstances: change the number "just once to be sure". That single request is exactly the conduct the law describes, and Iván would also have to explain why he accessed another person's patient report.

2. The VPN account that is still active. She does not log in. The right of access ended with the employment relationship; the company's failure to revoke it is their failing and does not restore the authorisation, and "I logged in to check whether it worked" describes a completed unauthorised access. The right thing: Lucía sends an e-mail to the security contact or to her former manager saying "my VPN credentials are still active, please revoke them", without having connected, and deletes the entry from her password manager. If she wants to be especially prudent, she takes a screenshot of the auto-fill as a record that she never authenticated. Never: connecting "to see how far I get" or sharing the finding on social media. An additional note: for the receiving company, this warning is a nonconformity in its offboarding process and should trigger a corrective action (06-04).

3. The credential dump with Nimbus customers in it. Two things have to be separated here. On the file: it is not downloaded and not kept, and the credentials are certainly not tested against any service — that would be credential stuffing, that is, unauthorised access, even if the aim is to check the risk. On the customers: Nimbus can and must act on what is its own. The right thing: (a) force a password reset on the affected accounts and revoke their active sessions, with no need to test anything; (b) review the audit table (C-07) and detections D-01/D-02 looking for earlier anomalous access to those accounts; (c) notify the customers with a clear, non-alarmist message, telling them their credentials appear in a public third-party dump and that they should also change them wherever they have reused them; (d) assess with the DPO whether any GDPR action is required — normally there is no breach at Nimbus if the credentials came from another service, but if there were successful logins there would be; and (e) use it as an argument to accelerate customer MFA. And the structural measure: subscribe to a legitimate leaked-credential monitoring service, which does this continuously and without handling dumps.

4. The 3,000 € demand. The pattern — payment before the details are handed over, a 72-hour deadline and an implicit threat to publish — is not responsible disclosure, and it may amount to extortion. It is very different from a researcher who reports and then accepts a voluntary reward. The right thing: (a) do not pay and do not negotiate the payment; (b) reply professionally and without hostility, because this may be somebody badly advised rather than an extortionist: thank them for the notice, refer them to Nimbus's disclosure policy, explain that there is no financial reward but there is public credit, and ask for the details under that policy; (c) keep the complete e-mail with its headers as evidence; (d) consult legal counsel before the next reply; (e) in parallel, take the substance seriously: the screenshot is convincing, so Lucía and Iván look for the flaw themselves and review the logs in case it has already been exploited — which would turn it into an incident and start the GDPR clock. What she would not do: pay, threaten back, or ignore it.

Exercise 2

Problems it raises, on three levels:

• Legal and data protection. Accessing a worker's e-mail affects fundamental rights and is subject to strict limits: necessity, proportionality, minimum intrusion and, generally, prior information about the employer's monitoring powers. Indiscriminate access to three months of correspondence would struggle to pass a proportionality test, and evidence obtained that way may also turn out to be invalid in any subsequent proceedings, so the measure is not merely risky: it may be useless for what Marta is trying to achieve.
• Employment. There are implications under the collective agreement and, where applicable, of informing employee representatives. A badly executed action can turn a case of information leakage into a case of infringement of a worker's rights, completely reversing the positions.
• Internal control. She is being asked to bypass the process: no record, no documented approval, no DPO and expressly excluding Sara (HR). It is exactly the pattern 06-04 identifies as the alternative path through which controls get broken. And it exposes Lucía personally, as the sole executor of an access with no cover.

Lucía's reply:

What she does afterwards and what she documents. She does not execute the e-mail access. She starts the activity review, which does have a basis and is proportionate, and she documents: the request received, her reply, the date, the scope of what she has reviewed and its result. If consultation with the DPO and counsel authorises a narrow access — for example, to metadata or to e-mails with specific external recipients over a defined period — she executes it within exactly that scope, with a second person present if possible and leaving a record.

If Marta insists without cover: Lucía restates her position in writing, asks for the instruction signed and with responsibility accepted, and if she is still required to execute it, escalates to the DPO and seeks her own advice. The underlying rule from section 4: the fact that your employer asks you for it does not relieve you of liability. And an observation worth making explicit: Marta is not acting in bad faith, she is acting in haste in the face of a real problem. That is why the right answer is not a flat refusal, but offering a path that resolves her legitimate problem within the framework. That is exactly the difference between the "department of no" of 06-01 and a useful professional.

Exercise 3

The first 48 hours.

• Hour 0-2 — Acknowledgement (Marta). A personal, non-automated reply, thanking her, giving a name and a direct contact, and confirming the 90-day deadline she proposes. It meets the policy's 2-working-day commitment and sets the tone for the whole relationship.
• Hour 2-8 — Triage (Iván and Lucía). Reproduce it in pre-production. The flaw described is serious: a mobile app token that does not go through the tenant check on the export endpoint means any customer can export other customers' data, and in clinic tenants that is data revealing health. It is classified critical on CVSS, exposure (Internet, authenticated) and data sensitivity.
• Hour 8-24 — The decisive question: has it been exploited? The append-only audit table (C-07) and the A-02 bucket access logs are queried, looking for exports from mobile tokens with a non-matching tenant, across the whole retention window. This is where it is decided whether this is a report or a breach.
• Hour 24-48 — Containment and fix. If the impact justifies it, export from the mobile app is temporarily disabled while the fix is made. The fix is structural, not a one-off patch: the endpoint goes through the current_tenant/require() dependency like every other one, the WHERE tenant_id filter is added, and a regression test is written that reproduces exactly the case in the report.

How it is decided whether it is also a GDPR breach. Using the criteria from 06-03: if the audit log shows real access to other tenants' data, there is a personal data breach, Nimbus is the processor and must notify each affected clinic within 24 hours under the contract, so that they notify the AEPD within their 72 hours. If the audit log shows no cross-tenant access across the whole retention window, it is an unexploited vulnerability: there is no breach, but the analysis and its conclusion are documented, because that is the evidence supporting the decision not to notify. And if the log retention does not cover the whole period during which the flaw existed, that has to be said honestly: not being able to rule out access is not the same as ruling it out, and the decision must be taken with the DPO. That nuance is usually what determines the real outcome in these cases.

E-mail to the researcher (day 1):

After fixing it. Five things, and all five matter: (1) invite the researcher to verify — it is the retest of 05-03, and now free of charge; (2) publish the agreed advisory and credit, and update the acknowledgements page; (3) ask why we did not detect it ourselves, which is step 9 of the loop: CI had authorisation tests, but only for web tokens, so they are extended to mobile tokens and a semgrep rule is written to detect any query against customer data with no tenant filter; (4) update the traceability matrix from 06-04 with this evidence and review whether risk R-04 in the 04-01 register changes; and (5) take it as a case into the development training of 06-05 — the best possible example, because it is our own code, it is recent and somebody outside found it. A well-handled external report does not close one flaw: it closes an entire class of flaws.

You have closed the taught part of the course with what 05-03 left pending and with what separates a competent technician from a professional. You know the legal line: unlawful access under article 197 bis, interception, the supply of tools under 197 ter, criminal damage under 264 and obstruction under 264 bis, with the five clarifications that avoid misunderstandings — unlawful access requires neither damage nor skill, remaining counts, aggravated forms exist and criminal liability is not the only kind — and with the finding that there is no good-intentions defence. You know what makes an authorisation valid: that it is given by somebody who can, with an explicit scope, a time window, in writing and beforehand; and you know the case almost everybody skips, that nobody can authorise you over third-party systems — not Marta over the cloud provider, not an employee over their employer. And you recognise the six behaviours people believe are lawful and are not, with the most frequent and worst understood: logging in with an account still active after leaving the company, when the right thing is to warn without logging in.

You handle professional ethics beyond the law: the duty of confidentiality with its four rules, the distinction between the technically possible and the acceptable — the question is not "can I?", it is "should I, on what basis and within what limit?" — the responsibility of whoever writes tools, and the hardest case of all: what to do when your employer asks you to monitor without a basis, conceal a breach or delay a notification. With the four principles that order it: leave a trail, escalate along the intended path, distinguish professional disagreement from illegality, and remember that the fact that your employer asks you for it does not relieve you of liability. And you know why the grey hat is a legal problem even when the intention is good: it does not exist as a legal category, whoever receives the warning cannot tell you apart from an attacker, and asking for a reward for a flaw found without authorisation can be read as extortion.

You have a command of responsible disclosure: why it exists, its three modes with their consequences, the role of INCIBE-CERT and CCN-CERT as intermediaries, and the usual 90-day deadlines with their rationale. You know how to report properly — summary, impact, minimal reproduction, and above all what you did and what you did not, plus the absence of any financial request, which are the two sections that protect you — and you know what is never done: exfiltrating, pivoting, asking for money, publishing early or threatening. And you know how to receive properly, which is Nimbus's side: the complete security.txt with its Expires that must be renewed, and a disclosure policy whose three useful clauses are the safe harbour, the excluded scope and the committed deadlines. With the nine-step internal loop, its two critical decisions — that triage can turn into an incident with the 72-hour clock running, and that the learning step is what gives lasting value — and the arithmetic that justifies it: handling a report well costs an hour; handling it badly costs your reputation.

You know when a bug bounty makes sense and why Nimbus should not open one yet, with the four prerequisites and the intermediate step of a private, invitation-only programme. You know the CVE system and what a CNA is, how an identifier is requested and why it is worth it: the work of an unknown researcher ends up, weeks later, protecting an SME in Valencia because its trivy picks it up on its own. And you close with the two open debates: the publication dilemma over exploits, with the question that orders it — what defence becomes possible that was not before — and the ethics of AI in security, with prompt leakage as a disclosure of data to a third party, generated code that remains the responsibility of whoever integrates it, and mistake-free phishing that confirms the thesis of 06-05: defence cannot depend on spotting spelling mistakes, it has to depend on reporting.

That closes Module 6 and with it the taught part of the course. Look back for a moment and you will see the whole journey: you started with the CIA triad and the vocabulary of risk (module 1), you understood the threat landscape and how an organisation defends itself (module 2), you learned to protect information with cryptography that is actually used (module 3), to decide with a risk register, policies, controls and a response plan (module 4), to execute with tooling, detection, pentesting, networks, applications, endpoint and cloud (module 5), and finally to sustain and demonstrate what you built with habits, regulations, the GDPR, evidence, people and ethics (module 6). And all of it on top of a concrete company: 38 people, 18,000 € a year, one sole systems administrator, an incident that cost 20 days of blindness and 1.2 TB, and a plan that fits into the real budget.

Now it is your turn. In Module 7: Final Project you stop reading about Nimbus and apply all of this to a case of your own: inventorying and classifying an organisation's assets, identifying and prioritising its risks, designing a control catalogue that fits a real budget, defining its response plan and its recovery strategy, choosing the regulatory framework that applies to it, building its traceability matrix and its awareness plan, and defending the decisions with the same judgement Marta has had to use to defend hers in every lesson. 07-01 sets out the brief. What you will be asked for is not that you know: it is that you decide, prioritise and justify it, which is exactly what is expected of a security professional on their first day at work.