At the end of the previous lesson a crack was left open in the control catalogue: there are controls whose effectiveness does not depend on Nimbus. C-03 requires just-in-time access from a consultancy with its own processes; C-19 replicates backups to the region of a provider whose decisions nobody at Nimbus takes; CI drags in hundreds of dependencies written by strangers. And the detail that sums it all up: the vector of the incident in 02-06 was not a Nimbus failure, but a breach at the consultancy that Nimbus did not even get to hear about until day 20. This lesson is about that part of the perimeter you do not control but do answer for: how a supplier is chosen, what you require of them by contract, how they are supervised, how they are offboarded, and how you manage the risk of the third-party software that forms part of your product.

1. The perimeter you do not control: you outsource execution, never responsibility
2. Nimbus's third-party map
3. The return of the consultancy: anatomy of the 02-06 vector
4. The supplier management life cycle
5. Due diligence proportionate to the risk
6. What the contract must say
7. Shared responsibility in the cloud
8. Software supply chain
9. Continuous supervision and the incident that is not yours
10. The third-party register as an artefact

When a physiotherapy clinic signs up with Nimbus, it is not signing up with "Nimbus and its twelve suppliers": it is signing up with Nimbus. If the transactional e-mail provider leaks the appointment reminder messages, the clinic will call Rubén, not the provider. And if the data exposed reveals which patients attend which treatment, the one who has to explain themselves — and, very probably, notify — will be Nimbus.

Hence the fundamental asymmetry of this lesson:

There is a legal translation of this idea. When a third party processes personal data on Nimbus's behalf, EU law distinguishes between the controller — whoever decides why and how the data is processed, which here is the clinic, with Nimbus in turn being controller with respect to its own employees — and the processor, who processes it following instructions. An infrastructure or transactional e-mail provider is usually a processor (or sub-processor) of Nimbus. The practical consequence that matters today is that choosing a processor badly and not supervising them is your own breach, not somebody else's.

Validation note. The classification of each third party as a processor, a sub-processor or an independent controller, and the associated contractual obligations, depend on the specific case and have direct legal consequences. Only the idea is presented here; the development belongs to 06-03. Before signing a data processing agreement, review it with legal advisers or with your compliance lead.

Before you can manage you have to list, and most SMEs discover at this point that they have twice as many suppliers as they thought. The column that provokes the most conversations is the last one.

Three readings of the map. First: the third-party surface is bigger than your own. Nimbus has 22 assets and nine categories of third party, and several of them touch data that reveals health information. Second: the ticketing tool looks harmless until you remember that customers attach screenshots containing real patient data when they open a ticket; that is the supplier everybody classifies wrongly. Third: open source dependencies are the only third party with no contract, no point of contact and no SLA, and yet their code runs with the same privileges as Iván's.

Promised in 03-07 and here it is. Remember the timeline: day −45, the consultancy suffers a breach and credentials for accessing its customers are leaked; it tells nobody. Day 0, 22:14, someone signs in to Nimbus with the consultancy's shared account, with no MFA, and nobody notices because overnight access by the consultancy is routine. Twenty days later, 1.2 TB exfiltrated and the backups destroyed.

Five conditions had to hold at the same time, and none of them was technical:

And the cost of not having avoided them, according to the analysis in 02-06: 40 clinics at a standstill, 1.2 TB of data revealing health information in an attacker's hands, backups destroyed, a breach notification of indeterminate scope — because the logs had rotated after 7 days — and lost customers. In other words: five measures of essentially nil cost separated Nimbus from the worst day in its history.

There is an even more uncomfortable detail. The first three conditions are Nimbus's, but the breach happened at the consultancy, and Nimbus did not find out for 45 days. Even if Nimbus had had MFA, it would still not have known its supplier had been compromised. The notification clause is not paperwork: it is the only mechanism by which information reaches you from the perimeter you do not control.

What should have existed, in the order in which it gets implemented:

1. Named accounts per engineer with their name and their e-mail address, never a "consultancy" account.
2. Mandatory phishing-resistant MFA, with no exception and written into the contract.
3. Just-in-time access: it does not exist until it is requested, lasts 8 hours and revokes itself (C-03).
4. Session recording retained for 12 months, with an alert on access outside the agreed window (C-09).
5. Quarterly review of who at the consultancy still has access and why (C-22).
6. A contractual incident notification clause with a 24-48 hour deadline.

The two phases most often neglected are 1 and, above all, 5. When a company stops working with a supplier, the commercial relationship ends the day the invoice is cancelled; the technical access does not. The exit has its own checklist:

• Revoke all the supplier's accounts, including service accounts and the API keys you issued them.
• Remove their IP addresses from any allowlist, along with their certificates or SSH keys.
• Retrieve your data in a usable format before closing the account, not afterwards.
• Require a certificate of destruction for your data in their systems and in their backups, with the date on which their own backups expire.
• Disconnect integrations, webhooks and CI secrets that point at their service.
• Record the offboarding in the third-party register with a date, so the next review does not go looking for them.

It is two hours of work that almost nobody does, and it produces exactly the kind of orphan access that appears in the case studies in 02-06.

The guiding principle: do not ask a supplier of 3 people for the same as one of 3,000. A 200-question questionnaire sent to a local consultancy produces two guaranteed outcomes: they do not answer it, or they answer it dishonestly. Make the effort proportionate to the criticality:

It is the document most often asked for and least often read. Four keys:

• Type I versus Type II. Type I says the controls were designed as at a date; Type II says they operated over a period (usually 6-12 months). Only the second demonstrates effectiveness, which is exactly the distinction from 04-03.
• The scope is everything. A report may cover only one product or one region. If your data is in the service that falls outside the scope, the report says nothing about you.
• Go straight to the exceptions. The test results section lists the deviations the auditor found. A report with no exceptions at all over 12 months deserves a question, not applause.
• Look at the complementary user entity controls. Almost every report includes a list of things you have to do for the supplier's controls to work. It is the shared responsibility from section 7, written out in full.

Validation note. All these clauses have legal and financial effects, and several of them interact with data protection law (the data processing agreement) and with commercial contract law. Draft or review them with legal advisers; the content of this table is a checklist of topics, not contractual wording.

One practical negotiating tip for a company of Nimbus's size: with the large cloud or SaaS providers you are not going to negotiate anything, so your job is not to draft clauses but to read theirs and decide whether the residual risk is acceptable (04-01). Where you do have real negotiating power is with the small suppliers — the consultancy, the accounting firm — which are precisely the ones that tend to have the poorest contracts. That is where you should spend your energy.

The most expensive misunderstanding about the cloud is believing that "the provider handles security". The provider handles the security of the cloud; you handle security in the cloud. Where the line falls depends on the service model:

Look at the last three rows: they are always Nimbus's, in all three models. And they are exactly the ones that failed in the incidents in 02-06: the misconfigured bucket was a customer configuration failure, not a provider one; the PostgreSQL finding on 0.0.0.0:5432 is customer network configuration; and the credential in the .env is customer identity management. The cloud provider has not failed in any of the problems Nimbus has.

The last row deserves a specific warning for SaaS: the fact that your documents live in a cloud office suite does not mean they are backed up against a deletion of your own or against ransomware that encrypts what is synchronised. The technical detail of secure cloud and container configuration belongs to 05-07; here it is enough to know where the line falls.

Dependencies are the third party with no contract. The Nimbus API declares around 40 direct dependencies, which drag in hundreds of transitive ones, and all of them run with the same privileges as Iván's code.

The baseline defence is to pin by hash, not by version or by tag, because a tag can be reassigned and a hash cannot.

An SBOM (Software Bill of Materials) is the complete list of components an artefact contains, with versions and licences, in a standard format such as CycloneDX or SPDX. Its value is not philosophical, it is operational: the day a critical vulnerability is published in a library, the question is "do we use it?", and without an SBOM the answer takes days.

Usage: ./sbom-nimbus.sh generates and stores; ./sbom-nimbus.sh log4j answers in seconds the question that in 2021 had thousands of companies searching for a week.

Signing and verifying your own artefacts (cosign with an ephemeral identity, 03-07) attests the origin, not the absence of malice: SolarWinds distributed a perfectly signed backdoor. That is why signing is combined with review and with an explicit update policy:

The last row is the cheapest and the most forgotten: the best moment to reject a dependency is before you add it. A library with a single maintainer, no releases in two years and 300 weekly downloads is a supply chain risk you avoid with a two-minute conversation in code review.

Due diligence is done once; the risk lasts for the whole contract. Nimbus's minimum viable supervision:

• Quarterly: review of active third-party access (C-22) and of current exceptions.
• Monthly: review of the SLA KPIs and of the out-of-window access alerts.
• Continuous: subscription to the status and security notices of the critical suppliers, and monitoring of public mentions of breaches.
• Annual: re-questionnaire of the enhanced-level suppliers and update of the third-party register.

When the incident is the supplier's, the sequence matters, because the temptation to wait for information is enormous:

The two classic mistakes in this flow are waiting for the supplier to confirm before revoking their access — step 3 depends on nobody else and is free — and assuming that if the supplier does not notify, nothing has happened, which is literally what went on for 45 days in 02-06.

Validation note. If a supplier's incident may affect your customers' personal data, notification deadlines and obligations apply that do not depend on the supplier's goodwill. Consult your compliance lead or legal advisers from the very first moment; the detail is covered in 04-05 and 06-03.

Notice T-09: an offboarding is not complete until the certificate of destruction arrives, and leaving that field visible as "Pending" is what stops the exit being signed off too early.

• Having no third-party inventory. You cannot review what you have not listed, and there are always more than you think. Tip: start from Sara's list of recurring expenses; that is where all the SaaS nobody declared is hiding.
• Trusting the badge and not reading the scope. "We have ISO 27001" says nothing if the scope does not include the service you are buying. Tip: always ask for the certificate with its scope statement and the date.
• Contracts that only talk about price and availability. That is the consultancy's contract in 02-06. Tip: the incident notification clause with a deadline in hours is the one that delivers the most value per line written.
• Due diligence only at signing. The supplier changes, you change and their sub-processors change. Tip: set the annual review in the register and treat it as a control with an owner.
• Forgetting the exit. Orphan access and your data in the systems of a company you no longer speak to. Tip: an offboarding is not closed without a certificate of destruction.
• Asking a small supplier for the same as a large one. You get a made-up answer and a false sense of control. Tip: make the questionnaire proportionate to the risk and spend your negotiating energy where you can actually negotiate.
• Assuming that the cloud includes backups. Neither the SaaS office suite nor the bucket is backed up against a deletion of your own. Tip: go through the shared responsibility table service by service.
• Pinning dependencies by tag. A movable tag is equivalent to running whatever the maintainer decides tomorrow. Tip: pin by hash and use --require-hashes.

For each of these four Nimbus third parties, decide the due diligence level (light, standard or enhanced), state the three most important questions in the questionnaire for that specific case and the contractual clause that cannot be missing:

1. A SaaS electronic signature tool that Sara wants to use for employment contracts.
2. A machine translation service that Rubén wants to integrate into support, sending it the text of the tickets.
3. The cleaning company for the Valencia office.
4. A new observability provider to which the API logs would be sent in real time.

This is the real register entry for one of Nimbus's third parties. Identify every problem and put the corrections in order:

On a Monday morning, Marta reads in a trade publication that Nimbus's transactional e-mail provider (A-11) has suffered an intrusion: the attackers accessed the sending metadata of some of its customers over three weeks. The provider has not told Nimbus anything yet.

1. What Nimbus data could be affected, and why is it sensitive even though it is "only" metadata?
2. List the actions for the first four hours, in order, indicating which of them do not depend on the provider.
3. What would you demand from the provider in writing, and to what deadline?
4. What should change in the contract and in the third-party register after the incident?

Exercise 1

The point of the exercise is number 4. Sending the API logs to a third party in real time means that third party receives a continuous copy of what happens in production, and if the team has not sanitised the content of its logs, that can carry patient identifiers, e-mail addresses, tokens or fragments of clinical data. An observability provider is, in practice, a supplier with access to production data, and it has to be assessed as such. And number 2 teaches the opposite trap: a "small", cheap service can be the one that takes the most sensitive data out of your perimeter.

Exercise 2

Problems, from most to least serious:

1. The project finished in November 2025 and the agency still has administrator access to the repository. It is phase 5 of the life cycle never executed: privileged orphan access four months old. It is exactly the pattern of the 02-06 vector.
2. A shared account ("agency") instead of named accounts: you cannot tell who did what, or whether that person still works there.
3. Administrator permissions on the repository when the work required, at most, write access to a branch. Least privilege breached.
4. No incident notification clause and no return or deletion: if the agency suffers a breach, Nimbus will not find out, and its code is still on the agency's machines.
5. Never assessed (last_assessment: null) despite being classified as High criticality.
6. Access to pre-production with a "to be reviewed" classification: nobody knows whether the agency has been reading real patient data for 18 months, and that doubt is itself a notifiable finding if it is confirmed.

Order of correction: (a) today, revoke the agency account, rotate any key or token that was handed over, and review the repository and pre-production database logs to establish whether there was activity after November. (b) This week, determine whether A-22 contains real data — finally closing the "to be reviewed" box in the 01-04 inventory — and, if it does, assess the scope with the compliance lead. (c) This month, complete the formal exit: request in writing the deletion of the code and the data with a certificate, and record the offboarding in the register. (d) Before the next project, build in the prior assessment, named accounts, minimal permissions and the notification and exit clauses.

Exercise 3

(1) The sending metadata of a transactional e-mail provider includes recipient, sender, subject, date and delivery status. In Nimbus's case that is: the patient's e-mail address, the timestamp and, very probably, a subject line such as "Reminder of your Thursday appointment at Fisioterapia Levante". Even with no clinical data inside the message, the combination of recipient and clinic reveals that this person is a patient of a specific healthcare centre, which is precisely the kind of data the impact scale in 04-01 scores at 5. "Only metadata" is, in this context, a dangerous euphemism. On top of that, the API key Nimbus handed them may be affected.

(2) The first four hours, in order. The first four do not depend on the provider: (a) open the incident log and record the time and the source of the news (04-05); (b) rotate the API key Nimbus holds with that provider, which is an action of your own, immediate and free; (c) review your own logs of that key's use in case there were sends not originated by Nimbus; (d) determine exactly what information is sent to that provider — which fields, with what subject lines, with what retention — so you can bound the exposure without waiting for anyone; (e) contact the provider in writing demanding confirmation of whether Nimbus is among those affected; (f) inform Marta and activate the response team; (g) prepare, without sending it yet, a draft communication to customers.

(3) In writing and to a 24-hour deadline: whether Nimbus is among the affected customers; the exact time window of the access; which categories of data were compromised and whether they include content as well as metadata; whether there is evidence of exfiltration or only of access; what measures they have taken; and whether they have notified the supervisory authority. And one additional request almost nobody makes: the list of Nimbus's sends falling within that window, which is what would allow precise notification instead of assuming the worst case, which was exactly Nimbus's problem in 02-06.

(4) In the contract: an explicit notification deadline in hours (if there was none, or it was 72 h, bring it down to 24), an obligation to provide the detail of the affected sends, and an updated declaration of sub-processors. In the third-party register: raise the criticality if it was underrated, bring the next assessment forward, and add the incident to the supplier's history — a fact that will weigh at the next renewal. And in the 04-01 risk register: this incident is a reassessment trigger, and a specific risk should appear covering the exposure of appointment metadata through third parties, with its own treatment. One technical improvement that scores well here: reduce the data sent to the provider to an opaque identifier and a generic subject line, applying minimisation.

You have learned to manage the part of the perimeter you do not control. You start from the fundamental asymmetry: execution, cost and technical knowledge can be outsourced, but responsibility never can, neither towards the customer nor towards the authority, and nor can A-20's reputation — with the legal distinction between controller and processor sketched here and developed in 06-03. You have Nimbus's third-party map with its nine categories, and its three readings: the third-party surface is bigger than your own, the ticketing tool is the supplier everybody classifies wrongly because customers attach screenshots with patient data, and open source dependencies are the only third party with no contract, no point of contact and no SLA whose code runs with full privileges.

You have gone back to the consultancy in the 02-06 incident and taken its vector apart: five simultaneous conditions — permanent access, a shared account, no MFA, no logging or alerting, no notification clause — none of them technical and all of them of essentially nil cost. With the most uncomfortable detail of all: even if Nimbus had had MFA, it would still have gone 45 days without knowing its supplier was compromised, because the notification clause is the only mechanism by which information reaches you from the perimeter you do not control.

You know the supplier life cycle and in particular its phase 5, the exit, which almost nobody executes: revoke all accounts and API keys, remove IP addresses and certificates, retrieve the data before closing the account, require a certificate of destruction and record the offboarding. You know how to carry out proportionate due diligence with three levels and a full questionnaire for the enhanced level, and you know how to read a SOC 2 report: Type II and not Type I, scope above badge, go straight to the exceptions and do not ignore the complementary user entity controls. You have the list of contractual clauses with its legal validation note and the realistic negotiating advice: with the big players you do not negotiate, so read and decide; with the small ones you do, and they are the ones with the worst contracts.

You have the shared responsibility model, with the decisive observation that configuration, identities and data are always yours in IaaS, PaaS and SaaS — and that, consequently, the cloud provider has not failed in any of the problems Nimbus has. And you can handle the software supply chain: direct and transitive dependencies, typosquatting, dependency confusion, maintainer takeover and CI compromise; pinning actions and dependencies by hash rather than by movable tags; the signed SBOM, whose value is answering "do we use that component?" in seconds; artefact signing that attests origin and not the absence of malice, with SolarWinds as the reminder; and an update policy with deadlines, whose cheapest line is the last one: the best moment to reject a dependency is before you add it. The lesson closes with continuous supervision, the response flow when the incident is the supplier's — where revoking access and rotating keys depends on nobody and comes first — and the third-party register, in which an offboarding is not closed until the certificate of destruction arrives.

And notice what has happened twice in this lesson. Analysing the consultancy's breach and responding to the e-mail provider's, you have needed something you do not yet have: an incident log, a team with roles, a decision on who is told and within what deadline, and a sequence agreed in advance. In 02-06, at 09:00 on day 20, Marta called the team together and nobody knew what to do first. That gap is not filled by the best risk register or the best control catalogue.

In the next lesson, Incident Response Plan (04-05), you will write the plan before the incident, because at three in the morning nobody improvises well: the NIST SP 800-61 phases, Nimbus's response team with deputies and out-of-band contacts, the severity matrix, preserving evidence before touching anything, the real trade-offs of containment, the customer communication templates, the incident log, one runbook written out in full and the blameless post-mortem applied to the incident in 02-06.