Trace the proposed route
List where the report is prepared, who receives it and where copies may be retained.
PCI DSS · Payment-data handling
PCI DSS review for file sharing
Start by checking whether the file needs to contain payment account data at all. Use a redacted sample to review the handover with the owner of your payment environment.
Check the boundary
Ask the payment security owner which systems and service providers the proposed exchange brings into scope.
Prepare review evidence
Record the approved fields, handling instructions and recipient before testing the route.
Review the report before release
Inspect exports, hidden worksheets and supporting attachments. Use sample data to test the process and document any questions for the assessor.
Can you remove the account data?
Use business references where they meet the need. Have the data owner review exports, attachments and screenshots before sharing. Do not assume masking alone removes a system from scope.
Is sensitive authentication data present?
Card verification codes, full track data and PIN blocks must not be retained after authorisation, even if encrypted. Stop the workflow and follow your approved handling process.
Has the complete workflow been assessed?
If account data is necessary, involve your PCI lead or assessor. Review every system, recipient and service provider involved before approving the transfer route.
Encryption is
one control.
Scope is the
whole picture.
Look at the file’s entire journey. Discuss whether MX is suitable for the specific information and environment before sending payment data.
- Stored information
- Review what is retained, where it resides, who can access it and how it is deleted when no longer required.
- Data in motion
- Confirm the cryptography and security protocols protecting any account data sent over public networks.
- People and permissions
- Document the business need for each recipient. Include external users and administrative access in the review.
- Supplier evidence
- Request applicable assessment evidence and a clear allocation of responsibilities. A product demonstration is not a PCI assessment.
Show us the workflow.
Leave out the card data.
Use a synthetic example to explain the business need, your proposed recipients and the boundaries set by your PCI team. We can explore the file-exchange requirements together.
Discuss your exchange requirementsA few important
distinctions.
Is MX certified as PCI DSS compliant?
This page does not assert a PCI DSS validation for MX. Ask the team for current, applicable evidence and confirm the assessed service scope with your PCI lead before using it for account data.
Does encrypting a file remove it from PCI DSS scope?
Do not assume that it does. Encryption is a protection measure, not a general exemption. Your environment, data flows and ability to affect account-data security determine the assessment.
Can we store a card verification code in an encrypted file?
Not after authorisation. PCI DSS prohibits retention of sensitive authentication data after authorisation, including card verification codes, even when encrypted.
Is PCI DSS only relevant to the US?
No. PCI DSS is a payment-industry standard used globally. Both UK and US organisations should establish their obligations with the relevant payment partners and assessors.