What SI-2 flaw remediation requires and why it is hard to prove
If an assessor or contract asks you to show SI-2 Flaw remediation, the core answer is this: you need documented flaw identification, tested patching installed within defined periods, and flaw remediation built into your configuration management process. The control does not ask for a perfect patch record. It asks you to show that you find flaws, decide how fast to fix them, test updates for effectiveness and side effects before installation, and then install them on time. Release 5.2.0 of SP 800-53 (27 August 2025) gives SI-2 one organization-defined parameter, which is the period you must set for installing security-relevant updates, and seven control enhancements. The newest of these, SI-2(7) Root Cause Analysis, asks you to analyze why flaws occur, not only to fix them. Confirm with your assessor how they expect that enhancement to be evidenced, since it is not in any SP 800-53B baseline.
Unpatched flaws create exposure that attackers actively look for, so the patch itself is rarely what fails an assessment. The evidence trail usually fails. Teams often patch systems but cannot show the list of flaws that applied to a given system at a given time, the date each update was released, the period the organization had defined, or the test record that preceded installation. SP 800-53A examines three artifacts directly: a list of flaws and vulnerabilities potentially affecting the system, a list of recent flaw remediation actions performed on the system, and installation or change control records for security-relevant updates. If any of these three lists cannot be produced from a source the assessor can inspect, the control is hard to prove even when the systems are current.
A practical first step is to check whether your vulnerability findings, remediation tickets and change records can be joined by system and date. Self-hosted tools can help here. DefectDojo can import findings from many scanner formats and deduplicate them, Greenbone Community Edition stores scan results in PostgreSQL, Wazuh correlates agent software inventories with vulnerability data, and Fleet matches installed software against advisory sources. Each tool produces one part of the trail, and none of them decides whether your defined period was met or whether your testing was adequate. Those decisions belong to your organization, and an independent assessor tests them. Ask any implementation partner to show, in writing, which record proves each of the three examine objects before work starts.
Which systems, teams and suppliers SI-2 covers
SI-2 applies to every component inside the system boundary that has a flaw someone must fix, so the scope decisions come before the patch process. Each card below is a decision or boundary question that changes who patches what, how fast, and what evidence an assessor will ask to see.
System boundary and inventory
SI-2 only reaches components the organization has declared inside the authorization boundary. Confirm that the boundary, the asset inventory and the vulnerability scanning scope all list the same hosts, containers, network devices and cloud resources. Any component missing from the inventory is a component that will never receive a flaw remediation record. Ask who signs off changes to the boundary and how new assets enter the inventory.
Operating systems and applications
Operating system packages and installed applications are the most common source of findings that SI-2 expects to be remediated. Decide which team owns the base image and which owns each application layer, then record that split in writing. Where a vendor publishes its own advisories, confirm that someone monitors those feeds in addition to the scanner output.
Firmware and network devices
Firmware on servers, storage, switches, firewalls and hypervisors often sits outside the normal patch cycle and outside the tools that scan operating systems. Identify which device owners receive vulnerability information for firmware, and how long a firmware update must wait for a maintenance window. Assessors commonly look for the same installation and change control records for firmware as for software.
Containers and base images
A container inherits flaws from its base image and from every library added during the build, and it may be rebuilt rather than patched in place. Confirm whether the remediation action is a rebuild, a redeploy or an in-place update, and who approves each. Check that the registry, the build pipeline and the running workloads are all covered by scanning, so a fixed image is actually the one running in production.
Third-party and vendor-supplied components
Vendor appliances, managed services and bundled libraries carry flaws the organization cannot patch directly. The question for SI-2 is who installs the fix and who evidences it. Put remediation duties, notice periods and access to patches into supplier agreements, and record which components the organization relies on the vendor to remediate.
Patch stream owners and approvers
Each patch stream needs a named owner who tests, approves and installs updates, and a separate role that verifies the result. Map the owner for each stream: operating system, middleware, application, firmware, cloud services and vendor appliances. Ambiguous ownership is the usual reason flaws stay open past their defined period, so assign owners in the SI-2 procedure before the first assessment.
How an assessor tests SI-2
This table maps how an assessor works through SI-2 under SP 800-53A Release 5.2.0, covering the determination statements, examine objects, interview focus and common findings. Read it as a preparation checklist: each row names what the assessor will ask for and where evidence usually falls short.
| Assessment element | What the assessor does | Evidence or gap to address |
|---|---|---|
| Determination statements | Tests 10 determination statements for SI-2 using examine, interview and test methods | Map each statement to a named owner and a specific artifact before the assessment starts |
| Examine: flaw and vulnerability lists | Reviews the list of flaws and vulnerabilities that may affect the system | Scanner exports or a vulnerability register that covers all in-scope components, with dates and sources |
| Examine: recent remediation actions | Reviews the list of recent flaw remediation actions performed on the system | Tickets or change records linking each finding to a fix, a compensating control or a risk acceptance |
| Examine: installation and change control records | Reviews records for security-relevant software and firmware updates | Change tickets showing test results, approval and installation date for each security update |
| Interview: system owners | Asks how flaws are found, prioritized, tested and installed, and who decides | Consistent answers that match the written process and the records, with named roles |
| Test: sample verification | Selects sample flaws and traces them from detection through testing to installation | Traceable records for each sample, including any update that was tested and then deferred |
| Common finding: missing timeframes | Organization-defined remediation periods are not documented or not met | A written timeframe per severity, and a record showing whether each finding met it |
| Common finding: untested updates | Security updates are installed without recorded testing for effectiveness or side effects | Pre-deployment test evidence in a staging or test environment, retained with the change record |
Implementing SI-2 step by step
This sequence turns SI-2 from a policy statement into a working cycle in which flaws are detected, tested, installed within defined timeframes, recorded in change control and reviewed, leaving evidence an assessor can trace from detection to deployment.
Define remediation timeframes by severity
The organization owns this decision. Its security, IT operations and system owners agree on how long each class of flaw may remain open after a fix is released, and how the timeframes differ for security-relevant updates and other changes. SI-2 requires installation within a defined period, so the timeframes must be written down before anything is measured against them. Ask your assessor which parameter values they expect to see for your system, since SI-2 leaves that value to the organization. The output is an approved timeframe matrix, signed by the system owner and stored with the system security plan, that names the severity classes, the deadlines and the exception path for flaws that cannot be fixed on time.
Build the flaw inventory and detection sources
Identify every component in the system boundary, including operating systems, applications, firmware and libraries, and name the sources that will reveal flaws in each. Scanners such as Greenbone Community Edition, the Wazuh vulnerability detection module and Fleet can match installed software against vulnerability data, and a centralized store such as DefectDojo can collect findings from other scanners. Confirm the coverage of each tool against your own asset list, because a scanner that cannot see a device will not report its flaws. The output is an asset-to-source map and a dated list of flaws and vulnerabilities potentially affecting the system, which is the artifact an assessor will examine first.
Triage and assign each flaw to an owner
Deduplicate findings from the detection sources, confirm which ones apply to the system as deployed, and assign each one a severity and an accountable owner. DefectDojo deduplicates imported findings using per-tool hashcode fields, which reduces the same flaw being tracked several times. Record why a finding is judged not applicable, because an unexplained closure looks like an omission at assessment. The output is a triaged backlog in which every open flaw has a severity, an owner, a due date derived from the approved timeframe matrix and a link to the record that will hold its remediation evidence.
Test patches before installation
SI-2 expects the organization to test software and firmware updates for effectiveness and for potential side effects before they reach production. Build a test environment that mirrors the production configuration closely enough to show whether the fix closes the flaw and whether it breaks dependent services. Where a vendor patch cannot be tested in time, document the compensating action and the approval for deferring the test. The output is a short test record per update, covering the environment used, the rescan result showing the flaw is closed, the functional checks performed and the approver who accepted the risk of installation.
Schedule and install approved fixes
Schedule installation within the timeframe for each flaw and deploy through the normal maintenance path for the platform. Where automation is used, keep the deployment pipeline tied to the same ticket so that the change is traceable to the flaw that triggered it. Rescan the affected asset after installation, because a successful installation command does not prove the flaw is gone. The output is a deployment record linking the flaw identifier, the ticket, the installation time and the post-installation scan result showing the flaw is no longer detected, or a documented exception where it remains.
Record each action in change control
Route every security-relevant update through the organization's change control process so that approval, testing, implementation and rollback planning appear in one record. SI-2 is tied to configuration management, so the same evidence that shows a change was controlled should show which flaw it addressed. Confirm with your change board how emergency changes are recorded, since out-of-band fixes are the most common gap. The output is a change record for each remediation that references the flaw, the test record and the deployment record, which together give an assessor a complete chain from detection to installation.
Review remediation metrics and root causes
On a recurring schedule chosen by the organization, review open flaws against their timeframes, the number of exceptions, the age of the oldest open items and the flaws that recur on the same components. Where a flaw class keeps reappearing, examine the root cause, such as a missing baseline, an unpatched image or a gap in the inventory, and feed the finding back into configuration management and the timeframe matrix. Release 5.2.0 added the root cause analysis enhancement SI-2(7), which is not in any SP 800-53B baseline, so confirm whether your authorization or contract asks for it before building that step into the routine. The output is a dated review record with decisions, owners and changes to the process, which is the evidence that the cycle improves over time.
What the SI-2(7) root cause analysis enhancement adds in Release 5.2.0
SI-2(7) Root Cause Analysis is the enhancement that Release 5.2.0 of NIST SP 800-53 added on 27 August 2025. It asks an organization to go beyond fixing an individual flaw and to determine why the flaw existed and why it was not caught earlier. NIST added it after finding a gap while analyzing the Secure Software Development Framework, and it sits alongside the SI-2 requirement to identify, report and correct flaws. The enhancement is not in any SP 800-53B baseline, so a low, moderate or high system does not inherit it automatically. Whether it applies depends on the authorization boundary, the contract, or an agency or FedRAMP requirement that names it. Confirm its exact wording in the OSCAL catalog and ask your assessor how they expect it to be evidenced before you design a process around it.
A practical root cause record for a significant flaw is usually a short, dated document tied to the ticket that tracked the fix. It should name the flaw and affected components, the change that introduced it (for example, a library version, a configuration setting or a missing test), the detection path and why detection was late or absent, and the corrective and preventive actions with owners. Link the record to the SA-15 development process that governs how the affected component was built and tested, and to the CM change record that deployed the fix. Illustrative example: a vulnerable dependency pinned in a build template might lead to a root cause record that points to the template, a change to dependency scanning in the pipeline, and an update to the approval checklist for new base images. Decide the threshold for when a record is required, such as flaws rated high severity or flaws that reached production, and write that threshold into your SI-1 policy.
Plan for the fact that root cause analysis is a judgment-based control, which makes assessor expectations more important than tooling. Open-source scanners such as DefectDojo can keep finding history, deduplicated across tools, so the record can cite the original detection and each reimport. Asset inventory from tools such as Fleet or Wazuh helps show which systems were affected and when they were patched. Those sources supply the facts for the record, but they do not write the analysis. Ask your assessor which systems and flaw classes they will sample, what depth of analysis they accept, and whether they expect the record to feed into a plan of action and milestones when the corrective action is not finished on time.
Evidence that passes an SI-2 assessment
SP 800-53A Rev. 5 tests SI-2 by examining a small set of records: the flaw list, recent remediation actions and change records for security-relevant updates. The cards below cover each artifact an assessor will ask for and how to keep it current between assessments.
Vulnerability scan results and flaw lists
The flaw list is the starting point of the SI-2 examination: an assessor checks whether it covers the operating systems, applications and firmware that could be affected by known flaws. Keep scan output from a tool such as Greenbone Community Edition or Wazuh, with scan scope, date and asset identifiers, so each flaw can be traced to a host. Check that the list is refreshed on a schedule you can name, not only before an assessment. Confirm that scan scope matches the system boundary in your security plan.
Approved remediation timeframes
SI-2 requires security-relevant updates to be installed within a defined period after release, and that period is set by the organization. Record the timeframe per severity class in a written standard that the assessor can read and that owners have approved. Without a documented timeframe, an assessor has nothing to measure actual patch dates against. Review the standard at the frequency your policy sets, and record each review as a dated decision.
Patch test records
SI-2 requires updates to be tested for effectiveness and side effects before installation. Keep records that show which update was tested, in which non-production environment, what was checked and who approved the result. Retain failed tests too, because they show the test step operated and not only the successful path. Ask your implementation partner or platform team to confirm that test environments mirror production closely enough for the results to mean something.
Change records for security-relevant updates
The examine method for SI-2 covers installation and change control records for security-relevant software and firmware updates. Each record should link a flaw to the change request, the approval, the implementation window and the post-change verification. Tie these records to your configuration management process so the same change ticket supports both SI-2 and CM-3 evidence. Spot-check that closed changes carry a result, not only a status.
Remediation status reports
Remediation status reports show whether each flaw on the list was installed, deferred or still open, and how long it stayed open. Generate them from the ticketing or vulnerability management system, and keep dated snapshots rather than overwriting one live view. DefectDojo can import findings from many scanner formats and deduplicate them, which helps keep one authoritative status per flaw. Confirm the report shows age against your approved timeframe.
Exception and risk acceptance records
Some flaws cannot be patched within the timeframe because of vendor delays, compatibility problems or operational constraints. Each exception needs a named risk owner, a compensating action, a review date and an expiry. Assessors look for exceptions that were approved before the deadline passed, and for exceptions that quietly became permanent. Store these records beside the flaw list so the open items on the status report can be matched to a documented decision.
What meeting SI-2 costs in money and effort
Most of the first-time effort for SI-2 goes into designing the flaw remediation process and connecting the tools that will produce its evidence. The organization owns the decisions: which timeframes it defines for security-relevant updates, who approves them, and how testing before installation is performed. An implementation partner can prepare the work, but the policy choices remain with the organization.
- Process design: Defining how flaws are identified, reported, tested and installed, including the organization-defined timeframe for installing security-relevant updates.
- Tooling integration: Connecting scanners, asset inventories and ticketing or change control records so that each remediation action leaves a traceable record.
- Configuration management linkage: Writing the rules that bring flaw remediation into configuration change control, which is where many of the examine objects in SP 800-53A are found.
- Test environment preparation: Building or confirming a non-production environment where patches can be tested for effectiveness and side effects before rollout.
- Mapping to the assessor's view: Confirming which records answer each determination statement so the assessment does not start from scratch.
Ask whether the quote separates these items and states which ones the organization must staff internally.
Recurring cost for SI-2 is the continuing work of finding flaws, testing updates, installing them and keeping the records complete. Because the control is exercised every time a patch is released, this work does not end after an initial assessment. The effort is ongoing whether the organization runs it with its own staff or contracts part of it out.
- Scanning and detection: Running vulnerability scans and inventory checks at a cadence the organization sets, then triaging the results.
- Testing and installation: Evaluating each security-relevant update before deployment and recording the outcome.
- Evidence upkeep: Keeping lists of flaws, recent remediation actions and change records current, since these are the artifacts an assessor examines.
- Tool maintenance: Updating scanner feeds, upgrading self-hosted components and reviewing findings for duplicates or false positives.
- Assessor sampling: Pulling sample records for an assessor, which depends on how well the evidence is already organized.
Ask the proposal to state the expected scan frequency, who performs triage and how evidence retrieval is supported after the initial engagement.
The cost of SI-2 scales with how much the organization must patch and how many places that patching must reach. Two systems of similar purpose can carry very different effort depending on their asset count, patch volume and the number of environments that need testing. The impact level chosen for the system also changes how much is required, because higher baselines carry additional SI-2 enhancements.
- Asset count: More hosts, containers and appliances mean more inventory to reconcile and more scan results to review.
- Patch volume: The number of security-relevant updates released for the software stack drives testing and deployment workload.
- Number of environments: Each additional environment, such as development, staging, production and disaster recovery, adds testing and change record effort.
- Impact level: The moderate and high baselines select SI-2(2), which adds automated flaw remediation status tracking, so the tooling and reporting scope grows.
- Deployment model: Air-gapped networks need locally hosted vulnerability data, which adds sourcing and update work.
Illustrative example: a system with a small, stable software stack will usually need less recurring triage than one with many third-party components, even at the same impact level.
A useful quote for SI-2 work states its scope in writing before any price is discussed. Because fixed-scope engagements define deliverables and timelines up front, the proposal should name the systems, environments, tools and evidence artifacts it covers. Vague proposals make it hard to compare options or to know what the organization still has to do itself.
- Written scope: The systems, environments, impact level and SI-2 enhancements included, with any exclusions named.
- Split of one-time and recurring items: Separate line items for setup and for ongoing support, testing or retainers.
- Responsibility matrix: A clear statement of what the implementation partner prepares, what the organization decides and what the independent assessor will test.
- Assumptions: Asset counts, patch volumes and existing tooling the estimate depends on, so changes can be priced against them.
- Evidence deliverables: The records the partner will produce and how they will be organized for assessment.
Before signing, confirm that the proposal does not imply the partner will issue an assessment report, since only an independent assessor can do that.
How self-hosted open-source tools produce SI-2 evidence
Self-hosted tools produce the records that an assessor will ask to see for SI-2, but they do not make the organization compliant. The organization owns the flaw remediation decisions, the testing rules and the timeframes. A scanner that runs every night and a database full of findings show that the activity happened. They do not show that the defined period was met, that the update was tested for side effects, or that the change was approved. Those judgments still need a named owner and a written record. Before relying on any tool, confirm its coverage and licensing. DefectDojo, Greenbone Community Edition, Wazuh and Fleet each detect or track flaws in a different place: DefectDojo consolidates findings from imported scanner reports, Greenbone scans network assets and stores results in PostgreSQL, Wazuh correlates agent software inventories with a vulnerability repository, and Fleet matches installed software on enrolled hosts against sources such as the NVD and OSV. Check which asset classes each one actually sees in your environment, including firmware, network devices, containers and application libraries, because a gap in the inventory becomes a gap in the flaw list. Also confirm the license terms against your use, since the licenses differ (BSD-3-Clause, AGPL-3.0-or-later, GPL-2.0-only and MIT).
Map each tool's output to the artifacts named in SP 800-53A for SI-2: the list of flaws and vulnerabilities potentially affecting the system, the list of recent remediation actions, and the installation and change control records for security-relevant updates. Scanner exports alone rarely cover the last item, so plan for the change record to live in your ticketing or change system and reference the finding identifier. Ask your assessor which format they will accept, such as exported reports, API pulls or screenshots with timestamps, and set up retention so the records survive the assessment period. Any tool-to-control mapping you document should be checked against your own configuration, not taken from a vendor's marketing material.
Decide early who reviews the tool output and how often, because a flaw list that nobody triages does not satisfy the requirement to remediate within the defined period. The planned evidence should include the scan configuration, the scan schedules, the triage decisions and the closure records, plus the test results for updates before they reach production. Where a tool is maintained by your own team, record the version in use and the upgrade history. If you need an outside party to configure these tools, scope that work in writing, and remember that the organization still owns the control and that only the independent assessor issues the assessment conclusion.
Who owns SI-2 work, who can be outsourced and where the auditor stops
Your organization owns SI-2. The control requires you to identify and correct flaws, test updates before installation, and install security-relevant updates within a period you define. Those decisions belong to people inside your organization, because they carry the accountability an assessor will ask about. Your team sets the remediation timeframes, decides which exceptions are acceptable, signs off on risk acceptance, and decides when a flaw is too disruptive to fix immediately and must be handled another way.
- Timeframes: Set and document the defined period for security-relevant updates, and the severity bands that drive it.
- Risk acceptance: Approve deferrals in writing, with an owner, a rationale and an expiry date.
- Test approval: Decide what testing is enough before a patch reaches production, for each system class.
- Root cause review: Review the causes of recurring flaws, which the SI-2(7) enhancement in Release 5.2.0 now addresses directly.
- Policy alignment: Keep the SI-1 policy and procedures current with the timeframes actually in use.
Confirm with your assessor which parameters in SI-2 your system security plan must define, since the organization-defined value is yours to set.
An implementation partner can prepare the systems that let your team do SI-2 work consistently. DeployOpen plans, implements and integrates self-hosted open-source platforms inside your own infrastructure, so scanning, ticketing and evidence collection run where your data already lives. The partner builds the machinery. It does not decide your timeframes, accept your risks or approve your patches.
- Scanning: Configure self-hosted vulnerability detection, such as Greenbone Community Edition for network scanning and Wazuh or Fleet for endpoint software inventory, scoped to your asset list.
- Ticketing and deduplication: Connect findings to a tracker, for example through DefectDojo, which imports reports from many tool formats and deduplicates them.
- Evidence pipeline: Export the flaw lists, remediation records and change control entries that an assessor will examine.
- Test environments: Build staging or test environments where patches can be checked for effectiveness and side effects before installation.
- Documentation: Write runbooks for how each tool is operated and how its output maps to the SI-2 procedures in your plan.
Ask any partner for a written scope that names each tool, each integration and each evidence artifact it will deliver.
The independent assessor tests whether SI-2 is implemented and operating, and issues the assessment report. NIST SP 800-53A gives the assessor ten determination statements for SI-2 and examine, interview and test methods to answer them. The assessor examines your flaw lists, recent remediation records and change control records, interviews the people who run the process, and tests a sample of outcomes. DeployOpen does not perform this role, does not issue assessment reports, and cannot issue a certification or attestation.
- Examine: Reviews the list of flaws and vulnerabilities affecting the system and the records of remediation actions.
- Interview: Asks owners how timeframes are applied and how exceptions are approved.
- Test: Samples changes to confirm that updates were tested and installed as documented.
- Report: Issues findings, and the organization decides how to respond through its plan of action and milestones.
- Independence: The assessor must be independent of the team that built the evidence pipeline.
Before engaging anyone, confirm with the sponsoring authority or contract owner which assessor is recognized for your program.
Where SI-2 programs usually fall short
SI-2 is rarely missed because teams never patch. It is missed because the steps around patching are undefined, unlinked or undocumented. The cards below cover the gaps assessors most often find in flaw remediation records and the closing action for each.
No defined remediation timeframes
SI-2 requires security-relevant updates to be installed within a period the organization defines. When that period is missing, or lives only in someone's head, an assessor has no yardstick and every late patch looks like a failure. Write the timeframe per severity class in the flaw remediation procedure, name the owner of each class, and confirm the same numbers appear in the SI-1 policy and the configuration management plan. Ask the assessor which evidence they expect to see for each class.
Scan results not tied to tickets
Vulnerability scanners produce findings, but SI-2 asks for correction. If a finding never becomes a tracked work item with an owner, a due date and a closure record, the assessor cannot trace it from detection to fix. Connect scanner output to a ticketing or findings workflow, deduplicate repeated findings, and keep the link between each finding and its change record. A finding that closes without a change record is a gap, even if the system is patched.
Emergency patches installed untested
SI-2 expects updates to be tested for effectiveness and side effects before installation. Under pressure from an actively exploited flaw, teams often skip that step and then cannot show what was tested. Keep a short, pre-approved emergency path that still records a test in a staging or canary environment, the rollback plan and the approver. Review emergency changes after the fact and confirm that each one has the same evidence as a routine change.
Unsupported software without a plan
When a vendor stops issuing security updates, SI-2 still applies to the system running that software. Many programs have no register of end-of-support components and no decision on upgrade, isolation or compensating control. Maintain an inventory that records each component's support end date, assign a decision owner, and document the compensating controls and the risk acceptance for anything that cannot be upgraded. Ask the assessor how they will test components that fall outside vendor support.
Missing root cause analysis records
Release 5.2.0 added SI-2(7) for root cause analysis, so flaw handling now has an explicit expectation to explain why a flaw existed. Teams that only record the patch miss the chance to fix the development or configuration process that let it through. For significant flaws, record the cause, the contributing process gap and the change that prevents recurrence. Confirm with the assessor whether SI-2(7) applies to your baseline, since it is not in any SP 800-53B baseline.
Questions buyers ask about SI-2
How much effort does SI-2 flaw remediation take to implement?
No effort figure is supplied for SI-2, so the honest answer is that effort depends on how many systems are in scope, how many software and firmware components each one runs, and how mature the current patching process is. Most of the work is one-time design: defining the remediation timeframes, wiring a scanner or inventory tool into a ticketing workflow, and writing the test-before-install procedure. Recurring effort is the steady run of scanning, triage, testing and installation records. Ask any partner for a written scope that lists the systems, the tools and the evidence to be produced, then compare quotes against that same list.
How long does SI-2 implementation take?
The timeline depends on scope, and no duration is supplied for this control, so treat any number you hear as unverified until it is tied to a written scope. Timelines usually move with the number of environments, whether an inventory already exists, whether patch testing environments are in place, and how many approval steps change control requires. Organizations that already run a vulnerability scanner and a change process mostly need to connect them and document the results. Ask for milestones tied to deliverables, such as a flaw remediation procedure, a working scan schedule and a sample of installation records.
Can a team implement SI-2 without an implementation partner?
Yes, an internal team can implement SI-2 without a partner, provided it has the skills and time. The control asks the organization to identify flaws, test updates for side effects, install security-relevant updates within a defined period and build remediation into configuration management. Open-source tools such as DefectDojo, Greenbone Community Edition, Wazuh and Fleet can collect and track findings, but someone still has to configure them, define the timeframes and produce the records an assessor will examine. A partner is worth considering when the internal team lacks capacity or has not run a formal patch testing process before. Independent auditors, not implementers, are the ones who assess and report on the result.
What does SI-2 need from internal staff?
SI-2 needs named owners across several functions, because the control spans security, operations and change management. Security staff own the flaw identification process and the remediation timeframes. System administrators and platform engineers own patch testing and installation. Change managers approve updates and keep the installation and change control records. Someone accountable for configuration management should confirm that flaw remediation is part of the baseline. Ask a partner to map each of these roles to a named person in the procedure, since assessors will look for evidence that each step happens and is recorded.
Is SI-2(7) root cause analysis required at the moderate baseline?
No. SI-2(7) is not in any SP 800-53B baseline, including the moderate baseline, so it is not required there by default. It was added in Release 5.2.0 of SP 800-53, issued on 27 August 2025, and NIST added it after analyzing the Secure Software Development Framework. The moderate and high baselines select SI-2(2) instead. Your contract, agency or sponsoring authority can still require SI-2(7) through tailoring or an overlay, so confirm with them in writing before you scope the work.
Does FedRAMP change the SI-2 requirement?
Yes, FedRAMP sets its own requirements for SI-2 on top of the NIST baselines. The FedRAMP Rev5 baselines require SI-2 at Classes B, C and D, and add SI-2(2) and SI-2(3) at Classes C and D. FedRAMP also points providers to its Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules, which govern how vulnerabilities are detected, evaluated and reported. FedRAMP 20x also links SI-2 to two Key Security Indicators, KSI-CMT-VTD and KSI-SVC-EIS. Read the current FedRAMP rules for your class before you define timeframes, because they can be stricter than the NIST text.
Which open-source tools can produce SI-2 evidence?
Several self-hosted open-source tools can produce evidence that feeds SI-2, though none satisfies the control alone. DefectDojo (BSD-3-Clause) imports findings from more than 500 security tool report formats and deduplicates them, which helps show a tracked list of flaws. Greenbone Community Edition (AGPL-3.0-or-later) schedules scans and stores results in PostgreSQL. Wazuh (GPL-2.0-only) correlates agent software inventories with a vulnerability repository, and Fleet (MIT) matches installed software against sources such as the NVD and OSV. Confirm each tool's coverage against your own operating systems and applications before relying on it, and keep the remediation and installation records that the tools cannot create for you.
How DeployOpen prepares SI-2 systems and evidence
DeployOpen acts as an implementation partner under a fixed written scope, and it does not issue assessment results. For SI-2, that means planning and building the scanning, tracking and change control systems that produce flaw remediation evidence inside the client's own cloud accounts, data centers or air-gapped networks, then documenting how they run. Engagements are usually agreed in writing before work starts, with scope, deliverables and timelines set out in advance. The organization keeps ownership of its SI-2 control, its defined remediation timeframes and its risk decisions. DeployOpen's role is to make those decisions operable in the tooling.
In practice, a scope for an SI-2 engagement would typically name the candidate sources of flaw data (for example, a self-hosted scanner, an endpoint inventory agent and a findings aggregator), the integration points with the existing change management system, and the examine objects an assessor is likely to ask for, such as lists of flaws and recent remediation actions. Testing of patches before installation, root cause analysis under SI-2(7) where the organization adopts it, and the reports that show remediation status can also be listed as deliverables. Confirm with DeployOpen during scoping which of these items are in and out, because the written scope is the only reliable description of the work.
DeployOpen also runs security testing, which can check whether the flaw detection the client relies on actually finds known weaknesses in its own systems. Ongoing support, upgrades and continuous testing are available as retainers. Any assessment of SI-2 is then carried out by an independent auditor, assessor or certification body, which decides whether the evidence is sufficient. Ask any partner, including DeployOpen, to show in writing which parts of the SI-2 evidence it prepares and which parts the independent assessor will test.
