SI-7(9): Verify Boot Process

SI-7(9) requires you to verify the integrity of the boot process for the system components you define, so only trusted firmware, bootloaders, and kernel images can start and anything tampered is detected and blocked or flagged. To operationalize it quickly, standardize “secure/measured boot” configurations, collect boot-attestation evidence, and prove exceptions are controlled. ¹

Key takeaways:

• Scope the exact components covered (endpoints, servers, network devices, hypervisors, cloud images) and document that scope. ¹
• Implement boot integrity verification (secure boot and/or measured boot with attestation), plus monitoring and response for failures. ¹
• Retain assessor-ready evidence: configuration baselines, enforcement settings, attestation logs, and exception approvals tied to assets. ²

The si-7(9): verify boot process requirement is a practical integrity control: prove that systems start from a trusted state, not from altered firmware, bootloaders, or kernel images. SI-7(9) sits under the broader “Software, Firmware, and Information Integrity” family, so auditors will expect more than a statement of intent. They will look for technical enforcement on real assets and repeatable evidence that the control operates continuously, not only during build time. ²

The fastest path to assessment readiness is to treat boot integrity like an asset-class baseline. Define which components are in scope, pick the verification method for each class (for example, UEFI Secure Boot for endpoints, measured boot with TPM attestation for servers, signed images for cloud instances, and vendor secure boot features for network appliances), then centralize the evidence. Your goal is simple to explain: “We can detect and prevent unauthorized changes that would execute before the OS security stack starts.” ¹

If you run a third-party-heavy environment (managed endpoints, hosted platforms, SaaS admins on BYOD, outsourced data centers), you also need contract and due diligence hooks. A third party that provisions your infrastructure can quietly become the control operator, so you must be able to obtain attestation evidence and configuration proof on demand.

Regulatory text

Requirement (excerpt): “Verify the integrity of the boot process of the following system components: {{ insert: param, si-07.09_odp }}.” ¹

Operator interpretation: You must (1) define the system components in scope for boot integrity verification, and (2) implement a method that verifies boot integrity for those components in a way you can demonstrate to an assessor. The placeholder indicates this is an organization-defined parameter: you choose the components, but you must justify the choice and operate the control across that scope. ¹

Plain-English interpretation (what SI-7(9) means)

• “Verify boot process integrity” means you have a technical mechanism that checks the boot chain before the system becomes operational, so tampered boot components are detected (and ideally prevented from loading).
• Verification should be enforceable and observable. “We enable secure boot” without proof, monitoring, and exception handling usually fails under assessment scrutiny. ²

Who it applies to

Entity types:

• Federal information systems
• Contractor systems handling federal data (including many regulated suppliers and service providers) ¹

Operational contexts where assessors focus:

• End-user computing fleets (Windows/macOS/Linux laptops and workstations)
• Server and virtualization estates (bare metal, hypervisors, container hosts)
• Network/security appliances (firewalls, routers, switches, IDS/IPS)
• Cloud infrastructure (golden images, instance boot settings, managed Kubernetes nodes)
• Industrial/OT or embedded systems where boot firmware compromise is high-impact

Third-party dependencies to account for: managed service providers, device manufacturers, hosting providers, and any third party that builds images or controls firmware updates. Your compliance obligation remains even if a third party runs the platform.

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

Step 1: Define and document scope (the “ODP”)

Create a scoped list of “system components” subject to SI-7(9). Good scoping is asset-based, not org-chart-based.

• Start from your CMDB or asset inventory.
• Group into classes: endpoints, servers, hypervisors, network devices, cloud images, specialized appliances.
• Document inclusion logic (for example, “All systems processing federal data,” “All privileged admin workstations,” “All internet-exposed production hosts”). ¹

Deliverable: “SI-7(9) Boot Integrity Scope” register (asset classes, owners, and verification method per class).

Step 2: Choose a boot integrity verification method per asset class

You have two common patterns; many programs use both:

• Secure boot (preventive): only signed/approved boot components can execute.
• Measured boot (detective): boot measurements are recorded (often via TPM) and can be attested/checked against known-good values.

Build a decision matrix:

Asset class	Preferred control pattern	What “good” looks like in audits
Endpoints	Secure Boot + management enforcement	Policy enforces secure boot state; exceptions are rare and approved
Servers / hypervisors	Measured boot + attestation; secure boot where supported	Attestation evidence ties to host identity and is monitored
Network appliances	Vendor secure boot / signed firmware	Config screenshots/exports + vendor documentation in your standards
Cloud instances	Signed images + instance boot settings + image pipeline controls	Evidence from image pipeline and cloud policy settings

Map the method to your environment and risk. Document the rationale. ²

Step 3: Implement standardized configuration baselines

For each asset class:

• Define the “known-good” boot configuration (secure boot on, TPM enabled where applicable, boot order locked, external boot disabled where feasible).
• Enforce via tooling (endpoint management, server configuration management, cloud policy).
• Prevent drift: configuration monitoring plus change control for any baseline modifications.

Control owner tip: Assign a single accountable technical owner per platform (endpoints, server, network, cloud). SI-7(9) breaks when ownership is shared but evidence is not. ²

Step 4: Establish monitoring, alerting, and response for boot integrity failures

Auditors will ask what happens when verification fails.

• Define failure conditions (secure boot disabled, boot measurements deviate, unauthorized firmware change).
• Route alerts to your security monitoring queue.
• Define response actions: isolate host, reimage, investigate firmware, validate supply chain, and open an incident ticket.

Keep the response playbook short and executable. “Investigate” is not a step. Define who does what and what evidence they collect. ²

Step 5: Control and evidence the exception process

You will have exceptions (legacy hardware, lab systems, break-glass recovery).

• Require documented business justification.
• Require compensating controls (restricted network segments, additional monitoring, restricted admin access).
• Time-bound exceptions and review them on a recurring cadence you define.

Exceptions are where SI-7(9) findings pile up because teams allow indefinite “temporary” carve-outs.

Step 6: Prove operation with recurring evidence

Operationalize collection:

• Pull device state reports (secure boot enabled/disabled).
• Pull attestation logs where implemented.
• Keep change tickets for firmware/boot-policy changes.
• Keep incident records for boot integrity alerts, even if false positives.

If you use Daydream to run third-party due diligence and control evidence workflows, treat boot integrity as a recurring evidence request for any third party that provisions or manages your endpoints/servers. Ask for (1) their baseline standard, (2) proof of enforcement, and (3) sample attestation outputs tied to assets supporting your environment.

Required evidence and artifacts to retain

Keep evidence aligned to how you implemented verification:

Governance artifacts

• SI-7(9) scope definition (system components list and rationale) ¹
• Boot integrity standard/baseline document per asset class
• Roles and responsibilities (control owner, platform owners, monitoring owner)

Technical enforcement artifacts

• Secure boot configuration policies (export/screenshot + settings descriptions)
• Attestation configuration (how measurements are collected, where stored)
• Cloud policy artifacts (image signing requirements, boot settings policies)

Operational artifacts

• Recurring compliance reports showing current secure boot/attestation status
• Exception register with approvals and compensating controls
• Change tickets for firmware updates and boot-policy changes
• Alert and incident tickets tied to boot integrity failures

Common exam/audit questions and hangups

Expect these:

1. “Which components are covered by SI-7(9), and why?” If you cannot name the scope and show it matches where sensitive workloads run, you will struggle. ¹
2. “Show me enforcement, not screenshots.” Auditors often request exported policy objects, device compliance reports, and evidence of monitoring.
3. “How do you detect tampering that happens before the OS?” This is the heart of SI-7(9). Secure boot/measured boot answers that; antivirus does not.
4. “What happens when a device fails verification?” You need a playbook and tickets that show you followed it.
5. “How do third parties fit?” If a third party images devices or manages hosting, show contract language and collected evidence.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating SI-7(9) as a one-time build setting. Fix: add continuous reporting and alerting so you can prove ongoing operation.
• Mistake: Over-scoping without enforcement capacity. Fix: scope by asset class and roll out in waves; document interim exceptions with compensating controls.
• Mistake: No link between attestation data and asset identity. Fix: ensure logs tie to a unique device ID that matches your asset inventory.
• Mistake: Firmware updates happen outside change control. Fix: require tickets for firmware/boot-policy changes and attach pre/post evidence.
• Mistake: Exceptions never expire. Fix: time-box exceptions and require periodic re-approval with updated risk acceptance.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite any. Practically, SI-7(9) failures increase exposure to bootkits, firmware tampering, and persistence mechanisms that evade OS-level controls. The operational risk is outsized because compromise occurs before your endpoint detection agent and disk encryption policies can help.

Practical 30/60/90-day execution plan

Use phases so you can move without inventing schedule claims.

First 30 days (Immediate)

• Name a control owner and platform owners; publish a one-page SI-7(9) scope statement. ¹
• Inventory in-scope asset classes and identify current secure boot/TPM/attestation capabilities.
• Draft baselines for endpoints and servers first; these are easiest to evidence centrally.
• Stand up an exception workflow (ticket + risk acceptance + compensating controls).

Day 31–60 (Near-term)

• Enforce secure boot baselines via endpoint/server management for the largest in-scope populations.
• Implement measured boot/attestation where feasible for servers and privileged endpoints; route signals to monitoring.
• Create recurring evidence pulls (reports exported and stored) and an audit folder structure by asset class.
• Add third-party evidence requests in Daydream for any third party that images or manages systems in scope.

Day 61–90 (Operationalize)

• Expand to network appliances and cloud images; standardize how teams prove boot integrity for each.
• Test the response playbook with a controlled failure scenario (secure boot disabled on a test device) and retain tickets/logs.
• Review exceptions, retire what you can, and document residual risk acceptance for what remains.
• Run an internal audit-style walkthrough: pick samples from each asset class and prove enforcement + evidence end-to-end.

Frequently Asked Questions

What counts as “system components” for SI-7(9)?

You define the components, but assessors expect the list to cover the platforms where sensitive workloads run and where a pre-OS compromise would matter. Document the list and your rationale as part of the organization-defined parameter. ¹

Does enabling Secure Boot satisfy SI-7(9) by itself?

Secure Boot is often a strong control, but audits usually require proof of enforcement and ongoing operation: policy, compliance reporting, and handling for failures. Add monitoring and an exception process so the control is testable.

How do we handle legacy systems that cannot support secure/measured boot?

Put them on a documented exception with compensating controls, restricted exposure, and explicit risk acceptance. Track a remediation path (replacement, upgrade, isolation) and keep evidence of the approvals.

What evidence is most persuasive to auditors?

Exported configuration policies plus recurring compliance reports that show secure boot/attestation status across the in-scope fleet are stronger than screenshots. Pair that with change tickets for firmware updates and incident tickets for failures.

How does SI-7(9) apply in cloud environments?

Focus on image integrity (signed/controlled golden images), instance boot configuration, and preventing drift through policy. Your evidence should come from the image pipeline and cloud policy settings, plus instance compliance reports where available.

A third party manages our endpoints/servers. Can we inherit SI-7(9)?

You can rely on a third party operationally, but you still need evidence. Contract for boot integrity enforcement and request periodic reports/attestation outputs; Daydream can track those requests and store recurring artifacts for audits.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5