Asset criticality tiering is a business conversation, not a technical one. The security team proposes tiers, but the business defines what "critical" means — a database storing PII is Tier 1 for a healthcare company but potentially Tier 3 for a manufacturing firm. At Ficsit, DC01 and PORTAL-EXT are Tier 1 not because of their technical role alone but because their compromise has immediate material business consequences. Discussion exercise: ask students what tier WIN-LEGACY-01 (the PLC controller) should receive. Most will say Tier 4. The correct answer may be Tier 1 — if that PLC controls physical manufacturing equipment, its availability directly impacts production revenue and potentially worker safety. Context determines criticality, not the IT team's opinion.

Use this section to break the false equivalence between "the scan ran" and "we're secure." Key teaching points: (1) Credentialed vs. uncredentialed — most enterprise scanners default to credentialed, but students entering immature organizations will encounter uncredentialed scans that miss 30–40% of vulnerabilities. Always ask: were these scans credentialed? (2) Coverage gap — a vulnerability on an unscanned host is worse than no scanner at all, because it creates false confidence. (3) False positives — Nessus and similar tools have false positive rates of 5–15%. Teach students not to auto-ticket every finding without verification. (4) Scan timing — weekly scans mean a vulnerability can exist for up to 6 days before it's detected. Continuous agent-based monitoring (EDR telemetry, software inventory agents) fills this gap.

The CVSS calculator uses the official v3.1 formula. Use the scoring exercise to build intuition about which metrics drive the score most: Attack Vector (Network vs. Local) and CIA impact are the two biggest drivers — AV:Network with High CIA across all three hits 9.8 with no Scope change. Students should understand why Scope:Changed pushes scores above 9.0 even when CIA is not all-High: a scope-changed vulnerability compromises resources beyond the vulnerable component itself. Common student error: confusing Privileges Required (PR) with the privilege level required on the target system after exploitation. PR:None means the attacker needs no credentials to trigger the exploit — it does not describe what access they gain once it succeeds.

The KEV table is the fastest way to show students why CVSS alone is an unreliable prioritization signal. All six KEV entries for Ficsit are CVSS 9.0+, which might make it seem like KEV and CVSS agree — they don't always. In real environments you will encounter KEV entries with CVSS 6–7 that outrank CVSS 9s in practice because active exploitation was observed at scale. Use Exercise 3 to drive home the compensating controls discussion: students will often accept "trusted IPs only" at face value. Push them to ask: Is that ACL on the firewall or just the application config? Is it tested? Does it cover all interfaces on the device? Who owns verifying it? A compensating control that hasn't been tested under adversarial conditions is a paper control.

The prioritization queue uses a composite score that weights KEV status, CVSS, asset tier, and age. Students should understand that the score is a decision-support tool, not a substitute for analyst judgment. Two teaching points: First, PORTAL-EXT appears twice in the queue (CVE-2021-44228 and CVE-2024-3400) — one In Progress, one Open. Ask students whether the In Progress patch for one changes their sense of urgency for the other. Answer: No. They are separate vulnerabilities requiring separate fixes; an in-flight patch for Log4Shell does not reduce your exposure to PAN-OS command injection. Second, EXCHANGE-01's CVE-2023-23397 (Outlook NTLM relay, no click required) sits at score 91 despite being on an internal asset — because the preview-pane trigger means every email received is a potential exploit attempt, even from a user who never opens it. Use this to challenge the assumption that internal-only assets are lower urgency.

Ficsit's patch table intentionally includes a Breached entry (CVE-2020-1472 on DC01) and an In Testing entry that is approaching its deadline. Students often focus on the Breached entry; redirect them to also ask why a Tier 1 critical is still in Testing after 19 days when the SLA is 7. The answer: change control approval delays and no expedited lane for KEV-listed CVEs. This is a program design failure, not just a ticket delay. Exercise 3 (verification steps) is frequently skipped in real programs. Push students to name concrete verification actions: run a credentialed scan targeting the specific CVE plugin, review the KB number in the Windows Update history, confirm with the asset owner that no rollback occurred. "Check that it's fixed" is not a verification step.

Risk acceptance is one of the most common real-world VM activities and one of the least taught. Students should understand three things: (1) Risk acceptance is a business decision, not a security team decision — the security team documents the risk, but the approving executive owns it. (2) Every exception must have a hard expiry — open-ended exceptions are how "temporary" workarounds become permanent. Ficsit's WIN-LEGACY-01 exception expires December 2026 but has no committed decommission date; this is the failure mode to watch for. (3) Compensating controls on an exception are meaningless unless they are tested and monitored. Ask students: what happens to the WIN-LEGACY-01 exception if the network isolation VLAN is misconfigured in a firewall rule change? Is there a detection? The honest answer is no — and that gap should be documented in the exception or rejected as a compensating control. Also note CVE-2018-13379 on VPN-BACKUP-01: FortiOS credential exposure with no external access is a believable control, but only if the device is confirmed off the routing table. Students should ask whether "no external access" has been audited recently.

The SLA dashboard surfaces two structural gaps: no automated breach notification, and no escalation chain below CISO level. Exercise 2 (discovery date dispute) is drawn from a real enterprise pattern — asset owners frequently push back on SLA clocks that started before they were notified. The correct answer is that discovery date is the clock start regardless of notification lag, because the vulnerability was exploitable from that date. If you accept the owner's argument, ask: what prevents every owner from delaying acknowledgment by 3–5 days as a de facto SLA extension? The policy fix is explicit language: "SLA commences at scan detection date as recorded in the vulnerability management platform." Exercise 3 should produce varied answers — accept any design that queries days-to-deadline, sets a warning threshold before breach (e.g., T-2 days), and routes to asset owner plus their manager rather than just the VM team alone.

The metrics section is where the lab connects technical VM work to business communication — a skill gap that is consistently cited in enterprise security hiring. Ficsit's numbers are intentionally unflattering: 62% PCR on Tier 1 criticals, 34-day average MTTR against a 7-day SLA, and 6 KEV entries open. Students will want to soften the board summary; push them not to. The board needs the honest picture because they are the ones who approve the headcount, tooling, and process changes required to fix it. The exercise's "no CVE IDs" constraint is intentional — it forces translation. A student who writes "CVE-2020-1472 with CVSS 10.0 on DC01 requires immediate remediation" has not completed the translation. A student who writes "a three-year-old vulnerability in our domain controller authentication system can be exploited without a password, giving an attacker control of every Windows computer in the building" has understood the communication task. Accept both versions but discuss which one moves a board to act.