Media Classification

PCI DSS requires you to classify every type of media that contains cardholder data based on the sensitivity of the data, then handle, store, transport, and destroy that media according to its classification. Operationally, you need a documented classification scheme, an inventory of media in scope, labeling or equivalent identification, and enforced handling procedures with evidence. (PCI DSS v4.0.1 Requirement 9.4.2)

Key takeaways:

• Define a clear media classification standard tied to cardholder data sensitivity and storage/handling requirements. (PCI DSS v4.0.1 Requirement 9.4.2)
• Maintain an inventory of all media types that can store cardholder data and apply classification consistently across teams and third parties. (PCI DSS v4.0.1 Requirement 9.4.2)
• Keep audit-ready artifacts: policy, inventory, samples of labels/records, procedures, training, and proof of enforcement. (PCI DSS v4.0.1 Requirement 9.4.2)

“Media classification” under PCI DSS is a practical control, not a paperwork exercise. Requirement 9.4.2 expects that you know where cardholder data can exist in “media” form (physical and electronic), that you have assigned those media a sensitivity classification, and that the classification drives how the media is handled across its lifecycle. (PCI DSS v4.0.1 Requirement 9.4.2)

For most organizations, the hard part is scope and consistency. Cardholder data can end up on paper reports, removable drives, laptops, backup tapes, virtual disks, screenshots, printed chargeback packets, call recordings, exported spreadsheets, and even logs. “Classified in accordance with sensitivity” means you need an organization-defined scheme that distinguishes media containing cardholder data from media that does not, and you need a repeatable way to apply that scheme so staff do not guess. (PCI DSS v4.0.1 Requirement 9.4.2)

This page translates the requirement into an implementable standard: define your classification model, map it to handling rules, apply it to an inventory of in-scope media, and retain evidence that proves the classification is real in daily operations.

Regulatory text

PCI DSS Requirement 9.4.2: “All media with cardholder data is classified in accordance with the sensitivity of the data.” (PCI DSS v4.0.1 Requirement 9.4.2)

Operator interpretation: what this means in practice

You must (1) identify the media that contains cardholder data, (2) assign it a defined classification level based on sensitivity, and (3) make the classification meaningful by linking it to required handling safeguards. If your teams cannot tell what is “in scope media with cardholder data” versus “non-sensitive media,” you will struggle to enforce storage, transport, access, retention, and destruction controls consistently. (PCI DSS v4.0.1 Requirement 9.4.2)

Plain-English requirement (what an assessor expects to see)

A PCI assessor will look for a classification standard that is:

• Documented: written definitions for classification levels and criteria for assigning them.
• Applied: media with cardholder data is actually marked or otherwise identified as such.
• Operationalized: procedures and staff behavior reflect the classification (for example, storage restrictions and secure destruction for the highest class). (PCI DSS v4.0.1 Requirement 9.4.2)

Who it applies to

In-scope entities

• Merchants
• Service providers
• Payment processors (PCI DSS v4.0.1 Requirement 9.4.2)

In-scope operational contexts

This requirement applies anywhere your environment can create, store, process, or transmit cardholder data, including:

• Corporate offices (paper records, printing, mailrooms)
• Contact centers (call recordings, notes, QA exports)
• IT operations (backups, snapshots, removable media, admin exports)
• Finance/chargebacks (spreadsheets, dispute packets)
• Third parties handling your cardholder data media (e.g., offsite storage, shredding, managed print services)

If a third party touches media containing your cardholder data, your classification and handling rules must extend to them through contract requirements and oversight, because the media still belongs to your PCI scope. (PCI DSS v4.0.1 Requirement 9.4.2)

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

Step 1: Define your media classification scheme

Create a small set of classes that a non-expert can apply consistently. A common, workable structure:

• CHD-Restricted: any media containing cardholder data (including PAN with any other card data elements).
• CHD-Authorized: media containing cardholder data that is already protected by strong controls (for example, encrypted backups) and is approved for limited operational use.
• Public/Internal: media that does not contain cardholder data.

Keep the scheme simple. The requirement is satisfied by “classified in accordance with sensitivity,” so your definition should clearly treat “contains cardholder data” as high sensitivity and force stronger handling. (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverable: Media Classification Standard (policy-level document) with:

• Definitions of each class
• How to determine class (decision rules)
• Owner of the standard and exception process
• Mapping from class → minimum handling requirements (see Step 3)

Step 2: Build and maintain a media inventory (in PCI scope)

Make a list of media types and specific repositories where cardholder data could exist. Include both physical and electronic media. At minimum, capture:

• Media type (paper, removable drive, laptop, backup tape, virtual disk, cloud object storage export, etc.)
• Location/system owner
• Contains cardholder data? (yes/no/unknown)
• Classification level
• Storage method (locked cabinet, encrypted storage, offsite vendor, etc.)
• Retention and destruction method

Reality check: “unknown” items are audit magnets. Treat them as high risk until validated, and document your validation steps. (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverable: Media Inventory Register (spreadsheet, CMDB entries, or GRC system record).

Step 3: Translate classification into handling rules people can follow

Your classification must drive behavior. Write handling standards that are short, explicit, and testable:

• Storage: where the media may be stored (e.g., locked storage for paper; encrypted volumes for electronic media).
• Access: who may access, how approval works, and what logs exist.
• Transport: how media may be moved (courier controls, tamper-evident packaging, chain of custody).
• Copying/printing: when allowed, and what safeguards apply.
• Retention: how long it can be kept and where retention is recorded.
• Destruction: required destruction method and proof requirements.

You do not need to over-engineer the rule set; you need to make it enforceable and aligned to the sensitivity you defined. (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverable: Media Handling Procedure (procedure-level document) mapped to each classification.

Step 4: Apply classification in the field (labeling or equivalent identification)

For physical media, labeling is often the cleanest control:

• Stamp/label printed reports and folders that contain cardholder data.
• Use pre-printed “Restricted” cover sheets for common workflows (chargebacks, settlements, call QA packets).
• Label storage containers (lockboxes, archive boxes) when contents are consistently restricted.

For electronic media, “labeling” may be implemented through system metadata and access controls:

• Folder/bucket naming standards and tags
• CMDB attributes
• Encryption requirements enforced by configuration for specific repositories
• Data loss prevention rules keyed to cardholder data patterns

Key point: your approach must let an auditor trace “this media contains cardholder data” → “it is classified” → “it was handled under the correct rules.” (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverables: Labeling standard, sample labels/screenshots, and evidence of rollout.

Step 5: Train the teams that create and move media

Target training to roles that touch media:

• Call center supervisors and QA
• Finance and disputes
• IT operations and backup admins
• Facilities/mailroom
• Any teams that ship, store, or destroy media

Training content should be scenario-based: “If you export transactions to a spreadsheet, what class is it and where can it be stored?” (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverables: training deck, attendance records, and a short knowledge check.

Step 6: Extend requirements to third parties handling your media

If a third party stores or destroys media containing your cardholder data, contract terms should require:

• Classification handling consistent with your standard
• Chain-of-custody and destruction certification
• Right to audit or receive independent assurance artifacts

In Daydream, many teams track these obligations as third-party requirements mapped to PCI DSS controls so renewal reviews and evidence collection stay consistent year over year. (PCI DSS v4.0.1 Requirement 9.4.2)

Deliverables: contract clauses, third-party SOPs, due diligence records, and destruction certificates.

Step 7: Monitor and test classification in operations

Build lightweight checks:

• Spot-check a sample of printed outputs from in-scope systems for correct labeling and storage.
• Review backup job targets to confirm encrypted destinations and correct classification in inventory.
• Validate that “restricted” media destruction produces certificates and is recorded.

Deliverables: inspection checklists, findings log, and remediation tickets.

Required evidence and artifacts to retain

Maintain an assessor-ready evidence set:

• Media Classification Standard (policy) (PCI DSS v4.0.1 Requirement 9.4.2)
• Media Handling Procedures (storage/transport/retention/destruction) (PCI DSS v4.0.1 Requirement 9.4.2)
• Media inventory/register with owners and classifications (PCI DSS v4.0.1 Requirement 9.4.2)
• Samples: photos of labeled physical media, screenshots of electronic tags/metadata, example restricted templates (PCI DSS v4.0.1 Requirement 9.4.2)
• Training materials and completion records for relevant roles (PCI DSS v4.0.1 Requirement 9.4.2)
• Third-party contracts/SOW language and oversight artifacts for media storage/destruction providers (PCI DSS v4.0.1 Requirement 9.4.2)
• Operational records: chain-of-custody logs, destruction certificates, exception approvals, and periodic spot-check results (PCI DSS v4.0.1 Requirement 9.4.2)

Common exam/audit questions and hangups

Expect these lines of inquiry:

1. “Show me your classification definitions. How do staff decide?” If the answer is “they know,” you will lose time in the audit. (PCI DSS v4.0.1 Requirement 9.4.2)
2. “List all media types that can contain cardholder data.” Assessors often test completeness by asking about edge cases like screenshots, exports, and backups. (PCI DSS v4.0.1 Requirement 9.4.2)
3. “Prove it’s applied.” They will ask for samples across departments, not just IT. (PCI DSS v4.0.1 Requirement 9.4.2)
4. “How do you control media at third parties?” Shredding and offsite storage vendors are frequent gaps. (PCI DSS v4.0.1 Requirement 9.4.2)
5. “Where is the evidence of destruction?” Certificates without clear linkage to the specific media batches can become a hangup. (PCI DSS v4.0.1 Requirement 9.4.2)

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating classification as a data governance label only. Fix: map each class to required handling rules and train people on the rules. (PCI DSS v4.0.1 Requirement 9.4.2)
• Mistake: Only classifying paper and forgetting electronic “media.” Fix: explicitly include removable media, backups, images, exports, and virtual storage in the inventory. (PCI DSS v4.0.1 Requirement 9.4.2)
• Mistake: No clear owner. Fix: assign a control owner for the classification standard and require periodic review tied to system changes. (PCI DSS v4.0.1 Requirement 9.4.2)
• Mistake: Exceptions become the default. Fix: require time-bound exception approvals with compensating controls and evidence. (PCI DSS v4.0.1 Requirement 9.4.2)
• Mistake: Third-party destruction without traceability. Fix: require chain of custody and certificates that reference dates, container IDs, or pickup tickets you can map back to internal records. (PCI DSS v4.0.1 Requirement 9.4.2)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak media classification increases the chance that cardholder data ends up in uncontrolled locations (shared drives, unencrypted backups, printed packets), which then undermines physical security, retention, and secure destruction controls that depend on knowing what is sensitive. (PCI DSS v4.0.1 Requirement 9.4.2)

Practical 30/60/90-day execution plan

First 30 days (foundation)

• Assign an accountable owner and confirm in-scope departments and third parties.
• Draft the Media Classification Standard and the first version of the Media Inventory Register.
• Identify the top workflows that generate media with cardholder data (printing, exports, backups).

By 60 days (operational rollout)

• Publish handling procedures mapped to each classification level.
• Roll out labeling (physical) and tagging/metadata standards (electronic) for the highest-risk workflows first.
• Add third-party contract requirements for any media storage/destruction providers coming up for renewal; document compensating controls where contracts cannot change quickly.

By 90 days (prove it works)

• Run spot checks across at least one business unit and one IT workflow; track findings to closure.
• Collect an evidence packet: labeled samples, inventory extracts, training records, and third-party certificates.
• Move ongoing tracking into a system of record (many teams use Daydream to track control owners, evidence, and third-party obligations in one place). (PCI DSS v4.0.1 Requirement 9.4.2)

Frequently Asked Questions

Does “media” mean only paper and backup tapes?

No. Treat media as any physical or electronic medium that can store cardholder data, including exports, removable drives, endpoints, and backups. Your inventory should make those explicit. (PCI DSS v4.0.1 Requirement 9.4.2)

Do we have to physically label every printed page with cardholder data?

PCI DSS 9.4.2 requires classification, not a specific labeling method. Labeling is a common way to prove classification for physical media, but you can also use controlled templates, cover sheets, and documented storage rules if they are consistently enforced. (PCI DSS v4.0.1 Requirement 9.4.2)

How detailed does the classification scheme need to be?

Keep it as simple as you can while still driving handling requirements. Most teams do fine with a small set of classes that clearly separates “contains cardholder data” from “does not,” plus any internal nuance you need for encrypted/approved repositories. (PCI DSS v4.0.1 Requirement 9.4.2)

What’s the minimum evidence an assessor will ask for?

Expect to produce your classification standard, a media inventory showing classification, and samples proving the classification is applied in daily workflows. Add training and third-party artifacts if external parties handle storage or destruction. (PCI DSS v4.0.1 Requirement 9.4.2)

How do we handle “unknown” media where we’re not sure if cardholder data exists?

Treat it as sensitive until you validate it. Document the investigation method, results, and any remediation such as cleanup, access restriction, or secure destruction. (PCI DSS v4.0.1 Requirement 9.4.2)

Our third-party shredder gives certificates, but they don’t list what was destroyed. Is that enough?

It often becomes an audit friction point because you need traceability. Improve your internal chain-of-custody records (container IDs, pickup tickets) so the certificate can be linked back to specific batches of classified media. (PCI DSS v4.0.1 Requirement 9.4.2)