The text of the System and Information Integrity Procedure
Approval #
| Role | Name | Signature |
|---|---|---|
| Chief Information Security Officer (CISO) |
Revision History #
| Date | Version | Description | Reviewer |
|---|---|---|---|
| 2026-10-31 | 1.0 | Initial issuance | [Reviewer name] |
Review cycle: Every year, under the Policy and Procedure Management Policy.
1. Purpose #
The people named in this procedure use it to carry out the SI control family policy (POL-SI). It covers every control in the system and information integrity family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.
This general procedure covers every control in the SI family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.
2. Scope #
This procedure applies to every information system that the Organization operates, or that others operate for it, under the low security baseline.
2.1 CSF 2.0 Alignment #
The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:
- ID.IM — Improvements (Identify function)
- PR.PS — Platform Security (Protect function)
- PR.IR — Technology Infrastructure Resilience (Protect function)
- DE.CM — Continuous Monitoring (Detect function)
- DE.AE — Adverse Event Analysis (Detect function)
- RS.AN — Incident Analysis (Respond function)
- RS.MI — Incident Mitigation (Respond function)
- RC.RP — Recovery Plan Execution (Recover function)
3. Controls Covered #
This procedure covers the following 12 controls in the SI family:
| Control | Title | Enhancement |
|---|---|---|
| SI-01 | Policy and Procedures | No |
| SI-02 | Flaw Remediation | No |
| SI-03 | Malicious Code Protection | No |
| SI-04 | System Monitoring | No |
| SI-05 | Security Alerts, Advisories, and Directives | No |
| SI-12 | Information Management and Retention | No |
| SI-12(1) | Limit Personally Identifiable Information Elements | Yes |
| SI-12(2) | Minimize Personally Identifiable Information in Testing, Training, and Research | Yes |
| SI-12(3) | Information Disposal | Yes |
| SI-18 | Personally Identifiable Information Quality Operations | No |
| SI-18(4) | Individual Requests | Yes |
| SI-19 | De-identification | No |
3.1 Derived Governance Requirements #
The requirements below come from federal governance sources and apply to the SI control family. They add to the NIST SP 800-53 control requirements that the Procedure section carries out.
OMB M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents through EDR
- The organization must ensure endpoint data is consolidated, retained, and archived to support analysis and insight as defined in CISA’s technical reference architecture. EDR solutions must be consistent with applicable privacy and statistical laws. (OMB M-22-01, §3)
CISA BOD 26-04: Prioritizing Security Updates Based on Risk
- The organization must follow CISA’s Internet Exposure Reduction Guidance to determine if vulnerable assets are publicly exposed, and must prioritize remediation of internet-exposed vulnerabilities over internal-only vulnerabilities. (CISA BOD 26-04, §2)
- The organization must track and report remediation status for all KEV catalog vulnerabilities, consolidating federal vulnerability remediation guidelines under a single directive. (CISA BOD 26-04, §3)
CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection
- The organization must conduct regular vulnerability detection across all assets and share results with CISA. Asset visibility is a prerequisite for effective patching, configuration management, and security lifecycle management. (CISA BOD 23-01, §2)
CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- The organization must develop and publish a vulnerability disclosure policy (VDP) that authorizes good-faith security research on internet-facing systems and gives a clear process for receiving and responding to reports. (CISA BOD 20-01, §1)
- The organization must establish a vulnerability handling process that includes triage, remediation timelines, and communication with reporters. The VDP must include clear authorization language to protect good-faith researchers from legal action. (CISA BOD 20-01, §2)
OMB M-23-02: Migrating to Post-Quantum Cryptography
- The organization must conduct a prioritized inventory of all cryptographic systems, focusing first on systems that: use asymmetric encryption for logical access control, contain data expected to remain sensitive beyond 2035, or use algorithms vulnerable to quantum cryptanalysis. (OMB M-23-02, §II.A)
OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography
- The organization must establish or update an internal governance structure with defined roles to oversee PQC migration, integrate PQC readiness into existing governance, and submit a PQC Migration Plan to OMB and ONCD within 120 days of the memo, aligned to NIST IR 8547, containing a risk-based system prioritization strategy and timelines and milestones for all migration phases. Deadline: Plan due 2026-10-22. (OMB M-26-15, Action Two)
44 U.S.C. 2911: Disclosure requirement for official business conducted using non-official electronic messaging accounts
- The organization must make sure that staff who create or send a record from a non-official messaging account copy an official account, or forward a complete copy to it within 20 days. Deadline: 20 days after the message is created or sent. (44 U.S.C. 2911)
NARA Bulletin 2023-02: Expanding the Use of a Role-Based Approach (Capstone) for Electronic Messages
- The organization must manage text, chat, and instant messages about agency business as federal records, and do not let messaging tools delete them before the records schedule allows. (NARA Bulletin 2023-02)
4. Procedure #
4.1 General Implementation Approach #
The Organization implements the SI controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the System and Information Integrity family.
The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.
Responsible party: The Information System Security Officer (ISSO) / System Administrator carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the SI policy (POL-SI) for the role definitions.
4.2 Control-Specific Procedures #
SI-01 — Policy and Procedures #
Baselines: Low / Moderate / High / Privacy CSF 2.0: DE.CM (Continuous Monitoring)
- Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:
- [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] system and information integrity policy that:
- Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
- Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
- Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls;
- Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the system and information integrity policy and procedures; and
- Review and update the current system and information integrity:
- Policy at least every 3 years and following significant changes; and
- Procedures at least annually and following [Assignment: organization-defined events — to be defined].
Procedure:
The CISO’s office keeps POL-SI and PROC-SI and runs their review cycle. The CISO’s office sends each issuance or revision to the Authorizing Official, System Owners, ISSOs, and the stakeholders on the distribution list, and records the distribution on that list.
The CISO’s office opens the review every 3 years in the policy library in the document management system. The CISO’s office gathers input from System Owners and ISSOs and checks the documents against the current the Cybersecurity and Infrastructure Security Agency (CISA) directives and the Office of Management and Budget (OMB) guidance. The office also confirms that the workflows it describes still match the environment. A change in technology, enterprise architecture, or the data types the Organization processes reopens the documents before the next scheduled review. For example, a new endpoint platform or a new category of data starts a review. The CISO approves each revision, and the change history stays with the document.
Evidence: the approved policy and procedures with their change history, the distribution records, and the review record in the document management system for each scheduled or event-driven cycle.
SI-02 — Flaw Remediation #
Baselines: Low / Moderate / High CSF 2.0: ID.IM (Improvements), PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience), DE.CM (Continuous Monitoring)
- Identify, report, and correct system flaws;
- Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
- Install security-relevant software and firmware updates within thirty (30) days of release of updates of the release of the updates; and
- Incorporate flaw remediation into the organizational configuration management process.
Procedure:
The vulnerability scanner scans the environment continuously. Each scan result becomes a risk-ranked ticketing system remediation ticket assigned to the owning administrator. Its due date is the earliest of the CISA Binding Operational Directive (BOD) 26-04 Table 1 timeline and the RA-05 timeframe for its severity. Administrators work the shortest due dates first, such as Known Exploited Vulnerabilities (KEV) catalog entries on internet-exposed assets.
Before a broad installation, administrators test each security update for effectiveness and side effects. The mobile device management (MDM) tool deployment rings send endpoint updates to a pilot group first. Server and cloud changes go through pre-production testing under the change process. Updates that pass go out on schedule. When an update fails testing, the administrator records the failure, works with the vendor on a fix, and keeps compensating measures in place until the fix installs.
The administrator closes a ticket only after a scanner rescan confirms the fix. The ISSO tracks remediation status across systems and reports KEV status as CISA BOD 26-04 requires. Evidence: the scan results, the remediation tickets with their due dates, the deployment ring records, the rescan results, and the status reports.
SI-03 — Malicious Code Protection #
Baselines: Low / Moderate / High CSF 2.0: PR.PS (Platform Security), DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)
- Implement signature based and non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;
- Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;
- Configure malicious code protection mechanisms to:
- Perform periodic scans of the system at least weekly and real-time scans of files from external sources at to include endpoints and network entry and exit points as the files are downloaded, opened, or executed in accordance with organizational policy; and
- to include blocking and quarantining malicious code; and send alert to administrator or defined security personnel near-realtime in response to malicious code detection; and
- Address the receipt of false positives during malicious code detection and eradication and the resulting potential impact on the availability of the system.
Procedure:
Administrators run the endpoint detection and response (EDR) tools on every endpoint and server with real-time protection turned on. The tools scan files from external sources as users download, open, or run them, run a full scan at least every week, and update protection content automatically as vendors release it. The secure web gateway inspects web traffic at the boundary and stops malicious content before it reaches an endpoint.
When a tool detects malicious code, it blocks and quarantines the code and keeps a copy of the malware file where it can. The tool sends an alert to the Security Operations Center (SOC), the incident response team, the System Owner, the ISSO, and the responsible administrators. The detection telemetry goes to the security information and event management (SIEM) system, where the SOC works the incident.
The SOC decides each suspected false positive. When the SOC confirms a false positive, an administrator adds an approved and documented exclusion, and the SOC records the availability impact of the event. Evidence: the protection configuration and update status, the detection and quarantine records, the SIEM system incidents, the alert notifications, and the documented exclusion list.
SI-04 — System Monitoring #
Baselines: Low / Moderate / High CSF 2.0: ID.IM (Improvements), PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience), DE.CM (Continuous Monitoring)
- Monitor the system to detect:
- Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Assignment: organization-defined monitoring objectives — to be defined]; and
- Unauthorized local, network, and remote connections;
- Identify unauthorized use of the system through the following techniques and methods: [Assignment: organization-defined techniques and methods — to be defined];
- Invoke internal monitoring capabilities or deploy monitoring devices:
- Strategically within the system to collect organization-determined essential information; and
- At ad hoc locations within the system to track specific types of transactions of interest to the organization;
- Analyze detected events and anomalies;
- Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;
- Obtain legal opinion regarding system monitoring activities; and
- Provide [Assignment: organization-defined system monitoring information — to be defined] to [Assignment: organization-defined personnel or roles — to be defined] [Selection (one or more): as needed; [organization-defined] — to be defined].
Procedure:
The SIEM system collects endpoint detections from the EDR tools, web and network events from the secure web gateway, and the system logs collected under the OMB M-26-14 minimum logging baseline. The SIEM system correlation rules turn these events into incidents, and the SOC analyzes each one. Sensors run at the boundary and on hosts. When an investigation needs visibility into a specific type of transaction, the SOC adds collection at that point and removes it when the need ends.
The SOC analyzes anomalies and escalates them under the Incident Response Plan. When threat conditions change, for example through intelligence reporting, an active campaign, or a directive, the CISO raises the monitoring level and the SOC adjusts rules and thresholds to match. The standing legal opinion on monitoring scope stays with the program records.
The SOC sends alerts and artifacts to the SOC Manager, the incident response team, the System Owner, the ISSO, and the CISO as events occur. The SOC also sends a [SI-04 parameter 5 — to be defined] summary and reports significant threat changes immediately. Evidence: the SIEM system incidents and rule configurations, the alert distribution records, the [SI-04 parameter 5 — to be defined] summaries, and the monitoring adjustment records.
SI-05 — Security Alerts, Advisories, and Directives #
Baselines: Low / Moderate / High CSF 2.0: ID.IM (Improvements), DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis), RS.AN (Incident Analysis)
- Receive system security alerts, advisories, and directives from CISA on an ongoing basis;
- Generate internal security alerts, advisories, and directives as deemed necessary;
- Disseminate security alerts, advisories, and directives to: to include system security personnel and administrators with configuration/patch-management responsibilities; and
- Implement security directives in accordance with established time frames, or notify the issuing organization of the degree of noncompliance.
Procedure:
The SOC monitors the inbound channels: CISA and OMB issuances, vendor notifications, and traffic from the Enterprise Security Operations Center and the incident response team. The SOC triages each item to decide whether it applies to the Organization. The SOC opens a ticketing system record for each actionable item, with an owner and the deadline the directive sets. The SOC routes informational items to the roles they concern and drafts an internal advisory when local conditions call for one.
The SOC sends each item to the System Owners, ISSOs, and administrators who must act on it. When the scope requires, the SOC also sends it to the IT office, all personnel, contract vendors, or the cloud service providers. The owner tracks implementation to closure and attaches verification evidence to the record. When a deadline is at risk, the CISO reports the degree of noncompliance to the issuing organization before the date passes.
Evidence: the advisory intake log, the dissemination records, the directive tickets with their closure evidence, and any noncompliance notifications.
SI-12 — Information Management and Retention #
Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.PS (Platform Security)
Manage and retain information within the system and information output from the system in accordance with applicable laws, executive orders, directives, regulations, policies, standards, guidelines and operational requirements.
Procedure:
System Owners work with records management personnel to map each system’s information to the records schedules that apply. They configure retention to match for application data, system outputs, and the administrative records the control program itself produces. Security telemetry follows the logging standard: the SIEM system keeps twelve months in active storage and eighteen months in cold storage.
When a retention period ends, the System Owner carries out the disposition the schedule requires, either destruction or transfer, and documents it under a ticketing system record. A litigation or investigation hold suspends disposition for the affected records until the hold is lifted. The ISSO verifies the retention configuration when a system is authorized and when it changes.
Evidence: the retention mappings, the storage and retention configurations, the disposition records, and the hold documentation.
SI-12(1) — Limit Personally Identifiable Information Elements #
Baselines: Privacy
Limit personally identifiable information being processed in the information life cycle to the following elements of personally identifiable information: [Assignment: organization-defined elements of personally identifiable information — to be defined].
Procedure:
During design and before each release, the System Owner compares the data fields in the system with the personally identifiable information (PII) elements listed in the privacy impact assessment. The Privacy Officer reviews the comparison. If a field is not on the list, the developers remove it, or the System Owner asks the Senior Agency Official for Privacy (SAOP) to approve an updated privacy impact assessment. The ISSO checks the same list during each security assessment and reports any extra PII field as a finding.
Evidence: the field comparison records, the approved privacy impact assessment, SAOP approvals of changes, and assessment findings.
SI-12(2) — Minimize Personally Identifiable Information in Testing, Training, and Research #
Baselines: Privacy
Use the following techniques to minimize the use of personally identifiable information for research, testing, or training: [Assignment: organization-defined techniques — to be defined].
Procedure:
Before a test, research, or training activity starts, the project lead asks the System Owner to approve a data set. The development team builds synthetic data for the activity and loads it into the test or training environment in the cloud platform. The System Owner confirms that the data set contains no real PII and records the approval. If a project lead believes real PII is necessary, the lead sends a written request to the Privacy Officer, who forwards it to the SAOP for a decision.
Evidence: the System Owner’s data set approvals, the description of each synthetic data set, and any SAOP exception decisions.
SI-12(3) — Information Disposal #
Baselines: Privacy
Use the following techniques to dispose of, destroy, or erase information following the retention period: [Assignment: organization-defined techniques — to be defined].
Procedure:
The Information Owner identifies records whose retention period has ended and tells the System Owner. The system administrators then erase the data, including copies, backups, and archived logs in the SIEM system. For a device that leaves service or is lost, the endpoint team issues a wipe command through the MDM tool. Media that staff cannot erase go to destruction. The administrator who performs the work records the method, the date, and the items in a disposal record. The ISSO reviews the disposal records during each security assessment.
Evidence: the records schedule entry, disposal and destruction records, the MDM tool wipe logs, and the ISSO’s review notes.
SI-18 — Personally Identifiable Information Quality Operations #
Baselines: Privacy
- Check the accuracy, relevance, timeliness, and completeness of personally identifiable information across the information life cycle [Assignment: organization-defined frequency — to be defined]; and
- Correct or delete inaccurate or outdated personally identifiable information.
Procedure:
The System Owner plans each quality check with the Information Owner and the Privacy Officer. The plan names the data sets, the PII fields, and the method for each test, such as matching a sample against source records. Where the system allows it, developers add input checks that test the format of each field at entry.
The data steward runs the check and lists each record that is wrong, out of date, irrelevant, or incomplete. The data steward then corrects or deletes each listed record. The system keeps a change history that shows the old value, the new value, the date, and who made the change. If a wrong record may have affected a decision about a person, the System Owner tells the program office so that staff can review the decision.
The Privacy Officer reviews the results of each check and reports trends and unresolved problems to the SAOP.
Evidence: the quality check plan, the check results, the list of corrected or deleted records, the system change history, and the Privacy Officer’s report to the SAOP.
SI-18(4) — Individual Requests #
Baselines: Privacy
Correct or delete personally identifiable information upon request by individuals or their designated representatives.
Procedure:
The Privacy Officer logs each request when it arrives and confirms the identity of the requester or the representative. The Privacy Officer sends the request to the System Owner, who finds the records and proposes a correction or deletion. If the change is not clear, the Privacy Officer consults the SAOP and General Counsel. The data steward makes the approved change and records it in the system’s change history. The Privacy Officer then sends the requester a written decision.
Evidence: the request log, identity check records, the SAOP and General Counsel consultation notes, the system change history, and the decision letter.
SI-19 — De-identification #
Baselines: Privacy
- Remove the following elements of personally identifiable information from datasets: [Assignment: organization-defined elements — to be defined]; and
- Evaluate [Assignment: organization-defined frequency — to be defined] for effectiveness of de-identification.
Procedure:
The data owner sends a request to the System Owner that names the data set and its intended use. A trained data steward removes the listed elements and any other fields that the intended use does not need. The data steward records the method and the fields removed. The Privacy Officer reviews the result and the System Owner approves the release. Staff store the de-identified data set in the cloud platform apart from the source data.
The Privacy Officer tests each released data set [SI-19 parameter 2 — to be defined]. The test tries to link records to people by using other available data. The Privacy Officer reports the results to the SAOP. If the test links any record to a person, the System Owner withdraws the data set, and the data steward applies a stronger method.
Evidence: the de-identification requests, the method and field removal records, the System Owner’s release approvals, the effectiveness test reports, and the SAOP’s decisions.
5. Parameters (ODP Values) #
The following organization-defined parameters apply to controls in this family:
| Parameter | What it sets | Value | Source |
|---|---|---|---|
| SI-01_ODP[05] | at least every 3 years | FedRAMP default | |
| SI-01_ODP[07] | at least annually | FedRAMP default | |
| SI-01_ODP[08] | significant changes | FedRAMP default | |
| si-02_odp | within thirty (30) days of release of updates | FedRAMP default | |
| SI-03_ODP[01] | signature based and non-signature based | FedRAMP default | |
| SI-03_ODP[02] | at least weekly | FedRAMP default | |
| SI-03_ODP[03] | to include endpoints and network entry and exit points | FedRAMP default | |
| SI-03_ODP[04] | to include blocking and quarantining malicious code | FedRAMP default | |
| SI-03_ODP[06] | administrator or defined security personnel near-realtime | FedRAMP default | |
| SI-05_ODP[01] | CISA | FedRAMP default | |
| SI-05_ODP[02] | to include system security personnel and administrators with configuration/patch-management responsibilities | FedRAMP default |
6. Evidence Artifacts #
Carrying out this procedure produces these records:
- System integrity monitoring configuration
- Patch management records
- Malware protection scan reports
- Security alert and advisory records
7. Performance Measurement #
The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.
| # | Performance Measure | Target | Frequency | Data Source |
|---|---|---|---|---|
| 1 | Endpoints with EDR deployed and reporting (M-22-01) | ≥ 99% | Monthly | EDR console vs. asset inventory |
| 2 | Critical flaws remediated within defined timelines | 100% ≤ 15 days (internet-facing) / ≤ 30 days | Monthly | Patch and vulnerability reports |
| 3 | Malicious code protection current (signatures/engines ≤ 24h old) | 100% | Weekly | antivirus (AV)/EDR update compliance |
| 4 | CISA directives and alerts actioned within directed timelines | 100% | Per directive | Directive compliance tracker |
| 5 | Integrity verification failures investigated | 100% within 72 hours | Monthly | File integrity monitoring alerts |
8. Training Requirements #
Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:
- General security awareness training, which all personnel take under POL-AT.
- Role-based training on this procedure’s steps, tools, and evidence.
- Training on the technology platforms listed under Technology Implementation, matched to their duties.
Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.
9. Governance References #
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy, September 2, 2020.
- CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
- OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
- Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
- Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
- OMB M-22-01: Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response (EDR), October 8, 2021.
- OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
- CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
- CISA Known Exploited Vulnerabilities Catalog, updated continuously.
- Disclosure requirement for official business conducted using non-official electronic messaging accounts (44 U.S.C. § 2911).
- NARA Bulletin 2023-02: Expanding the Use of a Role-Based Approach (Capstone) for Electronic Messages: Expanding the Use of a Role-Based Approach (Capstone) for Electronic Messages, January 5, 2023.
- NIST Cybersecurity Framework 2.0, February 26, 2024.
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards, November 12, 2024.
- OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
- OMB M-26-14: Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026.