MODULE ONE DESCRIPTOR
Module 1: Foundations of Cyber Vulnerability Reporting and Disclosure
Foundations of Cyber Vulnerability Reporting and Disclosure
4 Hours Total Duration | Module 1 of 6 Position | Digital + Live Delivery | Foundation Portfolio Role |
Module Purpose
Module One establishes the baseline capability practitioners need to understand the cyber vulnerability reporting ecosystem, distinguish vulnerability disclosure from incident reporting, identify relevant stakeholders, and map the end-to-end vulnerability reporting lifecycle.
The module is designed for product security officers, PSIRT leads, compliance managers, vulnerability response teams, engineering leads, QA staff, importers and distributors involved in CRA vulnerability handling and reporting.
The emphasis is practical and work-based. Learners do not simply learn definitions — they begin mapping how vulnerability reports currently enter, move through and escalate within their own organisation or a supplied case-study organisation.
The module prepares learners to understand how vulnerability reporting connects to:
– Vulnerability disclosure – Vulnerability handling – Coordinated Vulnerability Disclosure (CVD) – Product security response | – Incident reporting – Regulatory reporting – Manufacturer obligations under CRA Article 13 and Annex I |
Module Position in the Full Programme
Module One provides the operating baseline for the five later modules. It introduces the language, roles and process concepts that learners will need throughout the programme.
M1 Foundations | M2 Disclosure Policy | M3 Intake & Triage | M4 Remediation | M5 CRA Reporting | M6 Simulation & Portfolio |
The principal Module One output is a stakeholder and process map, which becomes the foundation artefact for the learner’s course portfolio and is refined in every subsequent module.
Module | How Module One feeds in |
Module 2 | Disclosure policy design draws on the stakeholder and process maps from Module One. |
Module 3 | Triage workflow design is built on the intake and ownership mapping begun here. |
Module 4 | Remediation and coordination planning extends the stakeholder map and escalation routes. |
Module 5 | CRA reporting decision-making uses the regulatory touchpoints identified in Module One. |
Module 6 | Final portfolio defence incorporates and presents all Module One foundation artefacts. |
Reference Base
This module is grounded in the following standards, frameworks and regulatory instruments:
Reference | Scope |
ISO/IEC 29147 | Vulnerability disclosure requirements and vendor recommendations |
ISO/IEC 30111 | Vulnerability handling and remediation processes |
CERT/CC CVD Guidance | Coordinated vulnerability disclosure stakeholders, process phases and operational failure points |
FIRST PSIRT Services Framework | PSIRT responsibilities, policy, triage, remediation and communications |
OWASP Vulnerability Disclosure Cheat Sheet | Researcher and organisational expectations for vulnerability disclosure |
NCSC Vulnerability Disclosure Toolkit | Practical implementation of vulnerability disclosure processes |
ENISA CRA Single Reporting Platform | Future reporting route for actively exploited vulnerabilities and incidents |
Module Learning Outcomes
By the end of Module One, learners will be able to:
1 | Explain the vulnerability reporting and coordinated disclosure lifecycle. |
2 | Distinguish between a vulnerability, weakness, exploit, exposure, threat, risk, incident and impact. |
3 | Identify the key internal and external stakeholders involved in vulnerability reporting. |
4 | Differentiate private disclosure, coordinated vulnerability disclosure, public disclosure, bug bounty reporting and incident reporting. |
5 | Recognise common vulnerability reporting failure modes. |
6 | Apply ethical and legal principles including authorisation, proportionality, safe harbour, researcher conduct and evidence handling. |
7 | Produce a first-version stakeholder map, current-state reporting process map and vulnerability lifecycle diagram. |
Programme Learning Architecture
Module One follows the standard four-component digital learning model used across the programme. All four components are mandatory and contribute to the learner’s portfolio.
| Component | Mode | Duration |
Part 1 | Foundation Digital Lesson | Pre-Recorded Digital Lesson | 60 Minutes |
Part 2 | Deep Dive Session 1 | Pre-Recorded Trainer-Led Session | 60 Minutes |
Part 3 | Deep Dive Session 2 | Pre-Recorded Trainer-Led Session | 60 Minutes |
Part 4 | Scenario / Simulation Assessment | Applied Assessment | 60 Minutes |
Part 1 | Foundation Digital Lesson Pre-Recorded Digital Lesson | 60 Minutes
Understanding the Vulnerability Reporting Ecosystem
Learning Purpose
To give learners a structured baseline understanding of vulnerability reporting, disclosure terminology, actors, reporting pathways and CRA relevance before moving into practitioner decision-making.
Recommended Lesson Flow
Time | Segment | Content |
0–5 mins | Module orientation | Why vulnerability reporting matters under the CRA; how Module 1 connects to the full practitioner portfolio |
5–15 mins | Key terminology | Vulnerability, weakness, exploit, exposure, threat, risk, incident, impact, remediation, mitigation |
15–25 mins | Vulnerability reporting lifecycle | Discovery, reporting, acknowledgement, validation, triage, coordination, remediation, disclosure, closure |
25–35 mins | Disclosure models | Private disclosure, coordinated disclosure, public disclosure, full disclosure, bug bounty reporting |
35–45 mins | Stakeholder ecosystem | Researchers, vendors, manufacturers, PSIRT, CSIRT, CNA, regulators, customers, importers, distributors, users |
45–52 mins | CRA context | Why manufacturers need repeatable, auditable vulnerability reporting processes |
52–57 mins | Knowledge check | 8–10 interactive questions covering key terminology and lifecycle stages |
57–60 mins | Reflection prompt | “Where does vulnerability reporting currently sit in your organisation?” |
Digital Learning Assets | Foundation Knowledge Check — Example Questions |
– Animated vulnerability lifecycle diagram – Glossary flashcards – Stakeholder ecosystem map – Short knowledge checks – Downloadable Module 1 workbook – Reflection worksheet | – Is every vulnerability a reportable incident? – What is the difference between a weakness and a vulnerability? – Who may act as an external coordinator in multi-party disclosure? – What makes a vulnerability report actionable? – What is the role of a PSIRT compared with a CSIRT? |
Part 2 | Deep Dive Session 1 Pre-Recorded Trainer-Led Session | 60 Minutes
Core Topics: Disclosure Practice, Stakeholders and Operational Risk
Learning Purpose
To move learners from baseline knowledge into practical interpretation of vulnerability reporting and disclosure in organisational environments.
Recommended Session Flow
Time | Segment | Content |
0–10 mins | Recap and positioning | How vulnerability reporting supports CRA readiness and post-market product security |
10–20 mins | Disclosure lifecycle in practice | How reports move from researcher to vendor to remediation and public advisory |
20–30 mins | Stakeholder roles | PSIRT, engineering, legal, compliance, communications, suppliers, customers, regulators |
30–40 mins | Vulnerability vs incident reporting | How to separate vulnerability handling from cyber incident response while recognising escalation points |
40–50 mins | Failure modes | No intake route, unclear ownership, delayed acknowledgement, legal overreaction, premature disclosure, poor evidence capture |
50–60 mins | Worked example | Trainer walkthrough of a flawed vulnerability report and the first 48 hours of organisational response |
Core Topics Covered
– Vulnerability reporting lifecycle – Stakeholders in the disclosure ecosystem – Private, coordinated and public disclosure models | – Bug bounty models and vulnerability disclosure programmes – Ethical and legal foundations – Common operational failure modes |
Trainer Demonstration
The trainer walks through a fictional report: “A researcher emails support@company.com claiming they can bypass authentication on a connected product API.” |
Learners observe how to identify: – Whether this is a vulnerability report – Who should receive it internally – What evidence is missing – Whether it is urgent – Whether it may later become a CRA reportability issue – What must be logged immediately |
Part 3 | Deep Dive Session 2 Pre-Recorded Trainer-Led Session | 60 Minutes
Practitioner Outputs: Mapping the Vulnerability Reporting Operating Model
Learning Purpose
To show learners how to produce the practical artefacts required for Module One and how these artefacts connect to later modules.
Recommended Session Flow
Time | Segment | Content |
0–10 mins | Output overview | What learners must produce and why it matters for the full practitioner portfolio |
10–22 mins | Stakeholder map | Internal and external stakeholder categories, accountabilities and escalation points |
22–35 mins | Current-state process map | Intake routes, ownership, handoffs, decision points, evidence capture and escalation |
35–45 mins | Vulnerability lifecycle diagram | End-to-end flow from discovery to closure |
45–52 mins | Glossary and terminology check | Standardising terms across legal, security, engineering and compliance teams |
52–60 mins | Maturity reflection | Identifying gaps and risks in current arrangements |
Practitioner Outputs — Learners begin creating: | Output Quality Criteria — Each output should be: |
– Stakeholder map – Current-state vulnerability reporting process map – Vulnerability lifecycle diagram – Glossary and terminology check – Initial maturity reflection | – Operationally realistic – Evidence-based – Clear enough for cross-functional use – Aligned to recognised disclosure practice – Suitable for later integration into the full CRA practitioner portfolio |
Part 4 | Scenario / Simulation Assessment Applied Assessment | 60 Minutes
Assessment: The Misrouted Vulnerability Report
Scenario Summary
A security researcher submits a vulnerability report through a general customer support channel. The report alleges that an unauthenticated user can access diagnostic data from a connected product. The support team treats it as a customer complaint. Engineering is unsure whether the issue is a bug, vulnerability or incident. Legal is concerned about unauthorised testing. Communications wants to avoid acknowledging the researcher until the facts are clear. Learners must review the scenario and produce a structured practitioner response. |
Assessment Timing
Time | Activity |
0–10 mins | Read scenario pack and evidence |
10–20 mins | Classify the report and identify key terminology issues |
20–35 mins | Build stakeholder map |
35–50 mins | Draft vulnerability lifecycle and escalation pathway |
50–60 mins | Complete maturity reflection and submit |
Required Assessment Outputs | Assessment Standard — Learners pass where they can: |
– Stakeholder map identifying internal and external parties – Initial vulnerability lifecycle diagram showing the correct reporting and handling pathway – Current-state process gap notes identifying where the organisation failed – Terminology classification distinguishing vulnerability, weakness, exploit, incident and risk – Initial maturity reflection identifying 3–5 improvement priorities | – Correctly classify the report as a vulnerability disclosure issue – Identify appropriate stakeholders and escalation points – Avoid confusing vulnerability reporting with incident response – Recognise missing evidence – Apply ethical and legally aware handling principles – Produce clear, usable practitioner artefacts |
Assessment Philosophy This aligns with the programme’s wider assessment approach: learners are assessed on defensible, usable, evidence-based artefacts rather than memory recall. |
Core Content Coverage
Module One covers the following content areas in sufficient depth to support the five later modules.
Vulnerability Reporting Ecosystem | Key Concepts | Disclosure Models & Failure Modes |
– Finder / Reporter – Vendor / Manufacturer – Asset owner / Product owner – CNA – Coordinator – CSIRT / PSIRT – Regulator – Customer / End user – Supplier – Open-source maintainer – Importer and distributor | – Vulnerability – Weakness – Exploit – Exposure – Threat / Risk – Incident / Impact – Severity / Exploitability – Disclosure / Coordination – Remediation / Mitigation – Advisory / Proof-of-concept – Safe harbour – Data minimisation – Authorisation / Proportionality | – Private disclosure – Coordinated Vulnerability Disclosure – Full public disclosure – Vulnerability Disclosure Programme – Bug bounty programme – Multi-party coordination – Open-source and supply-chain disclosure Failure Modes – No reporting channel – Unclear ownership – No acknowledgement process – Legal overreaction – No triage process – Delayed remediation – Inconsistent severity decisions – No link to regulatory reporting |
Practitioner Artefacts Produced in Module One
At the end of Module One, each learner should have produced five foundation artefacts. These become the starting point for the full course portfolio and are refined progressively in later modules.
# | Artefact | Used in Later Modules |
1 | Stakeholder map | M2, M3, M4, M5, M6 |
2 | Current-state vulnerability reporting process map | M2, M3, M4 |
3 | Vulnerability lifecycle diagram | M3, M6 |
4 | Glossary and terminology check | M2, M3, M5 |
5 | Initial maturity reflection | M6 |
Module One Assessment Standard
Assessment is portfolio-based. The following standards describe the expected level of learner performance.
Level | Descriptor |
Competent | – Can explain who is involved in vulnerability reporting – Understands how vulnerability reports should enter an organisation – Can distinguish reporting, handling, disclosure and incident response – Identifies where early-stage communication and escalation risks arise – Understands why a structured reporting process matters for CRA readiness |
Strong | – All Competent descriptors, plus: – Identifies practical process weaknesses and unclear hand-offs – Recognises missing evidence requirements and documentation gaps – Flags early regulatory risk indicators relevant to the CRA – Produces a stakeholder and process map that is operationally credible and audit-ready |
Link to Overall Programme Assessment
Module One contributes directly to the final portfolio assessment in Module Six. The foundation artefacts produced here are not standalone deliverables — they are the opening layer of a progressively built practitioner toolkit.
Module One Artefact | Role in Programme Portfolio |
Stakeholder and process map | Supports disclosure policy design (M2), triage workflow design (M3) and multi-party coordination planning (M4). |
Vulnerability lifecycle diagram | Contextualises triage decisions (M3) and informs the final portfolio defence (M6). |
Glossary and terminology check | Provides shared language for legal, security, engineering and compliance teams across all subsequent modules. |
Initial maturity reflection | Provides the baseline for the 90-day improvement plan completed in Module Six. |
€325.00