PCI DSS Software Development & Compliance for FinTech, E-commerce and SaaS Handling Cardholder Data

PCI SSC defines nine SAQ types. SAQ A applies to e-commerce/MOTO merchants that fully outsource cardholder data handling to a PCI-validated third party (hosted payment page, full redirect). SAQ A-EP applies to merchants whose website affects payment but does not receive cardholder data (e.g., JavaScript that posts directly to a processor — the new v4.0.1 added requirements around script integrity here). SAQ B is for imprint or standalone dial-out terminals; SAQ B-IP for standalone IP terminals. SAQ C and C-VT are for payment-application systems and virtual terminals. SAQ D is the full 300+ question monster — every service provider and every merchant that stores cardholder data lands here. We work to push you down the SAQ ladder: tokenisation, iframe/redirect patterns, P2PE-validated terminals (SAQ P2PE), and CDE network isolation typically move a Level 2 merchant from SAQ D to SAQ A-EP or SAQ A.

PCI DSS v4.0 superseded v3.2.1 on 31 March 2024; v4.0.1 (errata release) is now the only valid version. The 'future-dated' new requirements became mandatory on 31 March 2025 — these include targeted risk analyses for every requirement that allows flexibility, automated mechanisms for log review (Req 10.4.1.1), authenticated internal vulnerability scans (Req 11.3.1.2), web-tier script integrity controls (Req 6.4.3 and 11.6.1 — critical for SAQ A-EP), MFA for all access into the CDE (Req 8.4.2/8.5), and a documented assignment of every requirement to a role. We close v4.0.1 gaps and document the targeted risk analyses your QSA will ask for.

QSA (Qualified Security Assessor) is an external assessor certified by the PCI SSC to perform Report on Compliance (RoC) audits — required for Level 1 merchants and most Level 1 service providers. ISA (Internal Security Assessor) is an in-house employee certified to perform internal assessments and sign SAQs on behalf of their employer. ASV (Approved Scanning Vendor) is a separate certification for vendors running quarterly external vulnerability scans per Req 11.3.2 — Qualys, Tenable, Rapid7, and others hold ASV status. You typically need an ASV from day one (quarterly scans), and a QSA only if you are Level 1 or a service provider on the brand's mandated list. We are not a QSA or ASV; we are the team that gets you ready for both and runs the relationship.

PCI DSS scope is defined by the cardholder data environment (CDE) — any system that stores, processes or transmits cardholder data, plus connected systems. Tokenisation replaces the PAN with a non-sensitive token issued by a PCI-validated tokenisation service; if PAN never touches your systems (or only touches a tightly bounded vault), most of your stack is descoped. P2PE (Point-to-Point Encryption) is a PCI SSC validated solution that encrypts card data at the terminal hardware with a key your systems cannot decrypt — qualifying merchants drop to SAQ P2PE (~35 controls vs 300+). We design the tokenisation/P2PE architecture, document the scope reduction in a written scoping memo your QSA will accept, and segment the residual CDE behind firewalls/VPC peering with documented flow controls.

Layered: PCI DSS protects cardholder data at rest and in motion; PSD2 Strong Customer Authentication (SCA) governs how a payer authenticates a transaction in the EEA/UK (and EMV 3-D Secure 2.x is the technical protocol that delivers it); GDPR adds personal-data obligations on top of PCI — PAN is personal data under GDPR. SOC 2 CC and C controls overlap with PCI Req 7, 8, 10, 12 by ~60%. We build a single integrated controls map: SCA flows, 3DS exemptions, GDPR Article 6 lawful basis for payment processing, PCI DSS encryption and access controls, and SOC 2 evidence — all aligned so the same control discharges multiple obligations.

Three scoped phases, with the budget for each agreed before work starts. Scoping (2–3 weeks): CDE mapping, SAQ-eligibility decision, scope-reduction architecture memo (tokenisation, redirect, P2PE), gap analysis against the applicable SAQ controls, remediation roadmap. Implementation (8–12 weeks): network segmentation, MFA on all CDE access, encryption (FIPS 140-2/3), logging per Req 10 with automated review, secure development per Req 6, vendor management per Req 12.8, web-tier script controls per Req 6.4.3/11.6.1, and the PCI DSS policy pack. Annual SAQ Renewal: ASV scan oversight (quarterly throughout the year), targeted risk-analysis refresh, SAQ completion and AOC sign-off support. Each phase is fixed-scope with a budget agreed up front and no enterprise markup; QSA fees billed separately by the QSA firm.

Merchants accept payment cards for goods or services. Service providers store, process or transmit cardholder data on behalf of another entity — including hosting companies, payment facilitators, managed security services and software vendors whose products touch the CDE. Service providers face higher standards: Level 1 service providers must complete an annual Report on Compliance (RoC) rather than an SAQ; segmentation testing every six months (vs annually for merchants); quarterly personnel acknowledgement of PCI policy responsibility; and a designated security officer per Req 12.4.2. If your product is sold to merchants or other service providers and touches their cardholder data flows, you are a service provider. We assess which designation applies in the scoping engagement and build the programme accordingly.

Yes. All three major clouds publish PCI DSS Responsibility Matrices that specify which controls are inherited from the cloud provider versus which remain the customer’s obligation. Physical security (Req 9), hardware maintenance and hypervisor isolation are generally inherited; network segmentation, IAM, encryption key management, logging and all application-layer controls remain the customer’s. AWS, GCP and Azure each publish their own AOC and responsibility matrix. We build your CDE on the applicable cloud landing zone using PCI DSS-in-scope services (e.g., AWS KMS with FIPS 140-2 Level 3 validated HSMs), document the inherited controls in the scoping memo, and implement the remaining customer obligations with QSA-defensible evidence.

For a merchant moving to SAQ A-EP via tokenisation and redirect checkout: 8–12 weeks end to end — 2–3 weeks scoping, 6–8 weeks implementation, then a few days for SAQ completion once controls are in place. For SAQ D (storing cardholder data) or a RoC (Level 1 merchant or service provider): 16–24 weeks is typical, driven by the remediation backlog surfaced in the gap analysis and the QSA’s fieldwork schedule. The main timeline drag is always internal capacity for evidence collection, policy approvals and network change management — not the technical controls themselves. We provide a week-by-week roadmap with owner assignments after the scoping engagement.

A breach before compliance does not pause the PCI obligation — it accelerates it. Card brand fines for non-compliance and breach typically range from $5,000 to $100,000 per month per brand; post-breach forensic assessment (PFI — Payment Card Industry Forensic Investigation) is mandatory and must be performed by a QSA with PFI credentials. The PFI determines whether the breach was in-scope for PCI DSS requirements and which controls failed. From an engineering standpoint, the remediation priority after containment is the same control list we implement in a normal engagement — but under time pressure, with a PFI investigator reviewing evidence and a card brand compliance manager involved. We are not a PFI firm; in a breach scenario we work alongside your legal team, the acquiring bank and the PFI to close the technical gaps and rebuild the CDE on the scoped architecture. The best time to remediate is before the breach.