Implementing Regulations atop an ISMS experimental

Implementing Regulations atop an ISMS One management system, four regulations, ninety-three controls The regulation grammar. Why regulators ask for systems, not heroics: the five-part grammar (scope, duties, measures, reporting, oversight), CIA as the requirement language, and the four sector vignettes the course builds against.. State the five-part regulation grammar and give one example of each element.. Explain why a regulation asks for evidence of a system rather than a one-off fix.. Apply the five-part regulation grammar to identify which of the four teaching cases (Section 2.6) a given regulatory duty applies to.. The five-part grammar, CIA as the requirement language, The four teaching cases, Systems versus heroics The regulation grammar Regulators do not ask an organization to be lucky once. They ask for a system that keeps producing evidence of security, audit after audit, incident after incident. This module gives you the one grammar the rest of the course reuses to read any regulation quickly: scope, duties, measures, reporting, oversight. The five-part grammar The five elements are not independent. Scope decides who the duties attach to; duties decide which measures are mandatory rather than merely prudent; measures generate the evidence that reporting deadlines force into the open on a schedule; and oversight exists precisely because a self-graded system invites drift. Read any one element in isolation and it looks arbitrary. Read all five together and the grammar reveals why regulators keep returning to the same shape, directive after directive, regulation after regulation. Every regulation module in this course (07 Network Information Security Directive 2 (NIS2), 08 Digital Operational Resilience Act (DORA), 09 Cyber Resilience Act (CRA), and the Legislation, Policy, Measures (LPM) lesson inside 07) instantiates this same five-row table against its own case. Learn the grammar once here and you will never read a regulation as an undifferentiated wall of text again. CIA as the requirement language Regulators rarely say "confidentiality," "integrity," or "availability" directly, but their duties and measures decompose cleanly onto that lens using the Confidentiality, Integrity, Availability (CIA) framework: a reporting deadline exists because availability and integrity failures must surface fast; access-control duties exist to protect confidentiality; and change-management duties exist to protect integrity. Reading a statute through CIA turns legal prose into a checklist a security team can act on. The mapping works in the other direction too: name the CIA property a proposed control protects, and the matching duty is usually easy to find. A duty requiring immutable, tamper-evident audit logs protects integrity as much as it protects the ability to investigate later. A duty capping how long personal data may be retained protects confidentiality by shrinking the pool of data that could ever be exposed. Practising this translation before Module 07 applies it to a live statute is the fastest way to stop treating regulatory text as an undifferentiated wall of legal prose. The four teaching cases Modules 01 to 06 build the ISO/International Electrotechnical Commission (IEC) 27001:2022 management system itself, illustrated with short examples drawn from all four cases. Modules 07, 08 and 09 each apply one regulation fully to its own dedicated case. Module 11's capstone runs one simulated audit or regulator inquiry per case, the accepted cost of teaching four clean examples instead of one entangled one (Architecture Decision Record (ADR)-026). The four cases differ deliberately in size, sector and regulatory exposure: a mid-sized public water utility, a payment-services provider to two banks, a connected-device manufacturer, and a regional electricity distributor with a legacy French designation layered on top of NIS2. Despite those differences, the same five-part grammar reads cleanly against every one of them, which is the point: the grammar is a property of how regulators write, not a property of any one sector. Open the lab to map a short statute extract onto the five-part grammar, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Context and scope. ISO/IEC 27001:2022 Clause 4: interested parties, boundaries, interfaces and dependencies, producing a defensible ISMS scope statement.. Identify an organization's interested parties and their information security requirements.. Draw the ISMS boundary, including interfaces and dependencies with parties outside it.. Write a scope statement that would survive a Stage 1 audit challenge.. Interested parties, Boundaries and interfaces, Dependencies outside the ISMS, Writing a defensible scope statement Context and scope An Information Security Management System (ISMS) that scopes itself wrong is wrong forever after, no matter how well every later clause is executed. Clause 4 of ISO/International Electrotechnical Commission (IEC) 27001:2022 is where that first, load-bearing decision gets made. Clause 4 is deliberately short in the standard's own text, which tempts some organizations to treat it as a formality to clear before the real work of Clause 6 risk assessment begins. Treating it that way is a mistake this module exists to correct: every asset Module 02 will need to see, and every interested party whose requirement Module 05's policy pack must satisfy, is first named or excluded right here. Interested parties List everyone with a stake in the ISMS: regulators, customers, employees, suppliers, insurers, shareholders. For each, state what they actually need from information security, not what is convenient to assume they need. A regulator's requirement is rarely negotiable; a customer's stated requirement often is more specific than the contract implies. Some interested parties carry statutory weight that no negotiation can soften: a data protection authority's requirement, a sector regulator's minimum control set, or a critical-infrastructure designation each function as a floor beneath which the ISMS cannot fall regardless of budget or preference. Other parties, such as a single enterprise customer's security questionnaire, are genuinely negotiable within limits. Recording that difference explicitly in the interested-party list, rather than treating every requirement as equally flexible, is what lets Module 02's risk criteria be set honestly rather than optimistically. Boundaries, interfaces and dependencies The ISMS boundary is not the org chart. It is the set of assets, processes and locations the management system actually governs, plus every interface where something outside that boundary touches something inside it: a supplier's support access, a payment processor's API, a facilities contractor's badge system. Every interface is a place risk crosses the boundary in either direction, and Module 02's risk register will need to see each one. Every dependency crossing the boundary needs an owner on the inside, even when the asset itself sits outside the ISMS. A supplier's remote-access account should map to an internal sponsor who reviews it periodically; a payment processor's API key should map to an internal service owner who knows what happens if that key is revoked. Without that internal owner, an interface becomes a blind spot precisely at the moment Module 02's risk identification exercise goes looking for one. Writing a defensible scope statement A scope statement that would survive a Stage 1 audit challenge names the organizational units, locations, assets and technology included, states any exclusions with a reason, and accounts for every interested-party requirement and every boundary interface identified above. A one-sentence scope statement is nearly always a sign that this work was skipped, not that the organization is simple. A scope statement earns its defensibility from what it excludes as much as from what it includes. Naming a legacy subsidiary, a decommissioned data centre, or a business unit acquired after the ISMS was first scoped, and stating plainly why each sits outside the boundary, closes the exact gap an auditor is trained to probe first: the exclusion nobody thought to justify. Open the lab to draft a scope statement for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Risk assessment and treatment. The ISO/IEC 27005:2022 process: criteria, identification, analysis, evaluation and treatment, linked to the VERDICT risk spine and the NIST CSF 2.0 Govern function.. Set risk criteria and identify information security risks against a stated asset inventory.. Analyse and evaluate a risk, then select a treatment option and justify it.. Build a risk register with treatment plans that a Statement of Applicability can cite.. Risk criteria, Identification and analysis, Evaluation and treatment options, The risk register as a living document Risk assessment and treatment Every control in the Statement of Applicability should trace back to a risk in this module's register. If it cannot, the control is either unjustified or the risk process missed something. ISO/International Electrotechnical Commission (IEC) 27005:2022 is the process this module teaches; VERDICT's risk spine and the NIST Cybersecurity Framework (CSF) 2.0 Govern function supply the surrounding vocabulary. Risk work in this module is deliberately mechanical rather than intuitive: a stated scale, a stated formula, and a stated threshold, applied consistently, produce a register two different reviewers would populate the same way. That consistency is what lets Module 03's Statement of Applicability cite a risk register entry as its justification with confidence, rather than treating each control's inclusion as a matter of individual judgement. Criteria, identification, analysis, evaluation Set risk criteria before you find a single risk: what likelihood and impact scale will you use, and what score triggers mandatory treatment? Then identify risks against the asset inventory Module 01's scope produced, analyse each for likelihood and impact, and evaluate the result against your criteria. say: R equals L times I. where $L$ is likelihood on your chosen scale and $I$ is impact on the same scale. A simple product is not the only valid model, but it is the one this course's rule-based grader checks against, per Architecture Decision Record (ADR)-026's Fork 2 resolution. Criteria set before any risk is found should state, in writing, what score triggers mandatory treatment, who has authority to accept a risk above that threshold, and how often the criteria themselves get revisited. Setting criteria after risks are already identified invites the criteria to bend toward whatever score the identified risks happen to produce, which defeats the purpose of having criteria at all. Treatment options None of the four options is inherently superior; the choice should follow from the risk's score against the stated criteria, not from which option is cheapest or most familiar to implement. A risk rated far above the treatment threshold that gets 'retained' anyway, with no owner and no review date, is not a treated risk. It is an unrecorded decision to accept whatever the risk eventually costs. The risk register as a living document A risk register that is filled in once and never reopened is a compliance artifact, not a management tool. Tie each entry to a review cadence, an owner, and the Statement of Applicability control(s) it justifies, so Module 03's inclusions and exclusions have somewhere real to point. A register reviewed only once a year, immediately before a Stage 2 audit, tends to accumulate stale entries: risks whose likelihood changed months earlier, controls that were implemented but never marked complete, owners who left the organization. Tying the review cadence to Module 05's management review agenda, rather than to the audit calendar alone, keeps the register describing the risk landscape as it actually is rather than as it was when the entry was first written. Open the lab to build a risk register entry for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Controls and the Statement of Applicability. Annex A's 93 controls across four themes (organizational, people, physical, technological), and writing inclusion and exclusion justifications an auditor will accept.. Identify and classify an Annex A control into its correct theme (organizational, people, physical, technological).. Write a justified inclusion for an implemented control, citing the risk it treats.. Write a justified exclusion for a control that genuinely does not apply, without hand-waving.. Annex A's four themes, The 93 controls at a glance, Justifying inclusion, Justifying exclusion Controls and the Statement of Applicability The Statement of Applicability (SoA) is the single document an auditor reads first, because it is the Information Security Management System (ISMS)'s own claim about which of Annex A's 93 controls apply, and why. A sloppy SoA undermines confidence in everything that follows it. Annex A's four themes ISO/International Electrotechnical Commission (IEC) 27002:2022 gives each control's full implementation guidance; Annex A of ISO/IEC 27001:2022 itself only lists the control titles, which is why a serious SoA cites both documents. The four-theme structure replaces the fourteen clause-numbered domains ISO/IEC 27001:2013's Annex A used, a change that surprises auditors and implementers trained on the older standard. Mapping an organization's existing 2013-vintage control set onto the 2022 themes is itself a common piece of transition work, and getting the theme classification right matters beyond tidiness: an auditor sampling the technological theme expects a materially different kind of evidence than one sampling the people theme. Justifying inclusion An inclusion justification names the risk (from Module 02's register) the control treats, and points at where the control is actually implemented, not merely intended. "Implemented" and "planned" are different SoA states, and conflating them is one of the most common Stage 2 findings. A strong inclusion justification also states how the control's operation is verified, not merely that it exists. 'Multi-factor authentication is enforced on all privileged accounts, verified quarterly by an access review' survives an auditor's follow-up question in a way that 'multi-factor authentication is implemented' alone does not, because it answers the question an auditor is trained to ask next: how do you know it is still working today? Justifying exclusion An exclusion is not a shortcut. It states a real reason the control does not apply, typically because the risk it treats does not exist in this organization's context, or because another control already fully treats that risk. "Not applicable" with no reason is not a justification; it is a placeholder an auditor is trained to challenge. A common failure mode is excluding a control because it is inconvenient rather than because it is genuinely inapplicable. A control governing cryptographic key management, excluded because the organization 'does not do much encryption,' rarely survives scrutiny once the risk register shows a risk that key management would actually treat. The honest test is always the same: does the risk this control exists to treat exist here, and if it does, is it already fully treated by something else already in the Statement of Applicability? Open the lab to write one inclusion and one exclusion justification for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ The catalog crosswalk lab. Expressing implemented controls in ISO/IEC 27002:2022, NIST SP 800-53r5 and CIS Controls v8.1, with NIST CSF 2.0 as the pivot language between all three.. Build a mapping of one implemented control across ISO/IEC 27002, NIST SP 800-53r5 and CIS Controls v8.1.. Explain why NIST CSF 2.0 functions as a pivot rather than a fourth catalog to map into.. Identify where two catalogs describe the same control with materially different granularity.. 27002 to SP 800-53r5, 27002 to CIS v8.1, CSF 2.0 as the pivot, Catalogs as dialects, not different truths The catalog crosswalk lab Three control catalogs describe overlapping ground: ISO/International Electrotechnical Commission (IEC) 27002:2022, NIST Special Publication (SP) 800-53r5, and Center for Internet Security (CIS) Controls v8.1. Learning all three as separate courses would triple the work for no new security value; this module teaches catalog fluency instead, in a single mapping lab. Why a pivot, not a fourth catalog NIST Cybersecurity Framework (CSF) 2.0 is not a fourth catalog to map controls into. It is a shared vocabulary of six functions (Govern, Identify, Protect, Detect, Respond, Recover) that both other catalogs already align to, which makes it the pivot language you translate through rather than another destination to translate into. Treating CSF 2.0 as a pivot rather than a destination changes what 'finished' looks like for this lab. A crosswalk that stops at CSF 2.0, listing which function a control supports and nothing else, has not actually crosswalked anything; it has merely tagged the control. The lab's real deliverable is the ISO/IEC 27002-to-NIST SP 800-53r5-to-CIS Controls v8.1 mapping itself, with CSF 2.0 functions used only as the shared checkpoint that confirms the three catalog entries genuinely describe the same underlying outcome. Catalogs as dialects Take one implemented control, for example multi-factor authentication on privileged accounts, and express it in all three catalogs' own terms. The underlying security outcome does not change; only the vocabulary and the granularity do. ISO/IEC 27002 states the control at policy level; NIST SP 800-53r5 typically states it with more implementation and assessment detail; CIS Controls v8.1 states it as a prescriptive, numbered safeguard. This is also why swapping one catalog's vocabulary for another's mid-conversation causes so much confusion in practice: a control owner fluent in ISO/IEC 27002's policy-level language and an auditor trained on NIST SP 800-53r5's control-and-enhancement structure can describe the identical safeguard and sound, to each other, as though they disagree. The crosswalk lab exists precisely to make that disagreement visible as a translation problem rather than a substantive one. Where granularity genuinely differs Not every control maps one-to-one. Sometimes one ISO/IEC 27002 control corresponds to several NIST SP 800-53r5 controls, or a single CIS safeguard bundles what ISO/IEC 27002 treats as two separate controls. Naming that mismatch honestly, rather than forcing a false one-to-one mapping, is the actual skill this lab tests. Granularity mismatches are not a flaw in any one catalog; they reflect each catalog's own design goal. ISO/IEC 27002 is written to be broadly applicable across organization types, which pushes it toward policy-level statements. CIS Controls v8.1 is written to be immediately actionable by a security operations team, which pushes it toward numbered, prescriptive safeguards. Neither goal is wrong, and a crosswalk that pretends they produce identically grained statements will eventually mislead whoever relies on it. Open the lab to crosswalk ten implemented controls across all three catalogs for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Operating the ISMS. ISO/IEC 27001:2022 Clauses 5 to 10: policies, competence, awareness, documented information, metrics and management review, the machinery that keeps an ISMS alive between audits.. Draft a policy pack that satisfies Clause 5 leadership and Clause 7 support requirements.. Design a measurement plan with metrics that a management review can actually act on.. Explain what a management review must consider under Clause 9.3.. Leadership and policy, Competence, awareness, documented information, Metrics that management review can use, The management review agenda Operating the ISMS Clauses 4 and 6 build the Information Security Management System (ISMS); Clauses 5, 7, 8, 9 and 10 keep it alive between audits. A management system that is only ever assembled for the auditor's visit is not a management system, it is theatre. The clauses that keep an ISMS alive are less dramatic than the risk assessment or the Statement of Applicability, which is precisely why they are the ones most often left to decay. A policy pack drafted once at certification and never revisited, or a management review agenda that repeats the same slide quarter after quarter, is the most common way a technically sound ISMS quietly stops being a management system at all. Leadership and policy Clause 5 requires top management to demonstrate leadership, not merely sign a policy someone else wrote. A policy pack that survives scrutiny states intent in plain language, assigns accountability by role, and is actually referenced by the operational documents beneath it. Leadership evidenced only by a signature on a policy document, with no further trace, tends not to survive a Clause 5 interview. An auditor asking a Chief Information Security Officer (CISO) or equivalent role-holder to describe how a specific policy decision was reached, and receiving a clear account of the trade-off considered, is looking for exactly the kind of leadership Clause 5 requires: visible, personal, and able to explain itself under questioning, not merely present on paper. Competence, awareness, documented information Clause 7 requires the organization to determine the competence people doing ISMS-relevant work need, close any gap, and keep evidence of having done so. Awareness is not the same as competence: everyone needs to know the policy exists and what it means for them; only some roles need the deeper competence to implement it. Evidence of competence is usually easier to gather than evidence of awareness, which is exactly why awareness gets neglected. A training record proves someone attended a session; it does not prove they could apply the policy correctly under pressure. A short, role-specific scenario check, given months after the training rather than immediately after it, tests retention rather than merely attendance, and produces evidence a management review can actually act on. Metrics that management review can use A metric earns its place on a management review agenda only if a plausible result would change a decision. "Number of policies published" is usually noise; "mean time to close a critical vulnerability" is usually signal. Choosing metrics against the signal-versus-noise test also means retiring metrics once they stop earning their place. A metric that was signal when an ISMS was newly certified, such as the count of policies published, often decays into noise a year later once every required policy already exists; continuing to report it anyway crowds the management review agenda with numbers nobody is actually deciding anything from. The management review agenda Open the lab to build a policy pack and a measurement plan for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Resilience: the ISO 22301 layer. Business impact analysis, continuity strategy and testing under ISO 22301:2019, and what DORA will later demand of this same layer.. Run a business impact analysis and derive recovery time and point objectives.. Explain and select a continuity strategy proportionate to a stated impact and cost.. Design a continuity test that would satisfy both ISO 22301 and DORA's resilience-testing expectations.. Business impact analysis, Recovery objectives, Continuity strategy, Testing the plan Resilience: the ISO 22301 layer ISO/International Electrotechnical Commission (IEC) 27001 protects information; ISO 22301:2019 protects the organization's ability to keep operating when something protecting that information fails anyway. Digital Operational Resilience Act (DORA) will later demand a specific, testable version of this same layer from Meridis Pay (Module 08), which is why the resilience layer is built here, before any regulation is applied to it. Business impact analysis A business impact analysis identifies which processes matter most, how fast their unavailability starts to hurt, and what resources they depend on to resume. Its two headline outputs are the recovery time objective (how long an outage can be tolerated) and the recovery point objective (how much data loss can be tolerated). A business impact analysis is only as good as the people consulted to build it. Asking the process owner alone tends to overstate criticality, since every owner has an incentive to argue their own process matters most; triangulating against downstream dependents, customer contracts and regulatory deadlines produces a recovery time objective the rest of the organization will actually accept when a real incident forces a hard prioritization call. Continuity strategy and testing A continuity strategy proportionate to a low-impact process might be a documented manual workaround; a strategy proportionate to a critical process might be a hot standby site. Whichever strategy is chosen, ISO 22301 requires it to actually be tested, not merely documented, and a real, well-reported example shows why: the July 2024 CrowdStrike Falcon sensor update caused widespread outages across airlines, healthcare and other sectors worldwide, not through an attack but through a third-party software update, exactly the kind of dependency a continuity test should have exercised in advance. A tabletop exercise and a full failover test verify different things and neither substitutes for the other. A tabletop confirms that the people involved know the plan and can reason through a scenario together; a full failover confirms that the technical mechanism the plan depends on actually works under realistic conditions. A continuity programme that only ever runs tabletops has evidence of understanding, not evidence of capability. What DORA will later demand DORA does not accept "we have a plan" as evidence. Its digital operational resilience testing regime, including threat-led penetration testing for the most significant entities, requires the same continuity strategy this module builds to be exercised under realistic, adversarial conditions. The gap between 'documented and rehearsed' under ISO 22301 and 'tested under realistic, adversarial conditions' under DORA is not cosmetic. A continuity plan can pass a scheduled, cooperative tabletop and still fail the moment a threat-led penetration test assumes an adversary who is actively trying to prevent recovery rather than politely waiting for the plan to execute. Building the ISO 22301 layer with that harder future test already in mind is why this module sits before Module 08 rather than after it. Open the lab to run a business impact analysis and design a continuity test for one of the four teaching cases, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ NIS2, with the LPM lesson. Classification, Article 20 management-body duties, Article 21 minimum measures and Article 23 reporting timelines, worked against Rhône Valley Water Authority; the LPM/OIV lesson against Occitanie Électricité Distribution as ancestor and French transposition.. Classify an entity as essential or important under NIS2 by sector and size.. Perform the Article 23 reporting sequence (24 hour early warning, 72 hour notification, one month final report).. Explain how France's LPM/OIV regime anticipates and now folds into the NIS2 transposition.. Essential and important entities, Article 20 duties and Article 21 measures, Article 23's three deadlines, LPM/OIV: ancestor and transposition NIS2, with the LPM lesson Network Information Security Directive 2 (NIS2) (Directive (EU) 2022/2555) is the first regulation this course applies the five-part grammar to in full, worked against Rhône Valley Water Authority, a regional water and wastewater utility of roughly 140 staff. Scope: essential and important entities NIS2 classifies covered entities as essential or important by sector and size. Water and wastewater is an Annex I essential-entity sector, which is why Rhône Valley Water Authority is the case this module builds against rather than, say, Meridis Pay, whose regulation is Digital Operational Resilience Act (DORA), not NIS2. Sector classification alone does not finish the scoping question; size thresholds under NIS2 mean a very small entity in an otherwise essential sector can fall outside the directive's scope entirely, while a larger entity in an Annex II important-entity sector can still be caught. Rhône Valley Water Authority's roughly 140 staff comfortably clears the relevant size threshold for its sector, which is part of why this module can use it as a clean, uncontested example rather than one requiring a borderline scoping argument first. Duties and measures Article 20 places accountability for cybersecurity risk-management measures on the management body itself, including mandatory training. Article 21 then lists minimum measures: risk analysis, incident handling, business continuity, supply-chain security, and more, each of which should already sound familiar from Modules 02 and 06. Article 20's mandatory training requirement for the management body is easy to treat as a footnote and expensive to actually skip. A management body that has never sat through the training cannot credibly demonstrate the accountability Article 20 assigns to it personally, which makes the training record itself one of the more scrutinized artifacts in a NIS2 supervisory review, alongside the Article 21 measures it is meant to inform. Article 23's three deadlines There is no partial credit on these deadlines in this course's grader: a report that misses the 24 hour early-warning step fails, with the article cited, because a late early warning is not a smaller version of a compliant one, per Section 4 of the specification. The LPM lesson: ancestor and transposition France's Loi de Programmation Militaire (LPM) designated opérateurs d'importance vitale (OIV) years before NIS2 existed, and imposed Agence nationale de la sécurité des systèmes d'information (ANSSI)-supervised sector-specific security rules on them. Worked against Occitanie Électricité Distribution, a regional electricity distribution operator with an OIV designation: France's NIS2 transposition is absorbing and extending that same OIV logic rather than replacing it outright, which is why LPM is taught as a lesson inside this module and not as a thirteenth module of its own (Architecture Decision Record (ADR)-022). France is not unique in layering a national critical-infrastructure regime beneath NIS2's transposition; several member states carried forward pre-existing sector-specific obligations rather than starting from a blank page. What makes the LPM/OIV case worth a dedicated lesson here is how cleanly it demonstrates the general pattern: national security legislation predating an EU directive tends to survive as texture inside the transposition rather than being repealed by it. Open the lab to classify both cases and produce a 24 hour and 72 hour reporting pack for Rhône Valley Water Authority, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ DORA. The ICT risk management framework (Articles 5 to 16), incident classification and reporting, digital operational resilience testing including threat-led penetration testing, and the register of information for ICT third-party providers, worked against Meridis Pay.. Build a register of information entry for a critical ICT third-party provider.. Classify a major ICT-related incident and sequence its regulatory reports.. Explain what threat-led penetration testing adds beyond a standard penetration test.. The ICT risk management framework, Incident classification and reporting, Threat-led penetration testing, The register of information DORA Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554) is worked against Meridis Pay, a payment-services Information and Communication Technology (ICT) provider delivering services to two regional banks, a clean illustration of DORA's ICT third-party dimension without a Network Information Security Directive 2 (NIS2) or Cyber Resilience Act (CRA) obligation muddying the case. The ICT risk management framework Articles 5 to 16 require financial entities (and, through their contracts, their critical ICT third-party providers) to run an ICT risk management framework: identify, protect, detect, respond, recover, learn, and communicate, a cycle that should look familiar from Module 04's NIST Cybersecurity Framework (CSF) 2.0 pivot. The seven-stage cycle is not merely descriptive; DORA expects each stage to leave evidence. 'Identify' should point at a current ICT asset inventory; 'learn' should point at a post-incident review that actually changed something. A financial entity that can narrate the cycle from memory but cannot produce the artifact each stage is supposed to generate has, in supervisory terms, described a framework rather than operated one. Incident classification and reporting DORA's major-incident reports proceed through fixed stages on fixed regulatory timelines: an initial report, one or more intermediate reports as the picture develops, and a final report once the incident is resolved and its root cause understood. Threat-led penetration testing Beyond an ordinary penetration test, DORA's most significant entities must run threat-led penetration testing: red-team style engagements that simulate real threat-actor tactics against production systems under controlled, supervised conditions, closer to a live-fire exercise than a routine scan. Scoping a threat-led penetration test starts from cyber threat intelligence about who would plausibly target the entity and how, not from a generic checklist of attack techniques. That threat-intelligence-led scoping is the feature ordinary penetration testing rarely has and threat-led penetration testing is built around, which is also why the most significant entities, rather than every DORA-covered firm, carry the obligation: the exercise only teaches something new once an entity is a plausible, specific target. The register of information Financial entities must maintain a register of information covering every contractual arrangement with an ICT third-party provider. Because Meridis Pay is itself such a provider to its two bank clients, this module works the register from both directions: what Meridis Pay's own clients must record about it, and what Meridis Pay must in turn record about its own subcontractors. Keeping the register current is harder than building it the first time. A subcontractor added mid-year, a service tier upgraded without a formal contract amendment, or a provider acquired by another firm can each silently invalidate an entry that was accurate the day it was written. Treating the register as a one-time deliverable rather than a maintained artifact is one of the more common gaps a DORA supervisory review surfaces. Open the lab to build a register of information entry and an incident-report sequence for Meridis Pay, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ CRA. Product scope, Annex I essential requirements, conformity routes and CE marking, and the reporting regime effective 2026-09-11, worked against Ondine Sensors' connected metering gateway; a CCICCS-defined assessment, since no external CRA credential exists yet.. Determine whether a product with digital elements falls inside CRA scope.. Build and assemble a conformity file demonstrating Annex I essential requirements are met.. Explain what must be reported, to whom, and within what deadlines once the CRA's reporting regime takes effect.. Product scope under the CRA, Annex I essential requirements, Conformity routes and CE marking, The 2026-09-11 reporting regime CRA The Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847) is the first regulation in this course aimed at a product rather than an organization's operations, worked against Ondine Sensors, a manufacturer of a connected industrial metering and sensor gateway with firmware. Product scope A "product with digital elements" placed on the EU market falls inside CRA scope whether it is consumer or industrial equipment, and whether its connectivity is direct or indirect. Ondine Sensors' gateway, sold to industrial customers rather than consumers, is squarely in scope for exactly this reason. Indirect connectivity is the scoping detail organizations most often miss. A product with no network interface of its own but that is intended to connect to another product, or is supplied alongside software that connects it, can still fall inside CRA scope. Ondine Sensors' gateway connects directly, which keeps this module's teaching example uncomplicated, but a learner assessing a real product should check both direct and indirect connectivity before concluding CRA does not apply. Annex I essential requirements and conformity Annex I sets essential requirements across the product's lifecycle: security by design and by default, vulnerability handling, and clear information for the user, among others. Meeting them, and demonstrating that you have met them, is what a conformity assessment and Conformité Européenne (CE) marking certify. Conformity is not a single event that happens once at launch. Annex I's essential requirements apply across the product's entire lifecycle, which means a vulnerability discovered two years after CE marking is not a problem the conformity assessment already discharged; it is a live obligation under vulnerability handling, the same Annex I theme that shaped the product's design in the first place. The 2026-09-11 reporting regime From 2026-09-11, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform, on the same 24 hour early-warning and 72 hour notification rhythm this course has already taught for Network Information Security Directive 2 (NIS2). The grammar repeats; only the recipient and the trigger change. The 24 hour and 72 hour rhythm should feel immediately familiar from Module 07's NIS2 deadlines, and that similarity is deliberate rather than coincidental: the CRA's drafters reused a reporting cadence regulated entities and manufacturers alike were already being trained to expect, rather than inventing a fourth timeline for the same underlying discipline of surfacing a serious problem fast. No credential exists yet As of this course's own verification date, no examinable, market-recognized personal credential exists anywhere for the CRA specifically. Module 09's assessment is therefore CCICCS-defined, holding this ground honestly until a market credential exists, at which point the crosswalk overlay gains a row rather than the course needing a rewrite. Open the lab to assemble a product conformity file for Ondine Sensors' gateway, then take the self-test. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Certification bridge. Four examinable views over the course: PECB ISO/IEC 27001 Lead Implementer and Lead Auditor, PECB NIS 2 Directive Lead Implementer, and PECB DORA Lead Manager, with an original item bank built to the ADR-018 template.. Map a CODEX module to the PECB exam domain(s) it prepares a candidate for.. Distinguish the Lead Implementer and Lead Auditor exam foci for ISO/IEC 27001:2022.. Evaluate and answer an original, incident-stemmed practice item at the 70 percent pass standard PECB itself uses.. The four PECB exam landscapes, Lead Implementer versus Lead Auditor, Exam blueprint to CODEX module map, Original items, per ADR-018 Certification bridge This module maps four examinable views over everything CODEX has already taught: Professional Examination and Certification Board (PECB)'s ISO/International Electrotechnical Commission (IEC) 27001 Lead Implementer and Lead Auditor, Network Information Security Directive 2 (NIS2) Directive Lead Implementer, and Digital Operational Resilience Act (DORA) Lead Manager. None of it is new subject matter; all of it is a map of where what you already know is examined. None of the four credentials this module maps against requires a learner to memorise new subject matter distinct from what Modules 00 through 09 already covered. What changes from credential to credential is emphasis, format and the chair a candidate is asked to sit in: implementer, auditor, or sector-specific lead manager, each testing a different use of the same underlying knowledge. Four exam landscapes, one course The module-to-credential map in the table above is a starting point for revision planning, not a claim that a module is irrelevant to a credential it is not listed against. Module 02's risk process, for instance, underpins every one of the four exam landscapes even though it is not separately listed against each row, because every credential eventually tests whether a candidate can justify a decision by reference to an assessed risk. Lead Implementer versus Lead Auditor The same standard, read from two different chairs. A Lead Implementer builds the system and defends design choices; a Lead Auditor interrogates someone else's system for conformity and is trained to be sceptical of exactly the kind of unjustified inclusion or exclusion Module 03 warned against. As verified from PECB's own candidate handbook, the Lead Auditor exam is now 80 multiple-choice questions, open book, with a 70 percent pass mark; both exams share that same pass threshold. The practical consequence for a candidate is which habit of mind to train. Preparing for the Lead Implementer exam rewards practising the constructive question, 'given this context, what would I design,' repeatedly across the four teaching cases. Preparing for the Lead Auditor exam rewards the opposite habit: reading someone else's completed artifact and asking, 'what would I challenge here,' the same sceptical posture Module 03 first introduced when it warned against unjustified Statement of Applicability entries. Both exams nonetheless share more than the pass mark. Both expect a candidate to reason from clause text to a concrete organizational fact, not merely recall a clause number, and both treat an answer that ignores the stated facts of a scenario in favour of a generic textbook response as a wrong answer, regardless of how well-written that generic response might otherwise be. Original items, per Architecture Decision Record (ADR)-018 Every practice item in this module's bank follows the same template the ODYSSEY course already established: one exam content outline subtopic decomposed into one atomic learning outcome, placed in front of a real, cited, publicly reported incident or a clearly labelled simulated one, with one clear question. Nothing is copied or reconstructed from any real PECB exam; the standing legal-review precondition applies before this bank publishes. Building an original item bank rather than reusing or reconstructing real exam content is also what keeps this module durable against a PECB blueprint revision. Because each item is tied to an atomic learning outcome and a real or simulated incident rather than to the specific wording of a past exam question, the bank can be re-mapped to a revised blueprint without being rewritten from scratch, which matters given how often certification bodies update their content outlines. Open the lab to map each of your own completed modules to its exam domain, then take the scored practice set. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/ Capstone: the audit. Each of the four cases' artifact package faces its own simulated audit or regulator inquiry: Rhône Valley Water Authority and Occitanie Électricité Distribution a NIS2/LPM inquiry, Meridis Pay a DORA supervisory review, Ondine Sensors a CRA conformity check, per the four-case design ratified in ADR-026.. Build and assemble a complete artifact package (scope, risk register, SoA, policy pack, reporting pack) for one case.. Respond to a simulated auditor's finding without introducing a new nonconformity in the response itself.. Distinguish a major nonconformity from a minor one and from an observation, in the ISO/IEC 17021-1 sense.. Assembling the package, Responding to findings, Major versus minor nonconformity, One inquiry per case Capstone: the audit Everything CODEX has built now has to survive being questioned by someone who did not build it. This capstone runs one simulated audit or regulator inquiry per case, the accepted cost of the four-case design ratified in Architecture Decision Record (ADR)-026. One inquiry per case Rhône Valley Water Authority and Occitanie Électricité Distribution share a Network Information Security Directive 2 (NIS2)/Legislation, Policy, Measures (LPM) inquiry, since the LPM lesson lives inside the NIS2 module; Meridis Pay faces a Digital Operational Resilience Act (DORA)-style supervisory review; Ondine Sensors faces a Cyber Resilience Act (CRA) conformity check. Four packages, four inquiries, no single integrated audit, by design. Running four separate inquiries instead of one integrated audit also mirrors how these regulations actually operate outside the classroom: a NIS2 competent authority, a DORA supervisor and a CRA market surveillance authority are different bodies with different procedures, and an organization genuinely subject to more than one regime would face genuinely separate inquiries in practice, not a single combined one. Nonconformity, in the ISO/International Electrotechnical Commission (IEC) 17021-1 sense Classifying a finding correctly matters beyond vocabulary, because the classification determines what happens next. An observation can usually be addressed at the organization's own pace; a minor nonconformity typically requires a corrective action plan with a deadline; an open major nonconformity blocks certification or its renewal outright until it is closed, which is why Module 11's own grader treats the three categories as carrying materially different consequences rather than as three degrees of the same soft warning. A package with an open major nonconformity does not pass. There is no partial credit here either, matching Module 07's reporting-deadline rule: a system that is mostly compliant is not yet a system that produces evidence of security. Responding to a finding without making a new one A defensible response states the root cause, the correction, and the corrective action with a completion date. Arguing that the auditor misunderstood the business, without addressing the finding itself, is itself the kind of response an experienced auditor is trained to treat as a second, separate problem. A completion date matters as much as the correction itself, because a corrective action with no deadline is functionally indistinguishable from a corrective action that was never actually committed to. An auditor reviewing a response package checks the completion date against the entity's own change-management records precisely to test whether the date is a real commitment or a placeholder inserted to close the finding on paper. Open the lab to assemble your artifact package for one case and respond to its simulated finding, then submit the defended package. Related CCI capabilities CySSURANCE - Model it. Compute it. Govern it. https://www.cambridgecyberinternational.com/en/platform/. CySSURANCE Framework Modules - https://www.cambridgecyberinternational.com/en/platform/. PerfMeter - Numbers first; the platform can come later. https://www.cambridgecyberinternational.com/en/platform/