Cyberuptive

Buyer's guide

MDR for defense contractors handling CUI: what actually satisfies the assessment.

Most MDR vendor pages promise "CMMC support" without answering the question a C3PAO will ask. This is that answer. Where MDR fits in an SP 800-171 environment, what it satisfies and what it doesn't, and the six things to verify before you sign.

The shape of the problem

A defense contractor handling Controlled Unclassified Information (CUI) has to satisfy the 110 requirements of NIST SP 800-171 Rev 2 today, with Rev 3 tracking in the background for the eventual DoD rulemaking that will replace it. Managed Detection and Response is not one of those requirements. It's an operational service that contributes evidence to several of them, if the contract is written correctly. When it isn't, an MDR contract can actually create new gaps: undocumented data flows across the CUI boundary, analyst access without personnel screening evidence, telemetry stored in a cloud that doesn't meet DFARS 252.204-7012, and shared consoles that can't survive a C3PAO walkthrough.

The good news: this is fixable. The bad news: fixing it after you've signed is expensive. Most of what follows is the conversation you should have before the contract is drafted, not the remediation project that starts three weeks before your assessment.

Draw the CUI boundary before you shop

The single most useful artifact you can produce before evaluating any MDR is a current data-flow diagram of your CUI environment. Where does CUI enter (email attachments from primes, portal downloads, USB from lab equipment)? Where does it live (file shares, engineering workstations, GCC High mailboxes, ERP subsystems)? Where does it move (mobile devices, backups, third-party manufacturing partners)? Every user, system, and third party that touches CUI is inside the boundary of your System Security Plan (SSP). Everyone else is outside.

An MDR provider is, by definition, outside the boundary looking in. Their agents run on endpoints inside the boundary. Their telemetry crosses out of the boundary to a SIEM or data lake somewhere. Their analysts sit at consoles outside the boundary and reach in. The SSP has to document each of those transitions. The MDR contract has to make those transitions defensible. If either of those documents is silent on the MDR's data flows, you have a gap before an attacker ever shows up.

U.S. persons on U.S. soil, in writing

CUI is unclassified information. Handling it does not require security clearances. Handling it does require U.S. persons on U.S. soil per DFARS 252.204-7012 and the personnel-screening controls in SP 800-171 requirement family 3.9. Every analyst who can see raw telemetry from your CUI environment, and every engineer with production access to your MDR's back-end infrastructure, has to be a U.S. person. This applies to Tier 1 triage as much as it applies to senior threat hunters.

Most large managed-security providers run global follow-the-sun rotations for cost reasons. That model is fine for their commercial customers. It is not fine for a CUI environment unless the provider has carved out a dedicated U.S.-only pool with documented personnel, cleared access boundaries, and audit evidence that non-U.S. analysts cannot see your data. Ask for the contract clause that memorializes this, ask for the evidence artifact that supports it, and ask what happens when a U.S. analyst is on vacation. If the answer involves "our global team backs them up," walk.

We operate a 24/7 follow-the-sun SOC staffed entirely by U.S.-based analysts across multiple mainland time zones plus our Honolulu HQ. For CMMC and DFARS customers we scope dedicated U.S.-persons analyst pools and document personnel handling in the SSP. This is table stakes for CUI work, not a premium tier.

GCC High, FedRAMP, and where the CUI actually lives

DFARS 252.204-7012 requires cloud services used to process CUI to be FedRAMP Moderate equivalent or higher. For Microsoft 365, that means GCC High or Azure Government, not commercial and not GCC (without "High"). GCC handles some federal data types but does not meet DFARS for CUI or ITAR. GCC High does. Commercial does not.

This matters for MDR because most MDR providers built their platforms on commercial cloud (AWS commercial, Azure commercial, GCP). If their SIEM, data lake, or analyst console stores CUI-derived telemetry, that infrastructure has to meet FedRAMP Moderate equivalence. Three architectures pass:

  1. 1. MDR operates on your tenancy. Endpoint telemetry stays in your GCC High Sentinel workspace, analysts reach in via just-in-time RBAC, no bulk telemetry crosses out. Cleanest boundary; highest operational cost.
  2. 2. MDR operates its own GovCloud or FedRAMP High platform. Provider's back end is authorized separately, telemetry moves into that boundary rather than yours. Cost is spread across customers; you inherit the provider's authorization posture.
  3. 3. Hybrid: metadata to commercial, CUI-adjacent data stays in your tenancy. Requires precise data classification and constant vigilance; realistic only with a mature MDR partner who has done this before. Common failure mode: telemetry drift over time as new log sources are onboarded without re-review.

Do not assume the MDR salesperson understands the difference between these architectures. Get the data-flow diagram from their SE, in writing, before contract.

Single-tenant vs multi-tenant SOC: what actually differs

A multi-tenant SOC pools analysts across customers. On the same shift, the same analyst may triage alerts from a healthcare system, a manufacturer, and a defense sub. Multi-tenant is the dominant model for economic reasons: staffing 24/7 with dedicated analysts per customer is prohibitively expensive at anything below the enterprise tier.

Multi-tenant is not disqualifying for CMMC. What matters is whether the SOC can prove access segregation to a C3PAO. Specifically: named individual analysts with documented personnel-screening evidence, per-customer RBAC that surfaces only your data on the analyst's console, audit logs that show every analyst action against your telemetry, and an evidence pack for the assessment that maps to SP 800-171 3.1 (Access Control) and 3.3 (Audit and Accountability).

Single-tenant SOCs — dedicated analysts who see only your environment — sidestep the access-control complexity but cost significantly more. For most mid-market defense subs, the right answer is a multi-tenant SOC that has invested in the evidence infrastructure. Ask for a sample redacted evidence pack from a prior C3PAO assessment. If they can't produce one, they haven't done this work at scale yet, and you don't want to be their pilot customer.

We wrote a longer breakdown of the tenancy question in our single-tenant vs segregated SOC comparison, which extends the analysis with pricing bands and the specific audit questions a C3PAO tends to ask.

What MDR actually satisfies in SP 800-171

MDR is not a control. It's a service that contributes evidence to specific control families. The mapping below is the one we use when we write SOWs for CMMC-scoped customers. It's not exhaustive — a full MSSP contract touches more families — but these are the requirements MDR is expected to carry on its own.

Family Requirement What MDR delivers
3.6 Incident Response3.6.1, 3.6.2, 3.6.324/7 detection, documented IR runbooks, containment authority, quarterly IR exercises, evidence artifacts per incident.
3.11 Risk Assessment3.11.2, 3.11.3Continuous vulnerability posture, remediation tracking, quarterly risk summaries mapped to threat intelligence.
3.13 System & Comm. Protection3.13.1, 3.13.6Boundary monitoring, network flow analysis, TLS inspection where authorized, egress anomaly detection.
3.14 System & Info. Integrity3.14.1, 3.14.6, 3.14.7Flaw remediation tracking, indicator-of-attack detection, unauthorized-use detection, quarterly threat-hunt reports.
3.3 Audit & Accountability3.3.1, 3.3.5Log aggregation, retention, review cadence, chain-of-custody for security-relevant events.
3.1 Access ControlIndirect (via 3.1.12)Monitoring of privileged and remote sessions; MDR detects anomalous access, does not enforce policy.

Everything else — physical security, media protection, personnel screening, configuration management, awareness & training, identification & authentication — is outside MDR's scope. MDR alone will not pass a C3PAO assessment.

The six-question evaluation before you sign

  1. 1. Show me the data-flow diagram. Where does telemetry from my CUI environment go? What's stored, for how long, in which cloud, under which authorization? If they can't answer in one meeting, they haven't done this at scale.
  2. 2. Show me the U.S.-persons contract clause. Not the marketing page. The specific clause that names your entitlement to U.S.-only handling, including for backup coverage. Ask what happens on Christmas Eve.
  3. 3. Show me a redacted prior C3PAO evidence pack. The MDR provider has been through a customer's Level 2 assessment. What did they hand the assessor? If they can't produce it, they haven't been through one yet.
  4. 4. Show me the access-control model for my telemetry. Named individuals or roles? Just-in-time or standing access? How is analyst activity audited? How is that audit produced for me on request?
  5. 5. Show me how you handle a "boundary event." An analyst has to pivot to a customer system to complete an investigation. What's the change-control process, what's logged, what's reported back to us? Boundary events are common; unmanaged boundary events fail assessments.
  6. 6. Show me your SP 800-171 control mapping. Which requirements does the MDR contract directly satisfy, which does it contribute to, and which are explicitly out of scope? Get this in writing. If they hand you a document that claims to "cover" all 110 requirements, they don't understand the framework.

Phase 2 suspension: what changed, what didn't

On July 13, 2026 the Department of War (renamed from DoD) suspended CMMC Phase 2 — the third-party C3PAO assessment milestone that was scheduled to take effect November 10, 2026 — and stood up a 60-day CMMC Reform Task Force to review the entire program. During the review, contracts may include CMMC Level 1 (Self) or Level 2 (Self) assessment requirements only. C3PAO and DIBCAC designations are barred. Waivers are barred. Existing contracts that include C3PAO requirements must be amended to remove them.

What did not change: DFARS 252.204-7012, NIST SP 800-171 Rev 2, CMMC Level 1 and Level 2 self-assessments in SPRS, annual senior-official affirmation, the 72-hour cyber incident reporting requirement, and FedRAMP Moderate equivalence for cloud storage of CUI. If your program is subject to DFARS 7012, you are still subject to every operational security requirement it references. The change is only in who validates it.

Self-attestation is not a lower bar. A senior official at your company signs an SPRS affirmation each year, under False Claims Act exposure, that all 110 controls are implemented. The DOJ's Civil Cyber-Fraud Initiative has already produced multi-million-dollar settlements against contractors who misrepresented their SP 800-171 posture. The Phase 2 pause removes the auditor from the room; it does not remove the liability.

Practical implication for MDR buyers: the MDR conversation just became more important, not less. When third-party assessment returns in some form — and it will — the contractors who used the pause to build defensible programs will be positioned for award. The ones who took the pause as permission to defer are exposed both to a False Claims Act theory today and to a rushed remediation project when the reform task force reports.

Rev 2, Rev 3, and where the goalposts are moving

NIST SP 800-171 Rev 3 was finalized on May 14, 2024. Two weeks earlier, on May 2, 2024, DoD issued a class deviation keeping DFARS 252.204-7012 tied to Rev 2 with no expiration date. In April 2025 DoD published mandatory Organization-Defined Parameters (ODPs) for Rev 3 but has not amended 32 CFR Part 170 to require Rev 3 in CMMC assessments. As of August 2026, CMMC Level 2 assessments (self- or otherwise) still run against Rev 2's 110 requirements.

Practical implication for MDR buyers: build to Rev 2 today, and track Rev 3 delta items in your SSP as "monitoring." The largest changes in Rev 3 that affect MDR are the expanded audit and monitoring requirements (3.3 family), tighter incident-response documentation (3.6 family), and new controls around threat hunting and continuous monitoring. A modern MDR contract can and should already deliver evidence that meets Rev 3 by default. If yours can't, that's a signal to renegotiate before the eventual Rev 3-scoped assessment cycle begins.

What MDR alone will not do

MDR is a component, not the compliance program. It does not write your SSP. It does not classify your CUI or draw your boundary. It does not train your workforce (3.2 Awareness & Training). It does not manage your physical security (3.10 Physical Protection) or your media handling (3.8 Media Protection). It does not scope your Plan of Action & Milestones (POA&M). It does not represent you to the C3PAO. If the sales conversation is framing MDR as "your CMMC solution," push back — it's part of your compliance program, sitting alongside your CMMC advisory, SSP development, and assessment prep.

The right MDR partner tells you exactly what they cover and exactly what they don't, and helps you identify the other providers or internal capabilities you need to fill the rest.

How Cyberuptive delivers this

We run 24/7 Managed Detection and Response with U.S.-persons handling and pre-authorized containment, on a Trellix and Microsoft stack that operates in GCC High for CUI customers. Analyst access to CUI-scoped tenants runs through dedicated U.S. pools with named individuals and per-customer RBAC. Every incident and every quarterly report is written to double as SP 800-171 evidence. When a C3PAO shows up, our customers hand over a pre-built evidence pack, not a scramble.

We also do the work the MDR by itself won't: SSP development and CMMC advisory, vulnerability management, managed firewall, and full SOC-as-a-Service, so a defense sub can operate a Level 2 environment with one provider rather than five. Third-party validation of the architecture: Trellix and AWS have both published customer stories about how we run this stack in production, and Harvard Business Review covered the AI-augmented investigation pipeline that underpins it.

What to do next

If you already have an MDR contract, pull it out and answer the six questions in section "the six-question evaluation" above from what's actually written on paper. Every "no" or "unclear" is an addendum you should be negotiating before you file your next SPRS self-attestation. If you don't have MDR yet, the right sequence is: draw the CUI boundary, define the data flows, and only then start MDR vendor conversations. Shopping first, drawing the boundary later, is the most expensive way to do this — and the Phase 2 suspension does not make it cheaper.

If you'd like a second pair of eyes on the boundary or the MDR contract, schedule a 30-minute call. We'll tell you what's already in good shape, what's a gap, and what's a gap we can close. No sales theater, and no obligation to move your MDR.

Aloha, let's talk

Ready to compare your MDR against a C3PAO's checklist?

A 30-minute call will tell you whether your current MDR (or the one you're evaluating) is structurally eligible for a CUI environment, before the assessment finds out for you.