Prevent PAN Copy via Remote Access

PCI DSS 4.0.1 Requirement 3.4.2 means your remote-access setup must technically block staff from copying or moving Primary Account Number (PAN) data off the remote session, unless a person has explicit written authorization and a documented business need. Operationalize it by enforcing controlled virtual access paths, restricting clipboard/drive/print/redirection, and proving the exceptions process. (PCI DSS v4.0.1 Requirement 3.4.2)

Key takeaways:

• Treat “remote access” as a high-risk exfiltration path; block copy/relocation of PAN by design, not by policy.
• Allow exceptions only with named authorization, defined business need, and compensating technical controls.
• Evidence must show settings, testing, and monitoring that prevent PAN transfer via clipboard, file transfer, local drives, and printing.

“Prevent PAN copy via remote access” is a very specific requirement with a very specific failure mode: someone remote-connects to an environment that can display or handle PAN, then copies PAN out of that environment to an unmanaged endpoint, local storage, screenshots, files, or print paths. PCI DSS 4.0.1 Requirement 3.4.2 requires technical controls that stop that copy/relocation for all personnel by default, and it allows exceptions only when you can prove explicit authorization and a legitimate, defined business need. (PCI DSS v4.0.1 Requirement 3.4.2)

For a CCO or GRC lead, the fastest way to operationalize this requirement is to (1) map which remote-access technologies touch PAN, (2) choose an approved remote access pattern for PAN work (often via hardened jump hosts or virtual desktops), (3) disable common exfiltration channels (clipboard sync, drive mapping, file transfer, print redirection, screen capture where feasible), and (4) implement an exceptions workflow with access reviews and session monitoring.

This page gives requirement-level implementation steps, exam-ready evidence to retain, and the common audit hangups that cause teams to fail this control.

Regulatory text

Requirement: “When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.” (PCI DSS v4.0.1 Requirement 3.4.2)

Operator interpretation (plain English):

• If a user can reach a system handling or displaying PAN through any remote-access method, you must configure that remote-access method to prevent PAN from being copied or moved off the remote system/session.
• “Technical controls” means enforced settings and architecture, not a “do not copy PAN” policy.
• Exceptions are allowed, but only for named people with written authorization and a defined, legitimate business need, and you still need tight controls around how that copying happens. (PCI DSS v4.0.1 Requirement 3.4.2)

Who this applies to

Entities in scope:

• Merchants, service providers, payment processors in a PCI DSS assessment boundary where PAN is stored, processed, or transmitted. (PCI DSS v4.0.1 Requirement 3.4.2)

Operational contexts that trigger the requirement:

• Remote administration into the cardholder data environment (CDE) or connected systems.
• Remote customer support where PAN is visible in ticketing tools, consoles, logs, call-center desktops, or admin portals.
• Third party access (consultants, outsourced IT, BPO/call center) into environments that can access PAN.
• Hybrid work where employees access PAN-handling applications via VPN, VDI, RDP, SSH jump boxes, remote support tools, or browser-based consoles.

Remote-access technologies to inventory (examples):

• VPN + RDP/SSH
• VDI / DaaS
• Remote support tools
• Bastion/jump hosts
• Cloud console access paths that provide interactive access to hosts or databases

Your assessor will generally treat any “interactive session from outside the controlled environment” as a remote-access technology in practical terms, then ask how you prevent PAN transfer out of that session.

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

Step 1: Define the “PAN remote access” boundary

1. List systems/applications where PAN can be viewed, queried, exported, or appears in logs.
2. Identify all remote-access paths to those systems (employee, admin, and third party).
3. Record the technology and where control is enforced: endpoint agent, remote tool settings, gateway/bastion, VDI policy, DLP, or OS policy.

Deliverable: Remote-access data flow map for PAN touchpoints, plus a control ownership matrix.

Step 2: Standardize on approved remote access patterns for PAN work

Pick one of these patterns and make it your default:

Pattern A: VDI/virtual apps for PAN viewing

• Users connect to a managed virtual desktop.
• PAN is only accessible inside the virtual session.
• Exfiltration controls are enforced at the VDI policy layer.

Pattern B: Hardened jump host / bastion

• Users connect to a controlled jump host.
• From there, they access CDE systems.
• Disable session features that allow copy/relocation.

Pattern C: Controlled web access to PAN apps

• Browser access from managed devices with strong endpoint controls.
• Restrict download/export features and apply DLP.

You can support more than one pattern, but your evidence burden grows with each one.

Step 3: Disable the common “copy/relocation” channels in remote sessions

For each remote technology used to access PAN, explicitly address these channels:

Exfiltration channel	What to block or control	Evidence you’ll need
Clipboard sync	Disable copy/paste between local and remote	Config screenshots/exports; policy objects; tool settings
Drive mapping / folder redirection	Disable mapping local drives into session; block write access to local volumes	Remote tool policy; OS/VDI policy; test results
File transfer features	Disable built-in file transfer	Tool configuration; admin console export
Print redirection	Disable printing to local printers; restrict to secure print in controlled locations	Print policy; VDI settings; test results
Downloads/exports from apps	Restrict export functions; require approvals; log exports	App config; role permissions; logs
Screen capture	Where feasible, restrict screenshot tools on managed endpoints; monitor for capture	Endpoint policy; SOC detections; exception handling

The requirement is outcome-based: technical controls must prevent copy/relocation of PAN through remote access for most personnel. Your control set should cover the practical routes above. (PCI DSS v4.0.1 Requirement 3.4.2)

Step 4: Build an explicit authorization + business need exception process

The exception clause is narrow. Treat it like privileged access.

1. Define what qualifies (e.g., chargeback operations requiring PAN to be placed into a specific approved system).
2. Require written approval from the data owner and security/compliance.
3. Limit scope: specific users, systems, and time window; no blanket group approvals.
4. Add compensating technical controls for exception users, such as:
   • Stronger session monitoring/recording for their remote sessions
   • Step-up authentication
   • More restrictive endpoints (managed, encrypted, no local admin)
   • DLP rules focused on PAN patterns leaving the session
5. Review exceptions on a defined cadence and remove when the business need ends.

Deliverable: Exception register with approver, business justification, scope, start/end, and linked evidence. (PCI DSS v4.0.1 Requirement 3.4.2)

Step 5: Validate the control with negative testing

Auditors frequently ask “show me it’s blocked.” Do hands-on tests:

• Attempt copy/paste of PAN-like strings from remote to local.
• Attempt local drive mapping and file writes.
• Attempt printing to a local printer.
• Attempt “export” from the PAN application to local.

Capture:

• Test plan
• Tester identity/role
• Date/time
• Outcome screenshots or screen recording (redact any sensitive data)

Step 6: Monitor and respond

Even with prevention controls, you should detect attempted violations.

• Log remote session connections (user, source, target, time).
• Alert on use of blocked features (where the tool supports it).
• Monitor for atypical exports/downloads in PAN apps.
• Investigate exception-user activity with higher scrutiny.

Required evidence and artifacts to retain

Keep evidence in a form an assessor can evaluate quickly:

Governance

• Remote access standard for PAN systems describing the approved patterns and prohibited features
• Exception procedure and approval workflow
• Exception register with explicit authorization + business need documentation (PCI DSS v4.0.1 Requirement 3.4.2)

Technical configuration

• Remote access tool policy exports (clipboard, drive, file transfer, print settings)
• VDI policy objects or configuration exports showing restrictions
• Jump host hardening evidence (policy settings, access methods, allowed tooling)

Operations

• User access lists for remote access to PAN systems
• Change tickets for enabling/disabling restricted features
• Testing evidence (negative tests demonstrating prevention)
• Monitoring/alerting documentation and sample logs for remote sessions

Common exam/audit questions and hangups

Expect these, and pre-package answers:

1. “Which remote-access technologies are used to access PAN?”
   Have a single inventory and show where each control is enforced.

2. “Show me that a standard user cannot copy PAN out.”
   Provide test evidence, plus the configuration that makes it impossible. (PCI DSS v4.0.1 Requirement 3.4.2)

3. “Who is authorized to copy PAN and why?”
   Produce the exception register with explicit authorization and business need. (PCI DSS v4.0.1 Requirement 3.4.2)

4. “How do you control third party remote access?”
   Show that third parties use the same restricted path, with unique IDs and scoped access. If you treat third parties differently, explain the compensating controls.

5. “Does VPN alone satisfy this?”
   VPN is transport security, not copy/relocation prevention. Be ready to show the session controls that prevent transfer.

Frequent implementation mistakes and how to avoid them

• Mistake: Relying on policy language (“employees must not copy PAN”).
  Fix: enforce blocking controls in the remote technology. The requirement explicitly calls for technical controls. (PCI DSS v4.0.1 Requirement 3.4.2)

• Mistake: Only disabling clipboard, ignoring drive mapping and printing.
  Fix: treat exfiltration as multi-channel; document each channel and how you block it.

• Mistake: Broad exception groups (“Support Team” can copy PAN).
  Fix: name individuals, document business need, scope access, and review regularly. (PCI DSS v4.0.1 Requirement 3.4.2)

• Mistake: Allowing third party remote support tools with file transfer enabled “temporarily.”
  Fix: use a controlled tool profile with file transfer always disabled; require a formal break-glass for true emergencies.

• Mistake: No proof.
  Fix: keep exported configs and repeatable test scripts so the assessor doesn’t have to “trust” your narrative.

Enforcement context and risk implications

This requirement exists because remote access is a common exfiltration path: it bridges controlled environments (CDE/secure networks) and less-controlled endpoints (home devices, contractor laptops, unmanaged machines). If remote tooling allows clipboard sync, file transfer, drive mapping, or print redirection, PAN can leave the CDE quickly, and incident response becomes harder because data may spread across endpoints and personal storage. PCI DSS frames the required response as “technical controls prevent” with narrow exceptions, so assessors will treat gaps as control failures rather than documentation issues. (PCI DSS v4.0.1 Requirement 3.4.2)

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the obvious gaps)

• Complete inventory of remote-access paths into PAN-capable systems.
• Pick the default access pattern (VDI, jump host, or controlled web access) and publish a short standard.
• Disable clipboard sync, file transfer, drive mapping, and print redirection in the main remote tool profiles used for PAN access.
• Stand up an exceptions register and require explicit approvals for any temporary allowances. (PCI DSS v4.0.1 Requirement 3.4.2)

By 60 days (prove prevention and tighten exceptions)

• Run and document negative testing against each remote-access technology in scope.
• Migrate remaining PAN access to the approved patterns; deprecate “ad hoc” remote tools.
• Add enhanced monitoring for exception users and for high-risk actions (exports, unusual access patterns).
• Conduct the first access and exceptions review; remove stale entries. (PCI DSS v4.0.1 Requirement 3.4.2)

By 90 days (operationalize and make it audit-repeatable)

• Bake remote-access restrictions into configuration baselines and change management.
• Ensure third party access uses the same restricted patterns, with contract language that prohibits alternative remote tooling for PAN systems.
• Create an assessor-ready evidence pack: configs, tests, exception approvals, and monitoring samples.
• If you manage this work in Daydream, maintain a single control record with mapped systems, owner, evidence requests to IT, and an exceptions workflow so nothing lives in email.

Frequently Asked Questions

Does this requirement apply if PAN is only displayed (not stored) in the remote session?

Yes, if personnel can view PAN through remote access, the remote-access technology must prevent copying/relocation of PAN out of that session for non-exception users. The trigger is access to PAN, not just storage. (PCI DSS v4.0.1 Requirement 3.4.2)

Is disabling copy/paste enough to satisfy “prevent copy and/or relocation of PAN”?

Usually not by itself. Auditors commonly expect you to also address file transfer, local drive mapping, and print redirection because those are equally direct relocation paths for PAN. (PCI DSS v4.0.1 Requirement 3.4.2)

Can we allow a small team to copy PAN if they have a business need?

Yes, but only with documented, explicit authorization and a legitimate, defined business need. Keep it person-specific, scope-limited, and supported by additional technical controls and monitoring. (PCI DSS v4.0.1 Requirement 3.4.2)

How do we handle third party contractors who need remote access into PAN systems?

Put them on the same restricted remote-access pattern as employees, and require unique user IDs, scoped permissions, and logging. If they request file transfer or clipboard access, route it through the exception process with explicit authorization. (PCI DSS v4.0.1 Requirement 3.4.2)

What evidence is most persuasive to an assessor for this requirement?

Configuration exports showing blocked features plus negative test results that demonstrate a user cannot copy/transfer PAN out of the remote session. Pair that with an exception register for any authorized users. (PCI DSS v4.0.1 Requirement 3.4.2)

We use VPN to access an internal PAN application from corporate laptops. Does that count as remote access technology?

Treat it as in scope if personnel connect from outside your controlled environment or if the VPN provides remote connectivity into PAN-capable systems. VPN alone does not prevent copy/relocation; you still need technical controls at the session/app/endpoint layers. (PCI DSS v4.0.1 Requirement 3.4.2)