The short answer
PCI-DSS compliance does not have a single timeline. It depends on two things: your merchant or service provider level, and how much of your infrastructure actually touches cardholder data.
A Level 4 e-commerce merchant using a hosted payment page can complete a Self-Assessment Questionnaire (SAQ) in a few days. A Level 1 payment gateway running its own card vault needs 6 to 12 months for a full QSA-led audit, and that assumes the team is organized and responsive.
Here is a rough breakdown:
| Level | Who qualifies | Assessment type | Typical timeline |
|---|---|---|---|
| Level 1 | Over 6 million Visa/MC transactions per year, or any breach history | On-site QSA audit + Report on Compliance (RoC) | 6 to 12 months |
| Level 2 | 1 to 6 million transactions per year | SAQ or QSA audit (acquirer's call) | 3 to 6 months |
| Level 3 | 20,000 to 1 million e-commerce transactions per year | SAQ | 4 to 12 weeks |
| Level 4 | Under 20,000 e-commerce or up to 1 million other transactions | SAQ | 1 to 6 weeks |
These are total timelines from gap assessment to signed evidence, not just the assessment itself. How long remediation takes is the variable that most teams underestimate.
Merchant levels and what each actually requires
PCI-DSS defines levels by transaction volume across Visa, Mastercard, and other card brands. The thresholds above are for Visa and Mastercard; Amex and Discover have their own level definitions, though the boundaries are similar.
Level 1 is the most demanding tier. You need a Qualified Security Assessor (QSA) to conduct an on-site audit and produce a Report on Compliance. You also need a quarterly network scan by an Approved Scanning Vendor (ASV) and an annual penetration test.
Level 2 and 3 merchants can typically self-assess using an SAQ, but many acquirers require an Attestation of Compliance (AoC) signed by a QSA as well. Check with your acquiring bank before assuming the SAQ alone is enough.
Level 4 is the most common tier for Vietnamese e-commerce companies and small fintechs. SAQ plus quarterly ASV scans is the standard requirement.
Note: if you are a service provider (payment processor, gateway, hosting provider) rather than a merchant, the thresholds are different. Service providers processing over 300,000 transactions per year are Level 1. Below that is Level 2. Service providers face stricter requirements than merchants at equivalent levels.
Scope reduction: the biggest lever you have
Most teams focus on meeting requirements. The better question is: how much of your infrastructure do those requirements apply to?
Your cardholder data environment (CDE) is the set of systems that store, process, or transmit cardholder data, plus anything that can reach those systems. Every system inside the CDE is subject to all 12 requirement groups. Every system outside the CDE is not.
This is where you can compress your timeline significantly.
If your payment flow routes card numbers through your own servers, your CDE could include your application servers, databases, load balancers, CI/CD pipelines, developer laptops with production access, and anything on the same network segment. That is a large audit surface.
If you redirect users to a hosted payment page (like Stripe Checkout, PayOS, or a bank's hosted form) and never touch raw card data yourself, your CDE can shrink to near zero. You still need to complete an SAQ, but you use SAQ A, which has only 22 controls versus 300+ for SAQ D.
Three mechanisms commonly reduce scope. Hosted payment pages (iFrame or redirect) mean card data never hits your servers. Certified point-to-point encryption (P2PE) solutions can cut scope substantially for physical card acceptance. Tokenization replaces PANs (primary account numbers) with tokens in your systems so only your payment processor ever handles the real card data.
Spending 2 to 4 weeks on scope reduction before starting any remediation work is usually worth it. Reducing the CDE from 40 systems to 8 can turn a 9-month Level 2 project into a 3-month one.
The 12 PCI-DSS v4.0 requirements and which ones take longest
PCI-DSS v4.0 organizes controls into 12 requirement groups. Not all of them are equally time-consuming.
| Requirement | Topic | Typical effort for a Level 2 fintech |
|---|---|---|
| 1 | Install and maintain network security controls | High: network segmentation design takes weeks |
| 2 | Apply secure configurations to all system components | Medium: hardening guides exist, but rollout takes time |
| 3 | Protect stored account data | High if you store PANs; low if you use tokenization |
| 4 | Protect cardholder data with strong cryptography in transit | Low to medium: mostly TLS configuration |
| 5 | Protect all systems against malware | Low: deploy EDR, configure scans |
| 6 | Develop and maintain secure systems and software | Medium to high: SDLC changes and web app scanning |
| 7 | Restrict access to system components by business need | Medium: RBAC review across all CDE systems |
| 8 | Identify users and authenticate access | Medium: MFA rollout for all CDE access |
| 9 | Restrict physical access to cardholder data | Low for cloud-native companies |
| 10 | Log and monitor all access to system components | High: log aggregation, SIEM, and 12-month retention |
| 11 | Test security of systems and networks regularly | High: pen testing, ASV scans, IDS/IPS |
| 12 | Support information security with organizational policies | Medium: policy writing, training, vendor reviews |
Requirements 1, 10, and 11 consistently take the most calendar time. They require infrastructure changes, vendor procurement, and scheduled testing cycles that cannot be rushed regardless of how much engineering effort you throw at them.
Where fintech and payment companies typically get stuck
Network segmentation (Req. 1). Many Vietnamese fintechs start with flat networks or cloud VPCs without proper isolation. Designing and implementing segmentation that actually contains the CDE, then proving it works through pen testing and firewall review, is often the single longest task in a PCI project. Teams that underestimate this regularly add 6 to 10 weeks to their timeline.
Logging and monitoring (Req. 10). PCI-DSS requires centralized logging of all access to CDE systems, with 12 months of retention (3 months immediately accessible). For companies that do not already have a SIEM or centralized log management, standing one up, tuning it to reduce noise, and documenting review procedures takes 4 to 8 weeks. QSAs also want evidence that you actually review logs, not just that you collect them.
Penetration testing (Req. 11.4). You need both an external pen test and an internal pen test, plus segmentation testing if you claim network isolation as a scope reduction. Finding a qualified vendor, scoping the test, running it, reviewing the report, remediating findings, and running a retest adds 6 to 10 weeks to the process. This cannot start until your network segmentation is in place, which creates a dependency chain.
Software security and SDLC (Req. 6). Web application scanning and code review requirements catch teams that have never formalized their development process. QSAs look for evidence that security testing happens before deployment, not just after. Retrofitting this into an existing pipeline takes longer than building it into a new one.
Vendor management (Req. 12.8). You need written agreements with every third party that could affect the security of your CDE. For a typical fintech, that includes your cloud provider, payment processor, monitoring tools, and any SaaS product with production access. Chasing vendors for signed agreements, reviewing their AoC or SOC 2 reports, and documenting the outcome is a dull but time-consuming task.
SAQ options: which one applies to you
If you qualify for self-assessment, you need to pick the right SAQ type. Using the wrong one (typically SAQ D when you qualify for SAQ A) wastes months of effort.
| SAQ type | Who it is for | Number of controls |
|---|---|---|
| SAQ A | Card-not-present merchants; all cardholder data handled by PCI-compliant third parties; no electronic storage of card data | 22 |
| SAQ A-EP | E-commerce merchants with payment page scripts that could affect the transaction (even if hosted by a third party) | 191 |
| SAQ B | Merchants using imprint machines or standalone dial-out terminals only; no electronic cardholder data storage | 41 |
| SAQ B-IP | Merchants using standalone IP-connected POS terminals; no electronic storage | 83 |
| SAQ C | Merchants with payment application systems connected to internet; no electronic cardholder data storage | 160 |
| SAQ C-VT | Merchants using web-based virtual terminal accessed via browser only | 65 |
| SAQ D (Merchant) | All other merchants not covered above | 285 |
| SAQ D (Service Provider) | All service providers eligible for SAQ assessment | 285+ |
The most common scenario for Vietnamese e-commerce companies using a third-party payment gateway (VNPAY, MoMo, or a bank's hosted checkout) is SAQ A, provided the gateway handles all cardholder data entry and your site only receives a token or redirect response.
If your checkout page loads a JavaScript snippet from the payment provider and that script could be modified to capture card data (a Magecart-style attack vector), the card brands now classify you as SAQ A-EP, which has far more controls. This is a judgment call that your acquirer or QSA will make.
PCI-DSS v4.0: what changed and what it means for your timeline
PCI-DSS v4.0 was published in March 2022. Version 3.2.1 officially retired on March 31, 2024. All assessments now use v4.0.
The structural change in v4.0 is the introduction of a customized approach: instead of prescriptive controls, large organizations can define their own controls that achieve the same objective, provided they can prove it to a QSA. For most fintechs, the defined approach (follow the standard controls) remains simpler and faster.
Several new or significantly revised requirements in v4.0 affect timelines. Multi-factor authentication is now required for all access into the CDE, not just remote access, so if your internal admin tools lack MFA, that is a remediation item. Web application firewalls are required if your web apps can be reached from untrusted networks. Script management for public-facing pages means you must maintain an inventory of all authorized scripts and review them for tampering, which affects SAQ A-EP and SAQ D merchants. For several controls, v4.0 also allows you to set your own frequency based on a formal risk analysis rather than PCI's default intervals; useful for organizations with mature risk programs, but it adds documentation overhead for those without one. Finally, phishing-resistant authentication is a future-dated requirement. As of v4.0.1 (published June 2024), some new requirements have a compliance date of March 31, 2025, while others extend to March 31, 2026. Check the v4.0.1 summary of changes for which items still have a future-dated deadline.
For a company starting a PCI project today, the practical implication is that v4.0 covers more ground than v3.2.1 in areas like authentication, software security, and log management. Plan for that extra surface area in your remediation estimate.
Maintaining compliance: what happens after you get certified
Compliance is not a one-time event. The ongoing calendar looks like this:
| Activity | Frequency | Notes |
|---|---|---|
| ASV external vulnerability scan | Quarterly | Must use an Approved Scanning Vendor; clean scan required before each annual assessment |
| Internal vulnerability scan | Quarterly | Can be self-performed with approved tooling |
| Penetration test (external and internal) | Annual (or after significant changes) | Segmentation testing required if you use network isolation for scope reduction |
| SAQ or QSA audit | Annual | SAQ is self-attested; Level 1 requires QSA on-site |
| Log review | Daily (per Req. 10) | Automated alerting typically covers this, but QSAs look for evidence of human review |
| Access review | At least every 6 months | Review of all CDE user accounts and privileges |
| Policy and procedure review | Annual | All security policies must be reviewed and updated |
| Vendor compliance review | Annual | Confirm third-party AoCs and agreements are current |
The biggest operational mistake teams make after certification is treating the annual assessment as the only compliance task. By the time a QSA arrives, you want 12 months of clean quarterly scans, documented log reviews, and evidence of access reviews already on file. Scrambling to produce this in the 30 days before an assessment adds unnecessary stress and sometimes surfaces real gaps that delay certification.
Where pTrackly fits in
The tasks that typically extend PCI timelines are not technically hard. They are organizationally hard: tracking remediation items, collecting evidence, chasing vendors, and maintaining a continuous evidence record across multiple teams.
pTrackly is a compliance management platform built for this kind of work. It maps your controls to PCI-DSS v4.0, tracks evidence collection against each requirement, and gives you a live view of where your gaps are at any point in the project. For teams running their first PCI assessment, having that structure from day one avoids the common pattern of discovering in week 10 that weeks 1 through 6 produced no auditable evidence.
The actual technical remediation still takes the time it takes. But the coordination overhead that typically adds 4 to 8 weeks to a project is where good tooling makes a real difference.
If you are starting a PCI project and are not sure which level applies to you or how large your CDE actually is, a scoping exercise is the right first step. Start there before committing to any timeline.