# Chapter 11 Labs: Security Frameworks and GRC at Scale

This lab pack supports Chapter 11 of *Applied Cybersecurity: Foundations to Mastery*.
All six labs are analytical and documentation exercises: they produce artefacts
(gap tables, regulatory registers, risk registers, board packs, questionnaire banks)
that a real GRC programme keeps. There are no network-attack targets in this chapter.

The labs run in a Jupyter environment with pandas. The companion notebook
`11_control_matrix.ipynb` auto-generates the multi-framework control matrix
(CSF 2.0 / ISO 27001:2022 / SOC 2 / NIS2 / DORA / GDPR / NIST AI RMF / ISO 42001 / EU AI Act)
described throughout the chapter and provides scaffolding for all six labs.

---

## Prerequisites

- Docker Desktop (or Docker Engine + Compose plugin) installed and running
- ~1 GB free disk space for the image build
- No external network access required - all data is local

The image builds from `python:3.12-slim` and installs:
`jupyterlab`, `pandas`, `openpyxl`, `matplotlib`, `tabulate`

---

## Quick Start

```bash
# From this directory:
docker compose up -d

# Get the access URL (token is fixed as "ch11-grc-lab"):
docker compose logs jupyter | grep "http://127.0.0.1"

# Or just open: http://localhost:8888/lab?token=ch11-grc-lab
```

Open `11_control_matrix.ipynb` in JupyterLab and run cells in order.
All outputs are written to `notebooks/` (mounted from `./notebooks/`).
Seed data is in `seed/` (mounted read-only at `/home/jovyan/seed`).

---

## Lab 1: CSF 2.0 Gap Analysis on a Fictional Medium-Sized Firm

**Objective:** Execute a CSF 2.0 gap analysis for "Aria Logistics" (180 staff, AWS-hosted,
one SaaS payroll vendor, no formal ISMS). Produce a prioritised remediation list.

**Setup:** The seed file `seed/aria_logistics_profile.csv` contains Current and Target
Tier assignments for all 22 CSF 2.0 categories. No additional setup needed.

**Walkthrough:**

1. Open `11_control_matrix.ipynb` and run the Lab 1 section.
2. The notebook loads `aria_logistics_profile.csv` and computes the gap
   (Target Tier minus Current Tier) for each of the 22 categories.
3. Categories are sorted by gap size, with GOVERN categories prioritised first
   because the firm's largest exposure is its payroll vendor (GV.SC).
4. Review the Q1 action plan output: the top three gaps with a concrete quarter-one task.
5. Examine why "Tier 4 everywhere" is wrong for this firm (the over-engineering trap).

**Expected output:**
- `lab1_gap_table.csv`: 22 rows, one per CSF 2.0 category with Current/Target/Gap columns
- Console output showing the prioritised Q1 plan with GOVERN and GV.SC at the top

**Verify completion:** The notebook assertion cell checks that the table has exactly
22 rows (the verified CSF 2.0 count from CSWP 29) and that no target exceeds Tier 3
for this SME context.

**Cleanup:** No persistent resources; output files remain in `notebooks/`.

---

## Lab 2: DORA Register Meeting Article 28(3)

**Objective:** Build a register of information on all contractual ICT arrangements,
as DORA Article 28(3) requires, modelled on the four templates from Commission
Implementing Regulation (EU) 2024/2956 (Annexes I-IV).

**Setup:** The seed file `seed/dora_register_template.csv` contains a flat representation
of three fictional ICT providers: a cloud host, a SaaS AI fraud-detection tool,
and a clearing-and-settlement platform.

**Walkthrough:**

1. Run the Lab 2 section of the notebook.
2. The notebook pivots the flat CSV into the four register sheets:
   - RT-01: Reporting entity (with LEI)
   - RT-02: Provider master list (each with LEI)
   - RT-03: Contractual arrangements (with criticality flags)
   - RT-04: ICT service to function mapping
3. Note the criticality flag: all three arrangements support a critical or important
   function, which drives heavier DORA oversight for this entity.
4. Verify that at least one fourth-party sub-processor is surfaced
   (the AI fraud-detection vendor wraps a US foundation-model API).
5. The notebook exports a four-sheet Excel workbook (`lab2_dora_register.xlsx`).

**Expected output:**
- `lab2_dora_register.xlsx` (or `.csv` if openpyxl is unavailable): four-sheet register
- All three providers have LEI entries; sub-processor LEI included for fourth parties

**Verify completion:** Every row in RT-03 has a criticality flag populated.
At least one RT-03 row flags `sub_processors_identified = Yes` with a fourth-party LEI.

**Cleanup:** `docker compose down` (the container holds no persistent state).

---

## Lab 3: AI Risk Register - NIST AI RMF Map-Measure-Manage

**Objective:** Produce a three-row AI risk register applying the NIST AI RMF
Map-Measure-Manage loop to three distinct use cases.

**Setup:** The seed file `seed/ai_risk_register_template.csv` provides the
three use cases: a customer-service chatbot (UC-01), a CV-screening model (UC-02),
and an internal code-completion assistant (UC-03).

**Walkthrough:**

1. Run the Lab 3 section of the notebook.
2. The GOVERN section prints the one-page AI policy (risk appetite, ownership,
   non-negotiable characteristics from the NIST AI RMF).
3. The register loads and displays the MAP, MEASURE, and MANAGE columns.
4. The notebook flags which use case triggers EU AI Act high-risk obligations:
   UC-02 (CV-screening) is Annex III employment use case, requiring the full
   Articles 9-15 + Annex IV control set.
5. The chatbot (UC-01) triggers the Air Canada liability pattern: the company
   owns the chatbot's outputs regardless of the source.

**Expected output:**
- `lab3_ai_risk_register.csv`: three rows with Map/Measure/Manage columns
- Clear identification of UC-02 as the high-risk use case

**Verify completion:** Assertion checks three rows present; exactly one is high-risk.
All three MAP entries must include named affected stakeholders and data sources.

**Cleanup:** Output files in `notebooks/`; no persistent resources.

---

## Lab 4: EU AI Act Conformity Drill - Annex IV Technical Documentation Pack

**Objective:** Draft the technical documentation skeleton for the CV-screening model
(UC-02 from Lab 3), following EU AI Act Article 11 and Annex IV's nine headings exactly.

**Setup:** No additional seed data needed. The notebook generates the Annex IV
skeleton from the nine heading definitions.

**Walkthrough:**

1. Run the Lab 4 section of the notebook.
2. The notebook prints and exports a skeleton with one section per Annex IV heading.
3. Fill in the [bracketed placeholders] in `lab4_annex_iv_pack.txt`:
   - Section 2: The data datasheet is the most important - where did the training data
     come from, how was it labelled, what bias testing was run?
   - Section 4: The Art 9 risk-management entry (bias, inaccuracy, discriminatory output)
   - Section 8: Post-market monitoring plan with named owners
4. Key insight: the gaps you cannot fill are the actual findings an auditor would raise.
   A notified body or competent authority will start with Section 2(d) (data datasheet)
   and Section 4 (risk management).

**Expected output:**
- `lab4_annex_iv_pack.txt`: structured skeleton covering all nine Annex IV headings

**Verify completion:** The output file must contain all nine numbered sections.
Every section must be present even where content is scaffolded - absence of a section
heading is itself a conformity gap.

**Cleanup:** Output file in `notebooks/`.

---

## Lab 5: Board Pack - Three-Page Cyber-Risk Update

**Objective:** Produce the KRI inputs for a three-page cyber-risk board update
using fictional outputs from Labs 1-4. Report risk reduction against appetite,
not activity volume (the third pitfall).

**Setup:** No additional seed data; the notebook uses fictional KRI values for Aria Logistics.

**Walkthrough:**

1. Run the Lab 5 section of the notebook.
2. The notebook produces a KRI dashboard with four indicators, each with:
   - Current value vs. tolerance threshold (linked to GV.RM-02 risk appetite)
   - Trend (improving/worsening/stable)
   - FAIR-style euro exposure estimate
   - CSF 2.0 subcategory link
3. A bar chart visualises the exposure by KRI.
4. The self-grade cell checks for the Pitfall 3 failure mode: volume metrics
   (alerts triaged, emails blocked) instead of risk indicators vs. appetite.

**Expected output:**
- `lab5_kri_dashboard.csv`: KRI table with thresholds, trends, FAIR exposures
- `lab5_kri_chart.png`: bar chart for the board pack page 1

Board pack page structure:
- Page 1: Top three risks against appetite (FAIR exposure + trend arrow)
- Page 2: KRI vs. thresholds, regulatory exposure (NIS2/DORA/AI Act duties), material changes
- Page 3: Programme maturity (CSF Tier progress), incidents/near-misses, spend-vs-risk recommendation

**Verify completion:** No KRI in the dashboard should report a volume count
(the self-grade cell flags any "alerts triaged" / "emails blocked" style entries).

**Cleanup:** Output files in `notebooks/`.

---

## Lab 6: Vendor Security Questionnaire Bank (Classical + AI)

**Objective:** Build a tiered questionnaire bank that applies SIG/CAIQ for classical
vendors and adds an AI-specific addendum for any vendor whose product includes a model.

**Setup:** The seed file `seed/vendor_questionnaire_bank.csv` contains the full bank.

**Walkthrough:**

1. Run the Lab 6 section of the notebook.
2. The tiering rubric section shows how to score vendors on data sensitivity,
   business criticality, DORA criticality flag, and fourth-party concentration.
3. The question-set assignment maps tier scores to question depth:
   - Tier 1: SIG Detail (1,936 questions) + CAIQ (261) + AI tier (if applicable)
   - Tier 2: SIG Core (627) + AI tier (if applicable)
   - Tier 3: SIG Lite (128); AI tier if product includes a model
4. The AI-tier questions (AI-01 through AI-07) are highlighted - these are the
   questions a classical SIG or CAIQ does not ask:
   - AI-01: Model and training-data provenance (EU AI Act Annex IV sec 2)
   - AI-02: Data and model residency (GDPR Art 46)
   - AI-03: Prompt retention and fine-tuning terms (the most important question)
   - AI-04: Accuracy/hallucination SLAs (NIST AI RMF MEASURE)
   - AI-05: EU AI Act role and Annex III high-risk flag
   - AI-06: ISO 42001 / NIST AI RMF alignment
   - AI-07: Fourth-party foundation-model chain
5. The continuous monitoring plan shows per-tier refresh cadence, implementing
   the "vendor risk is a subscription" principle from Pitfall 2 (MOVEit/CL0P 2023).

**Expected output:**
- `lab6_questionnaire_bank.csv`: full tiered bank (classical + AI tier)
- `lab6_monitoring_plan.csv`: per-tier continuous monitoring cadence

**Verify completion:** The AI-tier section must contain at least 7 questions (AI-01 to AI-07).
The monitoring plan must have a row for each of the three tiers.
No Tier 3 vendor should be required to produce a full SOC 2 Type II report.

**Cleanup:** `docker compose down -v`

---

## Teardown

```bash
docker compose down -v
```

This stops and removes the container. No volumes are declared in compose,
so output files in `./notebooks/` persist on the host.

---

## Safety and Authorisation Note

All labs in Chapter 11 are documentation and analytical exercises.
No lab involves scanning, probing, or interacting with any network target.
No lab uses offensive tools.

Fictional data only: "Aria Logistics" and all vendors in the DORA register
are fictional. All LEI values in the seed data are illustrative format examples,
not real registered LEI codes. Do not use them to represent real entities.

If you adapt these labs to assess a real organisation, ensure you have written
authorisation from the asset owner before collecting or processing any real
vendor data, personal data, or system configuration information.

---

## Verified Framework Counts (from primary sources)

These counts are verified from NIST CSWP 29 directly; do not accept alternatives:

- CSF 2.0: 6 Functions, 22 Categories, 106 Subcategories
  - GOVERN: 6 categories
  - IDENTIFY: 3 categories
  - PROTECT: 5 categories
  - DETECT: 2 categories
  - RESPOND: 4 categories
  - RECOVER: 2 categories
- ISO 27001:2022 Annex A: 93 controls across 4 themes (37 Org + 8 People + 14 Physical + 34 Tech)
- NIST AI RMF: 4 Functions, 7 trustworthy characteristics, 12 GenAI risk categories (AI 600-1)
- EU AI Act: 4 risk tiers, Annex IV has 9 mandatory documentation headings

A count of 34 CSF categories means you are reading CSF 1.1, not 2.0.
A count of 114 ISO controls means you are reading the 2013 edition, which expired October 2025.
