PCI DSS readiness · how to complete it

Your PCI self-assessment, scoped and honest.

Your PCI DSS readiness assessment is a gap analysis built from your own answers against the twelve PCI DSS v4.0.1 requirements — scoped to how your business actually takes payment, so you're not answering for controls that don't apply to you. This page walks you through the worksheet: how scope works, what each status means, the evidence to have in hand, and the rows merchants most often get wrong. Plan on a half-day for a short SAQ, longer for SAQ D.

The three steps

Confirm your scope first. Your worksheet arrives pre-scoped to how you take cards — e-commerce redirect, hosted POS, virtual terminal, phone — which sets your SAQ type. Requirements that don't apply to your environment come marked Not Applicable with a rationale for you to confirm, not write from scratch.
Mark a status for every in-scope control — Compliant, Partial, or Gap — with a short note on how you meet it (the tool, policy, or evidence) and, for a Partial or Gap, how bad it is. Every row starts as Not Assessed; none should still say that when you send it back.
Send the completed worksheet back. It comes back to you as a gap-analysis report: every Gap ranked by severity, mapped to its requirement, with a remediation step and the SAQ you're working toward.

What each status actually means

COMPLIANT

The control is in place across your whole cardholder data environment (CDE) and you could evidence it to an assessor. Example: MFA is enforced for every login into the CDE, admin and user alike (8.4.2), not just remote access.

PARTIAL

The control exists but not everywhere it needs to, or not consistently. Example: MFA covers administrators but not all users into the CDE; scans run but findings aren't tracked to closure. Mark it Partial and note what's left — that becomes the smaller step on your plan.

GAP

The control isn't in place, or you can't yet show that it is. When in doubt, mark Gap — an honest gap you can remediate beats a Compliant your acquirer's attestation or a forensic review later reverses.

NOT APPLICABLE

The requirement genuinely can't apply to your scope — and it needs a written reason. Example: no wireless anywhere near the CDE makes the wireless rows (2.3, 11.2) Not Applicable. An N/A with no rationale is treated as a Gap; the rationale is the control. Don't use N/A to sidestep something inconvenient.

Have these in hand before you start

How you accept cards — e-commerce (redirect/iframe or your own page), POS terminals, virtual terminal, phone/mail. This decides your SAQ and most of your scope.
A card-data flow / PAN inventory — everywhere card data is stored, processed, or transmitted, and by what (12.5.1). If you don't know where it flows, you can't scope it.
Your network and CDE diagram — what's in the cardholder data environment and what's segmented out (12.5.2).
Your third-party service providers — payment gateway, hosting, anyone who could touch card data (12.8), and their compliance status.
Your latest ASV scan and penetration-test results, if you have them (11.3 / 11.4).
Who can reach the CDE and how they sign in — accounts, roles, and MFA coverage (7 and 8).

The rows merchants most often misread

Scope and the SAQ (12.5.1 / 12.5.2): the single most consequential answer — an under-scoped CDE makes every other row wrong. If you're not certain a system is out of scope, treat it as in scope until you can prove segmentation.
Stored sensitive authentication data (3.2.1 / 3.3.1): full track data, card verification codes, and PINs must never be retained after authorization, even encrypted. A Gap here is Critical severity even on a small SAQ — check what your systems and logs actually keep.
MFA into the CDE (8.4.1 / 8.4.2): v4 requires MFA for all access into the cardholder data environment, not just remote or admin logins. "We have MFA on email" isn't this.
Payment-page scripts and change detection (6.4.3 / 11.6.1): if you take payment on your own web page, v4 now requires you to inventory and integrity-check the scripts running in the customer's browser and to alert on unauthorized changes at least weekly. Almost everyone misses these two at first.
New-in-v4 rows (5.4.1 anti-phishing, 12.3.1 targeted risk analyses): requirements that didn't exist in v3.2.1, so they get skipped by habit. They're in scope now — answer them on their own merits.

Scope honestly, answer what's true. The report isn't a grade — it's a map to your SAQ. Narrowing your scope on paper or marking a hopeful Compliant doesn't shrink your real exposure; it just moves the discovery to your acquirer's attestation, or to a forensic investigator after an incident — which is exactly the moment this report exists to prevent. Nobody sees your gaps but you.

What happens after you submit

Your completed worksheet is reviewed and returned as a gap-analysis report — every Gap ranked by severity, mapped to its PCI DSS requirement, with a remediation step and the SAQ you're targeting — after it clears our accuracy check and a human review. It is a readiness gap analysis, not a QSA assessment and not an Attestation of Compliance — where formal validation is required, that is completed via the applicable SAQ you attest to, or by a Qualified Security Assessor. We'll tell you plainly which one you need.

A readiness assessment is a planning tool built from your self-reported answers — not an audit, not a certification, and not an Attestation of Compliance. Control references are paraphrased for plain language and reconciled against PCI DSS v4.0.1; the licensed standard governs. Questions? Write alerts@initialeyes.com.