IT Staff Content Layer — Fundamental Controls Pages

Design specification for the isms-it-staff SCM variant across all Fundamental Control pages. This covers what additional content IT Operations engineers see that all-staff users do not, how to structure it, and the design principles that keep each page coherent across audiences.

Design philosophy: what the IT staff layer is and is not

The all-staff layer on each FC page answers three questions for every reader: what does this control mean, what does it require of me personally, and what do I do if something goes wrong. That layer is complete in itself — an all-staff user can read it, understand their obligations, and act on them without being confused by technical content that is not relevant to them.

The IT staff layer answers a different set of questions: how is this control technically implemented, what am I responsible for configuring and maintaining, what evidence do I need to produce, and what do I do when the mechanism fails. It is additive — it appears below the all-staff content on the same page, visible only to the isms-it-staff and isms-security SCM groups.

The layer is not a repeat of the all-staff content in more technical language. It is genuinely different content that could not appear in the all-staff layer without either overwhelming non-technical readers or, more dangerously, disclosing implementation details that provide meaningful attack surface information to someone with malicious intent who has internal access to Confluence.

SCM layer implementation — technical mechanics

Before specifying content, the mechanics of how the layers work within Scroll Content Manager:

PAGE STRUCTURE (all five Fundamental Controls pages follow this pattern):

[All-staff content — no SCM wrapper]
  Visible to: isms-all-staff, isms-it-staff, isms-security, isms-management
  Contains: framework context, user obligations, what to do if wrong

{scroll-content:variant=isms-it-staff}
  [IT staff content — visible only to isms-it-staff and isms-security]
  Contains: technical implementation, procedures, evidence generation
{scroll-content}

{scroll-content:variant=isms-security}
  [Security team content — visible only to isms-security]
  Contains: evidence currency dashboards, assessor prep, POA&M templates
{scroll-content}

[Page footer — no SCM wrapper]
  Visible to all: where to go next table, version history

VARIANT HIERARCHY (SCM inheritance):
  isms-security inherits isms-it-staff content automatically if configured
  OR: wrap IT staff content in isms-it-staff; security staff see both their 
  own variant AND the isms-it-staff variant because isms-security is a superset

The content in this document covers only the isms-it-staff layer. The isms-security layer (evidence dashboards, assessor preparation, MITRE ATT&CK mapping, POA&M templates) has been covered separately in the security team content specification.

Universal IT staff layer structure — applies to all FC pages

Every FC page's IT staff layer follows the same structural template. This consistency means an IT Operations engineer who reads one FC page knows exactly where to look in any other. It also means assessors who navigate from the all-staff content down the page can find the technical evidence references in a predictable location.

IT STAFF LAYER STRUCTURE (per FC page):

Banner: [IT Staff layer — isms-it-staff and isms-security only]
  Brief statement of scope separation from all-staff content

Section A: Framework implementation summary
  Table: control reference → specific requirement → how implemented → evidence item
  Cross-reference to the AT-[family] advanced control page for full detail

Section B: Platform-by-platform technical procedures
  Per control function: Windows, macOS, Linux, network, cloud
  Configuration specifications with actual command/policy references
  Verification commands (how to confirm the control is working)

Section C: Failure detection and response
  What a failure looks like technically (not just "call IT Operations")
  Automated alerting configuration
  First-response steps before CISO is called

Section D: Evidence generation
  What to produce, when, how, and where to file it
  Specific evidence item IDs (EV-D##, EV-F##)
  Production commands/exports where applicable

Section E: Maintenance schedule
  Daily, weekly, monthly, quarterly, annual tasks for this control
  Who does each task (IT Operations / IT Manager / Security Analyst)
  Dependencies on other FC controls

FC-01 · Firewalls and Network Security — IT staff layer content

Implements: SC.L1-3.13.1, SC.L1-3.13.5, AC.L1-3.1.20, CE Firewalls, DEFSTAN P0–P1 §Boundary

What IT staff need beyond the all-staff content

All-staff readers know: use the VPN, do not use personal hotspots, report blocked sites. They do not need to know how the firewall is configured or how zones are separated.

IT staff need:

Section A — Framework implementation table: A concise mapping of the three CMMC Level 1 practices to the specific technical mechanisms that implement them, so that an engineer working on a firewall change understands which compliance obligation they are affecting.

CMMC Practice	Implemented by	Evidence
SC.L1-3.13.1 — Monitor, control, protect comms at boundaries	Perimeter firewall stateful inspection; zone model (VLANs 10/20/30/40/50); IDS/IPS inline at perimeter and Zone 2→Zone 3 boundary	EV-F03 (rule review), EV-D19 (config baseline), EV-F01 (boundary events in SIEM review)
SC.L1-3.13.5 — Subnetworks for publicly accessible components	DMZ (VLAN 10) physically or logically separated from Zone 2 (VLAN 20) and Zone 3 (VLAN 30) by firewall policy; no direct Zone 1→Zone 3 routing	Network architecture diagram in AT-SC-BDY
AC.L1-3.1.20 — Verify and control external connections	External connection register in EV-D19; all external connections documented with source, destination, protocol, auth method, and business owner	EV-D19 external connection register

Section B — Technical procedures (what distinguishes IT staff content): The full technical configuration specifications already documented in the FC-01 IT Staff Technical Procedures document. On the Confluence page, this section is a summary with a link to the full technical procedure document, plus the specific commands IT Operations engineers need on a day-to-day basis:

Zone model — VLAN IDs, subnets, trust levels, what lives where
Switch hardening commands — BPDU Guard, DHCP Snooping, Dynamic ARP Inspection, 802.1X per port
Firewall rule naming convention (mandatory: [ACTION]-[SOURCE-ZONE]-[DEST-ZONE]-[SERVICE]-[PURPOSE])
The default deny rule confirmation command
VPN split tunnelling verification: curl https://ipinfo.io/ip returns corporate IP when VPN is connected
External connection register — what fields are mandatory, where it lives (EV-D19), what triggers an update

Section C — Failure detection: - What a firewall log gap looks like in SIEM (EV-F06 alert: no events from firewall in past 60 minutes) - What to do when the default deny rule is not logging (Critical — enable immediately; no RFC required; document the emergency action in EV-D21 within 24 hours) - What to do when an unexpected open port is found in an external port scan (Emergency RFC; temporary deny rule in front of the affected port; CISO notified within 2 hours)

Section D — Evidence generation for this control:

Evidence ID	What to produce	How often	Command/export
EV-F03	Firewall rule review	Every 6 months (H1: April, H2: October)	Rule base export + SHA256 hash; diff against prior; 9-check review procedure
EV-D19	External connection register + network baseline	Annual + on architecture change	Manual document; CISO sign-off
EV-D21	Change management records (RFCs)	Per firewall change	ITSM RFC with SIA

Section E — Maintenance schedule specific to FC-01:

Weekly:
  □ Review SIEM alert queue — boundary-related alerts
  □ Any new external connections made this week not in EV-D19?

Monthly:
  □ EV-F01 boundary section — Zone 2→Zone 3 denies, after-hours Zone 3 access
  □ EV-F04 IDS/IPS alert review

Six-monthly:
  □ EV-F03 — full firewall rule review (H1 April, H2 October)

Annually:
  □ EV-D19 — full network baseline review including external connection register

FC-02 · Secure Configuration — IT staff layer content

Implements: AC.L1-3.1.22, CE Secure Configuration (all 5 requirements), DEFSTAN P0 §Secure Configuration

What IT staff need beyond the all-staff content

All-staff readers know: do not install software without approval, do not change security settings, do not put CUI on public systems.

IT staff need the technical specifics of how those restrictions are enforced and how they are verified.

Section A — Framework implementation table:

CE Requirement	Technical enforcement	Verification command	Evidence
Req 1: Only necessary software installed	MDM/Intune software restriction; WDAC policy on servers; Jamf restriction on macOS; apt repository lockdown on Linux	MDM: Intune Discovered Apps report; macOS: Jamf smart group "Apps not in approved list"	EV-D20 quarterly config audit
Req 2: Default passwords changed	LAPS v2 for Windows; vendor checklist for network devices	`Get-LapsADPassword -Identity [computer] -AsPlainText`; attempt default credential on sample network device	EV-D20 (Check 2 — default credential verification)
Req 3: Unnecessary accounts removed	GPO: Guest disabled; DefaultAccount disabled; inactive accounts suspended after 90 days	`Get-LocalUser` on sample devices; ACS quarterly review	EV-D20 (Check 4), EV-D01 quarterly
Req 4: Auto-update enabled	Intune Update Ring — 0-day deferral Ring 0; escalating deferral through Rings 1–4; macOS MDM `AutomaticUpdateInstall: true`	`Get-WUHistory` — check cumulative update within SLA of Patch Tuesday	EV-D07 patch register; EV-D20 (Check 5)
Req 5: Firewalls block unapproved access	GPO: `DefaultInboundAction: Block` all three profiles; macOS MDM: `BlockAllIncoming: true; EnableStealthMode: true`	`Get-NetFirewallProfile \| Select Name, Enabled, DefaultInboundAction`	EV-D20 (Check 6 — personal firewall verification)

Section B — Technical procedures:

The quarterly configuration audit (EV-D20) is the primary IT staff deliverable for this control. The procedure specifies: - CIS-CAT Pro — which benchmark and profile per OS type (BL-WIN11 → CIS_Windows_11_Benchmark_[version]-L1; BL-UBUNTU → CIS_Ubuntu_Linux_22.04_Benchmark_[version]-L1) - Six CE-specific checks beyond CIS-CAT Pro (software inventory, default credentials, EOL, unnecessary accounts, auto-update, public system review) - Three DEFSTAN-specific checks (baseline currency, network device defaults, unnecessary services) - How to handle the publicly accessible system review (AC.L1-3.1.22 — web crawl procedure, cloud public access block verification commands)

The configuration baselines (BL-[PLATFORM]) are referenced and linked from this section — not repeated. IT staff who need the full baseline go to AT-CM.

Section C — Failure detection: - MDM non-compliance alert: device appears in the CUI-Scope-NonCompliant Intune smart group. Response: investigate via Intune device details → check specific failed compliance rules → remediate within 5 days for standard violations; 24 hours for firewall disabled - CIS-CAT Pro score drops below 80% on a CUI-scope system: ITSM ticket → investigate deviation → restore or document exception in EV-D08 - Unapproved software detected in MDM discovered apps report: ITSM ticket → remove within 5 business days → investigate install path (if installed by non-IT user, potential policy breach for HR involvement)

Section D — Evidence generation:

Evidence ID	What	How often	Notes
EV-D19	Baseline configuration documents (BL-[PLATFORM] × 6)	Annual + on major OS/CIS release	IT Manager sign-off; version-controlled in Confluence page history
EV-D20	Quarterly configuration audit (CIS-CAT Pro output + 6 CE checks + 3 DEFSTAN checks)	Quarterly	All findings → EV-D08 within 5 business days
EV-D08	Configuration exception register	Per exception	CISO signature for Critical/High risk exceptions
EV-D22	Asset register — EOL flag field	Quarterly reconciliation	Monthly EOL flag check

FC-03 · User Access Control — IT staff layer content

Implements: AC.L1-3.1.1, AC.L1-3.1.2, IA.L1-3.5.1, IA.L1-3.5.2, CE UAC (all 5 requirements), DEFSTAN P0 §Access

What IT staff need beyond the all-staff content

This is the busiest FC page for IT staff content because user access control is the control domain with the most operational procedures — the JML process fires with every hire and departure, and the quarterly privileged account review is one of the most time-intensive recurring evidence items.

Section A — Framework implementation table:

CMMC Practice	Specific implementation	Key date relationship	Evidence
AC.L1-3.1.1 — Authorised users, processes, devices only	JML process with screening gate; every account creation has a corresponding ITSM ticket with HR screening completion date	Screening completion date in EV-B08 MUST precede account creation date in EV-D03 — this is the most tested date relationship across all three frameworks	EV-D03 JML log
AC.L1-3.1.2 — Authorised transactions and functions only	RBAC via Active Directory security groups; role profile matrix in JML log; no direct ACL assignment (groups only)	Review quarterly in EV-D01	EV-D01, EV-D02
IA.L1-3.5.1 — Identify users, processes, devices	UPN format: firstname.lastname@[domain]; no shared accounts; device naming convention: WS-[DEPT]-[ASSET#]	—	EV-D03
IA.L1-3.5.2 — Authenticate before access	CA-002 Conditional Access: all users, all apps, all locations, no bypass; CA-003 legacy auth block; FGPP: 16 char minimum	—	EV-D05, EV-D19

Section B — Technical procedures:

Four distinct procedure blocks, each with the implementation specifications IT staff need to operate:

Block 1 — JML workflow specifics:

JOINER PROCEDURE (10 steps — abbreviated reference):
  Prerequisite gate: HR confirms screening completion in EV-B08 first
  Step 1: ITSM ticket with screening reference number
  Step 2: Create Entra ID/AD account (UPN format: firstname.lastname@[domain])
  Step 3: Assign access groups per role profile matrix
  Step 4: Configure MFA — Authenticator app minimum; FIDO2 if privileged
  Step 5: Issue access card (ACS — aligned with FC-06)
  Step 6: Enrol device in MDM if not pre-enrolled
  Steps 7–10: [link to full FC-03 IT Staff Technical Procedures]

  DATE THAT MUST BE RECORDED IN EV-D03:
    HR screening completion date (from EV-B08 reference)
    Account creation date
    The screening date must be earlier — this is tested by every framework

LEAVER PROCEDURE (9 steps — most time-critical):
  Step 1: IT Manager receives HR notification (triggers the SLA clock)
  Step 2: Disable Entra ID / AD account SAME DAY
           Note: disable (not delete) — preserves audit trail
  Step 3: Revoke MFA — remove all authentication methods
  Step 4: Remove from VPN group (VPN-Users)
  Step 5: Deactivate ACS card — Facilities Manager
  Step 6: Sign out of all active sessions: Revoke-MgUserSignInSession
  Step 7: Transfer data custody to line manager
  Step 8: Pre-departure SIEM review — EV-F01 note
  Step 9: CISO signs EV-D04 leaver checklist

  SIEM review at Step 8 — what to look for:
    Unusual volume of file access or downloads in the 30 days before departure
    Connections to personal cloud storage (Dropbox, personal OneDrive, Google Drive)
    Connections to competitor IP ranges or unusual external destinations
    Any failed MFA events suggesting the account was being tested for exfiltration

Block 2 — Privileged account management:

DUAL-ACCOUNT MODEL:
  Standard account: firstname.lastname@[domain]
    Used for: email, browsing, standard applications, Teams
    Must NOT have: local admin rights, group membership in privileged groups

  Admin account: adm-firstname.lastname@[domain]
    Used for: system administration, server management, network device access
    Must NOT have: email configured (no mailbox)
    Must NOT be used for: browsing, Teams, personal applications

PAM CONFIGURATION:
  All privileged actions via PAM session checkout — no direct login to CUI servers
  Session recording: enabled for all privileged sessions
  Break-glass accounts: in PAM vault; require both CISO and IT Manager to check out

QUARTERLY EV-D01 — the checks IT staff must run:
  PowerShell to confirm no standard account in Domain Admins:
    Get-ADGroupMember "Domain Admins" | Where-Object {$_.SamAccountName -notlike "adm-*"}
    Expected: zero results

  PowerShell to confirm no admin account has a mailbox:
    Get-ADUser -Filter {SamAccountName -like "adm-*"} -Properties mail |
    Where-Object {$_.mail -ne $null}
    Expected: zero results

  PowerShell to confirm LAPS is functioning (no blank local admin passwords):
    Get-LapsADPassword -Identity [sample-computers] -AsPlainText
    Expected: all return a complex generated password

Block 3 — Conditional Access policy verification:

FOUR CA POLICIES — verify each quarterly in EV-D05:

CA-001: Admin MFA — all sign-ins
  Check: any adm-* account sign-in without FIDO2 in past 30 days?
  SIEM query: sign-in logs where userPrincipalName starts with "adm-" 
              AND authenticationRequirement != "multiFactorAuthentication"
  Expected: zero results

CA-002: User MFA all access
  Check: any sign-in to CUI-scope app without MFA satisfied?
  SIEM query: sign-in logs where conditionalAccessStatus = "success" 
              AND mfaDetail = null AND appDisplayName in [CUI app list]
  Expected: zero results

CA-003: Block legacy authentication
  Check: any successful legacy auth events?
  SIEM query: sign-in logs where clientAppUsed in 
              ("Exchange ActiveSync", "POP3", "IMAP4", "MAPI", "Other clients")
              AND status = "success"
  Expected: zero results (not just "low" — zero)

CA-004: Break-glass exclusion
  Check: any break-glass sign-in in past quarter?
  Expected: zero (break-glass sign-in generates immediate SIEM Critical alert)

FGPP VERIFICATION (for EV-D20 quarterly config audit):
  Get-ADFineGrainedPasswordPolicy -Identity FGPP-Standard-Users
  Expected values:
    MinPasswordLength: 16 (CE Requirement 4 minimum)
    PasswordHistoryCount: 24
    LockoutThreshold: 5
    LockoutDuration: 00:15:00

Block 4 — DEFSTAN contract-specific access controls:

When a DEFSTAN contract requires named personnel access to OFFICIAL data:
  Create contract-specific group: GRP-CONTRACT-[MOD-REF]-Access
  Membership changes require CISO approval (not just IT Manager)
  Record in EV-D03 with contract reference in Notes field

  Quarterly DEFSTAN check within EV-D01:
    Cross-reference GRP-CONTRACT-[MOD-REF]-Access membership against EV-B03
    (SC/DV clearance register)
    Any member whose clearance has lapsed: remove immediately; notify CISO;
    CISO notifies contracting authority (DEFSTAN 5-day notification requirement)

Section D — Evidence generation:

Evidence ID	Production trigger	Command/process	Filed at
EV-D03	Every joiner and mover event	ITSM ticket reference + AD account creation date + HR screening date	EV-D → Access Control → JML Log
EV-D04	Every leaver event	Three-section checklist; CISO sign-off within 5 business days	EV-D → Access Control → JML Log → Leavers
EV-D01	Quarterly	PowerShell exports + HR cross-reference; CE and DEFSTAN checks; IT Manager sign-off	EV-D → Access Control Reviews → Privileged [YYYY-QQ]
EV-D05	Quarterly	CA policy review (six checks); Entra ID MFA registration report export	EV-D → Access Control → MFA Status Report → [YYYY-QQ]

FC-04 · Malware Protection — IT staff layer content

Implements: SI.L1-3.14.2, SI.L1-3.14.4, SI.L1-3.14.5, CE Malware (all 5 requirements), DEFSTAN P0–P1 §Malware

What IT staff need beyond the all-staff content

Section A — Framework implementation table:

CMMC Practice	Location deployed	Update mechanism	Scheduled scan	Evidence
SI.L1-3.14.2 — Protection at appropriate locations	Endpoints (Windows/macOS/Linux); email gateway; web proxy; DNS filter; mobile MDM compliance	See 3.14.4 below	See 3.14.5 below	EV-D32 monthly
SI.L1-3.14.4 — Update mechanisms when new releases available	Windows: Windows Update / MDE cloud; macOS: vendor cloud every 4h; Linux: freshclam 24 checks/day; email gateway: continuous	SIEM alert: signatures >24h old on any CUI-scope device	—	EV-D32 Section B: signature currency %
SI.L1-3.14.5 — Periodic scans + real-time scans	Scheduled: weekly Sunday 02:00 (Windows/macOS/Linux); Real-time: on all file access (Windows IoavProtection + BehaviorMonitor; macOS Full Disk Access required for scope)	—	Confirm: `Get-MpComputerStatus \| Select LastQuickScanTime, LastFullScanTime`	EV-D32 Section C: scan completion %

Section B — Technical procedures (the critical IT staff operational content):

The most operationally critical single item in this section:

EICAR TEST PROCEDURE (quarterly on sample devices of each OS type):

Purpose: confirms real-time scanning is active and functioning
Evidence: document in EV-D20 quarterly config audit

EICAR string (save as eicar.com and as eicar.txt):
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Before running:
  Notify Security Analyst — the test generates a SIEM alert
  Confirm SIEM alert will not trigger incident response activation
  Note the start time

Windows test:
  Open Notepad → paste EICAR string → Save As eicar.com to Desktop
  Expected: AV alert fires within 5 seconds; file quarantined
  If file saves without alert: real-time protection NOT active — Critical finding

  Verify tamper protection while testing:
    Settings → Windows Security → Real-time protection → try to toggle Off
    Expected: toggle is greyed out or immediately returns to On

    From PowerShell (standard user account):
    Set-MpPreference -DisableRealtimeMonitoring $true
    Expected: Access Denied or error 0x800704EC

macOS test:
  Terminal: echo 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' \
  > /tmp/eicar-test.com
  Expected: file blocked on write or immediately quarantined
  Verify Full Disk Access granted:
    System Settings → Privacy & Security → Full Disk Access → [EDR agent]: ✓

Document result in EV-D20:
  "EICAR test conducted [date] on [device] [OS] by [engineer].
   Real-time detection: CONFIRMED. Time to detection: [N] seconds.
   SIEM alert generated: Yes. Tamper protection: CONFIRMED (toggle greyed)."

Additional IT staff procedure content:

Platform-specific agent deployment verification commands (per OS)
What to check when EV-D32 Section A shows coverage below 100% (reconciliation against EV-D22)
Signature update failure response (single device P3 vs multiple devices P2 vs persistent failure escalation)
AV exception management — how to request, who approves (IT Manager for all; CISO additionally for path exclusions), where the exception register lives (EV-D19 supplementary), 90-day review clock

Section C — Malware incident response (Class 1 and Class 2 only — Class 3 and 4 go to AT-IR):

CLASS 1 — Confirmed detection, automatic remediation:
  AV quarantined a file; no execution confirmed
  Action: verify quarantine; confirm no file access; log in EV-D32 Section D
  No escalation required if all below apply:
    File was quarantined before execution (IoavProtection fired, not BehaviorMonitor)
    No lateral movement indicators in SIEM
    No persistence mechanism detected (no new scheduled tasks, registry autorun, services)

CLASS 2 — Execution suspected (STOP — escalate immediately):
  Trigger: process injection alert; encoded PowerShell; ransomware behaviour;
           behavioural detection (BehaviorMonitor, not just signature)

  Phase 1 — Evidence preservation BEFORE isolation (5 minutes):
    SIEM: export all events for the device from past 24 hours NOW
    (This data may be unavailable or harder to retrieve post-isolation)
    EDR console: screenshot the alert timeline and process tree

  Phase 2 — Isolate (MDE remote isolation preferred — does not require physical access):
    Security.microsoft.com → Assets → Devices → [device] → Actions → Isolate device
    Select: Full isolation
    Reason: "Malware Class 2 — [brief description]"
    Confirm: device shows "Isolated" in console

  Phase 3 — CISO notification (call, not email):
    One sentence: "[Device] isolated — suspected code execution — [alert type]"

  Full investigation and remediation: AT-IR procedure takes over from here
  Create EV-D12 incident record immediately

Section D — Evidence generation:

Evidence ID	What	When	How
EV-D32	Monthly AV/EDR coverage report (6 sections)	By 7th of each month	EDR console export + email gateway stats + proxy stats; Security Analyst + CISO sign-off
EV-D20	Quarterly config audit — AV settings section	Quarterly	`Get-MpComputerStatus` batch run; EICAR test result; MDM compliance group check
EV-D12	Malware incident record	Per Class 2+ incident	Opened at detection; closed when PIR complete

FC-05 · Patch Management — IT staff layer content

Implements: SI.L1-3.14.1, CE Patch Management (all 4 requirements), DEFSTAN P0 §Patching

What IT staff need beyond the all-staff content

Section A — Framework implementation table:

This page requires the single most critical piece of operational knowledge across all FC pages. It must appear prominently in the IT staff layer, not buried in a subsection:

⚠ CRITICAL — THE SLA CLOCK STARTS AT VENDOR RELEASE DATE, NOT DETECTION DATE ⚠

Every assessor — C3PAO, CE+, DEFSTAN — will cross-reference entries in EV-D07
against NVD. They will:
  1. Take the CVE reference from your register
  2. Go to nvd.nist.gov/vuln/detail/CVE-[ID]
  3. Read the "Published" date
  4. Add your SLA days to that date
  5. Compare to your Actual Remediation Date

If your SLA Deadline column in EV-D07 was calculated from the date your
scanner detected the vulnerability rather than the NVD Published date,
your compliance percentage is wrong — and lower than you calculated.

SLA table (from vendor release date):
  Critical (CVSS 9.0–10.0): 7 calendar days
  High (CVSS 7.0–8.9): 14 calendar days
  Medium (CVSS 4.0–6.9): 30 calendar days
  Low (CVSS 0.1–3.9): 90 calendar days
  CISA KEV (any CVSS): 7 calendar days from KEV publication, regardless of CVSS

Section B — Technical procedures:

Block 1 — EV-D07 patch register field discipline:

The IT staff layer must make explicit what goes in each critical field — because the register is only evidentially valuable if every field is correct:

VENDOR RELEASE DATE — how to find it (mandatory field, never blank):
  Source: NVD — nvd.nist.gov/vuln/detail/CVE-[ID]
  Field to read: "Published" date in the vulnerability detail header

  For Microsoft patches (Patch Tuesday):
    Source: msrc.microsoft.com/update-guide
    Use the release date of the specific KB article, not the scan date

  NEVER use as vendor release date:
    × The date your scanner detected the CVE
    × The date you opened the ITSM ticket
    × The date the maintenance window was scheduled
    × The date you became aware of the advisory

WEEKLY EV-D07 REVIEW — what IT Manager checks every Monday:
  1. Any Critical entry with SLA deadline within the next 7 days?
     → Confirm patch is scheduled; escalate if no maintenance window booked
  2. Any Critical entry past SLA deadline with no EV-D08 exception reference?
     → This is an unmanaged breach — create exception immediately; notify CISO
  3. Any High entry within 5 days of deadline?
     → Flag to IT Manager for escalation
  4. Any CISA KEV entry opened this week?
     → Within 24h: targeted scan initiated; CISO notified

QUALITY CHECK (run before any assessment):
  PowerShell / ITSM query:
    Any entry where "Vendor Release Date" field is blank → fix before assessment
    Any entry where SLA Deadline = Detection Date + SLA days → wrong; recalculate
    Any Critical entry past SLA Deadline with no EV-D08 reference → unmanaged gap
    Any CISA KEV entry without CISA-KEV flag → add flag; confirm 7-day SLA applies

Block 2 — Ring deployment reference:

RING STRUCTURE (for Intune Update Ring policies):
  Ring 0: IT Operations devices — 0-day deferral — observe 48h before Ring 1
  Ring 1: Early adopters (10%) — 3-day deferral — observe 24h before Ring 2
  Ring 2: Standard wave 1 (40%) — 6-day deferral
  Ring 3: Standard wave 2 (remaining workstations) — 8-day deferral
  Ring 4: CUI servers — 10-day deferral — RFC required for each deployment

  CRITICAL SLA COMPRESSION (for 7-day Critical patches):
    Ring 0+1: Day 1 (same day as patch release)
    Ring 2+3: Day 2 (confirm Ring 0+1 no issues in the morning first)
    Ring 4 (CUI servers): Day 3 — Emergency maintenance window — CISO authorises

  RING 0 OBSERVATION CHECKLIST (before proceeding to Ring 1):
    □ All Ring 0 devices show patch installed in Intune
    □ Zero Ring 0 devices show install failure
    □ No Ring 0 engineers reported application failures (check ITSM past 48h)
    □ Event Log sample: no Critical errors post-patch on Ring 0 device
    □ SIEM: no anomalous events from Ring 0 devices in past 48h
    All checked: proceed to Ring 1
    Any failed: see rollback procedure

Block 3 — CISA KEV response procedure (step by step):

TRIGGER: new entry in CISA KEV catalogue affecting technology in scope
(SIEM alert or security analyst daily check)

Step 1 — Verify applicability (within 4 hours):
  Query EV-D22 (asset register): search by affected product name and vendor
  Query EDR software inventory: [EDR console] → Assets → Software → [product name]
  Query approved software list (AT-CM): is this product on our list?

Step 2 — Create EV-D07 entry (same day):
  CVE: [CVE-ID]
  Severity: "Critical — CISA KEV Override" (even if CVSS is lower)
  Vendor Release Date: KEV Publication Date (from cisa.gov/known-exploited-vulnerabilities)
  SLA Deadline: KEV Publication Date + 7 days
  CISA KEV: Yes

Step 3 — Initiate targeted scan (within 24 hours):
  Scanner scope: only systems identified in Step 1
  Plugin: specific plugin for this CVE (scanner plugin ID from vendor advisory)
  File as: EV-D06 triggered scan "KEV-[CVE-ID]-[YYYY-MM-DD]"

Step 4 — Patch or mitigate (within 7 days of KEV publication):
  Patch available: compressed ring deployment (Step 1 and 2 combined — day 1)
  No patch yet: vendor workaround + EV-D08 exception + compensating controls:
    Specific network isolation rule (not generic monitoring)
    SIEM detection rule for this specific CVE's exploitation signatures
    CISO sign-off on the exception entry

Step 5 — Close EV-D07 entry:
  Actual Remediation Date, Days to Remediate, Verified By
  Notify CISO of closure

Block 4 — EOL software management:

MONTHLY EOL FLAG CHECK (from EV-D22 asset register):

Windows OS EOL dates:
  Windows 10 all editions: 14 October 2025 — ANY device still running 
  Windows 10 in CE/DEFSTAN/CMMC scope after this date is a FINDING
  Windows 11 22H2: check microsoft.com/lifecycle for current dates

EOL detection commands:
  PowerShell (Windows — check from scanner or against EV-D22):
    Get-WmiObject Win32_OperatingSystem | Select-Object Caption, BuildNumber
    Cross-reference against: learn.microsoft.com/lifecycle/products

  Linux:
    lsb_release -rs  (compare against ubuntu.com/about/release-cycle)

  Applications (for each in approved software list):
    Check: endoflife.date/[product] for current support status

ACTION when EOL flagged:
  Within 5 business days: upgrade plan to IT Manager
  At EOL date with no upgrade: EV-D08 exception required
    CE: device must be removed from CE scope (no acceptable exceptions)
    DEFSTAN: compensating controls; upgrade plan with date; CISO sign-off
    CMMC: POA&M entry; remediate within 90 days for High-risk systems

Section D — Evidence generation:

Evidence ID	What	When	Notes
EV-D06	Vulnerability scan reports	Monthly (Tier 1) + weekly (Tier 2) + triggered (KEV)	Raw output + executive summary; authenticated scan confirmed
EV-D07	Patch tracking register	Continuous (24h after each scan); weekly IT Manager review	Vendor release date must come from NVD; not the detection date
EV-D08	Exception register	Per exception	CISO signature for Critical/High; monthly review note
EV-F02	Monthly security metrics — patching section	By 10th of each month	Compliance % from vendor release date; MTTR by severity; KEV closure rate

Section E — Maintenance schedule for FC-05:

Daily:
  □ CISA KEV check — any new entries affecting our software? (SIEM alert or manual)
  □ EV-D07: any new KEV entries created today?

Weekly (Monday morning before IT Manager review):
  □ EV-D07 quality check: blank vendor release dates? Wrong SLA calculations?
  □ EV-D07 progress notes: add review notes to all Critical and High open entries
  □ Internet-facing system scan (Sunday 02:00 output) — process findings into EV-D07

Monthly:
  □ EV-D06: full authenticated scan (first Tuesday); file within 24h of completion
  □ EV-D07: process all findings within 24h of scan
  □ EV-D08: CISO monthly review of all open exceptions; progress notes updated
  □ EV-F02: patch compliance metrics (by 10th)

Quarterly:
  □ EV-D22: EOL flag check — any new EOL items?
  □ Network device firmware: vendor advisory check for each device in EV-D22
  □ Scanner scope vs EV-D22 reconciliation: any CUI-scope systems not being scanned?

FC-06 and FC-07 — IT staff layer content (summary)

The FC-06 (Physical Protection) and FC-07 (Media Protection) IT staff layers follow the same structure as FC-01 through FC-05. The content distinctive to the IT staff layer is:

FC-06 — Physical Protection: - ACS access group configuration reference (AG-AllStaff-Zone2, AG-ITOps-Zone3, etc.) — which groups exist, what they permit, how IT staff are assigned - Card provisioning procedure (the 5-step process including the PIN generation requirement and the test-before-issue step) - Card deactivation SLA: 1 hour from final working day notification — what to do in ACS console (Status: Inactive, not delete) - Quarterly EV-D23 review procedure — the PowerShell comparison of ACS export against HR export; the Zone 3 access list check - CCTV system access credentials and health check procedure (EV-D29 monthly) - SIEM alert rules for Zone 3 after-hours access — the specific rule syntax

FC-07 — Media Protection: - Media register (EV-D22) maintenance — which fields IT Operations is responsible for maintaining and what triggers an update - Sanitisation procedure per media type — the 8 distinct procedures (HDD reuse, HDD disposal, SSD reuse, SSD disposal, USB, optical, paper, mobile) with the specific tools, methods, and verification steps - Destruction certificate process — the 5-step procedure from preparing the asset list to matching serial numbers on the received certificate to filing EV-D25 - Removable media technical enforcement — the specific GPO path (Computer Configuration → Administrative Templates → System → Removable Storage Access; all settings to Enabled) and the verification test (plug in USB, confirm it does not appear in File Explorer) - USB exception process — when and how IT Operations can grant a time-limited exception, and the hardware ID allowlist method in Intune

Below the security staff SCM layer, the following footer is visible to all IT staff and serves as the primary navigation point for finding more detailed procedures:

IMPLEMENTATION DETAIL — WHERE TO GO NEXT

For deeper technical procedures beyond this page:
  [FC-01] Full firewall configuration: FC-01 IT Staff Technical Procedures
  [FC-02] Full CIS-CAT Pro procedure: FC-02 IT Staff Technical Procedures  
  [FC-03] Full JML workflow: FC-03 IT Staff Technical Procedures
  [FC-04] Full AV deployment spec: FC-04 IT Staff Technical Procedures
  [FC-05] Full patch register procedure: FC-05 IT Staff Technical Procedures
  [FC-06] Full ACS configuration: FC-06 IT Staff Technical Procedures
  [FC-07] Full sanitisation procedure: FC-07 IT Staff Technical Procedures

For the SSP-level control implementations (advanced tier):
  FC-01 → AT-SC-BDY · Boundary Protection
  FC-02 → AT-CM · Configuration Management
  FC-03 → AT-AC · Access Control + AT-IA · Identification and Authentication
  FC-04 → AT-SI · System and Information Integrity
  FC-05 → AT-RA · Risk Assessment + AT-SI · System and Information Integrity
  FC-06 → AT-PE · Physical Protection
  FC-07 → AT-MP · Media Protection

Evidence filing locations:
  All EV-D items: EV-D series (see EV-D filing index on ISMS Home)
  All EV-F items: EV-F · Continuous Monitoring
  Technical procedures: IT Operations Procedures Library (OP-01 through OP-05)

Common design mistakes to avoid

Putting verification commands in the all-staff layer. A PowerShell command showing how to verify firewall settings tells an insider with malicious intent exactly what to check before exploiting a gap. Verification commands belong exclusively in the IT staff layer.

Duplicating all-staff content in the IT staff layer. The IT staff layer adds, it does not repeat. An IT engineer who reads the all-staff layer and then scrolls past a summary of what they just read in the IT staff layer learns nothing new and loses time. Every sentence in the IT staff layer should be content that the all-staff reader cannot see.

Making the IT staff layer a document dump. Linking to seventeen separate documents without explaining which one to use for which situation is not useful. The IT staff layer should contain enough operational context that an engineer can take the correct action from the page itself, with links to full procedures for when they need the detail.

Omitting the evidence generation section. The IT staff layer is where the evidence production responsibility is assigned — not just described. Every FC page's IT staff layer must specify exactly what evidence to produce, by when, using what mechanism, and where to file it. This is what converts a technical procedure into a compliance evidence trail.

Putting DEFSTAN contract-specific content in the general layer. The isms-it-staff layer is visible to all IT Operations engineers. DEFSTAN contract-specific details (which MOD contract, which personnel, which access groups) should be separated within the IT staff layer clearly, so engineers working on non-DEFSTAN contracts are not confused by obligations that do not apply to their work.

IT Staff Content Layer — Fundamental Controls Pages

Design philosophy: what the IT staff layer is and is not

SCM layer implementation — technical mechanics

Universal IT staff layer structure — applies to all FC pages

FC-01 · Firewalls and Network Security — IT staff layer content

What IT staff need beyond the all-staff content

FC-02 · Secure Configuration — IT staff layer content

What IT staff need beyond the all-staff content

FC-03 · User Access Control — IT staff layer content

What IT staff need beyond the all-staff content

FC-04 · Malware Protection — IT staff layer content

What IT staff need beyond the all-staff content

FC-05 · Patch Management — IT staff layer content

What IT staff need beyond the all-staff content

FC-06 and FC-07 — IT staff layer content (summary)

Page-level technical footer (present on all FC pages)

Common design mistakes to avoid