Self-attestation fails when organisations can describe controls but cannot prove they operate consistently under review. In practice, that creates gaps in evidence, scoping, and remediation tracking, which CMMC is designed to expose. Defence contractors should assume that undocumented access boundaries, weak POA&Ms, and incomplete supplier records will be treated as control failures, not administrative oversights.
Why This Matters for Security Teams
Self-attestation is not the same as demonstrable compliance. For DFARS and related defence supply chain obligations, what matters is whether controls are defined, implemented, monitored, and evidenced under scrutiny. A contractor can claim alignment with the NIST Cybersecurity Framework 2.0 or internal policy, but if access boundaries, logging, remediation, and supplier oversight cannot be shown consistently, the claim carries little operational weight.
The main risk is false confidence. Self-attestation tends to emphasise policy language, while assessors and prime contractors look for proof that the control actually works in production. That includes repeatable evidence for account management, incident response, configuration control, and exceptions handling. It also means the organisation has to understand its scope: which systems process covered data, which suppliers are in scope, and where inherited controls stop.
For defence work, the difference between saying a control exists and proving it is often the difference between passing review and failing it. In practice, many security teams encounter this only after a supplier questionnaire, audit, or contract review has already exposed the gap.
How It Works in Practice
In practice, DFARS-related expectations are usually tested through evidence collection, not narrative assurances. The control set may be mapped to NIST SP 800-53, the NIST SP 800-53 Rev 5 Security and Privacy Controls, or an internal compliance matrix, but reviewers will still expect artefacts that show the controls operate over time. That can include access reviews, system inventories, patch records, ticket history, alert handling, and supplier attestations tied to a defined scope.
A workable programme usually includes:
- Clear scope definition for covered systems, users, and suppliers.
- Documented control ownership with named accountability for each requirement.
- Repeatable evidence collection for operational controls, not just policy approval.
- POA&M tracking that shows findings, remediation dates, and closure evidence.
- Independent review of exceptions, inherited controls, and outsourced services.
Teams that rely only on self-attestation often miss the control-operating proof that matters most: whether a privileged account review happened on time, whether inactive accounts were disabled, whether subcontractor access was actually restricted, and whether logs were retained and reviewed as required. ISO-based governance models help here, especially ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls, because they force control ownership, evidence discipline, and continual improvement rather than one-time declarations.
Where identity and access are involved, the practical test is whether the organisation can prove least privilege, privileged access management, and supplier segregation in real records, not just in policy wording. These controls tend to break down when environments are spread across multiple inherited networks and subcontractors because evidence ownership becomes fragmented and remediation stalls between parties.
Common Variations and Edge Cases
Tighter compliance documentation often increases administrative overhead, requiring organisations to balance auditability against delivery speed. That tradeoff is real, especially for smaller defence suppliers that do not have dedicated governance teams. Current guidance suggests that the answer is not lighter controls, but better scoping and evidence discipline so the right systems are assessed without overextending the business.
There is no universal standard for this yet across every contract interpretation, so some organisations treat self-attestation as a starting point and others as a weak signal that must be backed by independent validation. The practical difference is whether third-party assessment, internal audit, or customer review will challenge the evidence. In higher-risk supply chains, that challenge is increasingly expected rather than exceptional.
Edge cases often appear when controls are inherited from a parent company, hosted in shared services, or delegated to cloud and managed service providers. In those environments, a statement of compliance can look complete while the actual proof sits elsewhere. If the organisation cannot retrieve timely evidence for access governance, configuration baselines, or supplier flow-downs, the attestation is unlikely to survive review. Security teams should treat that as a control design problem, not a paperwork problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk governance must support evidence-based compliance, not claims alone. |
| NIST SP 800-53 Rev 5 | CA-2 | Assessment controls require verification of implementation, not self-declared status. |
Define compliance ownership and review evidence as part of your governance process.
Related resources from NHI Mgmt Group
- What fails when a CMMC self-assessment is based on outdated evidence?
- What breaks when CMMC readiness is based on self-attestation instead of evidence?
- What is the difference between policy compliance and evidence-based compliance for AI systems?
- Why do compliance programs fail to stop identity-based breaches?
