SCM Security staff config
The isms-security audience sits above both isms-all-staff and isms-it-staff in the SCM hierarchy, and the content it unlocks should serve a genuinely different operational purpose — not more of the same implementation detail, but the assurance, intelligence, and programme governance layer that the security function owns exclusively. Here is the complete design specification for what that layer should contain and where it appears.
The architectural principle before the content list
The three-layer hierarchy has a clean functional separation that should govern every content decision. All-staff content answers "what must I do?" IT-staff content answers "how do I build and operate it?" Security-staff content answers "how do I know it's working, what does an attack look like against it, and what do I do when it fails?" Every piece of security-layer content should serve one of those three questions. If it does not, it belongs on one of the lower layers.
The practical consequence is that security-layer content is predominantly: evidence readiness checklists, control effectiveness indicators, threat intelligence integration, SIEM correlation context, investigation playbooks, assessment preparation guides, and POA&M templates. None of these belong on the IT-staff layer because IT staff implement controls — security staff assure them.
Layer 1: Evidence currency dashboards on every AT-[family] page
The single most valuable addition to the security layer is an evidence currency panel at the top of each AT-[family] page. This panel is invisible to IT staff but immediately visible to the security team. It answers the question "is this family assessment-ready right now?"
The panel for each family contains a table with every evidence item for that family, its required frequency, its last-produced date, its status (Current / Due within 30 days / Overdue), and the Confluence link to the actual evidence. The security analyst reviews this panel monthly and flags any overdue items to the relevant owner.
For AT-AU as an example, the panel shows:
| Evidence ID | Item | Required frequency | Last produced | Status |
|---|---|---|---|---|
| EV-F01 | Monthly SIEM log review | Monthly | [date] | Current |
| EV-F06 | SIEM health report | Monthly | [date] | Overdue |
| EV-D20 | Quarterly config audit | Quarterly | [date] | Due in 12 days |
| EV-D01 | Privileged account review | Quarterly | [date] | Current |
This panel does not duplicate the evidence register already in the page — the evidence register is the reference document saying what evidence exists. The currency panel is the operational status view saying whether that evidence is up to date. The distinction is significant: an evidence register entry for EV-F06 tells IT staff what to produce and how often; the currency panel tells the security analyst that EV-F06 has not been produced this month and someone needs to chase it.
The currency panel is the closest thing this Confluence space has to an audit readiness dashboard for each control family. A C3PAO assessment request arriving with 30 days' notice should produce no surprises if the security team has been maintaining these panels monthly.
Layer 2: Control effectiveness indicators per control
Below each control's implementation description (which IT staff can see), the security layer adds a control effectiveness assessment block. This is a structured quarterly self-assessment that the security analyst completes, asking three questions for each control:
First, the technical test result — did the control pass or fail the most recent spot test from the AT-[family] assessor checklist? For AT-IA 3.5.3 (MFA requirement), this is the result of the last time someone attempted to authenticate to a CUI-scope application without MFA and confirmed the attempt was blocked. For AT-AC 3.1.6 (non-privileged access to security functions), this is the result of the last time a standard user account attempted to access the PAM console and confirmed it was denied.
Second, the evidence completeness rating — is the evidence for this control complete, meaning an assessor could pick up the evidence items listed in the evidence register and independently verify the control is implemented without needing additional documentation? Controls where evidence is incomplete get a yellow rating; controls where evidence is missing get a red rating and a mandatory POA&M entry.
Third, the trend — is the control getting stronger, stable, or weaker compared to the previous quarter? A control with good implementation but a weakening trend (for example, MFA coverage at 98% this quarter but 99.5% last quarter) merits investigation before an assessment discovers it further.
The quarterly control effectiveness assessment across all 110 controls is the internal assessment programme required by NIST 800-171 3.12.1. The security layer makes this assessment integrated into the page structure rather than a separate annual event that the team scrambles to prepare for.
Layer 3: MITRE ATT&CK and threat intelligence integration per family
Each AT-[family] page at the security layer includes a threat context section that maps the controls in that family to the MITRE ATT&CK techniques they are designed to detect or prevent. This content is genuinely only useful to the security team — IT staff implementing the controls do not need to know which ATT&CK technique each SIEM correlation rule is targeting.
For AT-AU (Audit and Accountability), the threat context section shows:
The log review procedure (EV-F01) should specifically look for indicators of the following ATT&CK techniques: T1078 (Valid Accounts — authentication to unusual systems or at unusual times using valid credentials); T1070.001 (Indicator Removal — Windows Event Log cleared events are a direct indicator of log tampering, addressed in the 3.3.4 Windows Event Log cleared alert); T1136 (Create Account — new account creation outside the JML process); T1098 (Account Manipulation — group membership changes, MFA method changes, and access policy modifications); and T1021 (Remote Services — privileged remote connections outside maintenance windows).
For AT-SI (System and Information Integrity), the AV and IDS alert review should specifically correlate with: T1055 (Process Injection — process spawning behaviour that EDR classifies as suspicious); T1059 (Command and Scripting Interpreter — PowerShell Script Block Logging alerts firing in AT-CM baseline); T1190 (Exploit Public-Facing Application — IDS alerts correlated with scanner findings from AT-RA); and T1486 (Data Encrypted for Impact — ransomware indicators detected by EDR or file entropy monitoring).
The value of this content at the security layer is that it gives the analyst reviewing the monthly log review (EV-F01) a threat-informed lens rather than a compliance-checklist lens. The analyst is not just confirming that the log review was done — they are actively hunting for the techniques that the controls are supposed to detect. This is how continuous monitoring (3.12.3) becomes genuinely effective rather than procedural.
Each AT-[family] page at the security layer also includes a current threat intelligence note field — a free-text block updated by the security analyst when NCSC, CISA, or sector-specific intelligence is published that affects the threat picture for that family. For example, when NCSC publishes an advisory about exploitation of a specific VPN product (AT-SC family scope), the security analyst notes the advisory in the AT-SC threat intelligence field, triggers a targeted vulnerability scan within 24 hours (AT-RA 3.11.2 triggered scan procedure), and adds a SIEM correlation rule if indicators of compromise are available (AT-SI 3.14.6).
Layer 4: SIEM correlation rule documentation per family
Every SIEM alert rule that monitors controls in a given family is documented at the security layer of that family's page. IT staff who build and operate the SIEM see the configuration specification. The security layer adds the operational context: what the rule is detecting, which control it monitors, the expected alert rate, the triage procedure, and what a true positive looks like versus a false positive.
For AT-IA, the security layer shows the MFA-specific correlation rules:
Rule: MFA disabled for admin account — Entra ID event: MFA method removed or disabled for an account in an admin role. Control monitored: 3.5.3. Expected rate: zero (admin MFA removal should never happen without a change management record). True positive: an attacker who has compromised an admin account disabling MFA to establish persistent access. Triage: immediately check the change management log (EV-D21) for a corresponding RFC — if none exists, treat as a P1 incident. False positive: none expected (there is no legitimate reason to disable MFA for an admin account outside of a documented access review).
Rule: Legacy authentication success — Entra ID event: successful authentication via a legacy protocol (SMTP AUTH, IMAP, Basic AUTH). Control monitored: 3.5.3 (MFA bypass via legacy protocol). Expected rate: zero (legacy auth should be blocked via Conditional Access Policy 3). True positive: Conditional Access Policy 3 has failed or been misconfigured. Triage: immediately check Conditional Access policy status in Entra ID admin console. False positive: rare — only if the CA policy is correctly showing as blocked but the sign-in log category is misidentifying the client type.
This rule documentation at the security layer creates the connection between the control (documented at the IT-staff layer as a Conditional Access policy configuration) and the detection capability (the SIEM alert that fires when the control fails). The security analyst reviewing EV-F01 knows specifically which alert categories to check for each control family's monitoring obligations.
Layer 5: Investigation playbooks per incident type per family
Each AT-[family] page at the security layer contains a brief investigation playbook for the most likely incident type affecting that family. This is distinct from the AT-IR incident response playbooks, which cover the full lifecycle. The family-level investigation playbooks are rapid-triage guides for the security analyst in the first 30 minutes of a potential incident — before the incident is declared and the IRT is formally activated.
For AT-IA, the playbook is triggered when the security analyst sees a suspicious authentication pattern in the log review. The playbook covers: the first three queries to run in the SIEM (user's recent login history, MFA challenge results for this account in the past 7 days, devices the user has authenticated from); the four indicators that should make the analyst escalate to the Incident Commander immediately (successful logins from two geographies within the MFA feasibility window, admin role changes in the past 24 hours, password change not associated with an IT Operations ticket, new MFA method registered from an unfamiliar device); and the evidence to preserve before containment actions are taken (Entra ID sign-in log export for the affected account, MFA audit log export, device compliance history for the affected device).
For AT-AU, the playbook is triggered when EV-F06 shows a log source that has been silent for more than 4 hours. The playbook covers: the verification steps (is the source system operational? is the log forwarding agent running? is there a network path from the source to the SIEM?); the escalation trigger (if the source is an identity or network boundary system and it has been silent for more than 60 minutes, escalate to the Incident Commander — the outage may be intentional); and the evidence to preserve (last received log timestamp, network path trace, ACS access log for the server room during the gap period).
These playbooks are the security layer's answer to the gap between "the control exists" (IT-staff layer) and "we investigated a potential failure and here is what we found" (AT-IR evidence). They operationalise the response to monitoring alerts without requiring an incident declaration for every alert.
Layer 6: Assessment preparation guides per family
The assessor preparation checklists already in each AT-[family] page (accessible to isms-it-staff) tell the IT team what an assessor will examine and test. The security layer adds a complementary pre-assessment guide that is written from the security team's perspective rather than the assessor's.
The pre-assessment guide for AT-MP covers: which evidence items to pull and verify before an assessment day (EV-D25 destruction certificates — confirm one exists per disposed asset; EV-D26 sanitisation log — confirm no gaps in the past 12 months; EV-D27 backup logs — confirm 90 days of daily completion logs are present); the physical demonstration preparations (confirm the scanning workstation is available and AV signatures are current for the diagnostic media demonstration; confirm a sample CUI-labelled USB drive is available to show physical marking); and the interview preparation (the IT Manager should be prepared to explain the specific sanitisation method applied to the most recently disposed SSD, including whether cryptographic erasure or physical destruction was used and what tool was used).
The pre-assessment guide differs from the assessor checklist because it is written for someone preparing evidence rather than someone evaluating it. The tense shifts from "the assessor will examine" to "confirm that," from "test by attempting" to "prepare a test device for the demonstration." The security team uses this guide in the 4-week preparation window before any formal assessment.
Layer 7: POA&M item templates per control family
When the security analyst's quarterly control effectiveness assessment or the monthly monitoring review identifies a gap, they need to create a POA&M entry immediately. The security layer of each AT-[family] page contains pre-populated POA&M item templates for the most likely deficiency types in that family.
For AT-AU, the template library includes:
Template: Log source gap — Weakness description: [source system] has not forwarded logs to the SIEM since [date]. Gap duration: [N] days. Controls affected: 3.3.1 (retain logs), 3.3.4 (alert on failure). Risk during gap: Moderate (monitoring of this source was unavailable for the gap period; any security event during this period was undetected). Compensating controls during gap: manual review of local system logs on [date] confirmed no anomalous events during the gap period. Corrective action: restore log forwarding agent on [source system]; verify forwarding is active in SIEM dashboard. Target completion: [2 business days from detection]. Owner: IT Operations.
Template: MFA not enrolled — non-admin account — Weakness description: [N] non-admin accounts in the CUI scope do not have MFA enrolled as of [date]. Controls affected: 3.5.3 (MFA for network access to non-privileged accounts). Risk during gap: High if accounts are internet-accessible; Moderate if accounts are internal-only. Compensating controls: accounts are restricted to internal network access only by Conditional Access (named location policy) until MFA is enrolled. Corrective action: IT Operations to initiate MFA registration campaign for affected accounts; CISO to verify enrollment within 7 days. Target completion: [14 days from detection]. Owner: IT Manager.
These templates exist at the security layer because POA&M entries are a security programme responsibility, not an IT implementation responsibility. IT staff implement the controls; security staff assess whether they are working and create POA&M entries when they are not.
Layer 8: Cross-family evidence dependency map
A single page in the security layer of AT-CA documents the evidence dependencies across all 14 families — where an evidence item from one family is cited as supporting evidence by another family's control. This map is essential for assessment preparation because it identifies evidence items where a single production failure creates a multi-family compliance gap.
The critical dependencies to document include: EV-D05 (MFA coverage report) appears in both AT-IA (3.5.3) and AT-MA (3.7.5) — if the quarterly MFA report is missing, two family assessments are affected; EV-D06 (vulnerability scan reports) appears in both AT-RA (3.11.2) and AT-SI (3.14.1) — a gap in monthly scanning is a dual-family finding; EV-D21 (maintenance log) appears in AT-CM (3.4.3) and AT-MA (3.7.1, 3.7.2, 3.7.5, 3.7.6) — maintenance records that are incomplete affect two families; EV-D23 (physical access logs) appears in AT-PE (3.10.4) and AT-MP (3.8.1, 3.8.2) — ACS log gaps affect both physical protection and media protection evidence; and EV-D01 (privileged account review) appears in AT-AC (3.1.5, 3.1.6), AT-AU (3.3.8, 3.3.9), and AT-PS (3.9.2) — a missing quarterly access review creates findings across three families.
The map also documents the upstream dependencies — evidence items that must exist before other evidence items can be meaningful. The SIEM log review (EV-F01) is only meaningful if the SIEM health report (EV-F06) confirms the SIEM was ingesting all expected sources during the review period. The patch tracking register (EV-D07) is only meaningful if the vulnerability scan reports (EV-D06) that feed it are present and authenticated. The access review (EV-D01, EV-D02) is only meaningful if the JML provisioning records (EV-D03) confirm the current access grants were properly provisioned in the first place.
The security team uses this map during pre-assessment preparation to sequence their evidence production in dependency order — producing upstream evidence first, then the downstream items that depend on it, rather than working through families alphabetically and discovering mid-preparation that a dependency is missing.
Layer 9: Threat intelligence subscription register
A dedicated security-layer page (linked from AT-RA and AT-CA) documents all active threat intelligence subscriptions and advisory sources, with the last review date, the control families each source is most relevant to, and the procedure for acting on an advisory when it arrives.
The register covers: NCSC Early Warning (free UK government threat intelligence service — relevant primarily to AT-SI, AT-RA, AT-SC); CISA CISA KEV feed (critical for AT-RA triggered scanning procedure — an alert requires a SIEM search within 4 hours and a targeted scan within 24); CISP (Cyber Security Information Sharing Partnership — sector-specific intelligence; requires NCSC registration); Microsoft Security Response Centre advisories (Windows and Azure — AT-CM, AT-IA, AT-SI); vendor security advisories from the organisation's specific platform vendors (firewall vendor, SIEM vendor, EDR vendor — relevant to AT-SC, AT-AU, AT-SI respectively); and sector ISAC if the organisation participates in an Information Sharing and Analysis Centre relevant to defence or manufacturing.
For each source, the register specifies the action procedure: when an advisory arrives, which control family page is updated with a current threat intelligence note, which scanning or monitoring action is triggered, and whether a SIEM correlation rule update is required. The register makes the threat intelligence integration from AT-RA Section 3 (annual assessment procedure Phase 2) a continuous activity rather than an annual one.
Layer 10: The security-only SCM page — ISMS programme status overview
Beyond the per-family overlays, the security layer should have one page that exists only for the isms-security audience: a programme status overview that aggregates the view across all 14 families. This is the CISO's single-page operational dashboard.
It contains four sections. First, the evidence currency summary — a condensed version of all 14 families' currency panels, showing at a glance which families have overdue evidence items. Second, the POA&M status — a summary of the AT-CA POA&M showing total open items by severity, items due in the next 30 days, and items overdue. Third, the monthly monitoring completion status — a checklist confirming which EV-F items have been completed this month, which are pending, and which are overdue. Fourth, the assessment calendar — the next assessment date (internal or C3PAO), the preparation phase we are currently in, and the days remaining.
The programme status overview page is not a static document — it is the page the CISO updates at the beginning of each month after completing the monthly POA&M review. It is the security team's accountability document: the single place that shows whether the compliance programme is running effectively or falling behind. During an assessment preparation period it becomes the coordination hub — the page where the CISO tracks which families are ready, which need more evidence production, and which have POA&M items that need to be addressed before an assessor arrives.