PCI compliance isn't a 12-point checklist — it's your SAQ

This run-through covers every one of the 12 PCI DSS v4.0.1 requirements in plain English, so you can see what each one asks of you and where the real work sits. We've written it for businesses that take card payments over the phone, because that's the part of PCI most people get wrong and the part we spend our days fixing. Where it's true, we've flagged how routing the card capture through Paytia takes a requirement off your plate entirely — when an agent never hears, sees, or types a card number, the systems that would otherwise fall in scope simply aren't there to assess.

Requirement 1: Install and maintain network security controls

This is about controlling traffic in and out of the systems that touch card data. You need firewalls or equivalent controls between your cardholder data environment and everything else, with documented rules that explain why each path is allowed. Auditors want to see the rule set reviewed at least every six months, and they want to see that someone actually understands what each rule is for rather than a wall of legacy permits nobody dares delete.

The honest problem here is scope. If card numbers flow across your contact-centre network and into your CRM, every switch and segment in that path needs documenting and defending. When the card capture is descoped to Paytia, the cardholder data never enters your network in the first place, so the segment you'd have spent weeks mapping and segmenting isn't carrying anything an assessor cares about.

Requirement 2: Apply secure configurations to all system components

Default passwords and default settings are how a lot of breaches start. This requirement asks you to harden every system that's in scope — change vendor defaults, turn off services you don't use, and keep a configuration standard you can show an assessor. It applies to servers, network kit, and the workstations agents use, not just the obvious infrastructure.

Agent desktops are the part people forget. If a phone agent types a card number into a screen, that workstation is in scope and has to be hardened and evidenced like a server. Take the card entry off the desktop and that whole class of endpoints drops out of the conversation.

Requirement 3: Protect stored account data

If you store card data, you have to protect it — strong cryptography, tight key management, and a hard rule that you never store sensitive authentication data like the CVV after authorisation. The single best thing you can do here is store less. Every field you don't retain is a field you don't have to encrypt, justify, and prove you can delete on schedule.

We're firm on this one: most contact centres have no business reason to store card numbers at all. Call recordings that captured DTMF tones or an agent reading digits back are stored card data even if nobody thinks of them that way. With Paytia the digits are entered on the customer's keypad and masked before the recording, so there's no stored account data to protect because none of it ever reached a system you control.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open public networks

Whenever card data crosses a network you don't fully control — the public internet, a wireless link, a carrier you don't own — it has to be encrypted in transit with current, strong cryptography. That means modern TLS, no expired or weak protocols, and certificates you actually manage rather than ones that quietly lapsed.

For telephone payments this gets subtle, because a voice call carrying spoken card numbers is a transmission too, and the analogue last mile isn't something you can wrap in TLS. The clean answer is to not transmit the number as audio at all. Paytia captures the digits as keypad input on a secure channel, so the part that would otherwise be travelling as unprotected speech over a phone line isn't the bit carrying the data.

Requirement 5: Protect all systems and networks from malicious software

Every in-scope system that's commonly affected by malware needs anti-malware protection that's kept current, running, and generating logs you can review. v4.0.1 also expects you to address phishing through technical controls, not just an annual training slide, because phishing is how most credential theft into a card environment actually happens.

The scope point repeats here for a reason. Anti-malware coverage and evidence is proportional to how many systems are in scope. Fewer in-scope endpoints — because the card capture never touches them — means a smaller, more honest set of machines to keep clean and prove clean.

Requirement 6: Develop and maintain secure systems and software

Anything you build or run that's in scope has to be developed securely and patched in good time. Critical patches go on within a month, you protect public-facing web applications, and you manage change so a deployment can't quietly drag something new into scope without anyone noticing. If you write custom code that touches card data, secure development practices and code review aren't optional.

If you operate a payment page or store card data in your own application, this requirement is heavy and ongoing. When the payment capture is handled by Paytia's PCI DSS-validated platform, the code that touches the card number isn't yours to secure, patch, and pen-test — it sits with the provider whose job that is.

Requirement 7: Restrict access to system components and cardholder data by business need to know

People should only be able to reach card data if their job genuinely requires it, and access should default to denied until it's explicitly granted. You need documented roles, a defined access model, and proof that someone reviews who can see what rather than letting permissions accrete forever.

The biggest "need to know" population in most contact centres is the agents themselves, simply because they handle the payment. Remove the card number from the agent's reach — they stay on the line, the customer keys the digits, the agent never sees them — and the largest group of people you'd otherwise have to govern access for no longer has access to govern.

Requirement 8: Identify users and authenticate access to system components

Every person with access to in-scope systems needs a unique ID — no shared logins — and authentication strong enough for what they can reach. v4.0.1 tightened this: multi-factor authentication is expected for access into the cardholder data environment, and password rules got stricter. Shared agent accounts on a contact-centre application are a common and serious finding.

Strong authentication is good practice everywhere, so we're not pretending this disappears. But the number of accounts that need MFA into a card environment shrinks dramatically when the card environment your agents work in doesn't contain card data, because those agent systems are no longer the cardholder data environment that triggers the strictest controls.

Requirement 9: Restrict physical access to cardholder data

Physical access controls cover the buildings and media where card data lives — visitor procedures, controlled entry to areas with in-scope systems, and proper destruction of any media holding card data. For contact centres this has historically meant clean-desk rules, locked-down agent floors, and policing whether anyone can photograph a screen.

A lot of that burden exists because the card number is physically present where agents sit — on a screen, on a notepad, audible across a room. If the digits are never displayed or spoken on the floor, the clean-desk and screen-overlook controls you'd have to design and police around the payment moment have far less to protect.

Requirement 10: Log and monitor all access to system components and cardholder data

You need audit logs that record who did what to in-scope systems and card data, those logs have to be protected from tampering, time has to be synchronised so events line up, and someone has to actually review the logs and respond to anomalies. "We collect logs nobody reads" is a finding, not compliance.

Logging effort scales with the size of the environment you have to watch. A descoped telephone payment flow means fewer in-scope systems generating fewer logs that you have to retain, protect, and genuinely monitor — which makes the monitoring you do keep up far more likely to be meaningful.

Requirement 11: Test security of systems and networks regularly

Regular testing means vulnerability scans on a defined cadence, internal and external penetration testing at least annually and after significant change, and segmentation testing if you rely on segmentation to keep things out of scope. v4.0.1 also added checks around payment page integrity and unauthorised script changes, which matters if you run your own payment page.

Penetration testing is priced and scoped by what's in scope. Shrink the cardholder data environment by keeping card capture off your systems and the annual pen test, the scan footprint, and the segmentation testing all get smaller and cheaper — and the segmentation you're testing has less riding on it because less is hiding behind it.

Requirement 12: Support information security with organisational policies and programmes

This is the governance wrapper around the other 11 — a maintained information-security policy, a documented risk assessment, defined responsibilities, an incident response plan you've actually tested, and due diligence over third parties who could affect your card data. v4.0.1 leans hard on understanding which controls each party owns when you outsource part of the flow.

Outsourcing the card capture doesn't outsource your policy obligations, and we won't pretend it does — you still own the programme, the risk assessment, and the SAQ. What changes is the size and difficulty of what the policy has to cover. Most of our contact-centre clients move from SAQ D, which spans nearly all of the above in depth, to SAQ A, because the agents never touch the card and the validated handling sits with us. That's not the controls disappearing — it's them landing where they belong.

If you want to see the platform that makes the descoping in this checklist real — agents stay on the call, customers key the digits, and the card data never reaches your people or your systems — take a look at our PCI DSS v4 solution and we'll walk you through what it would mean for your own assessment.