3.14 SI
730 paragraphs across seven sections. Here is what distinguishes this page from the others in the family library, and the design decisions that carry the most operational weight.
What makes this page structurally different
Section 0 opens with an ISO 27001 Annex A positioning table before any control text — a deliberate choice for the SI family specifically. The four Annex A controls that SI implements (8.7, 8.8, 8.16, 8.23) span two very different problem domains: malware protection (8.7/8.8 — defensive, mostly IT Operations work) and monitoring activities (8.16/8.23 — detective, mostly Security Analyst work). These are often owned by different people in the same organisation, and evidence for one domain does not substitute for the other. Making this split explicit in section 0 prevents the common mistake of presenting AV coverage reports as evidence for the monitoring controls, or SIEM alert reviews as evidence for the malware controls.
Section 3 — the SIEM correlation rules table — is content that almost never appears in compliance documentation but is exactly what separates a SIEM that provides security value from a SIEM that is deployed to tick a compliance box. The ten detection rules listed cover the specific attack patterns that 3.14.6 and 3.14.7 require you to detect. A C3PAO assessor testing 3.14.6 will ask to see the SIEM console and demonstrate that these rules exist and fire. Without this table in the Confluence page, your engineers have no specification to build to.
The SLA clock issue — the most operationally important point
The patch remediation SLA table contains a note that deserves emphasis: the SLA clock starts at vendor release date, not detection date. This is stated in both the 3.14.1 implementation description and the SLA table, because it is the single most common reason organisations believe they are compliant when they are not.
Consider a critical CVE released on 1 January. Your monthly vulnerability scanner runs on 25 January and detects it. You patch it on 30 January — 5 days after detection, apparently within your 14-day SLA. But from the vendor release date, 29 days have elapsed. You have been non-compliant for 22 days and you did not know it because you were measuring the wrong start point.
The fix is straightforward: configure the patch tracking register (EV-D07) to record both the vendor release date and the detection date, and compute SLA compliance from the vendor release date. The patch tracking register template in EV-D07 should have the SLA status column automated — colour-coded from the release date field, not the detection date field.
The five-layer AV deployment specification
The AV deployment specification table in section 2 covers six protection components. The "appropriate locations" language in 3.14.2 is the fulcrum of almost every SI finding in first-time CMMC assessments. "Appropriate" means wherever malicious code can enter the system — which for a modern organisation means: endpoints (users execute malicious attachments); email (the primary delivery vector for malware); web proxy (drive-by downloads, malicious redirects); DNS (C2 callback resolution, domain generation algorithm traffic); and removable media (physical attack vector, especially relevant for DEFSTAN-scoped environments where airgapped systems are common). The deployment specification table makes each layer explicit so there is no ambiguity about what "deployed" means.
Replace the placeholder [EDR platform name] and [Email security platform] text with your actual product names before importing into Confluence. These placeholders are deliberate — CMMC SSP documentation must name the specific tools, not describe them generically.
The SIEM as evidence
The monthly log review record (EV-F01) is the evidence that the SIEM is operational rather than merely deployed. Common finding number six in the assessment checklist section captures this precisely: a SIEM generating alerts that no one reviews is a compliance theatre item, not a security control. The log review record must document that a named analyst reviewed the alert queue with the date, alert volume, and disposition.
For the SI family specifically, the log review record should have a dedicated UEBA review section noting: how many accounts exceeded the behavioural risk threshold this month, what investigations were opened, and what the outcomes were. This section is what satisfies 3.14.7 on paper — a SIEM deployed without UEBA configured has no mechanism to identify unauthorised use as distinct from any other system access.
Cross-linking in Confluence
The AT-SI page should carry active cross-links to four pages. Link to AT-AU (Audit and Accountability) because the logging infrastructure that 3.14.6 depends on for attack detection is specified there under 3.3.1 and 3.3.2. Link to AT-SC-BDY because the IDS/IPS deployment sits at the network boundary described in 3.13.1. Link to FC-04 (Malware Protection) because the all-staff content on AV and reporting sits there — AT-SI is the technical implementation layer, FC-04 is the behavioural layer. And link to AT-CA (Security Assessment) because the vulnerability scanning that implements 3.14.1 is also tested against 3.11.2 and 3.11.3 in the Risk Assessment family — these controls share the same evidence items (EV-D06, EV-D07) and the same scanning programme.