The System and Information Integrity (SI) domain keeps computers healthy and data honest. It is the immune system that looks for hidden infections. The SI family requires you to identify, report, and correct flaws. You must use antivirus and or anti-malware to scan computers, email, and files. You must know what normal behavior looks like and keep a constant eye out for abnormal behavior. System and Information Integrity keeps your network clean and your data accurate.
Domain level policies address the controls implemented within systems and organizations. Policies are the perfect home to define control parameters, such as frequencies. Procedures describe the implementation of policies or controls. Organizations may document procedures within the system security plan or within separate documents. Here are some of the principles that guided this system and information integrity policy:
A cover page tracks specific details regarding the policy, including:
NIST SP 800-53 defines specific objectives for domain-level policies. From this guidance we incorporate the following major sections into our policy:
The purpose statement should identify why the policy exists and what it aims to achieve.
The scope should identify who it applies to and under what circumstances.
The policy governance section covers most of the organization defined parameters. These subsections cover the following details:
The fourth section includes our policy statements. Subsection headings group related Policy statements together. Each policy statement has a unique number for traceability to other documents. A policy statement number consists of the section, subsection, and policy statement order.
The fifth section identifies the relevant roles and responsibilities identified in the policy. A single, short paragraph describes the responsibilities for each role. The sixth section identifies the supporting procedures. We opted to align our subsection headings with the names of supporting procedures. The seventh section identifies related documents, to include relevant policies. The eighth section documents a revision history. This table captures policy changes, including: version, effective date, approver(s), change summaries. The ninth section captures a formal authorization of the policy by the policy owner.
NIST identified a named set of procedures for each practice within NIST SP 800-171. The assessment guide (SP 800-171A) contains the original mappings. The CMMC assessment guides include this mapping as well. The potential assessment methods and objects section contains a subsection called examine. Within each practice, NIST identified relevant policies, procedures and other artifacts. We used the relevant procedures to organize the section headings within each policy.
Flaw Remediation
All end-user workstations must be registered with a patch management system before they are allowed into production use. When obtaining software and configuration scripts for these activities, personnel shall verify they are from a trusted and authenticated source. This verification includes downloading directly from official vendor websites or patch repositories and confirming the authenticity of any signing certificates. The use of patches or remediation scripts obtained from untrusted peer-to-peer sources, such as web forums, is strictly prohibited.
Personnel shall verify the integrity of software updates by comparing cryptographic hashes provided by the vendor or verifying digital signatures before execution.
All organizational systems shall be reviewed for general flaws on a thirty (30) day cycle to identify unauthorized services, misconfigurations, or known software weaknesses
Before any updates or patches are deployed to production, they must be reviewed and tested by an authorized test group to confirm they are secure, stable, and do not disrupt business operations. Vulnerability mitigation shall be performed by patching systems, removing or disabling vulnerable software, or isolating systems to prevent exploitation.
System flaws shall be remediated according to a risk-based timeline using the OWASP Risk Rating Methodology.
All critical-risk vulnerabilities or system flaws shall be mitigated within 30 days of discovery, or other mitigation strategies must be put in place to limit exposure before deployment. Applications with critical-risk issues are subject to being taken off-line or denied release into the production environment.
All high or medium-risk issues shall be reviewed to determine what is required to mitigate and scheduled accordingly, but shall be resolved within 90 days. Applications with high or medium-risk issues may be taken off-line or denied release into the production environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues shall be fixed in routine patch releases unless other mitigation strategies will limit exposure.
All low risk issues shall be reviewed to determine what is required to correct the issue and scheduled accordingly, generally within 180 days.
Any system flaw not automatically resolved within 30 days shall be reported internally via a service request or change ticket. The patch management system must provide the ability to report on applied/missing patches, track the last check-in date for each device, and remotely trigger installations.
If a device remains non-compliant with approved configuration standards for over 30 days, it shall be escalated to the Change Advisory Board (CAB). The CAB shall perform a risk assessment to determine a formal action, such as accepting the risk with a Plan of Action & Milestone (POA&M) entry, implementing a workaround, or disconnecting/disabling the device.
CMMC Objectives Covered in This Section:
Designated security personnel shall subscribe to external system security alerts, advisories (e.g., US-CERT, Vendor Notifications), and cyber threat intelligence sources. These alerts shall be monitored daily to ensure timely response to emerging threats, while broader threat intelligence trends shall be reviewed at least weekly.
When new cyber threats are observed, configuration management records shall be reviewed to identify the likelihood of the threat occurring within the organization’s specific environment. This analysis ensures that response efforts are prioritized based on actual system exposure.
When a cyber threat or security alert is identified as presenting a significant risk, designated security personnel shall communicate the threat to relevant stakeholders. Mitigation strategies shall be identified and either implemented on an emergency basis or added to the Plan of Action and Milestones (POA&M) for tracking.
CMMC Objectives Covered in This Section:
Antivirus and malware protection shall be enabled on all network-connected devices, including servers and end-user computing devices, wherever technically possible. Firmware-based appliances (e.g., printers, firewalls, switches, and SANs) are exempt from local antivirus installation but must be protected by network-level security controls to ensure comprehensive ecosystem integrity.
Malware protection systems shall be configured to provide continuous, real-time protection. This shall include enabling real-time scans of files as they are being downloaded, opened, or executed, and automatic scanning of portable storage devices (e.g., USB drives) immediately upon connection to the system.
Antivirus programs shall be set to update definitions automatically as new releases become available, at a minimum of once per 24 hours, and perform a full system scan at least once weekly to identify latent threats that may have bypassed real-time filters.
Malware protection systems shall utilize behavioral-based detection and heuristics to identify zero-day threats and anomalous system activity that may not yet have a known signature.
CMMC Objectives Covered in This Section:
Automatic spam filters shall be enabled at the email server to block, tag, or redirect both incoming and outgoing spam, malicious attachments, and restricted file types (e.g. executables). For example, outgoing spam may be blocked by default, while incoming spam is tagged and moved to the user’s junk folder. Furthermore, warning flags shall be enabled on messages originating from external senders.
Spam protection signatures and filtering rules shall be configured to update automatically when new releases are available from the vendor to ensure protection against evolving phishing campaigns.
The organization shall employ spoofing detection mechanisms to identify and quarantine illegitimate emails. Any email purporting to be from the internal domain that does not originate from the organization’s authorized email system shall be redirected to a quarantine folder to prevent delivery to the intended recipient.
Sandboxing shall be utilized to analyze active content, including macros and scripts, within a safe, isolated environment before delivery. If this analysis determines the item is malicious or that it alters the environment in an unexpected way, the item shall be blocked and the event logged for administrator review.
CMMC Objectives Covered in This Section:
The organization shall establish and maintain a Baseline of Authorized Use for all information systems. Authorized use is defined as activity that is directly required for the performance of official duties, the fulfillment of federal contract requirements, and the support of the organization’s mission. This baseline includes, but is not limited to, the use of authorized hardware, software, and communication protocols as documented in the Configuration Management Database (CMDB).
Any system activity, connection, or software execution that deviates from the established Baseline of Authorized Use shall be classified as unauthorized use. The organization shall implement automated monitoring tools to identify these deviations, including unauthorized data egress, access attempts by non-validated accounts, or the use of unapproved ports and protocols. All identified unauthorized use shall trigger an immediate security alert and be processed in accordance with the Incident Response Plan.
Security agents shall be deployed on all devices to enforce web content filtering. These agents shall be configured to deny access to unapproved site categories and known malicious domains (based on current threat intelligence) to strictly limit communications to authorized external systems.
VoIP traffic and usage shall be monitored for unauthorized activity, unusual traffic patterns, and potential security threats through the organization's SIEM or Network Monitoring Tool. Anomalies detected during VoIP monitoring shall trigger an alert for immediate investigation by the security team.
CMMC Objectives Covered in This Section:
FedRAMP guidance on how to write a control implementation statement states the following:
Write your policies before you start drafting your security plan. K2 GRC shows you exactly how each part of your policy connects to your security goals. This starts with selecting an objective to document.
After selecting a criteria, K2 GRC shows policy statements relevant to that criteria. The input screen shows the specific policy name and the statement’s number. This enables users to cite relevant policy sections within the control narratives. The system aggregates these control narratives to populate the system security plan (SSP).
The constant pressure of CMMC can be overwhelming. It is draining to spend your days worrying about unpatched bugs or hidden malware. Automating patches, employing antivirus and monitoring for abnormal behavior protects your system. Documenting compliance proves that you are a reliable link in the supply chain. You don't have to navigate the complex world of CMMC alone. Our System and Information Integrity Policy template is your compliance accelerator. It bridges the gap between requirements and strategy, saving you weeks of drafting. Download the policy template today to shore up your defenses. Simplify your audit preparation, and take a major leap forward toward your CMMC goals.
