System and Information Integrity Procedure

Approval #

Revision History #

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 moderate 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 30 controls in the SI family:

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)

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] system and information integrity policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the system and information integrity policy and the associated system and information integrity controls;

2. 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
3. Review and update the current system and information integrity:

1. Policy at least every 3 years and following significant changes; and
2. 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)

1. Identify, report, and correct system flaws;
2. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
3. Install security-relevant software and firmware updates within thirty (30) days of release of updates of the release of the updates; and
4. 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-02(2) — Automated Flaw Remediation Status #

Baselines: Moderate / High

Determine if system components have applicable security-relevant software and firmware updates installed using [Assignment: organization-defined automated mechanisms — to be defined] at least monthly.

Procedure:

The vulnerability scanner runs authenticated scans across all assets at least every month and reports each component’s status against the security-relevant releases that apply to it. Each missing update becomes a ticketing system ticket assigned to the owning administrator. Administrators flag components that drop out of scan coverage and re-enroll them. The MDM tool reports endpoint update state, and administrators use it to confirm the scan results. The ISSO reviews the monthly coverage and update status and raises any gaps with System Owners. Evidence: the monthly scan reports, the coverage records, and the ticket queue of missing updates.

SI-02(3) — Time to Remediate Flaws and Benchmarks for Corrective Actions #

Baselines: Moderate / High

1. Measure the time between flaw identification and flaw remediation; and
2. Establish the following benchmarks for taking corrective actions: [Assignment: organization-defined benchmarks — to be defined].

Procedure:

The vulnerability scanner records when it first detects a flaw and when a rescan confirms the fix. The ticketing system holds the ticket dates in between. The ISSO computes the time to remediate from those records and compares the results against the benchmarks. The ISSO reports the results to the CISO and System Owners. The ISSO analyzes each benchmark miss for its cause, such as testing delays, ownership gaps, or scheduling conflicts. The ISSO opens a ticket for each corrective change and tracks it to closure. Evidence: the timing reports, the benchmark comparisons, and the corrective action tickets.

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)

1. Implement signature based and non-signature based malicious code protection mechanisms at system entry and exit points to detect and eradicate malicious code;
2. Automatically update malicious code protection mechanisms as new releases are available in accordance with organizational configuration management policy and procedures;
3. Configure malicious code protection mechanisms to:

1. 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
2. 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

4. 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)

1. Monitor the system to detect:

1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Assignment: organization-defined monitoring objectives — to be defined]; and
2. Unauthorized local, network, and remote connections;

2. Identify unauthorized use of the system through the following techniques and methods: [Assignment: organization-defined techniques and methods — to be defined];
3. Invoke internal monitoring capabilities or deploy monitoring devices:

1. Strategically within the system to collect organization-determined essential information; and
2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;

4. Analyze detected events and anomalies;
5. 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;
6. Obtain legal opinion regarding system monitoring activities; and
7. 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-04(1) — System-wide Intrusion Detection System #

Baselines: Moderate / High

Connect and configure individual intrusion detection tools into a system-wide intrusion detection system.

Procedure:

Connectors send detections from the EDR tools and from the secure web gateway to the SIEM system, so the SOC sees every detection in one console with shared context. The SOC maintains the connectors and monitors their health. When a source stops sending data, the SOC treats it as a coverage gap and restores it under a ticketing system ticket. Administrators connect a new detection tool to the SIEM system before it enters production service. Evidence: the connector configuration and health status, the onboarding records, and the coverage gap tickets.

SI-04(2) — Automated Tools and Mechanisms for Real-time Analysis #

Baselines: Moderate / High

Employ automated tools and mechanisms to support near real-time analysis of events.

Procedure:

The SIEM system applies analytics rules to telemetry as it streams in from endpoint, network, and cloud sources and creates incidents in near real time. The SOC triages the incident queue, tunes rules that misfire, and adds rules as new attack techniques appear. The SOC records every rule change. When a correlation could link records in a way that creates privacy risk, the SOC assesses that risk with the Senior Agency Official for Privacy (SAOP) before the rule runs. Evidence: the analytics rule set with its change history, the incident queue records, and the tuning notes.

SI-04(4) — Inbound and Outbound Communications Traffic #

Baselines: Moderate / High

1. Determine criteria for unusual or unauthorized activities or conditions for inbound and outbound communications traffic;
2. Monitor inbound and outbound communications traffic continuously for [Assignment: organization-defined unusual or unauthorized activities or conditions — to be defined].

Procedure:

The secure web gateway monitors web and tunnel traffic at the boundary. The SIEM system correlates network telemetry against the SOC’s criteria: command and control beaconing, large outbound transfers, encrypted tunnels that no one authorized, and current advanced persistent threat indicators. Each match raises a SIEM system incident in near real time, and the SOC investigates it under the Incident Response Plan. The SOC maintains the criteria list and updates it as new intelligence and indicators arrive. Evidence: the monitoring criteria, the SIEM system rules that apply them, the incident records, and the criteria update history.

SI-04(5) — System-generated Alerts #

Baselines: Moderate / High

Alert [Assignment: organization-defined personnel or roles — to be defined] when the following system-generated indications of compromise or potential compromise occur: [Assignment: organization-defined compromise indicators — to be defined].

Procedure:

When telemetry matches a compromise indicator, the SIEM system raises the alert automatically and sends it to the SOC, the incident response team, the System Owner, the ISSO, and the responsible administrators. The alert includes its artifacts, the log entries and context an analyst needs to start work. The SOC maintains the routing lists and reviews them when personnel or responsibilities change. The SOC corrects any delivery failure under a ticketing system ticket. Evidence: the alert rules and routing configuration, the delivered notifications, and the incident records the alerts opened.

SI-04(16) — Correlate Monitoring Information #

Baselines: Moderate / High

Correlate information from monitoring tools and mechanisms employed throughout the system.

Procedure:

The SIEM system holds the endpoint detections, the web and network events from the secure web gateway, and the platform logs in one workspace. Correlation rules connect events across sources, for example an endpoint detection followed by unusual outbound traffic, or a privileged change paired with an unusual session. When a log source is added, the SOC builds correlation rules for it. When a rule produces an incident, the SOC triages it the same way as any other incident. When a rule produces only false alarms, the SOC tunes or retires it. Evidence: the correlation rule set, the incidents the rules generated, and the tuning records.

SI-04(18) — Analyze Traffic and Covert Exfiltration #

Baselines: Moderate / High

Analyze outbound communications traffic at external interfaces to the system and at the following interior points to detect covert exfiltration of information: [Assignment: organization-defined interior points — to be defined].

Procedure:

Outbound traffic passes through the secure web gateway at the boundary, where inspection covers encrypted sessions under policy. The SIEM system analyzes the flow records for signs of exfiltration, such as data hidden inside permitted protocols, transfers staged in pieces, and destinations that are unusual for the sender. Collection at the interior points the Organization designates feeds the same analysis. Each match raises a SIEM system incident, and the SOC investigates it with the owner of the affected data. When the SOC confirms exfiltration, it escalates the incident under incident response. Evidence: the inspection policy, the analytics rules for exfiltration patterns, the records of the designated collection points, and the investigation tickets.

SI-04(23) — Host-based Devices #

Baselines: Moderate / High

Implement the following host-based monitoring mechanisms at [Assignment: organization-defined system components — to be defined]: [Assignment: organization-defined host-based monitoring mechanisms — to be defined].

Procedure:

Administrators install the EDR tools as part of the standard build, and the agents report continuously. The MDM tool device compliance flags any endpoint whose agent is missing or has stopped reporting. Administrators restore a flagged host under a ticketing system ticket before it returns to service. Agent telemetry streams to the SIEM system for correlation with the other monitoring data. The SOC reviews agent coverage and follows up on gaps with the owning administrators. Evidence: the agent deployment and health reports, the compliance flags, the restoration tickets, and the coverage summaries.

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)

1. Receive system security alerts, advisories, and directives from CISA on an ongoing basis;
2. Generate internal security alerts, advisories, and directives as deemed necessary;
3. Disseminate security alerts, advisories, and directives to: to include system security personnel and administrators with configuration/patch-management responsibilities; and
4. 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-06 — Security and Privacy Function Verification #

Baselines: Moderate / High CSF 2.0: DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)

1. Verify the correct operation of [Assignment: organization-defined security and privacy functions — to be defined];
2. Perform the verification of the functions specified in SI-6a [Selection (one or more): [organization-defined]; upon command by user with appropriate privilege; [organization-defined] — to be defined];
3. Alert to include system administrators and security personnel to failed security and privacy verification tests; and
4. [Selection (one or more): shut the system down; restart the system; [organization-defined] — to be defined] when anomalies are discovered.

Procedure:

Administrators run function verification when a system starts, restarts, shuts down, or aborts, and when a privileged user requests it. The verification confirms four things. The system writes audit records and log collection receives them. Alerting paths deliver a test event. Detection agents report as healthy. The services approved in the System Security and Privacy Plan (SSPP) respond as expected. The SIEM system supports the verification by flagging log sources that have stopped sending data, so a system whose audit stream stops shows up as a health finding.

When a check fails, the system alerts the SOC, the System Owner, the ISSO, and the administrators. The administrator applies the response selected in advance for that system, either a shutdown, a restart, or the approved alternative, and records the action in the ticketing system. When failures recur, the administrator escalates to the System Owner, who corrects the underlying fault.

Evidence: the verification results for each transitional state, the health findings for silent sources, the failure alerts, and the response records.

SI-07 — Software, Firmware, and Information Integrity #

Baselines: Moderate / High CSF 2.0: PR.PS (Platform Security), DE.CM (Continuous Monitoring), DE.AE (Adverse Event Analysis)

1. Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information: [Assignment: organization-defined software, firmware, and information — to be defined]; and
2. Take the following actions when unauthorized changes to the software, firmware, and information are detected: [Assignment: organization-defined actions — to be defined].

Procedure:

Integrity monitoring runs continuously. The EDR tools detect tampering with operating system and application software on hosts, such as unexpected binaries, modified system files, and altered protection settings. Vulnerability scans verify that the installed software and firmware match the approved configuration. The alerts go to the SIEM system.

When a tool detects a change, it notifies the SOC and the responsible administrators. The administrator restores the component to its approved state from the standard build or from backup. The SOC decides whether the change was an error or an attack and escalates to incident response unless the change is clearly harmless. Firmware deviations follow the same steps, with the hardware owner involved.

Evidence: the integrity monitoring configurations, the detection alerts, the SIEM system incident records, the restoration tickets, and the investigation conclusions.

SI-07(1) — Integrity Checks #

Baselines: Moderate / High

Perform an integrity check of [Assignment: organization-defined software, firmware, and information — to be defined] [Selection (one or more): at startup; at [organization-defined]; [organization-defined] — to be defined].

Procedure:

The checks run on the defined triggers. At startup, restart, shutdown, and abort, the system compares its software against the baseline. Privileged users run a check on demand. New threat intelligence and new installations prompt a targeted check. A full check runs at least monthly through vulnerability scans compared against the approved software states. Each deviation becomes a ticketing system ticket for the administrators and the SOC, and the administrator records its disposition. Evidence: the check triggers and schedule, the monthly scan results, the deviation findings, and their dispositions.

SI-07(7) — Integration of Detection and Response #

Baselines: Moderate / High

Incorporate the detection of the following unauthorized changes into the organizational incident response capability: [Assignment: organization-defined changes — to be defined].

Procedure:

When the EDR tools or the SIEM system analytics detect an unauthorized configuration change or a privilege elevation, the detection becomes a SIEM system incident under the Incident Response Plan. The SOC triages the incident, contains it where needed, corrects the change, and records the disposition. The record keeps the artifacts: what changed, when, and under which account. The SOC keeps this history so that it can find patterns across months and support legal action when needed. Evidence: the incident records with their artifacts, the dispositions, and the retained detection history.

SI-08 — Spam Protection #

Baselines: Moderate / High CSF 2.0: PR.PS (Platform Security)

1. Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages; and
2. Update spam protection mechanisms when new releases are available in accordance with organizational configuration management policy and procedures.

Procedure:

Administrators run spam filtering on inbound and outbound mail, so that a compromised account cannot send spam from the Organization. They update the filter definitions under change control as vendors release them.

The email administrators publish a Sender Policy Framework (SPF) record and a Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy of reject for every second-level domain, with aggregate reports going to CISA. The administrators configure mail servers to offer opportunistic Transport Layer Security (STARTTLS) with the weak protocols and ciphers turned off. The ISSO treats a CISA Cyber Hygiene finding against these settings as a vulnerability with a due date.

Users send reports of spam or phishing that got through to the SOC. The SOC adjusts the filtering and hands confirmed malicious campaigns to incident response. Administrators record quarantine handling, release requests, and filter changes in the ticketing system.

Evidence: the filtering configuration and update records, the published SPF and DMARC records, the STARTTLS scan results, the user report dispositions, and the change tickets.

SI-08(2) — Automatic Updates #

Baselines: Moderate / High

Automatically update spam protection mechanisms [Assignment: organization-defined frequency — to be defined].

Procedure:

Administrators enable automatic updating in the spam protection configuration, so new definitions and detection content apply in near real time as the vendor publishes them. Administrators monitor the update status. A failed or stalled update raises a ticketing system ticket, and the administrator works it to correction. Administrators confirm the update state during each configuration review of the messaging boundary. The setting itself is under change control, so no one can turn it off without a recorded change. Evidence: the automatic update configuration, the update status records, and the correction tickets.

SI-10 — Information Input Validation #

Baselines: Moderate / High CSF 2.0: PR.PS (Platform Security)

Check the validity of the following information inputs: [Assignment: organization-defined information inputs — to be defined].

Procedure:

Development teams build validation under the Organization’s secure development standard. The application checks each defined input for format, length, range, and allowed values at the point of entry, and it rejects bad input with a safe error message instead of passing it to an interpreter. The System Owner records the validated input definitions with the system’s documentation.

Two activities verify the validation. The development team tests the validation before each release under the change process. The vulnerability scanner scans deployed applications for injection and input-handling weaknesses on its continuous cycle. Each weakness becomes a ticketing system ticket on the standard remediation timeline, and the team closes the ticket only after a retest confirms the fix.

Evidence: the input validation definitions, the release test records, the scan findings with their closure verification, and the remediation tickets.

SI-11 — Error Handling #

Baselines: Moderate / High CSF 2.0: PR.PS (Platform Security)

1. Generate error messages that provide information necessary for corrective actions without revealing information that could be exploited; and
2. Reveal error messages only to include the ISSO and/or similar role within the organization.

Procedure:

Each application splits its error output. The user sees a plain message that says what to do next. The diagnostic detail, such as stack traces, query text, and internal identifiers, goes to protected logs that the SIEM system collects. Only technical support staff with a valid need and the ISSO can read those logs. The development standard bars sensitive content from user-facing errors, and each release review checks how the application behaves on failure paths.

When an error message in production exposes internal detail, the System Owner opens a ticketing system ticket and corrects the message on the remediation timeline. The ISSO reviews the fix.

Evidence: the error handling standard, the release review results, the restricted log access configuration, and the correction tickets.

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 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-16 — Memory Protection #

Baselines: Moderate / High CSF 2.0: PR.PS (Platform Security)

Implement the following controls to protect the system memory from unauthorized code execution: [Assignment: organization-defined controls — to be defined].

Procedure:

The standard configuration includes the memory protections. Group policy applies the security baseline to domain-joined systems, and the MDM tool deploys the same baseline to managed endpoints. Both baselines keep execution restrictions and memory-layout randomization turned on. The exploit protection features in the EDR tool guard the running processes. Procurement standards require hardware and software that resist the memory manipulation attacks the Cybersecurity Team defines.

Compliance reports from the MDM tool and baseline checks flag any system whose protections have drifted. Administrators open a ticketing system ticket for each drifted system, restore the settings, and close the ticket. Each exception carries documented CISO approval and an expiry date.

Evidence: the baseline configurations, the compliance reports, the restoration tickets, and the exception register.

SI-18 — Personally Identifiable Information Quality Operations #

Baselines: Privacy

1. Check the accuracy, relevance, timeliness, and completeness of personally identifiable information across the information life cycle [Assignment: organization-defined frequency — to be defined]; and
2. 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

1. Remove the following elements of personally identifiable information from datasets: [Assignment: organization-defined elements — to be defined]; and
2. 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:

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.

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.