What 03.12.03 continuous monitoring requires for CUI systems
03.12.03 asks a nonfederal organization handling CUI to develop and implement a system-level continuous monitoring strategy, and to run that strategy so that ongoing monitoring and security assessments together show whether the system stays in the state its security plan describes. The organization owns this obligation. An assessor will test whether the strategy exists in writing and whether the activities it names actually happen, on a schedule, with results that feed back into decisions. Without monitoring, a system can drift from its approved baseline through configuration changes, new software, expanded access or lapsed patches, while the last assessment and the system security plan still describe the system as it was. Assessments then go stale, and a score or plan of action that looked accurate at one point no longer reflects reality.
The requirement is hard because it is a strategy plus operation, not a tool. A monitoring product can collect events and raise alerts, but 03.12.03 expects the organization to decide what is monitored at the system level, how often security controls are assessed, who reviews the output, what counts as a change that needs attention, and how findings reach the plan of action and milestones. An assessor reviewing the continuous monitoring strategy will look for those decisions, for the responsible roles, and for records showing that the monitoring ran. Rev. 2 had no equivalent split: CMMC Level 2, which still uses Rev. 2, assesses the same intent as CA.L2-3.12.3, and NIST's change analysis traces Rev. 2 requirement 3.12.3 to 03.12.03 as a minor change. NIST also states that withdrawn requirement 03.04.09 is addressed by 03.12.03 together with 03.01.05, 03.01.06, 03.01.07 and 03.04.08, so the monitoring strategy is also where many of the former configuration and identification concerns get their operating evidence.
Before scoping work, confirm three things with your contracting officer or the assessing body: which Rev. 2 or Rev. 3 requirement set applies to your contract, which organization-defined parameter values, such as monitoring frequencies, the federal agency expects you to assign, and whether the agency expects a written continuous monitoring strategy separate from the system security plan. Then ask the implementation partner to produce the strategy as a dated document with named owners, the monitored components, the assessment cadence and the review record. The strategy should be tested with a real change, such as a configuration deviation on one host, to show that detection, review and POA&M entry all occur. That test record is often the evidence that persuades an assessor.
Which systems, data and teams the monitoring strategy covers
Before writing a continuous monitoring strategy, the organization has to decide what the strategy covers. The CUI boundary, the split between system-level and organization-level strategies, shared cloud components and team ownership each change which monitoring activities are needed and who performs them.
The CUI system boundary and enclave
The system-level strategy applies to the system that stores, processes or transmits CUI, so the boundary sets its scope. Map every host, identity store, log source and network path that touches CUI, and mark the ones outside the boundary. A narrow enclave shrinks the monitored estate but forces strict controls on what connects to it. Confirm the boundary with the system security plan before selecting tools, because the monitoring coverage must match what is declared there.
System-level versus organization-level strategy
The requirement asks for a system-level continuous monitoring strategy, which is separate from any organization-wide program. The system-level strategy covers the controls and events of one CUI system, while the organization-level strategy sets common policy, tooling and reporting. Document which elements sit at each level and how findings move from one to the other, so assessors can trace a monitored control back to its owner.
Shared cloud and managed service components
Cloud identity providers, managed databases, SaaS email and hosting platforms often sit inside the boundary but are operated by someone else. Determine which monitoring data the provider exposes, which logs you can export, and which events remain visible only to the provider. Record these dependencies in the strategy and in the agreements that govern them, and confirm the provider's data retention and access terms before relying on its logs.
Security and IT operations ownership
Security typically owns alert triage, detection rules and assessment scheduling, while IT operations owns agent deployment, log forwarding and patch status. Assign each monitored element, such as endpoint telemetry, vulnerability scanning and authentication logs, to one accountable team with a named backup. Unclear ownership is a common reason monitoring data is collected but never reviewed. Ask who answers for a gap in each data source.
System owners and their monitored systems
System owners decide how their applications behave, which configuration changes are approved and which events matter for their business function. They should review the monitoring scope for their system and confirm that the assessment results and alerts they receive are relevant. Their sign-off on the monitored elements gives the strategy operational meaning and reduces disputes when findings require remediation.
Monitoring frequency values to assign
Rev. 3 uses organization-defined parameters, and the frequency at which monitoring and assessments occur is often one of them. If the federal agency does not specify these values, the nonfederal organization must assign them to complete the requirement. Set the frequencies in writing, justify them against the risk to CUI, and confirm with the contracting agency whether it has already published values that override yours.
How ongoing monitoring and security assessments fit into one strategy
Requirement 03.12.03 expects one documented, system-level continuous monitoring strategy that combines two linked activities: ongoing monitoring of the system and periodic security assessments. The strategy is the document that ties them together. Without it, monitoring produces alerts nobody reviews against the security requirements, and assessments run on a calendar with no current picture of how the system is behaving. An assessor testing this requirement will look first for the strategy itself, then for proof that the monitoring and assessment activities it describes actually happen and feed each other.
A workable strategy answers a short list of questions for the specific system. Which components are monitored, such as servers, endpoints, network boundary devices, identity services and cloud control planes, and which security-relevant signals each one produces. How often each signal is reviewed and how often the security requirements are assessed, with the frequency set by the organization and recorded in the plan. Who owns each review, who receives escalations, and what counts as a finding that must be tracked. The strategy should also say how monitoring results reach the assessment cycle. Findings that show a requirement is no longer met should trigger reassessment of that requirement, and confirmed weaknesses should move into the plan of action and milestones described under 03.12.02, with an owner and a target date.
The system-level strategy should map to the organizational continuous monitoring strategy, which sets the enterprise-wide rules for frequency, reporting and risk tolerance. Confirm with the contracting agency or your own governance body which parameters must be set at the organization level and which the system owner may tailor, because the requirement's organization-defined parameters are assigned by the nonfederal organization where the agency does not specify them. Test the strategy in practice before an assessment: pick one monitored signal, trace it to a review record, a decision and, where relevant, a POA&M entry. If that trail cannot be produced, the strategy describes intent rather than operation.
How an assessor tests 03.12.03 under SP 800-171A
SP 800-171A Rev. 3 assesses 03.12.03 with four determination statements. Each one is a yes or no test the assessor must answer before scoring the requirement as met. The statements check that the organization has defined a system-level continuous monitoring strategy, that the strategy includes ongoing monitoring, that it includes security assessments, and that the strategy is implemented. The assessor does not accept the requirement on the strategy's existence alone. Each statement needs its own supporting evidence, and a gap in any one of them means the requirement is not met.
- Strategy defined: a written system-level continuous monitoring strategy exists for the specific system in scope, not only an enterprise-wide policy.
- Ongoing monitoring included: the strategy names the monitoring activities, their data sources and their frequency.
- Security assessments included: the strategy ties ongoing monitoring to periodic security assessments of the system.
- Strategy implemented: the activities described in the strategy are running and producing records.
Before a scoping discussion, confirm with your assessor which statement wording and objects they will use, since the organization's own system boundary determines what each statement covers.
The examine method means the assessor reviews documents and artifacts. For 03.12.03, the examine objects listed in SP 800-171A Rev. 3 are the security assessment and monitoring policy and procedures, the organizational continuous monitoring strategy and the system-level continuous monitoring strategy. The assessor reads these documents to confirm they exist, are approved, name roles and cover the system in scope. The organizational strategy sets enterprise direction, while the system-level strategy must be specific enough to apply to the system under assessment.
- Policy and procedures: an approved policy with a current procedure that tells staff how monitoring is run and reviewed.
- Organizational strategy: an enterprise document that sets monitoring goals, roles and reporting paths.
- System-level strategy: a document for the system in the boundary, listing data sources, tools, frequencies and assessment cadence.
- Version and approval records: dates, owners and sign-off that show the documents are maintained.
- Consistency checks: the system security plan and the strategy should describe the same monitoring activities.
The assessor will compare these documents against each other and against the system itself, so check that the system-level strategy names real tools and real owners before the assessment.
The interview method means the assessor asks people how the work is actually done. SP 800-171A Rev. 3 names two groups of interview objects for 03.12.03: personnel with continuous monitoring responsibilities and personnel with information security responsibilities. The assessor uses these conversations to test whether the documented strategy matches daily practice. Staff who run alerts, review dashboards and schedule assessments should be able to explain what they do, how often and what happens when something looks wrong.
- Monitoring operators: questions about which feeds they review, how alerts reach them and how they record a decision.
- Security leadership: questions about how monitoring results feed risk decisions, the POA&M and the periodic assessment.
- Consistency of answers: different people describing the same process in the same way is strong evidence.
- Escalation paths: who is called, within what timeframe and through which channel when a monitoring result needs action.
- Ownership changes: whether staff know who covers the activity during leave or after a role change.
Prepare the people named in the strategy for these questions, and make sure they can point to the records that support each answer.
The test method means the assessor observes or exercises the mechanisms that implement continuous monitoring. The test objects for 03.12.03 in SP 800-171A Rev. 3 are the mechanisms for implementing continuous monitoring. In practice this means the log collection, detection rules, vulnerability scanning and alert routing the organization uses. The assessor may trigger a test event, check that it appears in the monitoring platform, confirm that an alert reaches its recipient and verify that the result is recorded. The test shows whether the mechanism works, not only whether it was purchased or configured once.
- Log coverage: whether the systems named in the strategy are actually sending events to the monitoring platform.
- Detection rules: whether the rules named in the strategy are loaded, enabled and firing on test input.
- Alert routing: whether alerts reach the named channel, such as a ticketing queue or an on-call mailbox.
- Assessment scheduling: whether scheduled assessments run and produce output on time.
- Recorded outcomes: whether each alert or finding leads to a ticket, a decision and a closure record.
Run these checks yourself before the assessor does, and keep the query results or screenshots that show each mechanism working on the date of review.
The most frequent weakness for 03.12.03 is a strategy that exists on paper but has no operating mechanism behind it. The document names a monitoring tool, a review cadence and a set of assessments, but the tool was never fully deployed, the review is not logged or the assessment was never repeated. Assessors treat this as a failure of the implementation determination, even when the document is well written. Other common findings follow the same pattern: the organizational strategy is detailed while the system-level strategy is generic, or the interview answers contradict the documents.
- Paper-only strategy: the document describes activities that produce no records when the assessor asks for them.
- Generic system-level strategy: the document could apply to any system and does not name this system's sources or owners.
- Gaps in log sources: systems inside the boundary are missing from monitoring with no documented reason.
- Unrecorded reviews: monitoring is performed informally, so no evidence of review dates or decisions exists.
- Disconnected assessments: assessment results do not feed back into the POA&M or the monitoring rules.
Before submitting evidence, compare your strategy, your interview preparation and your test results side by side, and confirm each claim in the strategy with a record that an assessor can examine.
How to build the continuous monitoring strategy step by step
This sequence turns the 03.12.03 requirement into a documented, system-level strategy that pairs ongoing monitoring with periodic security assessments, with each step closed by a named artifact the assessor can examine.
Define the system boundary and monitored components
Start by listing every component inside the boundary that stores, processes or transmits CUI, along with the supporting identity, logging, endpoint and network services those components depend on. Record hosts, network devices, cloud services and applications, and note which ones sit outside the boundary but connect to it. The organization owns this decision, and the system security plan should match it. The step is done when the inventory and boundary diagram agree with the system security plan and a named owner has signed off on both.
Set monitoring objectives, frequencies and ODP values
Write the objectives the monitoring must meet, such as detecting unauthorized changes, unpatched software and anomalous access to CUI, and assign a monitoring frequency to each. Requirement 03.12.03 sits inside Rev. 3, which uses organization-defined parameters, so the organization must assign any ODP value its federal agency has not specified. Check the contract, the agency and any published DoW values before you fix these numbers. The step closes with a strategy document that lists each objective, its frequency and the ODP values with their source.
Select data sources and monitoring tools
Choose the log sources, vulnerability feeds and detection content that deliver the objectives, then confirm each tool's capabilities against its current documentation rather than assuming them. Open-source candidates include OpenSearch Security Analytics for Sigma-based detection and correlation, Wazuh for log decoding and rule-based alerting, and Fleet for matching installed software against vulnerability sources. Document which source feeds which objective. The step closes with a tool and data-source matrix that an assessor can trace to the strategy.
Establish triage, escalation and alert handling
Define who reviews each alert, how severity is assigned, which events become incidents under the incident response plan, and how long-running weaknesses move to remediation. Record the handoff from monitoring to incident response and to the vulnerability process so no finding falls between teams. The step is complete when a written runbook names roles, severity criteria and escalation paths, and a tabletop check shows that a test alert reaches the right person.
Connect findings to assessments and the POA&M
Link the monitoring outputs to the periodic security assessment and to the plan of action and milestones so that each confirmed weakness becomes a tracked item with an owner and a planned remediation. Use monitoring results as an input to reassessing the requirements, and record which assessment changes they triggered. The step closes when a sample finding can be followed from the alert, through triage, into the POA&M and back into an updated assessment record.
Run and document the first review cycle
Operate the monitoring for one full cycle under the written frequencies, then review coverage gaps, alert quality, missed or noisy detections and how the team handled escalations. Record the changes made to sources, rules, ODP values or the runbook, and the reasons for each. Ask an internal reviewer or independent assessor to test a sample of the evidence. The step closes with a signed review record and a revised strategy version that becomes the baseline for the next cycle.
Evidence that satisfies 03.12.03 and how to keep it current
An assessor testing 03.12.03 looks for a strategy that is approved and in use, monitoring that produces records, and proof that someone reviewed those records and acted on them. The cards below cover each artifact and the routine that keeps it defensible between assessments. Each item should trace back to the strategy, so the evidence reads as one connected story rather than a folder of screenshots.
Approved system-level monitoring strategy
This is the core document for 03.12.03: a system-level continuous monitoring strategy that states what is monitored, how often, by which tools, who reviews the output, and how monitoring feeds security assessments. Confirm that it names the specific system boundary, carries an approval signature and date from the accountable owner, and matches the system security plan. An assessor will compare the strategy to what the tools actually do, so any gap between the two is a finding.
Monitoring configuration exports
Exports of detector, rule and collection settings show that the strategy was implemented, not only written. Keep dated exports of log sources, enabled detectors, rule sets and alert destinations, such as the Sigma rule sets used in OpenSearch Security Analytics or the built-in and custom rules in Wazuh. Store them under version control so a reviewer can see when a rule was added, changed or disabled, and who approved the change.
Alert and finding records with dates
Assessors test whether monitoring runs and produces results, so they ask for dated alert and finding records. Export findings with timestamps, source host, rule, log type and severity, and keep the alerts.log and alerts.json output or their equivalent in your retention store. Check that retention covers the period since the last assessment and that log gaps are documented, because an unexplained silence over several weeks looks like monitoring that stopped.
Review and triage records
Alerts without a documented response show that monitoring is not being used. Keep ticket or case records that show who received each alert, when it was triaged, the disposition (false positive, accepted risk, or incident), and the closure approver. Sample a set of alerts across severities and confirm each one has a traceable outcome. Reviewers who sign off on triage should be named in the strategy, so the records match the documented roles.
Assessment reports linked to monitoring results
03.12.03 sits alongside periodic security assessment, so the strategy should show monitoring results feeding the next assessment. Keep assessment reports that cite specific monitoring outputs, such as vulnerability inventories from Fleet or alert trends from the SIEM, and record which findings the assessment confirmed or retired. This linkage is the clearest proof that monitoring and assessment operate together as the requirement describes.
POA&M entries sourced from monitoring
When monitoring reveals a weakness, the remediation belongs in the plan of action and milestones with a clear source reference. Record the monitoring event or vulnerability that triggered each entry, the owner, the planned completion date and the status changes over time. Under CMMC, a 3.12.3 gap cannot be carried on a POA&M for Conditional status, so confirm which framework applies before deciding how monitoring gaps are tracked.
Keeping evidence current between audits
Evidence decays quickly if nobody owns its upkeep. Put the strategy and rule sets under version control with review dates, set a recurring review cadence that the strategy itself defines, and keep a dated log of each review. Prepare a sampling index that maps each determination statement to its artifact, so an assessor can select random months or alerts and find the supporting record within minutes. Ask your assessor which sampling approach they expect before the assessment begins.
What meeting 03.12.03 costs in money and effort
This table breaks down what it takes to run a system-level continuous monitoring strategy for 03.12.03, separating one-time build work from recurring operating effort and naming who is paid for each. Use it to shape a quote request, because no price or duration is stated here and the real figures depend on your environment and scope.
| Cost component | One-time or recurring | What drives it up or down |
|---|---|---|
| Tooling and licenses | Zero license fee for the open-source options named on this page, so recurring cost is mainly infrastructure | Confirm license terms (AGPL, GPL, Apache, MIT) with your legal team if you modify or redistribute the tools |
| Infrastructure and log storage | Recurring | Log volume from in-scope hosts, retention periods and whether you run the stack in your own data center or cloud account |
| Engineering time to deploy and tune | One-time, with periodic tuning | Number of log sources, custom Sigma or Wazuh rules needed, and how much CUI-system telemetry is already collected |
| Writing and reviewing the continuous monitoring strategy | One-time drafting, then recurring reviews | Whether the organizational and system-level strategies already exist, and how many system owners must approve changes |
| Alert triage staffing | Recurring | Alert volume after tuning, the on-call model, and how well findings feed into the POA&M under 03.12.02 |
| External testing or review | Recurring or periodic | Whether you commission independent review of the monitoring design or test detection coverage, and how often |
| Assessor sampling and evidence preparation | Recurring at each assessment | How well monitoring records are kept, the number of systems in scope, and whether evidence is exportable without manual collection |
| Quote items to request | Mixed | Ask for each component above as a separate line, the assumptions behind log volume and host counts, and which items the partner delivers versus the organization |
Who owns the strategy, who builds it and who assesses it
Your organization owns the continuous monitoring strategy. The strategy is a system-level document that states what is monitored, how often, by whom, and how findings reach decisions. Your security leadership approves the monitoring frequencies, accepts the residual risk where monitoring cannot cover a requirement, and decides how monitoring results feed the plan of action and milestones. No partner or assessor can make these decisions for you.
- Strategy ownership: a named role, usually the system owner or information security lead, signs the system-level continuous monitoring strategy and keeps it current when the system changes.
- Frequency decisions: the team sets how often each monitored area is reviewed, based on the system's risk and its contractual obligations.
- Finding review: analysts or a designated reviewer triage alerts and vulnerability results, decide what is a weakness, and open items in the plan of action and milestones.
- Ongoing operation: staff keep monitoring running after handover, including tuning rules, reviewing exceptions and retaining records.
- Accountability: the organization answers to its federal agency customer for compliance, whatever partners do.
Before engaging anyone, confirm that a named owner and reviewer exist for each monitoring source.
An implementation partner prepares the systems that produce monitoring evidence. DeployOpen works in this role. Work typically covers deploying self-hosted open-source monitoring components inside your environment, configuring log sources, detection rules and vulnerability inventory, documenting the configuration, and assembling evidence packages. The partner does not decide the strategy and does not assess the results of its own work.
- Monitoring stack: deployment and hardening of tools such as Wazuh, OpenSearch Security Analytics and Fleet inside your cloud accounts, data centers or air-gapped network.
- Configuration: log source onboarding, detector and rule setup, alert routing and vulnerability feeds, with settings recorded in a form an assessor can read.
- Evidence preparation: screenshots, exported alert records, configuration files and procedure documents that show the strategy is being carried out.
- Integration: connecting monitoring output to your plan of action and milestones and your existing ticketing or case tools.
- Written scope: the partner's tasks, deliverables and exclusions should be agreed in writing before work starts, so the boundary between building and deciding is explicit.
Ask the partner which evidence it will hand over, and which tasks remain with your staff after go-live.
Testing and reporting belong to independent parties. Under NIST's FAQ, application and implementation of SP 800-171, and any compliance issues, are the responsibility of the federal agency that holds the contract or agreement with your organization, regardless of the organization's size. Depending on the contract and the assessment type, the agency or a DoD assessor evaluates your monitoring against 03.12.03 and its determination statements in SP 800-171A Rev. 3. DeployOpen does not issue assessments, scores or certifications.
- Independent testing: the assessor examines policy and strategy documents, interviews people with monitoring duties, and tests the monitoring mechanisms themselves.
- Reporting: results and any scores come from the assessing party, not from the team or partner that built the system.
- Line on independence: a partner that configured the monitoring may explain it and provide evidence, but should not grade it or write the assessment conclusion.
- Contract terms: confirm with the contracting officer which assessment applies and which SP 800-171 revision the contract names, since current guidance on revisions is changing.
- Preparation, not sign-off: readiness reviews by a partner help you find gaps before an assessor arrives, and should be labeled as such.
Before any engagement, confirm in writing who will assess the system and what they will accept as evidence.
Where 03.12.03 implementations usually fall short
Most 03.12.03 findings come from a monitoring program that exists on paper but is not connected to the assessments, POA&M and CUI boundary it is supposed to serve. The cards below cover the gaps assessors and internal reviewers most often find, with a check for each. Use them as a pre-assessment walk-through of your own strategy and evidence.
No documented system-level strategy
Many organizations monitor their systems but cannot produce a written system-level continuous monitoring strategy for the systems that store, process or transmit CUI. Assessors look for a document that names the system, the monitored controls, the monitoring tools, the frequency for each activity and the owner of each. Check that the strategy covers the CUI system itself and every in-scope enclave, not only the enterprise program. A generic organizational policy does not satisfy the system-level element.
Monitoring not linked to assessments
Logs, scanner output and alerts are often collected but never fed back into the periodic security assessments that 03.12.03 requires the monitoring to combine with. The result is an assessment that is run from a checklist while the monitoring data sits unused. Confirm that a named process takes monitoring results into the assessment cycle and records what was reviewed, when, and what changed as a result.
Alerts without triage records
Security tools generate alerts that are acknowledged in the console but have no record of who reviewed them, what was decided and why. An assessor interviewing responsible personnel will ask how a specific alert was handled and expects a traceable answer. Check that each alert or finding has a disposition (closed as benign, escalated, or tracked) with a timestamp and an accountable reviewer. Wazuh alerts written to alerts.json and OpenSearch Security Analytics findings both give you the raw record to tie triage notes to.
Undefined ODP frequencies
Rev. 3 leaves several monitoring frequencies and parameters to the organization when no federal agency specifies them. A strategy that says monitoring is ongoing or periodic without defined values gives an assessor nothing to test against. Record each organization-defined parameter that governs monitoring, assign a value, document the reason, and show that the system follows it. Ask your contracting officer whether any values have been specified before you finalize them.
Log sources outside the CUI boundary
Monitoring is often configured for the domain controllers and servers that the team manages directly, while endpoints, cloud control planes, network devices, VPN concentrators and SaaS admin logs that touch CUI are left out. An assessor will compare the boundary in the system security plan with the list of monitored sources and look for gaps. Build a source inventory that maps each in-scope asset to the log and scan feeds that cover it, and treat any unmonitored component as an open item to address or document.
POA&M entries not traced to monitoring
Plan of action and milestones entries are sometimes written from memory at the time of an assessment rather than from what monitoring actually detected. That breaks the link between 03.12.02 and 03.12.03 and makes it hard to show that known vulnerabilities and weaknesses were tracked to closure. Each POA&M item should cite the monitoring source that surfaced it, the date it was detected and the planned completion. Where CMMC Level 2 applies, note that 32 CFR 170.21 limits which requirements may be carried on a POA&M for Conditional status, so confirm the item is eligible before listing it.
How much effort and outside help does 03.12.03 need?
How long does it take to write a first continuous monitoring strategy?
The duration depends on how many systems are in scope, how well the environment is documented and how many monitoring tools already produce usable data, so no fixed timeline applies. The 03.12.03 requirement covers a system-level strategy, which means you first need a clear system boundary, a current component inventory and a list of the logs and scan results that already exist. Ask any implementation partner for a written scope that lists the systems, the deliverables and the milestones before work starts, and confirm which of those steps depend on your own change approvals.
Can an in-house team write and run the monitoring strategy?
Often yes, provided the team has someone who understands the system boundary, the security tooling and the assessment method in SP 800-171A Rev. 3. The strategy needs to be specific enough that an assessor can examine it, interview the people named in it and test the mechanisms it describes. Teams that lack staff with monitoring or logging experience, or that run many systems under one enclave, usually bring in outside help for the design and the first tooling setup, then keep the operation in house. Decide early which party owns each responsibility and write that split into the strategy.
What does the organization need to provide for this work?
The organization owns the controls, so it must provide access and decisions that no outside party can supply. In practice that means:
- A named owner for the continuous monitoring strategy and the people who receive its results
- Read access to logs, asset inventories and scanner output from the systems in scope
- Approved change windows for deploying agents, collectors and rules
- Documented thresholds for what triggers an alert, a ticket and a plan of action and milestones entry
- Time for the people who respond to findings and for the staff who will be interviewed during assessment
What drives the cost of continuous monitoring for 03.12.03?
The main cost drivers are the number of systems and locations in the boundary, the variety of log sources and cloud services, the amount of custom detection content you must write, and the state of your existing documentation. Software licensing is only one component. Staff time for design, tuning, alert review and evidence collection usually makes up more of the total, and it recurs. Open-source platforms remove license fees but still require hosting, storage, maintenance and upgrades inside your environment. Ask for a quote that separates one-time setup from recurring operations, and ask which items are your own staff hours rather than vendor charges.
Can a partner run continuous monitoring after handover?
Yes, DeployOpen offers ongoing support and upgrades as retainers, which can cover tuning detection rules, reviewing platform health, applying upgrades and refreshing evidence between assessments. Support is agreed in writing, so define what the retainer includes, how quickly the partner responds to platform issues and who reviews findings each period. The platform stays in your own infrastructure throughout. Your team still makes the risk decisions and owns the strategy, and only an independent assessor can issue an assessment result.
Does the Rev. 2 3.12.3 wording in CMMC still apply to this requirement?
Yes, for CMMC Level 2 assessments. The CMMC rule makes Level 2 identical to SP 800-171 Rev. 2, so the equivalent of 03.12.03 is assessed as CA.L2-3.12.3 and carries 5 points in the scoring methodology. A plan of action and milestones cannot cover that practice for Conditional status under the CMMC rule. NIST's change analysis classifies the Rev. 2 to Rev. 3 change for this requirement as minor, but you should still map your evidence to the wording your contract and assessor use. Confirm the current status of CMMC and DFARS requirements with your contracting officer, because the DoD has issued changing guidance in 2026.
What should I ask an implementation partner before signing?
Ask for a written scope that names the systems in the boundary, the monitoring sources to be onboarded, the detection tools and their licenses, and the evidence each deliverable produces. Ask who writes the strategy, who tunes alerts, who keeps the platform patched and what happens to the configuration when the engagement ends. Confirm that the partner prepares evidence but does not issue assessment reports, and ask how it will coordinate with your independent assessor. A clear answer to each of these points makes the quote comparable with others.
How DeployOpen prepares monitoring evidence for 03.12.03
DeployOpen starts with a written, fixed scope that names the systems in the CUI boundary, the log sources to be ingested, the monitoring components to be deployed and the strategy documents to be delivered. The scope also records who in your organization owns each control, because 03.12.03 asks for a system-level continuous monitoring strategy that your organization must own and approve. A quote follows from that written scope, so the cost reflects the systems and log sources you actually have, not a standard package. Confirm the boundary and the list of log sources with your security team before any quote is requested.
Inside your own cloud accounts, data centers or air-gapped network, DeployOpen deploys self-hosted open-source components that match the scope. Typical choices include OpenSearch Security Analytics for Sigma-based detectors and correlation across log types, Wazuh for rule-based alerting and its alerts.log and alerts.json outputs, and Fleet for vulnerability detection on enrolled hosts. Each component is configured to ingest the agreed sources, and the detector, rule and alert settings are documented so an assessor can trace a monitored event to a finding and a response. Confirm with each vendor which features your chosen version supports before committing the design.
DeployOpen then prepares the evidence an assessor will examine: the organizational and system-level continuous monitoring strategies, the security assessment and monitoring policy and procedures, configuration records, sample alerts and findings, and the records showing who reviews them. Those records map to the examine, interview and test objects in SP 800-171A Rev. 3 for 03.12.03, so your personnel can explain them in interviews. At handover, your staff receive runbooks and admin training so the monitoring runs under your ownership. DeployOpen does not issue audit reports or certifications. An independent assessor or certification body makes that determination, and DeployOpen's role ends at preparing the systems and evidence described in the written scope.
