Building for FinTech: PCI DSS and SOC 2 Compliance Guide

Building for FinTech: PCI DSS and SOC 2 Compliance Guide

Building financial technology means navigating a maze of compliance requirements. Two acronyms dominate the conversation: PCI DSS (for payment card security) and SOC 2 (for overall security practices).

These frameworks feel overwhelming, but they’re not insurmountable. Understanding what’s actually required helps you build compliant systems without drowning in paperwork or blowing your budget.

---

Quick Answer: What You Actually Need

PCI DSS applies if you handle, process, or transmit credit card data. Even if you use a payment processor like Stripe, some requirements still apply.

SOC 2 is often required by enterprise customers and investors to demonstrate you have proper security controls in place.

The good news: using modern payment processors (Stripe, Braintree, Adyen) significantly reduces your PCI burden. And SOC 2 compliance is achievable with the right approach and tools.

---

PCI DSS: The Payment Card Industry Data Security Standard

What is PCI DSS?

PCI DSS is a set of security standards designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. It’s enforced by the major card brands (Visa, Mastercard, Amex, Discover).

Who needs to comply? Anyone who handles payment card data, even indirectly.

The 4 Merchant Levels

Level	Criteria	Validation Requirements
Level 1	6M+ transactions/year	Annual on-site audit, quarterly network scan
Level 2	1M-6M transactions/year	Annual self-assessment, quarterly network scan
Level 3	20K-1M e-commerce transactions/year	Annual self-assessment, quarterly network scan
Level 4	<20K e-commerce transactions/year	Annual self-assessment, recommended quarterly scan

Most startups begin at Level 4 and move up as they scale.

The 12 PCI Requirements (Simplified)

PCI DSS has 12 detailed requirements, but they cluster into 6 logical groups:

Requirement Group	What It Means
Secure Network	Firewalls, secure network configurations
Data Protection	Encryption of cardholder data (at rest and in transit)
Vulnerability Management	Regular security updates, malware protection
Access Control	Unique IDs, need-to-know access, physical access controls
Monitoring & Testing	Logging, monitoring, vulnerability scanning
Information Security	Policy, training, incident response

The Critical Decision: Touch Card Data or Not?

Your PCI compliance burden depends entirely on whether your systems touch cardholder data.

Option A: Never Touch Card Data (Recommended)

Use a hosted payment page where the user enters card details directly on the processor’s servers.

Provider	PCI Burden	Your Responsibility
Stripe Checkout	Lowest	Minimal compliance (SAQ A)
Stripe Elements	Low-Moderate	SAQ A-VP
Braintree Hosted Fields	Low-Moderate	SAQ A-VP
Custom implementation	High	Full PCI audit (SAQ D)

Option B: Touch Card Data (Not Recommended for MVPs)

Your servers see raw card data. This requires significantly more compliance work and higher security standards.

Recommendation: Start with hosted payment pages. Only consider touching card data if you have a compelling business reason and the resources for full compliance.

---

PCI SAQs: Which One Applies?

The Self-Assessment Questionnaire (SAQ) you complete depends on how you handle payments.

SAQ Type	When It Applies	Complexity
SAQ A	Cardholder data never touches your systems (e.g., PayPal)	Lowest
SAQ A-EP	E-commerce, outsourced payment page but some control	Low
SAQ B	Face-to-face terminals only	Low
SAQ B-IP	Face-to-face terminals with internet connectivity	Low-Medium
SAQ C-VT	Telephone or e-commerce channels with manual processes	Medium
SAQ C	E-commerce with payment application	Medium-High
SAQ D	All other merchants, including those who touch card data	Highest

For most SaaS companies: You’ll likely use SAQ A or SAQ A-EP if you use Stripe or Braintree properly.

---

SOC 2: Service Organization Control 2

What is SOC 2?

SOC 2 is an auditing framework that demonstrates your service organization has appropriate controls in place to secure customer data. Unlike PCI DSS, SOC 2 isn’t legally required. It’s often demanded by enterprise customers and investors.

The five SOC 2 Trust Services Criteria:

Criterion	What It Covers
Security	Protection against unauthorized access
Availability	System uptime and performance
Processing Integrity	Complete, accurate, and timely processing
Confidentiality	Protection of confidential information
Privacy	Collection, use, and disclosure of personal information

Type 1 vs. Type 2:

Report Type	What It Covers	Audit Period
Type 1	Controls designed and in place at a point in time	Single date
Type 2	Controls operating effectively over time	3-12 months

Type 2 is the gold standard and what most enterprises require.

When Do You Need SOC 2?

Trigger	SOC 2 Required?
Selling to enterprise B2B customers	Usually yes
Handling sensitive customer data	Usually yes
Series A+ fundraising	Commonly requested
Early-stage B2B SaaS	Sometimes
B2C products	Rarely

Timeline: SOC 2 Type 2 typically takes 6-12 months from start to report.

---

Building Compliant FinTech: Architecture Patterns

Payment Architecture (PCI DSS)

Recommended: Tokenization

Customer → Your Frontend → Stripe/Braintree (Card Data)
                ↓
            Token/Reference ID
                ↓
            Your Backend → Stripe/Braintree API → Charge

Key principles:

1. Never store card data: use tokens from your payment processor
2. Your servers only ever see tokens: never raw card numbers
3. Use 3D Secure for fraud prevention on high-value transactions
4. Implement webhook verification: confirm payment processor webhooks are legitimate

Example: Stripe Integration Pattern

import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// Client-side: Stripe Elements creates a payment method
// and sends it to your backend

async function createPaymentIntent(amount: number, currency: string) {
  // Your server NEVER sees card data
  // Only receives paymentMethodId from client

  const paymentIntent = await stripe.paymentIntents.create({
    amount,
    currency,
    automatic_payment_methods: {
      enabled: true,
    },
  });

  return paymentIntent.client_secret;
}

// Webhook handler: verify signature
async function handleWebhook(signature: string, payload: Buffer) {
  const event = stripe.webhooks.constructEvent(
    payload,
    signature,
    process.env.STRIPE_WEBHOOK_SECRET
  );

  // Handle the event
  switch (event.type) {
    case 'payment_intent.succeeded':
      // Update your database, fulfill order, etc.
      break;
  }
}

Security Architecture (SOC 2)

Core security controls:

Control	Implementation
Access Control	SSO (SAML/OIDC), RBAC, just-in-time access
Encryption	TLS 1.3, AES-256 encryption at rest
Logging	Centralized logging (Datadog, CloudWatch) with tamper-evident storage
Monitoring	Uptime monitoring, alerting, anomaly detection
Backup	Encrypted backups, tested restoration
Change Management	Code review, CI/CD, staged deployments
Incident Response	Documented procedures, escalation paths

---

Compliance-Friendly Technology Choices

Payment Processors with PCI Benefits

Processor	PCI Advantage	Best For
Stripe	Excellent documentation, SAQ A eligible, SOC 2 certified	Most SaaS, marketplaces
Braintree	SAQ A-VP eligible, PayPal ecosystem	E-commerce, PayPal-heavy users
Adyen	Global coverage, enterprise features	International expansion
Paddle	Merchant of Record (they handle PCI)	B2B SaaS (simplifies compliance)

Note: “Merchant of Record” models like Paddle or Lemon Squeezy can dramatically simplify compliance because they become the seller, not you.

Security & Compliance Tools

Tool Category	Options	Purpose
SSO/Identity	Auth0, Okta, WorkOS	Centralized access control
Logging	Datadog, CloudWatch, New Relic	Audit trail requirements
Security Scanning	Snyk, Dependabot	Vulnerability management
Compliance Platforms	Vanta, Drata, Secureframe	Automate SOC 2 preparation
Secrets Management	1Password, HashiCorp Vault	Secure credential storage

---

Common FinTech Compliance Mistakes

Mistake	Why It Happens	How to Avoid
Storing card data	Teams want to “save cards for future use”	Use processor tokenization, never store PANs
Assuming Stripe makes you PCI compliant	Misunderstanding of shared responsibility	You still have PCI requirements even with Stripe
Logging sensitive data	Debug logging captures request bodies	Sanitize logs, never log card data or tokens
No incident response plan	Teams focus on building, not operations	Document response procedures before you need them
Ignoring change management	Deploying directly to production	Implement code review, staged environments
Weak access controls	Shared credentials, no MFA	Use SSO, individual accounts, MFA everywhere
No background checks	Hiring without verification	Screen employees with system access
Missing SOC 2 documentation	Doing the right thing, not documenting it	Start documentation early, use compliance platforms

---

Minimum Viable Compliance Roadmap

Phase 1: Foundation (Months 1-3)

PCI DSS:

• Choose hosted payment flow (Stripe Checkout or Elements)
• Complete SAQ A or SAQ A-VP
• Implement TLS encryption
• Enable logging for payment flows
• Review quarterly scan requirements

SOC 2 Preparation:

• Document security policies (even simple one-pagers)
• Implement access controls (SSO, MFA)
• Enable centralized logging
• Set up background check process for new hires

Phase 2: Formalize (Months 4-6)

PCI DSS:

• Annual SAQ completion
• Quarterly vulnerability scans
• Review and update policies

SOC 2 (if pursuing):

• Select SOC 2 auditor
• Gap analysis against SOC 2 criteria
• Remediate identified gaps
• Begin Type 2 monitoring period

Phase 3: Certification (Months 6-12+)

SOC 2 Type 2:

• Complete monitoring period (typically 6-12 months)
• Final audit
• Issue SOC 2 Type 2 report

---

Compliance Cost Estimates

Initiative	One-Time Cost	Ongoing Annual Cost
PCI DSS (Level 4, SAQ A)	$0 - $500	$200 - $1,000 (scans, SAQ)
PCI DSS (Level 2-3, SAQ A-VP/C)	$5,000 - $15,000	$2,000 - $5,000
PCI DSS (Level 1, full audit)	$50,000 - $100,000	$10,000 - $30,000
SOC 2 Type 2	$20,000 - $50,000	$15,000 - $30,000
Compliance platform (Vanta, etc.)	Setup: $5,000	$10,000 - $20,000

Note: These are rough estimates. Actual costs vary significantly by company size, complexity, and auditor choice.

---

Real-World Examples

Example 1: B2B SaaS Marketplace

Used Stripe Connect for payments, implemented SOC 2 controls while building.

• PCI: SAQ A-VP (Stripe Elements, tokenized payments)
• SOC 2: Used Vanta for automation, completed Type 2 in 9 months
• Cost: ~$35K total for SOC 2, minimal PCI burden
• Timeline: Started SOC 2 prep after Series A, certified before enterprise sales

Example 2: E-commerce Platform

Handled thousands of transactions monthly.

• PCI: SAQ A (hosted checkout via Stripe)
• SOC 2: Not initially pursued, added later for enterprise customers
• Cost: ~$500/year for PCI compliance
• Timeline: PCI compliant from launch, SOC 2 added in Year 2

---

The Compliance Framework Decision Tree

Start here:

1. Do you handle credit card data?

   • No → PCI DSS doesn’t apply
   • Yes → Continue

2. Do you use a hosted payment page?

   • Yes → SAQ A or A-VP (simplified)
   • No → Full PCI audit likely required (expensive)

3. Are you selling to enterprise customers?

   • Yes → Plan for SOC 2 Type 2
   • No → May not need SOC 2 initially

4. Have you raised Series A+?

   • Yes → SOC 2 commonly requested
   • No → Can likely defer SOC 2

---

How We Can Help

Building compliant FinTech requires both technical expertise and regulatory knowledge. We’ve helped financial technology companies navigate PCI DSS and SOC 2 while shipping secure products.

Our Web Application Development and AI Features & Automation services include security-first architecture, compliance-friendly patterns, and integration with payment processors.

Book a free consultation to discuss your FinTech project.

---

Unsure which compliance frameworks apply to your situation? Let’s talk through your specific requirements and timeline.