System & information integrity.

01What this family protects

System & Information Integrity protects a system’s ongoing health — that known flaws get fixed, that malicious code gets kept out or caught when it gets in, and that unusual activity gets noticed. Where most Level 2 families set up a control once and maintain it, SI is explicitly about an ongoing, active watch: patches, signatures, advisories, and monitoring are all things that go stale if nobody keeps working at them.

02The rule says

All 7 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.14 has the full text and discussion for each; Source Library covers when to open it.

03In practice

Patch and flaw management (3.14.1). Identifying, reporting, and correcting known software and firmware flaws on a defined timeline that reflects severity — a critical, actively exploited vulnerability gets patched faster than a low-severity finding with no known exploit.

Malicious-code protection (3.14.2, 3.14.4–3.14.5). Anti-malware software at the points where code most often enters a system — email, web traffic, endpoints, removable media — kept current as vendors release new signatures and detection updates, running both periodic scans and real-time scanning of anything coming from outside the organization.

Staying current on threats (3.14.3). Watching public security advisories (CISA, a vendor’s own security bulletins, an ISAC if the organization belongs to one) relevant to the systems in use, and acting on what’s found rather than letting advisories pile up unread.

Monitoring (3.14.6–3.14.7). Watching inbound and outbound traffic for signs of an attack in progress, and being able to identify when a system is being used in a way it shouldn’t be — not necessarily a dedicated security-operations function for a small shop, but a real capability to notice when something looks wrong, not just a firewall’s default logging left unexamined.

04Where it fails

The classic miss is malware protection that’s installed but not actually current — the software runs, but signature or detection updates stopped applying months ago because nobody noticed a licensing lapse or a broken update service.

A second gap is 3.14.3’s advisory-monitoring requirement treated as optional because it doesn’t produce a visible artifact the way a scan report does. An organization that never checks CISA or a vendor’s security bulletins has no way of knowing a newly disclosed flaw in software it runs is being actively exploited.

05What evidence may look like

Endpoint-protection console output showing current signature or detection versions across the fleet; patch-management reports showing what’s been applied and what’s outstanding, with dates; a record — even informal — of security advisories reviewed and any action taken; and monitoring-tool configuration or sample alerts showing inbound and outbound traffic is actually being watched.

06At the shop

07Commonly confused with

Risk Assessment (RA). RA’s scanning (3.11.2) looks for vulnerabilities before they’re exploited; SI’s monitoring (3.14.6–3.14.7) looks for signs an attack is already underway. See Risk Assessment.

Audit & Accountability (AU). SI’s monitoring produces alerts and observations in something close to real time; AU governs what gets recorded and retained about system activity more broadly, including what SI’s monitoring tools log. See Audit & Accountability.

08Cross-desk links

None load-bearing for this family. Malware protection, patch management, and monitoring are covered on this desk’s own family pages; see Risk Assessment and Audit & Accountability.

09Sources