PCI compliance and fraud monitoring: What PCI DSS covers and what it does not

What PCI compliance does for cardholder data

A breach of stored card data is the direct route to card-not-present fraud: the numbers are sold and used on other merchants' checkouts. PCI DSS exists to shut that route. It forces encryption, access limits, logging and testing on every system that touches card data, so one misconfigured server does not hand an attacker a card dump.

Non-compliance costs money before any breach. Card brands and acquirers can fine merchants, raise transaction fees or withdraw the ability to accept cards. After a breach, the forensic investigation, card reissue costs and legal fees land on the merchant that failed the standard.

PCI DSS v4.0 and what changed from v3.2.1

PCI DSS v4.0 replaced v3.2.1, which is now retired, so every assessment runs against v4.0. The main shift is from a fixed checklist to a risk-based approach: a requirement can be met with a customized control if you can show it achieves the same outcome, and several controls that used to be periodic are now expected to run continuously.

The table compares the two versions:

Who is in the PCI ecosystem

PCI covers everyone in the chain between a shopper's card and the issuing bank.

The PCI SSC writes the standard, the card brands enforce it through acquirers, and merchants and service providers implement it. Each party is accountable for the card data it touches.

What the standard covers

PCI DSS sets controls for three states of card data: processing, transmission and storage. If a system does any of the three, it is in scope.

In practice that means encryption, access control, periodic risk assessments and independent audits on every in-scope system.

The five entities

Five kinds of organization make up the ecosystem:

• Card brands such as Visa, Mastercard, American Express and Discover set the rules and require compliance from anyone who handles their cards.
• Banks, both issuers and acquirers, issue cards, process payments and answer for their merchants' compliance.
• Payment processors such as PayPal, Stripe and Square move payment data between merchants and banks.
• Merchants accept card payments and must protect the card data that passes through their checkout.
• Service providers (hosting, IT support, managed payment services) handle card data on behalf of clients and are in scope for it.

Who is responsible for what

The responsibilities split along the same lines.

• Card brands maintain PCI DSS, publish compliance programs and monitor adherence.
• Banks keep their own infrastructure compliant, watch transactions for fraud and push their merchants to validate.
• Processors transmit data securely, run compliant platforms and offer tokenization so merchants never hold raw card numbers.
• Merchants secure their point-of-sale and checkout systems, run risk assessments and complete validation each year.
• Service providers protect the data they hold for clients and supply the evidence those clients need for their own assessments.

Where the practical work sits

Most of the day-to-day work lands on merchants and service providers. Processors reduce that load with tokenization: the card number is swapped for a token that is useless if intercepted, and a merchant that never stores a raw card number has far less to secure. Hosting providers that offer PCI-compliant environments do the same job for the infrastructure layer.

How PCI compliance and fraud prevention connect

Stolen card data feeds fraud. Every breach of a merchant database becomes a batch of cards tested and used elsewhere.

PCI DSS cuts off the supply side. It does not score transactions or spot a stolen card at checkout, but it makes your systems a poor source of fresh card numbers, and its logging and testing requirements mean you are more likely to find a compromise before the data is sold.

The controls that do the work

Four controls carry most of the fraud-prevention value.

• Encryption in transit over open, public networks. Intercepted data is unreadable, so a compromised network segment does not yield usable card numbers.
• Access control on a need-to-know basis, with a unique ID for every person who can reach card data. It limits what a stolen credential can reach and makes insider misuse traceable.
• Monitoring and testing. Intrusion detection, log review and penetration tests find weaknesses before an attacker does and surface a compromise while it is still small.
• Multi-factor authentication (MFA) for access to systems that hold card data. A phished password on its own no longer gets an attacker in.

Where compliance shrinks the attack surface

A second group of requirements reduces what there is to steal and how fast you react when something goes wrong.

• Store less. PCI DSS requires you to keep only the card data the business needs and to delete the rest securely. Data you do not hold cannot be breached.
• Train staff. Phishing and social engineering are common ways in, and staff who recognize them stop the attack at the inbox.
• Build securely. Security in the development lifecycle, code review and prompt patching close the software flaws attackers use to reach card data.
• Plan the response. A written incident response plan with named owners means a breach is contained by your team rather than reported to you by your acquirer.

The eight components of a fraud monitoring program

A fraud monitoring program for card data has eight parts. PCI DSS has a requirement for each one, which is why a compliant environment is also a monitored one.

Encryption

Encrypt card data in transit across open, public networks and protect it at rest. Intercepted or exfiltrated data is then worthless to the attacker.

Access controls

Restrict card data to people who need it for their job, give each of them a unique ID, and put MFA in front of the systems that hold it. This is what stops a stolen password, or a curious employee, from reaching card numbers.

Monitoring

Run intrusion detection and review logs on a schedule. The point is time to detection: an anomaly found during the daily log review is a ticket; the same anomaly found by your acquirer months later is a breach.

Audits and risk assessments

Periodic audits confirm the controls still work; risk assessments tell you which gaps matter. Both are required, and both are where drift between the documented environment and the real one gets caught.

Incident response

PCI DSS requires a written incident response plan: who is on call, how an incident is contained, how it is investigated and how the business recovers. Test it before you need it.

Security awareness training

Staff have to recognize phishing and social engineering and know who to tell. The required training is the floor; the people handling refunds and account changes need more, because they are the ones attackers call.

Secure software development

Build security into the development lifecycle: code review, dependency updates and prompt patching for anything that handles card data. An unpatched library on a payment page is an open door.

Network security

Firewalls, routers and switches need locked-down configurations, strong encryption protocols and segmentation that keeps the cardholder data environment separate from the rest of the network. Segmentation also shrinks your audit scope.

PCI DSS requirements: Levels, validation and the 12 controls

What you have to do depends on how many card transactions you process a year. The level sets the validation method; the 12 requirements apply to everyone.

The four merchant levels

PCI DSS puts merchants in four levels by annual transaction volume:

• Level 1: more than 6 million card transactions a year. An annual on-site assessment by a Qualified Security Assessor (QSA), or an internal audit by a certified internal auditor, plus quarterly network scans by an Approved Scanning Vendor (ASV).
• Level 2: 1 million to 6 million card transactions a year. An annual Self-Assessment Questionnaire (SAQ) plus quarterly ASV scans.
• Level 3: 20,000 to 1 million card transactions a year. Annual SAQ plus quarterly ASV scans.
• Level 4: fewer than 20,000 card transactions a year, or up to 1 million total transactions across all channels. Annual SAQ, with quarterly ASV scans if the acquiring bank requires them.

Validation by level

Validation follows the level. Level 1 is assessed on site by a QSA each year; Levels 2 to 4 self-assess with an SAQ; everyone except some Level 4 merchants submits quarterly ASV scans.

The 12 requirements

PCI DSS has 12 requirements grouped under six objectives:

1. Build and maintain a secure network and systems

• Install and maintain firewalls that control traffic between trusted and untrusted networks.
• Change every vendor-supplied default password and setting before a system goes live.

2. Protect cardholder data

• Protect stored cardholder data with encryption and strict retention limits.
• Encrypt cardholder data in transit across open, public networks.

3. Maintain a vulnerability management program

• Protect all systems against malware and keep anti-virus software current.
• Develop and maintain secure systems and applications, and patch known vulnerabilities promptly.

4. Implement strong access control measures

• Restrict access to cardholder data by business need to know.
• Identify and authenticate every user with a unique ID and strong authentication such as MFA.
• Restrict physical access to cardholder data.

5. Regularly monitor and test networks

• Track and log all access to network resources and cardholder data.
• Test security systems and processes regularly with vulnerability scans and penetration tests.

6. Maintain an information security policy

• Maintain a written security policy that covers employees and contractors.

What compliance buys you, and what non-compliance costs

Beyond avoiding fines, compliance pays in three ways. Falling out of compliance costs in four.

The upside

• Reputation. Compliance is evidence to customers and partners that card data is handled with care.
• Trust. A shopper who knows their card details are protected comes back, and trust shows up as repeat purchases.
• Legal footing. After a breach, a merchant that can show it met PCI DSS is in a far better position on liability and penalties. The same controls also cover ground required by GDPR and HIPAA.

The downside

• Fines and penalties from the card brands, from thousands to millions of dollars depending on the failure and the size of any breach, plus higher transaction fees and closer scrutiny from processors.
• Reputational damage. News of a breach travels fast, customers leave, and winning them back costs more than the controls would have.
• Legal liability: lawsuits from affected customers, regulatory action, and the cost of compensating cardholders for their losses.
• Operational disruption while the breach is contained and investigated, up to a temporary shutdown to fix the vulnerabilities.

Why staying compliant is hard

Getting compliant once is the easy part. Staying compliant fails for six predictable reasons.

The requirements are long

The 12 requirements break down into nearly 400 sub-requirements. Without a dedicated security team, reading them correctly is a project in itself, and the standard keeps changing underneath you.

It costs time and money

Security tooling, qualified people and annual assessments all cost money. Small and mid-sized merchants feel this most.

Infrastructure keeps changing

Every new system, migration or integration can pull card data into a place it was not before. Scope has to be re-checked each time, and legacy systems that cannot be patched need compensating controls.

Vendors are in scope too

Payment processors, hosts and IT contractors handle card data for you, and their failures are your failures under the standard. That means contract terms, attestation evidence each year and follow-up when their scans find something.

Monitoring never stops

Internal audits, QSA assessments and recurring vulnerability scans are the easy part to schedule.

Continuous log monitoring with someone watching it is the hard part, and the hardest for smaller teams.

Validation is paperwork

Depending on level you file an annual SAQ, submit quarterly ASV scans and perhaps host a QSA on site. Each needs evidence: policies, scan reports, asset lists, change records.

Keep that evidence current all year rather than rebuilding it the month before the assessment.

How to stay compliant

Six practices cover most of the work.

Define scope first

Scope is everything that processes, stores or transmits card data, plus anything connected to it.

Map it before anything else: every system, application, process and third party that touches a card number.

A system left off the map is unassessed and unprotected. Tokenization and segmentation are how you shrink the map.

Put the core controls in place

The baseline is the same for everyone:

• Firewalls that separate the cardholder data environment from less trusted networks.
• Encryption for card data in transit and at rest.
• Anti-malware that is deployed everywhere and kept current.
• Secure development practices for any application that handles card data.

Scan, test and watch the logs

Three activities belong on the calendar:

• Vulnerability scans on a schedule, with findings fixed rather than filed.
• An annual penetration test that tries the attacks a real adversary would.
• Log monitoring with alerts that someone responds to in real time.

Enforce access control

Three rules:

• Need to know: card data is visible only to people whose job requires it.
• Unique user IDs, so every action is attributable to a person.
• MFA on every system that holds cardholder data.

Write the incident response plan down

The plan has five stages:

• Preparation: roles, contact lists and procedures agreed before anything happens.
• Detection and analysis: how incidents are spotted and their impact sized.
• Containment and eradication: how the incident is stopped and the cause removed.
• Recovery: how normal operations resume.
• Post-incident review: what changes so it does not happen again.

Keep the documentation current

Documentation is what you show the assessor:

• Security policies and procedures for cardholder data.
• Risk assessments and the measures taken for each finding.
• Validation records: SAQs, ASV scan results and QSA reports.

Where Sensfrx fits next to PCI DSS

PCI DSS protects the card data you hold. It says nothing about whether the card being used on your checkout right now was stolen from someone else. That is the fraud monitoring half of the job, and it needs a different tool.

Sensfrx scores every signup, login and payment in real time from device, network and behaviour signals, and your rules turn the score into allow, review or block. It sits in front of the payment, so a stolen card or a hijacked account is caught before the order is approved.

What transaction scoring adds to compliance

Compliance controls answer "is our card data safe?". Transaction scoring answers "is this payment the cardholder's?".

The signals are different: device fingerprint, IP and network reputation, velocity across accounts and sessions, and how the user behaves on the page before checkout. None of them are in PCI DSS, and all of them are what separates a chargeback from a sale. Together the two cover the whole problem: the standard keeps your data out of the fraud supply chain, and scoring keeps other merchants' breached data off your checkout.

Where to start

If you process cards, get scope mapped and the SAQ filed; that is the compliance half. For the fraud half, put scoring in front of checkout. There are plugins for WooCommerce, Shopify, WHMCS, Blesta and WISECP; everything else goes through the REST API.

Start on the free plan, and if your stack is not listed, tell us what you run.