PCI DSS Compliance:Process Card PaymentsWithout the Liability
PCI DSS isn't law — it's the contract you sign with the card brands when you touch payment card data. The penalties for non-compliance go through your acquirer: fines, fees, and the right to stop processing your transactions.
Book a call
[01] Why Companies Comply with PCI DSS
PCI DSS keeps you on the card networks, limits post-breach magnitude, rewards aggressive scope reduction, and overlaps so heavily with ISO 27001 and SOC 2 that one security programme can serve all three.
// The Reality
PCI DSS isn't law — it's the contract every merchant and service provider signs with the card brands through their acquirer. Visa, Mastercard, American Express, Discover, and JCB enforce it through fines, monitoring, and the right to stop processing your transactions.
// Business Impact
Non-compliance lands as monthly fines from your acquirer, mandatory remediation, and — for repeat or serious failures — termination of your merchant agreement. Lose your ability to take cards and the business stops.
// Who Enforces What
- Acquirer / payment processor: front line, monthly fines, validation tracking
- Card brands: program-level rules, fines, and brand-specific obligations
- PCI SSC: maintains the standard, certifies QSAs and ASVs
- Issuer: enforces brand rules for cards they issue
// Strategic Advantage
Clean PCI alignment lets you switch acquirers, negotiate processing rates, and expand internationally without renegotiating compliance posture from scratch.
[02] What PCI DSS Actually Is
PCI DSS is six control objectives and twelve requirements: the objectives describe what the standard is trying to achieve, and the requirements are the specific things your QSA tests when the annual assessment comes around.
Objective 1
Build and Maintain a Secure Network and Systems
Network segmentation, firewalls ("network security controls" in v4 terms), and hardened system configurations protect the cardholder data environment from network-borne attack.
Objective 2
Protect Account Data
Cardholder data at rest is encrypted, hashed, tokenized, or truncated; data in transit is protected with strong cryptography over open, public networks.
Objective 3
Maintain a Vulnerability Management Program
Anti-malware controls and a continuous vulnerability management programme keep systems patched against the threats actually exploited in the wild.
Objective 4
Implement Strong Access Control Measures
Logical and physical access to cardholder data is restricted by business need-to-know, every user has a unique identity, and authentication is strong enough for what is being accessed.
Objective 5
Regularly Monitor and Test Networks
Continuous logging and monitoring detect security events; regular scanning, segmentation testing, and an annual penetration test validate that the controls work.
Objective 6
Maintain an Information Security Policy
An information security policy, supported by risk assessment, incident response, third-party management, security awareness, and an annual review cycle, anchors the entire programme.
[03] Understanding the PCI Programme
PCI DSS isn't a one-time certificate — it's an annual assessment wrapped around continuous operational obligations: quarterly scans, daily log review, ongoing change management, and an Attestation of Compliance that lives or dies on the evidence behind it.
[1/7] CDE SCOPING & DATA FLOW MAPPING (WEEK 1-3)
Define the cardholder data environment. Find every place card data enters, sits, or leaves — including paper, voice, email, and shadow systems. Scope reduction lives or dies in this phase.
// What Happens
A defensible CDE diagram and a defensible answer to "where is cardholder data?" — including the obvious places and the awkward ones.
// Deliverables
- Cardholder data flow diagram(s)
- Network diagram with CDE boundary
- Inventory of systems, people, and processes in scope
- Connected-to and security-impacting systems list
- Scope reduction roadmap (tokenization / hosted fields / segmentation)
// Effort
- Timeline: 2-3 weeks
- Your involvement: 15-20 hours
// activities
- Data Flow Mapping: Every path CHD travels, including paper and voice
- Network Diagrams: Current and target state of segmentation
- Connected Systems: "Connected-to" and "security-impacting" inventory
- Scope Reduction Plan: Tokenization, hosted fields, P2PE where applicable
- Out-of-Scope Validation: How you'll prove what's not in scope
[05] A Smarter Security Investment
When platform, service, and execution are considered together, Konfirmity delivers security and compliance with fewer tradeoffs and clearer long-term costs.
DIY Manual
Platform
None
Service
None
Audit
$15K
Year 1 total
$15K
Annual
$5K
Generic Platform
Platform
$25K
Service
None
Audit
$15K
Year 1 total
$40K
Annual
$30K
Traditional Consultant
Platform
None
Service
$50K
Audit
$15K
Year 1 total
$65K
Annual
$25K
Konfirmity
Platform
Included
Service
Included
Audit
$15K
Year 1 total
$50K
Annual
$35K
[05] FAQ's
What PCI DSS Actually Involves
Merchants are classified into four levels by Visa/Mastercard transaction volume — Level 1 (6M+/year), Level 2 (1M–6M), Level 3 (20K–1M e-commerce), Level 4 (everyone else). Service providers are Level 1 (300K+ transactions of any kind annually for a brand) or Level 2 (below that). Your level determines whether you do a SAQ or a full ROC.
Depends on how you take cards. SAQ A: outsourced e-commerce, no CHD touches your systems. A-EP: e-commerce that affects security of payment page but doesn't store/process/transmit CHD. B and B-IP: imprint machines / standalone IP terminals. C and C-VT: payment apps and virtual terminals. D: everyone else — including Level 2 merchants and most service providers. The SAQ choice drives 90% of the controls you have to validate.
Yes — and aggressively. Using a PCI-validated processor's hosted fields, iframes, or redirect checkout moves you toward SAQ A or A-EP, with a fraction of the controls of SAQ D. The CHD never touches your servers; their systems carry the bulk of the assessment. The trade-off is checkout UX flexibility and dependence on the processor's roadmap.
If you take card payments, you need PCI — the card brands' contract doesn't accept SOC 2 as a substitute. If you sell B2B in the US, you'll also be asked for SOC 2. The good news: the underlying controls overlap heavily (access, logging, vulnerability management, change control), so one operating cadence supports both annual cycles. PCI doesn't replace SOC 2 and vice versa.
v4.0 was released in March 2022, v4.0.1 in June 2024. v3.2.1 was retired on 31 March 2024. New in v4: a "customized approach" alternative to prescriptive requirements (must be backed by a targeted risk analysis), stricter authentication (MFA expanded), continuous monitoring obligations, and explicit requirements around phishing protection and e-commerce skimming. Many v4 "future-dated" requirements became mandatory on 31 March 2025.
An ASV (Approved Scanning Vendor) is a PCI SSC-certified company qualified to perform the quarterly external vulnerability scans required by Requirement 11. A QSA (Qualified Security Assessor) is an individual or company qualified to perform full Reports on Compliance for Level 1 merchants and service providers, and to validate complex SAQ scenarios. You always need an ASV if you have any external CDE-facing IPs; you only need a QSA at Level 1 or when scope complexity demands it.
[07] get started
Get started in the way that fits you best -- see the platform in action, speak directly with a security expert, or get real proof through a free external scan of your environment.
See the platform in action. We'll show you:
Adaptation to your specific stack
Integration with your existing tools
Custom evidence collection workflows
Dashboard views for stakeholders
Speak directly with one of our security experts:
Security program design for your industry
Compliance roadmap (SOC 2 → ISO)
Risk assessment and treatment planning
Vendor security review guidance
Want proof? We'll scan your surface for free:
Exposed assets and misconfigurations
SSL/TLS vulnerabilities
Vendor risk in your supply chain
Comparison to industry benchmarks