How to scope ISO 27001 for a payment service provider

Scope is where ISO 27001 implementations succeed or fail before the auditor arrives. For a payment service provider - whether that is an acquirer, a payment gateway, a BIN sponsor programme manager, or an embedded finance platform - drawing the ISMS boundary is genuinely difficult. The information flows that carry risk do not respect organisational lines. They cross settlement systems, card scheme connections, sponsor bank integrations, KYC providers, and merchant-facing APIs, often simultaneously.

Get the scope too broad and you take on audit obligations for parts of the business that add cost without proportionate risk reduction. Get it too narrow and the auditor will find that the most significant information assets are sitting outside the scope - which leads to a major nonconformity at Stage 1 that cannot be papered over.

This post covers how to think about ISMS scope for a PSP, the specific inclusion decisions that matter most, and the common scoping mistakes that independent advisors see repeatedly.

What ISO 27001 actually requires from a scope document

ISO 27001:2022 clause 4.3 requires the organisation to determine the scope of the ISMS, considering the external and internal issues identified under clause 4.1 and 4.2, and the interfaces and dependencies between activities performed by the organisation and those performed by external parties.

That last phrase - "interfaces and dependencies between activities performed by the organisation and those performed by external parties" - is the part PSPs consistently underweight. A PSP's core business model is built on interfaces with external parties: card schemes, sponsor banks, KYC/AML providers, FX counterparties, and acquiring banks. The scope document must acknowledge those interfaces and make explicit decisions about what is included and what is excluded from the ISMS boundary.

The scope document needs to name the specific systems, processes, locations, and organisational units within scope. A scope statement that reads "the IT infrastructure and information systems supporting our payment processing business" is not specific enough. An auditor will ask what "payment processing business" means, and if the answer reveals that significant assets are unaddressed, the scope statement is a problem.

The core scope decision: what is a critical or important function?

For a PSP, scoping typically starts with identifying the functions that, if disrupted or compromised, would cause material harm to clients, card scheme obligations, or regulatory compliance. Those functions are the anchor for scope.

For most PSPs, the functions that belong inside the ISMS scope include:

Transaction routing and processing - the systems that receive, authenticate, route, and authorise payment transactions. This is the primary operational asset. It typically includes the payment gateway or processing platform, the API layer connecting merchants to the PSP, and the switching logic connecting to card scheme networks.

Settlement and reconciliation - the processes and systems that calculate net settlement positions, submit files to card schemes or sponsor banks, and reconcile incoming and outgoing settlement flows. Settlement data is among the most sensitive information a PSP holds: it maps directly to client money flows and is an attractive target for fraud or manipulation.

Client and merchant data stores - the databases or platforms holding merchant onboarding records, contract data, transaction history, and fee structures. These are the information assets where a breach would cause direct regulatory and reputational damage.

KYC and AML processing - the onboarding workflow for new merchants or sub-merchants, including identity verification, document storage, and watchlist screening. For a PSP operating under an e-money licence or a payment institution licence, KYC data is a regulated asset with retention and access control obligations.

Sponsor bank and card scheme connections - the interfaces through which the PSP accesses card scheme rails (Visa, Mastercard) or settlement accounts. These interfaces represent the PSP's access to the payment system. Controls over who can initiate transactions, access reconciliation data, or modify routing configurations are high-stakes access control decisions.

Scope too broad: the cost of inclusion without focus

The temptation for a PSP's first ISO 27001 implementation is to include everything - all offices, all teams, all systems, all countries - on the basis that a comprehensive scope is more credible. In practice, a scope that is too broad creates problems.

An ISMS must be governed. Every asset in scope needs an owner, an associated risk assessment, and applicable controls. Every location in scope needs to be covered by the internal audit programme. Every supplier relationship in scope requires written information security agreements and periodic review. If the scope includes a small regional sales office with three staff, a back-office finance team that does not handle payment data, and a customer success function that uses third-party SaaS tools, all of those areas require audit coverage, risk assessment, and control evidence.

A representative scenario illustrates the problem: a PSP scoping its entire European business - including non-payment functions - finds that internal audit has to cover 12 locations and four functional teams. The audit programme takes 14 months, most of the findings relate to non-payment business areas, and the evidence that matters most to customers and regulators (transaction routing, KYC, settlement) is buried in a general audit programme designed to cover everything. The scope is technically comprehensive but operationally unmanageable.

The better approach is to define scope around the functions and systems that carry payment processing risk, and explicitly exclude functions that do not - with a documented justification for each exclusion. A sales office that does not handle transaction data, cardholder data, or merchant financial information can be excluded with a clear note in the scope document.

Scope too narrow: what the auditor finds outside the boundary

Narrowing scope to reduce audit burden is equally problematic when it excludes assets that carry real risk.

The most common narrowing mistake for PSPs is excluding third-party and cloud-hosted components on the basis that "we do not control that infrastructure." ISO 27001:2022 clause 4.3 is explicit: the scope must consider interfaces and dependencies with external parties. A PSP whose transaction routing runs on a third-party hosted platform cannot simply declare that platform out of scope. The ISMS must include supplier management controls (Annex A.5.19 to A.5.23) covering that provider, even if the infrastructure itself is not directly controlled.

A related narrowing mistake is excluding the sponsor bank connection from the ISMS boundary. The sponsor bank relationship typically includes a master services agreement with security provisions, an obligation to notify the bank of security incidents within a defined timeframe, and access to settlement accounts that represent significant financial exposure. That relationship carries information security obligations that belong inside the ISMS, not outside it.

Other assets that are frequently excluded but should be included:

• The PSP's internal ticketing or CRM system where merchant support cases are handled (contains sensitive merchant and transaction data)
• The developer access environment where code changes to the payment platform are made and tested
• Log management and SIEM infrastructure (if logs contain sensitive transaction or authentication data)
• The key management system or HSM infrastructure used for cryptographic operations

Drawing the boundary: a practical sequence

For a PSP working through scope definition, a useful sequence is:

Start with data flows, not org charts. Map where sensitive data - transaction data, cardholder data if any, merchant identity and financial data, settlement data - originates, where it is processed, and where it is stored or transmitted. Every system that touches those data flows is a candidate for inclusion.

Identify the interfaces with external parties. Card scheme connections, sponsor bank APIs, KYC provider integrations, FX counterparties. Each interface is an entry point for risk and needs a scope decision with a rationale.

Assess physical locations. If a key function is performed from an office or data centre, that location needs to be either in scope with associated physical security controls, or explicitly excluded with a justification.

Apply a proportionality test. For each candidate asset or function, ask: if this were compromised or disrupted, would it cause material harm to payment processing, client data, or regulatory obligations? If yes, include it. If not, document the exclusion.

Write the exclusions as carefully as the inclusions. Scope documents that list inclusions without documenting exclusions are incomplete. An auditor reading a scope document that does not mention the sponsor bank connection or the KYC platform will either ask about them (best case) or flag a gap in the scope assessment (common outcome).

When scope changes after initial certification

PSPs grow by adding new payment methods, new geographies, new merchant categories, and new scheme integrations. ISO 27001:2022 clause 4.3 is not a one-time exercise. Scope must be reviewed when the organisation changes in ways that affect the ISMS boundary - a new card scheme licence, a new sponsor bank relationship, a new sub-acquirer vertical. The management review process (clause 9.3) is the mechanism for ensuring that scope reviews happen and are documented.

A PSP that certified with a scope covering Visa and Mastercard processing and then added American Express acquiring without a scope review has a gap in the ISMS that will appear at the next surveillance audit, if not before.

Where Kellwick fits

Kellwick works with payment service providers to define ISMS scope that is defensible, proportionate, and anchored to the assets that carry the most risk - without taking on audit overhead that does not reduce that risk. If you are a PSP approaching certification or reviewing your existing scope, see how the payments readiness review addresses scope and evidence gaps.