SI-7 is the integrity control. It asks you to use integrity verification tools to detect unauthorized changes to software, firmware and information you define, and to take defined actions when a change is detected. NIST 800-53 binds US federal systems and, by contract, some others. For other companies it is a reference for a question that has grown more pointed in recent years: how do you know the code you run is the code you built?
What it asks
There are two parts:
- Employ integrity verification tools to detect unauthorized changes to the software, firmware and information the organization lists.
- Take the organization defined actions when such changes are detected.
Scope and response are yours to define, so an auditor will look for a list of what is covered and a record of what you do on a hit.
What it means in practice
NIST's guidance says unauthorized changes can come from errors or malicious activity. Software includes operating systems with key components such as kernels and drivers, middleware and applications. Firmware interfaces include UEFI and BIOS. Information includes personally identifiable information and metadata holding security and privacy attributes.
The guidance names integrity checking mechanisms: parity checks, cyclical redundancy checks, cryptographic hashes and associated tools, which can automatically monitor the integrity of systems and hosted applications.
For a typical software company, the practical reading has three layers:
- Build and release. Artifacts have recorded digests, ideally signed, and deploys verify them.
- Runtime. File integrity monitoring on hosts, image digest pinning for containers, and drift detection on configuration.
- Data. Hashes or signatures on records and evidence where tampering matters, plus audit trails on sensitive metadata.
Dependencies matter here too. A package that changes content under the same version, or a lockfile that quietly drifts, is an integrity event. An SBOM gives you a baseline to compare against, because it records what was supposed to be in the build.
The control also asks what you do next. The response might be an alert, a blocked deploy, an automatic rollback or an incident. Whichever you pick, it should be written down and tested.
Evidence to collect
- The list of software, firmware and information covered by integrity verification.
- Tool configuration: file integrity monitoring rules, signature verification in the deploy pipeline, image digest policies.
- Baselines such as SBOMs, lockfiles and approved image digests.
- Alerts or blocked events showing the tool detects changes.
- The defined response procedure and an example incident or test.
- Change tickets that explain legitimate changes, so authorized and unauthorized can be told apart.
Common gaps
- Integrity checks only at build time, with nothing at deploy or runtime.
- Containers pulled by mutable tag instead of digest.
- File integrity monitoring on, but so noisy that alerts are ignored.
- No mapping from change tickets to detected changes, so every change looks suspicious.
- Firmware ignored entirely.
- A response that exists on paper and has never been exercised.
How to implement it
Pick the highest value targets first: the production deploy pipeline, the base images and the systems holding your most sensitive data.
Sign or hash build outputs, store the digests, and have the deploy step verify them. Pin images by digest. Generate an SBOM for each release and keep it with the artifact.
Add file integrity monitoring on critical hosts with a tight rule set, and connect it to change management so approved changes are suppressed and unapproved ones alert.
Write the response in a runbook. Who is paged, what is isolated, how do you verify the last good state. Run the exercise once.
The enhancements cover integrity checks (SI-7.1), automated notifications of violations (SI-7.2), centrally managed tools (SI-7.3), tamper evident packaging (SI-7.4), automated response (SI-7.5), cryptographic protection (SI-7.6), integration of detection and response (SI-7.7) and auditing capability for significant events (SI-7.8). Automated notification and cryptographic protection give the most value early.
Click through it at your own pace, or open it full screen.
Quick check
What does SI-7 treat as information?
The guidance includes personally identifiable information and metadata that carries security and privacy attributes.
Is a hash enough to meet SI-7?
A hash is one integrity mechanism the guidance names. You still need a list of what is covered, automated checking, and a defined response when a change is detected.
