PCI DSS 4.0: what a startup should do in the first 90 days

In the first 90 days of PCI DSS 4.0, a startup should shrink the cardholder data environment, inventory every system and payment page script that touches card data, close the gaps, and start keeping evidence. Version 4.0 is the only active standard, and its future-dated requirements are now mandatory in assessments.

What does "PCI DSS 4.0" mean for you today?

Two dates matter. The PCI Security Standards Council says v4.0 became the only active version when v3.2.1 was retired on 31 March 2024. The future-dated requirements, which started as optional good practice, became required on 31 March 2025. If a customer or acquirer asks for PCI evidence now, you are measured against all of it.

Your validation path (which self-assessment questionnaire, or a full report) depends on how you take cards and what your acquirer or payment provider requires. Ask them in week one. Do not guess.

Days 1 to 30: scope and inventory

Most startups can cut their PCI burden more by changing architecture than by writing policy. If a hosted payment page or an embedded field from your payment provider captures the card number, your servers may never see it. Fewer systems in scope means fewer controls to evidence.

Then build the inventory you will be asked for:

• Every system that stores, processes or transmits card data, plus systems that connect to them.
• Every third party that touches payment flows, with a contact and a contract owner.
• Every script that loads on a payment page, with a reason it is there.

That last item deserves attention. PCI SSC describes requirements 6.4.3 and 11.6.1 as reducing the risk of e-skimming: payment page scripts must be authorized, checked for integrity, and monitored for tampering. The council notes these were removed from SAQ A but remain in the standard, so check which questionnaire applies to you rather than assuming you are exempt.

Days 31 to 60: close the gaps you can prove

Take your inventory and compare it with the requirements that apply to your validation path. For each gap, write one owner and one date. Typical early fixes for a small team are multi-factor authentication on every administrative path, removing shared accounts, and a patching routine with a record of what was patched and when.

Treat your dependencies as part of that routine. A vulnerable library on a payment page or in a service that handles card data is a finding someone will eventually ask about. A dependency inventory (an SBOM) plus reachability analysis helps you tell which known flaws are actually reachable from your code, so the patch queue reflects real exposure.

Days 61 to 90: evidence on a schedule

Auditors rarely doubt that you did something. They ask for proof that you did it repeatedly. Set a calendar of recurring tasks (access reviews, script inventory reviews, vulnerability scan runs) and store a dated record of each one in a single place. Compliance automation tools can collect some of this for you, but you still own deciding what the control is and who reviews it.

Finish the 90 days with a dry run: pick five requirements at random and see whether a colleague who was not involved can find the evidence in under ten minutes.

What to do

1. Ask your acquirer or payment provider which validation path applies to you.
2. Redraw your payment flow so card data touches as few of your systems as possible.
3. Inventory systems, third parties and payment page scripts, each with an owner.
4. Check that script authorization, integrity and tamper detection are covered if your payment page is yours.
5. Write a gap list with one owner and one date per line.
6. Schedule recurring evidence tasks and store dated records in one place.
7. Run a five-requirement dry run before any assessor arrives.

Quick check

Sources

• PCI SSC blog: guidance for PCI DSS e-commerce requirements effective after 31 March 2025
• PCI Security Standards Council: PCI DSS

Last reviewed: 18 October 2026.