NIST SP 800-53 SI System and Information Integrity: Key Controls, Enhancements and How to Evidence Them

The System and Information Integrity (SI) family is where patching, malware defence, monitoring and integrity checking meet an assessor, and it fails most often because the time periods and monitoring objectives in the controls were never written down. This guide works through the SI family of NIST SP 800-53 Rev. 5 control by control: what each key control and enhancement requires, which baselines select it, which organisation-defined parameters you must set, and what evidence an assessor will ask for under SP 800-53A. It includes the Release 5.2.0 changes to flaw remediation and integrity verification. It is written for control owners, system security plan authors, vulnerability and endpoint teams and assessors. For the catalogue as a whole, see the NIST SP 800-53 Guide; this page goes one level deeper on SI only.

Key takeaways

• SI-2c is a deadline you set. Flaw remediation requires installing security-relevant updates within a time period you define after release, testing them first and running them through configuration management. A blank parameter is a finding on its own.
• Release 5.2.0 added root cause analysis. SI-2(7), new on 27 August 2025, asks you to find and fix the underlying cause when an update or remediation fails. It is not yet in a baseline, so add it by tailoring if update failures have hurt you.
• SI-4 is monitoring with objectives. It asks you to state what you are monitoring for, detect unauthorised local, network and remote connections, and get a legal opinion on monitoring. Moderate adds real-time analysis, traffic monitoring and system-generated alerts.
• SI-7 starts at Moderate. Integrity verification of software, firmware and information is not in the Low baseline. At High, SI-7(15) requires cryptographic code authentication before installation.
• Several SI controls are developer-facing. SI-10 input validation, SI-11 error handling and SI-16 memory protection apply at Moderate and High and need evidence from the people who build the system, not only from operations.

The SI family at a glance

The table lists the SI base controls with baseline allocations, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High). SI-9 is withdrawn. SI-13 to SI-15, SI-17 and SI-20 to SI-23 are outside the baselines and are summarised later; the privacy controls SI-18 and SI-19 are omitted.

For baseline selection and tailoring, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

SI-2: flaw remediation and the 5.2.0 changes

SI-2 requires you to (a) identify, report and correct flaws, (b) test software and firmware updates for effectiveness and side effects before installation, (c) install security-relevant updates within a time period you define after release, and (d) incorporate flaw remediation into configuration management. NIST updated the SI-2 and SI-2(5) discussion in Release 5.2.0, responding to Executive Order 14306, to put more weight on the reliability and integrity of updates.

The settings column is our recommendation, not NIST text. Federal agencies also have CISA's Known Exploited Vulnerabilities catalogue and its binding directive, which should feed the first tier; see the CISA KEV Catalogue Guide. For planning patching as preventive maintenance, see the NIST SP 800-40 Rev 4 Patch Management Guide. Unsupported components that cannot be patched are handled by SA-22 in the SA family.

SI-3, SI-5 and SI-8: malicious code, advisories and spam

• SI-3 Malicious Code Protection: signature-based or non-signature-based mechanisms at system entry and exit points; automatic updates under configuration management; periodic scans at a frequency you define and real-time scans of files from external sources at the endpoint or network entry and exit points as files are downloaded, opened or executed; block, quarantine or another action you define, plus an alert; and handling of false positives. Modern EDR usually covers the mechanism; the evidence gap is coverage of servers, containers and build agents. See the EDR Guide.
• SI-5 Security Alerts, Advisories, and Directives: receive advisories from external organisations you name, generate internal ones, disseminate them to defined roles or organisations, and implement directives within time frames or tell the issuer about noncompliance. Name the feeds: vendor advisories, national CERT, sector ISAC. SI-5(1) at High automates distribution.
• SI-8 Spam Protection (M, H): spam protection at entry and exit points and updates under configuration management; SI-8(2) automates the updates. See the Email Security Guide.

SI-4: system monitoring

SI-4 asks you to monitor for attacks and indicators against monitoring objectives you define, detect unauthorised local, network and remote connections, identify unauthorised use through techniques you name, place monitoring strategically and ad hoc, analyse events, adjust monitoring when risk changes, obtain a legal opinion on monitoring, and provide monitoring information to defined roles. It works with AU: AU produces and protects the records, SI-4 watches the system.

Monitoring objectives should name identity threats explicitly: anomalous use of service accounts and API keys, new credentials added to applications, tokens used from unexpected locations. Non-human identities often have predictable behaviour, which makes deviations easier to detect than for people. See the SIEM Guide and the IDS and IPS Guide.

SI-6 and SI-7: verification and integrity

• SI-6 Security and Privacy Function Verification (H): verify correct operation of security functions you define, at defined transitional states, on command or at a frequency, alert on failure, and shut down, restart or take another action. Examples include checking that EDR, logging agents and host firewalls are running after start-up.
• SI-7 Software, Firmware, and Information Integrity (M, H): use integrity verification tools to detect unauthorised changes to software, firmware and information you define, and take defined actions. SI-7(1) performs integrity checks at start-up, at defined transitional states or events, or at a frequency. SI-7(7) feeds detected unauthorised changes into incident response.
• High additions: SI-7(2) automated notification of integrity violations, SI-7(5) automated response such as shutdown or restart, and SI-7(15) cryptographic authentication of defined software or firmware before installation.
• SI-7(12) Integrity Verification: revised in Release 5.2.0; it requires the integrity of defined user-installed software to be verified before execution. It is outside the baselines.

File integrity monitoring, signed packages and images verified at deployment, measured or Secure Boot and application allowlisting are the usual implementations. Signing keys are machine credentials and need their own protection. See the File Integrity Monitoring Guide, the Code Signing Security Guide and the Application Allowlisting Guide.

SI-10, SI-11, SI-12 and SI-16: application and data controls

• SI-10 Information Input Validation (M, H): check the validity of the information inputs you define. SI-10(6) Injection Prevention, outside the baselines, is worth tailoring in for web and API systems. See the Input Validation and Output Encoding Guide.
• SI-11 Error Handling (M, H): error messages give what is needed for correction without revealing exploitable information, and are shown only to roles you define. Stack traces and connection strings in responses fail it.
• SI-12 Information Management and Retention (L, M, H): manage and retain information in line with laws, policies and operational requirements. It connects to AU-11 for audit records and to your data retention schedule.
• SI-16 Memory Protection (M, H): controls you define to protect memory from unauthorised code execution, such as data execution prevention and address space layout randomisation, usually inherited from the operating system with evidence of configuration.

Outside the baselines, SI-13 predictable failure prevention, SI-14 non-persistence (refresh from trusted sources, which fits immutable infrastructure), SI-15 output filtering and SI-17 fail-safe procedures are the most useful tailoring candidates.

How to evidence SI controls

SP 800-53A uses examine, interview and test for SI. The table turns that into evidence that answers an assessor in one pass.

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the SI family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system.

1. Write the parameters. SI-2c time periods, SI-3c scan frequency and actions, SI-4a monitoring objectives, SI-5 sources and SI-7 scope.
2. Reconcile coverage. Compare patch, anti-malware and monitoring agent coverage with the asset inventory, including cloud workloads and build infrastructure.
3. Automate status first. Put SI-2(2) automated status reporting in place before changing deployment, so you can measure.
4. Deploy updates in rings. Pilot, broad, then sensitive systems, with a pause and rollback route for each ring. Record failures and run SI-2(7) root cause analysis on them.
5. Turn on integrity checks in alert-only mode. Tune SI-7 monitoring for two weeks, then enable SI-7(7) incident integration.
6. Write monitoring use cases against objectives. Tie each SI-4 objective to rules, alert routes and owners.
7. Collect evidence continuously. See the Audit Evidence and Continuous Controls Monitoring Guide.

Decision guidance

• Low versus Moderate: Low covers patching, malware protection, monitoring, advisories and retention. Moderate adds automated patch status, integrity verification, spam protection and the developer-facing input validation, error handling and memory protection controls.
• Automatic updates or controlled release: SI-2(5) automatic updates suit endpoints and stateless services; controlled release suits stateful or safety-related systems. Either way, define the time period and measure it.
• TLS inspection or endpoint telemetry: SI-4(10) at High can be met by inspection at defined points or by relying on endpoint visibility where inspection would break certificate pinning or mutual TLS between services. Record the choice.

Detection and measurement

• Median and 90th percentile time to remediate per SI-2 tier, against the parameter.
• Share of assets reporting patch status, anti-malware status and monitoring telemetry, against inventory.
• Number of failed or rolled-back updates and SI-2(7) root cause analyses closed.
• Integrity violations detected and share linked to an approved change.
• Monitoring objectives with at least one tested detection rule.

Framework mapping

Mappings are "intersects with", not equivalence, and are our reading of the texts. Check them against NIST's published informative references before using them in an audit. See the Control Mapping Guide.

Common failure patterns

• One patch window for everything: a monthly cycle with no faster tier for exploited, internet-facing flaws.
• Coverage measured against the agent console, not the inventory: unmanaged hosts are invisible, so coverage looks complete.
• Monitoring without objectives: rules exist but nobody can say which SI-4a objective each one serves.
• Integrity monitoring tuned into silence: noisy FIM rules disabled rather than scoped, leaving binaries unmonitored.
• Failed updates retried, not analysed: the same deployment fails each month and nobody runs root cause analysis.
• Developer controls left to operations: SI-10 and SI-11 marked inherited from the platform with no code-level evidence.

Practitioner checklist

• Set tiered SI-2c remediation periods and measure against them.
• Reconcile patch, anti-malware and monitoring coverage with the asset inventory monthly.
• Write SI-4 monitoring objectives that include service account and token misuse.
• Name SI-5 advisory sources and trace advisories to action.
• Define SI-7 integrity scope for binaries, firmware and critical configuration.
• Protect code signing keys and verify signatures before installation.
• Tailor in SI-2(7) and run root cause analysis on failed updates.
• Collect SI-10 and SI-11 evidence from development and testing.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: Revises Security and Privacy Control Catalog to Improve Software Update and Patch Releases
• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA: Known Exploited Vulnerabilities and BOD 22-01
• NIST: SP 800-171 Rev. 3
• NIST: Cybersecurity Framework 2.0
• CIS: Controls Assessment Specification, Control 7 Continuous Vulnerability Management

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Patch Management Guide · Risk-Based Vulnerability Management Guide · NIST SP 800-53 IA Identification and Authentication