PCI DSS 3.4 PAN display and copy restrictions

What PCI DSS 3.4 asks for and why it is hard to meet

Requirement 3.4 has two parts, and an assessor will test them separately. Requirement 3.4.1 governs masked display, meaning how much of a PAN appears on screens, receipts and reports. Requirement 3.4.2 governs copy and relocation, meaning the technical controls that stop PAN being copied or moved through remote-access technologies unless someone is explicitly authorized. Assessors usually ask both questions in the same walkthrough: what does an agent see on the payment screen, and what happens when that agent starts a remote session? The distinction between masking and truncation matters here. Masking hides digits when PAN is displayed, while truncation permanently removes digits from stored PAN. The PCI SSC's FAQ 1146 explains this difference, and the answer for 3.4 is that display is about hiding digits, not deleting them. The FAQ 1492 guidance on 8-digit BINs also applies, so confirm with your assessor how many leading digits your masking rules expose when the BIN is longer than the usual six. The work is hard because PAN appears in many places that do not share one configuration. Checkout applications, customer service tools, back-office consoles, printed receipts, exported reports and support ticket attachments each need their own masking logic. Remote-access tooling adds a second surface: screen sharing, clipboard sync and file transfer can move PAN out of the cardholder data environment without any application change. Since 3.4.2 became a required control on 31 March 2025 under PCI DSS v4.0.1, the support desk and the remote-access platform need the same scrutiny as the application. Start by listing every place PAN is rendered and every remote tool that can reach those screens.

Which screens, reports, people and tools fall under 3.4

Requirement 3.4 applies wherever full PAN can appear, not just in the database. The cards below walk through the places where card numbers surface in a payment environment and the scoping decisions that change how much work each one creates. Start by confirming which of these places actually display or move PAN in your environment.

Customer and agent screens

Checkout pages, stored-card selectors, order detail views and agent consoles are the most common places PAN is shown. Requirement 3.4.1 asks that only personnel with a legitimate business need see more than the BIN and last four digits, so each role that opens these screens needs a documented reason and a masked default. Check whether any screen renders the full number in the page source, a hover state, a print preview or a tooltip, because those paths are easy to miss in a review.

Printed and emailed receipts

Receipts, invoices and confirmation emails are often generated by a separate template or print service that nobody reviews during an application audit. Confirm which template fields pull the card number and whether the masking rule is applied at render time or only in the front end. The SAQ D note for Requirement 3.4.1 does not override stricter legal or payment brand rules for receipts, so check those rules for each region and card brand you accept before finalizing the template.

Operational and finance reports

Settlement files, reconciliation exports, fraud review queues and BI dashboards frequently carry PAN in clear text because they were built for matching transactions. Inventory every scheduled report and export, the recipients and the storage location of each file. Where a report only needs to match transactions, ask whether a token or the masked form can replace the full number, and confirm who can open the exported files on shared drives.

Support and call-center tools

Support staff often need to look up a card to resolve a dispute or refund, and ticketing systems, CRM notes and call recording tools can capture the number they read aloud or paste into a field. Confirm that the support console displays only masked PAN by default, that any reveal action is restricted to named roles, and that ticket attachments and free-text notes are checked for stray card data. Call recordings and transcripts are a separate question to confirm with your assessor.

Remote-access and screen-sharing tools

Requirement 3.4.2 requires technical controls that prevent copying or moving PAN through remote-access technologies, except for personnel explicitly authorized to do so. Remote desktop, screen sharing, remote-assistance tools and virtual desktops can all copy a visible number to a local clipboard or file. Identify which tools support clipboard, file transfer and drive mapping, disable those features for in-scope users, and record which exceptions are authorized and why.

Scoping decisions that change the work

Whether a system displays PAN at all is the first decision. A payment page that hands the card straight to a hosted provider may never render the full number inside your environment, which can remove a screen from the masking work entirely, though you should confirm that with your assessor and the provider's responsibility matrix. Likewise, a back-office tool that only receives tokens has nothing to mask. Document each system with a yes or no answer and the evidence behind it.

How an assessor tests PAN display and copy controls

This table compares each test area an assessor covers for Requirement 3.4, what they examine, the evidence they ask for and the findings they most often write up. Read it as a preparation checklist: if you cannot produce the evidence in the right-hand columns for each area, expect questions during fieldwork.

Test area	What the assessor examines	Evidence requested	Common findings
Masked display samples	Whether screens, receipts and reports show no more than the BIN and last four digits to users without a legitimate business need	Screenshots or exports from each user role, system configuration showing the masking rule, and the list of sampled screens	Full PAN visible on a customer service screen or in a report layout that was never reviewed for masking
Role-based access to unmasked views	Which roles can see more than the BIN and last four digits, and whether that access matches documented business need	Role definitions, access rights for each role, approval records for unmasked access and recent access review results	Broad support or operations roles inherit unmasked views by default, with no documented justification
Receipt and report samples	Printed and emailed receipts, settlement and operational reports, and dashboards that may contain PAN	Sample receipts from each point-of-sale or payment channel, report templates and export logs	Receipts or reports carry full PAN, or a stricter legal or payment brand rule for receipts is not applied
Exports and data extracts	Whether CSV, spreadsheet, log or ticket exports strip or mask PAN before leaving the system	Export configuration, sample files from recent extracts and the data handling procedure for analysts	Unmasked PAN in exports sent to analysts, shared drives or third-party tools
Remote-access configuration	Whether remote sessions block copy, paste, file transfer and drive mapping of PAN, with exceptions limited to authorized personnel	Remote-access policy settings, screenshots or configuration exports for clipboard, file transfer and drive redirection controls, and the list of users with exceptions	Unrestricted clipboard use or drive mapping in virtual desktop or remote support tools that reach the cardholder data environment
Authorization records for exceptions	Whether each exception to masking or copy restrictions has a named owner, business reason and approval	Signed approvals, the access request ticket, expiry or review dates and evidence that the exception was reviewed	Exceptions granted verbally or in chat, with no record of approval or end date
Interview and walkthrough	Whether staff who handle PAN can explain the masking and copy rules and where to find them	Walkthrough notes, staff training records and the procedure the assessor reviewed	Staff unaware that copying PAN into tickets or messages is restricted

How to implement 3.4 in sequence

This sequence moves a team from knowing where PAN appears to proving that display, copy and remote-access controls work as intended before an assessor arrives. Each step produces a record that the next step depends on.

Inventory every place PAN appears
Start by listing every screen, printed receipt, report, export file, log extract, support tool and API response that can show or carry full PAN. Include staging copies and reports sent to finance or call center teams, not only the main application. Work from the data-flow diagram and the cardholder data environment scope so nothing sits outside the review. The output is a display and export inventory with an owner, a source system and a note on whether each item shows full PAN today. The step is done when application owners have confirmed their entries and no known location is missing.
Define roles that need more than masked PAN
For each item in the inventory, decide which job roles have a documented legitimate business need to see more than the BIN and last four digits. Most teams find that this list is short, and that customer service, operations and developers usually do not need the full number. Record the justification for each role, the systems it applies to and who approves it. The output is a role matrix that maps roles to permitted displays. Ask your QSA or internal assessor to review the matrix early, because the reasoning behind each grant is what they will test.
Enforce masking at the application or data layer
Configure masking so that PAN is hidden by default in every interface, and only roles in the matrix see more. Decide whether masking happens in the application code, in a shared display service or in the data layer, and confirm it applies to exports and API responses as well as on-screen views. Be aware that masking differs from truncation: masking hides digits when displayed, while truncation removes them from stored data, which is covered under Requirement 3.5. The output is configuration records and code references for each masked location. Confirm with your platform team that masking cannot be bypassed by a direct database query or an unmasked report template.
Restrict copy and relocation through remote access
Identify every remote-access path into the cardholder data environment, including remote desktop, virtual desktop, screen-sharing and support tools. Configure them to block clipboard copy, file transfer and drive mapping of PAN for anyone not explicitly authorized, and disable session recording features that would capture unmasked screens where policy does not allow it. Where the platform is self-hosted, verify these settings in the platform's own configuration rather than relying on user training. The output is a remote-access configuration record for each tool, showing which controls are on and which roles are excepted. Ask the vendor to confirm which of these controls the product supports natively before you assume they exist.
Document authorized exceptions and approvals
Where a role must copy PAN or see it unmasked, record a formal exception with the business reason, the scope, the compensating safeguards and the named approver. Exceptions should expire or be reviewed on a defined schedule, and access to them should appear in your regular access review process. Link each exception to the role matrix so the two records agree. The output is an exception register with approvals attached. Assessors frequently look for exceptions that exist in practice but not on paper, so reconcile the register against the configuration records and access logs before the test phase.
Test with sample screens and reports
Before the assessment, test each inventoried item using test accounts that represent each role in the matrix. Capture screenshots, exported files and remote-session attempts to show what each role can see and copy, and confirm that unauthorized roles see only the permitted digits. Include the masking rules that apply to receipts, since the standard's requirement does not override stricter payment brand or legal rules for point-of-sale displays. The output is a test log with dates, tester names, results and retest records for any failure. Keep this log with the evidence set for your assessment, and retest after any change to the application or remote-access tools.

Evidence that passes 3.4 and how to keep it current

An assessor testing Requirement 3.4 looks for proof that PAN is masked for the right people and that copy or transfer through remote access is blocked. The artifacts below connect what the business intends with what systems actually show, and each one needs a named owner and a trigger for review.

PAN display inventory

This is the list of every screen, receipt template, report, export, API response and log view that can show a full PAN. It is the starting point for 3.4.1, because an assessor cannot confirm masking on a surface nobody recorded. For each entry, note the system, the owner, the roles that can reach it and the masking rule applied. Refresh it whenever a new screen, report or integration goes live, and during every change that touches the cardholder data environment.

Role-to-view matrix

This matrix maps each job role to the PAN views it may use, showing masked output by default and the narrow exceptions tied to a documented business need. It is the evidence that only personnel with a legitimate business need see more than the BIN and last four digits. Review it when roles are created, changed or retired, and at least on the schedule your access review process already uses. Ask whether support, finance and call-center roles have been checked separately, since these often gain broader views informally.

Masked and unmasked screen captures

Dated screen captures from each in-scope application, taken under the roles listed in the matrix, show what each role actually sees. Pair a masked capture with an unmasked capture only where a role is authorized for full PAN, and record the account used. Captures go stale after any interface change, so retake them as part of release testing rather than waiting for the assessment. Confirm that captures never leave the cardholder data environment through screenshot tools or shared drives.

Receipt and report samples

Samples of printed and emailed receipts, settlement reports, dispute files and customer statements show whether masking holds outside the application. Requirement 3.4.1 does not override stricter legal or payment brand rules for displays, such as rules for point-of-sale receipts, so check those rules before choosing the masking format. Keep one sample per template and retain prior versions when a template changes. Ask your acquirer or payment brand which receipt rules apply in your markets.

Remote-access copy and transfer controls

Requirement 3.4.2 requires technical controls that prevent copying or moving PAN through remote-access technologies unless the person is explicitly authorized. The evidence is the remote-access policy plus configuration exports from the remote-access platform, showing clipboard, file transfer, print redirection and drive mapping restrictions for sessions that can reach the cardholder data environment. Export the settings on a schedule and after every platform upgrade, and test one blocked copy attempt so the export matches observed behavior. Confirm that the settings cover every remote-access tool in use, including vendor support tools.

Exception register with approvals

Where a role needs full PAN for a documented reason, or where a copy restriction cannot be applied, the exception register records the request, the business justification, the compensating or limiting controls, the approver and the review date. Assessors check that each exception is approved, time-bound and actually in use, so remove access when a need ends. Review the register at each quarterly access review and whenever a related system changes. Keep approvals in a system the approver cannot edit after the fact.

Self-hosted identity and access tooling

Self-hosted identity tools can help generate role evidence by centralizing who holds which role and by documenting approval decisions. authentik acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, and midPoint runs access certification campaigns in which designated reviewers keep, change or revoke access items. Confirm with each vendor which of these capabilities fits your application landscape before you rely on it for evidence.

What meeting 3.4 costs in money and effort

This table breaks down the money and effort behind Requirement 3.4 by cost component, showing who is paid, whether the cost is one-time or recurring, what drives it, and how to reduce it. No prices or durations are given because a quote follows from written scope, so use the table to frame questions for that quote. The main takeaway is that open-source platforms remove license spend but not the engineering and evidence work.

Cost component	One-time or recurring	What drives it	How to reduce it
Masking configuration in applications and reports	One-time build, then recurring change control	Number of screens, receipts, exports, and print templates that show PAN	Centralize masking in one shared service or template library so each new view inherits it
Role design for PAN visibility	One-time design, recurring updates	Count of job roles that touch PAN and how many legitimate business needs exist	Map roles to the minimum display need first, then reuse the matrix across systems
Access reviews of PAN-visible roles	Recurring	Frequency set in your policy, number of reviewers, and size of the role catalog	Automate review campaigns with designated reviewers and clear revoke decisions
Remote-access controls to block copy or relocation	One-time configuration, recurring licensing where commercial tools apply	Number of remote-access paths, session tools in use, and whether clipboard, file transfer, or screen capture is blocked	Consolidate remote access through one gateway and confirm which tools are already licensed
Open-source tooling licenses	Usually no license fee, but hosting and support are recurring	Choice of identity, access, and session components and the infrastructure they run on	Confirm license terms with each project and budget for hosting and maintenance instead
Engineering effort to integrate and maintain	One-time integration, recurring maintenance	Legacy applications, custom code paths, upgrade cycles, and staff skills	Scope integrations in phases and track masking exceptions in a single register
Testing effort	Recurring with each release	Number of display paths, regression scope, and whether masking is tested with real-format test data	Automate masking checks in the pipeline and keep a fixed list of PAN-displaying screens
Evidence upkeep	Recurring	Frequency of screen changes, role changes, and assessor sample requests	Store configuration, role matrices, and test results in version control with dated records
External testing or review	Recurring, third party	Independent scope of testing and the depth of the review requested	Ask for a written scope that names the PAN paths to be tested and the expected deliverables
Assessor time	Recurring per assessment cycle	Number of PAN-displaying systems, sample size, and quality of prepared evidence	Prepare evidence packs before fieldwork, since only the assessor issues the report

How remote-access controls block copying PAN

Requirement 3.4.2 asks for technical controls that prevent PAN from being copied or moved through remote-access technologies, except by personnel who have been explicitly authorized. The risk is practical. A support agent who screen-shares a payment screen, pastes a card number into a chat window, or downloads a transaction export through a remote session can move full PAN outside the cardholder data environment (CDE) in seconds, and the masking applied at the display layer under Requirement 3.4.1 does nothing once the agent is looking at an unmasked source or the session tool captures what is on screen.

The controls work together. Disabling clipboard transfer and file transfer in the remote tool stops the most direct copy paths. Restricting or disabling session recording and screen capture for sessions that touch CDE screens stops PAN from being written to recordings that are stored and reviewed elsewhere. Limiting which hosts a remote session can reach keeps a support session from being used to pivot into systems that hold stored PAN. Each control covers a different route, so a gap in one is not closed by the others. Confirm each setting against the remote-access products your organization actually uses, including vendor-hosted support consoles, remote desktop gateways and any built-in screen sharing in collaboration tools, because default settings and administrator overrides differ between them.

Before an assessor visits, ask three questions: which roles are explicitly authorized to see or move full PAN through remote access, where that authorization is recorded, and how you would show that unauthorized copy attempts are blocked or logged. Your access review records and the remote tool's policy configuration are the usual evidence. Confirm with your QSA which evidence they will sample, since the approach you choose under the defined or customized approach determines how the control is described and tested.

Who owns 3.4 and what an outside partner can prepare

Your organization owns Requirement 3.4 in full. That means deciding who has a legitimate business need to see more than the BIN and last four digits of a PAN, approving the masking rules applied on screens, receipts and reports, and deciding which personnel are explicitly authorized to copy or relocate PAN through remote-access technologies. Ownership also covers the accountability for exceptions and for the evidence that the controls operate every day, not only at assessment time.

Access decisions: Define the roles that may view unmasked PAN and document the business reason for each.
Display rules: Set masking standards for point-of-sale receipts, agent screens, back-office reports and exports, and confirm them with your payment brands, since stricter brand or legal rules can apply.
Remote-access policy: Decide which remote-access tools are permitted in the cardholder data environment and who may copy or move PAN through them.
Recurring review: Schedule periodic reviews of who holds access to unmasked data and retire access that is no longer needed.
Exceptions and sign-off: Own any deviation, its approval and its compensating measures.

Check that each of these decisions has a named owner and a dated record, because an assessor will ask for both.

Where organizations fall short on 3.4 and how to close each gap

Most 3.4 failures are not missing masking code. They are masking applied in one place while PAN appears unmasked somewhere else, such as exports, APIs, reports or support tools. Each card below names one gap, the action that closes it and the evidence an assessor can inspect.

Masking only in the user interface

The payment screen masks PAN to the BIN and last four digits, but the export function, the reporting API and the webhook payloads return the full number. Requirement 3.4.1 applies to every point where PAN is displayed, so a masked screen does not close the gap. Inventory every output path, including CSV exports, PDF statements, API responses and message queues, and mask or remove PAN in each one. Evidence: a field-level map of outputs with a test result per output showing masked or absent PAN for an in-scope role.

Unknown screens and reports showing PAN

Internal dashboards, troubleshooting pages and scheduled reports built years ago often display full PAN because nobody remembers they exist. Assessors look for these during screen walkthroughs and sample reports from the data warehouse. Crawl the application and reporting platform for fields that match PAN patterns, review the results with product owners and record each finding with its owner and fix date. Evidence: the discovery output, the remediation tickets and a re-scan showing the field no longer displays full PAN.

Role sprawl that grants unmasked views

Support, operations and finance roles often accumulate permissions over time, and one legacy group may still allow unmasked PAN for a task nobody performs anymore. Requirement 3.4.1 limits full visibility to personnel with a legitimate business need, so each unmasked permission must trace to a documented job function. Map which roles can see unmasked PAN, remove grants that lack a justification and route the remaining grants through periodic review by a named approver. Evidence: the role-to-permission matrix, the justification for each unmasked role and the review record showing removals.

Remote-access tools with open clipboard and transfer

Remote support sessions are a common path for copying PAN out of a cardholder data environment. A desktop-sharing tool with unrestricted clipboard or file transfer lets an agent paste a full number into a chat or save it to a local file. Requirement 3.4.2 expects technical controls that prevent copying or relocating PAN through remote-access technologies, except for explicitly authorized personnel. Disable clipboard and file transfer in CDE sessions by default, enable them only for named exceptions and log each session. Evidence: the remote-access policy settings, a test showing blocked copy and transfer, and session logs for authorized exceptions.

Receipts and printed output that break the rule

Point-of-sale receipts, printed reports and emailed confirmations can show more digits than the masking rule allows, often because a template was copied from an older system. The SAQ D note for 3.4.1 states that it does not override stricter legal or payment brand rules for displays, such as receipt rules, so receipt templates need a separate check against those rules. Review each receipt, report and notification template against the masking standard, correct templates that show too many digits and confirm the rule with your acquirer for receipts. Evidence: the template inventory, before and after samples of printed and emailed output and the acquirer's written confirmation where relevant.

No documented exception approvals

Some teams need full PAN for chargebacks, fraud investigation or dispute handling, and they often get that access through informal arrangements. An assessor will ask who approved each exception, why it is needed, when it expires and how it is monitored. Create a written exception process that names the approver, the business reason, the scope of unmasked access and an expiry date, then review exceptions on a set cycle. Evidence: the approved exception register, signed approvals and records showing expired exceptions were closed.

What buyers ask about 3.4 before hiring help

How much effort does requirement 3.4 take, and what drives it?

The effort depends mostly on how many places display or export full PAN today, not on the masking rule itself. Requirement 3.4.1 covers screens, receipts, reports, printed output and any interface that shows a card number, so each one needs an owner, a masking decision and a test. Requirement 3.4.2 adds the remote-access side, where you must show technical controls that stop copying or relocating PAN through remote tools for anyone not explicitly authorized. Effort rises with the number of applications, the number of user roles that see PAN, the number of legacy reports and the amount of third-party software in the flow. Ask for an inventory of every PAN display point before accepting any estimate.

Can an in-house team meet requirement 3.4 without an outside partner?

Yes, a capable internal team can meet requirement 3.4 without a partner, because the controls are configuration, access and application changes that your own engineers can make. The harder part is evidence and consistency: someone must prove that every display point is masked, that role-based visibility is enforced and that remote-access controls work across all tools. Teams that lack recent experience with access control platforms, identity integration or security testing often find the testing and documentation take longer than the build. A partner can prepare systems and evidence, but the organization still owns the control and the decision to accept any residual risk.

How long does requirement 3.4 work usually take?

No duration can be stated without a written scope, so treat any timeline as a conditional estimate. The schedule depends on the number of display and export points, whether masking is built into existing applications or added through a new service, how many systems need remote-access restrictions, and how quickly change approvals and testing windows move in your environment. Freeze dates for payment releases and the availability of your assessor also affect the calendar. Ask the partner to list the phases, the dependencies between them and the points where your team must act before work can continue.

What do our engineers and business owners need to provide?

The work needs three kinds of input from your side. Engineers must give access to the applications, reports and remote-access tools, along with test accounts and change windows. Business owners must confirm which roles have a legitimate business need to see more than the BIN and last four digits, and they must approve exceptions in writing. Security and compliance staff must supply the current policies, the data flow diagrams and the list of authorized personnel for copy or relocation of PAN. Without these inputs, a partner can design the controls, but it cannot confirm that they match how your business actually uses card data.

Can masking be added to an existing application without a rebuild?

In many cases masking can be added to an existing application, but whether it is practical depends on how the application renders and exports PAN. Display masking is usually handled in the presentation layer, the API response or a shared service, so a change in one place can cover several screens. Receipts, scheduled reports, CSV exports and downstream feeds often need separate changes. Applications that store full PAN in logs, caches or reporting databases need more work, and those issues belong under other requirements as well. Ask for a review of each application's display and export paths before deciding between a targeted change and a larger redesign.

Can an implementation partner issue the PCI DSS validation for 3.4?

No. An implementation partner prepares the systems, controls and evidence for requirement 3.4, but only the assessor issues the validation. PCI DSS validation is documented on official PCI SSC templates, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance, and the payment brands decide which entities must validate. A certificate from any vendor is not recognized as validation. Confirm with your acquirer or the relevant payment brand which assessment type applies to your organization before you commission any technical work.

What should a written quote for requirement 3.4 include?

A useful quote lists the scope in concrete terms: the named applications, display and export points, remote-access tools and environments covered. It should state each deliverable, such as a PAN display inventory, masking changes, access configuration, remote-access control evidence and a test report, and say which party performs each task. Ask for the assumptions behind the price and duration, the client inputs required and the dates on which they are needed, and how changes to scope are priced. Also ask how one-time work differs from recurring support, retesting or upgrades. Most engagements are fixed-scope, so the written scope is the document that should control both price and timing.

How DeployOpen scopes and prepares evidence for 3.4

DeployOpen works on requirement 3.4 by first agreeing in writing which screens, receipts, reports and remote-access paths touch full PAN, then configuring masking and copy controls in your own infrastructure. The organization keeps ownership of its controls, while the assessor decides whether the evidence meets the requirement.

How we scope

Inventory every screen, receipt template, export and report that can display full PAN within the cardholder data environment.
Map which roles hold a documented legitimate business need to see more than the BIN and last four digits.
Agree the written scope, deliverables and timeline with you before any configuration work starts, as engagements are fixed-scope.

How we build

Configure masking in applications and reports so only approved roles see more than the BIN and last four digits.
Apply technical controls that block copying or relocating PAN through remote-access tools for unauthorized personnel.
Test masking and copy restrictions against each role and remote-access path, recording results for your assessor.

How we hand over

Deliver configuration records, role-to-display mappings and test results that show how 3.4.1 and 3.4.2 are met.
Document the procedures your staff follow for access requests, exceptions and review of remote-access settings.
Walk your team through the evidence so your organization can explain its controls to the Qualified Security Assessor.

How we support

Ongoing support, upgrades and periodic re-testing of masking and remote-access controls are available as a retainer.
Review changes to screens, reports and remote-access tools so new PAN displays are assessed before release.
Confirm with your assessor and payment brands any stricter display rules, such as those for point-of-sale receipts, that apply to your business.