Compliance · May 5, 2026 · ~12 min read

PCI Level 1 audit prep for SaaS startups: what actually moves the needle

A QSA walks in and asks for 300 artifacts. Most of them you don't have. Here's the playbook I've used twice — once at a fintech, once at a healthtech-meets-payments hybrid — to go from "we touch card data" to a clean Report on Compliance without burning the engineering team to the ground.

I've been on the engineering side of two PCI Level 1 audits. The first one was a 14-month death march. The second one took six months and the QSA wrote us a thank-you note. The difference wasn't more headcount or a bigger budget — it was a small set of decisions made early that compressed the work by an order of magnitude. This post is the playbook.

Audience: you're a senior engineer or eng lead at a SaaS startup. You process more than 6 million card transactions a year (that's the threshold for Level 1), or your acquirer just told you that you need to be Level 1 because your customers are demanding it. You've never been through one. The compliance vendor you hired is helpful but vague. You're staring at a 300-row evidence spreadsheet and wondering where to start.

1. Scope reduction is the only thing that matters

PCI DSS applies to your cardholder data environment — the CDE. The single highest-leverage activity in audit prep is shrinking the CDE to the smallest possible blast radius. Every system in the CDE has to satisfy 250+ controls. Every system connected to the CDE has to satisfy a meaningful subset. Every system not connected to the CDE is out of scope and the QSA will not look at it.

The math is brutal: if your CDE includes your monolith, your background workers, your data warehouse, and your customer support tooling, you have just signed up to harden, document, and produce evidence for hundreds of services. If your CDE is a single tokenization microservice plus its database, you have signed up for a much smaller list.

Tactics that actually reduce scope:

• Tokenize at the edge. Use a hosted iframe (Stripe Elements, Braintree Hosted Fields, Spreedly) so the PAN never enters your DOM. The browser submits directly to the processor; you receive a token. Your application servers never see card data, which means they're not in scope.
• If you must touch the PAN, isolate it in a single service. One small Go or Node service whose only job is to receive the PAN, hand it to the processor, store the token, and emit an event. Put it in its own VPC subnet. Nothing else lives there.
• Network segmentation is a control, not a diagram. Your QSA will run nmap from a non-CDE host to a CDE host. If anything answers, those two segments are now both in scope. Default-deny security groups, no shared subnets, no chatty service mesh sidecars bridging the boundary.
• Logs and backups carry scope. If your CDE service ships logs to your central Loki/Datadog cluster, that cluster is now in scope. Either route CDE logs to a CDE-internal sink, or scrub PAN at the source. Same for database backups, snapshots, and replicas.

Spend two weeks on this before you do anything else. Draw the boundary on a whiteboard. Walk it with your QSA. Get them to nod. Every "yes that's out of scope" you secure here is worth a hundred policy documents later.

2. The QSA is your collaborator, not your judge

This is the single biggest mindset shift for engineering teams. A QSA's job is not to fail you — it's to produce a Report on Compliance that will hold up if your acquirer's bank gets audited and points at it. They want you to pass. They will tell you exactly what evidence will satisfy each control if you ask.

Get them on a recurring 30-minute call. Bring questions. "For requirement 10.2.1, will a CloudTrail export filtered to CDE accounts satisfy this, or do you need application-level audit logs?" That single question, answered early, can save you a month of building the wrong thing.

Pick a QSA who has audited SaaS companies, not retailers. The control language was written for a Best Buy with point-of-sale terminals. A QSA who only audits brick-and-mortar will read 1.2.3 ("install personal firewall software on any portable computing devices") and demand you install host-based firewalls on your bastion EC2 instances. A SaaS-fluent QSA will accept "we don't have employee laptops in the CDE; access is via session-recorded SSM."

3. The 12 requirements, ranked by how much they will hurt you

PCI DSS has 12 top-level requirements. They are not equal. Here's how I'd rank them by engineering effort if you're starting from a typical SaaS baseline (you have AWS, you have CI/CD, you have logging, you do not have formal change management):

1. Req 10 — Logging and monitoring. Audit logs for every CDE access, retained 1 year, with 3 months "immediately available." File integrity monitoring on critical files. Daily log review (yes, daily, with evidence). This is the single largest engineering lift if you don't already have it.
2. Req 6 — Secure development. SAST, secret scanning, dependency scanning, threat modeling for major changes, separation of dev/test/prod, no production data in lower environments. Most SaaS shops have pieces of this; gluing it into a documented SDLC is the work.
3. Req 11 — Vulnerability management. Quarterly external ASV scans (use an approved vendor — Qualys, Tenable, etc.), internal scans, annual pen test, segmentation pen test if you're claiming segmentation (and you are). Budget the pen test 4 months out; good firms book up.
4. Req 8 — Identity and access. Unique IDs, MFA on all CDE access including engineers, password policy (or, better, FIDO2 + SSO + JIT access). If you can wire CDE access through your IdP with short-lived credentials, you eliminate half the controls in this section.
5. Req 1 — Network security. The diagrams. Oh, the diagrams. You need a CDE network diagram, a data flow diagram, and they need to match reality and each other. Maintain them in code (drawio in git, or a Terraform → diagram pipeline). Stale diagrams kill audits.
6. Req 12 — Policy. Information security policy, incident response plan, risk assessment, vendor management, security awareness training. This is mostly writing. It is boring but unskippable. Steal a template from your QSA.
7. Reqs 2, 3, 4, 5, 7, 9 — the smaller ones. Configuration standards, encryption at rest, encryption in transit, anti-malware, role-based access, physical security. Each is a discrete checklist; none should consume more than a week if your scope is tight.

4. Evidence is a product. Build it like one.

The single biggest waste of engineering time in audit prep is producing evidence by hand the first time, then producing it again three months later when the QSA asks for the updated version. Build evidence as a continuous output of your systems, not as a one-time export.

Concrete examples that paid for themselves on both audits:

• A nightly cron that exports access reviews. "Here are the 14 humans with CDE access, what role each has, and when each was last reviewed." Drops a CSV into an S3 bucket the QSA can read. Requirement 7 evidence, generated on autopilot.
• A CI gate that fails the build if a CDE service's Dockerfile changes without a security review label. Requirement 6 evidence: every change to in-scope code went through review, here's the GitHub API export.
• Terraform plans archived to S3 for every prod apply. Requirement 1.1.1 wants documented network configuration changes. The plan diff is the documentation.
• A `compliance/` directory in git with a markdown file per control, each one linking to the evidence: log queries, dashboards, runbooks, screenshots. The QSA gets a read-only invite to the repo. Their evidence collection becomes self-serve.

Treat the evidence pipeline as a product owned by one engineer for the duration of the audit. The compounding effect is enormous: by week 12 you should be able to satisfy a new evidence request in minutes, not days.

5. The change management trap

Requirement 6.4 wants documented change management with separation of duties. Most engineering teams hear "documented change management" and panic-install a Jira workflow with five approval steps, killing deployment velocity for a year.

You don't need a Jira workflow. You need evidence that changes to the CDE go through a defined process with appropriate review. A pull request with a CODEOWNERS-enforced review from a non-author, merged via a CI pipeline that runs tests and security scans, deployed via a documented promotion process — that is change management. Write it up as a one-page policy. Show the QSA your branch protection rules and a sample of merged PRs. Done.

The trap: if you don't write up what you already do, the QSA will assume you do nothing, and you'll end up implementing the Jira workflow anyway. The work isn't building a process; the work is documenting the process you have.

6. The 90-day timeline

If you're starting from scratch with a tight scope, here's the realistic timeline:

• Weeks 1–2: Pick your QSA. Lock the scope. Draw the CDE boundary. Get QSA sign-off on the boundary. Tokenize at the edge if you haven't.
• Weeks 3–6: Logging, monitoring, FIM, segmentation. The hardest engineering work, front-loaded so it has time to soak. Schedule the ASV scan for week 8 and the pen test for week 10.
• Weeks 7–10: Identity hardening, secret scanning in CI, dependency scanning, evidence pipeline. Knock out the policy documents in parallel — assign them to whoever has the spare cycles.
• Weeks 11–14: Pen test happens, findings come back, you fix the criticals, retest. ASV scan clean. QSA fieldwork begins.
• Weeks 15–18: QSA produces the ROC. You answer follow-up questions. Sign the AOC.

Six months from "we need to do this" to a signed AOC is achievable for a focused team. Twelve months is normal. Eighteen months means somebody let scope creep early and never recovered.

7. What I wish someone had told me

Three things, in order of how much they would have saved me:

1. The QSA's time is the bottleneck, not yours. If they have a 3-week response window on your evidence submissions, that compounds across 100+ controls. Find a QSA firm with a small, dedicated engagement team and confirm their cadence in the SOW.
2. Compliance debt is real and it accrues interest. Every shortcut you take in the first audit is something you'll pay for in the next one. Build the evidence pipeline to last. Write the policies in a way you'll actually maintain. The second audit can be 2x easier than the first if you set yourself up.
3. It will not kill your velocity if you do it right. The teams that get destroyed by PCI are the ones that bolt compliance theater onto their existing process. The teams that succeed integrate the controls into how they already work — branch protection, IaC, automated testing, audit logging — and treat the compliance documentation as a description of reality rather than a separate set of hoops.

If you're staring down your first PCI Level 1 and want a second pair of eyes on your scope diagram, your QSA selection, or your evidence pipeline design, that's literally what I do. Book a call and we'll go through it.