The System and Information Integrity Domain: the vigilance layer of the compliance program

What the System and Information Integrity Domain Is For

The System and Information Integrity domain addresses two complementary concerns: keeping the environment free of the flaws and malicious code that create exploitable conditions, and detecting the unauthorized activity that occurs when prevention falls short. Its seven requirements move from flaw remediation through malicious code protection, scanning, and monitoring, concluding with the identification of unauthorized use. The domain is where the compliance program operates on the premise that perfect prevention is impossible and continuous detection is essential.

The practitioner reading of SI is that it is the vigilance domain. Every other domain builds controls. SI verifies that those controls are operating and identifies when they are not. The boundary that SC establishes must be monitored for attacks under SI.3.14.6. The authorization baselines that AC defines must be enforced with detection for unauthorized use under SI.3.14.7. The vulnerabilities that RA identifies must be remediated with timeliness under SI.3.14.1. Without SI, the rest of the framework operates blind to its own failures.

For defense contractors preparing for CMMC Level 2 assessment, the SI domain also contains one of the more conceptually demanding controls in the entire framework. SI.3.14.7 on identifying unauthorized use requires that the organization know what authorized use looks like before it can detect deviation. The authorization-first reading of SI.3.14.7 white paper examines the two assessment objectives that NIST SP 800-171A splits the control into, and argues that the control cannot be satisfied by monitoring technology alone without the policy artifact that gives detection its reference point.

The Structure of the 7 Controls

The seven SI requirements organize into two clusters that reflect distinct concerns within the domain.

The first cluster covers protection from exploits. These four controls (3.14.1, 3.14.2, 3.14.4, and 3.14.5) address flaw remediation, malicious code protection, and the scanning that keeps systems clean. The cluster is the preventive side of the domain, working to reduce the conditions that unauthorized activity would otherwise exploit.

The second cluster covers monitoring and detection. These three controls (3.14.3, 3.14.6, and 3.14.7) address external security advisories, monitoring of communications for attacks, and the identification of unauthorized use. The cluster is the detection side of the domain, accepting that prevention cannot be complete and providing the visibility that allows response when prevention falls short.

The first cluster addresses flaw remediation and malicious code protection. These four controls work together to reduce the conditions under which unauthorized activity would otherwise find purchase in the environment.

SI.L2-3.14.1Flaw Remediation

System flaws must be identified, reported, and corrected in a timely manner. The control addresses vulnerability management as an operational discipline. Identification includes the scanning and advisory monitoring that surface flaws. Reporting is the internal communication that brings flaws to the attention of the team responsible for remediation. Correction is the actual patching or mitigation work that closes the vulnerability. The "timely manner" standard is an organizational decision that should align with the risk posed by each flaw category, with documented service level commitments that define acceptable remediation timelines. This control interacts directly with Risk Assessment through RA.3.11.2 and 3.11.3, which establish the scanning and remediation disciplines that SI.3.14.1 depends on.

SI.L2-3.14.2Malicious Code Protection

Protection from malicious code must be provided at designated locations within organizational systems. The control requires antimalware capability at the locations where malicious code is most likely to enter the environment. Designated locations typically include email gateways, endpoints, file servers, and network ingress points. The specific technology is not prescribed, but the protection must be operational rather than merely deployed. An antimalware product installed but not running, not receiving updates, or not configured to scan relevant file types does not satisfy the control. The assessable evidence includes the designated locations list, the protection mechanism in place at each, and the operational state of the protection.

SI.L2-3.14.4Update Malicious Code Protection

Malicious code protection mechanisms must be updated when new releases are available. The control addresses the operational reality that antimalware is only as effective as its signature database and detection engine. Updates must occur on a cadence that keeps protection current with emerging threats, and the update mechanism must be verified to operate consistently across the protected endpoints. Findings in this area often involve updates that are configured but fail silently on specific systems, leaving gaps that are invisible until an incident reveals them or until audit review surfaces them.

SI.L2-3.14.5System & File Scanning

Periodic scans of organizational systems and real-time scans of files from external sources must be performed. The control has two components. The periodic scan component addresses scheduled examination of systems for malicious code or other integrity issues. The real-time component addresses files as they enter the environment, whether through email attachments, downloads, removable media, or external file transfers. Both components must be operational and the scan scope must cover the full environment rather than just the systems where scanning is easiest to configure.

The second cluster addresses the detection side of the domain. These three controls accept that prevention cannot be complete and provide the visibility that allows response when attacks or unauthorized activity occur.

SI.L2-3.14.3Security Alerts & Advisories

System security alerts and advisories must be monitored, and action must be taken in response. The control requires that the organization is aware of emerging threats, vulnerabilities, and advisories affecting the systems in its environment. Sources typically include CISA advisories, vendor security bulletins, US-CERT notifications, and threat intelligence feeds appropriate to the organization's technology stack. The response obligation means that advisories are not just read but acted on, with documented decisions about which advisories require action in the specific environment and what actions were taken.

SI.L2-3.14.6Monitor Communications for Attacks

Organizational systems including inbound and outbound communications traffic must be monitored to detect attacks and indicators of potential attacks. The control requires monitoring that extends across both directions of network traffic. Inbound monitoring addresses external attack attempts. Outbound monitoring addresses compromised internal systems that may be attempting to exfiltrate data or communicate with external command infrastructure. The monitoring must produce detections that are actionable, meaning the output goes to personnel or systems capable of responding. Monitoring that generates alerts no one reviews does not satisfy the control, regardless of the technology sophistication behind the alerts.

SI.L2-3.14.7Identify Unauthorized Use

Unauthorized use of organizational systems must be identified. NIST SP 800-171A splits this control into two distinct assessment objectives: authorized use is defined, and unauthorized use is identified. Most implementations address only the second objective by investing in SIEM, DLP, and CASB coverage without producing the policy artifact that gives detection its reference point. The authorization-first reading of the control is the more defensible interpretation, because detection of unauthorized use requires a prior definition of what authorized use looks like. The dedicated white paper on SI.3.14.7 walks through the six elements of the authorization baseline (acceptable use policy, role-based access expectations, approved application inventory, approved data movement patterns, approved remote access conditions, and approved third-party and ESP interactions), explains how each element maps to related AC, CM, PS, and MP controls, and addresses the forward compatibility of the authorization baseline through the Revision 2 to Revision 3 transition.

Where System and Information Integrity Intersects with Other Domains

SI intersects with nearly every other domain because its monitoring function touches all of them, and its output feeds the broader compliance program.

Risk Assessment is the closest partner to SI. RA.3.11.2 establishes vulnerability scanning, and SI.3.14.1 establishes flaw remediation. The two controls work together as a cycle where RA identifies flaws and SI closes them. RA.3.11.3 remediation in accordance with risk depends on the SI operational capability to actually perform the remediation within the SLAs the risk picture defines.

Audit and Accountability provides the primary data source that SI monitoring depends on. Audit records are what SI.3.14.6 examines to detect attacks, and they are what SI.3.14.7 uses as evidence of deviation from authorized use. A weak AU implementation produces a weak SI capability regardless of the monitoring technology in place.

Access Control, Configuration Management, Personnel Security, and Media Protection all contribute to the authorization baseline that SI.3.14.7 references. AC defines what users can access. CM defines the approved configurations. PS defines the authorized personnel status. MP defines the approved data movement patterns. Each domain contributes an element of the baseline that SI uses to distinguish authorized from unauthorized activity.

Incident Response consumes SI output as its primary trigger. A detection under SI.3.14.6 or 3.14.7 is often what initiates the IR lifecycle, and the quality of the SI capability directly affects how effectively IR can respond.

Security Assessment depends on SI for the continuous monitoring that CA.3.12.3 requires. SI monitoring activity feeds directly into CA observation of control effectiveness, and the two domains operate together to detect drift from documented baselines between formal assessments.

System and Communications Protection defines the boundaries that SI monitors. The network segmentation SC establishes determines where SI monitoring must be positioned to observe relevant activity, and the technical protections SC implements are what SI validates are operating in practice.

Common Implementation Pitfalls

Several patterns come up repeatedly in System and Information Integrity readiness work.

Flaw remediation SLAs that are not aligned with risk. The organization remediates vulnerabilities on a uniform schedule that does not distinguish between critical and low-severity flaws. A medium-severity vulnerability on a critical system waits in the same queue as a high-severity vulnerability on a peripheral system. The SI.3.14.1 timeliness standard expects risk-informed prioritization, which requires integration with the RA risk picture rather than CVSS-only scheduling.

Antimalware updates that fail silently. The update mechanism is configured, but specific systems are behind on signatures and no one notices until the next audit or incident. SI.3.14.4 requires updates to occur, and the operational discipline includes monitoring for update failures. A centralized antimalware management console with alerting on out-of-date endpoints addresses this more reliably than distributed update configuration without central visibility.

Security advisories read but not acted on. The team subscribes to CISA advisories, vendor bulletins, and threat feeds. The advisories accumulate in inboxes and dashboards. No documented process translates advisory content into action in the specific environment. SI.3.14.3 requires that action be taken in response, and the assessable evidence is the documented decision trail from advisory to action or documented justification for no action.

Monitoring coverage gaps. The SIEM, IDS, or network monitoring platform covers the corporate network but not the manufacturing network, or covers servers but not endpoints, or covers ingress but not egress. SI.3.14.6 addresses both inbound and outbound traffic across organizational systems, and partial coverage produces gaps in the detection capability that would otherwise surface attacks or anomalies.

SI.3.14.7 treated as monitoring alone. The organization invests in detection technology for unauthorized use without producing the authorization baseline that gives the detection its reference point. The assessment objective that authorized use is defined is left unaddressed, and the detection capability has nothing to measure deviation against. The remediation is the authorization baseline described in the SI.3.14.7 white paper, which establishes the reference point that detection can then operate against.

Alerts generated but not reviewed. The monitoring capability produces output, but the personnel workflow does not include reliable review of that output. Alerts accumulate, significant detections blend in with noise, and real incidents surface through other channels rather than through the monitoring that was supposed to detect them. The remediation is alert triage and tuning to reduce noise, combined with documented review responsibilities that make the output actionable.

Real-time file scanning not extended to all ingress paths. Scanning is configured on email attachments but not on downloads, or on downloads but not on files transferred through cloud services, or on workstation endpoints but not on server file shares. The SI.3.14.5 real-time scanning obligation covers files from external sources broadly, and partial coverage produces the blind spots that malicious code uses to enter the environment.

Where to Start

For an organization new to the SI domain, the first work is the authorization baseline.

The foundational deliverable is the authorization baseline that SI.3.14.7 requires. The baseline defines what authorized use looks like in the specific environment: the acceptable use policy, role-based access expectations, approved application inventory, approved data movement patterns, approved remote access conditions, and approved third-party and ESP interactions. Each element traces to controls in other domains that the contractor already documents, and the baseline becomes the reference point against which detection operates. The SI.3.14.7 authorization-first white paper walks through the baseline construction in detail.

The second deliverable is the flaw remediation program. Documented service level commitments by risk level, integration with the vulnerability scanning output from RA, and operational tracking of remediation against those commitments. The program ties SI.3.14.1 to the broader RA framework and produces the evidence that assessment requires.

The third deliverable is the monitoring coverage map. Which systems are monitored by which mechanism, which ingress and egress points are covered, and where the gaps exist. The map supports SI.3.14.6 directly and also provides the foundation for continuous monitoring under CA.3.12.3. Gap closure follows from the map rather than from accumulating monitoring technology without strategic direction.

With the authorization baseline, flaw remediation program, and monitoring coverage map in place, the SI domain becomes an operational discipline rather than a technology acquisition exercise. The controls are seven, but the capability they describe is where the compliance program most directly confronts the adversarial reality that all the other domains protect against.