The AICPA never wrote the words penetration test required into SOC 2. Yet a service organization that walks into a Type II audit without one is almost guaranteed to leave with findings, follow-up questions, or a delayed report. That gap, between what the standard technically demands and what auditors operationally expect, is where most companies trip. This article breaks down the real SOC 2 penetration testing requirements: where they sit in the Trust Services Criteria, what auditors look for during Type I and Type II engagements, how often you should test, and what a good pen test report needs to contain to satisfy your auditor without inflating your budget. Understanding SOC 2 and Its Security Expectations What Is SOC 2? SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA) for service organizations that handle customer data. Unlike a certification, SOC 2 is an opinion: a licensed CPA firm reviews your security controls and issues a report stating whether those controls are designed (Type I) or operating (Type II) effectively. SOC 2 reports are read by enterprise procurement teams, security reviewers, and risk officers. Most B2B SaaS contracts in 2026 require one before signing. What Controls Does SOC 2 Require? Rather than dictating specific technologies, SOC 2 requires that you design and operate controls that demonstrably meet each criterion under the Trust Services Criteria (TSC). That gives you flexibility, and it also gives auditors latitude to ask hard questions. Does SOC 2 Require Penetration Testing? The Official SOC 2 Position on Penetration Testing The phrase penetration test appears in the AICPA’s 2017 Trust Services Criteria publication (with 2022 revisions) inside a single Point of Focus under CC7.1, the Common Criterion that requires entities to use detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities. The Point of Focus suggests management uses a variety of ongoing and separate risk and control evaluations to determine whether controls function. Penetration testing is named as one option. That is the entire textual basis. There is no clause that mandates an annual external pentest, no specification of scope, no required methodology. Short Answer: There Are No Mandatory SOC 2 Pen Test Requirements You can technically obtain a SOC 2 report without a penetration test, provided you can show your auditor that you use alternative evaluations to satisfy CC4.1 (ongoing monitoring) and CC7.1 (vulnerability identification). In practice, almost nobody does this successfully. Long Answer: You Still Need SOC 2 Penetration Testing Auditors view penetration testing as the strongest available evidence that your controls work against a determined adversary, not just on paper. CC4.1 asks the entity to perform ongoing monitoring to ascertain whether internal controls are present and functioning; a pen test is the most direct way to evaluate that. CC6.1 asks whether logical access controls can be bypassed; a pen test answers that question directly. CC7.1 ties this together by requiring you to detect newly introduced vulnerabilities. If you skip pen testing, you carry the burden of proving your alternative evidence is at least as good. That is a steeper hill than most organizations realize. What Auditors Expect During Type I and Type II Engagements A SOC 2 Type I report assesses control design at a single point in time. A Type II report assesses operating effectiveness over a defined audit period, typically six to twelve months. Both increasingly assume a recent penetration test exists. For Type II especially, auditors expect the test to fall within the audit window, with documented remediation of any critical or high findings before the period closes. Auditors rarely refuse a Type II report over a missing pentest outright, but they will issue a finding or qualified opinion if they cannot validate CC4.1 evidence. That qualification will be read by every customer reviewing your report. Most CISOs would rather budget $15,000 for a pentest than try to explain a qualified opinion to a procurement team. What Are the Actual SOC 2 Penetration Testing Requirements? Alignment with Trust Services Criteria A pen test that supports a SOC 2 audit must map its findings to specific criteria. Most reputable pentest firms now produce a Trust Services Criteria mapping appendix that ties identified vulnerabilities back to CC4.1, CC6.1, CC7.1, and where relevant CC7.2 through CC7.4. Without that mapping, your auditor has to do the interpretive work themselves, which typically means a follow-up request and a slower report. Scope Definition Requirements Scope should match your SOC 2 system boundary, not your entire infrastructure. If your audit covers a single SaaS product, its API, and its AWS account, that is what should be tested. Auditors look for evidence that the pen test scope was derived from the system description in your SOC 2 report. A mismatch between the two is one of the most common causes of fieldwork delays. Testing Frequency and Timing Requirements SOC 2 does not specify a frequency. Annual testing has become the de facto standard, with additional testing after material changes to architecture, authentication, or hosting. For organizations on continuous deployment, some auditors now accept a combination of annual deep-dive testing and continuous automated assessment as sufficient coverage, but this should be confirmed with your auditor before you rely on it. Remediation Evidence Requirements Findings without remediation are findings against you. Auditors expect documented remediation plans for every critical and high-severity issue, with closed tickets, retest results, or compensating controls recorded before the audit period ends. A finding sitting open in a backlog at audit time is treated almost identically to a finding that was never addressed. Penetration Testing vs. Vulnerability Scans for SOC 2 Both belong in your control set, but they answer fundamentally different questions. Vulnerability scanning is automated and broad, it identifies known CVEs and misconfigurations across your environment quickly and consistently. Penetration testing is manual and adversarial, it simulates what a real attacker would do with the access and information they can obtain. CC7.1 explicitly references both, and your auditor

The CMMC program turned from advisory framework to binding contract requirement on November 10, 2025, when the DoD’s Title 48 acquisition rule took effect.  That single date changed the market for CMMC advisory services overnight, and the Cyber AB Registered Practitioner credential moved from a useful business card to a genuine signal of competence.  Over 80,000 companies in the Defense Industrial Base now need help interpreting the rule, and the RP is the formal entry-level role in the ecosystem authorized to provide it. This guide explains what a CMMC Registered Practitioner is, how the role fits alongside CCPs, CCAs, RPOs, and C3PAOs, what it takes to earn the designation, and how Organizations Seeking Certification (OSCs) should think about engaging one. What Is a CMMC Registered Practitioner (RP)? A CMMC Registered Practitioner is an individual authorized by the Cyber AB, the official accreditation body for the CMMC ecosystem, to provide non-certified advisory and consulting services to Organizations Seeking Certification.  RPs help defense contractors interpret the CMMC model, scope their environments, build documentation, remediate gaps against NIST SP 800-171, and prepare for the formal assessment they will eventually undergo. The credential exists because the CMMC framework is genuinely dense. CMMC Level 2 maps to all 110 controls in NIST SP 800-171, and Level 3 layers on 24 selected requirements from NIST SP 800-172. Most contractors do not have the in-house expertise to implement these controls cleanly, and the Cyber AB needed a way to identify advisors who had at least demonstrated baseline knowledge of the program. An RP does not perform official assessments. That work is reserved for Certified CMMC Assessors (CCAs) operating under a C3PAO. The RP role is strictly advisory, and the Code of Professional Conduct that every RP must sign makes the boundary explicit. How RPs Fit Into the Broader CMMC Ecosystem The Cyber AB structures the ecosystem into two distinct lanes: consulting and implementation on one side, assessment and certification on the other. RPs sit on the consulting side. CCPs, CCAs, and C3PAOs sit on the assessment side. The two are kept deliberately separate so that no firm can audit work it helped configure, a separation that preserves the integrity of the certification process. Registered Practitioners vs. Certified CMMC Professionals (CCPs) The CCP is a more rigorous credential. CCP candidates must complete formal Cyber AB training delivered by a Licensed Training Provider, pass a commercial background check, and sit a proctored exam administered by CAICO. CCPs can participate in actual assessments as part of a C3PAO assessment team, though they cannot lead them. RPs cannot participate in assessments at all. In practical terms, the RP credential is the right starting point for consultants, MSPs, and internal compliance staff who want to demonstrate baseline CMMC fluency. The CCP is the right credential for professionals planning a career in CMMC assessment work. Registered Practitioners vs. C3PAOs A C3PAO (Certified Third-Party Assessment Organization) is the entity authorized to conduct official Level 2 certification assessments and issue formal CMMC status determinations. Fewer than 100 firms held C3PAO authorization as of early 2026, serving an ecosystem of more than 80,000 contractors. C3PAOs are companies. RPs are individuals. They do completely different jobs: the RP prepares the contractor, the C3PAO certifies them. Important: A C3PAO that helps a client implement controls is barred from later assessing that same client. This is a hard line in the Code of Professional Conduct. If you engage a firm for both readiness and certification work, you will end up paying two different organizations regardless, so plan accordingly from the start. What Does a CMMC Registered Practitioner Do? The work of an RP is the work of getting an organization to the starting line of a formal assessment without surprises. That includes interpreting which CMMC level applies to a given contract, scoping the CUI and FCI environments, identifying gaps against NIST SP 800-171, drafting the System Security Plan (SSP) and Plan of Action and Milestones (POA&M), advising on technical remediation, and coaching the OSC through mock assessments before the real one. Who Can a CMMC RP Help? RPs serve any organization in the Defense Industrial Base that needs to achieve a CMMC status. That includes prime contractors, subcontractors at any tier, MSPs, and MSSPs that handle CUI on behalf of defense clients, manufacturers, research universities, and civilian agency contractors whose departments have adopted CMMC-aligned clauses. The flow-down requirements in 32 CFR §170.23 mean that even small subcontractors who process Federal Contract Information (FCI) must hit Level 1, which keeps RP work relevant well past the first wave of large primes. What Services Does a CMMC RP Provide? The core service menu looks consistent across the market: gap assessments against NIST SP 800-171, scope definition, SSP and POA&M drafting, policy and procedure development, technical advisory on encryption, access control and incident response, and pre-assessment readiness reviews. Strong RPs also help clients interpret recent guidance changes, manage their SPRS score, and prepare evidence packages that will survive scrutiny from a C3PAO assessment team. Pro Tip: Evaluating a Registered Practitioner When evaluating an RP, ask whether they have walked a client through a full C3PAO assessment cycle, not just a gap assessment. There is a significant difference between consultants who write SSPs and consultants who have watched assessors actually challenge one. How to Become a CMMC Registered Practitioner The path is straightforward but not trivial. The Cyber AB controls the registration process end-to-end, and every step must be completed in order. Step 1: Complete the Required CMMC Registered Practitioner Training The RP training is delivered online through the Cyber AB’s learning management system. It covers the CMMC model document, the structure of the ecosystem, scoping methodology, FCI and CUI definitions, prime and subcontractor information flow, the assessment process, and the relationship between CMMC and existing DFARS clauses. The course typically takes around eight hours. Candidates should plan for roughly $500 to $600 in combined training and annual registration costs. Step 2: Register with the Cyber AB After training, candidates submit a

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. 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. 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,

Defense contractors handling Controlled Unclassified Information now face a choice that shapes their entire compliance budget: lock down the whole organization, or draw a tight boundary around CUI and protect only that. The second path is kown as the CMMC enclave. For many companies in the Defense Industrial Base, it is the faster, more affordable, and more operationally sensible route to certification, but only if it is scoped and implemented correctly. This article explains what a CMMC enclave is, how it differs from enterprise-wide compliance, and what it takes to build one that will actually hold up under assessment. What Is a CMMC Enclave? A CMMC enclave is a logically or physically isolated segment of your IT environment where all CUI is processed, stored, and transmitted. Everything inside the enclave boundary is in scope for a CMMC assessment. Everything outside is not. Think of your company as a building. The enclave is a locked, monitored room inside it. Only specific people are authorized to enter, all activity within the room is logged, and the security controls governing the room are documented and continuously enforced. The rest of the building operates normally, unaffected by the rigorous controls applied inside. The concept is explicitly supported by DoD guidance. The CMMC Level 2 Scoping Guide states that organizations “may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain.” That isolation can be achieved through physical separation, logical separation, or a combination of both. How a CMMC Enclave Differs from Enterprise-Wide Compliance Enterprise-wide compliance means applying all 110 NIST SP 800-171 controls across your entire organization: every endpoint, every user account, every application that touches any part of your network. That is the default interpretation many contractors start with, and it is expensive. A larger scope means more assets to harden, more users to train, more systems to document, and a bigger, more complex assessment. An enclave approach inverts the logic. Instead of bringing the whole organization up to CMMC Level 2 standards, you identify the minimum set of systems and users that genuinely need to touch CUI — and you apply full controls to only that subset. The result is a smaller, focused compliance footprint. The financial difference is real. Published case studies show that well-scoped enclaves reduce CMMC implementation costs by 20 to 45 percent compared to enterprise-wide approaches. A 40-person manufacturer, for example, reduced its projected CMMC implementation cost from $140,000 to $78,000 by migrating CUI into a cloud-based enclave. The savings compound: fewer assets to secure, fewer people to train, a smaller assessment scope, and lower ongoing maintenance costs year after year. Physical Separation vs. Logical Separation in a CMMC Enclave The DoD’s own scoping guidance is clear that security domains may use physical separation, logical separation, or a combination of both. Understanding the difference matters because your choice affects architecture, cost, and how an assessor will evaluate your boundary. Physical separation means CUI assets live on dedicated hardware, in a separate room or cage, disconnected from general-purpose networks at the cable level. It is the most defensible form of separation, but it also carries higher hardware costs and operational overhead. For some regulated environments — particularly those subject to Level 3 requirements or handling the most sensitive categories of CUI — physical separation may be necessary. Logical separation uses network segmentation, firewall rules, VLANs, and access controls to isolate CUI assets within a shared physical infrastructure. It is cheaper, faster to implement, and the more common approach for CMMC Level 2 enclaves — but it requires architectural rigor. A VLAN boundary that is not technically enforced, or a firewall rule that permits general IT traffic to reach CUI systems, will not hold up during assessment. A critical point the DoD has reinforced in its updated FAQ guidance: logical separation must be provable and documented. Saying you have logical separation is not enough. You need enforceable architecture, tested configurations, and the documentation to demonstrate both. Important: A common mistake is treating logical separation as a policy statement rather than an architectural fact. Assessors will test your boundary controls, not just read your System Security Plan. If traffic can flow between your corporate network and your CUI enclave — even indirectly — the enterprise network may be pulled into scope. Why CMMC Scoping Matters Before Choosing an Enclave Approach Scoping is the decision that determines everything downstream: which systems you secure, which employees you train, how much the assessment costs, and how confident you can be that you will pass. Getting it wrong in either direction creates problems. Over-scoping wastes money. If your compliance boundary includes systems that never touch CUI, you are paying to harden infrastructure that does not need it. Under-scoping is worse: if CUI flows through systems outside your declared enclave — shared email servers, unmanaged endpoints, a consumer file-sharing tool someone uses informally — your boundary is invalid and your assessment will fail. NIST SP 800-171 offers a useful framing: organizations “will not want to spend money on cybersecurity beyond what it requires for protecting its missions, operations, and assets.” Scoping is how you align security investment with actual risk. Every asset you can legitimately keep out of scope is a saving. How to Scope a CMMC Enclave Scoping starts with a single question: where does CUI actually go in your environment? The answer is usually more distributed than people expect. CUI flows through email. It lands in shared drives, project management tools, collaboration platforms, and sometimes personal devices. Before you can define an enclave, you need to map all of it. The DoD scoping process works through asset categories: CUI Assets (systems that directly process, store, or transmit CUI), Security Protection Assets (systems that enforce security functions for CUI assets), Contractor Risk Managed Assets, Specialized Assets (IoT, OT, test equipment), and Out-of-Scope Assets. Only Out-of-Scope Assets can be excluded from assessment — and to qualify, they must be provably isolated from CUI flows. The key