The previous lesson closed by pointing out the limit of autonomy: Nimbus has designed its calendar and its roadmap by looking at its own risk, and that is fine, but there are things you do not get to choose. When a clinic asks whether Nimbus complies with the GDPR, when an institutional customer demands the ENS (Spain's National Security Framework), or when a renewal contract makes signature conditional on an ISO 27001 certification, the conversation stops being about your own priorities. This lesson lays out the map: what genuinely obliges, what is voluntary, what applies to a Spanish SME like Nimbus and what does not, and above all how a sentence written in legal language is translated into concrete work that somebody has to do on a Tuesday morning.

Validation note. This lesson is training material, not legal advice. The specific applicability of each rule depends on the sector, the size, the activity, the customers and the jurisdiction, and rules get amended. Always verify the version in force in the official sources (the BOE, Spain's official gazette; EUR-Lex; the AEPD, the Spanish Data Protection Agency; INCIBE; the CCN) and validate the scope with a professional — a specialist lawyer, a Data Protection Officer or your compliance lead — before taking decisions.

1. Four things that get confused and are not the same
2. The regulatory map applicable to Nimbus
3. NIS2 and its transposition: why an SME can end up in scope
4. The ENS (Spain's National Security Framework)
5. LSSI-CE, healthcare sector rules and PCI DSS
6. Where regulation is heading: DORA and the AI Act
7. ISO/IEC 27001 in depth
8. Other standards and schemes: when to choose each one
9. From obligation to real work: requirement, policy, control, evidence
10. The customer as a de facto regulator
11. Reusing across frameworks: the unified control framework

The first mistake any organisation makes when it approaches this terrain is to throw everything into the same bag: "regulation". But a law, a certifiable standard, a reference framework and a contract clause have different natures, consequences and costs, and confusing them leads to effort being spent in the wrong place.

Three clarifications that save arguments:

• A voluntary standard can become mandatory by contract. No law requires ISO 27001 of Nimbus, but if a customer makes it a condition of renewal, its practical effect on the bank balance is identical to that of a legal obligation.
• Complying with a framework certifies nothing to a third party. Nimbus uses CIS IG1 (04-03) and NIST CSF (02-01), and that improves its security and organises its work, but it is not certifiable: there is no "CIS certificate". It serves to explain, not to attest.
• No legal rule requires specific controls. The GDPR does not say "use AES-256". It says "appropriate technical and organisational measures" proportionate to the risk. Translating that sentence into a specific control is done by the organisation, which must be able to justify it. That is precisely section 9.

The operational conclusion for an SME is reassuring: out of a list that looks frightening, what genuinely and unconditionally obliges are the GDPR, the LOPDGDD and the LSSI. The rest depends on business decisions (which customers you sell to) or on a specific verification (NIS2). And that verification is best done in writing and dated, because "we thought it did not apply to us" is not a defence.

Directive (EU) 2022/2555, known as NIS2, replaces the original NIS and hugely widens the set of organisations subject to cybersecurity obligations. It is a directive, not a regulation: it does not apply directly, but through the national rule that transposes it. Verify the status and the exact content of the Spanish transposition in force, because the details of scope, competent authority and penalty regime are fixed there.

How you determine whether an organisation is in scope. Two criteria combine:

1. Sector. NIS2 distinguishes highly critical sectors (energy, transport, banking, health, water, digital infrastructure, public administration, space) and other critical sectors (postal services, waste management, food, manufacturing, digital service providers, research).
2. Size. As a general rule, medium and large entities are in scope (from 50 employees or 10 million euros of turnover). Below that, they are in principle out of scope save for exceptions, and the exceptions are the important part.

Hence the classification into two categories, which determines the intensity of supervision:

Why Nimbus, with 38 employees, may fall in scope anyway. Three routes, and all three are real:

• As a digital service provider. A multi-customer SaaS can fit the digital service categories in the annexes. The exact classification depends on the definition set by the transposition.
• By criticality, even though it is small. The directive allows entities below the size threshold to be included when they are the sole provider of an essential service in a Member State or when a disruption would have a significant impact. A booking SaaS used by dozens of healthcare providers is a reasonable candidate for that assessment.
• By being pulled in through the supply chain, which is the most likely route and the most immediate. NIS2 expressly obliges entities in scope to manage the risks of their suppliers. If one of Nimbus's clinic customers is an entity in scope — or belongs to a hospital group that is — it will pass the same requirements down to Nimbus by contract. Nimbus will not get a letter from the authority: it will get a security annex from its customer. We already saw this from the other side in 04-04, when Nimbus was assessing the consultancy.

Basic risk-management obligations that the directive lists (article 21), and which the learner will recognise because they are the whole course:

Incident notification. NIS2 sets out a staged procedure for significant incidents: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month, to the CSIRT or the competent authority. It is a different and additional regime to the GDPR's: one and the same ransomware attack may require notifying the data protection authority of the personal data breach and the NIS2 authority of the service disruption. Verify the exact deadlines and recipients in the rule in force.

Management liability. This is the novelty that most changes the conversation in an SME: NIS2 makes management bodies responsible for approving risk-management measures and overseeing their implementation, and requires that they receive training. It can carry personal liability and, within the framework of the directive, the possibility of temporarily barring senior managers in essential entities. In practical terms: security stops being something that can be delegated to Lucía, and the time Marta spends in the 06-01 calendar goes from good practice to documented obligation.

The ENS, governed by Royal Decree 311/2022, establishes the security policy for the use of electronic means within Spanish public administration. Its relevance for a private company like Nimbus is indirect but very concrete: if Nimbus wants to sell its SaaS to a public-sector physiotherapy centre, a public university or a town council, the ENS enters the contract. Private-sector operators providing services to public-sector entities must demonstrate compliance within the scope of that provision.

System categories. The ENS classifies each system as BASIC, MEDIUM or HIGH according to the impact of an incident on the five security dimensions — availability, integrity, confidentiality, authenticity and traceability. Note that it extends the CIA triad of 01-01 with authenticity and traceability, which reinforces the importance of the C-07 audit log.

The measures are organised into three frameworks — organisational (org), operational (op) and protection measures (mp) — with a conformity audit at least every two years for the categories that require one. The declaration or certification of conformity is published and allows the public-sector customer to demonstrate that its supplier complies.

The useful reading for Nimbus. The ENS is not an obligation today, it is a commercial decision: it opens the door to the public sector and shuts out part of the competition, in exchange for an adaptation and audit cost that for a MEDIUM category does not come in under several tens of thousands of euros for the first cycle. The good news is that the work overlaps heavily with ISO 27001 and with what has already been done in modules 4 and 5: the risk analysis, the policy, access control, activity logging, encryption and backups are the same. What does not overlap is the documentary form: the ENS has its own structure, its own statement of applicability and its own language, and translating what has already been done into it consumes time.

LSSI-CE (Law 34/2002, Spain's e-commerce and information society services act). It applies to Nimbus by the simple fact of operating a website and an online platform with economic activity. Its obligations are modest and non-compliance is among the easiest for an authority to detect, because it is visible from outside:

• Accessible provider information: registered company name, NIF (the Spanish tax identification number), registered address, contact e-mail, registry details. A legal notice, in practice.
• Marketing communications identifiable as such and with prior consent, save for the exception of a pre-existing contractual relationship with similar products, always with a simple means of objecting in each communication.
• Cookies and tracking technologies: prior information and consent, with no deceptive patterns. This point intersects with the GDPR and with the AEPD's cookie guidance in force — verify which version is current, because the criteria have been updated several times.
• Retention of connection data on the terms set by the applicable rules.

Healthcare sector rules, via customers. Nimbus is not a healthcare provider, and neither Law 41/2002 on patient autonomy nor the rules on clinical records apply to it directly. But its customers are subject to them, and they will pass the requirements down in the contract: retention periods for clinical documentation, access and traceability requirements, and limitations on who can see what. The practical consequence is twofold: a clinic's appointment history cannot be treated as just another piece of commercial data, and the processor contract (06-03) is where who answers for what gets resolved.

PCI DSS and why Nimbus reduces its scope. PCI DSS is a payment card industry standard, required by contract with the acquiring bank and the card schemes — it is not a law. It applies to whoever stores, processes or transmits cardholder data. Nimbus tokenises payments at an external gateway (A-12): the customer's browser sends the card data straight to the gateway, which returns a token with no value outside that provider. Nimbus never sees the PAN.

This drastically reduces the scope, but it pays to be precise, because expensive mistakes are made here:

• Reducing is not eliminating. There is still an applicable self-assessment questionnaire, typically from the SAQ A or SAQ A-EP family depending on how the payment form is integrated. Determining which one applies is a technical question with consequences, and it is worth confirming with the acquiring bank.
• The page that loads the form is still in scope. If Nimbus serves the page on which the card is entered, an attack on its SPA — an injected script, a client-side skimmer — captures card data even though Nimbus does not store it. Hence the CSP of 05-03 and the integrity of third-party scripts are not cosmetic.
• One slip is enough to come back into scope: someone who takes a card number over the phone and writes it down, a log that records the full body of a request, a support ticket with a screenshot. The operational rule for Rubén is simple and absolute: if a card number arrives by any channel, it gets deleted and the customer is redirected to the gateway.

Two rules that do not apply to Nimbus today but that mark the direction of travel and are worth knowing, because the pattern will repeat.

• DORA — Regulation (EU) 2022/2554 on digital operational resilience. Aimed at the financial sector (banks, insurers, fund managers) and, very relevantly, at their ICT providers. It imposes ICT risk management, incident notification, resilience testing and a very detailed contractual regime with suppliers, including a register of arrangements and rights to audit. If Nimbus one day sold to a health insurer, it would receive this regime by contract.
• Regulation (EU) 2024/1689 on Artificial Intelligence (the AI Act). A risk-based approach, with prohibited practices, high-risk systems carrying strong obligations and transparency obligations for the rest, applying in stages. It does not reach Nimbus today. It would reach it if Nimbus added, for example, a model that prioritised patients or predicted churn using data revealing health. The classification would have to be assessed before building that feature, not afterwards.

The common pattern of recent European regulation, and the reason to pay attention to it: it regulates by risk and by sector, it extends liability to the supply chain, it requires notification and it holds management accountable. Any future rule that reaches Nimbus will have that shape, and whoever already has the risk analysis, the inventory, third-party management and the evidence in place will start with almost all the work done.

It is the most frequent request a technology SME receives, so it deserves detail.

What an ISMS is. ISO/IEC 27001 does not certify that a company is secure: it certifies that it has an Information Security Management System — a set of documented processes for identifying risks, deciding controls, applying them, measuring them and improving them — and that this system works. It is a management standard, a sibling of ISO 9001. Understanding this avoids the classic disappointment of someone expecting a list of mandatory technical controls.

Structure of the standard. Clauses 4 to 10 are the auditable requirements; Annex A is the reference control catalogue.

Annex A contains the reference controls, organised into four themes — organisational, people, physical and technological. The 2022 version restructured the annex compared with the 2013 one and added controls on threat intelligence, cloud security, configuration management, data leakage prevention and web filtering. Verify which version of the standard and which edition of the annex applies to your certification.

The role of risk analysis and the SoA. Here is the heart of the standard and what distinguishes it from a checklist: controls are not picked from a list, they are derived from the risk analysis. Nimbus already did that analysis in 04-01. The Statement of Applicability (SoA) is the document that walks through every Annex A control and, for each one, declares whether it is applicable or not, why, whether it is implemented, and where the justification lives. It is the document the auditor opens first, because it reveals in two minutes whether the ISMS is real or paper. An extract:

Two details separate a credible SoA from a decorative one: exclusions are justified with a business reason, not with "not applicable", and "partial" statuses appear. An SoA with everything implemented and nothing partial is the most reliable sign that nobody filled it in honestly, and an experienced auditor will start precisely there.

Certification cycle.

What it really costs and how long it really takes in a 38-person company that has already done the work of modules 4 and 5:

The honest decision for Nimbus. With an 18,000 € annual budget and 440 hours of Lucía's time — of which 300 are already committed to operating — certifying this year would consume the entire budget and displace the 06-01 roadmap. And there lies the decisive argument: today Nimbus would reduce more real risk by spending that money on detection, immutable backups and a pentest than on a certificate. An ISMS built on half-implemented controls produces a certificate that does not correspond to effective security, which is exactly the "compliance as a substitute" anti-pattern from 06-01.

The reasonable recommendation, in three steps: (1) this year, do the underlying work and build the traceability matrix from 06-04, which is 70 % of the ISMS even though it is not called that; (2) next year, a self-assessment against ISO 27001 with a consultant over two days to find out exactly where you stand; (3) certify when a specific contract pays for it, that is, when there is an identified customer making signature conditional on the certificate. Certifying before that is investing blind; certifying then is a business decision with a calculable return.

The difference between ISO 27001 and SOC 2 confuses a lot of people and is worth being clear about. ISO 27001 is an international certificate saying "this organisation has a conforming management system". SOC 2 is an audit report issued by an audit firm under US standards, describing controls and, in Type II, verifying their operation over a period (typically 6-12 months). Type I only looks at design on a given date, so a demanding customer will always ask for Type II. A SOC 2 report is delivered under a confidentiality agreement and contains detail; an ISO certificate is one page. Neither replaces the other, and doing both doubles the audit cost but not the implementation cost, because the underlying controls are largely the same.

Selection criteria, in order: is it required by somebody who pays? What is standard in the target customer's market? How much does it overlap with what we already have? Can we operate it every year, or will it be an effort abandoned after the first certificate? That last question kills off more projects than the previous three put together.

This is the section that makes this lesson usable, and the one that leads directly into 06-04. Every obligation — legal, contractual or from a standard — always travels the same four-leg road:

A worked example from beginning to end, with a real requirement and its full journey:

Leg 1 — Requirement. GDPR, article 32.1.b: ensure "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services", and 32.1.d: "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures". The same requirement appears, in different words, in NIS2 article 21 ("assessment of the effectiveness of measures") and in Annex A of ISO 27001. One piece of work, three rules covered.

Leg 2 — Policy. The organisation decides what that means for it, in normative language and with obligation verbs:

Leg 3 — Control. What gets implemented and who answers for it: this is C-14 in the 04-03 catalogue, with Lucía as owner, quarterly frequency and a defined verification method — a full restore into an isolated environment with integrity verification.

Leg 4 — Evidence. What is shown to an auditor, to a customer or to the AEPD:

Notice what makes this evidence good, and what almost nobody includes: it records an issue detected and its corrective action. An auditor who sees perfect reports quarter after quarter suspects the test is a formality; one who sees a failure detected and corrected concludes that the control genuinely works. Paradoxically, evidence that something failed and was fixed is worth more than evidence that everything went well.

That four-leg journey is reproducible for any obligation: if a requirement lands on your desk and you do not know what to do with it, write out the four legs and you will immediately see which one is missing. It is almost always the fourth.

Long before an authority asks anything, a customer will. The security questionnaires that clinics and gym chains send to Nimbus before signing or renewing are, in practice, the most frequent audit an SME undergoes. In 04-04 Nimbus played the part of the assessor; now it takes the part of the respondent.

The golden rule: answer honestly, and do not over-promise. A false answer in a questionnaire annexed to the contract can constitute a breach of contract, and if an incident exposes it, it aggravates everything else. A "not yet, planned for the second quarter" loses fewer contracts than people fear and builds credibility when it turns out to be true.

How to industrialise the answering, because the first questionnaire costs 20 hours and the fifth should cost 3: you build a reusable security pack with the approved answers, the architecture, the certifications and guarantees, the pentest summary, the privacy policy and the breach notification procedure. Each new questionnaire is answered by copying from the pack, and only what is missing gets researched. Marta maintains the pack and it is reviewed every six months. This is developed in 06-04, where it becomes part of the evidence system.

The nightmare of any organisation facing several simultaneous requirements is doing the same work three times in three different vocabularies. The solution is the unified control framework: a single catalogue of your own controls — C-01…C-22 at Nimbus — with a mapping to the requirements of each rule. You implement and verify once; you present as many times as necessary.

Three practical consequences of working this way, and all three show up in hours of work:

• You implement once. C-14 simultaneously satisfies article 32 of the GDPR, 21.2.c of NIS2, an Annex A control and an ENS measure. Whoever organises the work by rules does four projects; whoever organises it by controls does one.
• You answer fast. When a questionnaire or an auditor from a new framework arrives, you do not start from zero: you map the existing catalogue and only work the real gap.
• You see the real gap. The table shows clearly which requirements no control of your own covers. That is the outstanding work, and it is usually far smaller than reading the rule suggests.

Validation reminder. The mapping between controls and articles in this table is indicative and for training purposes. The definitive correspondence — especially the one presented to an auditor or an authority — must be reviewed with a compliance professional and against the text in force of each rule, which changes.

• Confusing "nobody has told me anything" with "it does not apply to me". The applicability of NIS2 or the ENS is determined by analysing the rule and the activity, not by waiting for a letter. Write it down, date it and keep it: it is evidence of diligence.
• Chasing certification before security. A certificate over half-done controls is expensive, fragile and does not protect. First the control, then the paper that proves it.
• Believing that tokenising payments eliminates PCI DSS. It reduces the scope drastically; it does not eliminate it. The page that loads the form is still in play, and one card number written on a ticket is enough to come back in scope.
• Copying a template SoA. An auditor spots an SoA with no justifications of its own in five minutes: they ask why a control was excluded and there is no answer. Exclusions are justified with business reasons.
• Over-promising in a customer questionnaire. It gets annexed to the contract. A "no, not yet" loses less business than a demonstrated breach.
• Working by rules instead of by controls. It is the most effective way to triple the cost without tripling the security.
• Tip: before deciding anything, build the table in section 2 with one row per rule and three columns — applies yes/no, why, who verified it and when. It costs two hours and usually halves the anxiety, because almost everything that looked frightening does not apply.
• Tip: build the security pack while answering the first questionnaire, not the fifth. The marginal cost at that moment is zero and the later saving is enormous.
• Tip: always verify the version in force. ISO 27001 changed its Annex A in 2022; the AEPD's cookie guidance has been updated several times; NIS2 depends on the national transposition. Citing an old version in front of an auditor destroys credibility.

Exercise 1 — Classifying requirements

Marta receives these five requests in the same week. Classify each one as a legal rule, certifiable standard, reference framework or contractual requirement, state the real consequence of not attending to it and propose what Nimbus does with each in the next 30 days.

1. A public hospital in Valencia wants to contract the SaaS for its rehabilitation service and its tender documents require conformity with the ENS at MEDIUM category.
2. A gym chain sends a 90-question questionnaire and a security annex requiring incident notification within 24 hours.
3. A consultant tells Marta that "you ought to implement NIST CSF".
4. The AEPD publishes new guidance on the processing of health data in applications.
5. A US customer asks for a SOC 2 Type II report before signing.

Exercise 2 — Walking the four legs

Take this requirement: "Third-party access to systems must be time-limited, individually authorised and periodically reviewed". Walk the four legs — requirement, policy, control, evidence — for Nimbus, knowing that the third party in question is the systems consultancy (A-19) and that this is how the 02-06 incident came in. Write the policy statement in normative language, identify the controls in the catalogue and define the evidence using the structure in section 9.

Exercise 3 — The decision to certify

A customer representing 18 % of Nimbus's revenue announces that from the next financial year it will require certified ISO 27001 of all its software suppliers. Marta asks you for a one-page analysis. Structure your answer with: total cost of the first cycle, impact on the 06-01 roadmap, intermediate alternatives that might satisfy the customer, and a recommendation with conditions.

Exercise 1

The combined reading is the lesson of the exercise: of five requests that all arrive looking equally urgent, only two actually move money, one is already done, one is reading and analysis, and the remaining one depends on a commercial decision. Classifying before acting saves weeks.

Exercise 2

Leg 1 — Requirement. It appears simultaneously in: GDPR arts. 28 and 32.1.b (processors and confidentiality), NIS2 art. 21.2.d (supply chain security), ISO 27001 Annex A (supplier relationships and access rights management), ENS op.acc/op.ext, and CIS v8 controls 5, 6 and 15. One requirement, five frameworks.

Leg 2 — Policy, in POL-08 (Supplier Management) with a cross-reference to POL-02:

Leg 3 — Controls. Four from the 04-03 catalogue, none of them new: C-03 (8-hour just-in-time access with automatic revocation), C-01 (MFA mandatory for the third party too), C-09 (alert on administrative access outside the window, which is detection D-03) and C-22 (quarterly review of access and contracts). Owners: Lucía for the technical ones, Marta for the administrative ones.

Leg 4 — Evidence:

And the detail that makes this evidence good, in line with section 9: it includes the finding of the two former-employee accounts at the consultancy and its correction. It is exactly the failure that produced the 02-06 incident, now detected by a control that works rather than by a customer's phone call on day 20. That is the difference between having a control and having it demonstrated.

Exercise 3

Total cost of the first cycle. 15,000-25,000 € in money and 300-450 internal hours, mostly Marta's, spread over 9-15 months. That is: between 83 % and 139 % of the annual security budget, and the equivalent of more than half the available project margin.

Impact on the 06-01 roadmap. Devastating if done in parallel. Certifying this year means cancelling the pentest (8,000 €), the internal audit (2,500 €) and a good part of the encryption and MDM work, and consuming the management hours that sustain the monthly and quarterly reviews. Likely result: a certificate over an organisation less secure than last year's. That is literally the compliance-as-a-substitute anti-pattern.

Intermediate alternatives that might satisfy the customer, in order of cost:

1. Explain what exists and demonstrate it: the full traceability matrix, the internal audit report, the summarised pentest report, restore reports, the dashboard. Marginal cost: close to zero, because it is material that is already produced.
2. Gap analysis against ISO 27001 by a consultant (2-3 days, 2,500-4,000 €), delivering the adaptation plan to the customer with committed dates. Many customers accept a credible plan with verifiable milestones, especially if Nimbus has gone years without reportable incidents.
3. Certification with a narrowed scope covering the production SaaS platform and excluding corporate functions. It significantly reduces cost and time. Careful: the scope appears on the certificate, and an attentive customer will read whether their service is inside it.
4. A contractual commitment to certify within 18 months with a penalty for failure. It turns an entry barrier into a project milestone and gives time to plan it properly.

Recommendation. Negotiate option 2 combined with option 4, and make the final decision conditional on two verifiable things: that the customer confirms in writing that the certificate is a condition of renewal and not a preference — worth checking, because sometimes it is not — and that you calculate whether that 18 % of revenue, plus the contracts the certificate would open, covers the 20,000 € of the cycle and its 3,000-4,000 € annual maintenance. If both are confirmed, certifying stops being a security expense and becomes a commercial investment, and it must be budgeted separately from the security budget, not inside it. That distinction is the key to the whole exercise: if it comes out of the security budget, Nimbus pays for the certificate with real risk; if it comes out of the commercial budget, it pays with the margin of the contract that justifies it.

You have brought order to terrain that usually produces more anxiety than useful work. You can distinguish the four things that get confused: the legal rule you do not choose and whose breach is fined, the certifiable standard you decide on and have audited, the reference framework that gives direction but attests nothing, and the contractual requirement that does not oblige in law but moves money all the same. Along with the three clarifications that avoid arguments: a voluntary standard becomes mandatory by contract, complying with a framework attests nothing to a third party, and no legal rule requires specific controls — the translation is done by the organisation and it must be able to justify it.

You have the map applicable to Nimbus, with the reassuring conclusion that what always and unconditionally obliges are the GDPR, the LOPDGDD and the LSSI-CE, while the rest depends on business decisions or on a verification best done in writing and dated. You know NIS2: its two criteria of sector and size, the difference between essential and important entities, the three routes by which a 38-person SME can end up in scope — the most likely being being pulled in through the supply chain, which arrives as a contractual annex rather than an official letter — its article 21 obligations that turn out to be the whole course, its staged notification of 24 h / 72 h / one month which is different from and additional to the GDPR's, and the novelty that changes things most: management liability and mandatory management training. You know the ENS, its five dimensions — which extend the CIA triad with authenticity and traceability — its basic, medium and high categories, and its nature as a commercial decision that opens the door to the public sector. And you know what the LSSI requires, what arrives via the healthcare rules that bind your customers, and why tokenising reduces but does not eliminate PCI DSS, with the critical detail that the page loading the form is still in play.

You have a command of ISO/IEC 27001 with the detail it deserves: what an ISMS is and why it certifies management rather than security, clauses 4 to 10 and what Nimbus already has for each, Annex A restructured in 2022, the central role of the risk analysis and of the Statement of Applicability — with its real extract and the two signals that mark out a credible SoA: exclusions justified with business reasons and "partial" statuses that actually appear — the full certification cycle, and the honest cost of 15,000-25,000 € and 300-450 hours over 9-15 months. With the conclusion an accommodating course would not give: today Nimbus would reduce more risk by spending that money on detection, immutable backups and a pentest, and the recommendation to certify when a specific contract pays for it. You can place the other schemes — 27017, 27018, 27701, 22301, SOC 2 Type II, CIS, NIST CSF, ENS — and the real difference between an ISO certificate and a period-based SOC 2 report.

And you take away the two tools that turn all of this into work: the journey requirement → policy → control → evidence, worked from beginning to end on article 32 of the GDPR through to an evidence file with a date, an author, a hash and — what makes it valuable — a failure detected and corrected; and the unified control framework, which maps C-01…C-22 against CIS, ISO, GDPR, NIS2 and the ENS so you implement once and present many times. Plus how to handle the customer as a de facto regulator: seven model answers to questionnaires, written honestly and without over-promising, and the reusable pack that turns 20 hours into 3.

Of the whole map you have covered, one rule applies to Nimbus always, unconditionally, with no size threshold and without depending on any customer; it reaches every row of database A-01 and every file in bucket A-02; and it has a particularity that multiplies its demands: the appointment history of a physiotherapy clinic reveals health data, and that makes it special category data under article 9. In Personal Data Protection and GDPR in Practice (06-03) we go down into the detail: controller versus processor and why Nimbus is both at once, the article 5 principles with a real retention policy, the lawful bases, data-subject rights and how they are actually handled — including the uncomfortable question of how you erase someone who sits inside a backup — the Record of Processing Activities, the Data Protection Impact Assessment, the article 28 contract, international transfers, and the 02-06 incident analysed step by step against the 72-hour clock.