Maria Fontán had read the email three times before she called an emergency stand-up. Maria was VP of Engineering at ClearLane Payments, a nine-year-old payment processor that routed roughly $2.3 billion a year in card-not-present transactions for mid-market e-commerce merchants. ClearLane had carried a clean PCI DSS Level 1 Report on Compliance for six straight years — no findings, no compensating controls, no drama. So when Meridian Retail Group's procurement team sent a one-line message pausing a $40-million-a-year platform integration "pending completion of a SOC 2 Type II examination," Maria's first reaction was irritation. We already prove we protect cardholder data. What more do they want?
What Meridian's risk team wanted, it turned out, was something PCI DSS was never built to answer: could ClearLane demonstrate — with independent, tested evidence — that its systems stayed available during peak retail periods, that every transaction it processed was complete, accurate, and authorized, and that the surrounding security program covered far more than the sixteen-digit card number sitting in the payload? PCI DSS told Meridian that cardholder data was protected. It said almost nothing about uptime commitments, change management discipline, or whether a duplicated transaction would be caught before it hit a merchant's settlement file. That gap is exactly where SOC 2 lives, and it is why an increasing number of banks, ISVs, and enterprise merchants now ask processors for both reports before they'll sign.
Who This Is for and What You'll Walk Away With
This article is for engineering leaders, compliance managers, and founders at payment processors, payment facilitators (PayFacs), gateways, and payment-adjacent platforms who already carry — or are working toward — PCI DSS compliance and are now facing a SOC 2 request from a bank, an enterprise merchant, or a card network partner. You'll walk away understanding exactly how SOC 2's Trust Services Criteria map onto (and extend beyond) PCI DSS's twelve requirements, which criteria matter most for transaction-processing workloads, how to scope a SOC 2 examination around the same system boundary you already defined for PCI, and where SOC 1 enters the picture if your processing touches a customer's financial statements. We'll also walk through tokenization, encryption, reconciliation, and fraud-control design patterns that hold up under both a Qualified Security Assessor's PCI review and a CPA firm's SOC 2 testing.
Why Buyers Ask for Both PCI DSS and SOC 2
Every processor eventually hears a version of Maria's question: "We're already PCI compliant — why do you also want SOC 2?" The honest answer is that PCI DSS and SOC 2 answer different questions for different audiences, and a sophisticated buyer wants both answered.
PCI DSS is a card-brand mandate — administered by the PCI Security Standards Council on behalf of Visa, Mastercard, American Express, Discover, and JCB — that applies to any entity that stores, processes, or transmits cardholder data. It is contractual, not statutory: no government wrote it into law, but every card network's operating rules require compliance as a condition of card acceptance, and non-compliance carries real consequences — fines, increased interchange costs, and in serious cases, loss of the ability to process cards at all. PCI DSS is narrow and deep: it exists to protect one specific asset class (cardholder data and sensitive authentication data) against one specific outcome (a breach that exposes card numbers).
SOC 2 is an attestation — an examination performed by a licensed CPA firm under SSAE 18, governed by the American Institute of Certified Public Accountants (AICPA) — that evaluates a service organization's controls against the Trust Services Criteria: Security, and optionally Availability, Processing Integrity, Confidentiality, and Privacy. It is broader and shallower than PCI DSS in scope — it doesn't dictate a fixed list of technical requirements the way PCI does — but it covers the entire operating environment, not just cardholder data: incident response, change management, vendor oversight, availability commitments, and whether the transactions you process are complete, accurate, timely, and authorized. Critically, SOC 2 is not a certification and does not replace PCI DSS. A payment processor that handles card data must still maintain PCI DSS compliance regardless of how many SOC 2 reports it holds.
"PCI tells my bank that you've locked the vault. SOC 2 tells my bank that the whole building has a functioning alarm system, a documented evacuation plan, and a night shift that shows up on time — every night, for the whole year we're reviewing." — Devon Achebe, Head of Payments Risk, Northfield Bank
Buyers layer the two because they're managing different exposures. A bank sponsoring a processor cares about safety and soundness broadly — outages, fraud losses, and reporting accuracy, not just card-data theft. An enterprise merchant integrating a payment API cares whether the processor's platform will be up during a Black Friday spike and whether a duplicated API call will double-charge a customer. Neither of those questions falls inside PCI DSS's scope, and both fall squarely inside SOC 2's.
Two Different Assurance Mechanisms, Side by Side
The confusion Maria hit is common enough that it's worth laying the two frameworks out directly, requirement type by requirement type, before going further.
Table 1: PCI DSS vs SOC 2 at a Glance
Dimension | PCI DSS | SOC 2 |
|---|---|---|
Governing body | PCI Security Standards Council (card networks) | AICPA |
Nature | Card-brand mandate (contractual requirement), not law | Voluntary attestation, market-driven |
Output | Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) + Attestation of Compliance | Examination report with auditor's opinion |
Assessor | Qualified Security Assessor (QSA) or internal Self-Assessment | Licensed CPA firm |
Scope | Cardholder data environment (CDE) — systems that store, process, or transmit card data | Entire in-scope system relevant to selected Trust Services Criteria |
Structure | 12 fixed, prescriptive requirements with sub-requirements | 5 flexible criteria categories (Security required, others optional) |
Frequency | Annual assessment, quarterly scans | Annual (typically), covering a defined observation period |
Primary question answered | Is cardholder data protected against theft and misuse? | Are the service organization's controls suitably designed and operating effectively across security, availability, integrity, confidentiality, and/or privacy? |
Replaces the other? | No | No — complements PCI DSS, does not substitute for it |
Neither framework is "better." A processor that treats SOC 2 as a superset that makes PCI DSS optional will fail its next card-brand compliance validation. A processor that treats PCI DSS as sufficient for enterprise sales will keep losing deals to competitors who also carry a Type II report. The two live together, and the smart operational move — which we'll return to later — is building one control environment and one evidence pipeline that services both.
What "Payment Processor" Means for Scoping Purposes
Before mapping controls, it's worth being precise about what kind of payment processor you are, because it changes which parts of SOC 2 and PCI DSS actually apply. "Payment processor" gets used loosely to describe several distinct roles in the transaction chain.
Table 2: Payment Processor Roles and Typical Scope Drivers
Role | What It Does | PCI DSS Exposure | Typical SOC 2 Criteria in Scope |
|---|---|---|---|
Acquirer / merchant acquirer | Contracts directly with merchants, settles funds via card networks | Full CDE — stores/processes/transmits card data | Security, Availability, Processing Integrity |
Payment gateway | Routes authorization requests between merchant and acquirer/processor | Transmits card data (often tokenized after first hop) | Security, Availability, Processing Integrity |
Payment facilitator (PayFac) | Sub-merchants onboard under the PayFac's master merchant account | Full CDE, often Level 1 due to volume | Security, Availability, Processing Integrity, sometimes Confidentiality |
Payment orchestration platform | Routes transactions across multiple acquirers/processors | Varies — often tokenized pass-through | Security, Availability, Processing Integrity |
Card issuer processor | Processes transactions on behalf of a card-issuing bank | Full CDE plus issuer-specific data | Security, Availability, Processing Integrity, Confidentiality |
ACH / bank-transfer processor | Moves funds via ACH/RTP rails, not card rails | PCI DSS may not apply; other frameworks (Nacha rules) do | Security, Availability, Processing Integrity |
The common thread across every row that touches card rails: PCI DSS applies, and it applies in full regardless of how small the entity is or how much of the flow is outsourced. The common thread across every row for SOC 2: Processing Integrity and Availability show up far more consistently for payment processors than for a typical SaaS company, because the core product — moving money correctly and on time — is precisely what those two criteria test.
The Trust Services Criteria That Matter Most for Payments
SOC 2 lets a service organization select which criteria to include beyond the mandatory Security (Common Criteria) baseline. For most SaaS companies, Security plus Availability is the default pairing. For payment processors, the calculus is different.
Table 3: Trust Services Criteria Applicability for Payment Processors
Criterion | Mandatory? | Why It Matters for a Payment Processor | Typical Inclusion Rate Among Processors |
|---|---|---|---|
Security (Common Criteria) | Yes, always | Baseline for every SOC 2; protects the CDE, corporate network, and application layer | 100% |
Optional | Merchants and banks need uptime guarantees; payment rails are latency- and uptime-sensitive | ~90% | |
Processing Integrity | Optional | Directly tests whether transactions are complete, valid, accurate, timely, and authorized — the core service promise | ~85% |
Confidentiality | Optional | Relevant where non-card sensitive data (bank account numbers, SSNs for KYC) is handled | ~55% |
Privacy (TSC) | Optional | Relevant when personal information beyond payment credentials is collected directly from consumers | ~25% |
Most processors we've worked with land on Security + Availability + Processing Integrity as their three-criteria SOC 2 scope, with Confidentiality added if the platform also handles bank account numbers or Know Your Customer (KYC) documentation outside the card-data flow. That combination directly answers the questions a bank or enterprise merchant is actually asking: will it be up, will it process correctly, and is the environment secure.
Processing Integrity: The Criterion That Does the Heaviest Lifting
If there's one Trust Services Criterion that separates a generic SOC 2 report from one that actually reassures a payment partner, it's Processing Integrity. This criterion tests whether system processing is complete, valid, accurate, timely, and authorized — five words that map almost perfectly onto what a bank or merchant needs to know about a payment processor's core function.
Processing Integrity is not primarily a security criterion; it's an operations-integrity criterion. Auditors testing it look for evidence that: inputs are validated before processing (a malformed transaction record doesn't silently corrupt a batch); processing logic produces correct outputs (an amount of $104.50 is settled as $104.50, not $1045.00 due to a decimal error); duplicate transactions are detected and prevented (idempotency controls on retried API calls); transactions complete within committed timeframes (authorization responses within an SLA window, settlement files delivered on the agreed batch schedule); and only authorized transactions are processed (fraud screening, velocity checks, and merchant-level authorization rules are enforced before funds move).
We cover Processing Integrity control design in far more depth in our companion piece, SOC 2 Processing Integrity: Data Accuracy and Completeness Controls — but the short version for payment processors is that Processing Integrity evidence overlaps heavily with what your reconciliation, settlement, and fraud teams already produce daily. The gap is rarely that the controls don't exist; it's that nobody has mapped them to a criterion and preserved the evidence in a form an auditor can sample against.
"Every processor I audit already reconciles nightly. Almost none of them can hand me twelve months of reconciliation exception logs with timestamps, owners, and resolution notes on day one. That gap — not missing controls — is what stretches a Processing Integrity examination from four weeks to four months." — James Okafor, Director of Audit, Meridian CPA Group
Availability: Uptime Commitments and Payment Rails
Payment processing is latency-sensitive in a way most software isn't. A checkout page that hangs for eight seconds during authorization doesn't just annoy a user — it produces an abandoned cart, a support ticket, and, at volume, a measurable revenue hit for the merchant. That's why Availability is included in roughly nine out of ten payment-processor SOC 2 scopes.
Availability testing looks at capacity planning, environmental protections for data centers, backup and recovery procedures, incident detection for outages, and — critically for payments — failover design. Auditors want evidence of defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets, tested disaster recovery plans, and monitoring that would catch a degraded authorization success rate before it became a full outage.
For payment processors specifically, Availability testing often extends past your own infrastructure into your dependency chain: card network connectivity, banking-partner API availability, and third-party fraud-scoring services. A processor's uptime is only as good as its weakest upstream dependency, and a mature Availability control set documents redundant connections to acquiring banks, multiple network paths to card networks, and a tested plan for degrading gracefully (e.g., falling back to a secondary processor route) rather than failing outright. We go deeper on the broader SaaS Availability control set in SOC 2 Availability Criteria: System Uptime and Performance Management, which is a useful baseline before layering payment-specific failover requirements on top.
Security: The Common Criteria Baseline Under a Payments Lens
Security — the Common Criteria — is mandatory in every SOC 2 and maps to the nine COSO-aligned control categories (CC1 through CC9): control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. None of that changes for a payment processor. What changes is emphasis and depth.
Table 4: Common Criteria Focus Areas for Payment Processors
CC Category | General SaaS Emphasis | Payment Processor Emphasis |
|---|---|---|
CC1 – Control Environment | Board oversight, ethics policy | Fraud-risk governance, PCI-SOC 2 dual-compliance ownership |
CC3 – Risk Assessment | General cyber risk | Transaction-fraud risk, settlement-failure risk, chargeback-fraud risk |
CC6 – Logical/Physical Access | Standard access control | Strict segregation of duties between transaction initiation, approval, and settlement |
CC7 – System Operations | Incident detection | Real-time transaction-anomaly monitoring, authorization-decline spike detection |
CC8 – Change Management | Standard SDLC controls | Change freezes around peak processing windows (holiday shopping, month-end settlement) |
CC9 – Risk Mitigation | Vendor risk generally | Subservice organization oversight for card networks, sponsor banks, gateways |
The underlying control objectives are identical to any SOC 2. What a QSA and a SOC 2 auditor both expect to see, differently framed, is that access to the systems that move money is tightly restricted, logged, and reviewed — and that's a natural bridge into the access-control and segregation-of-duties sections later in this piece.
Confidentiality and Privacy: When Card Data Isn't the Only Sensitive Data
Cardholder data itself — the primary account number (PAN), expiration date, and sensitive authentication data — is governed by PCI DSS, not by SOC 2's Confidentiality criterion. But payment processors routinely handle other sensitive information that PCI DSS doesn't touch: merchant bank account and routing numbers for settlement, business owner Social Security numbers collected for KYC and underwriting, and in some cases consumer PII collected during onboarding or dispute resolution.
That's the gap Confidentiality and Privacy fill. Confidentiality applies to any information designated confidential by agreement or policy — bank account details, merchant financial statements used in underwriting, proprietary risk-scoring models. Privacy applies specifically to personal information collected, used, retained, and disclosed about identified individuals, which becomes relevant for processors doing direct KYC on business owners or handling consumer disputes and refund requests that involve personal data.
Roughly half the payment processors we've assessed include Confidentiality; a much smaller share formally include Privacy, usually because their KYC and underwriting data collection is delegated to a sponsor bank or a specialized identity-verification vendor rather than performed in-house. Where you land depends on how much of that non-card sensitive data your own systems — rather than a partner's — actually touch.
Where SOC 1 Fits: ICFR and Payment Processors
A question that trips up almost every processor evaluating its assurance strategy for the first time: do we need SOC 2, SOC 1, or both? The answer depends on what your customers use your output for.
SOC 1 reports on controls relevant to a user entity's internal control over financial reporting (ICFR) — in other words, controls that matter because a customer's auditor needs assurance that numbers flowing from your system into the customer's financial statements are reliable. For a payment processor, that's directly relevant: if you're calculating settlement amounts, fees, and reserves that a merchant records as revenue and receivables on its own books, your merchant's external auditor may require a SOC 1 report covering those processing controls as part of the merchant's own financial-statement audit.
SOC 2, by contrast, addresses the broader operational trust question — security, availability, integrity, confidentiality, privacy — that isn't necessarily tied to anyone's financial statements. Many processors need both: SOC 1 for the merchants whose auditors need financial-reporting assurance over settlement calculations, and SOC 2 for the banks, ISVs, and enterprise partners who care about the wider security and operational posture.
"We used to think SOC 1 and SOC 2 were competing asks from different departments at the same client. They're not. Our merchant's controller wants the SOC 1 for her year-end audit. Our merchant's CISO wants the SOC 2 before he'll let us anywhere near his checkout page. Same relationship, two different reports, two different reasons." — Sarah Lindqvist, CISO, Anchorpoint Processing
SOC 1 vs SOC 2 vs PCI DSS: A Three-Way Comparison
Because processors routinely juggle all three, it's worth a single table that puts them side by side rather than comparing them two at a time.
Table 5: SOC 1 vs SOC 2 vs PCI DSS for Payment Processors
Attribute | SOC 1 | SOC 2 | PCI DSS |
|---|---|---|---|
Primary audience | User entities' financial statement auditors | Banks, enterprise merchants, ISV partners, risk/security teams | Card networks, acquiring banks, regulators indirectly |
What it assures | Controls relevant to ICFR (settlement, fee calculation, reserve accounting) | Security, availability, processing integrity, confidentiality, privacy of the system | Protection of cardholder data specifically |
Legal status | Not a law; AICPA attestation standard | Not a law; AICPA attestation standard | Not a law; card-brand contractual mandate |
Mandatory for card acceptance? | No | No | Yes, if handling card data |
Report type | Type I or Type II | Type I or Type II | ROC or SAQ + AOC |
Typical requester | Merchant's external auditor | Bank partner, enterprise merchant, ISV, investor diligence | Acquiring bank, card networks |
Distribution | Restricted use | Restricted use (SOC 3 available for public use) | Restricted, submitted to acquirer/card networks |
None of the three substitutes for another. A processor that only carries PCI DSS is protecting cardholder data but hasn't independently demonstrated availability, broader security governance, or processing accuracy. A processor that only carries SOC 2 has not satisfied the card networks' mandatory requirement to protect cardholder data — it will still be required to complete PCI DSS validation to keep processing cards, full stop.
Drawing the System Boundary: Scoping SOC 2 Around Payment Flows
Every SOC 2 examination starts with a system boundary — the defined edge of what's actually being examined. For a payment processor, getting this boundary right matters more than almost any other decision in the engagement, because it determines both audit cost and how convincingly the resulting report answers a bank's or merchant's question.
The instinct many processors have is to scope SOC 2 identically to their PCI DSS cardholder data environment (CDE). That's a reasonable starting point but usually wrong in the details. PCI DSS scope is drawn tightly around anything that stores, processes, or transmits card data — and nothing else. SOC 2 scope should be drawn around the system that delivers the service commitments you're making to the customer asking for the report, which typically includes components PCI DSS scoping would exclude: the merchant onboarding platform, the reporting and reconciliation dashboards merchants log into, the API gateway serving non-card metadata, and the internal risk and fraud-scoring systems, even where those systems only ever see a token rather than a live PAN.
"I've seen processors hand an auditor their PCI CDE diagram and say 'that's our SOC 2 boundary too.' It's a good first draft and a bad final answer. Your merchant dashboard has never touched a card number, but if it goes down, your merchant can't see their money — that's squarely inside Availability and Processing Integrity scope whether or not it's inside your CDE." — Priya Raman, QSA, Bastion Assurance Partners
Left unmanaged, this creates scope creep in the other direction too — pulling in systems that have nothing to do with the service commitments under review just because they share a network segment. A disciplined audit scope exercise walks through every service commitment in your customer contracts and merchant agreements (uptime SLAs, processing-time SLAs, data-handling commitments) and maps each one to the systems, people, and processes that deliver it. That mapping — not the PCI CDE diagram — is your real SOC 2 boundary.
PCI DSS Scope vs SOC 2 Scope: A Working Comparison
Table 6: How PCI DSS and SOC 2 Draw Their Boundaries Differently
Scoping Question | PCI DSS Approach | SOC 2 Approach |
|---|---|---|
What triggers inclusion? | Any system that stores, processes, or transmits cardholder/sensitive authentication data, or is connected to such a system | Any system relevant to the selected Trust Services Criteria and the service commitments made to customers |
Tokenized systems | Excluded from CDE if tokenization is properly implemented and validated | Often still in scope if they support availability or processing-integrity commitments |
Corporate IT (HR, finance) | Excluded unless connected to the CDE | Included if it affects the control environment (CC1–CC5) even without touching payment data |
Customer-facing dashboards (non-card data) | Typically out of scope | Typically in scope for Availability and Processing Integrity |
Merchant onboarding/underwriting systems | Out of scope (no card data) | In scope if onboarding accuracy affects processing integrity or Confidentiality applies to KYC data |
Subservice organizations | Assessed via their own PCI attestation (AOC) if in the transaction flow | Assessed via carve-out method or inclusive method |
Documentation output | Network diagram, data-flow diagram, CDE definition | System description covering infrastructure, software, people, procedures, and data |
Running both scoping exercises in parallel — rather than sequentially — is the single biggest efficiency gain available to a processor pursuing both frameworks. We'll return to that combined approach after covering the specific controls auditors on both sides care about most.
Tokenization: Shrinking PCI Scope While Strengthening SOC 2 Evidence
Tokenization is the highest-leverage control a payment processor can implement, because it does double duty: it's the single most effective PCI DSS scope-reduction technique available, and it directly strengthens the evidence base for SOC 2's Security and Processing Integrity criteria.
Tokenization replaces a live primary account number with a surrogate value (a token) that has no exploitable value outside the specific system that generated it. Once a PAN is tokenized at the earliest possible point in the flow — ideally at capture, before it reaches application servers — everything downstream of that point (order management, reporting, analytics, customer support tooling, fraud scoring) can operate on the token instead of the real card number. Those downstream systems drop out of PCI DSS scope entirely, because they never store, process, or transmit actual cardholder data.
For SOC 2, tokenization does something equally valuable: it shrinks the blast radius that Security controls need to defend and gives Processing Integrity testing a cleaner story. An auditor testing whether transactions are processed accurately can trace a token through the entire pipeline and confirm it consistently maps to the correct underlying transaction without ever needing to review systems that handle raw PAN data — which also means fewer systems need the highest tier of encryption, logging, and access restriction.
Table 7: Tokenization's Impact on Compliance Scope
System Component | Before Tokenization | After Tokenization |
|---|---|---|
Checkout/capture point | In PCI CDE, high-risk | In PCI CDE (unavoidable — this is where the PAN first appears) |
Order management system | In PCI CDE | Out of PCI CDE; still in SOC 2 Processing Integrity scope |
Reporting/analytics platform | In PCI CDE | Out of PCI CDE; in SOC 2 Availability/Processing Integrity scope |
Customer support tooling | In PCI CDE (agents could view PAN) | Out of PCI CDE (agents see masked token reference) |
Fraud-scoring engine | In PCI CDE | Out of PCI CDE; in SOC 2 Security scope for model integrity |
Number of systems requiring PCI-grade encryption/logging | High | Limited to tokenization vault and capture point |
A well-run tokenization program is one of the few investments that reduces PCI audit cost, reduces SOC 2 audit cost, and reduces actual breach risk simultaneously — which is why it's usually the first recommendation we make to a processor trying to bring both assessments under control.
Encryption Controls for Cardholder Data and Payment Instructions
Even with tokenization at the front door, encryption remains foundational, because the tokenization vault itself, the capture point, and any system that must temporarily handle a live PAN (for a network token request, for instance) need protection at the highest standard both frameworks expect.
Table 8: Encryption Requirements Compared — PCI DSS Expectation vs SOC 2 Evidence
Data State | PCI DSS Requirement | SOC 2 Evidence Auditors Expect |
|---|---|---|
PAN at rest | Strong cryptography (e.g., AES-256) or truncation/tokenization; render unreadable | Encryption at rest policy, key-rotation logs, access logs to encrypted stores |
PAN in transit | TLS 1.2+ over open, public networks | Encryption in transit configuration standards, certificate management records |
Settlement/ACH instructions | Not directly covered by PCI DSS | Encryption policy extended to bank-transfer instructions as part of Confidentiality/Processing Integrity |
Cryptographic keys | Documented key-management procedures, dual control, split knowledge for manual key operations | Key management policy, hardware security module (HSM) usage evidence, key-rotation schedule |
Encryption of backups | Required if backups contain cardholder data | Backup encryption policy and periodic restore-test evidence |
We treat encryption as table stakes rather than a differentiator in these assessments — every processor we've worked with has some encryption story. Where processors lose points with both a QSA and a SOC 2 auditor is key management: keys stored alongside the data they protect, no documented rotation schedule, or a single engineer holding standing access to the key-management console without a documented dual-control process. A properly configured HSM with logged, dual-authorized key ceremonies resolves most of these findings in one investment.
Reconciliation Controls: The Backbone of Processing Integrity Evidence
If Processing Integrity is the criterion that matters most for a payment processor, reconciliation is the control family that proves it. Reconciliation is the process of comparing two independent records of the same activity — a batch of authorized transactions against the settlement file sent to the acquiring bank, or the ledger balance in your internal system against the balance reported by a card network — to confirm nothing was lost, duplicated, or altered in transit.
Table 9: Core Reconciliation Control Points for a Payment Processor
Reconciliation Point | What's Compared | Frequency | Evidence an Auditor Samples |
|---|---|---|---|
Authorization-to-capture | Approved authorizations vs. captured transactions | Daily | Exception reports, aging of unmatched items |
Capture-to-settlement | Captured transactions vs. settlement file sent to acquirer | Per batch | Settlement confirmation logs, variance investigation notes |
Settlement-to-funding | Settlement file totals vs. funds actually deposited to merchant accounts | Daily | Bank statement matching records, discrepancy resolution tickets |
Network-to-internal ledger | Card network reporting vs. internal transaction ledger | Daily/weekly | Reconciliation software output, sign-off records |
Chargebacks and refunds | Dispute/refund requests vs. ledger adjustments | Daily | Chargeback tracking log, refund authorization records |
Fee and interchange calculation | Card network fee schedule vs. amounts charged to merchants | Monthly | Fee reconciliation spreadsheet/report, exception escalation log |
An audit trail that shows not just that reconciliation happened, but that exceptions were investigated, owned, and closed within a defined timeframe, is what converts a routine finance function into strong Processing Integrity evidence. Auditors will sample specific dates and ask you to produce the full chain: transaction, batch, settlement confirmation, exception log entry if applicable, and resolution note. Processors who build this evidence trail as a byproduct of daily operations — rather than reconstructing it under audit pressure — consistently see shorter fieldwork periods.
Fraud Detection and Prevention Controls
Processing Integrity's "authorized" component — one of its five sub-criteria alongside complete, valid, accurate, and timely — is where fraud controls live inside a SOC 2 examination. A transaction can be complete, accurate, and timely and still fail Processing Integrity if it was never actually authorized by the legitimate cardholder or merchant.
Table 10: Fraud Control Categories and Their Testing Evidence
Control Category | What It Does | Typical Evidence |
|---|---|---|
Velocity checks | Flags abnormal transaction frequency/value from a single card or merchant | Rule configuration records, alert logs, tuning-change history |
Address/CVV verification | Confirms cardholder-supplied data matches issuer records | AVS/CVV response logs, decline-reason reporting |
Device and behavioral fingerprinting | Detects anomalous device/session patterns | Model output logs, false-positive/negative review notes |
Merchant monitoring | Detects abnormal merchant-level activity (e.g., sudden volume spike, refund ratio) | Merchant risk-scoring reports, account-review escalation records |
Fraud risk assessment | Periodic formal review of fraud exposure and control effectiveness | Documented fraud risk assessment, management sign-off |
Case management/investigation | Tracks suspected-fraud cases to resolution | Case management system export, resolution timestamps |
Auditors testing Processing Integrity's authorization component will typically ask for a sample of declined and flagged transactions and trace the decision logic end to end — did the system apply the documented rule set, was the decision logged, and was any override properly authorized and recorded. A common gap: fraud rules get tuned informally by an analyst without a change record, which then can't be reproduced as evidence during the audit period. Treating fraud-rule changes with the same change-management discipline as code deployments closes this gap cleanly.
Change Management for Payment Processing Systems
Change management is a Common Criteria requirement (CC8) in every SOC 2, but it carries extra weight for payment processors because an uncontrolled change to authorization logic, fee calculation, or settlement batching can directly cause a Processing Integrity failure — real money processed incorrectly, not just a security exposure.
Table 11: Change Management Controls Auditors Expect for Payment Systems
Control | Purpose | Payment-Specific Nuance |
|---|---|---|
Documented change request/approval | Ensures changes are authorized before deployment | Changes to authorization, settlement, or fee logic require a second, independent approver |
Segregated environments | Prevents untested code from reaching production | Test environments use synthetic/masked card data, never live PANs |
Automated testing before deployment | Catches defects pre-release | Regression tests specifically covering transaction accuracy and idempotency |
Change freeze windows | Reduces risk during high-volume periods | Freezes around peak retail dates (holiday season, tax season for certain verticals) |
Rollback procedures | Limits blast radius of a bad deployment | Tested rollback specifically validated against in-flight transaction state |
Post-deployment monitoring | Confirms the change performed as intended | Real-time transaction-success-rate dashboards reviewed immediately post-release |
We cover the general SOC 2 change-management control set in more depth in SOC 2 Change Management: System and Application Updates; the payment-specific addition is that "tested" has to include a transaction-accuracy regression suite, not just functional and security testing, because a change that passes every security test can still silently miscalculate a fee.
Access Controls and Segregation of Duties in Money Movement
Nowhere does segregation of duties matter more than in a system that moves money. The core principle — no single person should be able to both initiate and approve a transaction, or both modify transaction records and approve the reconciliation that would catch the modification — runs through both PCI DSS's access-control requirements and SOC 2's CC6 logical-access criteria.
Table 12: Segregation of Duties Checkpoints for Payment Processors
Function | Must Be Separated From | Why |
|---|---|---|
Initiating a manual settlement/funding adjustment | Approving that adjustment | Prevents unauthorized fund movement |
Modifying merchant fee schedules | Approving fee-schedule changes | Prevents fraudulent fee manipulation |
Database-level access to production ledger | Application-level transaction processing | Limits ability to alter transaction records outside normal processing |
Reconciliation review | Transaction processing/settlement execution | Independent check catches errors or manipulation |
Fraud-rule configuration | Fraud-case investigation and disposition | Prevents an investigator from tuning rules to hide fraud |
Cryptographic key custodianship | Application/database administration | Limits blast radius of a compromised admin account |
Least privilege and multi-factor authentication for any account with standing access to production payment systems are baseline expectations from both a QSA and a SOC 2 auditor at this point — neither framework will pass an environment where privileged access to the transaction ledger isn't MFA-protected and individually attributable. We cover the broader access-control build-out in SOC 2 Access Controls: User Management and Privilege Administration.
Subservice Organizations: Card Networks, Sponsor Banks, and Gateways
Almost no payment processor operates in isolation. You depend on card networks for authorization routing, an acquiring or sponsor bank for settlement and regulatory standing, and often third-party gateways, fraud-scoring vendors, or cloud infrastructure providers. Each of these is a subservice organization for SOC 2 purposes, and each requires a scoping decision.
Table 13: Common Payment-Processor Subservice Organizations
Subservice Organization | Typical Role | Common Treatment |
|---|---|---|
Card network (Visa, Mastercard, etc.) | Routes authorization/settlement messages | Carve-out — their own security programs are independently governed |
Acquiring/sponsor bank | Settlement, regulatory sponsorship | Carve-out, supported by bank's own attestations/regulatory exams |
Cloud infrastructure provider (AWS, Azure, GCP) | Hosts application and data infrastructure | Carve-out, supported by provider's own SOC 2/SOC 3 reports |
Third-party fraud-scoring vendor | Provides risk scores used in authorization decisions | Carve-out or inclusive depending on contract/access depth |
Tokenization/vaulting provider | Manages token generation and PAN vault | Often inclusive if deeply integrated; carve-out if independently certified |
KYC/identity-verification vendor | Performs identity checks during merchant onboarding | Carve-out, supported by vendor's own compliance attestations |
Carve-Out vs Inclusive Method: Making the Call
The choice between the carve-out method and the inclusive method for each subservice organization affects both audit scope and how convincingly your report answers a bank's due-diligence questions.
Table 14: Carve-Out vs Inclusive Decision Factors
Factor | Favors Carve-Out | Favors Inclusive |
|---|---|---|
Subservice org has its own SOC 2/SOC 3 or equivalent attestation | Yes — reference it, don't re-test it | N/A |
Subservice org's controls are deeply intertwined with yours (shared systems, shared staff) | No | Yes — separating them would be artificial |
Subservice org is a card network or large regulated bank | Yes — practically impossible to include them in your audit | N/A |
Contractual/access ability to have their controls tested as part of your audit | Limited | Full access negotiated |
Client/bank wants full visibility into that vendor's control operation | Lower priority if attestation exists | Higher — inclusive gives full visibility |
Most processors use carve-out for card networks, sponsor banks, and cloud infrastructure providers (all of which publish their own attestations), and reserve inclusive treatment for smaller, more tightly integrated vendors — like a tokenization or fraud-scoring provider — where the client relationship depends on seeing exactly how that vendor's controls operate. Whichever method you choose, complementary user entity controls (CUECs) and complementary subservice organization controls need to be clearly documented in the system description so a reader understands exactly which controls you're representing as yours versus relying on a partner to operate.
Mapping PCI DSS Requirements to SOC 2 Criteria
The fastest way to see where evidence can be reused across both examinations is a direct requirement-to-criteria mapping. This is illustrative — every environment differs — but it reflects the overlap we consistently see in practice.
Table 15: PCI DSS 12 Requirements Mapped to SOC 2 Trust Services Criteria
PCI DSS Requirement (v4.0 structure) | Primary SOC 2 Criteria Overlap |
|---|---|
1. Install and maintain network security controls | Security (CC6, CC7) |
2. Apply secure configurations | Security (CC6, CC8) |
3. Protect stored account data | Security, Confidentiality |
4. Protect cardholder data with strong cryptography in transit | Security, Confidentiality |
5. Protect against malicious software | Security (CC7) |
6. Develop and maintain secure systems and software | Security (CC8) — change management |
7. Restrict access by business need to know | Security (CC6) |
8. Identify users and authenticate access | Security (CC6) |
9. Restrict physical access to cardholder data | Security (CC6) — physical access |
10. Log and monitor all access | Security (CC7) |
11. Test security of systems and networks regularly | Security (CC7) — vulnerability management |
12. Support information security with organizational policies | Security (CC1–CC5) — governance |
(No direct PCI equivalent) | Availability, Processing Integrity |
The mapping makes the strategic point plain: roughly ten of PCI DSS's twelve requirements have a direct evidence overlap with SOC 2's Security criterion. Availability and Processing Integrity — the criteria that matter most to a bank or enterprise merchant — have no PCI DSS equivalent at all. That's the actual answer to Maria's original question: PCI DSS was never going to tell Meridian Retail Group whether ClearLane's platform would stay up during a flash sale or whether a batch settlement would post accurately. Only SOC 2 does that.
The Combined Audit Approach: One Evidence Set, Two Reports
Given that overlap, the operationally smart move is not running PCI DSS and SOC 2 as two disconnected annual fire drills. Processors who handle this well build a single control and evidence framework, then produce two reports from it.
Table 16: Combined Compliance Approach — Practical Steps
Step | Action | Benefit |
|---|---|---|
1. Unify the control inventory | Build one control catalog tagged to both PCI DSS requirements and SOC 2 criteria | Eliminates duplicate control documentation |
2. Align observation/assessment periods | Where possible, schedule PCI assessment and SOC 2 Type II period to overlap | Reduces evidence-collection fatigue |
3. Centralize evidence collection | Use one continuous monitoring or GRC platform feeding both audits | Cuts manual evidence-gathering effort significantly |
4. Use one internal audit liaison team | Single point of contact for QSA and CPA firm | Reduces coordination overhead and conflicting answers |
5. Sequence testing logically | Complete PCI DSS scoping/tokenization work first — it shrinks both scopes | Smaller combined scope for the SOC 2 examination |
6. Cross-train control owners | Reconciliation, fraud, and engineering owners understand both frameworks' terminology | Faster, more consistent interview responses during fieldwork |
"The processors who suffer are the ones running PCI and SOC 2 as two separate projects with two separate spreadsheets. The ones who do this well have one control owner per domain who can hand a QSA and a CPA the same evidence folder and just point to a different tab." — Tomasz Kowal, VP Engineering, Fenwick Pay
Visualizing the Combined Assurance Journey
flowchart TD
A[Define System Boundary] --> B[Map Service Commitments & Card Data Flows]
B --> C[Select SOC 2 Criteria: Security + Availability + Processing Integrity]
B --> D[Confirm PCI DSS CDE via Tokenization]
C --> E[Build Unified Control Catalog]
D --> E
E --> F[Readiness Assessment & Gap Remediation]
F --> G[SOC 2 Type I Optional Baseline]
F --> H[PCI DSS QSA Assessment]
G --> I[SOC 2 Type II Observation Period]
H --> J[Report on Compliance / AOC Issued]
I --> K[SOC 2 Type II Report Issued]
J --> L[Combined Evidence Package to Bank/Merchant]
K --> LThis is the flow we walk processors through when both examinations are in play for the first time: scope once, remediate once, then let the two assessments run largely in parallel against the same evidence base rather than as sequential, disconnected projects.
Case Study: ClearLane Payments Closes the $40M Deal
Back to Maria Fontán and ClearLane. Once the team understood that Meridian Retail Group's request wasn't a duplicate of PCI DSS but a request for evidence PCI DSS simply doesn't produce, the project reframed itself. ClearLane scoped a SOC 2 examination covering Security, Availability, and Processing Integrity, built on top of the tokenization architecture it already ran for PCI scope reduction. Because reconciliation, fraud monitoring, and change management were already operationally mature — just undocumented as formal evidence — the gap remediation phase took eleven weeks rather than the five to six months ClearLane's auditor had initially estimated. The Type II observation period ran six months. ClearLane closed its first SOC 2 Type II report nine months after Maria's stand-up, with zero exceptions noted on Processing Integrity and one minor exception on Availability (a documented but untested failover runbook), remediated before the report was finalized. Meridian signed the $40-million integration two weeks after receiving the report, and ClearLane's sales team now leads with the SOC 2 report in every enterprise and bank-partner conversation rather than waiting for it to be requested.
Case Study: Fenwick Pay Catches a Reconciliation Gap Before It Became a Finding
Fenwick Pay, a mid-sized payment gateway processing subscription billing for SaaS merchants, began its first SOC 2 Processing Integrity examination assuming its nightly reconciliation process was airtight — it had run without a reported discrepancy for over two years. During readiness assessment, the audit team sampled twenty exception-log entries from the prior six months and found that eight of them had been closed with a generic "resolved" note and no documented root cause. Two, on closer investigation, traced back to a batch-timing bug that had been silently duplicating a small percentage of retried authorization calls — caught downstream by a manual finance review, but never formally logged as a control failure or fed back to engineering. Fenwick spent three weeks fixing the underlying idempotency handling and rebuilding its reconciliation exception workflow with mandatory root-cause fields before the Type II observation period began, avoiding what would otherwise have been a qualified opinion on Processing Integrity. The CFO's summary to the board: catching it in readiness cost three weeks; catching it in the auditor's report would have cost the renewal cycle with their two largest referral partners.
Case Study: Anchorpoint Processing Uses Tokenization to Shrink Both Audits at Once
Anchorpoint Processing, a payment facilitator onboarding sub-merchants across several verticals, entered its compliance program carrying PCI DSS Level 1 status with a cardholder data environment that touched roughly forty internal systems — reporting dashboards, customer support tooling, and its underwriting platform all handled live PANs at some point in the flow. A front-end tokenization project, completed over four months, moved PAN capture to a dedicated vault and converted every downstream system to token-only processing. The result: the PCI CDE shrank from forty systems to six, cutting PCI assessment fieldwork by more than half. Because the same tokenization boundary cleanly separated "systems that need PCI-grade controls" from "systems that need SOC 2 Processing Integrity and Availability evidence," Anchorpoint's first SOC 2 Type II examination scoped cleanly around the token-based architecture and closed in just over four months from kickoff to report — well under the six-to-nine-month range typical for a first-time payment-processor SOC 2.
Common Pitfalls Payment Processors Hit on Their First SOC 2
Table 17: Common SOC 2 Pitfalls for Payment Processors
Pitfall | Why It Happens | How to Avoid It |
|---|---|---|
Treating PCI CDE scope as the SOC 2 boundary | Assuming "already assessed" systems cover both frameworks | Map service commitments separately; expect the SOC 2 boundary to be broader |
No formal Processing Integrity evidence trail | Reconciliation happens operationally but isn't preserved as auditable evidence | Add timestamped owner/resolution fields to every exception log from day one |
Fraud-rule changes made without change records | Fraud analysts tune rules informally, outside the engineering change process | Apply the same change-management discipline to fraud-rule configuration as to code |
Underestimating subservice organization documentation | Assuming card networks and banks "just work" without formal carve-out language | Document carve-out/inclusive treatment and CUECs explicitly in the system description |
Confusing SOC 2 with a pass/fail certification | Sales and marketing teams borrow "certified" language from PCI DSS habits | Train customer-facing teams: SOC 2 is an attestation with an opinion, not a badge |
Ignoring SOC 1 need entirely | Assuming SOC 2 covers every audience, including merchants' financial auditors | Ask merchants directly whether their auditors require ICFR-relevant assurance |
Starting Type II observation before controls stabilize | Rushing to start the clock to meet a deal deadline | Run a short Type I or informal readiness pilot first to confirm controls are steady |
Cost and Timeline: What to Budget For
Table 18: Illustrative Cost and Timeline Ranges for a Payment Processor's First Combined PCI DSS + SOC 2 Program
Phase | Typical Duration | Illustrative Cost Range | Notes |
|---|---|---|---|
Readiness assessment (both frameworks) | 4–8 weeks | $15,000–$40,000 | Gap analysis against PCI CDE scope and proposed SOC 2 criteria |
Tokenization/scope-reduction project | 8–16 weeks | $50,000–$250,000+ | Highly variable based on architecture maturity; reduces both audit costs going forward |
Control remediation | 6–16 weeks | $20,000–$100,000 | Depends on gap volume; overlaps with readiness findings |
SOC 2 Type I (optional) | 1–2 weeks fieldwork | $15,000–$35,000 | Point-in-time design opinion; not always necessary if going straight to Type II |
SOC 2 Type II observation period | 3–12 months (commonly 6) | Included in Type II fee below | Longer periods generally reassure enterprise/bank buyers more |
SOC 2 Type II audit fee | 4–8 weeks fieldwork | $30,000–$80,000 | Scales with number of criteria and system complexity |
PCI DSS QSA assessment | 6–12 weeks | $40,000–$150,000 | Level 1 assessments cost more than smaller-volume SAQ-eligible entities |
Ongoing annual maintenance (both) | Continuous | $60,000–$150,000/year | Continuous monitoring tooling, internal audit liaison time, control owner effort |
Ranges above are illustrative and vary widely with transaction volume, system complexity, and how much remediation is needed before fieldwork starts — they're meant to set expectations for a budget conversation, not to be quoted as a fixed price. Processors comparing quotes often find our SOC 2 Cost Calculator useful for sanity-checking a vendor's proposal against typical ranges for their volume tier.
A 90-Day Roadmap for a First Combined Examination
Table 19: 90-Day Combined PCI DSS + SOC 2 Kickoff Roadmap
Days | Focus | Key Deliverables |
|---|---|---|
1–15 | Scoping and boundary definition | Unified system boundary, PCI CDE diagram, SOC 2 system description draft |
16–30 | Readiness assessment | Gap list mapped to both PCI requirements and SOC 2 criteria |
31–55 | Tokenization and technical remediation | PAN capture consolidated, downstream systems converted to token-only |
56–70 | Control documentation and evidence pipeline | Reconciliation logs, fraud-rule change records, access reviews formalized |
71–80 | Control owner training | Reconciliation, fraud, engineering teams briefed on both frameworks' evidence expectations |
81–90 | Auditor selection and kickoff | QSA and CPA firm engaged, fieldwork and Type II observation period scheduled |
Processors starting from scratch often find it useful to work from a structured SOC 2 Readiness Checklist alongside a SOC 2 Trust Services Criteria Mapping Template so the technical remediation team and the audit-liaison team are working from the same source of truth from day one.
How This Compares to FinTech and ISO 27001 Programs More Broadly
Payment processors sit inside the broader universe of financial-technology companies pursuing SOC 2, and much of the control philosophy overlaps with what we cover in SOC 2 for FinTech Companies: Financial Service Technology Compliance — sponsor-bank relationships, regulatory-adjacent controls, and the same tension between a mandatory framework (PCI DSS here, banking regulation there) and a voluntary trust-building attestation. If your organization is also pursuing or maintaining ISO/IEC 27001 certification, the good news is that most of the control work is shared rather than duplicated; we cover that overlap directly in ISO 27001 vs NIST/SOC 2/PCI DSS Compared and, for organizations running both an ISMS and a SOC 2 program simultaneously, in Running ISO 27001 and SOC 2 Together. The short version: ISO 27001 certifies an information security management system; PCI DSS mandates cardholder-data protection; SOC 2 attests to broader trust criteria. A mature payment processor eventually ends up with some combination of all three, and the control catalog you build for one should always be built to serve the others.
Turning a Compliance Requirement Into a Sales Advantage
It's easy to treat a SOC 2 request as another box to check after years of PCI DSS discipline. The processors who get the most out of the investment do the opposite: they treat the combined PCI DSS and SOC 2 evidence base as a competitive asset. A bank evaluating sponsorship partners, an enterprise merchant comparing three processors during an RFP, or an ISV deciding which payment platform to embed will all move faster — and often pay a premium — for a partner who can hand over a clean Type II report on day one instead of promising one in six months. The tokenization work that shrinks your PCI scope also shortens your SOC 2 timeline. The reconciliation discipline that satisfies Processing Integrity also reduces real operational risk. None of this is compliance theater; done well, it's the same operational maturity your risk and finance teams already need, documented in a form your sales team can put in front of a prospect. Processors evaluating where they stand today can start with our SOC 2 vs ISO 27001 Comparison Guide and a SOC 2 Control Matrix / RACI Template to see exactly which controls to assign, and to whom, before the next bank partner or enterprise merchant asks the question Maria Fontán once found so irritating.
Ready to see where your own program stands? PentesterWorld's assessment team works with payment processors on exactly this combined PCI DSS and SOC 2 journey — from tokenization architecture through readiness assessment to auditor selection — so reach out when you're ready to turn your next compliance request into a closed deal instead of a stalled one.