Software, Firmware, and Information Integrity | Integrity Checks

To meet the NIST SP 800-53 Rev 5 SI-7(1) integrity checks requirement, you must define what software, firmware, and information matters for your system, then perform integrity checks at startup, at specific transition or security-relevant events, or on a defined schedule, and keep proof those checks ran and were reviewed. Your goal is fast detection of tampering and unauthorized change. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Define scope first: “organization-defined” is the control; auditors will look for your explicit decisions. (NIST Special Publication 800-53 Revision 5)
• Automate integrity checks and tie them to boot, deployments, and incident-relevant events; manual checks rarely scale. (NIST Special Publication 800-53 Revision 5)
• Retain evidence that checks executed, what they validated, what failed, and how exceptions were handled. (NIST Special Publication 800-53 Revision 5)

Integrity checks sound simple until you try to operationalize “organization-defined” across cloud services, endpoints, images, containers, CI/CD pipelines, and managed third parties. SI-7(1) forces you to pick: what must be protected from unauthorized modification, when you will check it, and how you will detect and respond to integrity failures. (NIST Special Publication 800-53 Revision 5)

For FedRAMP and NIST-aligned programs, assessors typically expect integrity checks to be engineered into the platform, not bolted on as a quarterly script. In practice, teams pass this requirement when they can show: (1) baselines (hashes, signatures, golden images, approved configurations), (2) automated verification at defined moments (boot, deploy, update, privileged access, security alerts), and (3) evidence and response workflows that connect failures to tickets, triage, and remediation. (NIST Special Publication 800-53 Revision 5)

This page gives requirement-level guidance you can implement quickly: who owns what, what to configure, what to log, what to store for audit, and how to avoid the common mistake of only checking “files on servers” while ignoring firmware, images, and critical data stores. (NIST Special Publication 800-53 Revision 5)

Regulatory text

Requirement (verbatim): “Perform an integrity check of organization-defined software, firmware, and information at startup, at organization-defined transitional states or security-relevant events, or at an organization-defined frequency.” (NIST Special Publication 800-53 Revision 5)

What an operator must do:

1. Define which software, firmware, and information require integrity checking in your environment (“organization-defined”). (NIST Special Publication 800-53 Revision 5)
2. Define when integrity checks run: at startup, at transitions/security-relevant events, and/or on a schedule. (NIST Special Publication 800-53 Revision 5)
3. Implement technical mechanisms that perform checks, record results, and trigger response when checks fail. (NIST Special Publication 800-53 Revision 5)
4. Retain evidence that checks are configured as stated and operate as designed. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

You are proving that your system can detect unauthorized changes to code, device firmware, and critical data. That includes changes introduced by malware, insider actions, misconfigurations, compromised CI/CD pipelines, or third-party update channels. The control does not dictate a single tool; it dictates outcomes: defined scope, defined timing, repeatable checks, and auditable records. (NIST Special Publication 800-53 Revision 5)

Who it applies to (entity and operational context)

This requirement applies to:

• Cloud Service Providers and federal agencies operating systems under a NIST SP 800-53 / FedRAMP-aligned control baseline. (NIST Special Publication 800-53 Revision 5)
• Systems handling moderate-impact data where unauthorized modification creates confidentiality, integrity, or availability risk. (NIST Special Publication 800-53 Revision 5)
• Operational contexts where integrity can drift quickly, such as autoscaling fleets, container orchestration, serverless deployments, rapid patch cycles, and managed infrastructure controlled partly by third parties. (NIST Special Publication 800-53 Revision 5)

Ownership typically spans:

• Security engineering (design/standards), platform/SRE (implementation), endpoint/server teams (coverage), IAM (event triggers), and GRC (definition + evidence). (NIST Special Publication 800-53 Revision 5)

What you actually need to do (step-by-step)

Step 1: Define “what must be checked” (your integrity scope register)

Create an “Integrity Check Scope” list that names the items you will verify. Keep it short but defensible. Examples to consider:

• Software: OS binaries, critical services/agents, runtime packages, container images, IaC modules, CI/CD runners, security tooling. (NIST Special Publication 800-53 Revision 5)
• Firmware: BIOS/UEFI, BMC/iDRAC/iLO, network device firmware, storage controller firmware, hypervisor firmware where applicable. (NIST Special Publication 800-53 Revision 5)
• Information: security configurations, policy-as-code, IAM policy files, critical application configs, allowlists/denylists, key security datasets (for example, authorization tables) where tampering would matter. (NIST Special Publication 800-53 Revision 5)

Decision point: If an item can change frequently by design (autoscaling, immutable deployments), define integrity at the image/signature level rather than trying to hash every runtime file. (NIST Special Publication 800-53 Revision 5)

Step 2: Define “when checks run” (your event and frequency model)

Document the specific triggers you will use. Auditors want to see that “startup,” “transitional states,” and “security-relevant events” are concretely defined for your system. (NIST Special Publication 800-53 Revision 5)

A practical model:

• Startup: at host boot, VM initialization, container start, or node join to cluster. (NIST Special Publication 800-53 Revision 5)
• Transitional states: post-deployment, post-patch, image promotion to production, configuration change approval, or scaling events. (NIST Special Publication 800-53 Revision 5)
• Security-relevant events: privileged role assignment, unexpected binary change alerts, EDR detections, integrity tool tamper alerts, failed signature verification, or suspicious supply-chain indicators. (NIST Special Publication 800-53 Revision 5)
• Defined frequency: choose a schedule that fits operational reality for anything not covered by event triggers (for example, periodic scans of repositories or firmware inventory validation). (NIST Special Publication 800-53 Revision 5)

Step 3: Implement integrity mechanisms that match the asset type

Use mechanisms that are credible for the technology:

For software on servers/endpoints

• File integrity monitoring (FIM) on defined directories and binaries.
• Package signing verification and repository trust enforcement.
• Application allowlisting where feasible.
  Focus on “detect unauthorized change,” not “scan everything.” (NIST Special Publication 800-53 Revision 5)

For containers and CI/CD

• Signed container images and signature verification at deploy/admission time.
• Hash pinning or digest-based deploys.
• CI/CD provenance checks and controls that prevent unsigned artifacts from promotion. (NIST Special Publication 800-53 Revision 5)

For firmware and hardware-adjacent components

• Maintain a firmware inventory with approved versions.
• Validate firmware versions against approved baselines after maintenance windows, device replacement, or suspected compromise.
• If your environment supports secure boot/TPM attestation, define how attestation failures are handled and who gets paged. (NIST Special Publication 800-53 Revision 5)

For “information” (critical configs and data)

• Treat integrity as “only approved changes occur.” Implement:
  • Version control for configuration artifacts.
  • Immutable logging for changes and approvals.
  • Checksums/signatures for sensitive configuration bundles where practical. (NIST Special Publication 800-53 Revision 5)

Step 4: Connect integrity failures to response

Integrity checks without response are exam bait. Define:

• Severity classification for integrity failures (for example: production system binary changed outside change window).
• Required actions: isolate host, block deployment, revert to golden image, rotate credentials, initiate incident workflow.
• Escalation path and time expectations (don’t add numeric SLAs unless your program already has them). (NIST Special Publication 800-53 Revision 5)

Step 5: Make it auditable (logging, review, exceptions)

Implement:

• Central logging of integrity events (pass/fail, asset, timestamp, policy version).
• Alerting rules for failures and tamper attempts.
• A recurring review cadence for integrity tooling health and coverage drift (new repos, new clusters, new device types). (NIST Special Publication 800-53 Revision 5)

Operational note: If you use third parties for managed infrastructure, require integrity evidence (or equivalent attestations) in contracts and ongoing oversight, and document boundaries clearly. “They manage it” does not remove your requirement to ensure integrity checks occur for your defined scope. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Keep artifacts mapped to “scope, triggers, execution, and response”:

1. Integrity Check Scope Register (what is in scope, owners, rationale). (NIST Special Publication 800-53 Revision 5)
2. Baseline definitions: approved images, hashes, signatures, firmware versions, configuration baselines. (NIST Special Publication 800-53 Revision 5)
3. Configuration evidence:
   • Tool configuration screenshots/exports (FIM rules, admission controller policies, secure boot settings where applicable).
   • CI/CD policy configs showing signature enforcement. (NIST Special Publication 800-53 Revision 5)
4. Execution logs: startup checks, deploy-time validations, scheduled scans, and exceptions. (NIST Special Publication 800-53 Revision 5)
5. Alert and ticket evidence: sample alerts, incident tickets, change records tied to integrity failures and remediation. (NIST Special Publication 800-53 Revision 5)
6. Exception documentation: risk acceptance, compensating controls, expiry/review dates, and re-validation steps. (NIST Special Publication 800-53 Revision 5)

If you want to streamline evidence collection, Daydream can act as the system of record for the scope register, evidence requests to platform teams and third parties, and audit-ready traceability from requirement to artifacts.

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “What exactly is ‘organization-defined’ for software, firmware, and information in your system?” (NIST Special Publication 800-53 Revision 5)
• “Show me integrity checks running at startup or deployment. Where are the logs?” (NIST Special Publication 800-53 Revision 5)
• “What are your transitional states and security-relevant events? Who defined them and when were they last reviewed?” (NIST Special Publication 800-53 Revision 5)
• “How do you prevent unsigned/unapproved artifacts from reaching production?” (NIST Special Publication 800-53 Revision 5)
• “What happens when an integrity check fails? Show a closed ticket.” (NIST Special Publication 800-53 Revision 5)
• “How do you cover firmware, not just OS files?” (NIST Special Publication 800-53 Revision 5)

Hangup: teams often have strong CI/CD integrity controls but weak runtime/firmware coverage, or they have FIM on servers but no integrity gate on container deploys.

Frequent implementation mistakes and how to avoid them

1. Mistake: Defining scope as “all systems” with no specifics.
   Fix: publish a scope register with concrete categories and owners; include what’s excluded and why. (NIST Special Publication 800-53 Revision 5)

2. Mistake: Only scheduled scans, no event-based checks.
   Fix: add checks at boot and deployment transitions; make them blocking for critical workloads where feasible. (NIST Special Publication 800-53 Revision 5)

3. Mistake: Integrity checks run, but nobody reviews failures.
   Fix: route failures into your incident/ticketing workflow with defined triage ownership. (NIST Special Publication 800-53 Revision 5)

4. Mistake: Firmware ignored because “cloud.”
   Fix: document your shared responsibility model and verify what firmware layers you control; for what you don’t control, capture third-party assurances and boundary statements. (NIST Special Publication 800-53 Revision 5)

5. Mistake: Too much noise from FIM.
   Fix: tune to high-value paths and use change windows/approved change correlation to suppress expected modifications without suppressing real anomalies. (NIST Special Publication 800-53 Revision 5)

Risk implications (why assessors care)

Integrity failures are a common precursor to broader compromise: unauthorized binaries, tampered images, poisoned update paths, and configuration manipulation can all bypass preventive controls. SI-7(1) forces you to shorten the time between tampering and detection and to create proof that detection works under real operational conditions. (NIST Special Publication 800-53 Revision 5)

A practical 30/60/90-day execution plan

Days 1–30: Define and instrument the basics

• Publish the integrity scope register for software, firmware, and information. (NIST Special Publication 800-53 Revision 5)
• Choose triggers: boot/startup plus at least one major transition (deploy/promotion) and one security-relevant event source (for example, privileged access or EDR alert). (NIST Special Publication 800-53 Revision 5)
• Stand up centralized logging for integrity results and failures; verify retention aligns with your program needs. (NIST Special Publication 800-53 Revision 5)

Days 31–60: Make checks enforceable and auditable

• Add deploy-time integrity gates (signed artifacts, digest pinning, policy checks) for production paths. (NIST Special Publication 800-53 Revision 5)
• Tune FIM rules to reduce noise and document rationale for monitored paths. (NIST Special Publication 800-53 Revision 5)
• Create an integrity failure runbook and connect alerts to ticketing/incident workflows. (NIST Special Publication 800-53 Revision 5)

Days 61–90: Extend coverage and prove operations

• Expand to firmware inventory/baselines where you have control; document third-party boundaries where you don’t. (NIST Special Publication 800-53 Revision 5)
• Run a tabletop or operational test: simulate an unauthorized change and capture end-to-end evidence (alert → ticket → remediation → closure). (NIST Special Publication 800-53 Revision 5)
• Package audit evidence: scope register, tool configs, sample logs, and closed cases. Store it in a system like Daydream to keep it current as your environment changes.

Frequently Asked Questions

What counts as “integrity check” for SI-7(1)?

Any repeatable mechanism that verifies software, firmware, or information has not been modified outside approved baselines, and records results. The key is that checks run at your defined times and produce auditable evidence. (NIST Special Publication 800-53 Revision 5)

Do we have to check integrity at every single startup and every event?

You must perform integrity checks at startup, at organization-defined transitional states or security-relevant events, or at an organization-defined frequency. Document your chosen triggers and justify gaps with risk-based reasoning and compensating controls. (NIST Special Publication 800-53 Revision 5)

How do we handle integrity checks in immutable infrastructure (autoscaling, containers)?

Shift integrity from “runtime file hashing” to “artifact integrity.” Use signed images, digest pinning, and deploy-time policy enforcement so only approved artifacts run. (NIST Special Publication 800-53 Revision 5)

What is “information” in this control? Is it all data?

It is the information you define as integrity-sensitive, typically configurations, security policies, and critical datasets whose unauthorized modification changes system behavior or access. Put those items in your scope register and define how you validate them. (NIST Special Publication 800-53 Revision 5)

We’re on a major cloud provider. Do we still need firmware integrity checks?

You still must address firmware in your defined scope. If the cloud provider controls firmware, document the boundary and collect the provider assurance you rely on; cover the firmware you do control (for example, on-prem appliances, endpoints, network devices). (NIST Special Publication 800-53 Revision 5)

What evidence is most persuasive to an assessor?

A tight scope definition, configuration exports showing checks are enabled, centralized logs showing checks ran at required triggers, and at least one real integrity failure (or test) tied to a ticket and remediation record. (NIST Special Publication 800-53 Revision 5)