Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / CMMC Level 1 Requirements: A Complete Guide

CMMC Level 1 Requirements: A Complete Guide

Phase 1 of the Cybersecurity Maturity Model Certification program went live on November 10, 2025. From that date, the Department of Defense can write CMMC requirements directly into new solicitations, and contractors who handle even basic government data cannot win awards without a current CMMC status in the Supplier Performance Risk System (SPRS). For roughly 63 percent of the Defense Industrial Base, that means Level 1: 15 foundational safeguards, an annual self-assessment, and a signed affirmation from a senior official.

Level 1 is the smallest version of CMMC. It is also the one most contractors are about to encounter first, and the one with the highest false-confidence rate. This guide covers every requirement, every assessment objective, and every step from scoping to SPRS submission.

CMMC Level 1 Requirements Guide

What Is CMMC Level 1?

CMMC Level 1 (Foundational) is the entry tier of the Cybersecurity Maturity Model Certification program, codified in 32 CFR Part 170. It requires defense contractors who handle Federal Contract Information (FCI) to implement 15 basic safeguarding practices and to confirm that implementation through an annual self-assessment.

The 15 practices come directly from FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, a clause that has technically applied to federal contractors since 2016. What CMMC added is an assessment methodology and a verification mechanism. Until CMMC, no one was checking whether contractors actually did the 15 things they were contractually obligated to do. Under the final CMMC Program Rule, effective December 16, 2024, that gap is closed.

Earlier CMMC drafts described Level 1 as a 17-practice framework because three physical-protection requirements were listed separately. The final rule consolidates them, and the official count now sits at 15 practices with 17 underlying assessment objectives drawn from NIST SP 800-171A. Both numbers are correct, depending on which level of granularity you are working at.

What Is the Purpose of CMMC Level 1?

The purpose is narrow and specific: to protect FCI from unauthorized disclosure. 

FCI is information the federal government either generates or receives during contract performance that is not intended for public release. Think proposal correspondence, delivery schedules, performance reports, and routine contract communications. None of it is classified. None of it is even particularly sensitive in the traditional sense. But aggregated across thousands of contractors and exposed to adversaries, it gives a meaningful picture of what the U.S. government is buying, from whom, and on what timeline.

Level 1 exists because too much of the Defense Industrial Base was failing to apply even basic hygiene to that data. CMMC Level 1 turns inconsistent expectations into a yearly verification cycle.

CMMC Level 1 Scope

The CMMC Assessment Scope for Level 1 is defined in the official DoD CMMC Level 1 Scoping Guide. It covers every information system that processes, stores, or transmits FCI, along with the people, processes, and physical facilities that interact with those systems.

In practical terms, scope includes workstations and servers that handle FCI, cloud services used to store or transmit FCI, email systems used to send or receive FCI, file-sharing platforms holding FCI documents, network infrastructure carrying FCI traffic, physical facilities where any of the above are located, and personnel with access to any of the above.

Anything that does not touch FCI is out of scope. This is the simplest scoping model in CMMC, and it is also where most contractors trip up. The temptation is to declare a narrow scope (“just the one folder on the file server”) and ignore the email, the laptops, and the backups. Auditors and primes will not accept it.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

CMMC Level 1 Requirements: All 15 Practices Explained

The 15 practices fall across six domains. Each is mapped to a NIST SP 800-171 control identifier, but Level 1 only assesses the subset of objectives relevant to FCI.

Access Control (AC)

AC.L1-B.1.I – Authorized Access Control

Practice: Limit information system access to authorized users, processes acting on behalf of authorized users, or devices.

Maintain a current list of users, processes, and devices authorized to access systems holding FCI. This means active user-account management: unique identifiers for each user, accounts disabled promptly when employment ends, and a documented process for reviewing who has access and why. Shared credentials are not acceptable. This is the foundation every other access control practice is built on, and it is where many contractors have their first reckoning with how loosely their environments have actually been managed.

AC.L1-B.1.II – Transaction and Function Control

Practice: Limit information system access to the types of transactions and functions that authorized users are permitted to execute.

Apply the principle of least privilege. A user with access to read FCI does not automatically get access to delete it, share it externally, or modify system configurations. Role-based access controls (RBAC) satisfy this requirement. In practice, this means auditing what each role can actually do in your systems and trimming permissions down to what is genuinely necessary for the job function.

AC.L1-B.1.III – External Connections

Practice: Verify and control or limit connections to and use of external information systems.

Know what external systems your in-scope environment connects to — cloud storage, partner networks, contractor laptops on home Wi-Fi — and apply controls to those connections. Acceptable Use Policies, VPN requirements, and explicit allow-lists for external sharing all map here. The key word is verify: you need documented evidence that external connections are inventoried and controlled, not just assumed to be fine.

AC.L1-B.1.IV – Control Public Information

Practice: Control information posted or processed on publicly accessible information systems.

Make sure FCI does not end up on your public website, your company blog, or any other publicly accessible system. This is mostly a process control: establish who is allowed to publish to public-facing systems and what review happens before anything goes live. It sounds obvious, but incidents involving inadvertent FCI disclosure through company websites and public repositories are more common than the industry likes to admit.

Identification and Authentication (IA)

IA.L1-B.1.V – Identification

Practice: Identify information system users, processes acting on behalf of users, or devices.

Every user, service account, and device that accesses FCI must have a unique identifier. Shared accounts — the classic “admin” login that three people use — are not acceptable. This applies to human users, automated processes, and devices alike. Document your user inventory and tie every access event to a specific, identifiable entity.

IA.L1-B.1.VI – Authentication

Practice: Authenticate (or verify) the identities of those users, processes, or devices as a prerequisite to allowing access to organizational information systems.

Passwords, multi-factor authentication, certificates, or biometric controls. Level 1 does not mandate MFA the way Level 2 does, but most modern environments implement it as the practical default — and assessors will note when they see environments that do not. Password complexity requirements, account lockout policies, and password reuse restrictions all live under this practice. For a deeper look at how authentication requirements scale across CMMC levels, the CMMC encryption requirements guide covers related technical controls in detail.

Media Protection (MP)

MP.L1-B.1.VII – Media Disposal

Practice: Sanitize or destroy information system media containing FCI before disposal or release for reuse.

When you decommission a hard drive, a USB stick, or a printer with internal storage, you must wipe or destroy it before it leaves your control. NIST SP 800-88 sanitization procedures define what “wiped” means in practice: a quick format is not enough for most media types. Throwing old laptops in a donation bin or the dumpster is an explicit failure of this control, and it is one of the most common findings in Level 1 assessments.

Physical Protection (PE)

PE.L1-B.1.VIII – Limit Physical Access

Practice: Limit physical access to organizational information systems, equipment, and the respective operating environments to authorized individuals.

Locked server rooms, badge-access offices, and clean-desk policies. If anyone can walk into your office and sit down at an unlocked workstation holding FCI, you fail this control. Physical access controls need to be commensurate with the environment: a home-based contractor and a 200-person manufacturer have different practical implementations, but the principle is the same.

PE.L1-B.1.IX – Manage Visitors and Physical Access

Practice: Escort visitors and monitor visitor activity; maintain audit logs of physical access; and control and manage physical access devices.

This practice combines visitor escort procedures, physical access logging, and management of access devices (badges, keys, smart cards) into a single practice with three assessment objectives. Visitor logs need to be real and current. Badge management needs to include a process for deactivating credentials when employees leave or access needs change.

Worth Knowing: The consolidation of PE.L1-B.1.IX

The consolidation of PE.L1-B.1.IX from three practices into one is why you will see both "17 practices" and "15 practices" in older guidance. The final 32 CFR Part 170 rule confirms the count is 15 practices with 17 assessment objectives. Vendors and consultants who still quote 17 practices are working from outdated drafts.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

System and Communications Protection (SC)

SC.L1-B.1.X – Boundary Protection

Practice: Monitor, control, and protect organizational communications at the external boundaries and key internal boundaries of the information systems.

Firewalls at the network perimeter, network segmentation between trust zones, and monitoring of traffic at boundary points. For a small business, this can be as simple as a properly configured firewall with explicit allow rules and logged traffic. The key requirement is that the boundary is defined, protected, and monitored — not just assumed to exist because you have a router.

SC.L1-B.1.XI – Public-Access System Separation

Practice: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Your public-facing web server should not sit on the same network as your internal file server. Use a DMZ, separate VLANs, or hosted cloud separation to ensure that a compromise of a public system does not give an attacker a direct path into FCI-handling systems. If you have no publicly accessible systems within your assessment scope, this practice can be marked Not Applicable — but document that determination carefully.

System and Information Integrity (SI)

SI.L1-B.1.XII – Flaw Remediation

Practice: Identify, report, and correct information and information system flaws in a timely manner.

Patch management. Operating systems, applications, firmware — all of it. “Timely” is not defined with hard SLA language at Level 1, but assessors expect a documented patching process and evidence that patches are actually being applied, not just scheduled. A two-year-old critical vulnerability sitting unpatched is a finding regardless of what your policy document says.

SI.L1-B.1.XIII – Malicious Code Protection

Practice: Provide protection from malicious code at appropriate locations within organizational information systems.

Endpoint antivirus or EDR, email gateway scanning, and protection at any point where files enter the environment. Cloud-based protection counts, provided it is actually deployed and active on in-scope assets. “We have a license” is not the same as “it is installed and running on every covered endpoint.”

SI.L1-B.1.XIV – Update Malicious Code Protection

Practice: Update malicious code protection mechanisms when new releases are available.

Automatic signature updates and engine updates. The control is about currency, not just deployment. An antivirus product with definitions six months out of date fails this practice, even if the software itself is installed and running. Verify that automatic updates are enabled and confirm through configuration evidence — not assumption.

SI.L1-B.1.XV – System and File Scanning

Practice: Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.

Scheduled full-system scans plus real-time on-access scanning. Most commercial antivirus and EDR products do both by default, but you need evidence that the configuration is enforced across all in-scope endpoints — not just on the machine the IT manager happens to use. Export your endpoint management console settings. That is your evidence.

CMMC Level 1 Compliance Checklist

CMMC Level 1 Compliance Checklist

Before you begin a self-assessment, work through the following steps. This will not certify you, but it will surface most of the problems contractors encounter on their first attempt.

Confirm FCI handling. Identify every contract, vendor relationship, and data flow involving FCI. Review your DoD contracts and subcontracts for FAR 52.204-21 clauses.

Define your assessment scope. Document every system, location, and person that touches FCI. Reference the official CMMC Level 1 Scoping Guide and be prepared to defend every boundary decision.

Inventory your assets. Workstations, servers, cloud accounts, mobile devices, network gear. If it touches FCI, it is in scope and it needs to be listed.

Map controls to systems. For each of the 15 practices, document which technical or administrative measure satisfies it on each in-scope system. The mapping needs to be explicit, not assumed.

Identify your Affirming Official. This must be a senior representative with authority to bind the organization — a CEO, president, or designated corporate officer. An IT manager is not sufficient.

Gather evidence. Screenshots, configuration exports, policy documents, training records, vendor attestations. Evidence must exist before the assessment, not be created afterward.

Run a gap assessment. Self-test each practice. Since no POA&Ms are allowed at Level 1, anything not fully met must be remediated before the formal self-assessment.

Document a basic System Security Plan. Level 1 does not formally require an SSP, but assessors and primes will ask for one, and it becomes mandatory the moment you advance to Level 2. Start it now.

Register for SPRS access. Your Affirming Official needs a Procurement Integrated Enterprise Environment (PIEE) account with the SPRS Cyber Vendor User role.

Submit results and affirmation. Enter your Level 1 self-assessment results in SPRS and have the Affirming Official sign the attestation.

CMMC Level 1 Artifact Retention Requirements

Under 32 CFR 170.15(c)(2), the artifacts used as evidence for your Level 1 self-assessment must be retained for six years from the CMMC Status Date — the date the assessment was completed and entered in SPRS.

Six years matters because the DoD or a prime can ask to inspect your evidence at any point in that window. Refusing or being unable to produce it can trigger contract remedies, including suspension or debarment. The retention requirement also intersects with False Claims Act liability: if the affirmation submitted to SPRS turns out to have been inaccurate, the evidence chain is what gets investigated.

Practical retention covers the completed self-assessment record (objective-by-objective), all evidence cited in MET determinations, the senior-official affirmation signed in SPRS, any supporting policies, screenshots, and configuration exports referenced, and records of the assessment methodology used.

Most contractors store this in a dedicated compliance repository with version control.

Anything less invites a scramble during the next assessment cycle, since some evidence (like firewall rule snapshots) changes constantly and is hard to reconstruct after the fact.

Phased Implementation Timeline and Key Deadlines

CMMC implementation is rolling out in four phases under 32 CFR 170.3(e), on a timeline tied to the publication of the 48 CFR Acquisition Rule.

December 16, 2024: The 32 CFR Part 170 final rule takes effect, codifying CMMC as a federal regulation.

September 10, 2025: The 48 CFR DFARS final rule is published, amending DFARS 252.204-7021 to embed CMMC contract clauses.

November 10, 2025: Phase 1 begins. DoD solicitations can include CMMC Level 1 and Level 2 self-assessment requirements. This is the live enforcement date.

November 10, 2026: Phase 2 begins. Level 2 certification assessments (C3PAO-led) appear in more contracts at DoD discretion.

November 10, 2027: Phase 3 begins. Level 3 certification assessments enter contracts for the most sensitive CUI.

Full implementation is expected approximately three years after Phase 1, at which point all applicable contracts will contain CMMC clauses.

For Level 1 contractors, the operative date is November 10, 2025. From that point forward, a current Level 1 status in SPRS is a precondition for award on covered contracts. You do not get to fix it after the solicitation drops.

CMMC Level 1 Certification Challenges

Most Level 1 failures come from a small set of recurring problems.

Scope creep and scope denial. Contractors either underscope (excluding email, mobile devices, or cloud storage that clearly handles FCI) or overscope (sweeping in systems that have no FCI exposure). Both create problems. Underscoping risks false attestation. Overscoping wastes resources and creates evidence gaps that are hard to defend.

Missing evidence for inherited controls. Many Level 1 environments rely on cloud services (Microsoft 365, Google Workspace, AWS) to satisfy several practices. Inheritance is legitimate, but you need attestations from the provider, and you need to know which controls are inherited versus customer-responsibility. The shared responsibility model is real, and assessors check it.

Documentation that does not match reality. Policies that say one thing while configurations do another. The policy says workstations lock after 15 minutes; the actual Group Policy locks them after 60. Auditors compare written claims to system reality, and discrepancies become NOT MET findings.

Affirming Official confusion. The Affirming Official must be a senior representative with authority to bind the organization. An IT manager is typically not sufficient. A CEO, president, or designated corporate officer is the expected level. Some contractors discover this late in the process when no one in the org chart has the required authority formally documented.

Treating Level 1 as a checkbox. Level 1 is light compared to Level 2, but it is not nothing. The senior-official affirmation creates personal legal exposure, and the False Claims Act applies to false attestations the same way it applies to fraudulent invoices.

Important: The Department of Justice has been explicit that cybersecurity-related False Claims Act cases are an active enforcement priority. A signed CMMC affirmation that overstates compliance is precisely the kind of attestation that has produced multi-million-dollar settlements at other federal agencies. Take the senior-official signature seriously.

What Are the 15 CMMC Level 1 Requirements?

The 15 requirements come from FAR 52.204-21(b)(1) and cover Access Control (4 practices), Identification and Authentication (2), Media Protection (1), Physical Protection (2), System and Communications Protection (2), and System and Information Integrity (4). All 15 practices are described in full in the requirements section above.

Level 1 is self-assessment only. Contractors evaluate their own implementation and submit results to SPRS along with a senior-official affirmation. No C3PAO involvement is required at Level 1. Levels 2 and 3 involve third-party or government assessments depending on the contract type and data sensitivity.

Annually. The self-assessment must be performed every year, and a fresh senior-official affirmation must be submitted to SPRS within 12 months of the prior affirmation. Missing the deadline invalidates your status and makes you ineligible for new covered contract awards.

Noncompliance means loss of eligibility for new DoD contract awards requiring Level 1, potential suspension or termination of existing contracts, exclusion from prime contractor supply chains, and False Claims Act liability for any false attestations already submitted to SPRS.

For a small business with reasonable IT hygiene already in place, two to four weeks of focused effort is typical. For contractors starting from a less mature baseline, two to three months is more realistic. The bottleneck is usually evidence collection and scoping, not technical remediation. A structured gap assessment at the start of the process will give you a realistic timeline for your specific environment.

Yes. CMMC requirements flow down through the supply chain. Any subcontractor handling FCI in performance of a DoD subcontract needs its own current Level 1 status in SPRS. Primes are increasingly requiring proof of CMMC status before subcontract award, and this trend accelerated through 2025.

CMMC Level 1 covers 15 practices drawn from FAR 52.204-21 and addresses FCI only. NIST SP 800-171 contains 110 controls and addresses CUI, mapping to CMMC Level 2. The Level 1 practices are a subset of the broader 800-171 framework, but the two are not equivalent. A contractor compliant with NIST 800-171 is also compliant with Level 1; the reverse is not true. For a detailed breakdown of how the two frameworks compare, see our guide on CMMC vs NIST 800-171.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

Three Gulf states now run three different data protection regimes. Saudi Arabia’s regulator has already issued dozens of enforcement decisions. Bahrain has had a working statute since 2019, and the UAE has a federal law on the books but is still waiting on the executive regulations that will give it teeth. For any company operating across the region, the practical question is no longer whether these laws apply but how far apart they sit, and where compliance built for one falls short of another. This is a structured comparison of the personal data protection laws in Bahrain, UAE, and Saudi Arabia: what each one demands, where they converge on familiar GDPR principles, and the specific points where treating them as interchangeable will get you fined. The Three Laws at a Glance Bahrain moved first. Law No. 30 of 2018, the Personal Data Protection Law (PDPL), came into force on August 1, 2019, making it the first comprehensive standalone data protection statute in the Gulf Cooperation Council. It is supplemented by ten ministerial resolutions issued in 2022 that cover transfers, security measures, and notification procedures. The UAE followed with Federal Decree-Law No. 45 of 2021, effective January 2, 2022 — the country’s first federally applicable, GDPR-style law, issued alongside Federal Decree-Law No. 44 of 2021, which created the UAE Data Office as the federal regulator. The catch is that the executive regulations meant to flesh out timelines and penalties have still not been published, which leaves parts of the regime in a holding pattern. Saudi Arabia’s Personal Data Protection Law, issued by Royal Decree M/19 in September 2021 and amended in March 2023, is the strictest and the most actively enforced of the three. It came into force on September 14, 2023, and a one-year grace period ended on September 14, 2024. Since then, every organization processing the personal data of people in the Kingdom has been fully on the hook. Worth knowing: Saudi Arabia’s PDPL Saudi Arabia’s PDPL protects a person’s data not only during their lifetime but after death. That post-mortem protection is unusual among global privacy laws and means retention and disclosure decisions cannot assume an individual’s rights simply lapse when they die. Who the Laws Actually Reach All three statutes reach beyond their own borders. Bahrain’s PDPL applies to anyone residing or doing business in Bahrain, and to entities outside the country that process personal data using equipment located inside it. The UAE law applies to the processing of data belonging to people in the UAE, regardless of where the controller or processor is based. Saudi Arabia goes furthest, applying to any entity inside or outside the Kingdom that processes the personal data of Saudi residents — a scope that pulls in international businesses that may never have considered themselves subject to Gulf regulation. The big structural difference is the UAE’s free zones. The federal PDPL does not apply inside zones that maintain their own data protection regimes, most notably the Dubai International Finance Centre (DIFC) and the Abu Dhabi Global Market (ADGM), each of which runs its own established framework. A company in the DIFC answers to DIFC rules, not the federal law. That carve-out has no equivalent in Bahrain or Saudi Arabia, and it matters enormously for regional structuring decisions. Ready for GCC data privacy compliance? Talk to our experts and simplify Bahrain, UAE, and Saudi data privacy compliance. Schedule The Regulators Each country has its own supervisory authority, and they are at very different stages of maturity. Bahrain’s Personal Data Protection Authority (PDPA) operates under the Ministry of Justice, Islamic Affairs and Waqf and has full investigation, audit, and penalty powers. SDAIA — the Saudi Data and Artificial Intelligence Authority — is the current regulator in Saudi Arabia, with long-term supervision potentially moving to the National Data Management Office under the Kingdom’s wider data governance framework. SDAIA is visibly active: its enforcement committees issued 48 decisions confirming PDPL violations across the 2025 and 2026 review cycles, a level of regulatory output that should get the attention of any compliance team operating in the region. The UAE is the outlier. The UAE Data Office exists in law but is not yet fully operational, and the Telecommunications and Digital Government Regulatory Authority was tasked with providing administrative support during the office’s early years. In practice this means data subjects in the UAE currently lack a clear federal route to lodge a complaint, and enforcement guidance is still maturing. That ambiguity cuts both ways: it reduces immediate enforcement risk, but it also makes it harder to know exactly what compliance looks like. Lawful Basis, Consent, and Core Principles Consent sits at the center of all three regimes, but Bahrain leans on it hardest. Bahrain’s PDPL sets a default rule that personal data may not be processed without the data subject’s written and explicit consent, with a narrow set of alternative bases such as contract performance, legal obligation, and vital interests. Saudi Arabia and the UAE both recognize consent alongside other grounds, and Saudi Arabia’s amended law added legitimate interest as a basis — though it cannot be used for sensitive data and controllers are warned against treating consent as a convenient fallback when a more specific ground applies. Beneath the lawful-basis question, the three laws share the principles that anyone familiar with the same GDPR-shaped foundation will recognize: lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, and security. The vocabulary and structure track the European model closely, and deliberately so. That means a mature GDPR program is a strong starting point, not a finished one — the architecture transfers, but the local rules introduce enough variation to demand dedicated attention.   Data Subject Rights The rights packages are broadly similar across the three jurisdictions, but the enforcement emphasis differs. Individuals in all three countries can access their data, request correction, and object to certain processing. Saudi Arabia’s PDPL spells out the most comprehensive set — including access, correction, deletion, objection, and portability —

ISO 14001:2026 took effect on April 15, 2026, and it carries the first genuinely new clause the environmental standard has seen in over a decade. Any checklist built against the 2015 edition is now partly out of date. The structure auditors examine has shifted to the ISO Harmonized Structure, climate change is written into the requirements rather than bolted on through an amendment, and a new change management clause gives certification bodies a fresh place to record findings. This guide breaks down what an ISO 14001 certification audit checklist needs to cover now, clause by clause, and how to use it without turning your environmental management system into a paperwork exercise. What Is an ISO 14001 Audit Checklist? An ISO 14001 audit checklist is a structured set of questions and verification points an auditor works through to confirm an environmental management system (EMS) meets the requirements of the standard. It maps each clause to specific evidence: documents, records, interviews, and observed practice. The checklist is the auditor’s working tool, not the audit itself. A good checklist prompts the auditor to look for objective evidence rather than tick boxes, and it leaves room to record where the documented system and actual practice diverge. That gap — between what the procedure says and what people actually do — is where most findings come from. Stay Ahead of ISO 14001:2026 Changes Book an ISO 14001 Gap Assessment Schedule Why You Need an ISO 14001 Audit Checklist Without a checklist, audits drift. Auditors skip clauses, linger on the areas they find interesting, and produce findings that are hard to compare year over year. A checklist enforces coverage and consistency, which matters most when more than one auditor works the program or when you want surveillance results that trend cleanly against the baseline. It also protects you before the certification body arrives. A disciplined internal audit run against a checklist that mirrors the external audit surfaces the same nonconformities your registrar would — while you still have time to fix them. The checklist turns a once-a-year scramble into a repeatable process. Worth knowing: ISO 19011 ISO 19011 is the international guideline for auditing management systems, and it is not a standard you can certify against. You cannot become “ISO 19011 certified.” It exists to make your audit program competent and consistent — which is exactly what a third-party auditor checks when they review your internal audit records. Types of ISO 14001 Audits Not every audit serves the same purpose, and your checklist depth should match the audit type. The four you will encounter are internal, second-party, third-party certification, and the surveillance and recertification audits that follow. Internal Audit Sometimes called a first-party audit, this is conducted by or on behalf of the organization itself. It is a requirement of Clause 9.2, and it is the single most important audit you run, because it is the one you control. Internal audits should be planned across a program, cover the full EMS over the cycle, and use auditors who are competent and independent of the work they assess. Second-Party Audit A second-party audit is one organization auditing another it has a relationship with — most often a customer auditing a supplier or a company auditing its contractors. Under the 2026 revision, with its sharper focus on externally provided processes, products, and services, expect more of these as larger buyers push environmental criteria down their supply chains. Third-Party Certification Audit This is the audit that earns the certificate. An accredited certification body assesses your EMS against ISO 14001 in two stages. Stage 1 is a readiness review that checks whether the system exists, is documented, and is ready to be assessed. Stage 2 verifies that the EMS is fully implemented, effective, and producing the results it claims. Certification follows only once any major nonconformities are closed. Surveillance and Recertification Audits ISO management system certificates run on a three-year cycle governed by ISO/IEC 17021-1. After initial certification, the body conducts annual surveillance audits in years two and three to confirm the system is still operating, then a recertification audit before the certificate expires. Surveillance audits are narrower than the full assessment, but they are not a formality — and many organizations will fold their move to ISO 14001:2026 into a surveillance or recertification visit to keep cost and disruption down. ISO 14001 Audit Checklist: Clause-by-Clause Breakdown ISO 14001:2026 follows the ISO Harmonized Structure, the common framework shared with ISO 9001, ISO 45001, and ISO/IEC 27001. The familiar Plan-Do-Check-Act cycle still runs underneath it. Clauses 1 through 3 cover scope, references, and terms. The auditable requirements live in Clauses 4 through 10, and that is where your checklist does its work. Clause 4: Context of the Organization Verify that internal and external issues, interested parties, and the EMS scope are identified and documented. This is where the 2026 revision lands hardest. Context analysis must now explicitly weigh environmental conditions — including climate change, biodiversity, pollution levels, and the availability of natural resources. A context review that mentions only commercial and regulatory factors will draw a finding. Clause 5: Leadership and Commitment Check for evidence that top management is involved in substance, not ceremony. The environmental policy must be documented, communicated, and appropriate to the organization. Auditors look for real engagement: leaders who can speak to the policy, the objectives, and how environmental performance feeds into business decisions. The 2026 wording tightens leadership accountability, so a policy signed once and forgotten will not hold up. Clause 6: Planning and Risk Assessment This clause covers environmental aspects and impacts, compliance obligations, risks and opportunities, and objectives. It generates more nonconformities than almost any other. The life cycle perspective in Clause 6.1.2 is strengthened, with clearer expectations on upstream and downstream impacts. The headline change is Clause 6.3, Planning of Changes — the only entirely new clause in the revision. It requires a structured, planned approach to changes that affect the EMS, such as new products, site relocations, supplier changes, or process

A 3PAO is the independent firm that decides whether a cloud service is secure enough to handle federal data. The acronym stands for Third-Party Assessment Organization, and these accredited auditors sit at the center of the FedRAMP process. A federal agency will not grant an Authority to Operate (ATO) at the Moderate or High impact level without a 3PAO assessment behind it. That makes the 3PAO one of the most consequential vendors a cloud service provider (CSP) will hire on the road to the federal market. This guide explains what a 3PAO is, what it actually does, how a firm earns the accreditation, and when you should bring one in. It also covers how the role is changing under FedRAMP’s 2025 overhaul, because the job looks different now than it did even a year ago. What Does 3PAO Stand For? 3PAO stands for Third-Party Assessment Organization. The “third party” part is the whole point. The assessor is independent of both the cloud provider being evaluated and the government agency relying on the results. That independence is what gives a 3PAO report its weight. An agency can trust the findings precisely because the assessor has no stake in the outcome. What Is a 3PAO? A 3PAO is an independent firm accredited to evaluate the security of cloud services seeking authorization under FedRAMP, the Federal Risk and Authorization Management Program. The FedRAMP Program Management Office (PMO) recognizes these firms only after they pass a demanding accreditation process. Once recognized, a 3PAO is listed publicly on the FedRAMP Marketplace under the Assessors tab, where CSPs and agencies can find them. 3PAOs are not limited to federal work. The same firms are commonly authorized to perform GovRAMP assessments, the program formerly known as StateRAMP, for state and local government cloud procurement. The skill set transfers directly, since both programs lean on the same NIST control foundations. What Does a 3PAO Do? A 3PAO independently tests whether a cloud service offering (CSO) does what its documentation claims. The longer version breaks into four distinct areas: 1- Independent Security Assessments The core deliverable is a security assessment. The 3PAO evaluates a CSP’s controls against the relevant FedRAMP baseline, which maps to NIST SP 800-53. It builds a Security Assessment Plan (SAP), executes the testing, and documents the findings in a Security Assessment Report (SAR). The SAR is the artifact an agency’s Authorizing Official reads when deciding whether to grant an ATO. 2- Documentation Review and Validation Before any testing happens, the 3PAO reviews the System Security Plan (SSP), the primary document describing how each control is implemented. SSPs routinely run to hundreds of pages, and a vague or incomplete one will stall the schedule fast. The assessor checks that what the SSP claims matches what the system actually does, then tracks unresolved issues in a Plan of Action and Milestones (POA&M). 3- Penetration Testing FedRAMP assessments include mandatory penetration testing, and the 3PAO performs it. The assessor probes the system the way an attacker would, looking for exploitable weaknesses that control documentation alone would never surface. A clean SSP means little if a tester can walk straight through the front door. 4- Ongoing Continuous Monitoring Support Authorization is not a one-time event. CSPs must sustain compliance through continuous monitoring (ConMon), which includes regular scanning, vulnerability remediation, and periodic reassessment. 3PAOs often support annual assessments and significant-change reviews. One structural note worth tracking: as of March 2025, FedRAMP stopped running centralized continuous monitoring, and that responsibility now sits with each sponsoring agency. Worth knowing: 3PAO Reports FedRAMP states that 3PAO reports “serve as the basis from which the federal government makes informed, risk-based authorization decisions.” The assessment is not a formality. It is the evidence the entire authorization rests on. How Does an Organization Become an Accredited 3PAO? Becoming a 3PAO is nearly as demanding as the assessments these firms perform. There is one accreditation body, and the bar is high. A2LA Accreditation Requirements The American Association for Laboratory Accreditation (A2LA) is the sole body that accredits FedRAMP 3PAOs. Its FedRAMP 3PAO accreditation program puts applicants through a rigorous evaluation of technical competence. A firm must spend at least a year in A2LA’s Cybersecurity Inspection Body Program before it can even be considered for FedRAMP recognition, and it must pass technical proficiency testing administered through A2LA’s testing partner. ISO/IEC 17020 Compliance Accreditation hinges on conformance with ISO/IEC 17020, the international standard for bodies that perform inspections. The standard sets requirements for impartiality, independence, technical competence, and a functioning quality management system. In practice, this is what stops a 3PAO from cutting corners or playing favorites. The accreditation certifies the firm’s process, not just the talent of its people. FedRAMP-Specific Requirements Beyond ISO/IEC 17020, FedRAMP layers on its own recognition requirements covering program-specific knowledge and assessment methodology. A firm has to demonstrate it understands FedRAMP’s baselines, templates, and reporting expectations — not just general inspection practice. Only after clearing both bars does the firm appear on the Marketplace as a recognized 3PAO. Why Are 3PAOs Important for FedRAMP? FedRAMP runs on a “do once, use many” philosophy. One rigorous, independent assessment lets multiple federal agencies reuse the same authorization package instead of each running its own review. The 3PAO is what makes that trust transferable. Because the assessor is accredited and independent, an agency in one department can rely on a SAR produced for another. The program exists because federal systems must meet security obligations set under FISMA, the Federal Information Security Modernization Act, and the General Services Administration (GSA) runs FedRAMP to standardize how cloud services meet them. Without accredited assessors, every agency would judge cloud security on its own terms — which is exactly the fragmentation FedRAMP was built to end. Worth knowing: The FedRAMP Authorization The FedRAMP authorization landscape changed significantly in 2024 and 2025. The Joint Authorization Board (JAB) and its provisional ATO path were dissolved under OMB Memorandum M-24-15, leaving a single “FedRAMP Authorized” designation. Authorizations now flow through agency authorization or