PCI DSS

What PCI DSS is

The Payment Card Industry Data Security Standard (PCI DSS) is the global standard that governs how organisations handle payment card data. It applies to any business that stores, processes or transmits cardholder data, and it exists to reduce card fraud and protect cardholders. The current version is PCI DSS v4.0.1.

The standard is maintained by the PCI Security Standards Council, but it is enforced through the card brands and your acquiring bank or payment provider. In practice, if you take card payments — online, over the phone, in person, or through a third party — PCI DSS applies to you in some form. The level and manner of your obligation depend on how you take payments and how much card data touches your systems.

Who must comply — and how scope varies

Every merchant that accepts card payments is expected to comply. What differs is how you demonstrate it, and that is driven by your merchant level (broadly, your annual card transaction volume) and your payment channels.

The good news for most small and medium-sized organisations, including care providers taking occasional payments, is that compliance is usually demonstrated through a Self-Assessment Questionnaire (SAQ) rather than a full external audit. The trick is choosing the right SAQ, because each one reflects a different way of handling card data.

There is no exemption for taking “only a few” payments — accepting cards at all brings you into scope. But you can dramatically reduce your scope, and therefore your obligations, by handling less card data yourself.

SAQ types explained

The SAQ you complete depends on how you accept payments and how much cardholder data enters your environment. The main types are:

SAQ	Typically for
A	E-commerce or mail/telephone merchants who fully outsource cardholder data handling to compliant third parties.
A-EP	E-commerce merchants whose website affects the security of the payment but who do not store card data directly.
B	Merchants using standalone, dial-out terminals or imprint machines, with no electronic storage.
C	Merchants with payment application systems connected to the internet, with no card-data storage.
D	Merchants and service providers who do not fit the simpler types — the most comprehensive questionnaire.

Choosing correctly matters: an SAQ that does not match how you actually take payments will either overburden you or leave real risk unaddressed. Our guide to SAQ types walks through how to identify yours.

Reducing your scope is the smartest move

The single most powerful thing most organisations can do about PCI DSS is to handle less card data themselves. Every system, person and process that touches cardholder data falls within scope and must meet the standard — so the less card data flows through your own environment, the smaller and cheaper your compliance burden becomes.

In practice, scope reduction usually means letting a compliant third party do the risky part for you. A hosted payment page, a redirect to a payment provider, or a point-to-point encrypted terminal can mean that raw card numbers never actually enter your systems. That often moves you from a demanding questionnaire toward one of the simpler ones. The classic scope expander, by contrast, is casually storing card data you did not need to keep — a spreadsheet of card numbers, details written on a paper form, or a recorded phone call that captures a security code. Removing those habits can transform your obligations.

For care providers who only take the occasional payment — a deposit, a top-up fee, a private-pay invoice — this matters a great deal. With the right setup, compliance can be genuinely light. Get the setup wrong and even a low volume of payments can drag sensitive data through email inboxes, notepads and shared drives that were never designed to protect it.

How the requirements are organised

PCI DSS is built around a set of core requirements covering areas such as:

• Building and maintaining a secure network (firewalls, secure configuration)
• Protecting stored cardholder data and encrypting it in transit
• Maintaining a vulnerability management programme and anti-malware
• Implementing strong access control, unique IDs and least privilege
• Regularly monitoring and testing networks
• Maintaining an information-security policy

Version 4.0.1 places particular emphasis on treating security as an ongoing, business-as-usual activity rather than a once-a-year exercise, and strengthens expectations around authentication and targeted risk analysis.

The process, step by step

1. Determine scope. Identify every system, process and person that touches cardholder data — and look for ways to reduce that footprint.
2. Confirm your merchant level and SAQ type. Check with your acquirer if you are unsure which applies.
3. Assess against the requirements. Work through the relevant SAQ and identify gaps.
4. Remediate. Close gaps — technical controls, policies, access management and supplier assurance.
5. Complete the SAQ and attestation. Confirm your compliance and complete the Attestation of Compliance.
6. Maintain and revalidate. Sustain the controls and revalidate on the cycle your acquirer requires, including any scanning obligations.

Evidence and documents involved

Depending on your SAQ, you may need:

• A clear scope definition and network/data-flow understanding
• Policies covering information security and cardholder-data handling
• Evidence of access control, unique user IDs and least privilege
• Vulnerability scanning results where required (for internet-facing channels)
• Third-party assurance — evidence your payment providers are themselves compliant
• Records of staff awareness and incident-response arrangements

Merchant levels and what drives your obligations

Alongside your payment channels, your merchant level shapes how you demonstrate compliance. Levels are based broadly on the volume of card transactions you process each year, with the highest-volume merchants subject to the most rigorous validation and the smallest merchants generally able to self-assess. Most care providers and SMEs sit comfortably in the lower-volume tiers, where a Self-Assessment Questionnaire and, where relevant, periodic vulnerability scanning are enough — provided the right SAQ is chosen. Your acquirer (the bank or payment provider that processes your card transactions) is the authority on which level and validation route apply to you, so it is always worth confirming with them rather than guessing. The key point is that PCI DSS obligations are proportionate: they scale with both how much card data you handle and how directly your own systems touch it, which is why reducing your scope and confirming your level are the two decisions that most affect your workload.

Common mistakes

• Mis-selecting the SAQ, either overcomplicating compliance or understating real exposure.
• Storing card data unnecessarily — for example writing card numbers on forms — which massively expands scope.
• Assuming a payment provider makes you compliant. Outsourcing helps, but you remain responsible for your part of the flow.
• Treating telephone payments as out of scope. Taking card details over the phone brings people and processes into scope.
• Letting compliance lapse between annual attestations rather than maintaining controls continuously.

How it relates to the other standards

PCI DSS overlaps with the wider security and data-protection work we do:

• Its network, malware and access-control requirements align with Cyber Essentials and Cyber Essentials Plus.
• Cardholder data is personal data, so PCI DSS sits alongside your UK GDPR obligations — a card-data breach is very likely also a reportable personal-data breach.
• Organisations with an ISO 27001 ISMS can absorb many PCI DSS controls into existing policies and processes.
• An outsourced DPO can help manage the data-protection dimension of payment handling.

Terms such as cardholder data, acquirer and scope are defined in our glossary.

How 360 Cyber Compliance helps

The single most valuable thing we do on PCI DSS is help you get your scope and SAQ type right — because that decision shapes everything that follows. We work on a transparent fixed-fee basis with a clear delivery process, translating a technical standard into plain, practical steps.

We help you map how card data actually moves through your organisation, identify safe ways to reduce your scope, confirm the correct SAQ, work through the relevant requirements, and close the gaps with proportionate controls and documentation. Where scanning or supplier assurance is needed, we help you coordinate it, and we help you complete the SAQ and Attestation of Compliance accurately.

We provide practical support throughout the assessment and make no guarantees about outcomes — compliance depends on your controls genuinely meeting the standard and on your acquirer’s requirements — but our goal is to make PCI DSS proportionate, honest and manageable.

Keeping compliance alive between attestations

One theme running through PCI DSS v4.0.1 is that security should be business as usual, not an annual scramble. The organisations that find revalidation painless are the ones that keep their controls running steadily through the year: patches applied, access reviewed when staff join and leave, scanning carried out on schedule where required, and no quiet drift back to storing card data that should never be stored. We can help you build a light, sustainable rhythm so that each year’s attestation is a confirmation of good habits rather than a fresh project. If you would like a clear, honest read on where you stand today, get in touch to talk through how you take payments and what compliance would involve.