SI-2: Flaw Remediation

Quick-reference card

What this control requires

SI-02 requires organizations to identify, report, and correct system flaws, then test and deploy security-relevant updates within defined timelines. It’s one of the most operationally demanding controls in the System and Information Integrity family because it touches every layer of the technology stack, from operating systems and middleware to firmware on network appliances.

In practice, flaw remediation means standing up a repeatable process that catches known vulnerabilities, routes them to the right teams, validates that patches don’t break production, and deploys fixes before attackers can exploit the gap. That process has to feed back into configuration management so every change is tracked and auditable. Organizations that treat patching as a one-off IT task rather than a managed security workflow consistently end up with unpatched systems sitting in production for months.

The control also requires testing software and firmware updates for both effectiveness and potential side effects before installation. Skipping this step is a common failure mode, especially in environments with legacy applications or custom integrations where a vendor patch can introduce regressions. The intent is to balance speed of remediation against operational stability, with the organization defining acceptable time periods based on risk factors like system criticality, threat environment, and the nature of the flaw itself.

Why it matters

Unpatched software remains the most reliable entry point for attackers targeting organizations of any size. The gap between vulnerability disclosure and active exploitation has compressed to days in many cases, which means flaw remediation processes that operate on monthly or quarterly cycles leave organizations exposed during the window that matters most.

That exposure compounds when the same vulnerable software runs across multiple organizations. A single unpatched application can turn into a campaign-scale event affecting dozens or hundreds of targets simultaneously, as attackers automate exploitation against a known flaw.

Click2Gov Municipal Payment Portal Campaign (2017-2018)

In late 2017, attackers began systematically targeting municipal government websites running Click2Gov, a payment portal software used by dozens of U.S. cities to accept online utility bill payments. The attackers exploited a known vulnerability in the software to install card-skimming malware that silently copied payment card details at the moment of transaction. At least 46 cities were breached across the campaign.

The City of Oxnard, California notified the public in May 2018 after its bank flagged fraudulent transactions. Investigation revealed the city’s Click2Gov instance had been running unpatched from approximately July 2017. The patch had been available, but it hadn’t been applied.

Security researchers subsequently found approximately 295,000 stolen payment card records from the broader campaign listed for sale on dark web markets at roughly $10 per record. Oxnard and many of the other affected municipalities weren’t running vulnerability management processes adequate to detect or prioritize the unpatched exposure before attackers found it for them. The Click2Gov campaign is a textbook illustration of what SI-02 exists to prevent: a known flaw, an available patch, and exploitation that was entirely avoidable.

What attackers exploit

• Delayed patch deployment. Organizations that lack defined timelines for applying security updates leave known vulnerabilities open for weeks or months. Attackers scan for these gaps at scale.
• Untested updates that never ship. When teams skip testing or lack a staging environment, patches stall in approval queues indefinitely. The update exists but never reaches production.
• Incomplete asset inventories. Flaws can’t be remediated on systems the organization doesn’t know it owns. Shadow IT, forgotten test instances, and unmanaged firmware create blind spots.
• Configuration drift after patching. A patch applied without configuration management integration can be silently rolled back by automated deployments, system restores, or image refreshes, reintroducing the vulnerability.

How to implement

The most common implementation failure isn’t a lack of tooling. It’s a disconnect between the teams that discover flaws, the teams that test patches, and the teams that deploy them. Without a unified workflow, patches sit in queues while the clock runs on attacker exploitation.

For your organization

Start by defining organizational time periods for deploying security-relevant updates. These periods should vary based on risk, not follow a single blanket policy. Critical vulnerabilities in internet-facing systems need shorter windows than low-severity flaws in isolated internal tools. Base prioritization on exploitation probability data like EPSS (Exploitation Prediction Scoring System) and known exploited vulnerability catalogs rather than relying solely on CVSS severity scores.

Build a controlled patching environment where you can test updates before they reach production. This testing process needs to validate two things: that the patch resolves the identified flaw, and that it doesn’t introduce side effects that break functionality or degrade performance. Document the test results for each update cycle, because auditors will look for evidence that testing happened, not just that patches were applied.

Integrate flaw remediation into your configuration management process so every patch, service pack, or firmware update is tracked as a managed change. This means using change control records, maintaining an up-to-date system component inventory, and ensuring that vulnerability scans feed directly into your remediation workflow. Without this integration, there’s no reliable way to verify that a flaw was corrected across all affected systems.

Assign clear ownership for each stage of the workflow. Someone needs to be accountable for identifying flaws through scanning and assessment, someone needs to own the testing and validation step, and someone needs to confirm deployment. When these responsibilities aren’t defined, patches fall through the cracks. Conduct periodic reviews, at minimum quarterly, to verify that the remediation pipeline is functioning and that no critical flaws have aged past their defined remediation windows.

For your vendors

Assessing a vendor’s flaw remediation maturity requires looking beyond whether they claim to patch regularly. Request their flaw remediation policy and verify that it defines specific timelines for applying security updates based on severity. Ask for evidence of their patch testing process, including test results from recent update cycles. A vendor that can’t produce these records likely doesn’t have a structured remediation program.

Request their system component inventory or a summary that confirms they track which software and firmware versions are deployed across their environment. Without this inventory, the vendor can’t reliably identify which systems are affected when a new flaw is disclosed. Ask whether they maintain a controlled patching environment and how they validate that updates don’t introduce regressions before production deployment.

Review their configuration management records to confirm that patches are tracked as managed changes, not applied ad hoc. Red flags include vendors who can’t demonstrate that vulnerability scanning feeds into their remediation workflow, vendors whose patch timelines consistently exceed their own stated policy windows, and vendors who lack evidence of testing before deployment.

Conduct a vulnerability assessment of the vendor’s external attack surface to independently verify their claims. Look for outdated software versions, known vulnerable services, and unpatched infrastructure components. Discrepancies between what a vendor reports and what external scanning reveals are a strong indicator that their flaw remediation process has gaps.

Evidence examples

Cross-framework mapping

Related controls

• CA-05 Plan of Action and Milestones: tracks identified flaws through remediation to closure, ensuring nothing ages out without resolution.
• CM-03 Configuration Change Control: governs how patches and updates flow through the change management process before deployment.
• CM-04 Impact Analyses: requires testing the impact of changes, including security patches, before they’re applied to production.
• CM-05 Access Restrictions for Change: limits who can apply patches and updates, reducing the risk of unauthorized or untested modifications.
• CM-06 Configuration Settings: defines the security baselines that patches must restore or maintain after installation.
• CM-08 System Component Inventory: provides the asset list needed to determine which systems are affected by a disclosed flaw.
• MA-02 Controlled Maintenance: covers scheduled maintenance activities, including firmware updates on physical infrastructure.
• RA-05 Vulnerability Monitoring and Scanning: feeds the flaw identification step by continuously scanning for known vulnerabilities.
• SA-08 Security and Privacy Engineering Principles: guides how systems are designed to support efficient patching and update mechanisms.
• SA-10 Developer Configuration Management: ensures vendors and developers manage their own code changes in ways that support downstream flaw remediation.

Frequently asked questions

What is NIST SP 800-53 SI-02?

SI-02 is the NIST SP 800-53 control that requires organizations to identify system flaws, test software and firmware updates for effectiveness and side effects, install security-relevant updates within defined time periods, and incorporate the entire remediation cycle into configuration management. It applies across all three baselines (LOW, MODERATE, HIGH), making it a universal requirement for federal systems and any organization aligning to the framework. The control’s scope covers every type of software and firmware, including operating systems, applications, network device firmware, and security tools like malicious code signature updates.

What happens if SI-02 is not implemented?

Without a structured flaw remediation process, known vulnerabilities remain unpatched and exploitable in production environments, creating predictable entry points for attackers. The Click2Gov campaign demonstrated this risk at scale, where approximately 46 municipalities running the same unpatched payment portal software were breached using the same known exploit. Auditors assessing SI-02 compliance will look for specific evidence, including patch testing records, installation change control logs, and a maintained list of recent remediation actions performed on the system. Gaps in any of these areas indicate that the organization can’t verify whether identified flaws were corrected.

How do you audit SI-02?

Auditing SI-02 starts with reviewing the organization’s flaw remediation procedures and verifying that security-relevant software and firmware updates are installed within the organization-defined time period documented in their policy. Auditors then examine test results from update installations to confirm that patches were validated for both effectiveness and potential side effects before deployment. They verify that the organization maintains a current list of flaws and vulnerabilities affecting the system, cross-referenced against configuration management records that track each remediation action as a managed change.

How often should you patch for NIST 800-53 compliance?

NIST SP 800-53 doesn’t prescribe a universal patching frequency. Instead, SI-02 requires each organization to define its own time periods for installing security-relevant updates, based on factors like system criticality, the security category of the information processed, organizational risk tolerance, and the current threat environment. Most organizations set tiered timelines, applying critical patches to internet-facing systems within days and lower-severity updates within 30 to 90 days. The key compliance requirement is documenting your defined time periods in your system security plan and demonstrating through installation records that you’re consistently meeting them.