Make your PCI DSS scope smaller — then meet it.

No, and neither will anyone else. PCI SSC doesn't issue compliance certificates or permit its logos on documents claiming compliance. It recognizes four things as evidence of validation: the Report on Compliance (ROC), the Self-Assessment Questionnaire, the Attestation of Compliance (AOC) and the ASV Attestation of Scan Compliance. What you end up holding is a signed AOC. SecWiz is neither a QSA Company nor an Approved Scanning Vendor, so we prepare you for the signatures instead of providing them.

No, that date has passed. Since 31 March 2025 the 51 requirements introduced in v4.x as best practices have been mandatory, and every assessment scores them. The v4.0.1 PDF, published in June 2024, still prints the best-practice note beside dozens of requirements, but those notes date from publication. They are not live grace periods. If your last gap analysis assumed the grace period, expect 8.4.2, 6.4.2, 6.4.3, 11.6.1 and 10.4.1.1 to come back as failures.

Not out of scope, but close to the smallest scope on offer. Embedded payment pages sit at SAQ A, and since 31 March 2025 SAQ A carries an eligibility criterion that redirect merchants don't have: you must confirm your site isn't susceptible to attacks from scripts that could affect your e-commerce systems. PCI SSC FAQ 1588 gives two ways to meet it: implement 6.4.3 and 11.6.1 style protections yourself, or get written confirmation from a compliant processor that its embedded solution includes script protections. With neither, your SAQ is invalid.

For a mid-sized organization with a genuine CDE and no prior v4.x work, plan 9 to 15 months from kickoff to a signed AOC: scoping and discovery 4 to 8 weeks, gap assessment 8 to 12 weeks, remediation 4 to 9 months, then fieldwork and reporting. Two things stretch it: requirements with a hard technical floor, usually 8.4.2 multi-factor authentication (MFA) for all non-console CDE access, which is architecture rather than configuration; and evidence maturity, because quarterly scan cycles and six-monthly access reviews can't be back-dated. A first ROC inside six months usually means a tiny scope or a plan built on compensating controls.

It reduces scope, sometimes dramatically, but rarely eliminates it. Tokenization removes storage scope and leaves the capture path untouched, so the browser, the form and the transport still count. Outsourcing creates obligations of its own under Requirement 12.8: the provider list, written agreements in which the provider acknowledges responsibility for account data, and ongoing monitoring of their compliance status. Requirement 12.9 applies on top if you're a provider yourself.

Usually the opposite. The customized approach has no printed testing procedures, so your QSA has to derive them for your implementation. You owe a documented targeted risk analysis per control under 12.3.2 plus a controls matrix, and each control must demonstrably meet or exceed the security of the defined requirement. The standard itself says the effort will be greater. Several requirements aren't eligible at all, including the whole of Appendix A2. Nor is it a compensating control: those sit under the defined approach, need a documented technical or business constraint, and are revalidated every year.

No, and it's one of the most common v4.x findings. Requirement 12.3.1 wants a separate targeted risk analysis (TRA) for each requirement that lets you set your own frequency: 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1 and 12.10.4.1. Each names the asset being protected, the threat the requirement guards against and the contributing factors, and is reviewed at least every 12 months. A corporate risk register holds none of that at the detail required. Note that 7.2.5.1 is on the list: only 7.2.4 user account reviews have the fixed six-month cadence.

More than the card brands do. The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025, RBI/DPSS/2025-26/141, issued 15 September 2025, write PCI DSS into the regulator's own rules. Clause 9(a) makes you responsible for your merchants' infrastructure being compliant, so onboarding becomes a verification exercise. Annexure 1 clause 1.5 wants quarterly internal and annual external audit reports, bi-annual vulnerability assessment and security testing, and a PCI DSS compliance report carrying both the AOC and the ROC with corrective actions and closure dates. We run the vulnerability assessment. The security testing goes to an independent provider; we prepare its scope and evidence, as for Requirement 11.4. Merchants you onboarded on or before 31 December 2025 had to meet the due-diligence requirements by 15 September 2026.