SR-10 Inspection of systems: requirements and evidence

What SR-10 inspection of systems requires and why it matters

SR-10 requires the organization to inspect defined systems or components to detect tampering, at random, at a defined frequency, or when defined indications of need appear. The situation behind it is familiar: a laptop comes back from an overseas trip, a server is pulled from a site in a high-risk location, or a network appliance arrives with a damaged seal. Someone must decide whether the device can be trusted before it touches the production network again, and the control exists so that this decision rests on a documented inspection rather than on assumption. The risk is that hardware or firmware was altered while out of the organization's custody, or that a component was swapped in the supply chain. Under SR-10 the organization, not NIST, sets the parameters: which systems or components are in scope, how often random or periodic inspections occur, and which indications, such as a broken tamper seal, an unexpected firmware version or a device returning from a designated location, trigger an inspection.

The control is hard to satisfy for two reasons that show up in assessments. The first is that the triggers and frequencies were never defined, so staff have no shared rule for when an inspection is required and each case is handled differently. The second is that inspections happen but are not recorded. An assessor testing SR-10 under SP 800-53A looks for records of random inspections, inspection reports and results, and the acquisition documentation that explains what the components are supposed to look like. If those records do not exist, the control is not met, regardless of how careful the people involved were. Before any remediation work, the reader should confirm three things: which devices fall under the defined parameters, who is authorized to perform and sign off an inspection, and where inspection results are stored so that they can be produced for an assessor.

For an implementation partner, the practical work is to make the inspection trail automatic where possible. Asset records in an inventory tool such as GLPI can flag devices that have left the office or been assigned to travel, and endpoint data from Wazuh's Syscollector can show hardware, installed software and running services for comparison against a known-good baseline. Integrity tooling such as osquery file integrity monitoring or Bareos verify jobs can show whether files have changed since they were last cataloged. These tools produce useful evidence, but they do not replace a physical or logical inspection that a named person performs and documents. Whether they satisfy the parameters the organization has defined is a question for the organization and its assessor to settle, so confirm that scope with them early.

Which systems, components and triggers SR-10 covers

SR-10 applies in all three SP 800-53B security baselines and in FedRAMP Rev5 Classes B, C and D, so scope is set less by whether the control applies and more by what the organization defines. The four organization-defined parameters decide which components are inspected, how, how often and on which triggers, and those choices determine the workload.

Baseline and FedRAMP class scope

SP 800-53B assigns SR-10 to the low, moderate and high baselines, and FedRAMP's Rev5 baselines require it at Classes B, C and D. Start by confirming which baseline or class your system carries, because that sets the floor for whether inspection is in scope at all. Ask your authorizing official or FedRAMP contact to confirm the applicable class before defining the component set. Systems outside these baselines may still adopt SR-10 as a risk decision, and that choice should be documented.

Laptops, field kits and mobile devices

Laptops, tablets, field kits and ruggedized devices are the most common candidates because they leave controlled space and return to it. Decide whether every device is in the defined set or only those issued for travel, deployed to field sites or used in specific roles. Record the device classes in the component inventory so inspections can be traced to specific assets. Confirm with your assessor whether a device class you exclude can still be reached by a travel trigger.

Network gear, spares and removable media

Routers, switches, firewalls, spare hardware in storage and removable media often sit outside daily monitoring, which makes them easy to overlook. Network equipment is a frequent tampering target because it sits in the data path, and spares can be altered before deployment. Decide whether spares and removable media enter the defined set and how they are tracked between storage and installation. Document the reasoning, since an assessor will ask why items were left out.

Travel and high-risk location returns

Returns from travel or high-risk locations are the trigger most organizations define first, because devices may have been out of custody. Define which locations count as high risk, who decides, and how the device is flagged when it checks back in. Pair the trigger with a clear inspection method, such as a physical check of seals and ports plus a logical comparison of file and configuration state. Keep a record of each triggered inspection so the trigger can be shown to work.

Parameters that set the workload

The four organization-defined parameters cover which components are inspected, the inspection method, the frequency or the triggers that start an inspection. Each one multiplies the work: a random sample of ten devices a quarter is far lighter than every device checked on each return. Write each parameter as a specific value in the system security plan so the scope is testable. Ask any consultant to price the work from the completed parameter set, not from a general description of the control.

Related controls that share the evidence

SR-10 is related to SI-7 on integrity verification, SI-4 on system monitoring, SR-9 on tamper resistance, and SR-11 on component authenticity, among others. Inspection results often serve as evidence for these controls at the same time. Map your inspection records to these related controls early so one inspection can satisfy several assessment objectives. Confirm the mapping with your assessor, because the related-control list is not a statement of equivalence.

How an assessor tests SR-10 inspections

This table breaks down the single SP 800-53A determination statement for SR-10 by examine, interview and test method. Read each row as what the assessor looks at, what they ask you to produce, and where programs usually fall short. The main takeaway is that a defined inspection schedule means little without dated records showing the inspections actually happened.

Method	What the assessor looks at	Evidence requested	Common findings
Examine: records of random inspections	Whether inspection records exist for the defined systems or components, and whether selections were random or triggered by defined indications	Inspection logs with dates, asset identifiers, inspector names and the reason each item was chosen	Logs exist but show no selection method, or inspections cluster in a single period
Examine: inspection reports and results	Whether findings are written down, including clean results, and whether anomalies were escalated	Signed inspection reports, photos or hash comparison outputs, and the escalation ticket for any tamper indication	Reports record that inspection occurred but do not state what was checked
Examine: assessment reports and results	Whether prior assessments or audits covered SR-10 and whether gaps were tracked to closure	Previous assessment reports, plan of action entries and closure evidence	Prior findings on inspection remain open with no owner or date
Examine: acquisition documentation	Whether contracts or acquisition terms give the organization the right to inspect delivered components	Purchase terms, service agreements or statements of work that describe inspection access for the supplier or carrier	Contracts silent on inspection rights, especially for devices shipped from third parties
Interview: staff who perform inspections	Whether inspectors know the defined triggers, the procedure and what counts as a tamper indication	Named staff, training records and a walk-through of one recent inspection	Inspectors cannot describe the trigger criteria or the escalation path
Interview: supply chain and procurement owners	Whether the team knows which items are subject to inspection, such as devices returning from travel or high-risk locations	Current list of in-scope asset classes and the process that flags returning equipment	Procurement and IT hold different lists, so returning devices are missed
Test: sample an inspection end to end	Whether a selected component can be traced from trigger to inspection result to closure	A chosen asset, its inspection record, its tamper check output and any follow-up ticket	Record exists, but the tamper check output is missing or cannot be tied to the asset

Implementing SR-10 in six steps

This sequence turns the SR-10 requirement into a documented inspection program, so that the organization can show which systems and components it checks, when it checks them, how it checks them and what it found.

Define the four parameters in writing
SR-10 leaves four values for the organization to set, so the first output is a short parameter statement that names them. The control owner, usually the supply chain or security lead with input from procurement and IT operations, records the random selection approach, the inspection frequency, the indication-based triggers and the scope of systems or components covered. The step is done when an assessor can read the statement and see exactly what the organization committed to, with an approver's name and date on it. Confirm the wording of each parameter against the current release of the control in the OSCAL catalog before you finalize it.
Choose the inspected systems and components
Next, build the list of systems and components that fall under the inspection program. Start from the asset inventory, using a system such as GLPI's Assets module or Wazuh's Syscollector data, and filter for devices that leave controlled premises, hold sensitive data, sit in high-risk locations or are shipped to and from suppliers. The output is an inspection population register with asset identifiers, owners, locations and the reason each item is in scope. Review the register whenever the inventory changes so that new devices are not missed.
Set inspection triggers and selection rules
Translate the parameters into operational rules. Random selection can be driven by a documented draw from the register at the chosen interval. Frequency-based inspections follow a fixed schedule. Indication-based triggers cover events such as a device returning from travel, a device reissued after a repair, or a device reported lost and recovered. The output is a trigger matrix that tells the inspector what starts an inspection, who is notified and how the selection is recorded. Keep the random draw method documented so an assessor can reproduce it.
Define physical and logical inspection methods
Write the inspection procedure before the first inspection is performed. Physical checks cover seals, enclosures, ports, labels, added hardware and signs of opening or substitution. Logical checks compare the running state against a known-good baseline: the approved firmware and software versions, hashes of key system files, configuration settings and installed packages. Open-source tools can support the logical side. osquery's file integrity monitoring records changes to listed paths with hashes, and Bareos verify jobs compare files against previously cataloged attributes. The output is a written inspection checklist for each device class, along with the baseline records it depends on. Confirm that each tool can produce the evidence the checklist requires in your environment before you rely on it.
Record each inspection with results and disposition
Every inspection produces a record: the device identifier, the trigger, the inspector, the date, the checks performed, the results and the disposition. Disposition options should be defined in advance, such as returned to service, quarantined, reimaged from a known-good image or escalated as a suspected compromise. Escalations feed into the incident response and supplier notification processes. Store records in a system with access controls and retention rules so they can be produced for an assessor. A clean inspection with a complete record is as important as a finding, because the assessor will test whether the inspections happened as defined.
Review records and related controls on a cycle
On a defined review cycle, the control owner checks that the inspections ran as scheduled, that random selections followed the documented method, that trigger events were actioned and that every finding has a closed disposition. The review also looks across related controls. SI-7 covers integrity verification of software and information, SR-9 covers tamper protection across the life cycle, SI-4 covers system monitoring and SR-3 covers supply chain controls. Gaps found in the review go to the plan of action and milestones. The output is a signed review record that an assessor can test, and it should be updated whenever the parameters, tools or asset population change.

What SR-10 evidence passes an audit

An assessor testing SR-10 looks for proof that the organization defined what it inspects, how it selects items, and what it found and did about it. The six artifacts below form one chain, and each one only holds up if it matches the parameters the organization set for itself. Confirm every artifact against your own defined parameters before an assessment.

Written parameter definition

This document states which systems or components are inspected, the inspection method, the frequency or the indications that trigger an inspection, and who performs it. SR-10 has four organization-defined parameters, so the assessor will check whether each one is filled in. Keep it under document control and review it when asset categories change, such as new device types or new travel or high-risk location rules. Illustrative example: a laptop policy that requires inspection on return from a listed high-risk country. Confirm each parameter value with your own risk owners.

Inspection schedule or random selection log

SR-10 allows inspection at random, at a defined frequency, or on defined indications of need. Whichever mode you chose, keep a record that shows the selection was made and when. For random selection, log the method, the seed or draw process, and the items selected. For scheduled inspections, keep the calendar and any missed dates with explanations. Assessors compare this log against the parameter definition to see whether the program runs as written.

Completed inspection records

Each inspection needs a record showing the item identifier, the checks performed, the result, the name of the person who inspected it, and the date. Missing names or dates are the most common reason an inspection record fails review. Link each record to the asset entry in your inventory so the assessor can trace the item from the log to the device. Store records in a system that prevents later edits, or keep a version history.

Inspection results and actions taken

Results show what the inspection found, and the actions show what was done about it. A record of no findings is valid evidence, but it still needs a date and inspector. When a finding occurs, record the response, such as quarantine, reimaging, reporting to the security team, or returning the device to the supplier. Connect findings to the incident response or change process so the trail continues past the inspection. Ask your security team to confirm which findings trigger escalation.

Exceptions and their approvals

Some items will be skipped, delayed, or inspected by a different method than the one in the parameter definition. Each exception needs a written reason, a compensating measure, a named approver, an expiry date, and a review date. Assessors often sample exceptions to see whether they were approved by someone with authority and whether they expired on time. Review open exceptions at each risk review so temporary exceptions do not become permanent gaps.

Acquisition documentation with inspection terms

Where suppliers deliver or service components, contracts and purchase terms should state the inspection requirements the organization relies on, such as tamper checks at delivery or on return from repair. SR-10 evidence is stronger when these clauses exist alongside the inspection records they support. Review new contracts and renewals for these terms and keep the clause references in the inspection parameter document. Ask procurement to confirm which contracts already include them.

Self-hosted open-source tools that support SR-10 evidence

SR-10 asks for inspections to detect tampering, and an assessor will look for records showing what was inspected, when and what was found. The tools below keep inventory and file integrity data that can support those records, but none of them performs a physical inspection or replaces the inspection procedure itself.

GLPI asset inventory

GLPI's Assets module tracks computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered manually or pushed automatically by the GLPI Agent. For SR-10, the asset register gives the inspection program a defined population of components to select from. Check that each record captures serial numbers, location and custodian, because an inspection can only be shown against items the register identifies. Confirm the license terms with counsel before deployment.

Wazuh system inventory

Wazuh's Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores the results in the Wazuh indexer. Inventory snapshots over time can show whether a system's hardware or software changed between inspections. Check that the agents cover the components in scope, since endpoints without an agent will not appear in the records. Confirm the license terms with counsel before deployment.

Bareos verify jobs

Bareos verify jobs compare files against previously cataloged attributes, which gives a Tripwire-like capability for detecting changes after a break-in. For SR-10, verify job reports can show that protected files or firmware images on a system remained unchanged between inspections. Check which file sets are cataloged and how often verify jobs run, because a change that happens between runs will not appear. Confirm the license terms with counsel before deployment, since the AGPL carries obligations for networked modifications.

osquery file integrity monitoring

osquery's file integrity monitoring watches the files and directories listed under file_paths in its configuration and records changes to the file_events table with the action, time and path. Where possible it also calculates MD5, SHA1 and SHA256 hashes of changed files. For SR-10, these records can support evidence that critical files on an inspected device were not altered. Check that file_paths covers the boot, firmware and configuration locations relevant to tamper detection. Confirm the license terms with counsel before deployment, since osquery is dual licensed.

What meeting SR-10 costs in money and effort

This table breaks down the cost and effort components of running SR-10 inspections, who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so no figures appear here; use the table to structure your own estimate and quote requests.

Cost component	One-time or recurring	What drives it	How to keep it down
Parameter definition and procedure writing	One-time, revised on change	Number of system types, which components are in scope, and how many of SR-10's four organization-defined parameters you set (inspection selection, frequency, indication triggers and tamper criteria)	Define a small number of device classes and reuse one inspection procedure across them
Tooling or licenses	Recurring if commercial	Commercial asset and integrity products usually bill per device or per seat; self-hosted open source such as GLPI, Wazuh, osquery and Bareos can remove most license spend but still needs hosting and staff time	Confirm license terms with each vendor, and count self-hosting labor and infrastructure as cost
Inspection labor for physical checks	Recurring	Number of devices returning from travel or high-risk locations, the inspection frequency you define, and the time each physical check takes	Limit physical inspection to the defined trigger events and keep a checklist so each check is quick
Inspection labor for logical checks	Recurring	Volume of file integrity alerts, baseline quality, and how often hashes and inventory data are reviewed	Tune monitored paths and baselines so reviewers see fewer false positives
Inspector training	One-time per person, refreshed periodically	Number of staff who perform physical or logical inspections and how often procedures change	Train a small pool of inspectors and cross-train on the same checklist
Evidence upkeep	Recurring	Retention of random inspection records, inspection reports, asset inventory exports and acquisition documentation that an assessor will examine	Generate evidence from tooling on a schedule instead of compiling it by hand before each assessment
External review or testing	Periodic, optional	Whether you ask an independent party to review inspection procedures or test tamper detection, and the scope agreed in writing	Limit external work to a defined scope and reuse its results in later assessments
Auditor sampling	Per assessment cycle	How many inspections, devices or records the assessor samples, and how well your evidence is organized	Keep inspection logs complete and indexed so sampling requests can be met quickly

Who does what for SR-10: your team, a partner and the auditor

Your organization owns SR-10. The control is implemented by the organization, so the parameters, the inspection decisions and the dispositions of anything found must come from your staff. SR-10 asks you to define which systems or components are inspected, how selection happens (at random, at a defined frequency, or on defined indications of need), and what triggers an inspection. Those choices are yours to justify and to keep current.

Parameters: Set the four organization-defined parameters in SR-10 and record the reasoning, such as which devices return from travel or high-risk locations.
Inspection decisions: Decide who performs each inspection, what is checked physically and logically, and who may release a device back into service.
Dispositions: Record what happens when tampering is suspected or confirmed, including quarantine, escalation and supplier notification under related controls.
Records: Keep records of random inspections, inspection reports and results, and the acquisition documents that show where components came from.
Accountability: Name an owner who signs off on the procedure and reviews the records on a cycle you define.

Before an assessment, confirm that each inspection record can be traced to a parameter you set and a person who signed it.

Where SR-10 programs usually fall short

SR-10 is short, but assessors test it through the records it produces: defined parameters, inspection logs, retained results and the baselines those results are compared against. The gaps below are the ones that most often leave an inspection program unable to show it works, along with a concrete action to close each one.

Parameters left undefined

SR-10 has four organization-defined parameters, covering which systems or components are inspected, how selection happens, the frequency or triggers, and what counts as tampering indication. When these are blank or vague in the procedure, the assessor cannot tell whether the organization inspected what it said it would. Write each parameter as a value a tester can check, such as a named asset class, a sampling rate or a fixed interval. Have the control owner sign the completed parameter set and store it with the system security plan.

No record of random inspections

Where SR-10 calls for random inspection, the assessor will look for records that show selection was random and that inspections happened. Many programs inspect informally and keep no selection log, so the random element cannot be shown. Keep a dated register of which items were selected, by what method, who inspected them and when. Asset inventory data can supply the population from which selections are drawn.

Travel returns missing from procedure

Inspection triggers such as a device returning from travel or a high-risk location are often understood by the team but never written down. Without a documented trigger, an inspection after a trip looks like an exception rather than a required step, and it is skipped when the person who knows the rule is away. Write the trigger list into the procedure, tie it to the travel or asset-check-out process, and record each triggered inspection as its own entry.

Results not retained

Inspections that happen but leave no output cannot be assessed. The examine objects for SR-10 include inspection reports or results and assessment reports, so the assessor needs the finding, the item identifier, the inspector and the disposition. A tick on a checklist with no outcome does not meet that need. Standardize a short inspection report template, store it in the same system as the evidence register, and set a retention period that covers your authorization cycle. Confirm retention rules with your own compliance owner.

Logical checks without a known-good baseline

Logical inspection, such as checking whether installed software or files have changed, only detects tampering if the organization knows what the correct state looks like. Hashes or inventories captured after an incident prove nothing about what was there before. Capture a known-good baseline at build or receipt, then compare later state against it. Wazuh Syscollector inventory and osquery file integrity monitoring can supply the current state, but the baseline and the comparison schedule still need to be documented.

Supplier contracts without inspection cooperation

Physical inspection of hardware often depends on the supplier, a shipping partner or a managed service provider. If contracts do not give the organization the right to inspect delivered items or to obtain access to inspection-relevant information, an inspection program can stall at the point where it matters most. Review supplier terms against the SR-10 parameters and add inspection cooperation and notification clauses where they are missing. Coordinate this with the SR-5 and SR-8 contract language so the clauses are consistent.

Questions buyers ask about SR-10

How much effort does SR-10 take to implement?

The effort depends on how many systems or components the organization defines for inspection, how often inspections happen, and how much evidence the assessor will expect. SR-10 leaves four parameters for the organization to define in Release 5.2.0: which systems or components are in scope, whether inspection is random, at a defined frequency, or triggered by defined indications of need, and the frequency or triggers themselves. The work has two parts: setting up a repeatable inspection procedure, and then running it and recording the results. A small, stable asset set with few triggers is far less work than a large fleet of laptops that travel often. Ask any provider for a quote that lists the defined components, the inspection method for each, and the records it will produce.

Can we run SR-10 inspections ourselves without outside help?

Yes, in most cases the organization can do this in-house, because SR-10 is a process control and does not require specialist tooling. The organization owns the control, defines its parameters, and is accountable for the inspection records. Outside help is useful when the team lacks a current asset inventory, needs a written inspection procedure that matches its risk, or wants open-source tooling such as GLPI or Wazuh to hold the inventory and inspection history. An implementation partner can prepare systems and evidence, but only an independent assessor can test the control and issue findings. Decide early which parts your staff will perform and which you want to outsource.

How long does preparation for SR-10 usually take?

No duration is published for SR-10, so the timeline depends on the drivers rather than a fixed number. The main drivers are the number of components in scope, the number of defined triggers such as travel to a high-risk location or return from a repair, and whether a current asset inventory already exists. Each additional trigger adds a procedure, a checklist and a record type that staff must follow and an assessor must sample. Organizations with an accurate inventory and a few clear triggers can prepare much faster than those starting from scratch. Ask for a written plan that sets out the inventory work, the procedure drafting and the first inspection cycle before agreeing to a schedule.

What does SR-10 require from our staff day to day?

Staff must follow a defined inspection procedure, perform inspections on the agreed schedule or after each trigger, and record the results. Those who inspect need to know what tampering looks like for each component type, such as an unexpected seal, a changed port, a swapped drive or an unfamiliar firmware state. Those who review need to check that records exist for every random, scheduled or triggered inspection and that findings are escalated. Training matters because an assessor will interview people about how they perform the inspection. Clear ownership for each defined trigger prevents gaps when staff are traveling or on leave.

Does SR-10 apply to cloud-only systems?

SR-10 applies to the defined systems or components in scope, and a purely cloud-hosted system may have few physical components to inspect. The control still matters for the hardware and software the organization controls, such as administrator workstations, build hosts, hardware security modules and any on-premises gateways. For cloud services, the organization usually relies on the provider's controls and its own assurance evidence, so the boundary of what it inspects must be written down. Logical inspection can also apply, for example by checking the integrity of images, configurations and agent binaries. Confirm with the assessor how the cloud boundary and the provider's responsibilities are documented.

How does SR-10 relate to FedRAMP impact classes?

FedRAMP's Rev5 baselines require SR-10 at Classes B, C and D, according to the Consolidated Rules for 2026. In practice, a cloud service that targets any of those classes must define its inspection parameters, run the inspections, and keep evidence that an assessor can review. FedRAMP 20x also links SR-10 to three Key Security Indicators: KSI-SVC-ACM, KSI-SVC-EIS and KSI-SVC-VRI. Those links mean the inspection evidence should connect to configuration management, security evaluation and resource integrity records rather than sit in a separate file. Confirm the exact class and indicator requirements against the current FedRAMP rules before scoping.

Which open-source tools can produce SR-10 inspection evidence?

Open-source tools can hold the inventory and the integrity evidence that support SR-10, although none of them performs a physical inspection on its own. GLPI's Assets module records computers, network equipment, peripherals and racks, and can be fed by the GLPI Agent. Wazuh's Syscollector module collects hardware, software, open ports and services from endpoints for inventory views and reports. For change detection, osquery's file integrity monitoring records changes under configured file paths, and Bareos verify jobs compare files against cataloged attributes. Confirm each tool's fit with your inspection procedure, and record who reviewed each result.

How DeployOpen scopes and prepares SR-10 evidence

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own infrastructure. For SR-10, we prepare the inspection tooling, records and evidence that the organization uses to show it inspects systems for tampering. The organization owns the control and its inspection decisions, and an independent assessor determines whether the control is met.

How we scope

Confirm which systems and components fall under SR-10, including devices that return from travel or high-risk locations.
Record the organization-defined parameters for random selection, inspection frequency and triggering indications in the written scope.
Agree in writing which inspection methods are physical, which are logical, and which tools will produce the records.

How we build

Configure asset inventory so each in-scope device has a record that inspections can be matched against.
Set up file integrity monitoring on defined paths and baseline hashes for firmware and boot-relevant files where the platform supports it.
Build inspection checklists and record templates so each inspection captures who inspected, what changed, and the result.

How we hand over

Deliver documented inspection procedures, configuration records and sample inspection reports for the assessor's examine methods.
Provide evidence of acquisition documentation and assessment results that the organization's own reviewers can trace.
Walk the organization's staff through operating the tools and the inspection records, and confirm the handover in writing.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if the organization wants help keeping the tooling current.
Review inspection records and tool configuration periodically against the written scope and the organization's own review cycle.
Confirm with the organization's assessor which evidence formats they accept before the assessment begins.