SA-19(2): Configuration Control for Component Service and Repair

SA-19(2): Configuration Control for Component Service and Repair requires you to keep strict configuration control over components while they are being serviced or repaired, so repaired items return in a known-good, approved state. Operationalize it by tying service events to approved baselines, controlling who can change what during repair, and collecting objective evidence that components were verified before reintroduction. ¹

Key takeaways:

• Treat service/repair as a high-risk configuration change window, even when performed by a third party. ²
• Require baseline identification, authorized change control, and post-repair verification before anything re-enters production. ²
• Audit readiness depends on evidence: tickets, chain-of-custody, approvals, and verification results tied to asset IDs. ³

For most organizations, “service and repair” lives in an operational blind spot: equipment gets shipped out, a field technician swaps a board, a managed service provider “fixes” an appliance, and the asset comes back with minimal documentation. SA-19(2): configuration control for component service and repair requirement exists to close that gap by treating maintenance as a controlled configuration event.

As a CCO, GRC lead, or compliance officer supporting federal systems or contractor environments handling federal data, you should read SA-19(2) as a requirement to prevent unapproved changes, malicious substitutions, and configuration drift introduced through repair workflows. This is as much a third-party risk problem as it is an IT operations problem. If a third party touches your components, your program still needs to prove the organization kept configuration control, validated what changed, and restored the component to an approved state before reintroduction.

This page gives requirement-level implementation guidance you can hand to IT asset management, security engineering, and procurement. It also tells you what artifacts to retain so an assessor can trace each service event from authorization to verification, without relying on tribal knowledge or email threads. ²

Regulatory text

Provided excerpt: “NIST SP 800-53 control SA-19.2.” ³

What the operator must do: Implement configuration control mechanisms specifically for the period when a component is serviced or repaired. In practice, you must (1) know the approved configuration of the component before it leaves your control, (2) constrain and authorize any changes during repair, (3) maintain traceability and chain-of-custody, and (4) verify the component returns to an approved, documented configuration before it re-enters the environment. ²

---

Plain-English interpretation

SA-19(2) means: service and repair cannot be a “black box.” If a device, subcomponent, or system element is repaired internally or by a third party, you must manage that activity like a controlled change. Your goal is to prevent:

• Unauthorized modification (intentional or accidental) during repair
• Counterfeit or substituted parts
• Configuration drift (firmware, BIOS, OS images, security settings)
• Hidden persistence introduced during servicing (for example, altered firmware)

A good mental model: Repair is a temporary extension of your change management and configuration management program to an offsite or third-party workspace. ²

---

Who it applies to (entity and operational context)

Applies to:

• Federal information systems subject to NIST SP 800-53 control expectations. ²
• Contractor systems handling federal data where NIST SP 800-53 is contractually flowed down or used as the governing control framework. ²

Operational contexts where assessors expect to see SA-19(2) implemented:

• Network/security appliances repaired by OEMs or managed service providers
• Servers, laptops, mobile devices sent to depot repair
• Storage media replaced during hardware servicing
• Industrial/OT components with firmware servicing
• Cloud-managed hardware appliances (where the third party performs physical work but you remain accountable)

Teams typically involved:

• IT Asset Management (inventory, asset IDs, custody)
• Security Engineering (baselines, verification testing)
• IT Operations (change tickets, maintenance windows)
• Procurement / Third-Party Risk (contract language, service SLAs)
• Facilities / Logistics (shipping and custody controls)

---

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

1) Define the scope of “components” and service events

Create a scoped list of in-scope component categories (examples: endpoints, servers, network devices, security appliances, removable media, critical boards/modules) and define what counts as “service and repair” (depot repair, onsite technician visit, RMA swap, firmware reflash). Tie scope to your system boundary and asset criticality. ²

Deliverable: SA-19(2) scope statement + in-scope component list mapped to asset inventory.

2) Establish approved configurations (baselines) for in-scope components

For each in-scope component type, define “known-good” configuration items you can verify after repair:

• Firmware/BIOS versions
• Secure boot settings
• OS build / golden image identifier
• Critical security configuration settings
• Installed modules/cards and serial numbers where feasible

This baseline can live in your CMDB, endpoint management platform, infrastructure-as-code repository, or a controlled configuration standard. What matters is that it is versioned and approved. ²

Deliverable: Baseline standards + approval record.

3) Make service/repair a formal change path with authorization gates

Require a ticket for every service event, including:

• Asset ID, serial number, owner, system boundary
• Reason for service, expected work, and whether a third party is involved
• Approved baseline reference and what must be re-verified post-repair
• Authorization/approval (risk-based; higher for high-impact systems)

If you have emergency repairs, define an exception path with after-the-fact approval and documentation. ²

Deliverable: Service/repair change workflow (in ITSM) + approval matrix.

4) Control the maintenance environment and chain-of-custody

For third-party repairs, your controls should cover:

• Chain-of-custody: who had the component, when, and where it was stored/shipped
• Tamper-evidence where appropriate: packaging controls and receipt inspection steps
• Service provider identity and authorization: named provider, work order, technician identification where available
• Parts control: track replaced components, serial numbers, and disposition of removed parts (especially storage)

This is where third-party risk management becomes operational. Your contract and work order process must demand repair documentation and traceability, not “fixed” as the only outcome. ²

Deliverable: Chain-of-custody log template + receiving inspection checklist + third-party service requirements.

5) Verify and re-establish configuration control before reintroduction

Before the component is put back into production:

• Validate it matches the approved baseline or an approved change record
• Run integrity checks you can actually defend (for example: firmware version verification, secure boot enabled, endpoint compliance checks, configuration scan)
• Confirm security tooling is present and reporting (EDR, MDM, logging, certificates)
• For replaced devices: ensure the image and configuration are rebuilt from approved sources, not inherited from the repair shop state

Block reintroduction if verification fails; route to remediation and document the disposition. ²

Deliverable: Post-repair verification checklist + test results attached to the ticket.

6) Record what changed, close the loop, and trend issues

Close the service ticket with:

• Work performed and parts replaced
• Baseline validation results
• Deviations and approvals (if baseline changed)
• Custody record and receipt inspection outcomes

Trend recurring issues by component type and service provider. This helps justify tightening controls or switching repair partners. Daydream is often used here to standardize evidence capture and map SA-19(2) to the control owner, procedure, and recurring artifacts so audits do not turn into a document scramble. ³

---

Required evidence and artifacts to retain

Assessors will ask for objective evidence that configuration control was maintained through service and repair. Retain:

Core artifacts ³

• Service/repair ticket with approvals and timestamps
• Asset identity proof: asset tag, serial number, system boundary mapping
• Chain-of-custody log (shipment, receipt, internal handoffs)
• Third-party work order and service report (what was done; parts replaced)
• Receiving inspection record (tamper check, condition, discrepancies)
• Post-repair verification results (screenshots, scan output, compliance reports)
• Exception documentation if standard steps were bypassed

Program artifacts (standing documentation)

• SA-19(2) procedure / standard operating procedure
• Configuration baselines (versioned) for in-scope components
• Approval matrix for service/repair changes
• Third-party contract clauses or addenda requiring repair documentation and part traceability
• Training or job aids for ITAM/ITOps staff who execute the process ²

---

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me the baseline.” Where is the approved configuration defined, and how do you know what “good” looks like for this component type? ²
2. “Prove control during third-party repair.” How do you prevent unauthorized modification when the component is offsite? What documentation do you require back? ²
3. “Walk one repair end-to-end.” Pick a recent ticket and trace: authorization → custody → work performed → verification → reintroduction. Gaps show quickly here.
4. “What happens when verification fails?” If you cannot show a defined quarantine/remediation path, the control looks cosmetic.

Hangups that derail audits:

• No chain-of-custody evidence beyond a shipping label
• “We trust the OEM” without contractual service documentation requirements
• Verification performed informally with no retained output

---

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating repair as “break/fix” with no change record	You cannot prove authorization or trace what changed	Require ITSM ticket + approval gate for service events 2
Baselines exist only for servers, not appliances/endpoints	Repairs happen most often on endpoints and appliances	Define minimum baseline attributes per component class
No control over swapped parts/serials	Substitution risk and asset traceability breaks	Record part serials where feasible; require service report
Reintroducing devices before security tooling checks in	You create monitoring blind spots	Add a “back in telemetry” step to verification checklist
Evidence scattered across email threads	Audit response becomes unreliable	Centralize artifacts in the ticket and control repository; Daydream can standardize the evidence set 3

---

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat SA-19(2) primarily as an assessment and contract compliance risk rather than a control with a predictable enforcement pattern. The real business impact shows up as:

• A security incident originating from compromised or altered components after repair
• Failed authorization-to-operate (ATO) or negative assessment findings because you cannot show configuration control evidence ²

---

A practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign a single control owner across ITAM + Security + ITOps.
• Define in-scope component categories and service event triggers.
• Update ITSM: create a “Service/Repair” ticket type with required fields and an approval step.
• Implement a basic receiving inspection + quarantine step for returned components. ²

By 60 days (make it repeatable)

• Publish baseline standards for top component categories by risk.
• Add chain-of-custody requirements and a standard template for third-party service providers.
• Update third-party contract language or work-order terms to require service documentation and part traceability.
• Train the teams who open/close repair tickets and who perform verification. ²

By 90 days (make it auditable)

• Run a sample-based internal test: trace recent repair events end-to-end and document gaps.
• Add automated verification where possible (configuration checks, compliance reports) and ensure outputs are retained.
• Build an audit-ready evidence pack per ticket and a dashboard of open/failed verification cases.
• Map SA-19(2) explicitly to owners, procedures, and recurring evidence artifacts in your GRC system; Daydream is commonly used to keep this mapping current as systems and providers change. ³

---

Crosswalk and related controls (to speed operational alignment)

SA-19(2) rarely stands alone. Align it with:

• Configuration management and baseline controls (to define and approve “known-good”)
• Change management (to authorize repair activity and deviations)
• Third-party risk management (to contractually require documentation and traceability)
• Asset management (to maintain identity, custody, and lifecycle records)
• Incident response (for suspected tampering or unexplained configuration changes)

This crosswalk is operational, not theoretical: the same ticket should satisfy multiple control objectives if you design it correctly. ²

Frequently Asked Questions

Does SA-19(2) apply if the OEM performs the repair and we never see the internal work?

Yes, because you still need configuration control outcomes: authorization, traceability, and verification before reintroduction. Require service documentation through contracts or work orders and validate the component against your baseline on return. ²

What counts as “component” for SA-19(2)?

Treat any hardware or device that can affect confidentiality, integrity, or availability as a component, including appliances, endpoints, servers, and firmware-bearing modules. Document your scope decision and keep it consistent with your system boundary. ²

If we replace a device entirely (RMA swap), do we still need configuration control?

Yes. The replacement is effectively a new component entering the environment, so you must verify it meets the approved baseline and is enrolled in security tooling before production use. Keep the swap documentation tied to the asset record. ²

How do we handle emergency repairs where approvals would slow restoration?

Define an emergency path with documented criteria, a minimal authorization step, and mandatory post-repair verification plus retrospective approval. Auditors accept urgency more readily than undocumented exceptions. ²

What evidence is most persuasive to an assessor for SA-19(2)?

A single ticket that contains approvals, custody records, the third-party service report, and objective post-repair verification output tied to the asset ID. Screenshots and exported scan results usually beat narrative statements. ²

We have a CMDB but it’s incomplete. Can we still meet SA-19(2)?

You can start by enforcing the repair ticket and chain-of-custody workflow for in-scope components and progressively improve inventory accuracy. Document the interim approach and show consistent execution on the assets that matter most. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5

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