How to Evaluate PCI DSS, SOC 2, and ISO 27001 for Payment Platforms

Introduction#

Certifications and regulatory authorisation answer different risk questions, so treat them as separate checks in payment-platform due diligence. For onboarding or renewal, focus on three things: what boundary is attested, who assessed it, and whether the activity also needs separate legal permission. This guide is for compliance, legal, finance, and risk owners evaluating PCI DSS, SOC 2, and ISO/IEC 27001 without confusing them with UK regulatory status.

• PCI DSS: Ask for the exact CDE scope and whether a PCI SSC-qualified QSA performed the assessment. PCI DSS v4.0.1 is listed as Jun. 2024.
• SOC 2 examination: Verify which services and trust criteria are actually in scope.
• ISO/IEC 27001: Confirm which entities, business units, and locations the certificate covers. The ISO page lists ISO/IEC 27001:2022 as Edition 3, 2022-10.
• FCA authorisation or registration (UK): A separate regulatory status, not a certification. For UK payment services, authorisation or registration is tied to the Payment Services Regulations 2017 (UK SI No. 752). The FCA states that nearly all UK financial service activities must be authorised or registered, and firms that want to provide payment services or issue electronic money should check whether they need FCA authorisation or registration.

The practical move is straightforward: map each vendor claim to the risk it actually covers, then request the latest scope statement and current attestation or report for that scope. Broad phrases like "aligned with ISO" or "SOC 2 compliant" are not enough without scoped evidence. This pairs well with our guide on Healthcare Staffing Platform Payments Compliance for Safer Rollouts.

If you are running this review for onboarding or renewal, you should mark the file incomplete until your team has the exact scope statement and the current artifact in hand. We use that rule because we want badge pages kept out of approval evidence.

Selection criteria that separate real coverage from checkbox compliance#

When you approve vendors for card acceptance and cross-border payouts, score scope, evidence, and exception handling before you score certification logos. A narrower, provable control boundary is often easier to validate than a broad integrated-compliance claim that cannot be mapped to production services.

Use this as a gating rule. If a vendor cannot show where payment card data enters, transits, or could affect the Cardholder Data Environment (CDE), and cannot map that boundary to PCI DSS controls and its ISO/IEC 27001 ISMS, pause the review.

1. Control scope clarity

Start here because every later document depends on a clear boundary. PCI scoping guidance uses a conservative default: treat everything as in scope until verified otherwise, and include systems that could impact CDE security, not only systems that directly store or transmit card data. Prefer vendors that can show scoped production architecture and the exact people, processes, and technology in scope.

1. Independent assurance quality

Verify who performed the assessment and what artifact you are actually receiving. For PCI DSS, ask for service-provider attestation artifacts that customers can use as scope evidence. For SOC 2, confirm a CPA examined and reported on service-organization controls. Prioritize current reports with clearly named scoped services over statements like "audited annually."

1. Operational evidence quality

Control claims should tie back to operating records. Ask for exception logs, control ownership records, and policy-to-control mappings that connect PCI DSS requirements to ISMS controls. If the vendor cannot produce that evidence pack, the claim may be hard to defend in your own audit.

1. Remediation maturity

Findings and exceptions are normal. What matters is how they are handled. Check how issues are tracked, who owns remediation, and how status is reviewed over time. One practical checkpoint is cadence: PCI SSC material cites monitoring third-party PCI DSS compliance status at least once every 12 months.

1. Regulatory fit beyond ISO/IEC 27001

ISO/IEC 27001 addresses ISMS governance and continual improvement, not payment-licensing status in each market. In the UK, the Payment Services Regulations 2017 establish firms that must be authorised or registered to provide payment services, and the FCA overview page shows an update date of 17/12/2025. Prefer vendors that can explain whether their operating model triggers FCA authorisation or registration analysis, rather than implying certification alone resolves that question.

If two platforms look similar, choose the one with clearer production scope and better-disclosed exceptions. That decision is usually easier to defend in procurement, internal audit, and renewals.

We covered this in detail in A Guide to SOC 2 Compliance for SaaS Companies.

The 5 certification profiles that actually fit payment platform models#

Most teams do not need the same assurance mix. The right profile depends on where card data sits, who needs assurance evidence, and how complex your operating boundaries are.

1. PCI-led operator

Use this when card acceptance is central and the CDE boundary is clearly mapped. PCI DSS directly targets entities that store, process, or transmit cardholder or sensitive authentication data, including service providers, so it fits card-heavy platform risk. It is especially practical where payment brands or acquirers can drive compliance and validation expectations. The upside is direct, payment-specific control coverage. The tradeoff is procurement depth: without a SOC 2 examination, some enterprise buyers may view a PCI-only posture as too narrow. Check the current service-provider attestation artifact and a production scope map that includes systems that could impact CDE security, not only systems that directly handle card data.

1. SOC-led B2B vendor

This fits when procurement and enterprise assurance reviews are the primary blocker. A SOC 2 examination is a CPA report on controls relevant to security, availability, processing integrity, confidentiality, or privacy, and it is designed for a broad range of users. The limit is straightforward: SOC 2 does not replace PCI DSS when card data is in scope. Use this profile when card-data risk is outside the vendor boundary or separately covered. Confirm the report scope matches the exact production service you will use, not a narrower internal environment.

1. ISMS-led global scaler

Use this when governance has to work across entities, products, and markets. ISO/IEC 27001 defines ISMS requirements, and the current listing is ISO/IEC 27001:2022 (Edition 3, 2022-10). Its strength is governance depth and continual improvement across the organization. Its limit is payment specificity: ISO/IEC 27001 alone does not prove PCI DSS sufficiency for card-data services. If a vendor leads with ISO/IEC 27001, still require an explicit PCI DSS posture for services that store, process, transmit, or could impact card data.

1. Integrated triad

Choose this for mature platforms that need to satisfy payment-specific, enterprise-assurance, and governance expectations at the same time. Combined PCI DSS, SOC 2, and ISO/IEC 27001 coverage can be a defensible model when those expectations overlap. The benefit is audience fit across risk, procurement, and security governance. Aligning PCI DSS and ISO/IEC 27001 can also reduce duplicate compliance work. The tradeoff is coordination load: scope statements, exceptions, and remediation status have to stay aligned across all three assurance tracks.

1. In-progress claimant

Reserve this for early diligence or constrained pilots with explicit contractual safeguards. "Working toward" signals intent, not completed attestation. SDK.finance is a grounded example: on a page dated 11. 12. 2024, it states it is working toward SOC 2 for code storage and development processes and that SOC 2 may not directly apply to the Platform. That is useful disclosure, but it is not the same as a completed CPA examination report. If you proceed, document the assessed boundary, review checkpoints, and reassessment rights before any production expansion.

A practical rule is simple: start PCI-led when card handling is core, SOC-led when procurement assurance is the immediate need, ISMS-led when governance complexity spans markets, and integrated triad when the platform is critical to enterprise payment operations.

If you want a deeper dive, read Gruv Platform Payments: The Complete B2B Guide to Global Payouts Compliance and Embedded Finance.

Where PCI DSS and ISO/IEC 27001 overlap and where they do not#

Use PCI DSS and ISO/IEC 27001 together, but do not treat them as substitutes. If your service handles card data, scope PCI first, then reuse applicable controls in your ISMS.

1. Scope target

PCI DSS is payment-data specific. It applies to entities that store, process, or transmit cardholder or sensitive authentication data, and to systems that could impact CDE security. The CDE includes the people, processes, and technology involved in that handling. ISO/IEC 27001:2022 (Edition 3, 2022-10) is an ISMS requirements standard: establish, implement, maintain, and continually improve information security in organizational context. When you review a vendor, confirm that the PCI scope matches the real production payment boundary, and check whether the ISO scope covers that same service boundary.

1. Control overlap

There is real overlap in security outcomes. PCI SSC mapping shows PCI DSS requirements directly map to 96 of 108 NIST subcategories. But overlap is not replacement. PCI SSC is explicit that mapped frameworks are not interchangeable, and broad risk-framework outcomes alone do not assure payment data protection. Reuse evidence where scope, owner, and timing align, but avoid claims like "aligned to ISO/NIST" without a clear PCI-relevant control map.

1. Implementation sequence

When card handling is central, start with PCI scoping discipline. Underestimating PCI scope is a common first-audit failure and can create downstream rework. Build a production scope map for where card data enters, moves, is stored, and which connected systems can impact CDE security. If you rely on segmentation, validate that it is implemented and defensible. PCI SSC's December 2016 scoping guidance notes segmentation can reduce in-scope components when properly implemented. Practical sequence: define the card-risk perimeter with PCI DSS first, then map reusable controls and evidence into ISO/IEC 27001 to reduce duplicate work without overstating what ISO proves.

Need the full breakdown? Read ISO 27001 Certification for Tech Companies Working With Enterprise Clients.

What evidence to request before you trust a certification claim#

Treat any certification claim as unverified until the vendor shows the certified boundary, current attestation artifacts, and current exception status. This is where strong claims either hold up or fall apart.

1. Scope statement first

Ask for the exact scope statement for each claim: PCI DSS, SOC 2, and ISO/IEC 27001. For PCI DSS, confirm the scope includes all entities and systems that store, process, or transmit cardholder data, or could impact CDE security, not just the payment app front end. If scope is limited to internal IT or a narrow support function, it may be weak evidence for production payment risk.

1. Latest attestation artifacts, not logo pages

For PCI claims, request the current AOC and, when relevant, related assessment output such as a ROC. Check version freshness: PCI DSS v4.0.1 appears in the PCI SSC library (Jun. 2024), with v4.0.1 AOC documents (Aug. 2024) and a v4.0.1 ROC Template (Jan. 2025). If a vendor still circulates older PCI paperwork without explaining the gap, treat it as a review issue. For SOC 2, require the report itself. If it is Type 2, verify operating effectiveness over a defined period, not only control design.

1. Control ownership and exception evidence

Do not stop at certificate or report titles. Request deviation or exception logs, remediation status, and evidence that major controls are tied to owners and test results within the attested scope. Badge pages alone are not evidence packs. Your checkpoint is whether each major control area is tied to an owner, a test result, and remediation status.

1. Verify the certifier and production boundary

For ISO/IEC 27001, verify who issued the certificate, because ISO does not issue certificates itself. Ask for the certification body and whether accreditation can be independently checked. If it is UKAS-accredited, use UKAS CertCheck. Then confirm the certificate scope includes the production payment services you rely on, not only limited internal systems.

1. Treat NIST alignment as supplemental, not dispositive

"NIST-aligned" is not proof of PCI DSS or SOC 2 coverage. PCI SSC states PCI and NIST mappings are supplemental and not interchangeable, and NIST does not run a CSF certification or endorsement program. If a vendor claims "NIST certified" or broad NIST alignment, require an explicit mapping to concrete controls in PCI or SOC 2 materials. Otherwise, treat it as informational only.

You might also find this useful: SOC 2 for Payment Platforms: What Your Enterprise Clients Will Ask For.

Vendor comparison table for compliance and regulatory fit#

Use this table as a decision sheet, not a badge count. If two vendors tie on certifications, choose the one with clearer production-scope boundaries and clearer exception disclosure.

What changes the ranking#

Scope and legal fit usually decide outcomes faster than labels. SDK.finance shows why: the PCI claim is explicit, but the same public text limits that scope and places customer cardholder-data handling responsibility with the customer. If your service touches payment card data, that boundary can matter more than the Level 1 label.

Global Payments / GPUK LLP shows the reverse pattern. The retrieved materials do not establish PCI DSS, SOC 2, or ISO/IEC 27001 status. They do provide a concrete UK authorization signal under PSR 2017 (reference 504290), which is material for UK payment-service use cases.

Verification checks that save time later#

For GPUK LLP, confirm the legal entity name and reference 504290 in the FCA Financial Services Register before approval. For any PCI claim, verify scope against entities and systems that store, process, or transmit cardholder data, and systems that could impact CDE security.

Where teams get misled#

Security-adjacent positioning is not the same as production-environment assurance. Kaseya's public note that some modules may not be SOC2 Type II audited is useful because it gives you a concrete follow-up path. Ask for module-level scope, current report period, and carve-outs for the version you will use.

ISMS.online and VikingCloud signals are mainly tooling or advisory adjacency in the retrieved materials, not proof of a payment vendor's own attested production scope. Certifications also do not replace FCA authorization or registration duties under PSR 2017 when UK payment services apply.

For a step-by-step walkthrough, see How to Build a Deterministic Ledger for a Payment Platform. Use this as your shortlist checklist, then confirm operational evidence and control touchpoints in Gruv's developer docs.

Escalation triggers your team should not handle informally#

Stop informal handling when any of these appears. Route it to legal, compliance counsel, or an executive risk decision. These are perimeter questions, not routine document requests.

1. Certification claims clash with UK market-entry rules

Escalate immediately if a vendor's certification posture looks strong but its UK payment-services status is unclear. Under Payment Services Regulations 2017, payment services in the UK require the provider to fall into permitted categories, and the FCA states it is an offence to provide payment services without correct authorisation or registration. This is a legal perimeter question, not a trust-page question. Confirm the legal entity, the activity you are buying, and whether FCA authorisation or registration is required for that activity. PCI DSS, SOC 2, or ISO/IEC 27001 claims do not replace PSR 2017 or FCA status. If applicability is unclear, seek independent legal or compliance advice.

1. The contract promises "compliance" but does not define scope or evidence

Escalate when contract language says "PCI compliant" or "SOC 2 compliant" without scope boundaries, report commitments, or timing. PCI DSS scope includes entities that store, process, or transmit cardholder data and those that could affect CDE security. PCI scoping guidance also warns that everything is in scope until verified otherwise. Ask for the covered production services and boundaries in writing. For SOC 2, require the actual report and period, since SOC 2 is report-based assurance on controls, not a generic badge.

1. The vendor cannot explain control ownership across subprocessors

Escalate when control ownership across the vendor and downstream providers is unclear. ISO/IEC 27001 addresses ISMS requirements and continual improvement, but certification language alone may not show which party owns which controls in your operating model. This is higher risk when card-data-adjacent systems are involved, because connected service providers can use nested service providers. Require the ISMS scope statement, subprocessor visibility, and a clear written ownership map before treating risk as understood.

1. A high-risk gap remains open at renewal or launch

Do not let commercial urgency override unresolved high-risk gaps. If a material gap is still open at renewal or launch, treat it as a formal exception with mitigation terms, dates, and named owners. If the gap touches UK permissions, PCI scope, or unresolved third-party control ownership, require written mitigation, timelines, and executive sign-off before renewal. Related: How Platform Operators Should Plan PCI DSS Level and Cost.

Implementation sequence that reduces surprises without overbuilding#

Use this order: lock scope first, set assurance expectations second, collect remediation evidence third, and crosswalk controls last. If card handling is central to your model, do PCI DSS scoping before any control mapping.

1. Define your risk posture and card boundaries first

Start with a written data-flow view of where card data is stored, processed, or transmitted, then include anything that could affect CDE security. PCI DSS is a baseline with 12 requirements, but those requirements only become useful after scope is clear.

Checkpoint: can you name the exact production services, networks, devices, and directly connected components that touch or could impact the CDE? If that boundary is fuzzy, later assurance claims will be fuzzy too.

1. Set minimum assurance requirements before requesting documents

Set SOC 2 as a minimum artifact when you need detailed control assurance for a broad set of users. In parallel, set ISO/IEC 27001 expectations for establishing, implementing, maintaining, and continually improving an ISMS. They serve different purposes, and neither replaces PCI DSS when card data is in scope.

Decision rule: use SOC 2 to evaluate report-based control assurance, and use ISO/IEC 27001 to evaluate whether governance operates as an ongoing management system.

1. Request an evidence pack, score gaps, and assign named owners

Do not accept certificates alone. Require remediation-validation records, then score gaps against your target posture and assign named owners with due dates and decision paths.

Assign one coordinator for security-activity closure even if multiple teams own pieces. Without clear ownership, open issues drift into launch or renewal without defensible evidence.

1. Map controls across PCI DSS, SOC 2, and NIST, then run one evidence cadence

After scope and evidence are stable, use crosswalks to reduce duplicate testing where overlap is real. Use Current vs Target Profiles to reveal and prioritize gaps, and treat mappings, especially non-NIST-submitted mappings, as prioritization inputs rather than equivalence claims.

Keep one continuous evidence cadence with shared artifacts, then do separate signoff against each applicable source framework. That keeps operations lean without treating frameworks as interchangeable.

Common mistakes that cause rework in audits and renewals#

Four avoidable mistakes usually drive audit and renewal rework: treating intent as assurance, assuming scope without proof, mixing security evidence with licensing status, and leaving exceptions undocumented.

1. Accepting "in progress" as if it were attested assurance

Treat "working toward SOC 2" or "working toward ISO/IEC 27001 certification" as intent, not completed assurance. SOC 2 assurance is a SOC 2 examination report, and ISO/IEC 27001 certification is issued by an external certification body. Ask for the current SOC 2 report and the ISO/IEC 27001 certificate. If they are missing, record an open gap.

1. Assuming PCI DSS coverage without a proven card-data map

PCI DSS scope includes more than systems that directly store, process, or transmit card data. It also covers components that could affect CDE security, including service-provider environments. If no one can show where card data enters, transits, is stored, and what connected components can impact the CDE, scope decisions may need to be reopened at renewal. For a refresher, see What is 'PCI DSS' compliance and do I need it?

1. Confusing security certifications with payment-services authorization

Security certifications do not replace payment-services authorization context. For UK payment services or e-money activity, confirm whether the entity should be authorized or registered with the FCA, and verify the firm details on the FCA Financial Services Register. Treat this as a separate check from SOC 2, ISO/IEC 27001, or PCI DSS evidence.

1. Leaving exceptions undocumented because the control "basically exists"

Undocumented exceptions can undermine audit defensibility. PCI reporting requires documented compensating-control support for outcomes such as "In Place with CCW," and SAQ guidance ties compensating controls to legitimate, documented constraints. If you approve an exception, document the constraint, approver, expiry, and compensating evidence so the decision survives renewal review.

Applying this to Gruv evaluations and internal governance#

Treat assurance review as an approval gate, not a late-stage document chase. If a PCI DSS, SOC 2, or ISO/IEC 27001 claim is not tied to a current artifact and named scope, mark it as not covered.

1. Make assurance artifacts part of the approval record

In intake and renewal records, require the exact evidence for each claim: the latest SOC 2 examination report, the ISO/IEC 27001 certificate with scope statement, and PCI DSS validation material where card data or components that could impact the CDE are in scope. Record what is attested now versus planned, because "working towards" is not an issued report, certificate, or validation result.

1. Test payout and virtual-account claims against operating evidence

Trust pages help with orientation, but they are not enough for payout or virtual-account decisions. Require operating artifacts such as a current card-data flow or payment-data boundary diagram, production control ownership, exception logs, and recent access-review or change evidence. If a vendor cannot show where data enters, transits, and which connected components could impact the CDE, treat scope as unresolved.

1. Use precise status language in stakeholder updates

Use four labels in every update: attested, in progress, unknown, and needs specialist review. This prevents "aligned" from being interpreted as completed assurance. For example: "ISO/IEC 27001 certificate and scope statement received; SOC 2 report pending; PCI DSS scope not yet evidenced."

1. Tie the checklist to architecture and regulatory decisions

When design choices affect payout rails, message formats, or UK payment activity that may require FCA authorization or registration, connect assurance review early. ISO 20022 is an international financial messaging standard, and the Fedwire Funds Service announced completed migration on July 15, 2025. That indicates richer payment data can influence operations and sanctions/AML handling as well as format design. Keep FCA perimeter checks separate from security-assurance checks, and if ISO 20022 changes payment data content, link that review to payout architecture planning in this migration guide. Related reading: Understanding Payment Platform Float Between Collection and Payout.

Conclusion#

Do not choose the vendor with the most badges. Choose the one that can prove scope, provide current attested evidence, and show clear escalation paths when gaps appear.

If you need one operator shortcut, check your boundary map before you compare certification logos. We do that because our first question is whether the attested service matches your production dependency.

1. Scope proof beats logo count

Start with scope boundaries. PCI DSS is scope-based for entities that store, process, or transmit cardholder data, so confirm where card data enters, moves, and exits the environment. For ISO/IEC 27001, review the certificate and ISMS scope statement, and verify that scope covers the production payment service you plan to use.

1. Attested artifacts beat marketing language

Base approval on artifacts: the latest SOC 2 examination report, the ISO/IEC 27001 certificate with scope wording, and PCI DSS validation documents. When you need requirement-level detail for card controls, request the ROC because it documents environment, methodology, and status by requirement. Treat statements like "working toward SOC 2" as in-progress posture, not completed assurance.

1. Escalation discipline beats informal acceptance

Security attestations do not replace local regulatory checks. For UK payment services or e-money activity, run a separate FCA authorization or registration check under the Payment Services Regulations 2017 or the Electronic Money Regulations 2011, as applicable. Escalate early when contracts promise broad "compliance" but do not name the exact artifact, scope boundary, or renewal commitment.

Use one comparison table and evidence checklist for onboarding, renewal, and market expansion. Record whether the SOC 2 report is current, whether the ISO/IEC 27001 scope matches the service sold, and whether PCI DSS evidence is current enough for your risk posture. Also record whether exceptions or remediation items remain open. If a vendor cannot explain control ownership across subprocessors or cannot show that production payment services are in scope, treat that as a decision risk, not an administrative detail.

If you need a practical review of certification scope versus real payout operations, talk with Gruv.