PCI DSS and File Transfers: Cardholder Data in Motion

Every night, a mid-size retailer's systems produce a settlement file: one row per card transaction, ready to be reconciled with the payment processor. It is an ordinary batch job on an ordinary transfer server — until you look inside the file and find full card numbers in a plain text column. At that moment the server, the job, the network path, and the administrator all acquire a new supervisor: PCI DSS, the security standard the payment card industry attaches to anyone who handles card data.

PCI DSS is unusual among the frameworks an admin meets. It is not a law — no legislature passed it — yet it is one of the most prescriptive and most consistently enforced standards in existence, because the enforcement comes through the banking relationships a business cannot operate without. It is also the framework where file transfer sits closest to the center of the story, since card data in a file crossing a network is precisely the scenario the standard's authors worried about most.

This article translates the standard's expectations into transfer terms: what data triggers it, how the crucial concept of "scope" decides your workload, what strong cryptography means on a transfer server, what the logging obligations look like — and why the single best move is often getting card numbers out of your files entirely. It is part of our Compliance Frameworks series; as always, your acquirer, assessor, and compliance team make the official determinations, and this article helps you implement them well.

What PCI DSS Is and Who Makes You Follow It

PCI DSS is a contractual standard created by the payment card brands and administered by their industry body. When a business signs an agreement with an acquirer — the bank that processes its card payments — that agreement obliges the business to comply with the standard. The same applies to service providers, companies that store, process, or transmit card data on behalf of others, or that could affect its security. There is no regulator with a badge; there is a bank with a contract, and behind it card networks that can impose penalties, raise processing costs, or ultimately cut a business off from card payments. For most organizations that is enforcement enough.

How compliance is demonstrated varies with size and role. Smaller merchants typically complete a self-assessment questionnaire — a structured checklist attesting to the controls in place. Larger merchants and most service providers undergo an assessment by a qualified security assessor, an outside auditor certified for exactly this work, who examines evidence and writes a formal report. Either way, someone eventually asks pointed questions about any system that touches card data, and transfer servers are a standard stop on that tour. If a vendor handles card files for you, their compliance becomes part of your story too — the theme of our vendor assessment series.

The Data: PAN and Friends

The standard revolves around one field: the PAN, the primary account number — the long number across the front of a payment card. Where the PAN goes, PCI DSS follows. Cardholder data means the PAN alone or together with the cardholder's name, the expiration date, or the service code. A file containing full PANs is regulated cargo, no matter how it got there or how briefly it exists.

A second category is stricter still. Sensitive authentication data — the security code printed on the card, the full contents of the magnetic stripe or chip, PIN data — must never be stored after a transaction is authorized, not even encrypted. If you ever find these fields in a file on a transfer server, that is not a hardening task; that is a stop-everything conversation with your security and compliance people, because the data should not exist at rest at all.

One transformation changes the picture: truncation. A PAN reduced to at most the first six and last four digits — the form you see on receipts — is generally no longer treated as cardholder data, because the middle digits are gone and cannot be recovered from the file. Remember that asymmetry: masking a number on a screen changes only the display, while truncating it in the file changes what the file is. It becomes the key to the scope-shrinking strategy later in this article.

Scope: The Concept That Decides Your Workload

Before any control matters, PCI DSS asks a defining question: which of your systems are in scope for assessment? The answer: every system that stores, processes, or transmits cardholder data — a zone called the cardholder data environment, or CDE — plus every system connected to those systems or able to affect their security. Scope is infectious by design. A transfer server that carries the settlement file is squarely in scope. The directory server it authenticates against, the monitoring host that reaches into it, the admin workstation that manages it — all of these can be pulled in with it.

Everything in scope must meet the standard's full weight: hardening, patching, access control, logging, testing, documentation. That is why experienced practitioners treat scope reduction as the most valuable control of all. Every system you can honestly remove from scope is a system you no longer have to defend in an assessment. The diagram below shows the same settlement feed built two ways — with full PANs, where scope swallows the transfer estate, and with tokenized data, where it does not.

Card Data in Motion: Strong Cryptography or Nothing

For data that does cross networks, the standard's language is blunt: cardholder data transmitted over open, public networks must be protected with strong cryptography — current, unbroken protocols and algorithms, configured without the weak options. The internet is the canonical open network, but assessors also read the phrase to cover wireless links and any path an attacker could plausibly reach. In transfer terms:

• SFTP, FTPS, or HTTPS for every card-data flow. Plain FTP transmits the PAN in cleartext and fails instantly — if any legacy card feed still uses it, that is finding number one, and our case for retiring plain FTP writes itself.
• Current TLS versions and vetted SSH settings, with old protocol versions and weak ciphers disabled on the server. What counts as "strong" drifts as attacks improve, which is why the standard says "strong cryptography" instead of naming an algorithm and why your cipher configuration needs periodic review — the discipline covered in cipher policy basics.
• Never PAN over end-user messaging. Email, chat, and texting are explicitly the wrong channel for card numbers unless the data itself is rendered unreadable first — and the realistic answer is simply "we do not send card data that way, ever."
• File-level encryption as a second layer. Encrypting the settlement file itself with OpenPGP protects it at rest in staging folders and download areas, and keeps it unreadable even if a channel is misconfigured. In practice this is an automation step: a scheduled job in Sysax FTP Automation can OpenPGP-encrypt the nightly batch, deliver it over SFTP, retry on failure, and send an email notification if the run breaks — turning the control into something that happens every night without a human remembering it.

Verifying that nothing cleartext remains is its own task; the techniques in cleartext discovery — watching your own network for unencrypted protocols — are exactly how assessors and attackers alike will check your claim.

What about transfers that never leave the building? Formally, the strong-cryptography demand targets open and public networks. In practice, treating internal card-data hops as if they were public is the safer engineering default: internal networks host compromised workstations more often than anyone likes to admit, segmentation mistakes happen, and an assessor who sees cleartext PAN moving anywhere will ask uncomfortable questions about where else it travels. Encrypting every hop also spares you from proving, flow by flow, which network segments count as trusted — a category of argument that rarely ends well for the defender.

Accounts and Access on an In-Scope Server

The standard's access-control philosophy is need to know: access to cardholder data restricted to the people and systems whose job requires it, denied by default to everyone else. Layered on top are expectations that will look familiar from every other framework: a unique ID for every user, no shared or generic accounts, strong authentication, multi-factor authentication for administrative and remote access to in-scope systems, and prompt removal of access when people leave. For a transfer server, that means the settlement feed runs under its own service account with access to exactly one folder tree; administrators log in as themselves; and the processor's pickup account cannot see anything but its own drop zone. The care and feeding of those non-human accounts is a subject of its own — see service account hygiene.

Network-level restriction earns its keep here too. If the processor connects from a known set of addresses, an allowlist limits the account to those addresses and turns a stolen password into a much smaller problem — reasoning explored in IP allowlisting and geo-restrictions. On the product side, Sysax Multi Server supports this pattern directly: per-server IP allow and block lists, authentication against built-in accounts, Windows or Active Directory, or public keys, and a FIPS 140-2 mode for environments that require validated cryptographic implementations.

Access also has to stay correct over time. Staff change roles, the processor's operations team rotates, and the standard expects rights to be revoked promptly and reviewed periodically rather than accumulating forever. A quarterly pass over the transfer server's account list — who is this, why do they still need access, when did they last connect — catches the drift before an assessor does, and the partner-facing half of that routine is mapped out in the partner credential lifecycle.

Logging: Track and Monitor All Access

PCI DSS is demanding about logs, and unusually specific about what happens to them. The expectation has three parts. First, record: every access to cardholder data and every action on in-scope systems should be traceable to an individual — logons, file reads and writes, administrative changes, failures. Our guide to what to log on a transfer server covers the event catalog. Second, review: logs are expected to be examined daily, which for any real team means automation — alerts and daily summaries rather than a human reading raw logs, the approach described in alerts from transfer logs. Third, retain: keep at least one year of log history, with roughly the most recent three months immediately available for analysis rather than parked in offline archives.

The practical implication is that log storage needs designing, not defaulting. A server that overwrites its log after two weeks fails the retention expectation silently. Sysax Multi Server logs activity to file and to a database with rollover, which supports the pattern assessors like to see: a queryable recent window for the daily review, and archived history deep enough to cover the retention period.

The Best Control: Take Card Data Out of the Files

Now return to the retailer's settlement feed, because its ending is instructive. Everything above — encryption, accounts, logging — treats the file's contents as a given. The stronger question is: why does the file contain full PANs at all?

Most of the time, downstream systems need to match transactions, not to know card numbers. Matching can run on a token — a substitute value issued by a tokenization service, useless to a thief, that consistently represents the same card — or on the truncated first-six-and-last-four plus transaction identifiers. When the retailer's team asked their processor that question, the answer was that the reconciliation only needed tokens and truncated digits. The export was changed, the PANs disappeared from the file, and the transfer server stopped carrying cardholder data at all. The controls stayed (they were good practice anyway), but the assessment conversation about that server became five minutes instead of five days. Whether a particular redesign takes a system out of scope is ultimately your assessor's call — but "remove the data" is the one control that makes every other control easier.

Two supporting practices make this durable. First, hunt for card data you do not know about: PANs have a recognizable shape, so pattern scanning across exports, staging folders, and archives keeps turning up surprises — the technique behind pattern-based controls, applied to discovery. Second, treat every request for a new card-data feed with the same first question: can this work with tokens or truncation instead? Knowing what data leaves your network is what makes that question answerable.

A PCI DSS Transfer Checklist

The working summary, in copy-paste form. It is not the standard — it is the transfer-shaped slice of it, phrased as questions you can act on.

PCI DSS TRANSFER CHECKLIST
[ ] Every flow that carries cardholder data identified; each one
    challenged: could it use tokens or truncated PANs instead?
[ ] No sensitive authentication data (security codes, track/PIN
    data) in any file, anywhere, ever
[ ] All card-data flows on strong cryptography: SFTP/FTPS/HTTPS,
    current TLS versions, weak ciphers disabled
[ ] No PAN over email, chat, or messaging — stated in policy,
    checked by pattern scans
[ ] File-level OpenPGP encryption on batches that rest on
    intermediate systems
[ ] Unique accounts; need-to-know folder access; MFA on admin
    and remote access; IP allowlists for partner accounts
[ ] All access to card data logged and traceable to individuals
[ ] Daily log review running (automated alerts + summary)
[ ] One year of log history retained, recent three months
    quickly searchable
[ ] Scope documented: which systems touch card data, which
    connect to them — reviewed when flows change
[ ] Quarterly and annual assessment tasks on the calendar with
    named owners

Where This Fits

PCI DSS looks intimidating, but its transfer chapter reduces to four moves: know exactly where card data is, encrypt it wherever it moves, control and log every touch, and — wherever the business allows — replace the card numbers with tokens so whole systems fall out of the argument. The recurring themes are the same five that every framework demands, a pattern laid out in why compliance frameworks care about file transfers.

If your organization also answers to HIPAA, SOX, or privacy law, do not run four parallel projects; build the control set once and map it with a transfer control matrix. The nearest neighbor in this series is SOX and file transfers — same money, different worry — and when assessment season arrives, our audit-ready reporting series covers turning these controls into evidence.

Frequently Asked Questions