Third-Party Risk Management (TPRM) is the process an online merchant uses to identify, assess, contract for, monitor and exit relationships that can affect payments, customer data or business continuity. The relevant third parties may include payment gateways, processors, fraud tools, cloud hosts, software vendors, fulfilment partners and outsourced customer-support providers. A practical programme gives the highest scrutiny to providers that handle sensitive data, can interrupt checkout or settlement, or are difficult to replace.
How to build a third-party risk register
Commercial market estimates indicate continued investment in this field. Fortune Business Insights estimated the global third-party risk management market at USD 11.73 billion in 2026 and forecast USD 38.31 billion by 2034, a 15.94% compound annual growth rate for 2026–2034. These are analyst estimates rather than regulatory statistics, and market definitions can differ between research firms.
A merchant should start with a third-party register that records the service provided, data accessed, system connectivity, countries involved, business owner, contract dates and replacement difficulty. Tier each relationship by impact: a provider that can expose account data, stop payment acceptance or delay fulfilment needs deeper due diligence and more frequent monitoring than a low-impact supplier. NIST’s Cybersecurity Framework 2.0 supply-chain guidance supports prioritising suppliers by criticality and managing their risks throughout the relationship.
Technology supports—not replaces—TPRM governance
Software can help maintain evidence, renewal dates, risk ratings and alerts, but it does not transfer accountability or prove that a provider’s controls work. Use automation to support a defined lifecycle: intake, inherent-risk tiering, due diligence, approval, contracting, onboarding, monitoring, incident handling and offboarding. Assign a named owner and escalation path for each critical relationship, and require human review when an alert could affect customer access, payment routing or service termination.
Third-Party Risk Management requirements: GDPR and PCI DSS
Legal duties depend on the merchant’s role, data, sector and markets. When the EU GDPR applies and a merchant acting as controller appoints a processor, Article 28 requires the merchant to use processors that provide sufficient guarantees and to govern the processing through a binding contract containing specified terms; sub-processor arrangements are also controlled.
For payment-card environments, outsourcing payment processing does not remove the merchant’s PCI DSS responsibilities. The PCI Security Standards Council says merchants should confirm provider compliance for the services used, maintain written responsibility acknowledgements, monitor compliance status at least annually and understand shared responsibilities. Merchants should map the rules that actually apply to each relationship instead of treating GDPR, HIPAA or PCI DSS as universal vendor badges.
Where third-party failure affects online merchants
For an online merchant, third-party failure can appear as checkout downtime, diverted settlements, exposed customer data, fraudulent account access, delayed fulfilment or an unsupported compliance claim. For merchants operating in restricted or closely monitored sectors, these dependencies should also be mapped as part of the wider high-risk payment processing infrastructure.
TPRM cannot eliminate these outcomes. It can make them easier to prevent, detect and contain when the merchant knows which providers support each critical process, limits access to what is needed, tests contractual assurances and has an approved fallback or exit plan.
A practical third-party risk management checklist
Select controls according to the relationship, not the vendor’s product category. For each critical provider:
- Confirm scope and identity: Record the contracting entity, service, hosting locations, data flows, integrations and material sub-processors.
- Test the evidence: Review evidence relevant to the service, such as a current PCI DSS Attestation of Compliance, independent assurance report, penetration-test summary, licence or insurance certificate. Confirm its scope, period and exceptions rather than accepting a logo.
- Allocate responsibilities: Document which party owns access control, security updates, fraud configuration, incident notification, customer support, refunds, backups and regulatory requests.
- Write measurable terms: Set service levels, security requirements, breach-notification timing, audit or evidence rights, sub-processor controls, data return or deletion, termination assistance and change-notification duties.
- Monitor material changes: Track compliance evidence, outages, incidents, ownership changes, new sub-processors, service degradation and contract renewals at a frequency proportionate to risk.
- Plan the exit: Identify data-export requirements, credential removal, token or integration portability, customer communications and an approved replacement path before a critical provider fails.
Questions for your payment provider
Ask each payment provider to answer for the exact service and contracting entity you will use:
- Which entity will process, acquire, gateway, store tokens or settle funds, and which material functions are subcontracted?
- Which PCI DSS responsibilities belong to the merchant and which belong to the provider? Can the provider supply current evidence covering the service in scope?
- What data does the provider receive, where is it processed, how long is it retained and how are sub-processors approved or disclosed?
- What events trigger incident notice, re-underwriting, reserves, settlement delay, suspension or termination?
- What service levels, recovery objectives, support channels and escalation paths apply during an outage or security incident?
- How can the merchant export transaction, reconciliation and token-related data where contractually and technically permitted, revoke access and complete an orderly exit?
Record the answers, unresolved exceptions, evidence owner and next review date. A questionnaire is not a control unless material answers are verified and acted upon. These questions complement WiseAlt’s broader guide to choosing a payment processor for a high-risk business.
Third-party risk management checklist: final priorities
Third-party risk management is not a software purchase or a one-time questionnaire. For online merchants, it is a repeatable process for identifying critical providers, testing relevant evidence, assigning shared responsibilities, monitoring material change and preparing an exit. The depth and frequency of review should follow the provider’s actual access and operational impact.
WiseAlt advises merchants on payment-provider selection, payment infrastructure and operational due diligence. WiseAlt is not a bank, acquirer, payment processor, gateway, law firm or guarantor of approval. For help mapping provider dependencies and preparing questions for a payment partner, contact WiseAlt; obtain qualified legal, privacy and PCI advice for obligations that apply to your business.
