You have chosen your case and written the scope statement. This lesson is the project's working manual: the eight deliverables of the dossier, one by one, with their purpose, their minimum requirements, their quality requirements — the ones that separate a passing dossier from a good one — their format, the lesson that resolves them, a template ready to copy and fill in and a fragment already filled in on one of the fictitious cases so that you can see the expected standard without ambiguity. Work with it open in a tab and do not read it end to end in one sitting: read the deliverable you are on, copy its template, fill it in and come back when you have finished. At the end you will find the cross-cutting requirements — the ones assessed over the complete dossier — the suggested file structure and a checklist you must pass before considering yourself finished.
Contents
- How to read this lesson and the project identifiers
- E1 — Context, asset inventory and classification
- E2 — Risk register
- E3 — Minimum documentation set
- E4 — Control catalogue
- E5 — Response and recovery plan
- E6 — Technical verification plan
- E7 — Regulatory framework, compliance and data protection
- E8 — Awareness programme and roadmap
- Cross-cutting quality requirements
- Delivery format and file structure
- Pre-closure checklist
- How to read this lesson and the project identifiers
Each deliverable is presented with a four-field card: purpose (the question it answers), minimums (what has to be there no matter what), quality (what distinguishes competent from basic) and format and reference (indicative length and the lesson that resolves it). Use this identifier convention throughout the dossier as well: it is the course's own, and it is what will make the E7 traceability matrix possible with no extra work.
A-nn Asset R-nn Risk C-nn Control POL-nn Policy
D-nn Detection RB-nn Runbook T-nn Processing activity (RoPA) EV-nn Evidence
PR-xxx Procedure (PR-EXC-01 exceptions, PR-BRE-01 breaches, PR-DER-01 data subject rights)Number them stably: if you withdraw risk R-05, do not renumber the ones that follow; mark it as withdrawn. That stability is what allows a document written six months ago to still be readable.
- E1 — Context, asset inventory and classification
| Field | Content |
|---|---|
| Purpose | "What do we have and what is it worth?". Without this, everything else is opinion |
| Minimums | Organisation profile; inventory of ≥ 15 assets with identifier, owner, criticality and classification; DFD with trust boundaries; STRIDE of one flow with at least one threat per applicable letter |
| Quality | Intangible assets (reputation, data, contracts) and not just servers; owner with a first name and a surname; criticality justified by business impact; boundaries where the level of trust changes, not where the colour of the drawing changes |
| Format · Ref. | Short prose + tables + diagram, 3-5 pages · 01-01, 01-04 |
## 1.1 Profile Name and sector · Size and sites · Business model in two sentences · Data
it processes and why it matters · Resources: … €/year, … h/year internal, … from third
parties · Non-negotiable constraints · Scope: in … / out …
## 1.2 Inventory
| ID | Asset | Type | Owner | Criticality | Classification | Notes |
| A-01 | | Data/System/Service/Identity/Person/Intangible | | Critical…Low | Public/Internal/Confidential/Restricted | |
## 1.3 DFD (mermaid) with trust boundaries FC-1, FC-2…
## 1.4 STRIDE of the flow "…"
| STRIDE | Specific threat to this flow | Asset | Resulting risk |
| S / T / R / I / D / E | | | R-.. |Worked example — inventory for Clínica Sonrisa Norte (extract):
| ID | Asset | Type | Owner | Crit. | Classification |
|------|--------------------------------------|------------|----------|----------|----------------|
| A-01 | DentaGest clinical database (SQL) | Data | Elena V. | Critical | Restricted |
| A-03 | Windows server in Gijon | System | Nuria P. | Critical | Internal |
| A-04 | Backup NAS (same room as A-03) | System | Nuria P. | Critical | Restricted |
| A-11 | Vendor's shared admin account | Identity | Nuria P. | Critical | Restricted |
| A-14 | Reception phones with WhatsApp | System | Nuria P. | High | Restricted |
| A-18 | Local reputation and word of mouth | Intangible | Elena V. | Critical | Public |Three details make it competent rather than basic. A-11 is an asset: a shared account is not a vulnerability, it is an asset with an owner, and treating it that way lets it appear in the inventory and not only in the complaints. A-18 exists: reputation is the asset a local practice's revenue depends on, and leaving it out makes it impossible to score any reputational risk. And A-04 carries the note about the room, the piece of information that will turn a medium risk into a critical one two deliverables later.
- E2 — Risk register
| Field | Content |
|---|---|
| Purpose | "What can go wrong, how much does it hurt and in what order do we attack it?" |
| Minimums | ≥ 10 risks using the course formula; scales and 5x5 matrix declared; inherent and residual; strategy and owner per risk; ≥ 2 risks with ALE and ≥ 1 control with ROSI |
| Quality | That they cover more than one dimension — third parties, people, availability, compliance, fraud — and not ten variants of ransomware; impact in business language; residual scored against the real state of the control; and at least one formally accepted risk, because accepting is legitimate and accepting nothing means nothing has been decided |
| Format · Ref. | Master table + cards for the top 3-5 + calculations, 4-6 pages · 04-01 |
- id: R-01
description: >
If [THREAT] exploits [VULNERABILITY] on [ASSET],
then [TECHNICAL IMPACT] with [BUSINESS CONSEQUENCE].
assets: [A-01, A-04]
category: "Ransomware | Third party | Leak | Availability | Fraud | Compliance"
inherent: {l: 4, i: 5, band: "Critical"} # 1-5; l as an annual frequency
quantification: {sle_eur: 0, aro: 0.0, ale_eur: 0, assumptions: "Where each figure comes from"}
strategy: "Mitigate | Transfer | Avoid | Accept"
controls: [C-01, C-04]
residual: {l: 2, i: 5, band: "High",
justification: "Scored against controls VERIFIED as of today"}
owner: "First name and surname"
next_review: 2027-03-01Worked example — R-01 at the dental practice, with its ALE and the control's ROSI:
R-01 If an attacker who has compromised the DentaGest vendor uses the shared
administrator account with no MFA (A-11) to reach the Gijon server (A-03), then they
encrypt the clinical database (A-01), the DICOM images (A-02) and the NAS mounted on the
same network (A-04), halting clinical activity at all three sites, losing access to the
clinical records of 4,800 patients, producing a breach notifiable to the AEPD within 72 h
and breaching the retention duty of Law 41/2002.
Inherent: L=4 (known, frequent vector in the sector) x I=5 => CRITICAL
ALE: SLE = 67,200 (8 days x 8,400 EUR/day of lost revenue) + 12,000 (recovery and
forensics) + 6,000 (notification, legal advice, communication) + 42,000 (patient
attrition, 2 % of the list) = 127,200 EUR
ARO = 0.15 (once every ~7 years: healthcare SME, third-party vector)
ALE = 127,200 x 0.15 = 19,080 EUR/year
ROSI of C-04 (immutable off-site backups with quarterly testing): cuts the ALE by 65 %
-it does not prevent encryption; it prevents irreversible disaster and shortens the
outage from 8 days to 2- => 12,402 EUR/year avoided against an annual cost of
780 EUR + 16 h of Nuria + 6 h of Datacer ~ 1,110 EUR.
ROSI = (12,402-1,110)/1,110 = 1,017 %
Residual after C-01, C-04 and C-11: L=2 x I=5 => HIGH. It does not drop further because
the clinical and regulatory impact does not depend on likelihood, and because C-01 remains
in "planned" status until the vendor accepts the contractual change.
Strategy: Mitigate. Owner: Elena Vazquez. Review: quarterly.What makes this card excellent is not the number: it is that every figure carries its assumption, that the ROSI compares against a cost that includes hours and not only euros, and that the residual explains why it does not drop further. An ALE with no assumptions is an invented number formatted as a calculated one.
- E3 — Minimum documentation set
| Field | Content |
|---|---|
| Purpose | "What rules do we set ourselves and who approves them?" |
| Minimums | Policy map with owner, priority and the risks it covers; two policies written in full; exceptions procedure with expiry |
| Quality | That the two chosen are the ones attacking the top 3 risks, not the ones easiest to write; language their real audience can read; consistent use of MUST / MUST NOT / SHOULD; and that the organisation can comply with them — a policy banning what everybody does daily is a self-inflicted nonconformity |
| Format · Ref. | Table + two complete documents, 5-8 pages · 04-02 |
# POL-nn — <name> Policy
**Version · Approved by · Date · Annual review · Owner · Audience**
1. Object — 2. Scope (what it covers and what is expressly excluded) — 3. Definitions —
4. Responsibilities (who does what, by role) — 5. Statements: numbered, one obligation per
line, with MUST / MUST NOT / SHOULD — 6. Exceptions (refers to PR-EXC-01) —
7. Non-compliance — 8. Related documents# PR-EXC-01 — Exception
id: EXC-2027-001
policy_or_control: "POL-02 §5.4 / C-01"
requester: "Name and genuine operational reason"
related_risk: R-01
residual_risk_with_exception: "High"
compensation: "What is done in the meantime" # MANDATORY
approved_by: "Whoever can accept that level of risk"
approval_date: 2027-01-15
expires: 2027-07-15 # MANDATORY, max. 6 months, renewable once
status: "Active | Renewed | Closed | Expired"Worked example — the dental practice's policy map:
| ID | Policy | Risks | Prior. | Owner |
|--------|-------------------------------------------|-------------------|--------|----------|
| POL-02 | Access Control and Clinical Identity | R-01, R-04, R-06 | 1 | Elena V. |
| POL-03 | Patient Communication and Channels | R-02, R-09 | 1 | Nuria P. |
| POL-04 | Backups and Continuity | R-01, R-05 | 1 | Nuria P. |
| POL-05 | Managing Suppliers with Access to Data | R-01, R-07 | 1 | Elena V. |
| POL-08 | Incident and Breach Response | All | 2 | Elena V. |
Written in full: POL-02 and POL-03. POL-02 attacks the number one risk -shared identity,
both the vendor's and the treatment rooms'- and is a precondition of the access
traceability Law 41/2002 requires; POL-03 is the only realistic way to resolve the use of
WhatsApp with health data, the risk with the greatest exposure to penalties and the one no
technical measure resolves on its own.That closing paragraph explains why those two and not others, in terms of risk and legal obligation. Five lines that mark the difference between choosing and being landed with it.
- E4 — Control catalogue
| Field | Content |
|---|---|
| Purpose | "What do we do, what does it cost and does it fit?" |
| Minimums | ≥ 15 controls with nature (T/A/P), function (preventive, deterrent, detective, corrective, recovery, compensating), risks, annual cost, hours/year, status and mapping to CIS v8 IG1; the reconciliation with budget and hours; and the list of discards with their justification |
| Quality | That it genuinely fits: costs ≤ budget and hours ≤ hours available, with a reserve; that there are detective and recovery controls and not only preventive ones; that every top-5 risk has a control of each relevant function; honest status (planned until verified); discards with an argument, not through oversight |
| Format · Ref. | Master table + reconciliation + discards, 3-5 pages · 04-03; the content of each control is in 02-04, 03-07 and module 5 |
## 4.1 Catalogue | ID | Control | Nat. | Function | Risks | €/year | h/year | CIS IG1 | Owner | Status |
## 4.2 Reconciliation sum of controls / 10-20 % reserve / TOTAL / AVAILABLE / MARGIN, in € and in hours
## 4.3 Discards | Candidate | Cost | Risk it would have treated | Why it is discarded | When it is reviewed |Worked example — catalogue, reconciliation and discards for the dental practice:
| ID | Control | Nat.| Function | Risks | EUR | h | CIS | Status |
|------|------------------------------------------------------------|-----|---------------|------------|-----|----|------|---------|
| C-01 | Named account + MFA for the vendor's support, enabled | T+A | Prev.+Detect. | R-01, R-07 | 0 | 12 | 5.x | Planned |
| | on demand and revoked after 8 h | | | | | | 6.x | |
| C-04 | Immutable off-site backup + timed restore test | T+A | Recov.+Detect.| R-01, R-05 | 780 | 22 | 11.x | Planned |
| C-05 | Individual identity in treatment rooms with proximity card | T | Prev.+Detect. | R-04 |1,450| 30 | 5.x | Planned |
| C-08 | Secure photo channel inside DentaGest and withdrawal of | T+A | Prev. | R-02 | 960 | 18 | 3.x | Planned |
| | WhatsApp | | | | | | | |
| C-11 | Alert on administrative access outside the agreed window | T | Detect. | R-01, R-07 | 0 | 14 | 8.x | Planned |
RECONCILIATION 16 controls 7,190 EUR / 168 h Nuria + 96 h Datacer · 20 % reserve
1,438 EUR + 12 h
TOTAL 8,628 EUR / 180 h Nuria / 96 h Datacer · AVAILABLE 9,000 / 180 / 120
MARGIN 372 EUR / 0 h of Nuria / 24 h of Datacer
DISCARDS
Managed EDR, 3,600 EUR (R-01): consumes 40 % of the budget and does not attack the main
vector, which is the use of a LEGITIMATE ACCOUNT by a compromised third party -an EDR
sees anomalous processes, not an authorised administrative session-. C-01, C-04 and C-11
cover that vector for 780 EUR. Review 2028 Q1.
Replacing DentaGest, 22,000 EUR: outside the budget by a factor of 2.4; it is not a
security decision but an investment one. Moves to the multi-year plan. Review 2029.
External pentest, 4,500 EUR: it is not expensive, it is premature. With 7 of 16 controls
unimplemented it would confirm holes already documented here. Review 2028 Q3.That last discard is the most instructive: the pentest is not discarded for being expensive, but for being premature. Paying 4,500 € for someone to confirm the holes you have already documented is spending on information you already own; that reasoning — sequence, not just cost — is the professional judgement the project is looking for. And look at the margin: 0 hours of Nuria's time. The catalogue fits in the money but is at the limit on the scarce resource, and that has to be said, because it is where the plan will break if anything goes wrong.
- E5 — Response and recovery plan
| Field | Content |
|---|---|
| Purpose | "What do we do when it happens, who is in charge and how soon are we back?" |
| Minimums | Team with names, roles and out-of-band contacts; S1-S4 severity matrix with criteria and times; one complete runbook for the most likely scenario; communication matrix with the 72-hour clock; summarised BIA with RTO/RPO per system and backup strategy with its test |
| Quality | A runbook executable by someone who did not write it: commands, locations, phone numbers, zero tacit knowledge; RTOs justified by impact rather than chosen because they sound right; backups that meet 3-2-1-1-0 or explain why not; date of the last restore test even if it is "never"; communication that says who notifies whom and within what legal deadline |
| Format · Ref. | Tables + step-by-step runbook, 5-7 pages · 04-05, 04-06 |
# RB-nn — <Scenario>
**Triggered when:** specific, observable triggers · **Default severity:** S?
**Owner / deputy:** … · **Out-of-band channel:** … (never corporate e-mail)
0. Before touching anything: start time, action log (who/what/when), preserve
evidence — do NOT power off, do NOT reinstall, capture before containing
1. Detection and triage (target … min) — 2. Containment (target … min), with exact commands
3. Eradication — 4. Recovery, with explicit criteria for returning to production —
5. Communication: to whom, by whom, within what deadline — 6. Closure and post-mortem (72-96 h)
Contacts: | Role | Name | Phone | Alternative |. Whoever executes CANNOT decide:
paying a ransom · communicating publicly · notifying the authority · reporting to the policeWorked example — BIA, RTO/RPO and backups for the dental practice:
| System / process | Impact of the outage | RTO | RPO | Justification |
|--------------------------|-------------------------------------|------|------|--------------------------------------|
| Clinical records (A-01) | Patients cannot be treated safely: | 4 h | 24 h | More than 4 h cancels the working |
| | clinical risk | | | day at all 3 sites (~40 appointments)|
| DICOM images (A-02) | The X-ray is retaken: cost and an | 48 h | 24 h | Avoidable dose, but does not stop |
| | unnecessary dose for the patient | | | treatment |
| E-mail (A-06) | Communication with patients and the | 24 h | 24 h | The telephone exists as an |
| | outside world | | | alternative |
3-2-1-1-0: 3 copies OK (production + NAS + new external one with C-04) · 2 media OK ·
1 off-site NO and 1 immutable NO -> C-04 resolves both with a 30-day locked retention ·
0 errors NO: it has never been restored; first timed test 2027-02.
Last successful restore: NEVER. This fact, exactly as written, goes into the executive
summary: it is the sentence that gets the 780 EUR of C-04 approved.
- E6 — Technical verification plan
| Field | Content |
|---|---|
| Purpose | "How do we know this works and that it has not broken?" |
| Minimums | Scanning calendar with what, tool, frequency and owner; catalogue of 8-10 detections with source, logic and action; penetration test or technical review plan with its rules of engagement |
| Quality | That it is operable with the case's hours — a detection nobody is going to review is not a detection; specific logic rather than a title; at least one detection for the vector of the number one risk; a pentest with scope, exclusions, window and contact; and how each detection is tested, because an untested alert does not exist |
| Format · Ref. | Tables, 3-4 pages · 05-01, 05-02, 05-03 |
## 6.1 Calendar | What is verified | Tool | Frequency | Owner | h/year | Output |
## 6.2 Detections | ID | Detection | Source | Specific logic | Sev. | Action | How it is tested |
## 6.3 Pentest or review — Type and timing · Scope · EXCLUDED · Window · Emergency
contact · Stop criterion · Deliverable: report + retest of the critical findingsWorked example — the dental practice's detection catalogue (extract):
| ID | Detection | Source | Logic | Sev | How it is tested |
|------|------------------------------------|-------------------|------------------------------------|-----|-----------------------------------|
| D-01 | Vendor access outside the | Server RDP | Support account session outside | S2 | Open a test session on a Saturday |
| | authorised window | sessions | Mon-Fri 9-18 or with no ticket | | and time the alert |
| D-02 | Mass encryption or deletion in A-02| Windows file | >200 files modified or deleted in | S1 | Rename 250 files in a decoy |
| | | auditing | <5 min by one user | | folder |
| D-04 | Silent failure of the nightly | Backup job log | No "backup OK" in 26 h, or backup | S2 | Deliberately stop the backup |
| | backup | + NAS | size <80 % of the 7-day average | | service for one night |
| D-08 | Mass export from DentaGest | Database auditing | SELECT over >500 records by one | S1 | Run a 600-row query with a test |
| | | | user in a single session | | account |The "how it is tested" column is what separates this catalogue from a wish list. And D-04 deserves a comment of its own: the most profitable detection watches no attacker at all, it watches that the backup ran. A silent backup failure is what turns a recoverable incident into an irreversible one, and detecting it costs zero euros.
- E7 — Regulatory framework, compliance and data protection
| Field | Content |
|---|---|
| Purpose | "What does the law require of us and how do we prove we comply?" |
| Minimums | Applicable rules with the reason for each one; RoPA with ≥ 3 processing activities; reasoned decision on the DPIA; traceability matrix with ≥ 10 rows (risk → policy → control → evidence); breach notification procedure |
| Quality | Distinguishing law, standard, framework and contract (06-02); each processing activity with a lawful basis and, where article 9 data is involved, its 9.2 exception; a DPIA decided with judgement and justifying the "no" as well; specific, dated evidence rather than "it is reviewed periodically"; and a breach procedure that says who starts the 72-hour clock and from when |
| Format · Ref. | Tables + procedure, 4-6 pages · 06-02, 06-03, 06-04 |
# RoPA entry (art. 30 GDPR) · 7.4 Matrix: | Risk | Policy | Control(s) | Evidence | Date | Status |
- id: T-01
activity: "Patient clinical records"
role: "Controller" # or Processor, and on whose behalf
purpose: "Provision of dental care and its follow-up"
data_subjects: ["Patients", "Legal representatives of minors"]
data: ["Identification", "Health (art. 9)", "Radiological images"]
lawful_basis: "art. 6.1.b and 6.1.c"
art_9_exception: "art. 9.2.h — preventive medicine and healthcare"
recipients: ["Dental laboratory (processor)", "Finance provider (with consent)"]
international_transfers: "No | Yes: mechanism …"
retention: "At least 5 years from the end of the episode of care (Law 41/2002)"
security: [C-01, C-04, C-05, C-11]
related_risks: [R-01, R-04]Worked example — the DPIA decision and an extract of the matrix:
DPIA (art. 35). Is one required? YES, for T-01 (clinical records) and T-03 (DICOM images).
Reasoning: two criteria from art. 35.3 and the EDPB guidelines are met: (a) large-scale
processing of article 9 data -4,800 active patients, three sites, continuous activity- and
(b) data on vulnerable people, since minors are treated with their representatives'
consent. One criterion already recommends it; two make it required in practice. Besides,
the DPIA is the document that will justify to the AEPD why residual risks R-01 and R-04
were accepted with the real budget.
And for T-05, the appointment reminders? NO: ancillary processing, no automated
decision-making, no systematic evaluation and no article 9 data beyond the existence of an
appointment. The NEGATIVE decision is documented, because not carrying out a DPIA is also
a decision you have to be able to justify.
Validation note: the "large scale" qualification and the specific requirement depend on
the supervisory authority's criteria. Check the AEPD's published lists and consult a DPO
or legal adviser before closing it in a real case.
| Risk | Policy | Controls | Specific evidence | Date | Status |
|--------|-------------|-----------------|-------------------------------------------|------------|---------------|
| R-01 | POL-05 §5.2 | C-01, C-11, C-04| Contract with an on-demand access clause; | 2027-02-10 | C-01 awaiting |
| | | | Q1 session log | | signature |
| R-02 | POL-03 §5.1 | C-08, C-14 | Screenshots of the secure channel in | 2027-04-30 | Being implem. |
| | | | production; signed reception training log | | |
| R-05 | POL-04 §5.4 | C-04 | Timed restore test report | 2027-02-28 | NEVER DONE |
- E8 — Awareness programme and roadmap
| Field | Content |
|---|---|
| Purpose | "How do we sustain it and how do we know we are on track?" |
| Minimums | Training learning paths by role; annual security calendar; dashboard with 8 indicators with formula, target and associated control; quarterly roadmap with owner, cost and measurable outcome, reconciling with E4 |
| Quality | Genuinely different paths per role and not the same course repeated; phishing metric = report rate, not just the click rate (06-05); indicators measurable with what the organisation has, mixing KPIs and KRIs; a roadmap that puts first what treats the worst-scored risks and not what is easiest |
| Format · Ref. | Tables + gantt, 3-4 pages · 06-05, 06-01 |
## 8.1 Learning paths | Role | What they need to know | Format | Length | Frequency | How it is measured |
## 8.2 Dashboard | # | Indicator | Type | Formula | Target | Control | Frequency |
## 8.3 Roadmap | Qtr | Initiative | Risk it treats | Owner | € | Hours | Measurable outcome |Worked example — the dental practice's dashboard:
| # | Indicator | Type | Target | Control | Freq. |
|---|----------------------------------------------------|------|-------------|---------|-----------|
| 1 | % of vendor accesses using a named account | KPI | 100 % | C-01 | Monthly |
| 2 | Days since the last tested restore | KRI | <= 90 | C-04 | Monthly |
| 3 | % of M365 mailboxes with MFA | KPI | 100 % | C-02 | Monthly |
| 4 | % of treatment room stations with individual login | KPI | >= 95 % | C-05 | Quarterly |
| 5 | REPORT rate in the phishing simulation | KPI | >= 40 % | C-14 | Half-year |
| 6 | Patient photographs received over WhatsApp | KRI | 0 by month 9| C-08 | Monthly |
| 7 | Mean days to patch criticals / 8 Alerts tested in 12 months | KRI/KPI | <=14 d / 100 % | C-09, E6 | Monthly |Indicator 6 is the most interesting: it measures an entrenched human practice, it is measured by counting rather than with tools, and its target is a curve — from around 120 a month to zero in nine months — not a switch. Banning WhatsApp on day 1 with a target of zero produces an indicator nobody reports honestly.
- Cross-cutting quality requirements
These are assessed over the complete dossier and they carry the most weight in 07-03:
| # | Requirement | What to check |
|---|---|---|
| 1 | Identifier consistency | Every A-nn, R-nn, C-nn cited exists; the risks point to E1 assets; the E4 controls are in the E7 matrix; the E8 roadmap contains only E4 controls |
| 2 | Financial realism | The sum reconciles with the budget and with the hours. What does not fit is in the discard list with its justification |
| 3 | Justification of every decision | No line exists "just because": every control points to a risk, every risk to an asset, every deadline to an impact |
| 4 | Fictitious or anonymised data | No real personal data, real domain, real IP or credential, not even as an example |
| 5 | Traceability as the guiding criterion | The dossier can be walked in both directions: from a euro spent to the risk it treats, and from a risk to the evidence that proves it |
The thirty-second consistency test. Pick a control at random from E4 and walk it: which risk does it treat? does that risk exist in E2? on which asset? is it in E1? which policy backs it? which evidence proves it in E7? does it appear in the roadmap with an owner and a quarter? If the chain breaks, there is your next half hour of work. If it holds for three random controls, your dossier is consistent.
- Delivery format and file structure
There is no formal delivery to anyone, but the project has to exist as an artefact: if it lives in a single 60-page document, you are not going to maintain it and you will not be able to show it in parts.
security-dossier-<organisation>/
├── README.md Index, version, date, scope in 10 lines
├── 00-executive-summary.md 1 page. Written LAST
├── E1-context-assets.md · E2-risk-register.md · E4-control-catalogue.md
├── E3-policies/ map + POL-02 + POL-03 + PR-EXC-01
├── E5-response-recovery/ plan + RB-01-<scenario>.md
├── E6-technical-verification.md · E8-awareness-roadmap.md
├── E7-regulation-compliance/ framework + ropa.yaml + dpia-decision.md +
│ traceability-matrix.md + PR-BRE-01
└── annexes/ assumptions.md · open-decisions.md · sources.mdVersion it with git, even if you work alone. The history tells you when you changed your mind and why if you write good commit messages; you can tag v1.0 when you finish and keep iterating without fear; and if one day you show the project, a repository with twenty commits spread over eight weeks demonstrates a working process, which is exactly what an interviewer wants to see. Add a .gitignore and never put real data into the history: what goes into git does not come out easily. Markdown for the text, markdown tables rather than pictures of tables, mermaid for the diagrams and YAML for the data structures; if you need a PDF, generate it from the markdown and not the other way round.
- Pre-closure checklist
Run through it before considering yourself finished and before opening 07-03. Whatever you cannot tick, either fix it or note it in open-decisions.md; what is not acceptable is leaving it in silence.
### Completeness
- [ ] All 8 deliverables exist, none is half-done and they all meet the **minimums** on
their card (sections 2 to 9); 1-page executive summary written at the end
### Consistency and realism
- [ ] Every identifier cited exists in the deliverable it comes from
- [ ] Every top-5 risk has a preventive AND a detective control; every E4 control is
in the E8 roadmap, or it is said why not
- [ ] Total cost ≤ budget and total hours ≤ hours available, with a reserve
- [ ] Explicit list of discards with reason and date; ≥ 1 formally accepted risk
### Honesty and protecting the dossier itself
- [ ] No control shown as "implemented" without evidence to back it; the ALE figures
carry their assumptions; what is not known is in `assumptions.md`
- [ ] Zero real personal data, real domains, real IPs or credentials; if the case is
real, written authorisation filed and everything anonymisedCommon Mistakes and Tips
- Filling in the templates like forms. The template is scaffolding, not the building. An E2 with all ten cards filled in but with no paragraph explaining why R-01 comes first is a completed form, not an analysis: the prose that justifies is worth more than the table that lists.
- A catalogue that does not fit. It is the most frequent failure and the easiest to spot: the costs are added up and they exceed the budget or — more usually — the hours are added up and 400 h appear for a person who has 180. Always add up both columns.
- Optimistic statuses and policies copied off the internet. "Implemented" for everything that only exists in the plan: remember 04-03, a control that has never been tested is in planned status whatever its owners say. And copied policies are spotted instantly — they talk about "the Information Security Committee" in an eight-person company, or demand separation of duties where there is only one technical person; a policy the organisation cannot comply with generates a nonconformity at the first audit.
- Tip: write the traceability matrix row first. When you are unsure whether a control deserves to be included, try writing its E7 row — risk, policy, control, specific evidence, date. If you cannot name the evidence, the control is not yet well defined.
- Tip: keep
assumptions.mdopen and leave the executive summary until last. One line in the annex every time you decide something the brief does not state: that is how you tell what you know from what you have assumed. And write the executive summary on the last day, in one sitting: if it flows, the dossier is well built; if it is a struggle, the conclusions were not clear in the documents, and that is valuable information about your own work.
Exercises
The exercises are real steps of the project. Do them on your case; the solutions are worked out on the dental practice to fix the expected standard.
Exercise 1 — Turn one asset into two risks and a control that fits. Take a single asset from E1 — the one that worries you most — and produce the complete chain in miniature: two risks phrased with the formula and scored on the 5x5 matrix; one control that treats at least one of them, with its cost and its hours; and the traceability matrix row with specific, dated evidence. Check that the control fits in the remaining budget.
Exercise 2 — The impossible reconciliation. List ten candidate controls with their cost and their hours, unfiltered. Add them up. Almost certainly they will not fit. Now decide what goes in and what does not and write the discard table. The part being assessed is not the selection: it is the argument for each discard.
Exercise 3 — The row you cannot fill in. Pick the control in your E4 you have the most doubts about and try to write its complete E7 row. If you cannot name the evidence, diagnose why: is the control badly defined, does it have no owner, or is it not verifiable with the case's means? Rewrite it until the row comes out.
Solutions
Solution 1 — Complete chain over A-04 (the backup NAS)
R-05 If ransomware that has compromised the Gijon server (A-03) reaches the NAS (A-04)
through the permanently mounted share, then it also encrypts the only existing
backup, making it completely impossible to recover the clinical records of 4,800
patients, with a prolonged shutdown of clinical activity and a breach of the
retention duty of Law 41/2002. L=3 x I=5 = CRITICAL
R-11 If fire, flood or burglary affects the Gijon server room, then the server and the
only backup are lost together, with the same effect as R-05 and with no attacker
involved at all. L=2 x I=5 = HIGH
C-04 Immutable off-site backup, 30-day locked retention and quarterly timed restore
test. T+A. Recovery + Detective. R-01, R-05, R-11. CIS 11.x.
780 EUR and 22 h/year. Nuria P. Planned. 8.7 % of the budget for the best-scored
risk: it fits comfortably and it is the best risk-reduction-per-euro in the
catalogue.
Residual for R-05: L=3 x I=3 = MEDIUM. The likelihood does NOT drop -ransomware can
still get in- but the impact goes from irreversible to "two days of outage". That is
exactly what a recovery control does: it does not reduce L, it reduces I.
| Risk | Policy | Control | Specific evidence | Date | Status |
|--------|-------------|---------|-----------------------------------------------|------------|---------|
| R-05 | POL-04 §5.3 | C-04 | Timed restore report with start and end times | 2027-02-28 | Planned |
| | | | and verified tables; screenshot of the 30-day | | |
| | | | locked retention | | |Solution 2 — The impossible reconciliation
UNFILTERED CANDIDATES EUR h Nuria h Datacer
1 Immutable off-site backup + tests (C-04) 780 22 6
2 MFA in M365 (C-02) / 3 On-demand vendor access (C-01) 0 20 10
4 Individual identity in the treatment rooms (C-05) 1,450 30 16
5 Secure channel for patient photographs (C-08) 960 18 4
6 Alert on access outside the window (C-11) 0 14 10
7 Training + 2 phishing simulations (C-14) 450 12 0
8 Managed EDR on 30 machines 3,600 10 20
9 Replacing DentaGest with a supported version 22,000 40 60
10 External pentest with retest 4,500 8 0
TOTAL 33,740 / 174 h / 126 h AVAILABLE 9,000 / 180 h / 120 h
IN: 1-7 (plus six minor controls). OUT: 8, 9 and 10, with the arguments from section 5:
the EDR does not attack the main vector -a legitimate account-, replacing the software is
an investment decision and not a security one, and the pentest is not expensive but
premature. All three carry a review date, which is what turns a discard into a decision.Solution 3 — The row that would not come out
The problematic control is the one many people would write as "C-12: raise staff awareness about the appropriate use of patient data". When you write its row, the evidence column stays empty: "what do I show to prove that staff are aware?". The diagnosis is not that the evidence is missing: it is that the control is badly defined. "Raising awareness" is not a control, it is an aspiration: it has no observable outcome, no operational owner and cannot be verified.
BEFORE C-12 Raise staff awareness about the appropriate use of patient data.
Evidence: ????
AFTER C-12 Mandatory 45-minute training on processing health data, with a 10-question
quiz and an 80 % pass threshold, on every employee's induction and with an
annual refresher. Nuria P. Cost 0. 6 h/year. R-02, R-04, R-06.
CIS IG1 14.x.
| Risk | Policy | Control | Specific evidence | Date | Status |
|--------|-------------|---------|-----------------------------------------------|------------|---------|
| R-02 | POL-03 §5.2 | C-12 | Signed attendance register + export of the | 2027-05-30 | Planned |
| | | | quiz results with the % of passes | | |The proof that it is now right: the evidence can be named, it has a date, it is contemporaneous with the fact and it is generated by the activity itself — four of the five attributes of valid evidence from 06-04 — and the fifth, completeness, is met because the register covers the whole workforce and not a sample. The general lesson: if you cannot name the evidence, the control does not yet exist. It is the cheapest test you can apply to your catalogue, and in two minutes it detects the decorative controls that would otherwise make it all the way to the roadmap.
Conclusion
You now have the complete working manual. You know what is asked of you in each deliverable: E1 with the profile, the inventory of at least fifteen assets with a named owner, the DFD with trust boundaries and the STRIDE of one flow; E2 with ten risks phrased with the formula, scored on the 5x5 matrix, with inherent and residual, two ALEs with their assumptions and one ROSI; E3 with the policy map, two written in full — the ones attacking the top 3, not the easy ones — and the exceptions procedure with mandatory expiry; E4 with fifteen controls with nature, function, cost, hours, CIS IG1 and an honest status, reconciling with the budget and with the discard list; E5 with the team, the severities, a runbook executable by someone who did not write it, the 72-hour clock and RTO/RPO justified against 3-2-1-1-0; E6 with the verification calendar, between eight and ten detections with their logic and how each one is tested, and the pentest plan with its rules of engagement; E7 with the rules and their reasons, the RoPA with lawful basis and article 9 exception, the reasoned DPIA decision — including the "no" — the traceability matrix and the breach procedure; and E8 with the learning paths by role, the calendar, eight measurable indicators and the roadmap that reconciles with E4. You also have the ready-to-copy templates and, alongside each one, a filled-in fragment that sets the bar: the inventory where a shared account and reputation are assets; the card where every ALE figure carries its assumption and the residual explains why it does not drop further; the catalogue that discards a pentest for being premature and not for being expensive; the BIA that writes "last successful restore: NEVER" and turns that fact into the argument that approves the budget; the detections with the "how it is tested" column; the DPIA that reasons the negative as well; and the dashboard whose most interesting indicator measures a curve of human behaviour rather than a switch. And you take away the five cross-cutting requirements assessed over the whole — identifier consistency, financial realism, justification of every decision, fictitious or anonymised data and traceability as the guiding criterion — with the thirty-second consistency test, the file structure, the recommendation to version with git and the checklist covering completeness, consistency, realism and honesty.
Now comes the work. When you have a first complete version — even an improvable one, which always beats a perfect unfinished one — go to 07-03: Project Evaluation: there you will find the rubric you will score yourself with, the same deliverable shown at its four levels so you can see where you stand, the red flags that invalidate a dossier however good it looks, and the five defence questions you should be able to answer without looking at your documents. Assessing yourself well is, in itself, one of the competencies this course sets out to leave you with.
Fundamentals of Information Security Course
Module 1: Introduction to Information Security
- Basic Concepts of Information Security
- Types of Threats and Vulnerabilities
- Principles of Information Security
- Assets, Attack Surface and Threat Actors
Module 2: Cybersecurity
- Definition and Scope of Cybersecurity
- Types of Cyber Attacks
- Social Engineering and Phishing
- Protection Measures in Cybersecurity
- Identity, Authentication and Access Control
- Cybersecurity Incident Case Studies
Module 3: Cryptography
- Introduction to Cryptography
- Symmetric Cryptography
- Asymmetric Cryptography
- Hash Functions, HMAC and Password Storage
- Cryptographic Protocols
- Key Management, Certificates and PKI
- Applications of Cryptography
Module 4: Risk Management and Protection Measures
- Risk Assessment
- Security Policies
- Security Controls
- Third-Party and Supply Chain Risk
- Incident Response Plan
- Disaster Recovery and Business Continuity
Module 5: Security Tools and Techniques
- Vulnerability Analysis Tools
- Monitoring and Detection Techniques
- Penetration Testing
- Network Security
- Application Security
- System Hardening and Endpoint Security
- Cloud and Container Security
Module 6: Best Practices and Regulations
- Best Practices in Information Security
- Security Regulations and Standards
- Personal Data Protection and GDPR in Practice
- Compliance and Auditing
- Training and Awareness
- Ethics, Legal Aspects and Responsible Disclosure