Secure Media Distribution

“Secure media distribution” is a chain-of-custody problem. If media containing cardholder data leaves your controlled space, you must be able to answer three questions fast: What left, who authorized it, and where is it now. PCI DSS 4.0.1 Requirement 9.4.3 turns those questions into operational requirements: you must log outbound media, use a secured courier or another delivery method that can be accurately tracked, and keep offsite tracking logs with details about the media’s location. (PCI DSS v4.0.1 Requirement 9.4.3)

This requirement often gets missed because teams focus on encryption, network controls, and access management, while “media” feels legacy. In practice, media can include backup drives, removable storage, printed reports, call recordings exported to physical devices, or any other storage format that contains CHD. The risk is straightforward: loss or theft during transit can become a payment card data exposure, and you may not even be able to prove what was lost if your logs are weak.

This page gives you requirement-level implementation guidance you can put into a procedure, evidence plan, and audit-ready workflow quickly.

Regulatory text

PCI DSS 4.0.1 Requirement 9.4.3: “Media with cardholder data sent outside the facility is secured as follows: media sent outside the facility is logged, media is sent by secured courier or other delivery method that can be accurately tracked, and offsite tracking logs include details about media location.” (PCI DSS v4.0.1 Requirement 9.4.3)

Operator interpretation (what the assessor expects):

• You maintain an outbound media log covering every instance of CHD media leaving your facility. (PCI DSS v4.0.1 Requirement 9.4.3)
• You can show the delivery method was secured and trackable (for example, carrier tracking numbers and delivery confirmation). (PCI DSS v4.0.1 Requirement 9.4.3)
• Your offsite tracking log is not just “shipped.” It must include enough detail to determine the media’s location in transit and its destination status (for example, in-transit, delivered to named site, received by named person/role). (PCI DSS v4.0.1 Requirement 9.4.3)

Plain-English requirement

If you send any media that contains cardholder data outside your facility, you must:

1. record the shipment in a log,
2. ship it using a method you can track accurately, and
3. maintain an offsite tracking log that shows where the media is. (PCI DSS v4.0.1 Requirement 9.4.3)

Who it applies to (scope)

Entity types: Merchants, service providers, payment processors in scope for PCI DSS. (PCI DSS v4.0.1 Requirement 9.4.3)

Operational contexts where this shows up:

• Offsite storage or rotation of backups that contain CHD.
• Sending storage devices to a data center, disaster recovery site, or third party storage facility.
• Shipping physical records (printouts, letters, settlement reports) that include CHD.
• Sending replacement hardware that still contains CHD (for example, a drive shipped for repair) if the CHD is still present.

Practical scoping rule: If the media contains CHD and it leaves a facility you control, treat it as in scope for this requirement and run the chain-of-custody workflow. (PCI DSS v4.0.1 Requirement 9.4.3)

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

Step 1: Define “media with cardholder data” for your environment

Document what counts as media in your operations, then identify which of those can contain CHD. Keep it concrete:

• Removable electronic media (USB, external drives).
• Backup tapes/drives.
• Printed materials.
• Any other storage artifacts that can hold CHD.

Tie this definition to your data handling standard so staff do not improvise during shipping.

Step 2: Create a “No log, no ship” procedure

Write an SOP that makes logging a gating control: if it is not logged, it cannot leave the facility. The SOP should specify:

• Who can approve shipment.
• Who can package/release media.
• What log fields are mandatory.
• How tracking information is captured and reconciled.

Step 3: Implement the outbound media log

Use a register (ticketing system, GRC workflow, or controlled spreadsheet) with required fields that match the requirement language. At minimum, capture:

• Unique media identifier (asset tag or internal ID).
• Description of contents (avoid including CHD itself; record classification like “contains CHD”).
• Date/time released from facility.
• Sender facility and destination facility.
• Sender name/role and approver name/role.
• Courier/delivery method and tracking number.
• Packaging controls used (for example, tamper-evident seal ID).
• Expected delivery date and receipt confirmation status. These entries support “media sent outside the facility is logged” and create the backbone for tracking. (PCI DSS v4.0.1 Requirement 9.4.3)

Step 4: Use a secured courier or accurately trackable delivery method

Select carriers and services that provide reliable tracking events and delivery confirmation. The requirement is not satisfied by informal hand-carry without a trackable method unless you have an alternative that is “accurately tracked” and produces location details. (PCI DSS v4.0.1 Requirement 9.4.3)

Operationalize this with a courier standard:

• Approved couriers/services list.
• Minimum tracking capability (tracking number, scan events, delivery confirmation).
• Rules for exceptions and who can approve them.

Step 5: Maintain an offsite tracking log with media location details

This is commonly where programs fail. Your offsite tracking log must do more than store a tracking number; it must record “details about media location.” (PCI DSS v4.0.1 Requirement 9.4.3)

A workable approach:

• Mirror carrier scan events into your log at key milestones (picked up, in transit, out for delivery, delivered).
• Record receipt at destination with date/time and recipient identity (name or role, depending on your privacy rules).
• If media is stored offsite, record storage site name and internal location reference (vault ID, cabinet ID, or similar).

Step 6: Reconcile shipped vs. received (close the loop)

Add a reconciliation checkpoint:

• Shipment remains “open” until receipt is confirmed and logged.
• Escalation path if delivery is late, tracking is stale, or destination cannot confirm receipt.
• Incident workflow if media is lost or suspected compromised.

Step 7: Train the people who actually ship things

Train shipping/IT operations, records management, and any business unit that might send physical documents. Training should emphasize:

• The “No log, no ship” rule.
• How to select the correct shipping method.
• How to update the offsite tracking log and record receipt.

Step 8: Validate with periodic sampling

Run a recurring control test: sample outbound shipments and verify the log fields, tracking evidence, and documented location details match what happened. This makes your process assessable and keeps it from becoming a paperwork-only control. (PCI DSS v4.0.1 Requirement 9.4.3)

Where Daydream fits (practical): If you already run third-party risk and control evidence collection through Daydream, treat couriers and offsite storage providers as third parties and attach the outbound/offsite tracking logs, courier SLAs, and sampling results to the relevant control record. This reduces scramble during PCI evidence requests and helps correlate incidents with specific shipments.

Required evidence and artifacts to retain

Keep artifacts that let you prove all three parts of the requirement. (PCI DSS v4.0.1 Requirement 9.4.3)

Minimum evidence set (auditor-ready):

• Written procedure/SOP for media leaving the facility.
• Outbound media log entries for sampled shipments.
• Offsite tracking log showing location details through delivery/receipt.
• Carrier tracking pages/POD (proof of delivery) screenshots or exported tracking events tied to log entries.
• Approvals for shipment (ticket approvals, email approvals, workflow approvals).
• Receipt confirmations from destination (ticket closure, signed receiving log, or equivalent).
• Exception register (if you ever deviate) and corrective actions.

Common exam/audit questions and hangups

Auditors tend to test traceability and completeness. Expect questions like:

• “Show me the last several instances where CHD media left the facility and the corresponding log entries.” (PCI DSS v4.0.1 Requirement 9.4.3)
• “How do you know where the media is right now if it’s in transit?” (PCI DSS v4.0.1 Requirement 9.4.3)
• “What makes this courier ‘secured,’ and what tracking evidence do you retain?” (PCI DSS v4.0.1 Requirement 9.4.3)
• “What happens if a shipment is delayed or a tracking number stops updating?” (PCI DSS v4.0.1 Requirement 9.4.3)
• “How do you ensure all teams follow the same process?” (PCI DSS v4.0.1 Requirement 9.4.3)

Hangup to preempt: If your log only captures a tracking number and a ship date, many assessors will say you did not capture “details about media location.” Build location status fields and receipt confirmation into your log design. (PCI DSS v4.0.1 Requirement 9.4.3)

Frequent implementation mistakes (and how to avoid them)

1. Relying on the carrier website as the only “log.”
   Fix: maintain your own log that references carrier tracking and adds internal context (what, where, who). (PCI DSS v4.0.1 Requirement 9.4.3)

2. No unique identifier per media item.
   Fix: require an asset tag or shipment ID that follows the media from release to receipt.

3. “Delivered” without “received.”
   Fix: require destination confirmation in your tracking log and keep the shipment open until confirmed. (PCI DSS v4.0.1 Requirement 9.4.3)

4. Shadow shipping by business teams.
   Fix: publish a single intake path (service desk request) and train records/shipping staff to reject unlogged shipments.

5. Exception process that becomes the default.
   Fix: make exceptions rare, require security approval, and review exceptions for recurring root causes.

Enforcement context and risk implications

No public enforcement sources were provided for this specific requirement, so stick to the direct risk model. Loss of CHD media in transit creates two problems at once: potential exposure of cardholder data and inability to prove what data was affected if your logs are incomplete. Requirement 9.4.3 is designed to keep shipments accountable and traceable so you can prevent loss and respond decisively when something goes wrong. (PCI DSS v4.0.1 Requirement 9.4.3)

Practical execution plan (30/60/90-day)

First 30 days (stabilize and stop gaps)

• Identify all outbound CHD media workflows (IT backup rotation, records shipping, hardware repair returns).
• Publish an interim “No log, no ship” rule and a simple log template.
• Restrict shipping authority to named roles and require approvals.
• Select approved carriers/services that provide accurate tracking and delivery confirmation. (PCI DSS v4.0.1 Requirement 9.4.3)

By 60 days (standardize and make it auditable)

• Convert the log into a controlled workflow (ticketing/GRC) with mandatory fields.
• Add offsite tracking fields that clearly show media location and receipt status. (PCI DSS v4.0.1 Requirement 9.4.3)
• Implement reconciliation: open-to-close shipment status with escalation triggers.
• Train impacted teams and publish a one-page job aid.

By 90 days (prove it works)

• Run a control test: sample recent shipments, trace each from approval to receipt, and correct defects.
• Add exception reporting and management review.
• Bring third parties into view: confirm offsite storage providers’ receiving procedures and evidence expectations.
• Store artifacts in a single evidence location so PCI requests are painless (many teams map this directly in Daydream alongside third-party records and control evidence).

Frequently Asked Questions

Does this apply if the media is encrypted?

Yes. The requirement is about logging, trackable delivery, and offsite location tracking for media sent outside the facility. Encryption may reduce exposure risk, but it does not replace chain-of-custody controls. (PCI DSS v4.0.1 Requirement 9.4.3)

What counts as “media” under secure media distribution?

Treat any physical or electronic storage that contains cardholder data as media, including removable drives, backup media, and printed materials. If it can store CHD and it leaves your facility, run the process. (PCI DSS v4.0.1 Requirement 9.4.3)

Is a tracking number enough to satisfy “offsite tracking logs include details about media location”?

Often no. Keep the tracking number, but also record location/status milestones and final receipt details so you can answer “where is it now” without hunting through emails and carrier pages. (PCI DSS v4.0.1 Requirement 9.4.3)

Can staff hand-carry media to another office?

Only if you can accurately track the delivery and record media location details in your offsite tracking log. If you cannot produce reliable evidence of location and receipt, use a secured courier with tracking. (PCI DSS v4.0.1 Requirement 9.4.3)

What evidence do assessors usually request first?

A sample of recent outbound shipments, the associated media log entries, and the tracking/receipt proof that ties each shipment to a known location and destination. They also ask for the written procedure that defines the process. (PCI DSS v4.0.1 Requirement 9.4.3)

How do we handle shipments to a third party storage provider?

Treat the storage provider as a third party in your operational workflow: log the shipment, use trackable delivery, and require receiving confirmation that you can attach to the offsite tracking record. Keep the evidence tied to each shipment. (PCI DSS v4.0.1 Requirement 9.4.3)