PCI DSS Compliance Goals

If your business takes credit or debit cards, PCI DSS compliance is not optional, it is a contractual obligation you sign up for the moment you get a merchant account. PCI DSS stands for Payment Card Industry Data Security Standard, and it is maintained by the PCI Security Standards Council, the body founded by Visa, Mastercard, American Express, Discover, and JCB.

The standard has moved on since the last time this page was updated. PCI DSS 4.0 replaced version 3.2.1, and as of March 31, 2025, every one of its requirements, including the roughly 51 that were originally "future dated" and treated as best practice, became mandatory. The council built the update on extensive industry input: over three years, more than 200 organizations submitted over 6,000 items of feedback that shaped the standard. As PCI SSC Executive Director Lance Johnson said when the standard was published, "the industry has had unprecedented visibility into, and impact on the development of PCI DSS v4.0. Our stakeholders provided substantial, insightful, and diverse input that helped the Council effectively advance the development of this version of the PCI Data Security Standard." If your compliance documentation still references 3.2.1 or talks about future-dated requirements as optional, it is out of date and an assessor will flag it.

This post walks through the current compliance process and the six goals (with their 12 underlying requirements) that PCI DSS is built around, along with where teams typically get tripped up trying to meet them.

The PCI DSS compliance process

There are three phases: assessment, remediation, and reporting. None of them are one-time events; PCI DSS compliance is a cycle, not a certificate you earn once and file away.

Step 1: Assessment

Assessment means mapping the flow of cardholder data end to end, across every device that touches it, point of sale terminals, servers, laptops, even the mobile devices your staff use for order taking. The Council publishes Self-Assessment Questionnaires (SAQs) matched to different merchant types, and larger merchants work with a Qualified Security Assessor (QSA), an independent firm certified by the Council to perform formal assessments.

In practice, this is where scope creep usually lives. Teams assume their cardholder data environment is smaller than it actually is, then discover during assessment that an old file share or a marketing tool has cached card numbers nobody accounted for.

Step 2: Remediation

Remediation fixes whatever the assessment turned up. This can be as small as a firewall rule change or as large as re-architecting how card data is stored. Typical remediation actions include:

• Cataloging and prioritizing discovered vulnerabilities by severity
• Replacing insecure processes (plaintext storage, shared logins, unpatched software)
• Re-scanning to confirm the fix actually holds, beyond simply closing the ticket

One thing worth being honest about: remediation budgets are usually underestimated. Fixing a scoping mistake after the fact, for example realizing cardholder data touched a system nobody segmented off, often costs far more than doing the network segmentation properly the first time.

Step 3: Reporting

Once remediation is done, you report to your acquiring bank and the card brands you work with. Under PCI DSS 4.0, merchants and service providers still submit quarterly scans through an Approved Scanning Vendor (ASV), large-volume merchants still need an on-site QSA assessment resulting in a Report on Compliance (RoC), and smaller merchants can self-assess with an Attestation of Compliance (AoC). The reporting mechanics did not change much in 4.0, but the bar for what counts as "compliant" going into that report did.

Six PCI DSS compliance goals

PCI DSS organizes its 12 requirements under six goals. This structure carried over from 3.2.1 into 4.0 unchanged, even though the technical detail underneath several requirements got considerably stricter.

Goal 1: Build and maintain a secure network and systems

This goal covers network architecture and configuration hygiene. Before online banking, network security mostly meant keeping criminals from physically accessing hardware. Today it means securing PIN entry devices, point of sale integrations, and the layered networks that move a transaction from swipe to settlement.

Requirement 1: Install and maintain network security controls

PCI DSS 4.0 broadened the old "firewall" requirement into "network security controls," acknowledging that many organizations now rely on cloud security groups and software-defined perimeters instead of, or alongside, traditional firewalls. Whatever the technology, the intent is the same: block unauthorized traffic to cardholder data environments and log what gets through.

Practical basics still apply here:

• Default-deny inbound rules, with explicit allow-listing for what actually needs access
• Regular review of firewall and cloud security group logs for anomalies, more often than a quarterly glance
• Documented justification for every open port or rule, reviewed at least every six months under 4.0

Requirement 2: Apply secure configurations to all system components

Leaving vendor-supplied default passwords in place is still, remarkably, a routinely common finding in PCI assessments. A default admin password on a point of sale terminal or a payment gateway is functionally an open door.

PCI DSS 4.0 also pushed harder on configuration standards generally, beyond passwords alone. That means documented hardening baselines for every system type in the cardholder data environment, going further than a one-time password change.

Goal 2: Protect account data

Cardholder data includes the primary account number (PAN), cardholder name, expiration date, and the service code. PCI DSS 4.0 renamed this goal from "protect cardholder data" to "protect account data" to make clear that sensitive authentication data, like CVV and full track data, falls under the same protections even though it must never be stored after authorization.

Requirement 3: Protect stored account data

The rule here is simple to state and hard to follow in practice: do not store sensitive authentication data after authorization, and encrypt or truncate whatever account data you do need to retain. 4.0 added more specific technical requirements for how PANs are displayed (masking beyond the first six and last four digits unless there is a documented business need) and tightened key management expectations.

Requirement 4: Protect cardholder data with strong cryptography during transmission

Transport Layer Security (TLS) remains the standard mechanism for encrypting data in transit. PCI DSS 4.0 adds a detail that trips people up: assessors must now confirm that the TLS certificates protecting PAN transmission are valid, unexpired, and not revoked, presence alone no longer counts. An expired certificate that still "works" because browsers cache trust is technically a compliance gap.

Goal 3: Maintain a vulnerability management program

Vulnerability management means continuously finding and closing security gaps before someone else finds them first. IBM's 2025 Cost of a Data Breach Report found the global average cost of a breach dropped to $4.44 million, down 9% from $4.88 million the year before, the first decline in five years, largely credited to faster containment driven by AI-assisted detection. In the United States specifically, though, the average cost hit a record $10.22 million, up 9% year over year. Suja Viswesan, IBM's Vice President of Security and Runtime Products, summed up why the gap matters: "AI is making attacks faster and cheaper, while breaches keep getting more expensive. When organizations have an extended gap between discovery and remediation, that imbalance shows up directly in breach costs." A live vulnerability management program is precisely what closes that gap.

Further reading: Types of vulnerabilities

Requirement 5: Protect systems and networks from malicious software

Anti-malware tooling needs to be current and actively updated. PCI DSS 4.0 also explicitly recognizes that anti-malware mechanisms should account for phishing-delivered malware and removable media, reflecting how attackers actually get in now rather than assuming a pure network-perimeter threat model.

Requirement 6: Develop and maintain secure systems and software

This means keeping software patched on a defined schedule and training developers on secure coding. PCI DSS 4.0 added new requirements around protecting payment pages in consumer browsers, specifically requiring a mechanism to detect and respond to unauthorized script changes, a direct response to the wave of e-commerce skimming (Magecart-style) attacks that have hit online retailers. If you are not sure where to start, cyber security companies that specialize in PCI work can scope this properly rather than treating it as a checkbox.

Goal 4: Implement strong access control measures

Access should be restricted to people who genuinely need it for their job function, not granted by default and revoked later.

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

Build access around roles, not individuals. A payments processing role gets access to cardholder data; HR and accounting typically should not, even though they are inside the same company.

Requirement 8: Identify users and authenticate access to system components

Every person with access needs a unique ID, and PCI DSS 4.0 made multi-factor authentication mandatory for all access into the cardholder data environment, a broader reach than the remote-administrative-access-only rule under 3.2.1. This is among the more consequential changes in the 4.0 update, and among the more commonly missed during self-assessment.

Requirement 9: Restrict physical access to cardholder data

Physical security still matters even in a cloud-first world. Card readers, server rooms, and any physical media containing account data need controlled, logged access.

Goal 5: Regularly monitor and test networks

Monitoring exists to catch the thing you did not anticipate. Penetration testing simulates real attacks to find weak points before an actual attacker does.

Further reading: Penetration testing vs vulnerability scanning

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

Centralized logging through a security information and event management (SIEM) platform is still the standard approach. PCI DSS 4.0 tightened log retention and review cadence requirements, and explicitly calls for automated log review mechanisms rather than relying purely on manual analyst review, since manual review at scale simply does not keep pace with modern log volumes.

Requirement 11: Test security of systems and networks regularly

This covers penetration testing, vulnerability scanning, and testing your team's response procedures, beyond the tooling itself. Under 4.0, internal vulnerability scans must now be "authenticated" scans in most cases, meaning the scanner logs in with valid credentials rather than simply probing from outside, which surfaces a different and often larger set of findings than unauthenticated scanning did.

Goal 6: Maintain an information security policy

A written policy that nobody reads is not a policy. This goal is about making sure security expectations are documented, trained on, and actually followed.

Requirement 12: Support information security with organizational policies and programs

Your policy needs to cover every person who touches cardholder data, including third-party vendors and contractors, an area PCI DSS 4.0 pushed harder on with expanded requirements for managing third-party service provider risk. An effective incident response plan spells out who notifies card brands, who handles backups and restoration, and who talks to the public, decided before an incident happens, not during one.

Review your policy at least annually, ideally more often given how quickly the threat picture changes, and get it audited periodically by a QSA or an internal team with no stake in rubber-stamping it.

What this means going forward

The honest takeaway for 2026: PCI DSS 4.0 is not a paperwork refresh of 3.2.1, it materially raises the bar on authentication, encryption validation, and third-party risk management. Organizations that treated the March 2025 deadline as a soft suggestion are now finding gaps during their next assessment cycle. If your last compliance review predates that deadline, it is worth re-scoping now rather than waiting for your acquiring bank to ask why your AoC looks stale.