>> All posts

So you have to do PCI DSS — here's where to start

May 15, 2026By J. Foster Davis, Co-Founder & COO5 min readComplianceBest practices

Finance, product, or a payment partner just said PCI DSS. Maybe you're taking cards now. Maybe a processor sent a questionnaire. Maybe a customer security schedule name-dropped it. You don't need a memorized requirement encyclopedia today. You need a clear start.

Important: This is orientation for a CIO/CISO, not a substitute for the PCI DSS standard, a QSA, or your acquirer's instructions. Don't implement from a blog. Confirm details with the parties who will judge you.

Core concepts (read this first)

PCI DSS (Payment Card Industry Data Security Standard) is a security standard for organizations that store, process, or transmit cardholder data — or that could affect the security of that data. It's maintained by the PCI Security Standards Council; your acquirer (the bank/processor side of your merchant relationship) and sometimes large customers enforce how you show compliance.

You don't get a universal "PCI certificate" from one global body the way people talk about ISO. Instead you complete the validation path that applies to you, then produce an artifact — commonly a Self-Assessment Questionnaire (SAQ) and/or an Attestation of Compliance (AOC), or a report from a QSA (Qualified Security Assessor) when your path requires an on-site/third-party assessment. Download current forms from the PCI SSC Document Library. Which path applies depends on how you take payments and what your acquirer says. Ask them; don't pick an SAQ type from a blog table.

Scope is everything. "Cardholder data environment" (systems that store/process/transmit account data, plus connected systems) defines how painful this is. Architecture choices — e.g., sending browsers straight to a gateway so raw card numbers never hit your servers — can shrink scope. Draw the flow before you debate requirements.

How often? Validation is typically an annual rhythm (plus ongoing expectations like vulnerability scanning where your path requires it). Confirm cadence and scan rules with your acquirer/assessor — they vary by merchant level and method.

Versions change. The standard is revised over time (you'll hear version numbers in contracts). Use whatever version your acquirer currently requires; don't assume last year's packet still matches.

What the mandate often means in business terms

Someone believes card data (or systems that can affect it) touches your world — and they want the matching SAQ/AOC or QSA outcome, not a vague promise that you're "secure."

Clarify these before you rebuild the world

  1. Why now? New payment feature, customer contract, processor notice, breach anxiety — the driver changes urgency and evidence.
  2. How do cards actually flow today? Draw it on one page: browser → gateway → processor → you. Where (if anywhere) is primary account data present in your environment?
  3. Who is the assessing authority for us? Acquirer? Processor? Customer? Which document did they send?
  4. What deliverable do they want? SAQ type, AOC, full assessment — get the name of the artifact in writing.
  5. What's already outsourced? Payment processors and gateways change your residual responsibility — document what they cover vs what you still own (often the app, integrations, and anything that still touches data).

If you can't draw the data flow, you're not ready to debate requirements.

Who you'll need in the room

  • Executive sponsor (often CIO/CISO + Finance/COO for payment decisions)
  • Owner of the payment architecture (Eng/Product)
  • Security / IT for network, access, logging, vulnerability process
  • Whoever holds the processor/acquirer relationship
  • Qualified help when required — e.g., a QSA when your path calls for one (your acquirer or counsel can tell you if; don't invent the trigger here)

What the journey usually feels like

Timelines vary wildly with scope and card-flow design — ask the party that will accept your paperwork for their expectations. The shape is typically:

  1. Understand card flow & scope — in-scope systems shrink or explode here
  2. Reduce scope where honest — architecture choices (how you accept payments) often matter more than buying tools
  3. Gap look against the required path — whatever assessment type you were told to complete
  4. Remediate & evidence — fix gaps; keep records
  5. Assess / attest — submit or undergo whatever your acquirer/customer requires
  6. Operate — PCI isn't a one-time trophy; expect ongoing obligations (confirm cadence with your assessor/acquirer)

Evidence categories (not a requirement dump)

You'll generally be asked for things like:

  • Network and data-flow diagrams that match production
  • Policy and process records for access, change, vuln management, incident response
  • Technical evidence — configs, scan/test outputs, access reviews, logging samples
  • Third-party artifacts — processor AOCs, contracts, responsibility matrices

If the diagram and production disagree, stop and fix that first.

Common surprises

  • "We're outsourced" ≠ "we're done" — residual duties remain; list them
  • Shadow flows — a marketing site form, an old integration, a support tool that sees card data
  • SAQ / assessment type mismatch — Sales agreed to language that doesn't match your architecture
  • Scope grows when Eng ships a "small" payment feature without security review

First 30 days — starter checklist

  • Get the requesting party's email/PDF: exact deliverable + deadline
  • Draw current card data flow with Eng; mark where PAN/CHD can appear
  • List processors/gateways and retrieve their responsibility docs / AOCs you already have
  • Name owners for architecture, security, and merchant/acquirer relationship
  • Schedule a call with acquirer/processor compliance contact — ask what assessment path applies to you
  • Freeze net-new payment experiments until scope is written
  • Inventory existing scans, pen tests, and logging you can reuse as evidence later

Where continuous testing helps (lightly)

PCI conversations still live or die on scope honesty. Continuous outside-in assessment helps you see what is actually reachable on the perimeter and verify real issues — and compliance-mapped reporting can support technical evidence — but it does not replace a QSA, an SAQ you signed, or your acquirer's rules.

For that supporting technical proof, see Compliance or book a demo once your card flow and assessor path are clear.

Authoritative sources

See your cyber risk, proven.

Book a demo>> More posts