SR-11 Component authenticity: requirements and evidence

What SR-11 component authenticity asks your organization to prove

If a contract, authorization package or FedRAMP assessment says SR-11 applies to your system, the control asks you to show two things: that you have a documented anti-counterfeit policy and working procedures that keep counterfeit components out of the system, and that you report any counterfeit you find to the supplier or other parties you have defined. The control sits in the Supply Chain Risk Management family and was moved here from SA-19 after that control was withdrawn. SP 800-53B selects SR-11 for the low, moderate and high baselines, and it selects enhancements (1) and (2) as well, so an assessor will expect to see the base control and both enhancements evidenced at every impact level. The risk is simple to state: a counterfeit or altered component, such as a memory module, network card or drive, can carry defects or hidden functions that no later patch will remove.

The practical difficulty is visibility. Component provenance often sits with a distributor, a contract manufacturer or a field technician, outside the view of the team that runs the system. Procurement knows what was bought, maintenance knows what was swapped during a repair, and engineering knows what was configured, but those records rarely connect by serial number, part number or asset identifier. Before you write procedures, confirm which of your suppliers and service providers are responsible for sourcing, which parties you will notify when a counterfeit is found (the source, your contracting officer or another defined party), and whether your contracts already give you the access you would need to investigate.

Start by mapping each component class in the system boundary to its acquisition path and its repair path, then decide where asset records will be kept and who checks them. Ask your acquisition team which contract clauses cover authenticity and reporting, and ask your maintenance provider how replacement parts are sourced and whether the training they give technicians covers counterfeit recognition. Assessors will look for records of reported counterfeit components, acquisition documentation, service level agreements and acquisition contracts, so confirm early that these exist and can be pulled for the system. The enhancements add anti-counterfeit training and configuration control during repair, and these are often the gaps that surface late, so plan them with the same care as the base control.

Which components, teams and suppliers SR-11 reaches

SR-11 reaches further than the hardware on the data center floor. Scope depends on which components the system actually uses, which teams touch them between purchase and retirement, and which third parties handle them, and it is set by the system's baseline and authorization boundary. The cards below cover those decisions and the controls where SR-11 work connects to others.

Hardware, firmware and software components

Start with the component types inside the authorization boundary: servers, network devices, storage, endpoints, firmware for each, and the software packages that run on them. Anti-counterfeit work applies to physical parts and to the firmware and media that arrive with them, so the inventory should record both. Check that the boundary inventory is complete before deciding which items the anti-counterfeit policy must cover. Asset tools such as GLPI can hold the record, but the scope decision is the organization's to make.

Replacement parts and spares

Spare drives, memory, power supplies and line cards are the parts most often bought outside the primary channel to close a gap quickly. Each spare that will enter the system is a component SR-11 must address, even if it sits in a cabinet until needed. Ask who approves emergency purchases and whether those purchases pass the same verification steps as planned orders.

Acquisition and receiving teams

Procurement sets the source of each component, and receiving checks the delivery against the purchase order and the expected packaging, serial numbers and documentation. Both teams should know which suppliers are approved and what happens when a shipment does not match. Confirm that receiving logs are kept with the asset record so an assessor can trace a component from order to installation.

Maintenance and repair teams

Internal technicians who replace parts, reflash firmware or return a device under warranty create the points where a genuine component can be swapped for a counterfeit or altered one. Define who may open a system, which parts may be fitted, and how changes to configuration during repair are recorded. The enhancement on configuration control during repair belongs to this team's procedures.

Resellers, depot repair and managed providers

Resellers, depot repair providers and managed service providers often handle components on the organization's behalf. Their contracts and service level agreements should state how they source parts, how they report suspected counterfeits and who bears the cost of a replacement. Ask each third party to describe its own verification steps, then compare those steps against the organization's policy.

Related controls: PE-3, SA-4, SI-7, SR-9, SR-10

The Release 5.2.0 catalog relates SR-11 to PE-3 (physical access control), SA-4 (acquisition process), SI-7 (software and information integrity), SR-9 (tamper resistance and detection) and SR-10 (inspection of systems or components). Each one covers part of the same trust chain, so evidence collected for one can support the others. Confirm the mapping with the control text and your own assessor before relying on it in a plan.

How an assessor tests SR-11 and what they ask to see

This table maps the five SP 800-53A determination statements for SR-11 to the examine, interview and test methods an assessor uses, the records they request, and the findings they commonly raise. Read each row as a question the assessor will ask, then check whether your organization can answer it with dated, retrievable evidence.

Assessment method	What the assessor does and asks to see	Common findings
Examine: counterfeit reporting records	Requests records of counterfeit system components that were reported, including what was found, where the component came from, who was notified and when. An empty log may be acceptable only if the organization can show how it would have recorded one.	No reporting path defined; reports exist only in email threads; no evidence that reported counterfeits reached the source or defined parties.
Examine: acquisition documentation	Reviews purchase records, receiving and inspection checklists, and component identifiers (serial numbers, certificates of authenticity) to confirm that anti-counterfeit checks happen before components enter the system.	Receiving steps are informal; no link between purchase orders and installed serials; checks are documented for some purchases but not others.
Examine: service level agreements	Checks whether SLAs with maintenance and hardware providers require authentic parts, define how suspected counterfeits are handled, and set how fast suspected cases are reported.	SLAs silent on counterfeit parts; vendor support terms do not cover substituted or refurbished components.
Examine: acquisition contracts	Reviews contract clauses for the system, its components and services for anti-counterfeit terms, supplier notification duties and rights to audit or return non-genuine parts.	Contracts omit counterfeit terms; clauses exist only in templates not applied to older agreements.
Interview: acquisition staff	Asks how purchasing verifies authenticity, which sources are approved, and what they do when a supplier cannot prove a component is genuine. Answers should match the written procedure.	Staff describe steps that the written procedure does not contain; no one knows who receives a counterfeit report.
Interview: maintenance and security staff	Asks how repairs are performed, which replacement parts are allowed, and how suspected counterfeits found during service are escalated and documented.	Field technicians substitute parts without a record; security staff are not told about suspected counterfeits.
Test: component verification sample	Selects a sample of recently received or replaced components and checks that identifiers match purchase and inventory records, and that verification steps were performed and recorded.	Mismatched serials or missing inventory records; verification steps skipped for urgent replacements.
Test: reporting path walkthrough	Walks a hypothetical suspected counterfeit (illustrative) from detection to report, confirming the named owner, the notification target and the record kept at each step.	Path stops at the first handoff; the named owner has left the role; the source is not notified.

Implementing SR-11 in the order an assessor will check it

This sequence moves SR-11 from a written anti-counterfeit policy to contract terms, training and repair controls, so that each step leaves a record an assessor can examine. The owner of the system sets the organization-defined parameters early, because later steps depend on them.

Set the organization-defined parameters
Before writing anything, the control owner decides and records the values SR-11 leaves to the organization: which parties receive counterfeit reports beyond the source, what counts as a suspect component, and how often the anti-counterfeit procedures are reviewed. Supply chain and security leads approve these decisions, and the approval record becomes the first item in the evidence file. Confirm the exact parameter wording against the Release 5.2.0 catalog before the decisions are finalized, because the parameter structure is the basis of every later step.
Write the anti-counterfeit policy and procedures
The security and procurement owners write the anti-counterfeit policy and the procedures that put it into practice, covering how components are checked, who may approve an exception, and how staff recognize suspect parts. Leadership or the designated official approves the document, and it is versioned and reviewed on the schedule set in step one. The approved, dated document is the primary evidence for the policy requirement, so an assessor will look for the approval signature and the review history.
Define detection and quarantine at receipt and in service
Operations staff define the checks applied when components arrive, such as verifying packaging, serial numbers and vendor documentation against purchase records, and the checks repeated in service, such as comparing installed hardware and software inventory with the approved baseline. Suspect items are isolated under a documented quarantine step with a named owner. Inventory tools such as GLPI Assets or the Wazuh Syscollector inventory can record what is installed and show deviations, and the quarantine log and inspection records become evidence of detection.
Establish the counterfeit reporting path
The organization defines who reports a confirmed or suspected counterfeit, to whom (the source, or the other parties named in step one), within what internal escalation, and how the report is recorded. The procedure is tested with a tabletop walk-through so the people who would report know the route. Evidence includes the reporting procedure, a sample report template and the records of any reports made, or a signed statement that none have occurred in the review period.
Add counterfeit terms to contracts and SLAs
Procurement and legal teams add anti-counterfeit obligations to acquisition contracts and service level agreements, such as requirements for authentic components, notice of suspected counterfeits and cooperation with investigations. Contract language is reviewed against the anti-counterfeit procedure so the two agree. The executed contracts and SLAs are the evidence that the obligations exist, and the assessor will compare them against the procedure. Ask counsel to confirm the clauses fit your contract templates and jurisdiction.
Train relevant staff on counterfeit detection
This step covers the anti-counterfeit training enhancement, SR-11(1). The owner identifies the roles that receive or install components, inspect them or handle repairs, and delivers training on the detection checks, quarantine and reporting steps from the earlier procedures. Completion records are kept per person, and the training content is updated when the procedures change. Training completion lists and course materials are the evidence, and an assessor will check that the trained roles match the roles who actually perform the checks.
Control configuration during repair
This step covers the repair enhancement, SR-11(2). Maintenance and engineering staff define how configuration is controlled when a component is repaired or replaced, including verifying the replacement part against the approved record, recording the change, and checking the restored configuration against the baseline. Repair tickets, change records and post-repair inventory comparisons show the control operating. Confirm with your maintenance vendors that their repair procedures meet the same checks before relying on them.

Evidence that passes SR-11 and how to keep it current

SR-11 is tested through records, not declarations: a policy, a log of counterfeit reports, contract terms, training history and repair records. Each artifact below has a different refresh rhythm and owner, and the inventory data that links a component to its records is only as good as its coverage.

Anti-counterfeit policy and procedures

This is the written policy and the procedures beneath it that describe how counterfeit components are detected and kept out of the system. An assessor checks that the documents name the owner, the scope of components covered, the detection steps (for example, verifying authenticity at receipt against vendor documentation) and the reporting path. Confirm that the procedures match what staff actually do at receiving and installation. Review on the cycle your own policy program sets, and after any material counterfeit event or change in sourcing. Ownership usually sits with the supply chain or procurement function, with security approving it.

Counterfeit reporting record

A counterfeit reporting record shows that a suspected or confirmed counterfeit was reported to the source or other defined parties. Illustrative example: a network switch fails authenticity checks at receiving, is quarantined, and the record notes the serial number, the supplier notified, the date of notice and the supplier's reply. Keep one entry per event, even for events that were closed as false positives. Refresh the log continuously as events occur and review it at least on the assessment cycle. The security operations or procurement lead typically owns it.

Acquisition contract clauses and SLAs

Contracts and service level agreements show that counterfeit controls were written into the terms with suppliers and integrators. Look for clauses requiring authentic components, notice of suspected counterfeits, support for investigation and reporting timelines the organization can enforce. Check that each clause maps to the supplier that actually delivers hardware or software in your environment. Refresh when contracts renew, when suppliers change or when a supplier's terms are amended. Legal and procurement own the documents, and the system owner should confirm the terms reach the operational team.

Training records for enhancement 1

Enhancement SR-11(1) concerns anti-counterfeit training for personnel who handle components. Records should show who was trained, on which version of the material, the date, and the test or attestation that followed. Training is only evidence if the people in receiving, field service and administration roles are on the list, so compare the roster against the staff who touch hardware. Refresh training on the organization's defined schedule and whenever the policy or procedures change. HR or the security awareness program owns the records, and the system owner signs off on coverage.

Repair change records and configuration baselines

Enhancement SR-11(2) covers configuration control during repair, so the evidence is the change ticket, the pre-repair and post-repair configuration baseline, and the verification that the replaced component matches the approved part. Check that every repair produced a change record and that the baseline was compared after reinstallation. Refresh these records at each repair event and reconcile them against the configuration baseline on the assessment cycle. The operations or change management team owns the records, with the component owner approving restored configurations.

Asset inventory exports

An inventory export is the link between a physical or logical component and the records above, showing serial numbers, models, firmware versions and locations. Tools such as GLPI Assets or Wazuh Syscollector can produce inventories that help you confirm each component has a traceable record, but they must be reconciled against the actual system boundary. Check that exports cover every component in scope, including spares and replacements, not only the ones that were easy to discover. Refresh exports monthly or on the defined inventory cycle and after every repair. The configuration or asset management owner should run the reconciliation.

What meeting SR-11 costs in money and effort

This table breaks down the work behind SR-11 by cost component, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the rows as a checklist for building your own estimate from a written scope and your environment.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Anti-counterfeit policy and procedure drafting	One-time, then reviewed periodically	Number of component types, number of sites and how many teams handle receiving and repair	Reuse existing acquisition and asset policies, and scope the procedure to the component classes your system actually uses
Contract clause updates	One-time per contract, recurring at renewal	Number of suppliers and resellers, and whether existing agreements already cover counterfeit reporting	Update standard terms once and apply them at renewal rather than reopening every agreement at the same time
Training delivery for anti-counterfeit awareness	Initial delivery, then recurring for new staff and refreshers	Headcount of receiving, procurement and field staff, and the enhancement that adds anti-counterfeit training	Build short role-based modules and track completion in the same system used for other security training
Inventory and receiving process work	One-time design, recurring operation	Component volume, number of receiving points and how much identity data suppliers provide	Record component identifiers in an open-source asset inventory such as GLPI, which avoids license spend on the inventory tool itself
Reporting process design for counterfeits	One-time design, recurring when a case occurs	Number of defined reporting parties and whether reports go to the source, a government body or both	Define one intake path and a standard report template before the first event
Repair configuration control	Recurring with each repair	Repair frequency, whether repairs are done in house or by a vendor, and how often baselines change	Verify component integrity after repair with inventory and integrity tooling, and keep repair records in the change process
Tooling for inventory and integrity checks	Initial setup, then recurring operation and staff time	Number of endpoints, whether an SBOM is required and how often inventories are reviewed	Self-hosted open-source options such as Wazuh Syscollector and Trivy can produce inventory evidence without a per-seat license, though hosting and staff time still apply
Assessor sampling and evidence preparation	Recurring at each assessment	Baseline level, number of components and records sampled, and how well records are organized	Keep reported-counterfeit records, acquisition documents and service agreements in a single indexed location before the assessment starts
Independent external review	Optional, recurring if used	Scope of the review, whether the reviewer is independent of the implementer, and number of systems covered	Ask for a fixed-scope written proposal listing deliverables, and confirm whether the reviewer will issue any report

Open-source tools that produce SR-11 inventory and configuration evidence

SR-11 asks an organization to detect counterfeit components and to show what it has done about them, which depends on knowing what is installed, where it came from and whether it still matches its record. The four tools below each produce a different slice of that record: hardware and asset inventory, endpoint software state, and software component bills of materials. None of them is a substitute for the anti-counterfeit policy, the reporting procedure or the training the control also requires.

GLPI Assets for component records

GLPI's Assets module holds computers, monitors, software, network equipment, peripherals, printers, phones and racks, entered by hand or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. For SR-11, the useful part is a component record that carries the manufacturer, serial number, purchase source and assigned location, so that an unexpected device can be traced to an approved acquisition. Confirm in your own instance which fields your version captures and how the agent reports serial numbers. GLPI is licensed under GPL-3.0-or-later.

Wazuh Syscollector for endpoint state

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint and stores them in the Wazuh indexer. Dashboard reports let a reviewer compare what is actually running against the approved baseline, which is the basis for spotting unauthorized or substituted hardware and software. Confirm which inventory fields are collected on each operating system you run, since coverage varies by platform. Wazuh is licensed under GPL-2.0-only.

Dependency-Track for software authenticity review

OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, and flags components with known vulnerabilities, outdated versions, modified components and license risk. Its tracking of components by SPDX license ID gives a reviewer a single list of what each product contains and where it came from. A component flagged as modified or outdated is a prompt to check its origin against the supplier's published artifacts. Confirm how your team will source the SBOMs it ingests, because the review is only as trustworthy as the input. Dependency-Track is licensed under Apache-2.0.

Trivy for SBOM generation and scanning

Trivy identifies the OS packages and software dependencies in a target and can output them as a software bill of materials. It can also scan an existing SBOM, which lets a team check components delivered by a supplier as well as components built in-house. Running it on build outputs and on deployed images gives two records to compare, so that a mismatch between what was built and what was deployed becomes visible. Confirm the SBOM format and the scan targets your pipeline supports before relying on the output as evidence. Trivy is licensed under Apache-2.0.

Who owns SR-11 work and what is worth outsourcing

Your organization owns SR-11 in full. The control asks for an anti-counterfeit policy and procedures, a way to detect and prevent counterfeit components from entering the system, and a process for reporting counterfeits to the source or other defined parties. Those decisions depend on your supplier relationships, your risk tolerance and your knowledge of your own environment, so they cannot be delegated to a vendor or consultant.

Policy and procedures: Your leadership approves the anti-counterfeit policy, names the owner and sets the review cycle.
Organization-defined parameters: You choose the values for the parameters the control leaves open, such as the parties that receive counterfeit reports and the conditions that trigger them.
Supplier relationships: Your procurement and legal teams hold the contracts and the channels through which suspect components are reported to the source.
Judgment on components: Your security or asset team decides whether a specific component is counterfeit and what happens to it.
Enhancement decisions: You decide how anti-counterfeit training and configuration control during repair will work for your staff and your repair providers.

Confirm that each of these items has a named owner in your own documents before you engage any outside party.

Where SR-11 programs usually fall short and how to close the gap

SR-11 programs rarely fail because the policy is missing. They fail where the policy meets daily work: a reporting path nobody tested, contracts that never mention counterfeits, and repairs that quietly change configuration. Each card below names one gap and the artifact that closes it.

Reporting path that stops at the policy

The anti-counterfeit policy often names no owner for reporting a suspect component to the source or other defined parties. Staff then do not know whether to contact the supplier, the security team or the manufacturer. Write a short reporting procedure with a named role, the contact details for each supplier, and a record template. Check the path with a tabletop exercise using a suspect part, and keep the completed record as evidence of reported counterfeit components.

Acquisition contracts without counterfeit terms

Purchase orders and service agreements frequently omit any clause on counterfeit detection, authentic-part warranties or supplier notice. The assessor will look at acquisition contracts and service level agreements for the system and its components. Review the top suppliers by component type and add clauses that require authentic parts, disclosure of gray-market sourcing and prompt notice of suspected counterfeits. Keep the amended contracts in the acquisition file.

No training record for component handlers

Staff who receive, install, repair or dispose of components need to recognize counterfeit risk, yet many programs have training for the security team only. Identify the roles that touch hardware and spare parts, deliver anti-counterfeit training to them, and record attendance and the date of each session. The training record and its content are what an assessor will ask to see when testing the anti-counterfeit enhancement.

Repairs that change configuration unrecorded

Repair and replacement work can alter firmware, boot settings or installed software without any change ticket. The enhancement for configuration control during repair expects the organization to keep control of the system while a component is serviced. Require a change record before and after each repair, compare the configuration against the approved baseline, and link the record to the replacement part's serial number. Tooling such as configuration baselines in a CMDB can hold this comparison.

Inventory that drifts from the installed system

A hardware register that was accurate at purchase often no longer matches what is installed after swaps, moves and repairs. Without that match, an organization cannot show which components it received, from which supplier, or whether a suspect part is in service. Reconcile the asset register against discovered hardware and software on a set schedule. GLPI can hold asset records from its inventory agent, and Wazuh Syscollector reports hardware and installed software from each endpoint for comparison.

Organization-defined parameters never set

SR-11 leaves several values to the organization, including the reporting parties and the enhancement choices that apply to the system. Many system security plans state the control but leave these parameters blank or copied from a template. Set each parameter in the system security plan, approve it with the authorizing official, and confirm the values match what staff actually do. Recheck them whenever the baseline or supplier base changes, and confirm the values against the OSCAL profile for your baseline.

Questions buyers ask about SR-11 cost, effort and audit

What drives the cost of meeting SR-11 component authenticity?

The cost depends mostly on how many component types and suppliers fall inside the system boundary, how many of those components are repaired or replaced in the field, and how much of the anti-counterfeit procedure already exists. Organizations pay for internal time to write the policy and procedures, for training if the enhancement applies, for inventory and provenance records, and for an independent assessment. Most of these costs are one-time build work followed by recurring review and evidence collection. No supplied figure sets a price, so ask any partner or auditor to quote each component separately against your written scope.

Can an organization implement SR-11 without outside help?

Yes. SR-11 is a policy and procedure control backed by records, so an internal team with security, procurement and operations staff can write the anti-counterfeit procedure, define how suspect components are detected and reported, and keep the records. Outside help is most useful when the team lacks experience with component verification, needs help connecting inventory tooling to the procedure, or wants an independent view before an assessment. The organization always owns the control. An implementation partner can prepare systems and evidence, but only an independent assessor issues findings.

What does SR-11 require from internal staff?

Staff need to own the anti-counterfeit policy, run the detection and reporting steps, and keep the records an assessor will examine. In practice this means a named owner for the procedure, procurement staff who check component sources before purchase, operations staff who verify components on receipt and during repair, and a person who can send counterfeit reports to the source or other defined parties. If the training enhancement is selected, staff must complete anti-counterfeit training that the organization defines and records. Ask your assessor which roles they expect to interview.

How long does SR-11 take, and why doesn't NIST set a timeline?

The time depends on the size of the system, the maturity of existing supplier and asset records, and whether the procedure must be written from scratch. NIST does not set this timeline. Its risk management FAQ states that NIST does not estimate compliance costs or set federal implementation timelines, leaving those to OMB Circular A-130. Ask a partner or auditor to break the schedule into policy, procedure, records and assessment phases, and confirm the dates in writing before work starts.

Does SR-11 apply in a FedRAMP or contract context, and which classes name it?

SR-11 applies wherever a system is assessed against SP 800-53, including federal contracts and FedRAMP authorizations. FedRAMP's Rev5 baselines, as set out in the Consolidated Rules for 2026, require SR-11, SR-11(1) and SR-11(2) at Classes B, C and D. FedRAMP 20x also lists SR-11 or its enhancements among the related controls of two Key Security Indicators, KSI-CED-RAT and KSI-SVC-VRI. Confirm the class and contract language with your authorizing official or contracting officer, because the requirement follows the contract.

How does SR-11 relate to SR-9, SR-10 and SA-4?

SR-11 covers detecting and reporting counterfeit components. SR-9 covers tamper resistance and detection across the life cycle, SR-10 covers inspection of systems or components for tampering, and SA-4 covers acquisition process requirements, including contract terms that can require suppliers to provide authentic components. The FedRAMP and NIST catalog relationships list SR-9, SR-10, SA-4, SI-7, PE-3 and SR-10 as related to SR-11. In an assessment, the same inspection records and acquisition contracts may support more than one control, so plan evidence once and map it to each control.

What will an assessor ask for first under SR-11?

Assessors following SP 800-53A typically begin with the written anti-counterfeit policy and procedures, then ask for records of reported counterfeit system components, acquisition documentation, service level agreements and acquisition contracts for the system, components or services. Expect questions about how components are verified on receipt and during repair. Prepare these records before the assessment starts, and confirm with your assessor which examine, interview and test methods they will use.

How DeployOpen prepares SR-11 systems and evidence

DeployOpen works on SR-11 Component authenticity as a fixed-scope implementation engagement inside your own infrastructure. We prepare the systems that hold component records, the anti-counterfeit procedures and the evidence an assessor will examine, while your organization keeps ownership of the control and the independent assessor issues any conclusion.

How we scope

Agree in writing which components, suppliers and asset records fall within the SR-11 scope.
Confirm which acquisition contracts, service level agreements and counterfeit reports the assessor will ask to examine.
Record who owns the anti-counterfeit policy, the reporting path and the repair configuration control process.

How we build

Configure GLPI Assets or Wazuh Syscollector to hold component inventory records tied to acquisition documentation.
Set up Dependency-Track and Trivy so component provenance data and SBOMs can be checked against recorded inventory.
Test the counterfeit reporting workflow and repair configuration checks so they produce records an assessor can trace.

How we hand over

Deliver the written procedures, configuration records and tool exports mapped to the SR-11 determination statements.
Document each evidence source, its owner, where it is stored and how often it is refreshed.
Provide a handover walkthrough so your team can produce the same evidence without DeployOpen involved.

How we support

Offer ongoing support and upgrades for the inventory and SBOM tooling as a retainer.
Re-check evidence collection when NIST or FedRAMP changes the related control requirements.
Support your assessor's questions on the prepared evidence, while the assessor alone issues findings or reports.