SI-7 Software, firmware, and information integrity

What SI-7 asks for and why assessors focus on it

An audit, a FedRAMP authorization or a customer contract has asked for SI-7, and you need to know what it demands before you scope any tooling. In plain terms, SI-7 Software, Firmware, and Information Integrity requires your organization to run integrity verification tools that detect unauthorized changes to the software, firmware and information you define, and to carry out defined actions when a change is found. The control does not name a product. It asks you to decide what counts as protected, how changes are detected and what happens next, then to show that the mechanism works. The risk it addresses is silent tampering: a modified binary that still starts, a configuration file edited to weaken logging, or a data set altered without anyone noticing. Those changes often produce no visible failure, so detection depends on comparing current state against a trusted reference.

SP 800-53B assigns SI-7 to the moderate and high security control baselines, so most systems that handle sensitive federal or contractor data will be expected to meet it. Appendix C of SP 800-53 Rev. 5 marks it as an assurance-related control, which is why assessors give it close attention: they are looking for evidence that the protection actually operates, not only that a policy describes it. Confirm the baseline and enhancement selections against the current SP 800-53B release and your authorizing body's overlay before you size the work.

Three decisions usually make SI-7 hard. First, defining what is monitored: a file integrity monitor that covers only the operating system misses application code, container images, bootloaders and the data stores that matter most. Second, deciding who gets alerted and how quickly, which needs a named owner and an agreed route for alerts that fire outside business hours. Third, proving alerts were handled. An assessor will ask for a sample of detected changes and follow each one to a ticket, a determination of whether the change was authorized, and a recorded response. A tool that generates alerts nobody closes will fail this test even if detection works perfectly. Ask your assessor early which system components they will sample, and check that your monitoring scope, alert routing and ticket records can produce that sample without manual reconstruction.

Which systems, files and teams fall under SI-7

Before any integrity tool is deployed, the organization must decide which baseline applies and which software, firmware and data sets count as monitored. Each decision below changes the number of assets, the evidence an assessor will ask for, and the people who must sign off on what is watched.

Choosing the baseline

SI-7 appears in the SP 800-53B moderate and high baselines, and FedRAMP requires it at Classes C and D. A system categorized as moderate needs SI-7 with two enhancements selected under SP 800-53B, while a high system adds more. Confirm the impact level in the system security plan first, because the enhancement count sets how much monitoring and evidence the assessor will test.

Defining monitored software and firmware

SI-7 requires the organization to define which software, firmware and information is checked. A narrow definition of operating system binaries, boot loaders and security tooling is far less work than covering every application package. Write the list down with the owner of each item, because an assessor will compare the definition against what the integrity tool actually watches.

Endpoints and servers in scope

Every server, workstation and appliance that hosts a defined component needs an agent or equivalent check, along with a baseline of checksums and attributes. Inventory drift is the common failure point: a host that is missing from the monitoring console produces no evidence. Ask the infrastructure team for an authoritative asset list and reconcile it against the monitoring console before the assessment window opens.

Containers and images

Container images are software artifacts that change at build time rather than on a running host. Decide whether SI-7 covers the image registry, the running container filesystem, or both. Immutable images with signed digests make verification simpler, while mutable runtime layers need file integrity checks inside the workload. Document the choice, since it determines where alerts originate.

Build pipelines and code signing

Build servers, artifact stores and signing keys can alter what ships without touching production. Deciding whether the pipeline is in scope affects who must review changes to build scripts and how signed artifacts are verified before deployment. Assign an owner for the pipeline's configuration and for the signing process, and confirm that changes to either generate audit records that an assessor can review.

Third-party and open-source components

Vendor binaries and open-source dependencies are part of the system even when another party builds them. The organization must decide how it verifies their integrity, and whether it keeps a software bill of materials that identifies component versions. Ask suppliers for signed release artifacts and checksums, and record who in procurement or engineering owns the answer.

Owners and approvers for each set

Each monitored set needs a named owner who approves baseline changes and reviews alerts, and a separate reviewer who confirms that authorized updates were expected. Without this split, planned patching and malicious changes look identical in the alert queue. Map owners to the monitored sets in writing, and check that the on-call rota covers integrity alerts outside business hours.

How an assessor tests SI-7 and what they ask to see

This table maps the assessment approach for SI-7 from SP 800-53A, showing what an assessor examines, asks and tests, and the evidence that supports each step. Read each row as a question the assessor will put to your team, with the artifact that answers it. The main takeaway is that a tool that is installed is not enough: the assessor expects a defined monitored set, a documented baseline, a named responder and a test that proves changes are detected.

Assessment step	What the assessor does	Evidence that passes
Determination statements	Confirms the six SP 800-53A determination statements for SI-7 are each met, including that the monitored software, firmware and information is defined and that unauthorized changes are detected.	A written mapping from each determination statement to the system component, configuration and owner that satisfies it.
Examine: integrity verification tools	Reviews the integrity verification tool, its version, its scope and its documentation to confirm it covers the defined items.	Tool inventory with version, monitored paths or assets, and the documented purpose of each monitor.
Examine: system design documentation	Checks that the design shows where integrity checks run, what they protect and how results reach responders.	Architecture diagram showing agents, manager, alert destinations and the systems they cover.
Examine: configuration settings	Compares the live tool configuration with the documented settings, including scan schedule, real-time monitoring and excluded paths.	Exported configuration files, change history for the configuration, and a record of the approved baseline.
Examine: audit records	Samples integrity alerts and related logs to see whether events were generated, stored and tied to a user or process.	Alert records with timestamps, affected file, change type and actor, retained for the period the organization defines.
Interview: alert response	Asks who receives integrity alerts, who triages them, how fast they respond and what happens outside business hours.	Named roles, on-call or escalation procedure, and tickets showing alerts were acted on.
Interview: changes and exceptions	Asks how authorized changes are separated from unauthorized ones and how baselines are updated after approved change.	Change records linked to baseline updates, with approver names and dates.
Test: controlled change	Makes a controlled, approved test change to a monitored file, then confirms the tool raises an alert with the expected detail.	Test plan, the change made, the resulting alert and the ticket closing the test.
Common finding: undefined monitored set	The assessor cannot tell which software, firmware or information is covered, so the determination cannot be met.	A written list of monitored items tied to the system boundary and the risk decision behind it.
Common finding: alerts nobody reviews	Integrity alerts exist in the tool but no one triages them, or review is informal and undocumented.	Defined review cadence, assigned owner and records of reviewed and closed alerts.
Common finding: no proof of baseline	The team cannot show the approved checksum or attribute baseline, or the baseline was rebuilt without review.	Baseline export with hashes or attributes, its creation date and an approval record.

What changed in SI-7(12) under Release 5.2.0

Release 5.2.0 of SP 800-53, issued on 27 August 2025, widened SI-7(12) Integrity Verification so it applies to all organization-defined software, not only organization-defined user software. Before this release, the enhancement reached only the user-facing software an organization chose to name. Under the revised wording, the software parameter you define can cover operating system components, vendor-supplied packages, build artifacts and firmware, provided your definition includes them. The control itself still asks for integrity verification tools that detect unauthorized changes, and the enhancement adds the requirement to verify that integrity for the software you name. SI-7(12) appears in no SP 800-53B baseline, so it applies to a system only when the organization selects it or an agreement, such as a contract or a sponsor's control set, adds it. Confirm that with your authorizing official or contracting team before you plan work around it. Do not assume that a moderate or high baseline implementation of SI-7 has covered the enhancement. The practical first step is to open your SI-7 organization-defined parameter, compare its current value with the revised enhancement text and the NIST summary of changes, and record the decision in your system security and privacy plan.

A wider parameter changes what you must be able to show. If the software you define now includes container images, CI/CD build outputs, third-party binaries and firmware images, you need a way to verify each of them against a known reference, such as a signed hash, a signed build attestation or a recorded baseline from a trusted build. Open-source file integrity monitoring, such as Wazuh, can alert on changes to monitored paths after a baseline is recorded, but it does not by itself prove where a package came from. Decide which artifact classes are in scope, which reference values you will trust and who approves changes to those references. Expect to document this in the SI-7 implementation statement and in the configuration settings an assessor will examine. Release 5.2.0 also revised or updated several related controls, including AU-2, AU-3, CA-7, IR-4, IR-6, IR-8, SA-15, SI-2 and SI-7, along with the -1 policy controls. An assessor reading the change log will see SI-7(12) alongside changes to flaw remediation and to developer and acquisition requirements, so the record of your decision should cross-reference those items. Ask your assessor which release your assessment is written against, and confirm whether your sponsor requires you to adopt the 5.2.0 wording before your next assessment cycle.

How to implement SI-7 step by step

This sequence takes SI-7 from undefined scope to a tested integrity monitoring capability, with each step producing a record an assessor can examine against the SP 800-53A procedures for the control.

Define monitored software, firmware and information
The organization, through its system owner and security team, lists the software packages, firmware images, configuration files and data sets that SI-7 must cover, and records the organization-defined parameters that set which items count and what actions follow a detected change. The output is a signed integrity scope statement that names each monitored asset class, its owner and the defined response actions. The step is done when every item in the system boundary is either in scope or excluded with a documented reason that the assessor can review.
Select the integrity method and record a verified baseline
The security engineering team chooses the integrity verification tool, such as a file integrity monitor, and records a baseline of checksums and file attributes for the monitored locations while the systems are in a known good state. The baseline is captured under change control and stored where it cannot be altered by the monitored hosts. The output is a baseline report with hashes, attributes, capture date, approver and the tool configuration, which an assessor can compare against the examine objects for integrity verification tools and system configuration settings.
Configure scheduled and real-time checks with alert routing
Engineers configure the monitoring agent or manager to run checks on a defined schedule or in real time for each monitored path, and to send alerts when a user or process creates, modifies or deletes a monitored file. Alerts are routed to a named owner and a shared queue so that no single mailbox is the only recipient. The output is a configuration export and an alert routing matrix. The step closes when a test alert reaches the named owner and the configuration files are under version control.
Define the response and review workflow with tickets
The incident response and operations leads write a procedure that states how each integrity alert is triaged, who decides whether a change is authorized, when an incident is opened, and how the result is closed. Every alert creates a ticket that links to the change request or to the incident record. The output is the written procedure plus a sample of closed tickets showing triage, decision and closure. This step is complete when the assessor can trace a detected change from the alert through to an authorized change or a containment action.
Extend integrity checks to supply chain artifacts and firmware
Where the defined scope includes software supply chain artifacts or firmware, the team generates a software bill of materials for each deployed system, for example with Trivy, and loads the inventory into a component analysis service such as OWASP Dependency-Track to detect modified or unexpected components. Firmware images are checked against the vendor or internal reference values that the organization has verified. The output is the SBOM set, the component analysis reports and a firmware verification record. Teams should confirm with their tooling vendors which formats and integrations their versions support before committing the design.
Run a controlled change test and record the result
The team makes a planned, authorized change to one monitored file in a non-production environment, then deliberately makes an unauthorized change to a test file, and confirms that the monitor detects both, raises the expected alert, routes it to the named owner and creates a ticket. The test is repeated after any change to the tool configuration. The output is a dated test record with inputs, observed alerts, ticket references and any defects found, along with the remediation for each defect. This record gives the assessor direct evidence that the control operates as defined.

Evidence that passes an SI-7 assessment

An assessor testing SI-7 under SP 800-53A will ask for proof that the defined integrity scope is monitored, that changes are detected, and that detected changes are either authorized or handled as incidents. The artifacts below connect those three checks, and each one needs a refresh rhythm so it still reflects the system when the assessment happens.

Defined monitored set and rationale

This is the written list of software, firmware and information the organization has chosen to protect under SI-7, such as operating system binaries, configuration files, container images and security tool components. Assessors compare it against the system design documentation, so every entry should trace to a component in the boundary. Record why anything excluded is outside the defined scope. Review the set after each significant change and at least once per assessment cycle, and keep dated versions so the set in force during the audit period can be shown.

Integrity tool configuration and baseline records

Export the configuration of the file integrity tool, including monitored paths, the schedule or real-time setting, hash and attribute types, and alert rules. Pair it with the baseline snapshot of checksums and attributes taken from a known-good state. An assessor will check that the configuration matches the monitored set and that the baseline was captured before the monitoring began. Store configuration in version control so every change to scope leaves a commit history. Refresh the baseline after authorized updates, and keep the prior baseline.

Sample alert records with change details

Alert records show that the tool detects changes in practice. Each record should state which file or directory changed, whether a user or process made the change, the time, and the attributes that differed from the baseline. Include both a test-generated alert and, where one exists, a real one. Export a dated sample each quarter, covering different monitored asset types, so the evidence reflects the system over time rather than a single demonstration. Confirm the alert retention period in your own environment before promising an assessor older samples.

Response tickets with closure notes

Every alert that is not matched to an approved change should open a ticket that records triage, the investigation outcome, containment steps and the reviewer who closed it. Closure notes must say whether the change was malicious, erroneous or unauthorized, and what restored the monitored item to its approved state. Assessors sample these tickets to test that defined response actions occur. Review open and aged tickets on a recurring cadence, and export a sample of closed tickets with their notes for each assessment period.

Change records matching authorized alerts

Authorized changes, such as patches or configuration updates, will trigger alerts. The evidence that matters is the link between each alert and an approved change request, showing that the change was planned, reviewed and deployed through the change process. Unmatched alerts are the exceptions an assessor will examine. Keep the change ID in the alert or ticket, and run a reconciliation each month to list alerts without a matching change. This shows that authorized activity was not treated as an incident and that unauthorized activity was not silently accepted.

Test record of a controlled change

A controlled test proves the tool detects what it is supposed to detect. Make a planned, documented change to a monitored file in a non-production environment, record the time and the actor, and confirm that an alert fired with the expected details and that the response ticket was opened. Document the result, including any gaps. Repeat the test after tool upgrades, scope changes and major platform updates, and schedule it at a fixed interval so the evidence stays current between audits.

What meeting SI-7 costs in money and effort

This table breaks the cost of meeting SI-7 into components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so no figures appear here; use the drivers and quote questions to compare offers. Read it as a checklist for scoping, not as a budget.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for
Tooling and licenses	Software vendors or none for open source	Recurring if commercial; open-source tools carry no license fee	Number of monitored hosts and paths. Ask whether the quote includes support subscriptions and whether any component is commercial-only.
Engineering to configure and baseline	Implementation partner or internal platform team	One-time, with later re-baselining after major changes	Number of systems, depth of monitored paths and how many software and firmware components are in scope. Ask for the baseline method and which systems are excluded.
Alert review and response	Internal security operations staff	Recurring	Change volume, how often changes are authorized through change control and how alerts are routed. Ask how false positives from approved updates are suppressed.
Evidence upkeep	Internal compliance or platform staff	Recurring	Frequency of assessments and number of systems that need retained integrity reports, configuration settings and audit records for SI-7.
External testing or review	Independent assessor or testing firm	Recurring when an annual assessment applies	Whether FedRAMP's annual independent assessment applies at Class C or D, and how many systems are sampled. Ask what the assessor will test and what the report covers.
Auditor sampling	Independent auditor or assessor	Recurring with each assessment cycle	Sample size, number of change events and number of systems selected. Ask the auditor for its sampling approach before work starts.
Open-source staffing	Internal staff or implementation partner	Recurring for operations, one-time for setup	Open-source tools such as Wazuh remove license spend but still require people to operate, tune and retain evidence from them. Ask for a staffing estimate in the written scope.

Open-source tools that produce SI-7 evidence

SI-7 asks for a way to detect unauthorized change and a record that the check runs. The four tools below cover different parts of that job: watching files on hosts, verifying backup data, tracking the software components inside your systems, and inventorying what is installed. None of them makes an organization compliant on its own, and each needs a defined scope, configuration and review process before its output counts as evidence.

Wazuh file integrity monitoring

Wazuh, licensed under GPL-2.0-only, records a baseline of checksums and file attributes for the directories you select, then raises an alert when a user or process creates, modifies or deletes a monitored file. Checks can run on a schedule or in real time, and alerts record how and when a file changed and who made the change. For SI-7, the evidence is the monitored-path list, the baseline, and a sample of alerts with the disposition your team recorded. Confirm that the monitored paths match the defined software, firmware and information in your system, and that alerts reach people who act on them.

Bareos verify jobs

Bareos, licensed under AGPL-3.0-only, is a backup system whose Verify jobs compare files on a target against attributes previously stored in its catalog. A mismatch shows that a file changed after the backup was taken, which is useful for detecting tampering with recovered or stored data. Keep in mind that Verify jobs only check against the last cataloged state, so a change made before the backup was taken will not appear. Confirm the verify schedule, the job logs you retain, and how mismatches are escalated. AGPL-3.0 obligations apply if you modify and distribute the software, so have counsel review your use.

OWASP Dependency-Track component monitoring

Dependency-Track, licensed under Apache-2.0, consumes and produces CycloneDX SBOMs and VEX, and flags components with known vulnerabilities, outdated versions, modified components and license risk. For SI-7, it supports integrity of software by showing which components a system actually uses and whether any have been altered from their upstream form. Its output, including the component inventory, findings and the analysis decisions recorded against them, is a useful evidence trail. Confirm that the SBOMs fed into it are generated from your real build and deployment artifacts, and that someone reviews the modified-component findings.

Trivy software bill of materials

Trivy, licensed under Apache-2.0, identifies the OS packages and software dependencies in a target and can export them as a software bill of materials. It can also scan an existing SBOM, which lets you check a component list produced elsewhere. For SI-7, the SBOM and scan output show the software inventory that your integrity checks are meant to protect, and give you a baseline to compare against later. Confirm which targets you scan, how often, and whether the SBOM format you export matches what your downstream tools expect. Trivy is a scanner, so it does not replace file integrity monitoring or signature verification.

Who owns SI-7 and what an outside partner can take on

Your organization owns SI-7. NIST SP 800-53 places the control with the organization and the system, so decisions about what is protected and what happens after a change cannot be delegated to a vendor. Your team defines the software, firmware and information sets that integrity checking covers, approves the baseline that monitoring compares against, and decides how alerts are triaged and who accepts residual risk.

Defined sets: Decide which binaries, configuration files, firmware images and data stores fall under SI-7, and record the organization-defined parameters that set those boundaries.
Baseline approval: Sign off on the known-good state of each monitored asset before it goes live, and on every later change to that baseline.
Alert response: Staff the triage queue, define who investigates an unauthorized change and what containment steps are required.
Risk acceptance: Document any deviation, exception or unmonitored component in your risk register with a named accountable owner.
Policy alignment: Keep the SI-1 policy and the integrity procedures current with how the tools actually run.

Before engaging anyone, confirm internally who holds each of these decisions and where they are written down.

Questions buyers ask before bringing in help for SI-7

How much effort does SI-7 take, and what drives it?

SI-7 effort depends mostly on how many software, firmware and information components sit in scope and how many of them already have integrity tooling. The control itself asks for verification tools that detect unauthorized changes and defined actions when changes are found, so the work splits into selecting and configuring those tools, deciding what they watch, setting alert and response rules, and collecting evidence. Costs rise with the number of hosts and file paths monitored, the number of distinct platforms, and whether the organization must also run SI-7(12) across all defined software. Ask any partner for a written breakdown by component group, not a single number, and ask which items are one-time setup and which recur, such as tuning, baseline refreshes and evidence collection each assessment cycle.

Can an in-house team implement SI-7 without outside help?

Yes, an in-house team can implement SI-7 if it has engineers who can deploy and tune integrity monitoring, a documented owner for the control, and time to produce evidence the assessor can examine. Outside help usually makes sense when the team lacks experience with baseline design, when the system spans several platforms, or when an assessment deadline is fixed. Whichever path you choose, the organization keeps ownership of the control. DeployOpen prepares systems, configurations and evidence under a written scope, but it does not issue assessment reports, and an independent assessor still tests the control. Check whether your internal team can name the components in scope and explain how alerts are reviewed before deciding.

How long does SI-7 implementation usually take?

The timeline is set by scope, starting condition and approval steps, not by the control text, and no duration is fixed by NIST for SP 800-53 implementation. NIST leaves implementation timelines to OMB Circular A-130 for federal agencies, so any duration you hear should be treated as a proposal, not a standard. The main drivers are how many systems need integrity baselines, whether change records and configuration documentation already exist, how many approvals a change to monitored settings needs, and how long the assessment window is. Ask for a milestone plan with dates tied to deliverables, and confirm which milestones depend on your change advisory board or on access to your environment.

What does the work need from our organization?

The work needs named owners, reliable access and clean change records. Typically, you need an accountable owner for SI-7 who can approve which files and directories are monitored, a system administrator who can grant access to hosts and cloud accounts, and a security contact who will receive and triage alerts. Change records matter because integrity monitoring flags modifications, so approved patches and configuration changes must be documented to separate expected activity from unauthorized change. Ask the partner to list every role it needs by name or title before work starts, along with the access level for each, and the change records it will reconcile against.

Can a partner issue the SI-7 assessment or certify compliance?

No. A partner can prepare systems, configurations, documentation and evidence for SI-7, but only an independent auditor, assessor or certification body can test the control and issue a report or certificate. DeployOpen follows this division: it implements and documents controls inside your environment and prepares evidence, while the independent assessor examines the integrity tools, design documentation, configuration settings and audit records against the SP 800-53A procedures. Before you sign, confirm the assessor's qualifications and independence with your governing body, and make sure the statement of work says the partner will not sign or attest to compliance.

How does SI-7 differ when FedRAMP applies?

Under FedRAMP's Rev5 baselines, SI-7 is required at Classes C and D, with additional enhancements at each class, so the scope is larger than the NIST moderate or high baseline alone. FedRAMP also requires SI-7 and SI-7(1) at Classes C and D to be included in an independent FedRAMP assessment at least once a year, and FedRAMP 20x maps SI-7 or its enhancements to several Key Security Indicators. Under the FedRAMP Consolidated Rules for 2026, you should confirm the exact enhancement count for your class in the machine-readable rules, since the requirement details matter for scoping. Ask your partner to show how each enhancement maps to a specific tool, configuration and evidence artifact.

Does SI-7(12) change the work for existing environments?

Yes, it can. Release 5.2.0 of SP 800-53, issued on 27 August 2025, revised SI-7(12) Integrity Verification so it applies to all organization-defined software rather than only user software. That widens the set of components that must be covered if you select this enhancement, which matters most in environments with large operating system and third-party software footprints. SI-7(12) is not in any SP 800-53B baseline, so it applies only when your organization or your authorizing body selects it. Confirm with your authorizing official whether the enhancement is in your selected set before scoping the monitoring work.

How DeployOpen scopes and prepares SI-7 evidence

DeployOpen works on SI-7 as an implementation partner: we prepare the integrity tooling, configuration and evidence inside your own infrastructure, and your organization owns the control. Independent assessors, not DeployOpen, test the control and issue any report or certificate.

How we scope

We confirm which systems, software, firmware and information stores fall inside the SI-7 boundary and which baseline applies.
The written scope names the integrity tools, monitored paths and defined actions for each in-scope component before work starts.
Engagements are fixed-scope, so deliverables and timelines for SI-7 work are agreed in writing before any build begins.

How we build

We deploy and configure file integrity monitoring, such as Wazuh, against baselines of checksums and attributes you approve.
We set up verification jobs and alert routing, and test that deliberate unauthorized changes produce the expected alerts.
We document SBOM generation with tools such as Trivy and Dependency-Track to support the SI-7(12) software scope.

How we hand over

We deliver configuration records, monitored-object inventories, alert test results and runbooks that map each tool to SA-type evidence.
Evidence is packaged for the assessor's examine methods, covering integrity tool configuration, design documentation and audit records.
Your staff receive documented procedures so they can operate, review and respond to integrity alerts after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the initial engagement.
Retainers can cover tool upgrades, baseline updates after approved changes and review of integrity alerts over time.
Ask any provider to confirm in writing which SI-7 tasks they perform and which remain with your team or an independent assessor.