Governance, Risk & Compliance
Lab Series

Scenario

Step-by-Step

1. Define the scope.

   Write 2–3 sentences describing which systems, locations, and data are in scope. For FinTrack: payment processing platform, customer database, employee laptops, cloud infrastructure (AWS).

2. Build an asset inventory.

   Create a spreadsheet with columns: Asset Name | Asset Type | Owner | Classification (Public / Internal / Confidential / Restricted) | Location. Populate at least 10 fictional assets for FinTrack (e.g., PostgreSQL customer DB, Stripe API integration, employee MacBooks).

3. Select a framework and list applicable controls.

   Use ISO 27001:2022 Annex A. It has 93 controls across 4 themes (Organisational, People, Physical, Technological). Create a tab in your spreadsheet and list each control with its reference (e.g., A.5.1 — Policies for information security).

4. Rate current compliance status for each control.

   For each control, assign: Not Started / Partial / Implemented / Not Applicable. Since FinTrack is a new program, most will be Not Started — that's fine and realistic.

5. Identify your top 10 gaps.

   Sort your control list by those marked "Not Started" that are highest-risk or required for certification. These become your Gap Register. Add columns: Gap Description | Risk if Unaddressed | Priority (High / Medium / Low) | Owner | Target Date.

6. Draft a 6-month compliance roadmap.

   Group the gap items into monthly milestones (e.g., Month 1: write policies; Month 2: conduct risk assessment; Month 3: deploy technical controls). This becomes the project plan you'd present to leadership.

Template — Asset Inventory

Asset Name          | Type        | Owner        | Classification | Location    | Notes
──────────────────────────────────────────────────────────────────────────────────
Customer DB (Prod)  | Database    | Engineering  | Restricted     | AWS RDS     | Contains PII
Payment API         | Application | Engineering  | Confidential   | AWS ECS     | PCI scope
Employee Laptops    | Hardware    | IT           | Internal       | Office/Remote| 38 units
AWS S3 Logs Bucket  | Storage     | Engineering  | Internal       | AWS S3      | 90-day retention
Slack Workspace     | SaaS        | IT           | Internal       | Cloud       | SSO enforced?
  → Add at least 10 rows. Mark PII-containing assets clearly.

Template — Gap Register

Control Ref | Control Name              | Status      | Gap Description                | Priority | Owner  | Due
──────────────────────────────────────────────────────────────────────────────────────────────────────
A.5.1       | InfoSec Policies          | Not Started | No written policies exist      | High     | CISO   | M1
A.5.10      | Acceptable Use of Assets  | Not Started | No AUP published to staff      | High     | HR/IT  | M1
A.8.8       | Mgmt of Technical Vulns   | Partial     | Patch cycle ad-hoc, no SLA     | High     | DevOps | M2
A.6.3       | Information Security Aware | Not Started | No security training program   | Medium   | HR     | M3
  → Continue for all identified gaps.

Completion Checklist

• Scope statement written (2–3 sentences)
• Asset inventory created with ≥10 assets, classified and owned
• ISO 27001 Annex A controls listed in spreadsheet with compliance status
• Top 10 gaps identified with priority and owner assigned
• 6-month roadmap drafted with monthly milestones

Scenario

Step-by-Step

1. Identify threats and vulnerabilities.

   For each asset from Lab 1, brainstorm realistic threats. Use the STRIDE model as a prompt: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Aim for 15 risk entries.

2. Score inherent risk (before controls).

   Rate each risk's Likelihood and Impact on the 1–5 scale. Multiply to get the Inherent Risk Score. Be honest — use the worst-case realistic scenario, not the absolute worst case.

3. Identify existing controls.

   For each risk, note any controls already in place (e.g., "MFA enabled on AWS console"). If there are none, write "None".

4. Score residual risk (after existing controls).

   Re-score the risk with existing controls factored in. This is the Residual Risk Score that the organisation currently carries.

5. Select a treatment for each risk.

   Assign Mitigate / Accept / Transfer / Avoid. For all "Mitigate" entries, write the proposed control action. For "Accept," document the business justification.

6. Assign ownership and due dates.

   Every risk entry must have a Risk Owner (the person accountable, not just responsible). Set a review date for each risk — quarterly for High/Critical, annually for Low/Medium.

7. Create a Risk Heat Map.

   Draw a 5×5 grid (Likelihood on Y axis, Impact on X axis) and plot each risk by its residual score. Colour-code zones: green (low), yellow (medium), orange (high), red (critical). This is your Board-ready visual.

Template — Risk Register

ID  | Asset           | Threat                      | Vuln                  | L | I | Inherent | Controls         | L | I | Residual | Treatment  | Owner    | Due
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
R01 | Customer DB     | SQL Injection                | Input not sanitised   | 3 | 5 | 15 HIGH  | WAF deployed     | 2 | 5 | 10 MED   | Mitigate   | Dev Lead | Q1
R02 | Employee Laptops| Phishing / Credential Theft | No security awareness | 4 | 4 | 16 HIGH  | None             | 4 | 4 | 16 HIGH  | Mitigate   | HR/IT    | M1
R03 | AWS S3 Bucket   | Misconfigured public access | Manual config process | 2 | 5 | 10 MED   | Config audits    | 1 | 5 | 5 LOW    | Accept     | DevOps   | Q2
R04 | Payment API     | Third-party breach (Stripe) | Vendor dependency     | 2 | 5 | 10 MED   | Contract + cyber | 1 | 4 | 4 LOW    | Transfer   | Legal    | Annual
  → L = Likelihood 1-5, I = Impact 1-5. Add at least 15 risk rows.

Completion Checklist

• At least 15 risk entries identified across multiple assets
• Inherent risk scored (Likelihood × Impact) for all entries
• Existing controls documented and residual risk re-scored
• Treatment assigned (Mitigate / Accept / Transfer / Avoid) with justification
• Risk owner and review date assigned to every entry
• 5×5 heat map drawn with risks plotted by residual score

Scenario

NIST CSF at a Glance

The NIST CSF organises security into 5 Functions, each containing Categories and Subcategories. Your job is to rate HealthBridge's current capability against each Function.

Step-by-Step

1. Download or recreate the NIST CSF subcategory list.

   The official list is at nist.gov/cyberframework. For this lab, you can use the 5 Functions with their top-level Categories (approximately 23 categories total).

2. Define a maturity scale.

   Use: 0 = Not Implemented | 1 = Initial (ad-hoc) | 2 = Developing (defined but inconsistent) | 3 = Defined (documented and practiced) | 4 = Managed (measured) | 5 = Optimised (continuous improvement).

3. Score HealthBridge's current state for each Category.

   Given the scenario (no formal program, recent ransomware), most Identify and Protect scores will be 0–1. Respond and Recover may be slightly higher if they managed to recover from the ransomware. Be realistic.

4. Set a target state score for each Category.

   Given their size and sector (healthcare), a realistic 12-month target for most categories is 2–3. Note the gap (Target – Current).

5. Prioritise the biggest gaps.

   Rank categories by gap size. Cross-reference with the Risk Register (Lab 2 concept) — the largest gaps that relate to the highest risks get priority.

6. Write a one-page executive summary.

   Summarise: overall maturity score (average across all categories), the top 3 critical gaps, and the recommended first 90 days of action. No jargon — this goes to clinic leadership, not security engineers.

Template — Gap Assessment

Function | Category                      | Current (0-5) | Target (0-5) | Gap | Priority | Notes / Evidence
──────────────────────────────────────────────────────────────────────────────────────────────────────────
IDENTIFY | ID.AM – Asset Management        |       0       |      3       |  3  |  HIGH    | No asset inventory exists
IDENTIFY | ID.RA – Risk Assessment          |       0       |      3       |  3  |  HIGH    | No formal RA ever done
IDENTIFY | ID.GV – Governance               |       1       |      3       |  2  |  HIGH    | No InfoSec policy
PROTECT  | PR.AC – Access Control           |       1       |      4       |  3  |  HIGH    | Shared admin passwords reported
PROTECT  | PR.AT – Awareness Training        |       0       |      3       |  3  |  MEDIUM  | No training program
DETECT   | DE.CM – Continuous Monitoring    |       0       |      2       |  2  |  HIGH    | No SIEM or alerting
RESPOND  | RS.RP – Response Planning        |       1       |      3       |  2  |  HIGH    | Informal response; no IR plan
RECOVER  | RC.RP – Recovery Planning        |       1       |      3       |  2  |  MEDIUM  | Backups exist, untested
  → Complete all 23 NIST CSF categories. Calculate average Current and Target scores.

Completion Checklist

• All 5 NIST CSF Functions scored at Category level (current + target)
• Gap calculated (Target – Current) for every category
• Top 5 gaps prioritised with justification
• Overall maturity score calculated (average across all categories)
• One-page executive summary written in plain language

Scenario

Step-by-Step

1. Write the Information Security Policy (ISP).

   This is the top-level document. It should state the organisation's commitment to information security, assign overall accountability (CISO or equivalent), and reference subordinate policies. Target: 1–2 pages.

2. Write the Acceptable Use Policy (AUP).

   This governs how staff may use company systems and data. Cover: permitted use, prohibited activities, personal device rules (BYOD), internet/email use, password requirements, consequences of violation. Target: 2–3 pages.

3. Add a policy metadata header to each document.

   Policy Name | Version | Owner | Approved By | Approval Date | Next Review Date | Classification.

4. Map each policy to its ISO 27001 control.

   Create a one-line mapping table at the end of each policy (e.g., AUP section 3.2 → A.5.10 Acceptable Use of Assets).

5. Write an exception process.

   Describe how staff can request an exception if they genuinely cannot comply with a policy requirement. Include: who approves, what documentation is needed, and how exceptions are tracked (this feeds your exception register).

Template — Policy Document Structure

FINTRACK LTD — ACCEPTABLE USE POLICY
──────────────────────────────────────────
Version:       1.0
Owner:         Head of IT / CISO
Approved By:   CEO — [Name]
Date:          [Date]
Next Review:   [Date + 1 year]
Classification: Internal
──────────────────────────────────────────

1. PURPOSE
This policy defines acceptable use of FinTrack's information systems,
networks, and data by all employees, contractors, and third parties.

2. SCOPE
Applies to: All staff, contractors, and any third party accessing FinTrack systems.

3. ACCEPTABLE USE
3.1 Systems are provided for business purposes. Incidental personal use is permitted
    provided it does not interfere with duties or consume excessive resources.
3.2 Users must not store personal data on company systems without approval.
3.3 Users must lock their screen when leaving a workstation unattended.

4. PROHIBITED ACTIVITIES
Users must not:
  • Access, copy, or share data beyond their authorised role
  • Install unauthorised software on company devices
  • Use company systems to access illegal or inappropriate content
  • Share credentials with others under any circumstances

5. PASSWORDS
All accounts must use passwords of ≥14 characters. MFA is mandatory for
all business-critical systems. Passwords must not be reused across systems.

6. VIOLATION
Violations may result in disciplinary action up to and including termination.

7. EXCEPTIONS
Requests for exceptions must be submitted to [owner@fintrack.com] with
business justification and approved in writing before non-compliance begins.

8. CONTROL MAPPING
Section 3: ISO 27001 A.5.10  | Section 5: A.5.17  | Section 4: A.8.19, A.8.20

Completion Checklist

• Information Security Policy drafted (1–2 pages, leadership-approved fictionally)
• Acceptable Use Policy drafted with all 7 sections
• Policy metadata header on both documents (version, owner, review date)
• ISO 27001 control mapping table included
• Exception process defined and documented

Scenario

Step-by-Step

1. Classify the vendor's data access tier.

   Tier 1 (Critical): Processes regulated PII or has deep system access. Tier 2 (High): Accesses internal data. Tier 3 (Low): No data access. DocuStore Pro handles customer PII with bank data — this is Tier 1, triggering full assessment.

2. Build a questionnaire covering 8 security domains.

   Write 3–5 questions per domain (see template below). Each question should be yes/no or multiple choice with space for evidence.

3. Fill in the questionnaire as if you are DocuStore Pro.

   Simulate realistic vendor responses. Mix strong answers (SOC 2 certified, MFA enforced) with some gaps (no formal patch SLA, sub-processors not disclosed).

4. Score each domain and calculate a total risk rating.

   Assign each domain a score: 0 (no controls) → 3 (strong controls). Weight high-risk domains (data security, access control) more heavily.

5. Identify red flags / deal-breakers.

   Certain answers should be automatic escalation triggers regardless of overall score: no encryption at rest, no incident notification process, no sub-processor disclosure.

6. Write a vendor assessment report with a recommendation.

   Conclude with one of: Approve / Approve with conditions / Reject. List any contractual obligations that must be included in the Data Processing Agreement (DPA).

Template — Vendor Questionnaire

DOMAIN 1 — Data Security
Q1: Is data encrypted at rest? If so, what algorithm?         → Response: Yes, AES-256
Q2: Is data encrypted in transit?                                  → Response: Yes, TLS 1.2/1.3
Q3: Where is data physically stored? Which regions?               → Response: AWS eu-west-1 (Ireland)
Q4: Do you use sub-processors? Who are they?                      → Response: "Not disclosed" ⚠ RED FLAG

DOMAIN 2 — Access Control
Q1: Is MFA enforced for all admin/staff access?                   → Response: Yes
Q2: Is access reviewed periodically? How often?                  → Response: Annually
Q3: Is privileged access managed separately (PAM)?               → Response: No formal PAM tool ⚠

DOMAIN 3 — Incident Response
Q1: Do you have a documented IR plan?                             → Response: Yes
Q2: What is your customer notification SLA for breaches?          → Response: 72 hours

DOMAIN 4 — Certifications & Audits
Q1: Do you hold SOC 2 Type II / ISO 27001 certification?         → Response: SOC 2 Type II (2023)
Q2: Can you provide the most recent audit report / cert?          → Response: Yes, under NDA

  → Add domains: Vulnerability Management, Business Continuity, Personnel Security, Physical Security

Completion Checklist

• Vendor classified into a risk tier (1 / 2 / 3)
• Questionnaire built across at least 6 security domains
• Questionnaire completed with simulated vendor responses
• Domain scores calculated and at least 2 red flags identified
• Assessment report written: Approve / Approve with conditions / Reject
• DPA obligations listed (what must be in the contract)

Scenario

Step-by-Step

1. Select 5 ISO 27001 Annex A controls to test.

   Choose a mix across themes: at least one organisational, one technological, and one people control. Suggested: A.5.1 (InfoSec Policies), A.5.17 (Auth information), A.6.3 (Awareness training), A.8.5 (Secure authentication), A.8.8 (Vulnerability management).

2. For each control, write a control description in plain language.

   Explain what the control requires the organisation to do, without ISO jargon. This is the "what should be happening" baseline.

3. Define the test procedure.

   Describe step-by-step what you would do to test the control — what you'd request, who you'd interview, what system you'd query.

4. Define what "pass" evidence looks like.

   List the specific artefacts the auditor would need to see. Be precise: not just "a policy" but "signed PDF version 1.2 dated within the last 12 months with CEO approval signature."

5. Create mock evidence for each control.

   For this lab, simulate the evidence. Write a short mock policy, create a fictional training completion report, produce a screenshot-style config description. This is what a GRC analyst would gather before handing off to the auditor.

6. Rate each control as: Pass / Pass with observation / Fail.

   An "observation" (not quite a finding) is where the control is mostly met but has a minor weakness. A "finding" (fail) is a nonconformity that must be remediated for certification.

Template — Evidence Pack

Control Ref:    A.6.3 — Information Security Awareness, Education and Training
Plain Desc:     All staff must receive security awareness training relevant to their role.
                Training must be updated regularly and completion tracked.

Test Procedure:
  1. Request the security awareness training curriculum and materials
  2. Request training completion records for all staff (last 12 months)
  3. Interview 3 randomly selected staff: "When did you last receive security training?
     What topics were covered?"
  4. Verify the training was reviewed/updated within the last year

Pass Evidence Needed:
  ✓ Training materials (slides/video) with a version date
  ✓ Completion report showing ≥95% staff completed training in last 12 months
  ✓ Evidence of annual curriculum review (email approval or change log)
  ✓ Interview notes confirming staff awareness

Mock Evidence Created:
  - "FinTrack Security Awareness Training v2.1 — Completed March 2025"
  - Completion report: 37/38 staff complete (97.4%) — 1 person on leave
  - Interview notes: 3 staff confirmed phishing training and password policy

Audit Rating:   PASS ✓
  → Repeat this block for all 5 selected controls

Completion Checklist

• 5 controls selected across at least 3 Annex A themes
• Plain-language description written for each control
• Test procedure documented (what you'd do, who you'd ask)
• Pass evidence defined specifically (not vaguely)
• Mock evidence created or described for each control
• Each control rated: Pass / Pass with observation / Fail

Scenario

Step-by-Step

1. Describe what data is processed and why.

   Document: What personal data is used (transaction history, account details, spending categories)? Who processes it (FinTrack + AI vendor)? What is the lawful basis under GDPR (consent? legitimate interests?)? What is the purpose?

2. Assess necessity and proportionality.

   Is the data processing actually necessary for the feature to work? Could less personal data achieve the same outcome (data minimisation)? Is the retention period justified? Could users opt out?

3. Identify privacy risks to individuals.

   List at least 5 risks. Consider: unauthorised access to spending data, AI model profiling leading to discrimination, data shared with third-party AI vendor without user knowledge, data retained beyond necessity, re-identification of anonymised data.

4. Rate each risk (Likelihood × Impact).

   Use the same 1–5 scale from Lab 2. Add a "privacy impact" dimension: how much harm could this cause to individuals (embarrassment, financial loss, discrimination)?

5. Propose mitigation measures for each risk.

   For each risk, define the control measure. Examples: pseudonymise transaction data before sending to AI vendor; obtain explicit consent with a clear opt-in; include the AI vendor in the vendor assessment process (Lab 5); limit data retention to 90 days.

6. Consult the Data Protection Officer (DPO) — simulate this.

   Write a one-paragraph summary you would send to the DPO requesting sign-off, including the residual risks after mitigation and your recommendation (proceed / proceed with conditions / do not proceed).

7. Complete the DPIA record.

   Compile all sections into a single DPIA document. Add: Date | Feature Name | Data Controller | DPO Sign-off | Outcome | Review Date.

Template — DPIA Record

SECTION 1 — PROCESSING DESCRIPTION
Feature:           AI-Powered Spending Insights
Data Subjects:     FinTrack retail customers (~12,000)
Data Processed:    Transaction history, merchant names, amounts, dates, account balance
Lawful Basis:      Legitimate interests (Art. 6(1)(f)) — under review; consent preferred
Third Parties:     InsightML Ltd (AI vendor, data processor, EU-based)
Retention Period:  Proposed: Indefinite ⚠ — under review

SECTION 2 — RISK REGISTER
Risk                              | L | I | Score | Mitigation
──────────────────────────────────────────────────────────────────────────
AI vendor data breach             | 2 | 5 |  10   | Vendor DPIA required; DPA signed
Profiling leads to discrimination | 2 | 4 |   8   | Bias audit on model; human review
Retention beyond necessity        | 3 | 3 |   9   | 90-day hard delete policy
User unaware data shared with AI  | 4 | 3 |  12   | Update Privacy Notice; add consent
Re-identification of pseudonymised | 1 | 5 |   5   | Pseudonymisation + k-anonymity check

SECTION 3 — OUTCOME
Recommendation:    PROCEED WITH CONDITIONS
Conditions:        1) Update Privacy Notice before launch
                   2) Obtain explicit opt-in consent
                   3) Complete vendor assessment for InsightML Ltd
                   4) Set 90-day transaction data retention cap
DPO Sign-off:      [DPO Name] — pending
Review Date:       6 months post-launch or if processing changes

Completion Checklist

• Processing description completed (data, subjects, purpose, lawful basis, third parties)
• Necessity and proportionality assessed — data minimisation considered
• At least 5 privacy risks identified and scored
• Mitigation measure defined for each risk
• DPO consultation paragraph written
• DPIA record compiled with outcome: Proceed / Conditions / Do Not Proceed

Scenario

Step-by-Step

1. Identify the policy clause being violated for each situation.

   Reference the exact policy and section. E.g., AUP Section 5: "MFA is mandatory for all business-critical systems." The legacy server cannot enrol in MFA — this violates AUP §5.

2. Write a formal exception request for each situation.

   Each request must include: Requestor name and role | System/asset affected | Policy clause breached | Business justification (why cannot comply) | Risk introduced | Proposed compensating controls | Requested duration.

3. Assess the risk level of each exception.

   Use the same Likelihood × Impact scoring from Lab 2. An exception that introduces a Critical residual risk should require CISO or Board-level approval, not just a manager sign-off.

4. Define compensating controls for each exception.

   Compensating controls are alternative safeguards that reduce the risk created by not following the policy. For the MFA exception: network isolation of the legacy server + enhanced monitoring + monthly access review.

5. Determine the appropriate approver for each exception.

   Create an approval matrix: Low risk → Team Manager. Medium → CISO. High/Critical → CISO + Legal. Document who approved, when, and for how long.

6. Log all exceptions in an Exception Register.

   The register tracks every active exception, its status, expiry date, and whether a resolution plan exists (e.g., "Legacy server to be decommissioned by Q3 — tracked in IT roadmap").

7. Simulate a quarterly exception review.

   Go through each entry: Has the exception expired? Has the root cause been resolved? Should it be renewed, escalated, or closed? Document the review outcome.

Template — Exception Request Form

EXCEPTION REQUEST FORM
──────────────────────────────────────────────────────────
Exception ID:         EXC-001
Date Submitted:       [Date]
Requestor:            Alex Osei, Infrastructure Lead
System / Asset:       Legacy Payroll Server (WIN-PAY-01, Windows Server 2012)
Policy Violated:      Acceptable Use Policy v1.0, Section 5 — MFA Mandatory

Business Justification:
  WIN-PAY-01 runs payroll software that does not support modern MFA
  protocols. Upgrading or replacing the software requires a 6-month
  procurement and migration process. Disabling the server would halt
  payroll processing for 200+ employees.

Risk Introduced:
  Without MFA, a compromised credential could allow unauthorised access
  to payroll data including salary and bank details.
  Risk Score: Likelihood 2 × Impact 5 = 10 (MEDIUM)

Compensating Controls:
  1. WIN-PAY-01 isolated to dedicated VLAN; no internet access
  2. Access restricted to 3 named accounts (monthly access review)
  3. All logins logged and forwarded to SIEM with alerting
  4. Physical access to server room required

Requested Duration:   6 months (until payroll system migration is complete)
Resolution Plan:      New payroll SaaS with MFA support — procurement in progress (IT-2025-014)
Approver Required:    CISO (Medium risk)
Approved By:          [CISO Name] — [Date]
Expiry Date:          [Date + 6 months]

Template — Exception Register

ID      | Policy Clause | Asset         | Risk  | Comp Controls | Approver | Approved   | Expiry     | Status
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
EXC-001 | AUP §5 – MFA  | WIN-PAY-01    | MED   | VLAN iso, SIEM | CISO    | 2025-01-10 | 2025-07-10 | Active
EXC-002 | AUP §3 – Admin| Dev MacBook   | MED   | EDR enhanced   | CISO    | 2025-01-12 | 2025-04-12 | Active
EXC-003 | AUP §3 – ProdDB| Contractor X | HIGH  | Audit log, VPN | CISO+Leg| 2025-01-15 | 2025-02-15 | Active
  → Review all entries quarterly. Flag any approaching expiry 30 days in advance.

Completion Checklist

• Policy clause identified for each of the 3 situations
• Formal exception request written for all 3 scenarios
• Risk scored for each exception (Likelihood × Impact)
• Compensating controls defined for each exception
• Approval matrix created (who approves at Low / Med / High risk)
• Exception Register populated with all 3 entries
• Quarterly review simulated — outcomes documented

Scenario

Step-by-Step

1. Identify critical business processes.

   For HealthBridge, list all key operational processes: patient scheduling, clinical records access, prescription processing, billing, staff communications. Focus on processes that, if disrupted, directly harm patient safety or revenue.

2. Conduct the Business Impact Analysis (BIA).

   For each process, rate the impact of disruption at four time intervals: 1 hour, 4 hours, 24 hours, 72 hours. Use a 1–5 scale: 1 = Negligible, 5 = Catastrophic (patient safety risk, regulatory breach). This determines prioritisation.

3. Define RTO and RPO for each critical system.

   The patient scheduling system going down for 72 hours is catastrophic — so its RTO should be 4 hours maximum. The RPO should be no more than 1 hour of data loss given appointment data changes constantly.

4. Identify recovery strategies for the top-priority system.

   Options include: restore from backup, failover to secondary site, use a manual paper-based workaround while IT is restored, use a cloud-hosted DR environment (hot/warm/cold standby). Select and justify the strategy that meets the RTO/RPO.

5. Write the Disaster Recovery Plan for the Patient Scheduling System.

   The DRP must include: trigger conditions (when is the DRP invoked?), step-by-step recovery procedure, roles and responsibilities, communication plan, rollback procedure if recovery fails, and success criteria (how do you know recovery is complete?).

6. Define a BCP test schedule.

   A plan that has never been tested is not a plan — it's a hope. Define: tabletop test (quarterly), walkthrough test (annually), full failover test (annually). Document who owns each test and what constitutes a pass.

Template — BIA Table

Process                  | System             | 1hr | 4hr | 24hr | 72hr | RTO    | RPO    | Priority
──────────────────────────────────────────────────────────────────────────────────────────────────────────
Patient Scheduling       | SchedPro (SaaS)    |  2  |  3  |   5  |   5  | 4 hrs  | 1 hr   | CRITICAL
Clinical Records (EHR)   | HealthEHR (on-prem)|  3  |  4  |   5  |   5  | 2 hrs  | 30 min | CRITICAL
Prescription Processing  | RxLink API         |  2  |  3  |   4  |   5  | 4 hrs  | 2 hrs  | HIGH
Staff Email              | Microsoft 365      |  1  |  2  |   3  |   4  | 8 hrs  | 4 hrs  | MEDIUM
Billing / Finance        | QuickBooks Online  |  1  |  1  |   2  |   4  | 24 hrs | 4 hrs  | MEDIUM
  → Impact scale: 1=Negligible, 5=Catastrophic. Add all key HealthBridge processes.

Template — DR Plan Structure

DR PLAN — PATIENT SCHEDULING SYSTEM (SchedPro)
──────────────────────────────────────────────────────
RTO:              4 hours
RPO:              1 hour
Recovery Strategy:Warm standby in AWS eu-west-1 (syncs every 30 min)
DR Owner:         IT Manager — [Name]

TRIGGER CONDITIONS
Invoke this DRP when SchedPro is unavailable for >30 minutes AND
the vendor's support team cannot confirm resolution within 60 minutes.

STEP-BY-STEP RECOVERY
Step 1 [T+0:00]  — IT Manager declares incident; notifies IC and clinic director
Step 2 [T+0:15]  — Activate manual paper-based scheduling workaround (see Annex A)
Step 3 [T+0:30]  — Contact SchedPro vendor; open P1 ticket; obtain status
Step 4 [T+1:00]  — If vendor cannot restore within 1hr, invoke AWS warm standby:
                    a) SSH to dr-schedpro-aws.internal
                    b) Run /opt/dr/promote_standby.sh
                    c) Update DNS: schedpro.healthbridge.ie → DR IP
Step 5 [T+2:00]  — Validate DR environment: test booking creation, cancellation
Step 6 [T+3:30]  — Communicate restoration to all clinical staff
Step 7 [T+4:00]  — RTO checkpoint: if not restored, escalate to CEO + Board

COMMUNICATION PLAN
  T+0:00  → IT team notified (PagerDuty)
  T+0:30  → Clinic director + reception managers notified
  T+2:00  → All clinical staff notified of DR status
  T+4:00  → Board notified if RTO breached

SUCCESS CRITERIA
  ✓ Staff can view and create appointments in DR environment
  ✓ Appointment data loss does not exceed 1 hour (RPO met)
  ✓ System restored within 4 hours (RTO met)

TEST SCHEDULE
  Tabletop:       Quarterly (Jan, Apr, Jul, Oct)
  Failover drill: Annually (off-hours, last Sunday of March)
  Owner:          IT Manager

Completion Checklist

• Critical business processes identified (at least 5)
• BIA completed with impact scores at 1hr / 4hr / 24hr / 72hr
• RTO and RPO defined for each critical process
• Recovery strategy selected and justified for top-priority system
• Disaster Recovery Plan written with trigger, steps, comms, and success criteria
• BCP test schedule defined (tabletop + failover drill)

Scenario

Step-by-Step

1. Build the GRC Program Status Dashboard.

   Create a single-page summary showing: Compliance Program maturity score (from Lab 1 + 3), number of open risks by severity (from Lab 2), Gap Assessment score (Lab 3), open policy exceptions (Lab 8), active vendor risks (Lab 5), and BCP/DR readiness status (Lab 9). Use a traffic-light (RAG) status for each domain.

2. Write a Top 5 Risks summary for the Board.

   From your risk register (Lab 2), pull the 5 highest residual-risk items. For each, write 2–3 sentences in plain business language — no technical jargon. Include what the risk means in business terms (financial loss, reputational damage, regulatory fine) and what's being done about it.

3. Summarise the compliance posture.

   How many ISO 27001 controls are: Implemented / Partial / Not Started? What is the percentage complete? What is the path to certification — and what are the blockers? Translate the gap register (Lab 1) into a simple progress bar narrative.

4. Present vendor and third-party risk exposure.

   How many vendors have been assessed (Lab 5)? How many are Tier 1? Are there any with outstanding remediation requirements? Are all critical vendors covered by a signed DPA? Flag any unassessed critical vendors as an open risk.

5. Summarise open exceptions.

   From Lab 8: how many exceptions are active? Which are approaching expiry? Are any at High/Critical risk with no resolution plan? The Board needs to know if any exceptions represent material risk that they should be aware of.

6. Present the 12-Month GRC Roadmap.

   Build a quarter-by-quarter roadmap covering: Q1 (achieve ISO 27001 certification), Q2 (complete vendor assessment program), Q3 (close all High-risk exceptions), Q4 (conduct first full BCP failover test). Each milestone should include owner, cost estimate (even rough), and success metric.

7. Write the Board briefing script.

   Structure a 15-minute Board presentation: 2 min opening (purpose and scope), 5 min current state (dashboard + top 5 risks), 3 min compliance progress, 2 min vendor and exceptions, 3 min roadmap and ask (budget, headcount, or policy decisions needed from the Board).

Template — GRC Status Dashboard

DOMAIN                     | STATUS | SCORE / COUNT        | TREND  | NOTES
──────────────────────────────────────────────────────────────────────────────────────────────────
ISO 27001 Compliance        | 🟡 AMB | 58% controls met     |   ↑    | Certification in 3 months
Risk Register               | 🟠 AMB | 3 Critical, 6 High   |   →    | 2 Critical unmitigated
NIST CSF Maturity           | 🟡 AMB | Avg score: 2.1 / 5   |   ↑    | Detect function still 0.8
Policy Coverage             | 🟢 GRN | 8 of 12 policies done|   ↑    | AUP + ISP complete
Vendor Risk                 | 🔴 RED | 3 of 9 Tier-1 assessed|  ↑    | 6 unassessed vendors
Open Exceptions             | 🟡 AMB | 3 active (1 High)    |   →    | EXC-001 expires in 2 weeks
BCP / DR                    | 🔴 RED | Plan drafted, untested|  ↑    | No failover test conducted
Awareness Training          | 🟢 GRN | 97% completion       |   ↑    | Annual cycle complete
  → 🟢 Green = On track | 🟡 Amber = Needs attention | 🔴 Red = Requires escalation

Template — Board Top 5 Risks

RISK 1 — Unassessed Third-Party Vendors
Six of our nine critical vendors have not yet undergone a security assessment.
If any of these vendors suffered a breach, FinTrack could face data exposure
affecting customer payment records and potential regulatory fines of up to €20M
or 4% of global turnover under GDPR.
Action: Vendor assessment program to be completed by end of Q2.

RISK 2 — Customer Database SQL Injection Vulnerability
A vulnerability in our payment API's input validation could allow an attacker
to extract customer bank account details. A WAF is in place but the underlying
code fix has not been deployed. Estimated exposure: 12,000 customer records.
Action: Developer fix prioritised — target: 30 days.

RISK 3 — No Tested Disaster Recovery for Core Systems
Our DR plan for the core payment platform exists on paper but has never been
tested. In the event of a ransomware attack (similar to the HealthBridge incident),
we do not have validated confidence in our ability to recover within the 4-hour RTO.
Action: Failover drill scheduled for Q3.

  → Write risks 4 and 5 from your own Risk Register (Lab 2)

Template — 12-Month GRC Roadmap

QUARTER | MILESTONE                              | OWNER      | METRIC
────────────────────────────────────────────────────────────────────────────────
Q1      | ISO 27001 Stage 2 Audit + Certification | CISO / GRC | Cert received
Q1      | Close EXC-001 (legacy payroll server)    | IT Manager | Exception closed
Q2      | Complete vendor assessments (all Tier 1)  | GRC Analyst| 9/9 assessed
Q2      | Deploy SIEM and detection rules           | SecOps     | NIST DE score ≥ 2.5
Q3      | Close all High-risk open exceptions       | GRC / CISO | 0 High exceptions
Q3      | Conduct BCP full failover test            | IT Manager | RTO/RPO met in test
Q4      | Annual Risk Register review               | GRC Analyst| All risks re-scored
Q4      | NIST CSF re-assessment (target score ≥ 3) | CISO       | Avg score ≥ 3.0/5
  → Each row should reference the Lab or document it relates to for traceability.

Completion Checklist

• GRC Status Dashboard built with RAG status across all 8 domains
• Top 5 risks written in plain business language (no jargon)
• Compliance posture summarised with percentage progress
• Vendor risk exposure summarised (assessed vs. unassessed)
• Open exceptions summarised with any near-expiry flagged
• 12-month GRC roadmap drafted with owners, milestones, and metrics
• 15-minute Board briefing script written and timed

Why this lab exists

The EU AI Act entered into force in August 2024 and is now actively enforced in stages. Prohibited AI practices became enforceable in February 2025; obligations for general-purpose AI (GPAI) models applied from August 2025. Any GRC analyst working in or with EU-facing organisations must understand AI risk classification, governance obligations, and the ISO 42001 standard — which is becoming as expected as ISO 27001 was a decade ago.

Scenario

EU AI Act — Risk Tiers at a Glance

ISO 42001 — AI Management System (AIMS) Structure

Step-by-Step

1. Create an AI System Inventory for FinTrack.

   List every AI system or AI-enabled feature in use (or planned). For each, record: System Name | Purpose | Data inputs | Who is affected | Vendor or in-house | Deployment status. This is your AI asset register — the starting point for all governance.

2. Classify each AI system under the EU AI Act risk tiers.

   Apply the four-tier model to each of the three FinTrack AI features. The credit-scoring model is Annex III (High Risk — credit decisions affecting natural persons). The Spending Insights tool is Limited Risk. The internal HR chatbot is Limited Risk (must disclose it's AI). Document your classification rationale.

3. Build an AI Risk Register.

   For each AI system, identify specific AI risks (bias, drift, opacity, data quality, third-party dependency). Score each risk using Likelihood × Impact × Severity of harm to individuals (add a third axis: 1 = inconvenience → 5 = physical/financial harm or discrimination).

4. Define human oversight controls for the High Risk system.

   EU AI Act Article 14 requires meaningful human oversight of High Risk AI. For the credit-scoring model: define who reviews AI-generated decisions before they affect customers, what the override process is, and how decisions are logged for auditability.

5. Map controls to ISO 42001 Annex A.

   Select the 10 most relevant controls from ISO 42001 Annex A for FinTrack's AI use cases. For each control, document: current status (Implemented / Partial / Not Started), gap description, and treatment action. This becomes your AI compliance gap register.

6. Draft an AI Policy statement.

   Write a one-page AI Policy for FinTrack covering: permitted AI use cases, prohibited uses (aligned to EU AI Act Article 5), data governance requirements for AI training data, human oversight requirements, and accountability (who owns AI governance). This maps to ISO 42001 clause 5.2.

7. Write an AI Incident response procedure.

   Define what constitutes an "AI incident" (e.g., model producing discriminatory outputs, unexplained decisions leading to customer harm, model drift detected). Define: detection triggers, escalation path, customer notification obligations, regulator notification (EU AI Act requires serious incident reporting), and post-incident review.

Template — AI System Inventory & Classification

System Name          | Purpose                    | Data Inputs              | Affected Parties     | Source    | EU AI Act Tier | Rationale
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
CreditScore AI       | Loan approval scoring       | Transactions, credit hist| Customers (EU)       | In-house  | HIGH RISK       | Annex III §5(b) — credit scoring decisions on natural persons
Spending Insights    | Personalised spend reports  | Transaction history       | Customers (EU)       | Vendor ML | LIMITED RISK    | No consequential decisions; transparency obligation applies
HR Chatbot (internal)| Staff HR query handling    | HR policy docs            | Employees            | Vendor SaaS| LIMITED RISK   | Art. 50 — must disclose AI to users interacting with it
  → Add all AI systems. Re-assess tier when purpose or data inputs change.

Template — AI Risk Register

System          | Risk                    | L | I | Harm | Score | Treatment                          | Owner      | ISO 42001 Control
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
CreditScore AI  | Biased outputs (gender) | 3 | 5 |  5   |  75   | Bias audit quarterly; diverse dataset| Data Sci  | A.6.2.4 Fairness
CreditScore AI  | Model drift             | 3 | 4 |  4   |  48   | Monthly performance monitoring     | MLOps      | A.6.2.6 Performance
CreditScore AI  | No explainability       | 4 | 4 |  4   |  64   | Implement SHAP/LIME explanations   | Engineering| A.6.2.5 Transparency
Spending Insight | Third-party model opacity| 2 | 3 |  3   |  18   | Vendor AI assessment (Lab 5 method)| GRC        | A.8.4 Supply chain
HR Chatbot      | Hallucination / bad HR  | 3 | 3 |  3   |  27   | Human review of novel queries      | HR / IT    | A.6.2.3 Human oversight
  → Score = L × I × Harm. Prioritise High Risk system entries first.

Template — ISO 42001 Annex A Gap Register (Top 10 Controls)

Control Ref | Control Name                         | Status      | Gap / Notes                               | Priority
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
A.5.2       | AI Policy                            | Not Started | No AI policy exists                       | High
A.6.1.2     | AI Risk Assessment Process            | Partial     | Risk register started (this lab)          | High
A.6.2.3     | Human Oversight Mechanisms            | Partial     | Defined for CreditScore; not documented   | High
A.6.2.4     | Fairness & Bias Testing              | Not Started | No bias testing process in place          | High
A.6.2.5     | Transparency & Explainability        | Not Started | No explainability tooling deployed        | High
A.6.2.6     | AI System Performance Monitoring      | Not Started | No model drift monitoring                 | High
A.7.4       | AI Training Data Governance           | Partial     | Data documented; no quality audit process | Medium
A.8.4       | AI Supply Chain / Third-Party         | Not Started | Vendor AI not assessed                    | High
A.9.1       | AI Incident Detection & Reporting    | Not Started | No AI incident procedure exists           | High
A.10.1      | Continual Improvement of AIMS         | Not Started | No review cycle defined                   | Medium

Completion Checklist

• AI System Inventory created with all FinTrack AI features listed
• Each system classified under EU AI Act risk tier with written rationale
• AI Risk Register built (at least 8 entries, scored on L × I × Harm)
• Human oversight controls defined for the High Risk (credit scoring) system
• ISO 42001 Annex A gap register completed for top 10 controls
• AI Policy statement drafted (1 page, covers permitted use, prohibited use, accountability)
• AI Incident response procedure written with escalation path and regulator notification

Why this lab exists

Traditional GRC — gather screenshots once a year, hand them to an auditor — is being replaced. Modern GRC platforms (Vanta, Drata, Secureframe, Anecdotes, TrustCloud) connect directly to cloud environments, identity providers, and vulnerability scanners, running automated pass/fail tests against controls every day. The result is "always-on compliance" — you know your posture right now, not as of last quarter's audit. Lab 6's manual evidence gathering is still a useful skill, but this is what production looks like in 2026.

Scenario

Step-by-Step

1. Map FinTrack's tech stack to data sources for CCM.

   For each major system FinTrack uses, identify what compliance-relevant data it can expose via API. This becomes your CCM integration map — the foundation of what can and cannot be automated.

2. Categorise your ISO 27001 / SOC 2 controls into: automatable vs. manual.

   Go through the control list from Lab 1/6. For each control, decide: Can this be tested programmatically? If yes, what data source is needed and what's the pass/fail logic? If no, document why and what evidence collection process remains manual.

3. Write control test specifications for 8 automatable controls.

   For each automated control, write a test spec in the format: Control → Data Source → Test Logic → Pass Condition → Fail Condition → Alert Action. See the template below.

4. Design the alert and remediation workflow.

   When a control test fails, what happens next? Define: Who is alerted (control owner), what SLA they have to remediate (e.g., Critical = 24 hrs, High = 7 days), how the failure is tracked (ticket in Jira/TheHive), and when it auto-escalates to the CISO.

5. Design cross-framework control mapping.

   A key benefit of CCM is that one test can satisfy multiple frameworks simultaneously. For example, a test proving "MFA is enforced for all admin accounts" satisfies: ISO 27001 A.8.5, SOC 2 CC6.1, and PCI DSS Requirement 8. Map your 8 control tests across at least two frameworks each.

6. Define your compliance posture dashboard.

   Design (on paper or in a spreadsheet) what your real-time compliance dashboard would show: overall % controls passing, controls by framework, trend over the last 30 days, open failures by severity, and time-to-remediation metrics. This is what you'd present to the CISO weekly.

7. Identify what stays manual and document the evidence collection process for each.

   For non-automatable controls, write a simplified evidence collection runbook: what to collect, from whom, how often, where to store it, and how to link it to the relevant control in your GRC platform.

Template — CCM Integration Map

System / Tool       | Type              | Data Available via API                          | Controls it can test
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
AWS (IAM + Config)  | Cloud Platform    | IAM users, MFA status, S3 permissions, Config rules| Access ctrl, Encryption, Config mgmt
Okta                | Identity Provider | User MFA enrolment, session policy, app access  | MFA enforcement, Access reviews
GitHub              | Code Repository   | Branch protection, code review requirements     | Change mgmt, Secure SDLC
Tenable / Qualys    | Vuln Scanner      | CVE severity, patch status, age of open findings| Vulnerability management SLA
Jira                | Ticketing         | Incident ticket status, SLA compliance          | Incident response timeliness
Jamf / Intune       | MDM (Laptops)     | Encryption status, OS patch level, AV installed | Endpoint security controls
HR System           | People Data       | Employee onboarding/offboarding dates           | Access revocation, Joiners/Movers/Leavers
  → Manual (no API): Physical security inspections, vendor interviews, policy awareness sign-offs

Template — Automated Control Test Specifications

TEST 1 — MFA Enforcement (Admin Accounts)
Control:        ISO 27001 A.8.5 / SOC 2 CC6.1 / PCI DSS 8.4
Data Source:    Okta API — list all users with admin role
Test Logic:     For each admin user: check mfa_enrolled = true AND mfa_factor_type ≠ SMS
Pass Condition: 100% of admin users have MFA enrolled (non-SMS)
Fail Condition: Any admin user with mfa_enrolled = false OR mfa_factor_type = SMS
Alert Action:   Notify IT Admin within 1 hour; auto-create Jira ticket; CISO if not resolved in 24hrs
Frequency:      Every 6 hours

TEST 2 — S3 Bucket Public Access
Control:        ISO 27001 A.8.9 / SOC 2 CC6.6
Data Source:    AWS Config — S3 bucket ACL and bucket policy
Test Logic:     For each S3 bucket: check block_public_access = true AND no public bucket policy
Pass Condition: Zero S3 buckets with public read or write access
Fail Condition: Any bucket with public access enabled
Alert Action:   Notify DevOps immediately; CRITICAL ticket; CISO notified same day
Frequency:      Every 1 hour

TEST 3 — Critical Vulnerability Patch SLA
Control:        ISO 27001 A.8.8 / SOC 2 CC7.1
Data Source:    Tenable API — CVE severity, discovery date, patch date
Test Logic:     For CVE severity = Critical: (today - date_discovered) must be ≤ 7 days
Pass Condition: All Critical CVEs patched within 7 days of discovery
Fail Condition: Any unpatched Critical CVE older than 7 days
Alert Action:   Daily digest to DevOps Lead; escalate to CISO at day 10
Frequency:      Daily

  → Write TEST 4 (Offboarding: access revoked within 24hrs of HR termination date)
  → Write TEST 5 (Encryption at rest: all RDS instances encrypted)
  → Write TEST 6 (Code review: no direct commits to main branch without PR approval)
  → Write TEST 7 (Laptop disk encryption: 100% of managed devices show FileVault/BitLocker on)
  → Write TEST 8 (Logging: CloudTrail enabled in all AWS regions)

Template — Cross-Framework Control Mapping

Test Name                  | ISO 27001      | SOC 2    | PCI DSS    | NIST CSF 2.0
──────────────────────────────────────────────────────────────────────────────────────────
MFA Enforcement (Admin)    | A.8.5          | CC6.1    | Req 8.4    | PR.AC-7
S3 Public Access           | A.8.9          | CC6.6    | Req 3.5    | PR.DS-1
Critical Vuln Patch SLA    | A.8.8          | CC7.1    | Req 6.3    | DE.CM-8
Offboarding Access Revoke  | A.5.18         | CC6.2    | Req 8.2    | PR.AC-1
Encryption at Rest (RDS)   | A.8.24         | CC6.7    | Req 3.5    | PR.DS-1
Code Review Required (PR)  | A.8.32         | CC8.1    | Req 6.4    | PR.IP-1
  → One test result = evidence across 4 frameworks simultaneously.

Completion Checklist

• CCM Integration Map built for FinTrack's full tech stack
• ISO 27001 / SOC 2 controls categorised as Automatable vs. Manual
• 8 automated control test specifications written (Control → Source → Logic → Pass/Fail → Alert)
• Alert and remediation workflow designed with SLAs and escalation path
• Cross-framework mapping completed (each test mapped to ≥2 frameworks)
• Compliance posture dashboard designed (metrics, trend, open failures)
• Manual controls documented with evidence collection runbook

What changed from CSF 1.1 to CSF 2.0

NIST released Cybersecurity Framework 2.0 in February 2024 — the first major update since the original 2014 release. The biggest change is the addition of a sixth function: Govern (GV). This formalises what was previously implied but not explicit: that security strategy, roles, risk appetite, policy, and supply chain risk management must be governed at the organisational level, not just operationally managed. CSF 2.0 also significantly expands supply chain risk management (C-SCRM) and explicitly scopes the framework for organisations of all sizes — not just critical infrastructure.

CSF 2.0 — The Six Functions

Scenario

Step-by-Step

1. Review your Lab 3 CSF 1.1 scores for HealthBridge.

   Pull up the gap assessment from Lab 3 (or use the template values). These are your baseline scores across the original five functions. You will compare these to your new CSF 2.0 scores to measure 12-month progress.

2. Score HealthBridge on the new GOVERN (GV) function.

   This is entirely new — there is no Lab 3 baseline to compare against. Score each GV category (0–5 maturity scale from Lab 3). For a clinic with no formal security program prior to the ransomware attack, most GV scores will reflect the work done in the past 12 months: policies written (Lab 4), roles assigned, risk appetite defined. Be realistic.

3. Score GV.SC — Supply Chain Risk Management.

   This is the most scrutinised new category in CSF 2.0. For HealthBridge: Do you have a vendor inventory? Are critical vendors assessed (Lab 5 method)? Is there a process for monitoring vendor security posture on an ongoing basis? Are fourth parties (your vendor's vendors) considered? Score each sub-category honestly.

4. Re-score the updated Identify (ID) and Protect (PR) functions.

   CSF 2.0 adds ID.IM (Improvement — processes for learning from incidents and improving the program) and restructures PR into cleaner categories including PR.PS (Platform Security — covering secure configuration, software integrity, and technology infrastructure). Score these new sub-categories for HealthBridge.

5. Calculate 12-month progress across all five original functions.

   Compare Lab 3 current scores to your new CSF 2.0 scores for the same categories. Calculate the delta (improvement). Which functions improved the most? Which are still lagging? Present this as a before/after comparison table.

6. Identify the top 5 new gaps introduced by CSF 2.0.

   Some gaps will be genuinely new — things CSF 1.1 didn't ask about that CSF 2.0 now explicitly requires (e.g., a formal risk appetite statement under GV.RM, a supply chain risk management plan under GV.SC). List the top 5 new gaps not in your Lab 3 assessment.

7. Update the 12-month roadmap from the Capstone (Lab 10).

   Add the new CSF 2.0 gaps to FinTrack / HealthBridge's roadmap. Prioritise GV.SC (supply chain risk) and GV.RM (risk strategy formalisation) — these are the areas auditors and regulators are paying the most attention to in 2025–2026.

Template — CSF 2.0 Gap Assessment (GV Function)

Function | Category                              | Current (0-5) | Target | Gap | Priority | Evidence / Notes
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
GOVERN
GV       | GV.OC – Organisational Context         |       1       |   3    |  2  |  HIGH    | Stakeholders partially mapped; no formal context review
GV       | GV.RM – Risk Management Strategy        |       1       |   3    |  2  |  HIGH    | No documented risk appetite or tolerance thresholds
GV       | GV.RR – Roles & Responsibilities       |       2       |   3    |  1  |  MED     | IR roles assigned (post-incident); not formally documented
GV       | GV.PO – Policy                          |       2       |   3    |  1  |  MED     | AUP + ISP written (Lab 4); 4 further policies outstanding
GV       | GV.OV – Oversight                       |       1       |   3    |  2  |  HIGH    | No Board-level security reporting cadence established
GV       | GV.SC – Supply Chain Risk Mgmt          |       0       |   3    |  3  |  HIGH    | No vendor inventory; no third-party risk process
  → GV.SC is the biggest new gap for most organisations. Treat it as High priority.

12-MONTH PROGRESS (CSF 1.1 vs CSF 2.0 comparable functions)
Function | Lab 3 Score (CSF 1.1) | New Score (CSF 2.0) | Delta | Trend
──────────────────────────────────────────────────────────────────────────────
IDENTIFY |       0.8             |        1.9          |  +1.1 |  ↑↑
PROTECT  |       0.7             |        2.1          |  +1.4 |  ↑↑
DETECT   |       0.4             |        1.2          |  +0.8 |  ↑
RESPOND  |       1.0             |        2.4          |  +1.4 |  ↑↑
RECOVER  |       1.1             |        2.2          |  +1.1 |  ↑↑
GOVERN   |       N/A             |        1.2          |   N/A |  NEW
  → Overall average: 1.83 / 5.0 — progress from 0.8 baseline. Target: 3.0 in 12 months.

Template — Top 5 New Gaps (CSF 2.0 only)

New Gap                              | CSF 2.0 Ref | Why it matters                                    | Priority
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
No formal risk appetite statement    | GV.RM-01    | Without one, risk decisions are inconsistent       | HIGH
No supply chain risk management plan | GV.SC-01    | Vendors are a primary attack vector (SolarWinds)  | HIGH
No Board security reporting cadence  | GV.OV-01    | Board cannot provide oversight without visibility  | HIGH
No improvement tracking from incidents| ID.IM-01   | Lessons Learned not feeding back into controls     | MEDIUM
Platform security baseline undefined | PR.PS-01    | No secure config standard for servers/cloud        | HIGH
  → These 5 gaps should all feed into the updated 12-month roadmap (Lab 10 Capstone).

Completion Checklist

• Lab 3 CSF 1.1 baseline scores reviewed and noted for comparison
• All 6 GOVERN categories scored (GV.OC through GV.SC)
• GV.SC supply chain risk scored with specific vendor process findings
• Updated ID and PR categories scored (including ID.IM and PR.PS)
• 12-month progress comparison table completed (CSF 1.1 vs CSF 2.0)
• Top 5 new CSF 2.0 gaps identified and prioritised
• Lab 10 roadmap updated to include new CSF 2.0 gap remediation milestones

Which framework should I start with?