Security Monitoring Audit & Accountability // 10 MIN READ

Do You Actually Need a SIEM for CMMC Level 2?

The Budgeting Question Behind the Architecture Decision

NIST SP 800-171 does not require a SIEM by name. But it requires audit log collection, review, correlation, alerting, and incident response — and the question is whether your environment can satisfy those requirements without one. For many contractors, the answer is more nuanced than the vendor pitch suggests.

Why This Question Keeps Coming Up

Every defense contractor preparing for CMMC Level 2 hits the same inflection point: their consultant, their MSP, or a vendor tells them they need a SIEM. The price tag — anywhere from $15,000 to $80,000 per year for a small to mid-sized organization, depending on the product and data volume — stops the conversation. The contractor asks: does the requirement actually say I need this?

The honest answer is no. The requirement does not say "deploy a SIEM." But the honest answer is also that the requirement demands a set of capabilities that, in most environments of any complexity, are very difficult to satisfy without something that functions like one.

The real question is not "do I need a SIEM?" The real question is: can I collect audit logs from every in-scope system, retain them for the required period, review them on a defined schedule, correlate events across sources, generate alerts for security-relevant activity, and produce evidence of all of the above during an assessment — without a centralized platform? For a five-person company with one server, maybe. For a 50-person company with GCC High, Intune, a firewall, a VPN, and an on-premises file server, probably not.

The SIEM question is ultimately a budgeting question disguised as a compliance question. Contractors want to know if they can pass an assessment without spending $40,000 a year on a platform they don't fully understand. The answer depends on what the controls actually require — and what the assessor will actually ask for.

What the Requirement Is Really Asking For

The Audit and Accountability (AU) control family in NIST SP 800-171 contains the controls that drive the SIEM conversation. These are not suggestions. Each one is decomposed into assessment objectives, and each objective is independently scored Met or Not Met. Here are the controls that matter most:

Control What It Requires What This Means in Practice
AU.L2-3.3.1 Create and retain system audit logs and records Every in-scope system must generate audit logs. Those logs must be retained for a documented period — typically one year at minimum.
AU.L2-3.3.2 Ensure actions of individual users can be uniquely traced Logs must include sufficient detail to attribute events to specific users — not just system accounts or generic entries.
AU.L2-3.3.5 Correlate audit review, analysis, and reporting Logs from multiple systems must be correlated — meaning events on one system can be connected to events on another to identify patterns.
AU.L2-3.3.6 Provide audit reduction and report generation You must be able to filter, search, and generate reports from audit data — not just store it in raw form.
SI.L2-3.14.6 Monitor organizational systems Detect attacks, indicators of compromise, and unauthorized activity through monitoring — not just after-the-fact log review.
SI.L2-3.14.7 Identify unauthorized use The monitoring capability must generate alerts for unauthorized or anomalous behavior — passive log collection is not sufficient.
IR.L2-3.6.1 Establish an incident response capability You must be able to detect, report, and respond to incidents — which requires the monitoring infrastructure to feed the incident response process.
Read these controls together — not in isolation. Individually, each one could theoretically be satisfied with manual processes. Together, they describe a system that collects logs from all in-scope sources, retains them, correlates events across sources, generates reports and alerts, and feeds an incident response process. That is functionally a SIEM — whether you call it one or not.

SIEM Versus Centralized Logging Versus Managed Detection

The market offers three broad approaches to satisfying the AU and SI controls. Each has a different cost profile, a different level of operational effort, and a different evidence story during an assessment.

01

Full SIEM (Self-Managed)

Products like Microsoft Sentinel, Splunk, Elastic SIEM, or LogRhythm. Deployed in your environment or cloud. You configure the log sources, write the detection rules, tune the alerts, and operate the platform. Provides full correlation, dashboards, and reporting. Satisfies every AU and SI control — but only if someone operates it competently. A SIEM that nobody monitors is a liability, not a control. Typical cost: $20,000–$80,000+/year depending on data volume and licensing model.

02

Centralized Log Aggregation (No Correlation Engine)

Products like Graylog, a syslog server, or Windows Event Forwarding to a central collector. Logs are collected and stored in one place, searchable and exportable. But there is no built-in correlation engine, no automated alerting, and no detection logic. You can satisfy AU.L2-3.3.1 (create and retain logs) and AU.L2-3.3.2 (user traceability), but satisfying AU.L2-3.3.5 (correlation) and SI.L2-3.14.6 (monitoring) requires manual effort — or additional tooling layered on top. Typical cost: $0–$10,000/year. Operational cost: high.

03

Managed Detection and Response (MDR)

A third-party service — Huntress, Arctic Wolf, Todyl, Blumira, or similar — that deploys agents or collects logs from your environment and monitors them 24/7 with a team of analysts. The provider handles correlation, alerting, and initial triage. You handle escalation and response. Satisfies AU and SI controls through the provider's platform, but creates a shared responsibility model: the provider is an External Service Provider, and their monitoring infrastructure generates Security Protection Data that may be in scope. Typical cost: $8,000–$40,000/year.

The cheapest option is rarely the simplest. Centralized logging without correlation looks affordable on paper — but the manual effort to review logs daily, generate reports, identify anomalies, and document the process for an assessor often exceeds the cost of an MDR subscription. The question is not just what the tool costs. It is what the process around the tool costs.

Environments Where a SIEM Is Hard to Avoid

There are environments where the combination of log sources, correlation requirements, and monitoring obligations makes it impractical to operate without a SIEM or an MDR platform. If your environment matches any of the following patterns, budget for a centralized monitoring platform from the beginning.

  • Hybrid infrastructure — GCC High cloud services plus on-premises servers, network appliances, and endpoints. Logs come from Azure AD, Exchange Online, SharePoint, Intune, Windows Event Logs, firewall syslog, VPN concentrators, and endpoint detection agents. Correlating events across these sources manually is not viable at any scale.
  • More than 25 in-scope users — The volume of authentication events, file access events, email events, and endpoint events generated by 25+ users produces a log volume that cannot be meaningfully reviewed without automated filtering, aggregation, and alerting.
  • Remote workforce — Remote access introduces VPN logs, conditional access events, device compliance events, and geolocation-based anomalies. Detecting a compromised remote session requires correlating authentication logs with endpoint telemetry and network traffic — a task that requires correlation logic, not manual review.
  • MSP or ESP involvement — If an external provider manages any part of your infrastructure, the handoff between their monitoring and yours must be documented and testable. An MDR platform with a shared dashboard or a SIEM with role-based access is often the cleanest way to demonstrate that monitoring covers both sides of the shared responsibility boundary.
  • DFARS 7012 incident reporting obligation — DFARS requires reporting cyber incidents to the DoD within 72 hours and preserving forensic images for 90 days. Meeting this timeline requires detection capabilities that operate in near-real-time — not a weekly manual log review.
If you recognize your environment in this list, the question is not whether to deploy a monitoring platform. It is which one — self-managed SIEM, cloud-native SIEM like Sentinel, or an MDR service — and how to configure it so the evidence is assessor-ready from day one.

Environments Where Simpler Approaches May Still Work

Not every contractor needs a $40,000 SIEM deployment. Some environments are small enough, simple enough, and well-scoped enough that a lighter-weight approach can satisfy the AU and SI controls — provided the process around it is rigorous and documented.

May Work

Cloud-Only, Small Enclave

A 10-person company with all CUI in GCC High, no on-premises servers, endpoints managed by Intune, and no VPN. Audit logs come from a single source: the Microsoft 365 Unified Audit Log. Microsoft Defender for Office 365 provides alerting. Microsoft Purview provides search and reporting. The log source count is low enough that a weekly structured review — documented with screenshots and timestamps — may satisfy the assessment objectives.

May Work

Enclave with Minimal Surface

A contractor that segments CUI into a small enclave — a few dedicated workstations, a single file share, and a firewall — with no cloud CUI processing. Log sources are limited to the firewall, the file server, and the workstations. Event volume is low. A centralized syslog collector with a documented daily review process and manual correlation may be sufficient — but only if the review is consistently performed and evidenced.

The critical requirement in both scenarios is not the tool. It is the documented, consistent, evidenced process. An assessor evaluating a small environment without a SIEM will ask: "Show me your log review process. How often do you review? What do you look for? Show me the records from the last three months." If the answer is "we check when something seems off," the control is Not Met — regardless of how small the environment is.

A SIEM automates the evidence trail. Without one, you must create that evidence trail manually — and that manual effort must be sustained, consistent, and reviewable. Many contractors who start with a manual process end up deploying a monitoring platform within the first year simply because the manual burden is unsustainable.

What "Review," "Correlation," and "Response" Need to Look Like

These three words appear throughout the AU and SI control families, and assessors interpret them with specific expectations. Satisfying the word on paper requires demonstrating the action in practice.

Capability Review
A defined, recurring process — daily or weekly — where a designated individual examines audit logs for anomalies, failed authentication attempts, privilege escalation, unauthorized access, and policy violations. The review must produce a dated record: a log review checklist, a ticket, a report export, or a screenshot with a timestamp. "We look at it when something seems wrong" does not satisfy this requirement.
Capability Correlation
The ability to connect events across systems to identify patterns that no single log source would reveal on its own. Example: a failed VPN login from an unusual location, followed by a successful Azure AD sign-in, followed by a large file download from SharePoint. Each event is individually unremarkable. Together, they indicate a potential compromise. Correlation can be automated (SIEM rules) or manual (a trained analyst reviewing multiple logs side by side) — but it must be demonstrable.
Capability Response
When the review or correlation process identifies a security-relevant event, there must be a documented response pathway: who is notified, what initial containment actions are taken, how the event is classified, and how it feeds into the incident response plan. An alert that fires into a dashboard nobody checks is not a response capability. The monitoring system must connect to a human process that acts on its output.
The assessor's test: "Show me an alert that fired in the last 90 days. Walk me through what happened after it fired — who saw it, what they did, and how it was resolved." If you cannot produce a concrete example, the monitoring control is scored Not Met — even if the SIEM is deployed and configured.

Evidence Examples That Pass Without Overbuilding

Contractors frequently overbuild their monitoring stack in pursuit of "compliance" and then struggle to operate it — or they underbuild and cannot produce evidence when the assessor asks. The goal is to build exactly enough to satisfy every assessment objective, with evidence that is clean, consistent, and reproducible.

Here is what a defensible evidence package looks like for the AU and SI controls — without requiring an enterprise-grade SIEM deployment:

Evidence 01 Log Source Inventory
A document listing every in-scope system, what audit events it generates, where those events are sent, and the retention period for each. This is the "what are we collecting and from where" artifact — and it must match the SSP boundary.
Evidence 02 Retention Configuration
Screenshots or exports from your SIEM, log aggregator, or Microsoft 365 Unified Audit Log settings showing the retention period is configured and enforced. If using Sentinel, the workspace retention policy. If using M365, the Purview audit retention policy.
Evidence 03 Review Records
Dated evidence of regular log reviews — a completed checklist, a ticket closed as "no anomalies detected," a weekly summary report, or a SIEM dashboard export with the reviewer's name and date. Must cover at least the prior 90 days. Gaps in the review schedule are findings.
Evidence 04 Alert Rules
Configuration exports or screenshots of the alerting rules in your monitoring platform — what conditions trigger an alert, who receives the notification, and what the expected response is. Rules should cover at minimum: failed authentication, privilege escalation, unauthorized access attempts, and changes to security configurations.
Evidence 05 Alert Response Example
At least one concrete example of an alert that fired and was investigated — a ticket, an email thread, or a SIEM case file showing the alert, the triage steps, the determination, and the resolution. This proves the monitoring system is not just configured but actively operated.
Evidence 06 Correlation Capability
A demonstration — live or documented — showing that events from multiple sources can be connected. In Sentinel, a KQL query joining sign-in logs with SharePoint access logs. In an MDR dashboard, a correlated alert that references both endpoint and identity telemetry. In a manual process, a log review record that references events from two or more systems.
Notice what is not on this list: A $60,000 Splunk deployment. A 24/7 SOC. A SOAR platform with automated playbooks. Those tools are valuable — but they are not required for CMMC Level 2. What is required is a system that collects, retains, reviews, correlates, alerts, and responds — and evidence that each of those verbs is actually happening. The tool is a means. The evidence is the end.

The Bottom Line

You do not need a SIEM to pass CMMC Level 2. You need the capabilities that a SIEM provides: centralized log collection, retention, review, correlation, alerting, and an operational process that acts on the output. Whether you deliver those capabilities through a self-managed SIEM, a cloud-native platform like Microsoft Sentinel, an MDR service, or — in the smallest environments — a rigorous manual process is an architecture and budget decision, not a compliance decision.

But be honest about your environment's complexity. If you have more than a handful of log sources, if you have a remote workforce, if you have an MSP managing any part of your infrastructure — the manual approach will break down before the first assessment. The money you save by avoiding a monitoring platform is money you spend on unbilled hours reviewing logs, generating reports, and hoping nothing falls through the cracks.

The assessor does not care what product you use. The assessor cares that you can show them a log review record from last Tuesday, an alert that fired last month and was investigated, and a retention policy that covers the last year. Build the process first. Then choose the tool that makes the process sustainable.