PCI DSS 4.0 has been fully in force globally since March 31, 2025. By May 2026, every entity touching cardholder data, whether a payment-processing startup or an e-commerce shop accepting card payments, is expected to be compliant against the updated standard. Yet most pre-seed and seed fintech teams are still operating against PCI DSS 3.2.1 mental models. The result: their first formal assessment lands with avoidable failures.
This is not another generic walkthrough of the 12 PCI DSS requirement areas. The PCI Security Standards Council publishes those, and they are exhaustive. This is a focused list of the nine requirements I see pre-seed and seed fintechs most often miss when preparing for their first assessment, drawn from public PCI Council documentation and patterns common across early-stage cloud-native startups.
Each section names the requirement, cites its PCI DSS 4.0 reference, explains why startups miss it, and outlines what "passing" actually looks like at the cloud-native engineering level. Where I am stating practitioner opinion rather than the standard's text, I have labelled it inline.
Quick context: what changed in 4.0
PCI DSS 4.0 was published by the PCI Security Standards Council in March 2022. The transition timeline was: PCI DSS 3.2.1 retired in March 2024, and the "future-dated" requirements (the most operationally demanding changes) became mandatory in March 2025. As of 2026, full 4.0 compliance is required for any merchant or service provider in scope.
Four structural shifts matter for the engineering team:
- Customised approach: a new option (Annex E) that lets entities meet a requirement through alternative controls, provided they document a Targeted Risk Analysis. This is genuine flexibility but it adds documentation overhead.
- Continuous focus, not point-in-time: many controls now require ongoing monitoring rather than annual proof.
- Multi-factor authentication everywhere: no longer just for admin access.
- Stronger cryptography and inventory requirements: full crypto inventories, mandatory keyed hashing, and longer minimum password lengths.
With that frame, here are the nine requirements I see startups miss most.
1. MFA on ALL access to the CDE, not just admin
PCI DSS 4.0 Reference: Requirement 8.4.2
Under 3.2.1, multi-factor authentication was required only for non-console administrative access to the cardholder data environment (CDE) and for remote access. Under 4.0, MFA is required for all access into the CDE, regardless of whether the user is an administrator or a regular employee. This is the single most common gap I see at startups.
The typical failure pattern: the engineering team has MFA enforced on their cloud console (AWS Console, GCP Console) for admin roles via IAM Identity Center or similar. But the backend admin portal that customer support staff use to look up a transaction, a portal that touches cardholder data, only requires a password. That portal is now non-compliant.
What passing looks like: every system that stores, processes, or transmits cardholder data, plus every system connected to the CDE, enforces MFA for all users. For cloud-native startups this typically means: IAM Identity Center with MFA enforced at the SSO layer for all human access, plus application-level MFA on internal admin portals via your auth provider (Auth0, Clerk, WorkOS).
2. Fifteen-character minimum passwords
PCI DSS 4.0 Reference: Requirement 8.3.6
The minimum password length under 3.2.1 was seven characters. Under 4.0 it is fifteen characters (or twelve if combined with other complexity requirements). Most pre-seed startups still have their authentication providers configured to the seven-character minimum that was the industry standard a decade ago.
This sounds trivial. It is not. Changing minimum length triggers password resets for the existing user base, which means a forced support workload spike on the day of the change. Startups that defer this hit the deadline scramble at month eleven of their compliance prep.
What passing looks like: your IdP (Okta, Azure AD, Auth0) password policy is updated to 15-character minimum, and the change is rolled out with sufficient communication time so users do not get locked out. A single configuration change in Auth0 or Okta admin, but plan it for a low-traffic week.
3. Authenticated internal vulnerability scans
PCI DSS 4.0 Reference: Requirement 11.3.1.2
Under 3.2.1, internal vulnerability scans had to be performed quarterly but could be unauthenticated (the scanner did not need to log in to the systems it was scanning). Under 4.0, internal vulnerability scans must be authenticated, meaning the scanner runs with credentials that allow it to inspect the actual configuration of each host.
The failure mode: startups run Nessus, Qualys, or Tenable scans without configuring credentialed scanning, then submit the results as evidence. The auditor flags this immediately. Authenticated scanning surfaces a different (and larger) set of findings, because it can read configuration files, package versions, and patch levels that surface scanning cannot see.
What passing looks like: your vulnerability scanner is configured with a dedicated service account on each in-scope host (or via cloud-native agents) that has read-only access to package managers, registry/config stores, and OS-level metadata. Scans run quarterly minimum, and reports are reviewed within an SLA. For containerised workloads this typically means using AWS Inspector or equivalent.
4. Targeted Risk Analysis documentation
PCI DSS 4.0 Reference: Requirement 12.3.1
Under 4.0, the entity must perform and document a Targeted Risk Analysis (TRA) for every requirement where it uses the customised approach (Annex E), and for every compensating control. The TRA must justify the risk-equivalence of the alternative control compared to the defined approach.
Most startups discover this requirement on the day they realise a particular defined-approach control will not work for them. They reach for the customised approach as a workaround, then learn that customised approach requires extensive TRA documentation: threat modelling, control effectiveness analysis, residual risk justification, annual review.
What passing looks like: a documented TRA for each requirement where you deviate from the defined approach. The PCI Council publishes a TRA template; use it. The TRA is a written artefact, not a verbal explanation to the auditor. Annual review is required, so calendar a TRA refresh review every twelve months.
Practitioner opinion: for a pre-seed startup, the customised approach is usually not worth the documentation overhead. Stick to the defined approach wherever possible and only invoke customised approach for the one or two genuinely awkward controls.
5. Detection of changes to payment pages (anti-skimming)
PCI DSS 4.0 Reference: Requirements 6.4.3 and 11.6.1
This is the single most consequential new requirement in 4.0 for e-commerce merchants and payment-page integrators. The standard now requires:
- Req 6.4.3: a mechanism to authorise all scripts loaded on payment pages, plus an integrity check to detect unauthorised script changes.
- Req 11.6.1: a change-and-tamper-detection mechanism that alerts the entity to unauthorised modifications of HTTP headers or the payment-page DOM.
The threat being mitigated here is Magecart-style attacks, where a malicious script is injected into a payment page and silently exfiltrates card data to an attacker-controlled domain. Most startups have no monitoring at all on their payment-page integrity.
What passing looks like: implementation of either Content Security Policy with strict source allowlisting, Subresource Integrity (SRI) hashes for every third-party script, or a payment-page monitoring tool (Source Defense, Imperva Client-Side Protection, Akamai Page Integrity Manager) that detects DOM/script changes in real time. For a pre-seed shop the cheapest viable path is CSP plus SRI, configured carefully and tested against the actual payment integration (Stripe, Razorpay, Adyen). Many fintechs offload this entirely to the payment processor by using a hosted payment page (Stripe Checkout, Razorpay Standard Checkout) where the merchant page never directly handles the card data, narrowing PCI scope.
6. Cryptographic inventory
PCI DSS 4.0 Reference: Requirement 12.3.3
The entity must maintain a documented inventory of all cryptographic cipher suites and protocols in use, reviewed at least annually. This includes both data-at-rest and data-in-transit cryptography, across all systems in scope.
Most cloud-native startups have no formal inventory. They know "we use TLS 1.2 or higher" and "we encrypt with AES-256" but cannot produce a written document listing: which TLS versions are enabled on which load balancers, which cipher suites are accepted, which KMS keys exist, which symmetric and asymmetric algorithms are used by which application, which hash functions are used for password storage, what the key rotation schedule is for each key.
What passing looks like: a single document (typically a spreadsheet or a Confluence page) listing every cryptographic algorithm, cipher suite, and key in use across the in-scope environment, mapped to the system that uses it, the rotation schedule, and the responsible team. Reviewed annually with a documented sign-off. This document is one of the highest leverage compliance artefacts to build early because it surfaces weak-cipher misconfigurations that would have been failures regardless of PCI DSS.
7. Anti-phishing controls
PCI DSS 4.0 Reference: Requirement 5.4.1
The entity must deploy automated mechanisms that detect and protect personnel against phishing attacks. This is a new explicit requirement in 4.0; under 3.2.1, anti-phishing was implicit under broader malware-protection language.
Most startups rely on the default phishing protection that ships with Google Workspace or Microsoft 365. That default is good but does not by itself satisfy the requirement. The standard expects active configuration plus visible evidence of detection capability.
What passing looks like: a documented anti-phishing technology stack (the email provider's protection settings, configured rather than at default, plus optionally a dedicated tool like Abnormal Security, Material Security, or Tessian for higher-risk environments) and quarterly phishing simulation runs with results tracked. For a pre-seed team, the cheapest viable path is enabling Google Workspace's advanced phishing protection settings (Strict mode, external sender warnings, encrypted external email warnings) plus running a quarterly phishing simulation via a free tier of KnowBe4 or GoPhish.
8. Manual code review for bespoke software in the CDE
PCI DSS 4.0 Reference: Requirement 6.2.4
Under 4.0, software developed internally for use in the CDE (custom and bespoke software) must be reviewed at least annually using either manual code review by qualified personnel or automated tools (or both). The wording is important: "either" is acceptable, but pure reliance on automated SAST scanning without any manual review is not sufficient if the SAST tool has known limitations on the language or framework used.
The failure pattern: a startup runs GitHub Advanced Security or Snyk Code, generates a clean scan report, and assumes that suffices. The auditor asks: what does the SAST tool's documentation say about its coverage of your stack? If there are known gaps (and there always are: SAST tools struggle with custom DSLs, complex business-logic vulnerabilities, and certain serverless patterns), some level of manual review is required to compensate.
What passing looks like: automated SAST in CI/CD (GitHub Advanced Security, Snyk, Semgrep), plus an annual targeted manual review of the in-scope code paths by either a qualified team member or an external code-review service. Documented review notes, not just the SAST report.
9. Continuous monitoring for service providers
PCI DSS 4.0 Reference: Requirement A.3.5
For entities that meet the definition of a service provider (which includes most B2B fintech startups that process or store cardholder data on behalf of another entity), 4.0 introduces continuous monitoring obligations that go beyond the annual assessment. Service providers must perform and document ongoing reviews of their PCI DSS scope, the in-scope systems, and the effectiveness of their controls.
Pre-seed and seed fintechs often miss this because they treat PCI DSS compliance as a one-and-done event (pass the assessment, file the AOC, ship). The standard now expects ongoing operational rigour: quarterly internal reviews of scope changes, ongoing control effectiveness validation, change-driven re-assessment when the architecture shifts.
What passing looks like: a documented quarterly compliance review cadence with assigned owner, output artefacts (a quarterly compliance status report), and evidence of scope re-validation when significant architectural changes occur. This is calendar discipline more than engineering work, but startups that skip it find themselves scrambling to reconstruct evidence at re-assessment time.
The honest summary table
| Most-missed requirement | PCI 4.0 Section | Typical fix effort |
|---|
| MFA on all CDE access, not just admin | 8.4.2 | 1-2 weeks (IdP reconfiguration + comms) |
| 15-character minimum passwords | 8.3.6 | 1 day (IdP config) + 1-2 weeks for rollout |
| Authenticated internal vulnerability scans | 11.3.1.2 | 2-4 weeks (scanner credentials, agent rollout, baseline) |
| Targeted Risk Analysis documentation | 12.3.1 | 1-2 weeks per TRA (compounds quickly) |
| Payment-page change detection (anti-skimming) | 6.4.3 / 11.6.1 | 2-6 weeks (CSP + SRI + monitoring tool) |
| Cryptographic inventory | 12.3.3 | 1-2 weeks (audit + documentation) |
| Anti-phishing controls | 5.4.1 | 1 week (Workspace/M365 config + sim setup) |
| Manual code review for bespoke software | 6.2.4 | Annual; 1-2 weeks per cycle |
| Continuous monitoring (service providers) | A.3.5 | Ongoing; quarterly cadence |
Stage-specific recommendation
If you are a pre-seed fintech (under 15 engineers) just starting PCI DSS scoping: reduce scope first. Use a hosted payment page (Stripe Checkout, Razorpay Standard, Adyen Drop-in) so your application never touches raw card data. This narrows PCI scope dramatically, typically from SAQ D to SAQ A or A-EP. Several of the requirements above either drop out of scope or become straightforward at that lower SAQ tier.
If you are a seed fintech processing card data through your own systems (SAQ D-merchant or SAQ D-service-provider): the nine requirements above are your highest-priority gaps. Order of operations: passwords (Req 8.3.6, fastest) and MFA (Req 8.4.2, near-fastest), then payment-page anti-skimming (Req 6.4.3 / 11.6.1, the highest-risk if missing), then cryptographic inventory (Req 12.3.3, foundational documentation), then the rest in the order above.
If you are a service-provider fintech with enterprise customers asking for AoC: the continuous-monitoring requirement (A.3.5) is your enterprise-customer-facing signal. Build the quarterly review cadence early. Enterprise procurement teams will ask for evidence of ongoing compliance posture, not just an annual certificate.
The trap: assuming PCI DSS is a 12-month project
The most expensive mistake I see Indian and GCC fintech founders make is treating PCI DSS compliance as a 12-month preparation project culminating in an audit. The reality is closer to: PCI DSS becomes a baseline operational rhythm from the day cardholder data first touches your infrastructure. The annual assessment is just the visible checkpoint.
The startups that pass cleanly are not the ones who hire a consultant for a final-month sprint. They are the ones who built the controls in continuously from week one of touching card data. The gap requirements above are the ones that compound when deferred: passwords, MFA, crypto inventory, and TRA documentation all become exponentially harder to retrofit after the system has grown.
If you want a second opinion on your PCI DSS 4.0 scope and gaps
MatrixGard runs a free 20-minute PCI DSS scope and gap-readiness audit for pre-seed and seed fintech founders. Your specific cardholder data flow, your current SAQ tier, your most likely gaps against the 4.0 requirements, my honest read in 20 minutes. No NDA required for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. All requirement references taken from the PCI DSS v4.0 specification as published by the PCI Security Standards Council. The "most missed" framing is a practitioner opinion based on pattern frequency, not a published PCI Council statistic. Fix-effort estimates are practitioner ranges; actual effort varies with architecture and team maturity. The list is not exhaustive; PCI DSS 4.0 contains 64 distinct requirements across 12 control areas, and full compliance requires meeting all applicable controls for the entity's SAQ tier.
