If you handle Federal Contract Information (FCI) on a Department of Defense contract, you have to attest to 15 specific cybersecurity safeguarding requirements in SPRS— the DoD's Supplier Performance Risk System — before you can keep that contract. Those 15 requirements are CMMC Level 1, and they're the exact same controls written into FAR 52.204-21(b)(1)(i)–(xv), the “Basic Safeguarding of Covered Contractor Information Systems” clause that the government has been quietly putting in contracts since 2016.
The problem isn't the requirements themselves — most of them are common sense. The problem is that they're written in cybersecurity jargon that a five-person defense-tech startup cannot reasonably parse. So below is every single one in plain English, with the evidence you actually need to satisfy it.
What CMMC Level 1 actually is
CMMC Level 1 is a self-attestation. You implement all 15 safeguarding requirements, you submit a SPRS affirmation signed by a senior official, and you're bid-eligible for any DoD contract that flows down FCI. There is no third-party assessor for Level 1; you sign your name and you live with the consequences if you're wrong (more on that in our SPRS score guide).
The 15 safeguarding requirements are organized into six families. Each is identified in FAR 52.204-21(b)(1) by Roman numeral (i–xv) and maps to a named CMMC practice (e.g. AC.L1-3.1.1) in the official CMMC Assessment Guide. Below, every requirement is paired with what it means, what evidence satisfies it, and where teams typically trip up.
Access Control (AC) — 4 requirements
AC.L1-3.1.1 — Limit access to authorized users
Plain English:Only people who work for you (or whom you've formally invited) can sign into the systems where FCI lives. No shared accounts. No “the intern uses the founder's login.”
Evidence that satisfies it: a signed Authorized Users Roster(name, role, system, date access granted) and a screenshot of your identity provider showing the same names — Microsoft 365 admin center, Google Workspace admin, Okta, or whatever you use. The two have to match.
AC.L1-3.1.2 — Limit transactions and functions to those users are authorized to perform
Plain English:Not everyone gets admin. Engineering gets engineering, finance gets finance, the receptionist doesn't get production database access.
Evidence: a role matrixmapping job title to system permissions, plus a screenshot of role assignments in your IdP. If you're using M365, that's the Roles & admins page; in Google Workspace, it's Admin roles.
AC.L1-3.1.20 — Verify and control connections to external systems
Plain English: If your laptops or servers connect out to third-party SaaS, partner networks, or contractor systems, you have to know which ones and you have to control them.
Evidence: an External Systems Inventorylisting every SaaS app and partner network you connect to, plus the policy or admin setting that approves it. Most teams build this inventory by exporting the OAuth grants from M365/Google.
AC.L1-3.1.22 — Control information posted publicly
Plain English:Before anything goes on your public website or social media, someone makes sure it's not FCI. That sounds obvious until your sales engineer tweets a screenshot of a slide deck with a customer logo on it.
Evidence: a brief written posting policy and a signed acknowledgment from anyone with authority to publish on behalf of the company.
Identification & Authentication (IA) — 2 requirements
IA.L1-3.5.1 — Identify users and devices
Plain English:Every person and every device that touches your systems has a unique, traceable identity. No “laptop3” or “dev-machine.” Real names, real hostnames, in a real inventory.
Evidence: Your authorized users roster (covers people) plus an Access Device Register listing every laptop, desktop, and managed phone with hostname, owner, and OS. Microsoft Intune and Google Endpoint Management both export this.
IA.L1-3.5.2 — Authenticate users and devices
Plain English:Passwords alone aren't good enough. You need multi-factor authentication (MFA) on the systems where FCI lives. This is the single highest-leverage practice on the list and the one most failed audits hinge on.
Evidence:a screenshot of your IdP's MFA enforcement policy showing it applies to all users, plus a current MFA enrollment report. SMS-based MFA technically counts at L1, but TOTP (Authenticator app) or hardware keys are the right answer.
Media Protection (MP) — 1 requirement
MP.L1-3.8.3 — Sanitize media before disposal or reuse
Plain English:When a laptop, USB drive, or hard disk leaves the company — sale, donation, trash, RMA — the data on it is gone. Cryptographic erase, full disk wipe, or physical destruction.
Evidence: a Media Disposal Log with serial number, disposal date, method (NIST 800-88 wipe / shredded / crypto-erased), and the name of the person who did it. One row per retired device.
Physical Protection (PE) — 2 requirements
PE.L1-3.10.1 — Limit physical access to organizational systems
Plain English:Random people can't walk into the room with your servers, your network closet, or the desks where FCI is on screen.
Evidence: a Physical Access Roster— who has badge, key, or door-code access to FCI areas. If you work from a coworking space or home offices, document that explicitly and describe the lock-and-key controls that apply.
PE.L1-3.10.3 — Escort visitors and monitor visitor activity
Plain English: If a non-employee comes into your FCI area, an employee is with them the whole time and you write down that they came in.
Evidence: a Visitor Log— date, name, company, escort, time in, time out.
PE.L1-3.10.4 — Maintain audit logs of physical access
Plain English:The visitor log lives somewhere durable, and it's preserved. If the door has a badge reader, keep its logs too.
Evidence: the visitor log itself, retained for at least 1 year, plus an export of badge-reader access events if applicable.
PE.L1-3.10.5 — Control and manage physical access devices
Plain English: You know how many keys, badges, and door codes exist; you know who has each one; and you take them back when employees leave.
Evidence: an Access Device Register with the issued/returned columns filled out.
System & Communications Protection (SC) — 2 requirements
SC.L1-3.13.1 — Monitor, control, and protect organizational communications at the boundaries
Plain English:You have a firewall (or a managed cloud equivalent) between your network and the internet, and you've configured it. The default-deny rule is in place.
Evidence: a Network Boundary Inventorylisting each boundary device (router, firewall, VPN concentrator, cloud security group), the rule set, and the last review date.
SC.L1-3.13.5 — Implement subnetworks for publicly accessible system components
Plain English:Anything that's on the public internet (your website, your customer portal) lives in a separate network segment from your internal systems. Classic DMZ pattern, or a public/private subnet split in AWS/Azure/GCP.
Evidence:a network diagram — even a whiteboard photo — showing the public subnet separate from the private one, and the firewall rules that enforce the boundary.
System & Information Integrity (SI) — 4 requirements
SI.L1-3.14.1 — Identify, report, and correct system flaws in a timely manner
Plain English: You patch your stuff. Operating system updates, browser updates, server updates, on a regular cadence.
Evidence: a Patch Log showing the last time each managed device was patched. Microsoft Intune, Jamf, and Google Endpoint Management all produce this directly.
SI.L1-3.14.2 — Provide protection from malicious code
Plain English:Anti-malware is installed and running on every endpoint where FCI is processed. Microsoft Defender for Endpoint, CrowdStrike, SentinelOne — pick one, use it, prove it.
Evidence: an Endpoint Antivirus Inventory— device, antivirus product, version, last-seen date, definitions date.
SI.L1-3.14.4 — Update malicious code protection mechanisms
Plain English: Definitions and engine versions are kept current. Automatic updates count.
Evidence: the same inventory above, with the definitions date column actually populated and recent.
SI.L1-3.14.5 — Perform periodic and real-time scans
Plain English: Your antivirus runs both scheduled scans and real-time / on-access scanning. The default settings on Defender, CrowdStrike, etc. cover this; you just have to confirm nobody turned them off.
Evidence: a screenshot of the scan policy showing both modes enabled, and a recent scan results export.
How to actually implement these in a week
Most small contractors lose 80–120 hours of founder time attempting to interpret these practices, build the artifacts, and write the SSP. That's the consultant arbitrage: $9,000–$30,000 in fees chasing what's ultimately a structured data-collection problem.
The faster path is to start with the templates. Custodia's platform ships every roster and log in this article as a CSV you can fill in, walks you through each practice in plain English with prompts tailored to your tech stack (M365, Google Workspace, Okta, AWS), and auto-drafts your SSP narrative as you go. Most users complete a defensible package in 3–5 business days.
FAQ
How is CMMC Level 1 different from Level 2?
Level 1 covers FCI and is a self-attestation. Level 2 covers CUI, requires NIST 800-171's 110 controls, and (for prioritized contracts) requires a third-party assessor. See the comparison.
Do I need a third-party assessor?
No. CMMC Level 1 is a self-assessment with annual self-affirmation in SPRS by a senior official.
What if I implement 14 of 15 safeguarding requirements?
Your SPRS affirmation has to be all 15 met or you're non-affirming. Level 1 is binary. There's no partial credit.
How often do I have to re-affirm?
Annually. Custodia members get the next cycle prepped automatically every October — no extra fee, no fire drill.
“Federal contractors who treat compliance as a one-week sprint plus a year-round watch always beat the ones who treat it as a consulting engagement.”— The Custodia Compliance Team