CMMC 2.0 Readiness Assessment

The Cybersecurity Maturity Model Certification (CMMC) 2.0 framework establishes cybersecurity requirements for organizations in the Defense Industrial Base (DIB) that handle Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). The Department of Defense (DoD) published the CMMC 2.0 final rule (32 CFR Part 170) to enforce these requirements through the defense acquisition process. Government agencies and contractors must achieve the appropriate CMMC level to be eligible for DoD contracts.

CMMC 2.0 simplifies the original five-level model into three levels. Level 1 (Foundational) requires implementation of 17 basic safeguarding practices from FAR 52.204-21 and allows annual self-assessment. Level 2 (Advanced) requires implementation of all 110 security requirements from NIST SP 800-171 Revision 2. Depending on the sensitivity of the CUI involved, Level 2 may require either self-assessment or third-party assessment by a CMMC Third Party Assessment Organization (C3PAO). Level 3 (Expert) requires implementation of a subset of NIST SP 800-172 enhanced security requirements and requires government-led assessment by the Defense Contract Management Agency (DCMA).

For most government agencies and defense contractors handling CUI, Level 2 is the target. This assessment tool focuses on Level 2 readiness by mapping the 110 NIST 800-171 controls to iboss SASE capabilities, identifying which controls iboss directly satisfies, which controls iboss partially addresses, and which controls require additional tools or administrative measures. The goal is to give organizations a clear picture of their compliance posture and the gaps that need to be filled.

NIST Special Publication 800-171 Revision 2 organizes its 110 security requirements into 14 control families. Understanding the scope of each family is essential for planning a comprehensive compliance program. While iboss SASE addresses controls across multiple families, no single tool covers all 14 — a defense-in-depth approach with complementary solutions is necessary.

The 14 control families are: Access Control (AC) with 22 requirements, Awareness and Training (AT) with 3 requirements, Audit and Accountability (AU) with 9 requirements, Configuration Management (CM) with 9 requirements, Identification and Authentication (IA) with 11 requirements, Incident Response (IR) with 3 requirements, Maintenance (MA) with 6 requirements, Media Protection (MP) with 9 requirements, Personnel Security (PS) with 2 requirements, Physical Protection (PE) with 6 requirements, Risk Assessment (RA) with 3 requirements, Security Assessment (CA) with 4 requirements, System and Communications Protection (SC) with 16 requirements, and System and Information Integrity (SI) with 7 requirements.

iboss SASE capabilities have the strongest coverage in the Access Control, System and Communications Protection, Audit and Accountability, and Identification and Authentication families. Moderate coverage exists in Configuration Management, Incident Response, Risk Assessment, and System and Information Integrity. Families such as Physical Protection, Personnel Security, and Maintenance are primarily addressed through administrative controls and physical security measures outside the iboss platform.

• Access Control (AC): 22 requirements — strong iboss coverage via ZTNA, SWG, CASB
• Awareness and Training (AT): 3 requirements — administrative controls, LMS integration
• Audit and Accountability (AU): 9 requirements — strong iboss coverage via logging and monitoring
• Configuration Management (CM): 9 requirements — partial iboss coverage, requires endpoint management
• Identification and Authentication (IA): 11 requirements — strong iboss coverage via identity integration and MFA
• Incident Response (IR): 3 requirements — partial iboss coverage via alerting and log analysis
• Maintenance (MA): 6 requirements — primarily administrative and endpoint management controls
• Media Protection (MP): 9 requirements — partial iboss coverage via DLP, requires endpoint DLP
• Personnel Security (PS): 2 requirements — administrative HR controls
• Physical Protection (PE): 6 requirements — physical security controls, no iboss mapping
• Risk Assessment (RA): 3 requirements — partial iboss coverage via vulnerability visibility
• Security Assessment (CA): 4 requirements — administrative controls with iboss reporting support
• System and Communications Protection (SC): 16 requirements — strong iboss coverage via SWG, encryption, network segmentation
• System and Information Integrity (SI): 7 requirements — partial iboss coverage via malware protection and monitoring

The Access Control family is the largest in NIST 800-171 with 22 requirements, and it is where iboss SASE provides some of its deepest coverage. The iboss Zero Trust Network Access (ZTNA) architecture enforces the principle of least privilege by default — users and devices must be authenticated, authorized, and continuously validated before accessing any resource.

AC.L2-3.1.1 requires limiting system access to authorized users, processes acting on behalf of authorized users, and devices. iboss ZTNA accomplishes this by requiring identity verification before granting access to any application or resource. Access decisions are made per-session based on user identity, device posture, location, and risk score. No implicit trust is granted based on network location.

AC.L2-3.1.2 requires limiting system access to the types of transactions and functions that authorized users are permitted to execute. iboss application-level policies can restrict users to specific functions within SaaS applications — for example, allowing read access to a cloud application but blocking file uploads or data exports based on the user's role.

AC.L2-3.1.3 requires controlling the flow of CUI in accordance with approved authorizations. iboss DLP and CASB policies enforce data flow controls by inspecting content in transit and blocking unauthorized transfers of CUI to unapproved destinations. Combined with tenant restrictions and domain-level controls, iboss provides granular control over where CUI can flow.

AC.L2-3.1.5 requires employing the principle of least privilege. iboss ZTNA policies are configured on a deny-by-default basis — users are granted access only to the specific applications and resources required for their role, with no lateral movement permitted. Micro-segmentation at the application layer prevents users from discovering or accessing resources outside their authorization.

AC.L2-3.1.12 requires monitoring and controlling remote access sessions. iboss provides full visibility into remote access sessions regardless of user location. Because all traffic routes through the iboss cloud, remote users are subject to the same policy enforcement, logging, and monitoring as on-premise users — there is no distinction between remote and local access from a security posture perspective.

• AC.L2-3.1.1 (Authorized Access): iboss ZTNA enforces identity-based access — FULLY ADDRESSED
• AC.L2-3.1.2 (Transaction Control): iboss application-level policies restrict user functions — FULLY ADDRESSED
• AC.L2-3.1.3 (CUI Flow Control): iboss DLP + CASB enforce data flow policies — FULLY ADDRESSED
• AC.L2-3.1.4 (Separation of Duties): iboss role-based policies support duty separation — PARTIALLY ADDRESSED (requires IAM integration)
• AC.L2-3.1.5 (Least Privilege): iboss ZTNA deny-by-default architecture — FULLY ADDRESSED
• AC.L2-3.1.7 (Privileged Function Control): iboss restricts admin access and logs privileged actions — PARTIALLY ADDRESSED (requires PAM integration)
• AC.L2-3.1.12 (Remote Access Monitoring): iboss monitors all remote sessions through cloud proxy — FULLY ADDRESSED
• AC.L2-3.1.13 (Remote Access Encryption): iboss encrypts all remote access traffic via TLS — FULLY ADDRESSED
• AC.L2-3.1.14 (Remote Access Routing): iboss routes all traffic through managed access points — FULLY ADDRESSED
• AC.L2-3.1.20 (External Connections): iboss SWG controls and monitors all external connections — FULLY ADDRESSED
• AC.L2-3.1.22 (Publicly Accessible Content): iboss DLP prevents unauthorized CUI publication — PARTIALLY ADDRESSED

The System and Communications Protection family contains 16 requirements focused on protecting data in transit, enforcing communications boundaries, and preventing information leakage. iboss SASE provides strong coverage across this family due to its role as the primary network security enforcement point.

SC.L2-3.13.1 requires monitoring, controlling, and protecting communications at external system boundaries and key internal boundaries. As a cloud-delivered Secure Web Gateway, iboss sits at the boundary between the organization's users and the internet, inspecting all inbound and outbound web traffic. The iboss architecture extends this boundary enforcement to every user regardless of location, effectively creating a per-user boundary that travels with the device.

SC.L2-3.13.6 requires denying network communications traffic by default and allowing by exception. iboss ZTNA and SWG policies operate on an implicit-deny model. All network communications are blocked unless explicitly permitted by policy. This is fundamental to the Zero Trust architecture and directly satisfies this requirement.

SC.L2-3.13.8 requires implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. iboss enforces TLS encryption on all traffic processed through the platform. SSL inspection decrypts traffic for policy enforcement and re-encrypts it before forwarding, ensuring end-to-end encryption. The iboss platform supports TLS 1.2 and 1.3 and enforces strong cipher suites.

SC.L2-3.13.11 requires employing FIPS-validated cryptography when used to protect the confidentiality of CUI. iboss utilizes FIPS 140-2 validated cryptographic modules in its cloud infrastructure. Organizations should verify the current FIPS validation status with iboss and document it as part of their System Security Plan.

SC.L2-3.13.15 requires protecting the authenticity of communications sessions. iboss enforces session integrity through certificate validation, session token management, and protection against session hijacking. The cloud proxy architecture ensures that all communications sessions are authenticated and integrity-protected.

• SC.L2-3.13.1 (Boundary Protection): iboss SWG provides boundary monitoring and control for all users — FULLY ADDRESSED
• SC.L2-3.13.2 (Architectural Designs): iboss SASE architecture implements security in the design — PARTIALLY ADDRESSED (requires overall system design documentation)
• SC.L2-3.13.5 (Public-Internal Separation): iboss segregates public and internal traffic flows — FULLY ADDRESSED
• SC.L2-3.13.6 (Default Deny): iboss ZTNA and SWG operate on implicit-deny model — FULLY ADDRESSED
• SC.L2-3.13.8 (CUI Encryption in Transit): iboss enforces TLS encryption on all traffic — FULLY ADDRESSED
• SC.L2-3.13.10 (Key Management): iboss manages encryption keys within its platform — PARTIALLY ADDRESSED (requires organizational key management policy)
• SC.L2-3.13.11 (FIPS Cryptography): iboss uses FIPS 140-2 validated modules — FULLY ADDRESSED (verify current validation)
• SC.L2-3.13.12 (Collaborative Device Control): iboss CASB controls collaborative computing devices — FULLY ADDRESSED
• SC.L2-3.13.15 (Session Authenticity): iboss protects session integrity through certificate validation — FULLY ADDRESSED
• SC.L2-3.13.16 (CUI at Rest): NOT ADDRESSED by iboss — requires endpoint/storage encryption (BitLocker, LUKS)

The Audit and Accountability family contains 9 requirements focused on creating, protecting, and retaining system audit logs sufficient to monitor, analyze, investigate, and report on unlawful or unauthorized system activity. iboss provides comprehensive logging capabilities that directly address the majority of these requirements.

AU.L2-3.3.1 requires creating and retaining system audit logs and records sufficient to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. iboss generates detailed audit logs for all web traffic, application access, DLP events, policy actions, and administrative changes. These logs capture user identity, timestamp, source and destination, action taken, and outcome. Log retention is configurable and should be set to meet the organization's requirements — NIST 800-171 does not specify a retention period, but three years is a common standard.

AU.L2-3.3.2 requires ensuring that the actions of individual system users can be uniquely traced. iboss integrates with identity providers (Azure AD, Okta, on-premises AD) to correlate all activity with individual user identities. Every log entry includes the authenticated user identity, enabling full attribution of actions to specific individuals.

AU.L2-3.3.5 requires correlating audit record review, analysis, and reporting processes to support organizational investigations. iboss provides a centralized reporting dashboard with the ability to search, filter, and correlate events across users, time periods, applications, and policy actions. Reports can be exported and integrated with SIEM platforms for broader correlation with events from other systems.

AU.L2-3.3.8 requires protecting audit information and audit logging tools from unauthorized access, modification, and deletion. iboss audit logs are stored in the iboss cloud infrastructure with role-based access controls restricting log access to authorized administrators. Logs are immutable once written — they cannot be modified or deleted by district administrators, providing a tamper-resistant audit trail.

• AU.L2-3.3.1 (System Audit Logs): iboss generates comprehensive activity and policy action logs — FULLY ADDRESSED
• AU.L2-3.3.2 (User Accountability): iboss correlates all activity to authenticated user identities — FULLY ADDRESSED
• AU.L2-3.3.3 (Event Review): iboss dashboard enables review, analysis, and investigation — FULLY ADDRESSED
• AU.L2-3.3.4 (Audit Failure Alerting): iboss monitors logging health and alerts on failures — FULLY ADDRESSED
• AU.L2-3.3.5 (Audit Correlation): iboss supports event correlation and SIEM integration — FULLY ADDRESSED
• AU.L2-3.3.6 (Reduction and Reporting): iboss reporting provides filtering, aggregation, and trend analysis — FULLY ADDRESSED
• AU.L2-3.3.7 (Authoritative Time Source): iboss cloud uses NTP-synchronized authoritative time — FULLY ADDRESSED
• AU.L2-3.3.8 (Audit Protection): iboss logs are stored immutably in cloud infrastructure with RBAC — FULLY ADDRESSED
• AU.L2-3.3.9 (Audit Management): iboss limits audit log management to authorized administrators — FULLY ADDRESSED

The Identification and Authentication family contains 11 requirements ensuring that users and devices are properly identified and authenticated before being granted access to organizational systems. iboss integrates deeply with identity infrastructure to enforce these requirements at the network and application layer.

IA.L2-3.5.1 requires identifying system users, processes acting on behalf of users, and devices. iboss identifies users through integration with enterprise identity providers including Microsoft Entra ID (Azure AD), Okta, Google Workspace, and on-premises Active Directory. Device identification is accomplished through the iboss cloud connector agent, which registers each device and reports device attributes including compliance status, OS version, and certificate presence.

IA.L2-3.5.2 requires authenticating the identities of users, processes, and devices as a prerequisite to allowing access. iboss enforces authentication through SAML 2.0 and OIDC integration with the organization's identity provider. Users must authenticate before any network or application access is granted. The iboss agent provides device-level authentication through certificate-based identity.

IA.L2-3.5.3 requires the use of multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. iboss supports MFA enforcement by integrating with identity providers that require MFA as part of the authentication flow. Additionally, iboss can be configured to require step-up authentication for access to sensitive applications, adding a conditional MFA layer based on application sensitivity, user risk score, or device posture.

IA.L2-3.5.7 requires enforcing a minimum password complexity for authentication to password-based systems. While password policy enforcement is primarily the responsibility of the identity provider and directory service, iboss integrates with these systems and enforces that users are authenticated through the compliant identity infrastructure. iboss does not allow password-only local authentication for administrative access — all admin access requires MFA through the identity provider.

• IA.L2-3.5.1 (User Identification): iboss identifies users via IdP integration and device agent — FULLY ADDRESSED
• IA.L2-3.5.2 (Authentication): iboss enforces SAML/OIDC authentication before access — FULLY ADDRESSED
• IA.L2-3.5.3 (MFA): iboss supports MFA via IdP integration and conditional step-up auth — FULLY ADDRESSED (requires IdP MFA configuration)
• IA.L2-3.5.4 (Replay Resistance): iboss uses token-based authentication with replay protection — FULLY ADDRESSED
• IA.L2-3.5.5 (Identifier Reuse Prevention): managed by IdP, iboss enforces IdP decisions — PARTIALLY ADDRESSED (IdP responsibility)
• IA.L2-3.5.6 (Identifier Disabling): managed by IdP, iboss enforces disabling within session TTL — PARTIALLY ADDRESSED (IdP responsibility)
• IA.L2-3.5.7 (Password Complexity): managed by IdP, iboss enforces IdP authentication — PARTIALLY ADDRESSED (IdP responsibility)
• IA.L2-3.5.8 (Password Reuse): managed by IdP — NOT DIRECTLY ADDRESSED by iboss
• IA.L2-3.5.9 (Temporary Passwords): managed by IdP — NOT DIRECTLY ADDRESSED by iboss
• IA.L2-3.5.10 (Cryptographic Authentication): iboss uses certificate-based device auth — FULLY ADDRESSED
• IA.L2-3.5.11 (Authenticator Feedback): iboss login interface obscures credential entry — FULLY ADDRESSED

No single platform addresses all 110 NIST 800-171 requirements. This gap analysis identifies the control areas where iboss provides full coverage, partial coverage (requiring complementary configuration or integration), and no coverage (requiring separate solutions). Organizations should use this template to build a complete compliance roadmap.

iboss provides full or substantial coverage for approximately 45-55 of the 110 controls, concentrated in Access Control, System and Communications Protection, Audit and Accountability, and Identification and Authentication. These are the controls most directly related to network security, web traffic inspection, data protection, and user access management.

Partial coverage exists for approximately 20-25 controls where iboss provides supporting capabilities but additional tools or administrative measures are needed. For example, Configuration Management (CM) controls require endpoint management tools (Intune, JAMF) alongside iboss, Incident Response (IR) controls require documented procedures and a response team beyond the alerting iboss provides, and Risk Assessment (RA) controls require a formal risk management program that iboss reporting supports but does not constitute.

Gaps requiring separate solutions exist primarily in Physical Protection (PE) — physical access controls, environmental protections, and facility security have no iboss mapping. Personnel Security (PS) — background checks and personnel screening are HR functions. Maintenance (MA) — system maintenance controls require endpoint and server management tools. Media Protection (MP) — while iboss DLP addresses some media protection controls for data in transit, controls related to media sanitization, marking, and physical media protection require endpoint and operational procedures.

• FULLY ADDRESSED by iboss (approximately 45-55 controls): AC.L2-3.1.1, 3.1.2, 3.1.3, 3.1.5, 3.1.12-14, 3.1.20; AU.L2-3.3.1-9; SC.L2-3.13.1, 3.13.5, 3.13.6, 3.13.8, 3.13.11, 3.13.15; IA.L2-3.5.1-4, 3.5.10-11
• PARTIALLY ADDRESSED (approximately 20-25 controls): CM controls (pair with Intune/JAMF), IR controls (pair with IR procedures), RA controls (pair with risk program), SI controls (pair with EDR)
• NOT ADDRESSED — requires separate solutions: PE family (physical security), PS family (personnel security), MA family (maintenance tools), MP media sanitization controls
• Complementary tools recommended: EDR/XDR for endpoint protection (SI, CM), PAM for privileged access (AC.L2-3.1.7), MDM/UEM for device management (CM, MP), SIEM for cross-platform correlation (AU, IR), vulnerability scanner for risk assessment (RA)
• Administrative controls required: documented policies for all 14 families, training program (AT), personnel screening process (PS), physical security program (PE), maintenance procedures (MA)
• Document the compliance status of each control in the System Security Plan (SSP)
• Create a Plan of Action and Milestones (POA&M) for all controls not yet fully implemented

CMMC Level 2 assessment scoring follows the methodology defined in NIST SP 800-171A and the CMMC Assessment Guide. Each of the 110 security requirements is evaluated as MET, NOT MET, or NOT APPLICABLE. For self-assessments, the organization calculates a score based on the DoD Assessment Methodology, which assigns point values to each requirement and subtracts points for unmet requirements from a perfect score of 110.

Each requirement starts at a value of 1, 3, or 5 points depending on its security weight as defined in the DoD Assessment Methodology. If a requirement is fully implemented, no points are deducted. If a requirement is not implemented or only partially implemented, the full point value is deducted. The resulting score is submitted to the Supplier Performance Risk System (SPRS). A score of 110 indicates full compliance. Scores below 110 must be accompanied by a Plan of Action and Milestones (POA&M) describing the remediation timeline, and certain high-value controls cannot have open POA&M items.

To prepare for assessment, organizations should conduct a thorough self-evaluation of each control, document the implementation status with supporting evidence, prepare the System Security Plan (SSP) describing how each requirement is addressed in the organizational environment, create POA&M entries for any gaps with realistic remediation timelines, and assemble the evidence package that an assessor would review.

For controls addressed by iboss, evidence should include platform configuration exports, policy documentation, sample log reports demonstrating operational effectiveness, and architecture diagrams showing how iboss fits into the overall security posture. For controls partially addressed by iboss, clearly document what iboss provides and what complementary controls are in place or planned.

Organizations should target a score of 110 with zero open POA&M items for the strongest compliance posture. If gaps exist, prioritize remediation of high-value (5-point) controls first, as these represent the most significant security impact and are weighted most heavily in the assessment.

• Review all 110 controls and classify each as MET, NOT MET, or NOT APPLICABLE
• For each MET control, document the implementation with evidence (iboss exports, policy documents, logs)
• For each NOT MET control, create a POA&M entry with remediation steps and target completion date
• Calculate the SPRS score using the DoD Assessment Methodology point values
• Prepare the System Security Plan (SSP) with implementation descriptions for all 110 controls
• Prioritize remediation of 5-point controls, then 3-point, then 1-point
• Verify that no mandatory POA&M-prohibited controls have open items
• Submit the SPRS score and maintain the SSP and POA&M as living documents
• Schedule annual reassessment to maintain certification currency