PCI-DSS for SaaS: what we learned

PCI-DSS (Payment Card Industry Data Security Standard) is one of those compliance frameworks that looks straightforward on paper and turns out to be deeply architectural in practice. When we started our Level 1 assessment, required because we process over 6 million card transactions per year, we expected a documentation exercise. We got a 14-month infrastructure transformation.

Scoping is everything

The most important thing you can do before any PCI work is minimize your scope. Every system that 'stores, processes, or transmits cardholder data' is in scope, and so is every system that can reach those systems. In our initial architecture, that was approximately 60% of our infrastructure because our internal network was largely flat.

We spent the first four months on network segmentation alone: VLAN isolation, micro-segmentation with next-gen firewall rules, and removing direct connections between the cardholder data environment (CDE) and our general business systems. By the time we were done, the CDE comprised 12% of our total infrastructure, a far more manageable scope.

Requirement 6: Secure software development

Requirement 6 of PCI-DSS 4.0 is where most SaaS companies discover gaps. It mandates secure coding practices, code review for security, and protection against common web vulnerabilities (OWASP Top 10). Our engineering team was already doing code review, but 'code review' and 'security-focused code review' are different disciplines.

• · Trained all engineers on OWASP Top 10 with hands-on exercises
• · Added SAST (Semgrep + CodeQL) to every PR pipeline
• · Added DAST scanning to staging environments weekly
• · Formalized threat modeling for any feature touching payment flows
• · Required two-person review for all changes to CDE-touching code

Requirement 8: Identity and access management

MFA everywhere sounds obvious. It's harder than it sounds when you have 200 engineers, 40 contractors, dozens of service accounts, and a mix of legacy systems that don't support modern MFA methods. We deployed a hardware security key mandate (FIDO2/WebAuthn) for all human access to CDE systems, no TOTP, no SMS. For service accounts we moved to short-lived certificates issued by an internal CA rather than long-lived API keys.

# Audit all IAM users with console access but no MFA
aws iam get-credential-report --query 'Content' --output text \
  | base64 -d \
  | awk -F, '$4 == "true" && $8 == "false" {print $1, "- no MFA"}'

Logging: you need more than you think

PCI-DSS requires comprehensive audit logging and, critically, the ability to detect and respond to anomalies within 24 hours. Our existing logging was adequate for debugging but not for compliance: logs were retained for 30 days, not the required 12 months; log integrity wasn't guaranteed; and we had no alerting on suspicious patterns like off-hours CDE access or bulk data queries.

We rebuilt our logging pipeline: centralized log aggregation into immutable S3 storage with object-lock enabled (WORM compliance), 13-month retention, and a SIEM deployment with rules covering every PCI-required event type. The SIEM alone took three months to tune; the initial false-positive rate made it unusable.

The QSA relationship

Your Qualified Security Assessor isn't an adversary. Treat them as a consultant who happens to also write your assessment report. We had three substantive conversations with our QSA before starting formal assessment work, which let us identify scope and control gaps early rather than during the on-site assessment.

PCI compliance is not a destination. It's an operating model. The organizations that struggle most are those that treat it as a one-time project.

What we'd do differently

• · Start network segmentation on day one, before any other work
• · Hire a dedicated compliance engineer: part-time QSA time is not a substitute
• · Automate evidence collection from day one (manual evidence gathering for 300+ controls is brutal)
• · Use tokenization for any payment data that doesn't need to be raw: dramatically reduces scope
• · Plan for the assessment to take twice as long as you expect