SOC 2 · Fintech & financial services
SOC 2 Readiness for Payment Processors & PayFacs
This engagement exists because a PCI AOC answers questions about your cardholder data environment, and platform partners embedding your payments increasingly want assurance about everything else too: uptime of the API they integrate against, how you manage merchant KYB data, how changes reach production. We scope the SOC 2 examination around your broader service organization, close the gaps, and prepare you for the auditor. Most PayFacs start this when an ISV or marketplace partner's procurement team asks for a report the AOC was never designed to be.
Reviewed by the Privacy Horizon team · Last reviewed
What you're protecting
What SOC 2 examines beyond your PCI scope
PCI DSS validates the CDE. SOC 2, when a platform partner asks for it, is really asking about the operational spine around your whole payments platform.
The full service organization, not just the CDE
Merchant portal, onboarding systems, ledger and the APIs your platform partners integrate against all become part of the audited system, whether or not they touch raw cardholder data.
Availability of the platform partners depend on
If the availability criterion is in scope, incident history, uptime commitments and your recovery arrangements for the payment API all become control territory a PCI AOC never addresses.
Access lifecycle across the broader estate
Provisioning, role changes and revocation across onboarding tools, the merchant portal and internal admin consoles, not only the systems PCI scopes as CDE-adjacent.
Change management for a partner-facing API
How new releases reach the API your integration partners depend on, and how those changes are reviewed and approved, since a partner's own customers feel every regression.
Confidentiality of merchant and ledger data
Beneficial-owner files, settlement records and fund balances sit outside PCI's cardholder-data definition but squarely inside what a platform partner's confidentiality criterion is meant to protect.
Regulatory map
Where the SOC 2 demand on PayFacs actually comes from
No statute requires SOC 2 of a Canadian PSP. The requirement is set by the platform partners and marketplaces you sell through, and understanding what they are really asking for shapes the whole response.
Platform partners standardizing on SOC 2
ISVs and marketplaces embedding your payments increasingly treat SOC 2 as their baseline vendor-assurance requirement, separate from and broader than the PCI attestation you already hold.
PCI's AOC covers a narrower boundary
An Attestation of Compliance speaks to cardholder-data controls within the CDE; it says nothing about platform availability, merchant-portal access management or ledger confidentiality, exactly the gap a partner's SOC 2 request is trying to close.
Sponsor due diligence accepting transferable assurance
A sponsor running B-10-style oversight can either assess you directly or accept an independent report; for PayFacs with several sponsor and platform relationships, one SOC 2 examination can replace a season of bilateral reviews.
PIPEDA obligations underneath the criteria
SOC 2's confidentiality and privacy criteria overlap heavily with what safeguarding merchant-owner and cardholder data already requires by statute, so readiness work discharges legal duties while it builds audit evidence.
What goes wrong
What the readiness process surfaces at a PayFac
The gap review tends to find the same soft spots, each one a genuine risk your PCI assessment was never scoped to catch.
Access nobody re-certified outside the CDE
Merchant-portal and onboarding-tool access often gets far less scrutiny than the CDE, even though it reaches the same beneficial-owner and settlement data a partner's confidentiality criterion cares about.
Undocumented reliance on the KYB vendor
The vendor-management criteria expect a documented view of what your KYB and identity-verification provider actually does, not an assumption that its marketing page describes reality.
Evidence that evaporates
Controls performed but never recorded, access reviews held in someone's head, cannot support a Type II observation period, however solid the underlying practice actually is.
Outages that never reached your PCI evidence
A platform-affecting outage can be entirely outside your PCI AOC's scope while being exactly what a partner's availability criterion, and potentially the RPAA's own notification duty, is watching for.
Our soc 2 for payment processors & payfacs
What our SOC 2 preparation includes for a PayFac
Gap review, documentation, control support, internal review and steady guidance through to the auditor, scoped around the platform your partners actually integrate against.
Demand analysis before commitment
We examine what your partner actually needs, sometimes a completed questionnaire or a readiness letter genuinely suffices, so you only commit to the audit the relationship demands.
System description and scoping
Defining the service, the system boundary and the trust criteria in scope, deliberately drawn to complement rather than duplicate your existing PCI scope.
Gap review against the criteria
A structured comparison of current practice to the selected criteria, producing a remediation plan ordered by audit impact and how much it overlaps with controls PCI already required.
Documentation and control build-out
Policies, procedures and control descriptions written for a platform business, with evidence capture designed into normal release and access-management workflows.
Internal review and auditor preparation
A pre-audit check of readiness, coaching for the people facing interviews, and support selecting and managing the CPA firm that issues the report.
How the engagement runs
The readiness path from partner demand to report
Sequenced so the platform relationship is protected from day one, not only once the audit is complete.
Step 1
Respond to the partner now
We help you answer the procurement request immediately with a credible plan and interim assurances, which usually secures the time preparation needs.
Step 2
Scope and gap review
Boundary, criteria and current-state assessment complete within weeks, producing the remediation roadmap and a realistic audit timeline.
Step 3
Remediate and evidence
Controls close in priority order while evidence accumulates, coordinated with your PCI cycle so the same access reviews and change logs serve both.
Step 4
Type I, observation, Type II
Many PayFacs take a Type I to satisfy an urgent partner requirement, then run the observation period into a Type II that sustains the relationship long term.
What it costs
The cost picture for a PayFac's SOC 2 readiness
Cost tracks the distance between current practice and the criteria you select: security alone is a smaller lift than adding availability and confidentiality, and how much of your PCI evidence, access reviews, change logs, incident records, can be reused rather than built from scratch. Platform breadth matters more than headcount here.
Budget separately for the audit itself, the CPA firm's fee, which varies with scope and report type, and remember a Type II adds the observation period to the calendar. We quote the readiness work fixed after an initial review of your current PCI evidence and platform architecture.
Payment Processors & PayFacs: SOC 2 questions, answered
Not by law, but commercially, often yes. PCI DSS validates your cardholder data environment; it says nothing about platform availability, merchant-portal access management or how you handle KYB and ledger data outside PCI's definition of cardholder data. If your growth runs through platform partners or marketplaces whose own procurement standardizes on SOC 2, the report becomes the price of the integration, separate from and additional to the PCI attestation you already maintain.
Usually both, for different reasons. The AOC proves your cardholder-data controls meet PCI DSS; the SOC 2 report proves the broader service organization, availability, access management, change control and confidentiality across systems the AOC never reaches, operates soundly. A partner integrating your embedded-payments API typically wants assurance about both what happens to card data and what happens when your platform changes or goes down, which is exactly the gap between the two reports.
Substantially, yes, where the systems overlap. Access reviews, change-management records, incident logs and vulnerability-management evidence built for PCI DSS map directly onto SOC 2's security criterion for the same systems. What usually needs building fresh is evidence for systems outside PCI scope, the merchant portal, onboarding tooling, the ledger, and for any additional criteria like availability that PCI doesn't address at all.
Type I attests controls are suitably designed at a point in time; Type II adds evidence they operated effectively across an observation window, and sophisticated platform partners discount Type I accordingly. The pattern that serves most PayFacs well is committing to Type II as the destination, using a Type I only when a partner needs paper before an observation period can complete.
Security is the mandatory baseline. Availability is worth adding when partners integrate against your API directly and care about uptime, which is common for embedded-payments relationships. Confidentiality is worth adding given how much merchant KYB and settlement data you hold outside PCI's cardholder-data definition. Processing integrity and privacy are less commonly requested but worth confirming against your specific partner's questionnaire before excluding them.
Running the two in parallel is usually faster than sequencing them, since the same access reviews, policies and change records can serve both once the SOC 2 scope is defined. A gap review typically completes within weeks; the harder variable is the Type II observation period, generally several months, which is why PayFacs facing a near-term partner deadline often start with a Type I timed to their PCI assessment window.
More for payment processors & payfacs
Other services for this niche
About this service
Answers & guides
What's Protecting Your Business from the Next Threat?
Don't wait for a breach to expose your vulnerabilities. Let Privacy Horizon secure your data, ensure compliance, and build lasting trust.