Delivery and Removal

PE-16 is a physical security control with a very operational failure mode: components walk out the door (or enter the facility) without clear authorization, traceability, or inventory reconciliation. For FedRAMP Moderate systems, you are expected to run delivery and removal like a controlled process, even when the “facility” is a shared colocation suite or a contractor-operated space.

This requirement is not limited to servers in a datacenter. It commonly covers laptops used for privileged administration, removable media used for break-glass recovery, network devices shipped for replacement, and any other organization-defined system components that could store, process, or provide access to the FedRAMP system. The goal is straightforward: prevent unauthorized introduction of components (tampering, rogue devices) and prevent loss or exfiltration of components (data exposure, service disruption), while leaving a trail an assessor can follow.

The fastest path to operationalizing PE-16 is to (1) define what “system components” means for your environment, (2) implement an authorization workflow for every entry/exit event, and (3) retain records that tie each movement to a person, a purpose, and an inventory update. ¹

Regulatory text

Requirement (PE-16): “Authorize and control organization-defined types of system components entering and exiting the facility; and maintain records of the system components.” ¹

Operator interpretation:
You must (a) decide which components require control at the door, (b) ensure those components only move with explicit authorization and supervision/verification appropriate to your facility model, and (c) keep records that prove what moved, when, by whom, and under what approval. “Organization-defined” is the work: assessors will expect your definition to be documented, consistent, and implemented in daily operations. ¹

Plain-English interpretation (what PE-16 is really asking)

Treat the physical movement of system components like a security-sensitive change. If a component crosses the boundary of your facility (inbound delivery, outbound return, decommission, repair shipment, loaner swap), you need:

• A policy-backed rule that says which components are controlled and how.
• A pre-approved reason to move it.
• A controlled handoff (identity checks, packaging controls, chain-of-custody).
• A record that can be reconciled to the asset inventory and, when relevant, to sanitization/destruction evidence.

This is how you prevent three recurring issues: unauthorized devices being introduced, authorized devices being removed without traceability, and missing inventory history during incident response or audits.

Who it applies to (entity + operational context)

Entities: Cloud Service Providers and Federal Agencies operating FedRAMP Moderate systems. ¹

Operational contexts where PE-16 becomes “real”:

• Datacenters / colo suites: Rack-and-stack, hardware swaps, RMA returns, smart-hands work.
• Corporate offices supporting the FedRAMP system: Admin workstations, network gear in closets, secure storage rooms.
• Third-party managed facilities: Shipping/receiving performed by a colocation provider or logistics partner (still your control to define and verify).
• Hybrid operations: Components staged at one site, then moved to another (spares lockers, secure cages, offsite storage).

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

1) Define “system components” that require delivery/removal controls

Create a scoped list and bake it into policy and procedure. Common categories:

• Compute (servers, blades), storage arrays, backup appliances
• Network/security devices (routers, switches, firewalls, HSMs)
• End-user devices with privileged access (admin laptops, jump hosts if portable)
• Removable media and portable storage
• Any component labeled as handling FedRAMP system data or credentials

Decision rule: If the item can store sensitive data, contains credentials/keys, provides privileged access, or is required for availability, include it.

2) Establish a standard “Move Authorization” workflow

Minimum operational requirements:

• Request: ticket or form with item identity, reason, source/destination, carrier method, requested time window.
• Approval: authorized approver (facility/security/IT asset owner) signs off before movement.
• Verification: identity validation for the person moving/receiving the component and matching item identifiers (asset tag/serial) to the request.
• Exception handling: emergency moves (outage/RMA) still require after-the-fact documentation and management review.

Practical tip: Make approvals role-based (e.g., “Asset Owner” + “Physical Security”) so moves do not stall when one person is unavailable.

3) Control the physical transfer at the boundary

Controls depend on facility model, but you need a consistent pattern:

• Inbound: verify shipment matches approved request; inspect packaging for tamper indicators if you use them; log receipt; stage in controlled area.
• Outbound: verify authorization; confirm correct item; package securely; document chain-of-custody; log handoff to carrier/authorized person.
• On-site moves (cage to loading dock): treat as controlled if it crosses a defined boundary (secure room to public corridor).

If a colocation provider controls the loading dock, require evidence from them (delivery logs, visitor logs, ticket references) and reconcile against your authorization record.

4) Maintain records that reconcile to inventory

Your records must be good enough for an assessor to pick a random component and trace:

• where it was,
• when it moved,
• who authorized it,
• who handled it,
• where it went,
• and whether inventory reflects the new status/location.

5) Integrate with related controls (so PE-16 doesn’t fail indirectly)

PE-16 often breaks when it is isolated from adjacent processes:

• Asset management: inventory updates must be part of the move closure criteria.
• Media protection / sanitization: outbound decommissioned items may require wipe/destruction evidence before removal.
• Access control and visitor management: movers and receivers must be authorized to be in the space.
• Incident response: missing movement records become an incident when a component is lost.

6) Put ownership on a named function

Assign a single accountable owner (often Physical Security or IT Asset Management) and define handoffs:

• Requestor (system ops)
• Approver (asset owner + security)
• Custodian (shipping/receiving or datacenter ops)
• Inventory controller (asset management)

If you’re coordinating across teams and third parties, tools like Daydream can help centralize evidence capture (tickets, approvals, logs) and keep PE-16 artifacts audit-ready without chasing screenshots across inboxes.

Required evidence and artifacts to retain

Keep artifacts in a form that supports sampling and traceability:

• Policy/procedure defining in-scope component types and required authorization/control steps
• Move authorization records (tickets/forms) with approvals and rationale
• Chain-of-custody documentation (handoff signatures, carrier tracking references, receiving acknowledgments)
• Shipping/receiving logs (inbound/outbound registers) mapped to ticket IDs
• Asset inventory records showing updated status/location and identifier fields (serial/asset tag)
• Exception records for emergencies, with management review and closure notes
• If applicable: sanitization/destruction evidence tied to the specific asset identifier before removal

Common exam/audit questions and hangups

Assessors typically probe these angles:

• “What types of system components are controlled under PE-16, and where is that defined?” ¹
• “Show me the last few removals of servers/network gear. Where is the authorization and who approved it?”
• “Pick a random asset tag. Prove its last movement and current location match inventory.”
• “How do you handle RMAs and emergency swaps?”
• “How do you ensure a third party’s loading dock controls align with your requirements?”

Hangup: “Facility” ambiguity. If you operate in colo, define the controlled boundary (cage, suite, secure staging room) and show how entry/exit is governed at that boundary.

Frequent implementation mistakes (and how to avoid them)

1. Undefined scope (“everything is a system component”).
   Fix: define categories and examples; keep scope defensible and implementable.

2. Inventory updates happen “later.”
   Fix: make inventory update a closure requirement for the move ticket.

3. No link between door logs and approvals.
   Fix: require ticket ID in shipping/receiving logs, and require logs to reference asset identifiers.

4. Third-party shipments bypass your workflow.
   Fix: contractually require shipment notice and logs; operationally require your pre-authorization even if the third party performs the physical handoff.

5. Emergency processes become the normal path.
   Fix: limit emergency criteria; require manager review; trend exceptions.

Risk implications (why operators should care)

Operationally, PE-16 failures show up as:

• Data exposure risk if storage or endpoints leave without sanitization or chain-of-custody.
• Supply chain and tampering risk if components enter without authorization and inspection.
• Availability risk if critical spares or production gear goes missing.
• Audit risk when you cannot reconcile movement records to inventory during sampling.

PE-16 is also a control that incident response teams rely on. If you cannot quickly answer “who removed that device and why,” containment and forensics slow down.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Define in-scope component types and facility boundary points for entry/exit.
• Publish a short procedure: request → approval → verification → log → inventory update.
• Stand up a single intake channel (service desk form or ticket type) for all moves.
• Identify where logs will live and who owns them.

By 60 days (Operational hardening)

• Train shipping/receiving, datacenter ops, and security on the workflow.
• Add required fields to tickets: asset tag/serial, destination, carrier, approver.
• Implement spot checks: compare recent shipments against inventory changes.
• Formalize third-party expectations (colo or logistics) and define what evidence they must provide.

By 90 days (Audit-ready execution)

• Run an internal sample test: select a set of inbound/outbound moves and prove end-to-end traceability.
• Tighten exception handling, add management review notes, and trend recurring exceptions.
• Document standard evidence packages for assessors (policy + sample move packets + inventory reconciliation).
• Centralize artifacts for retrieval (ticketing exports, logs, approvals). If evidence collection is scattered, Daydream can be the system of record for PE-16 audit packets.

Frequently Asked Questions

What counts as a “system component” for the delivery and removal requirement?

PE-16 leaves the scope to the organization, but assessors expect a documented list of component types you control at entry/exit. Include anything that stores sensitive data, contains credentials/keys, provides privileged access, or is critical to availability. ¹

Do we need to log every package that arrives at the office?

Log movements for the component types you defined in scope for PE-16, not general office supplies. Your definition must be clear enough that shipping/receiving staff can follow it consistently. ¹

How do we handle colocation facilities where we don’t control the loading dock?

You still need pre-authorization and records for components entering/exiting your controlled boundary (e.g., your cage). Require the colo provider to supply delivery/visitor logs or ticket references that you can attach to your authorization record.

What does “authorize and control” mean in practice?

“Authorize” means a documented approval before movement; “control” means identity verification and a managed handoff so the correct item moves to the correct destination. You should be able to prove the chain-of-custody with records. ¹

Can we use shipping tracking numbers as our “records”?

Tracking numbers help, but they rarely show asset identifiers, approvers, and receiving verification. Pair carrier tracking with an internal move ticket that includes asset tag/serial and approvals, then retain both as a single evidence packet.

How strict do we need to be for emergency hardware swaps during an outage?

Allow emergency removals, but require a documented emergency ticket, the name of the authorizing manager, and after-the-fact reconciliation to inventory. Assessors will look for controlled exceptions rather than undocumented bypasses.

Footnotes

1. NIST Special Publication 800-53 Revision 5