Payment Processor Due Diligence for Enterprise Vendor Files: SOC 1 vs SOC 2, PCI AOCs, and the Exhibits Your Auditors Expect

An enterprise payment processor due-diligence file should do more than prove that somebody downloaded a SOC report and an insurance certificate. 

It should show what services the processor performs, which legal entities and systems provide those services, what independent evidence covers them, what responsibilities remain with the enterprise, which gaps were identified, and how those gaps were resolved or accepted.

That is the purpose of payment processor due diligence documents.

Depending on the relationship, a complete file may include a SOC 1 Type II report for controls relevant to financial reporting, a SOC 2 Type II report addressing applicable security and other Trust Services Criteria, a current PCI Attestation of Compliance, insurance documentation, business continuity and disaster recovery evidence, financial-condition information, a subprocessor inventory, privacy documentation, and key contractual exhibits.

The objective is not to collect the largest possible pile of compliance documents. It is to determine whether each artifact actually covers the service, legal entity, systems, locations, dependencies, and reporting period the enterprise relies on.

That distinction matters. A processor can maintain credible assurance reports while a particular product, subsidiary, newly acquired platform, token vault, or outsourced dependency falls outside the scope the enterprise assumed it was reviewing.

What Payment Processor Due Diligence Documents Should You Collect?

The appropriate evidence package starts with the services being purchased.

An enterprise using a processor only for a hosted payment page may require a different level of review from an organization relying on the same provider for gateway services, acquiring, token storage, recurring billing, settlement reporting, dispute workflows, and multi-region processing.

Begin by documenting exactly what the provider does.

The service inventory might identify:

• acquiring or transaction processing;
• payment gateway services;
• hosted checkout;
• tokenization and credential vaulting;
• recurring billing;
• settlement and funding;
• transaction reporting;
• chargeback and dispute management;
• fraud screening;
• payment orchestration;
• API connectivity;
• point-of-sale connectivity;
• cross-border payment services.

Once the service inventory exists, map each artifact to a specific risk.

A SOC 1 report may address financial-reporting dependencies. A SOC 2 report may provide assurance about security or other applicable Trust Services Criteria. A PCI AOC addresses PCI DSS validation scope. Insurance provides evidence of certain risk-transfer arrangements. 

BCP and DR documentation addresses resilience. Financial information addresses viability. Contract exhibits determine what the processor is actually obligated to do.

This prevents a common vendor-management failure: obtaining many documents without establishing what any of them prove.

Processor Due Diligence Document Matrix

Document	Primary Risk Addressed	Internal Owner	Typical Refresh Approach	Key Review Question
SOC 1 Type II, when relevant	Financial-reporting controls	Controllership, SOX, Internal Audit	Review current report during periodic assessment	Does the report cover processor activities relevant to our financial reporting?
SOC 2 Type II, when relevant	Security and other scoped Trust Services Criteria	Security, GRC, Vendor Risk	Review current report periodically	Does the described system include the services and infrastructure we use?
PCI DSS AOC	Card-data security validation	Security, PCI, Payments	Review current applicable validation	Are our processor services within the assessed PCI scope?
ROC or additional PCI evidence, where necessary	Detailed PCI assessment evidence	PCI, Security	Risk-based	Is additional detail required to resolve a material scope question?
Cyber insurance certificate	Cyber-risk transfer	Procurement, Risk, Legal	Review current policy period	Is the appropriate legal entity insured?
Technology E&O/professional liability	Errors in technology or professional services	Legal, Procurement	Risk-based	Is coverage relevant to the contracted activity?
Business continuity summary	Continuity of critical business functions	Operational Resilience	Periodic review	Can essential processor operations continue during disruption?
Disaster recovery summary	Technology recovery	Technology, Resilience	Periodic review	How are critical systems recovered following disruption?
BCP/DR test evidence	Recovery preparedness	Resilience, Technology	Review latest relevant test	Has recovery capability actually been exercised?
Financial statements/public filings	Financial viability	Finance, Procurement	Risk-based periodic review	Is the processor financially capable of supporting the relationship?
Subprocessor list	Fourth-party dependency	Vendor Risk, Privacy, Security	Periodic and event-driven	Who supports the service behind the processor?
DPA/privacy exhibit	Privacy and data processing	Privacy, Legal	Contract and change-driven	Where and how is relevant data processed?
Incident-response summary	Cyber and operational response	Security, GRC	Risk-based	Does the vendor have an established response and escalation structure?
Penetration-test executive summary, where appropriate	Technical security testing	Security	Risk-based	Does testing relate to systems that support our service?
Regulatory or licensing evidence, where applicable	Legal and regulatory authority	Legal, Compliance	Requirement-dependent	Does the entity hold the permissions required for the service performed?

The document list should be risk-based rather than universal. A lower-risk service may not justify every artifact in the matrix, while a processor deeply embedded in settlement, recurring billing, or card-data handling may require considerably more scrutiny.

SOC 1 vs SOC 2 for a Payment Processor

Understanding SOC 1 vs SOC 2 payment processor reporting is essential because the reports answer different questions.

AICPA describes SOC 1 as an examination of controls at a service organization that are likely to be relevant to user entities’ internal control over financial reporting. SOC 1 reports are intended for user entities and the auditors of those entities when evaluating how outsourced controls affect financial reporting.

SOC 2 addresses a service organization’s system and controls relevant to security, availability, processing integrity, confidentiality, or privacy, depending on the scope of the engagement.

Organizations needing authoritative definitions can refer directly to the AICPA SOC reporting guidance.

SOC 2 should not be described as a certification. It is an attestation report.

SOC 1 vs SOC 2 Comparison

Attribute	SOC 1	SOC 2
Primary focus	Controls relevant to user entities’ internal control over financial reporting	Controls relevant to applicable Trust Services Criteria
Typical reviewers	Finance, controllership, internal audit, SOX, financial statement auditors	Security, GRC, privacy, technology, procurement, vendor risk
Payment-related examples	Settlement, reconciliation, transaction completeness, fee calculations, reporting	Access controls, security monitoring, availability, change management, incident processes
Type I	Design of controls at a specified date	Design of controls at a specified date
Type II	Design and operating effectiveness over a period	Design and operating effectiveness over a period
Replaces the other?	No	No

The correct question is therefore not “Which report is better?”

It is:

Which risks created by this processor relationship need independent assurance, and which report addresses those risks?

Why Finance and Audit Care About SOC 1

Payment processing can directly feed financial reporting.

Consider settlement files imported into an ERP. Finance may rely on those files to reconcile cash, transaction totals, fees, refunds, and chargebacks.

A processor may also calculate fees, prepare transaction reports, maintain settlement records, or transmit information used in revenue-related controls.

If those outsourced processes are relevant to internal control over financial reporting, SOC 1 may become important to controllership, SOX, internal audit, or financial statement auditors.

Mapping the authorization, clearing, and settlement workflow before reviewing the SOC report can help identify precisely where processor information enters financial systems.

SOC 1 should still be requested based on relevance. It is not automatically required merely because the vendor processes payments.

Why Security and GRC Care About SOC 2

Security teams evaluate a different set of dependencies.

A payment provider may operate administrative portals, payment APIs, token systems, infrastructure, privileged-access processes, monitoring tools, change-management processes, incident-response procedures, and other technology that the enterprise cannot directly control.

Those dependencies explain why security and GRC teams often seek SOC 2 evidence.

However, “SOC 2 Type II received” should never be the final review conclusion.

The reviewer should determine:

• which legal entity is covered;
• which system is described;
• which products are included;
• which Trust Services Criteria are included;
• which locations or infrastructure are relevant;
• what period the examination covers;
• what exceptions occurred;
• which controls the customer must perform;
• which subservice organizations are excluded or included.

Security architecture should also be considered separately from assurance status. Controls such as encryption, authentication, access restriction, segmentation, and tokenization still need to be evaluated according to the payment architecture being deployed.

Type I vs Type II: Why the Reporting Period Matters

SOC Type I and Type II reports provide different kinds of evidence.

A Type I report evaluates the design of controls at a specified point in time.

A Type II report addresses both control design and operating effectiveness over a defined period.

That distinction often makes Type II more informative for a mature service provider because it provides evidence about whether controls operated during an examination period rather than only whether controls were suitably designed at one date.

That does not mean Type I should automatically be rejected.

A newly implemented platform or newly established control environment may initially have only Type I evidence. The enterprise can evaluate whether that evidence, combined with other safeguards and follow-up commitments, is sufficient for the current risk.

The vendor file should record the distinction rather than treating “SOC report received” as a binary field.

How to Read a SOC Report Without Missing the Important Parts

The most important information in a SOC report is rarely limited to its cover page.

At minimum, a reviewer should examine:

• report type;
• report period;
• service organization;
• described system;
• products or services within scope;
• service auditor’s opinion;
• exceptions or deviations;
• management responses where included;
• complementary user entity controls;
• subservice organizations;
• relevant system changes.

The review should then be summarized in a short internal memorandum or structured vendor-risk record.

SOC Report Review Checklist

Item	What to Check	Potential Concern
Report type	SOC 1/SOC 2 and Type I/Type II	Evidence does not match the risk under review
Legal entity	Entity named in the report	Different entity from the contracting processor
System description	Systems and services included	Product used by the enterprise is unclear
Examination period	Dates actually covered	Material assurance gap
Auditor’s opinion	Nature of the opinion	Qualification or other modification requiring assessment
Control testing	Relevant test results	Repeated or significant deviations
Management response	Explanation and remediation	Unresolved finding without credible action
CUECs	Customer responsibilities	Required internal control has no owner
Subservice organizations	Inclusive/carve-out treatment	Critical dependency is outside tested scope
Major changes	Acquisitions, migrations, redesign	Current deployment may differ materially from report scope

Opinion, Exceptions, and Scope

Start with the auditor’s opinion.

Determine whether the opinion contains qualifications or other modifications that may affect reliance on the report.

Then examine scope.

A favorable opinion does not mean every product sold by the company was examined. The system description determines what the report actually addresses.

The enterprise should be able to answer:

Can we trace the service named in our contract to the system described in this SOC report?

If the answer is uncertain, seek written clarification.

Exceptions require equally careful interpretation.

A control exception means the auditor identified a deviation during testing. One exception does not automatically make the processor unacceptable.

The more useful questions are:

• Which control failed?
• Which system did it affect?
• Did it affect the service we use?
• Was it isolated or recurring?
• How long did the issue exist?
• Did management implement remediation?
• Are compensating controls available?
• Has a similar issue appeared previously?

A deviation in an irrelevant system deserves a different response from a repeated failure affecting settlement data or privileged access to a system the enterprise depends on.

Complementary User Entity Controls

Complementary user entity controls—CUECs—deserve special attention because they convert a vendor report into enterprise responsibilities.

The processor’s control framework may assume that customers perform certain controls themselves.

Depending on the actual report, those controls might involve account provisioning, periodic access review, reconciliation, configuration, escalation procedures, key-management responsibilities, or other customer activities.

These are examples only. CUECs must always be taken from the specific report being reviewed.

The enterprise should not merely copy them into the due-diligence file.

Each applicable CUEC should become an internal control action.

CUEC Action List

CUEC	Internal Owner	Existing Control?	Evidence	Gap
Applicable report requirement	Assigned business or control owner	Yes/No	Control evidence	Remediation if needed
Applicable report requirement	Assigned owner	Yes/No	Review record	Identified deficiency
Applicable report requirement	Assigned owner	Yes/No	System evidence	Follow-up action

The important question is not whether the processor listed CUECs. It is whether the enterprise performs the relevant ones.

Pro Tip: Add CUECs to the same control inventory used for internal testing. Leaving them inside a vendor PDF makes them easy to miss during future audits.

Complementary Subservice Organization Controls

Processors frequently depend on other organizations.

Examples can include:

• cloud infrastructure;
• data centers;
• telecommunications;
• fraud platforms;
• tokenization systems;
• identity services;
• banking partners;
• software infrastructure providers.

SOC reports may treat these dependencies using an inclusive or carve-out approach.

Under an inclusive approach, relevant controls at the subservice organization are included in the description and examination.

Under a carve-out approach, the subservice organization’s controls are excluded from the service auditor’s examination of that system, although controls maintained by the processor to monitor the dependency may still be covered.

This distinction matters because a processor cannot eliminate dependency risk merely by outsourcing a function.

If a critical payment capability relies on a carved-out subservice organization, determine whether additional assurance evidence is necessary.

How to Verify a PCI Attestation of Compliance

The PCI AOC should be reviewed with the same attention to scope as a SOC report.

PCI SSC’s current document library provides PCI DSS v4.0.1 assessment materials, including separate Attestations of Compliance for merchants and service providers and the corresponding ROC framework. The authoritative forms are available through the PCI Security Standards Council document library.

For a PCI attestation of compliance vendor review, verify more than the presence of an AOC PDF.

The reviewer should understand:

• which legal entity was assessed;
• whether it was assessed as a service provider;
• which services were included;
• what version of PCI DSS formed the basis of the validation;
• when the assessment was completed;
• what validation method was used;
• what assessor information applies;
• which systems or locations are identified;
• which relevant third parties are part of the scope.

PCI AOC Validation Matrix

Field	What to Verify	Why It Matters
Assessed entity	Legal name	Shows who was actually assessed
Commercial/DBA name	Relationship to vendor brand	Helps reconcile brand and legal entity
Assessment information	Current assessment details	Helps identify stale evidence
PCI DSS version	Standard used	Establishes the assessment framework
Service-provider role	Nature of assessment	Confirms correct context
Assessor information	QSA or other applicable validation context	Supports assessment verification
Services included	Processing, gateway, hosting, vaulting, etc.	Connects AOC to the service consumed
Environment	Systems and locations described	Clarifies scope
Dependencies	Relevant third parties	Identifies nested service-provider risk
Conclusion	Assessment outcome	Establishes what was attested

AOC vs ROC

The AOC and ROC are related but different.

The AOC is the formal attestation summarizing the result and scope of the PCI DSS assessment.

The ROC, or Report on Compliance, contains considerably more detailed assessment evidence.

Customers often receive the AOC because the ROC can contain sensitive information about infrastructure, control testing, and system design.

An enterprise should not assume it needs the complete ROC for every processor relationship. Additional detail may be appropriate where a material scope question remains unresolved, but the request should be proportionate to the risk and confidentiality involved.

Verify the Service You Actually Use

A statement that the processor is “PCI compliant” is insufficient.

The enterprise may use only one component of a much larger corporate platform.

That component could be:

• a hosted checkout page;
• gateway API;
• acquiring service;
• token vault;
• recurring billing service;
• payment orchestration layer;
• point-to-point encryption service;
• ecommerce integration.

Determine whether the service described in the contract is represented in the AOC.

Organizations with complex integrations should also map PCI DSS requirements for enterprise payment systems against their own payment architecture instead of relying entirely on the processor’s validation.

PCI compliance by a service provider does not eliminate the customer’s own PCI responsibilities.

Check Legal Entity Alignment

Large payment providers frequently operate through several companies.

The contracting legal entity may differ from:

• the commercial brand;
• the entity named in the SOC report;
• the PCI assessed entity;
• a regulated subsidiary;
• an acquiring entity;
• a technology affiliate.

That difference is not automatically problematic.

The problem occurs when the vendor file cannot explain the relationship.

Maintain a documented mapping such as:

Commercial brand → contracting entity → SOC entity → PCI entity → material affiliate

Where the relationship is unclear, request written confirmation from the processor.

Assessor and Service-Provider Classification

Avoid assuming every processor follows an identical PCI validation process.

Card brands, acquirers, and compliance-accepting entities can impose validation requirements depending on the processor’s role and circumstances.

If terms such as “Level 1 service provider” appear in vendor material, verify them against the applicable card-brand or acquiring requirements instead of copying the classification into the risk file without context.

The key operational question remains the same:

Does the validation evidence actually cover the service and environment on which the enterprise depends?

Scope Creep and Product Changes

Annual review should not be the only trigger for PCI reassessment.

Suppose the enterprise initially contracts for a gateway but later enables:

• network token services;
• recurring billing;
• hosted payment fields;
• a different acquiring route;
• a newly acquired platform;
• an additional data region.

That change can alter the risk and assurance mapping.

Confirm whether the new service remains within the same SOC and PCI scope. If necessary, obtain updated evidence or written scope confirmation.

Insurance Evidence

Insurance fills a different part of the processor risk file.

Depending on the relationship, procurement or risk teams may request evidence of:

• cyber liability coverage;
• technology errors and omissions or professional liability;
• crime or fidelity coverage where relevant;
• general liability where procurement policy requires it.

Do not prescribe universal limits.

Appropriate insurance requirements depend on factors such as transaction exposure, data handled, contractual liability, business criticality, and the enterprise’s own insurance program.

What to Check

Review:

• insured legal entity;
• insurance carrier;
• policy period;
• stated limits;
• deductible or retention where available;
• applicable certificate-holder information;
• material exclusions where policy detail is available.

A certificate of insurance is evidence that stated coverage exists. It is not the equivalent of reviewing the complete policy.

If a material exposure depends on a particular form of coverage, legal or risk specialists may need to examine the actual policy language rather than relying solely on the certificate.

Business Continuity and Disaster Recovery

Business continuity planning and disaster recovery address related but distinct problems.

Business continuity planning focuses on keeping critical business operations functioning during disruption.

It can include:

• personnel;
• alternate operating procedures;
• communications;
• supplier dependencies;
• facilities;
• operational workarounds;
• decision authority.

Disaster recovery focuses more specifically on restoring technology, infrastructure, applications, and data after an interruption.

A strong processor due-diligence file should therefore avoid a checkbox labeled simply “BCP/DR = Yes.”

What to Ask for in a BCP/DR Summary

For a material processor, useful review information may include:

• governance and accountability;
• critical services included in planning;
• testing cadence;
• major dependencies;
• recovery priorities;
• alternate sites or cloud regions where applicable;
• communication procedures;
• escalation arrangements;
• RTO and RPO information where disclosed;
• latest relevant test date;
• high-level test result;
• unresolved material findings.

The enterprise rarely needs sensitive infrastructure detail solely to establish whether resilience testing occurs.

RTO and RPO

Recovery Time Objective and Recovery Point Objective are different measures.

RTO represents the target period for restoring a service after disruption.

RPO represents the point to which data must be recovered, effectively describing the tolerable data-loss window.

A processor might publish or contractually provide different objectives for different services.

Do not assume a platform-wide RTO or RPO.

Match the objective to the actual processor component and compare it with the enterprise’s business-impact tolerance.

A gateway that supports checkout may have different recovery implications from a historical reporting portal.

Financial Condition

A critical payment processor can create significant dependency.

Financial review may therefore be appropriate when failure or deterioration could create:

• operational disruption;
• reduced investment in security or resilience;
• weakened customer support;
• pressure on technology programs;
• acquisition or restructuring risk;
• difficult migration circumstances.

Potential evidence includes:

• audited financial statements;
• SEC filings for public companies;
• credit-rating information;
• parent-company information;
• appropriate private-company financial evidence.

The objective is not to make an investment recommendation.

It is to determine whether there are financial conditions that materially change the enterprise’s vendor-risk assessment.

Subprocessor Evidence and Fourth-Party Risk

A third-party risk payment provider assessment is incomplete if the review stops at the direct processor.

Processors can depend heavily on other organizations for hosting, identity, telecommunications, fraud analysis, support, or other critical activities.

Request enough information to understand material subcontractors or subprocessors.

Useful fields include:

Field	Review Question
Legal name	Who is the dependency?
Service provided	What does it do for the processor?
Geography	Where is the relevant activity performed?
Data access	Which categories of data can it access?
Criticality	What happens if the provider fails?
Replacement process	How is a significant provider replaced?
Notification process	How are customers informed of material changes?

Not every processor publishes its full supplier ecosystem publicly.

That does not mean procurement should demand commercially sensitive information about every vendor.

The review should focus on dependencies that are material to the enterprise’s service, security, privacy, or continuity risk.

Data Residency and Processing Locations

Payment environments can involve several categories of information:

• payment-account data;
• transaction information;
• tokens;
• fraud data;
• application logs;
• support records;
• personal information;
• settlement information.

Ask where relevant categories are stored, processed, accessed, or backed up.

Do not treat PCI DSS compliance as a substitute for privacy or data-residency analysis.

PCI DSS addresses payment-data security. Privacy law, contractual obligations, cross-border transfer requirements, customer commitments, and localization rules can create additional requirements.

Subprocessor Change Notifications

Contracts can also establish how material subprocessor changes are handled.

Depending on the relationship, provisions may address:

• advance notice;
• updated subprocessor lists;
• privacy assessment;
• security reassessment;
• objection mechanisms where appropriate;
• consequences of a material unacceptable change.

There is no universal notification period that should be inserted into every processor agreement.

The required period should provide enough practical time for the enterprise to satisfy its own legal, operational, and risk obligations.

Bridge Letters and SOC Reporting Gaps

SOC Type II reports cover historical periods.

An enterprise fiscal year or audit period may extend beyond the report’s end date while the processor’s next report is not yet available.

That is where a bridge letter can become useful.

A bridge letter is generally a management representation addressing the period after the end of the SOC examination period. It may address whether material changes or significant events occurred in the control environment during the gap.

It is not an independent SOC examination.

Example of a Timing Gap

Assume:

• SOC 2 Type II period ends September 30.
• Enterprise fiscal year ends December 31.
• The next SOC report has not yet been issued.

The enterprise or its auditor may request bridge information covering October through December.

The bridge documentation should be associated with the preceding SOC report and reviewed for:

• legal entity;
• period addressed;
• material control changes;
• significant incidents;
• system changes;
• organizational changes.

Do not establish a universal acceptable gap.

The appropriate response depends on the processor’s risk, the length and nature of the gap, report timing, control changes, and the requirements of the enterprise’s auditors or control framework.

When the New SOC Report Is Delayed

A structured response can include:

1. Request the current bridge letter.
2. Confirm whether material control changes occurred.
3. Ask whether significant incidents affected the covered service.
4. Confirm expected timing for the next report.
5. Determine whether additional evidence is needed.
6. Document temporary risk acceptance when necessary.
7. Review the new report when it becomes available.

Pro Tip: Record the SOC examination end date as a separate vendor-management field. The date the PDF was received does not tell reviewers how current the tested control period actually is.

Contract Exhibits That Belong in the Processor Risk File

Independent reports show how controls were assessed.

The contract determines what the processor has promised to the enterprise.

For that reason, contract exhibits should be reviewed as part of the processor vendor risk assessment, not treated as a purely legal workstream.

Useful third-party-risk principles can also be found in the Federal Reserve, FDIC, and OCC interagency guidance on third-party relationships. The guidance emphasizes risk-based due diligence, contractual controls, ongoing monitoring, and termination planning.

Contract Exhibit Checklist

Clause	What to Review	Why It Matters
SLA	Scope, formula, exclusions, maintenance and remedies	Defines service accountability
Incident notice	Trigger, timing and update obligations	Supports enterprise response
Security definitions	Incident, breach, suspected compromise, outage	Reduces ambiguity
Security exhibit	Security obligations and evidence	Establishes contractual baseline
DPA/privacy	Data roles, transfers, retention, subprocessors	Governs personal-data processing
Subprocessor terms	Notification and change process	Addresses fourth-party changes
BCP/DR	Continuity obligations and testing	Supports resilience
Audit rights	Reports, evidence and exceptional audits	Maintains oversight
Regulatory cooperation	Assistance with inquiries and exams	Supports regulated operations
Data export	Transaction and reporting data availability	Supports transition
Token migration	Responsibilities where technically possible	Reduces recurring-payment lock-in
Data deletion	Timing, retention exceptions, confirmation	Governs post-termination data
Transition assistance	Migration and operational support	Reduces exit disruption

Uptime SLA

Availability terms should be evaluated from the formula inward.

Review:

• which service is covered;
• how availability is calculated;
• the measurement period;
• scheduled-maintenance exclusions;
• external-dependency exclusions;
• regional treatment;
• how an outage is measured;
• whether the enterprise must file a claim;
• available service credits or remedies.

Do not accept a headline availability percentage without understanding its denominator and exclusions.

Two vendors can advertise the same availability target while providing materially different contractual protection.

Incident and Breach Notification

Notification provisions should identify both the event and the clock.

Terms such as:

• “security incident”;
• “suspected compromise”;
• “confirmed breach”;
• “service outage”

should not automatically be treated as interchangeable.

A processor could experience an operational outage without a data breach. It could also detect suspicious activity before confirming whether data was compromised.

Contracts should define when each obligation begins.

Notification timing also needs context.

“Promptly,” “without undue delay,” and a fixed number of hours or days are different contractual approaches.

There is no single period that is appropriate for every enterprise.

The processor’s obligation should support the enterprise’s legal, regulatory, contractual, customer, and internal incident-response requirements.

Audit Rights and Regulatory Cooperation

Processor contracts frequently address assurance through several layers.

Routine review may rely on:

• SOC reports;
• PCI evidence;
• security documentation;
• questionnaires;
• remediation information.

Additional rights can apply when a significant incident, material control problem, or regulator request creates a need for more information.

Unlimited onsite auditing is not necessarily practical for large shared-service environments.

The objective is to secure sufficient rights to obtain evidence and satisfy legitimate audit or regulatory obligations without building a clause that is operationally unrealistic.

Data Return and Exit Rights

A processor exit involves far more than terminating the MSA.

The enterprise should understand whether it can retrieve:

• transaction history;
• settlement reports;
• dispute records;
• reconciliation files;
• configuration data;
• reporting history;
• recurring billing information;
• permitted payment credentials or tokens.

Exit requirements should be considered during procurement, while negotiating leverage still exists.

Token Portability

Token portability deserves its own assessment.

Token architecture can vary substantially.

A credential may be represented by:

• a processor-vault token;
• a gateway token;
• a network token;
• another proprietary identifier.

Those tokens are not automatically portable.

Migration can depend on:

• who controls the vault;
• token design;
• processor cooperation;
• payment-network requirements;
• PCI responsibilities;
• incoming provider capability;
• contractual restrictions.

Understanding payment tokenization in enterprise environments before contracting can help teams identify where future migration dependencies may arise.

Do not assume the solution is simply obtaining raw card numbers from the outgoing processor.

A secure migration should minimize unnecessary exposure of account data and follow applicable PCI and network requirements.

Data Deletion

Termination provisions should also state what happens after data export.

Questions include:

• Which information must be deleted?
• When does deletion occur?
• Which information must remain for legal or regulatory reasons?
• How long can retained information remain accessible?
• Can the processor confirm deletion?
• What happens to backups?
• What responsibilities continue after termination?

Retention exceptions should be stated clearly rather than hidden inside generic language permitting indefinite preservation.

Termination Assistance

For a critical processor, transition may require cooperation.

Potential contractual topics include:

• migration planning;
• technical support;
• export assistance;
• credential or token migration coordination;
• reporting continuity;
• parallel operations where agreed;
• transition contacts;
• continuation of essential services during the agreed transition.

The contract does not need to prescribe every future migration step.

It should provide enough structure to prevent the outgoing processor from becoming an avoidable transition bottleneck.

How to Build a Processor Vendor Risk Assessment

The processor vendor risk assessment should combine assurance evidence, operational dependency, contract terms, and the enterprise’s own controls.

At minimum, review these risk domains:

• financial;
• settlement;
• security;
• privacy;
• compliance;
• operational resilience;
• technology;
• subprocessor;
• concentration;
• financial viability;
• exit.

Risk Tiering

Organizations commonly tier vendors based on business impact.

A processor might be classified as critical/high, moderate, or lower risk depending on factors such as:

• payment volume;
• customer impact;
• settlement dependency;
• sensitive-data access;
• system integration depth;
• geographic reach;
• substitutability;
• recovery difficulty.

Do not apply a universal scoring threshold.

A processor that is critical to an ecommerce company may be less critical to an enterprise where it handles only a small secondary channel.

Inherent vs Residual Risk

Inherent risk is the exposure created by the processor relationship before considering mitigating controls.

Residual risk is the exposure that remains after considering:

• processor controls;
• enterprise controls;
• insurance;
• contractual protections;
• architectural mitigations;
• remediation.

This distinction prevents a well-controlled high-impact relationship from being incorrectly classified as inherently low risk.

Mapping Findings to Remediation

A consistent remediation workflow improves both vendor management and auditability.

Use:

Finding → Business Relevance → Severity → Vendor Response → Internal Compensating Control → Due Date → Residual Risk Decision

Suppose a SOC report contains an exception.

The enterprise should first decide whether the affected system supports the services being consumed.

If it does, ask:

• how long the issue existed;
• how widespread it was;
• whether compensating controls operated;
• whether the vendor remediated it;
• whether similar deviations occurred previously;
• whether additional enterprise safeguards are needed.

A finding should be accepted, mitigated, escalated, or remediated based on its business significance rather than its mere presence.

When to Escalate

Escalation may be warranted when evidence indicates issues such as:

• an opinion qualification material to the service;
• a material PCI scope gap;
• serious unresolved security deviations;
• missing resilience evidence for a critical service;
• unacceptable incident-notification provisions;
• significant financial deterioration;
• unclear ownership of a critical platform;
• material subprocessor opacity;
• inability to recover important data during exit.

These are escalation indicators, not automatic rejection criteria.

The enterprise should document why the matter changes residual risk and who approved the decision.

Annual Refresh Cadence and Event-Driven Review

A structured annual review is useful, but the artifacts themselves do not all operate on identical calendars.

SOC reports have defined examination periods.

PCI validation follows the applicable validation cycle.

Insurance follows policy periods.

Financial statements follow the vendor’s reporting calendar.

Subprocessor inventories can change between scheduled reviews.

The correct control is therefore an annual assessment supported by artifact-specific tracking and event-driven reassessment.

Annual Refresh Calendar

Artifact	Normal Review	Event Trigger
SOC 1 Type II, if applicable	Current report during annual assessment	Material financial-processing change
SOC 2 Type II, if applicable	Current report during annual assessment	Material system/control change
PCI AOC	Current applicable evidence	PCI scope or service change
Insurance	Current policy-period evidence	Coverage or entity change
BCP/DR	Periodic/annual review	Significant outage or resilience change
DR test evidence	Latest available relevant evidence	Recovery failure
Financial condition	Risk-based review	Restructuring, distress, acquisition
Subprocessor list	Current list	Material subprocessor addition/replacement
Privacy/DPA	Contract and change review	New geography/data processing
SLA	Renewal/change review	New platform or service
Exit plan	Periodic review for critical vendor	Architecture or portability change
Bridge letter	When needed for assurance gap	New SOC report becomes available

Enterprise Vendor Management Payments Ownership

A mature enterprise vendor management payments workflow assigns responsibility by discipline.

Function	Primary Responsibility
Procurement	Evidence collection, commercial terms, renewal workflow
Payments	Service inventory and payment architecture
Finance/Controllership	Financial-process impact
Internal Audit/SOX	Relevant SOC 1 assessment and control reliance
Security/GRC	SOC 2, technical assurance, security exceptions
PCI	PCI AOC validation and responsibility mapping
Privacy	Personal-data processing and subprocessors
Legal	Contract, incident, audit and exit provisions
Operational Resilience	BCP/DR and recovery dependencies
Vendor Risk	Consolidated risk decision and follow-up

No single team can review every aspect effectively.

Payments understands which products are actually deployed. Finance understands settlement and reconciliation. Security understands technical exposure. Privacy understands data-processing implications. Legal controls contractual remedies.

The vendor-risk function should integrate these findings into one decision record.

Initial Due Diligence vs Annual Refresh vs Event Review

Initial Due Diligence

Initial onboarding establishes the baseline.

It should include:

• full service inventory;
• legal entity mapping;
• inherent risk assessment;
• SOC review;
• PCI validation;
• insurance;
• BCP/DR;
• financial assessment;
• subprocessors;
• privacy;
• SLA;
• incident terms;
• audit rights;
• data return;
• exit planning.

Annual Refresh

Annual reassessment should concentrate on changed or renewed evidence.

That includes:

• new SOC reports;
• current PCI evidence;
• current insurance;
• latest resilience testing information;
• financial updates;
• subprocessor changes;
• outstanding remediation;
• contract amendments;
• new processor services.

Event-Driven Review

Do not wait for the annual calendar when the vendor relationship changes materially.

Potential triggers include:

• major security incident;
• significant outage;
• acquisition;
• restructuring;
• new processor product;
• data-center or cloud migration;
• material subprocessor change;
• regulatory action;
• significant control change.

The One-Email Annual Document Request

A structured request reduces delays and back-and-forth.

Use exact artifact names, distinguish required documents from conditional requests, specify current versions, identify the reporting period where appropriate, and provide a secure upload destination.

Annual payment processor document request

Please provide the current versions of the following materials for our annual third-party review:

• SOC 1 Type II report, if applicable to the services provided to us;
• SOC 2 Type II report, if applicable;
• current PCI DSS service-provider Attestation of Compliance covering the services we use;
• current bridge letter if needed for the period after the latest SOC examination;
• current applicable insurance certificates;
• latest BCP/DR summary;
• date and high-level outcome of the most recent relevant BCP/DR test;
• current subprocessor/subcontractor list applicable to our services;
• latest financial statements, public filing reference, or other agreed financial-condition evidence;
• notice of material security, compliance, organizational, platform, or control changes since the previous review; and
• confirmation of changes to applicable security, privacy, SLA, incident, subprocessor, continuity, data-return, or termination exhibits.

Please upload confidential materials to [secure location] by [due date].

If an item is not applicable, please identify the item and briefly explain why.

How to Make the Vendor Request Easy to Fulfill

Avoid vague requests such as “Please send all compliance documents.”

Instead:

1. Use exact document names.
2. Request current versions.
3. Identify which services are being reviewed.
4. Separate required documents from “if applicable” items.
5. State whether a bridge letter is actually required.
6. Provide a secure upload location.
7. Name a due date.
8. Identify a contact for scope questions.

A processor with a mature assurance program may already distribute SOC and PCI reports through a trust portal or NDA-controlled repository.

Use those channels when available rather than asking representatives to send confidential documents through ordinary email.

Confidentiality and Distribution Controls

SOC and detailed security materials may contain sensitive information.

Access should generally be restricted to personnel with a legitimate review need.

Appropriate practices include:

• controlled document repositories;
• role-based access;
• NDA compliance;
• limited forwarding;
• version control;
• retention of review summaries separately from broad collaboration folders.

The objective is to preserve evidence without turning confidential assurance reports into uncontrolled internal files.

Reading the Executive Summary Is Not Enough

A polished executive summary can explain the processor’s assurance program, but it cannot replace the underlying review.

For a SOC report, reviewers still need to inspect:

• scope;
• period;
• opinion;
• exceptions;
• CUECs;
• subservice organizations.

For a PCI AOC, reviewers still need to inspect:

• entity;
• version;
• assessment information;
• service-provider context;
• service scope.

For BCP/DR evidence, reviewers still need to understand what critical services were considered and whether meaningful testing occurred.

A vendor file should record the review conclusion, not just the receipt date.

Common Enterprise Processor Due Diligence Mistakes

Mistake	Why It Creates Risk	Better Approach
Collecting SOC 2 but ignoring financially relevant SOC 1 needs	Financial control dependency remains unassessed	Determine whether processor activities affect ICFR
Reading only the SOC cover page	Critical scope information is missed	Review opinion, scope, period, exceptions and CUECs
Ignoring CUECs	Customer obligations may not operate	Assign each relevant control internally
Accepting outdated PCI evidence	Current scope may not be demonstrated	Obtain current applicable validation
Failing to map AOC scope to the service	Wrong platform may have been assessed	Match contracted products to PCI scope
Ignoring entity differences	Evidence may belong to another affiliate	Maintain entity mapping
Treating a bridge letter like a SOC audit	Management representation is over-relied upon	Use it only to address the reporting gap
Ignoring subprocessors	Critical fourth-party exposure is hidden	Review material dependencies
Accepting an SLA headline	Exclusions can change effective protection	Review formula and exclusions
Omitting exit provisions	Migration becomes difficult	Negotiate data and transition rights upfront
Assuming tokens are portable	Recurring credentials can create lock-in	Assess architecture and contract rights
Refreshing only on an anniversary	Material changes may remain unnoticed	Use event-driven triggers

Practical Payment Processor Due Diligence Workflow

A repeatable operational workflow can be structured as follows:

1. Inventory processor services in scope.
2. Identify data and transaction flows.
3. Confirm the contracting legal entity.
4. Classify vendor criticality.
5. Request the core evidence package.
6. Review SOC 1 scope and opinion where relevant.
7. Review SOC 2 scope and opinion where relevant.
8. Log exceptions and deviations.
9. Map applicable CUECs to internal controls.
10. Review subservice organizations.
11. Validate the PCI AOC.
12. Confirm PCI entity and service scope.
13. Review insurance evidence.
14. Review BCP.
15. Review disaster recovery evidence.
16. Review latest relevant resilience testing.
17. Review financial condition.
18. Review subprocessors.
19. Review privacy and data residency.
20. Review SLA calculations.
21. Review incident and breach-notification terms.
22. Review audit and regulatory cooperation rights.
23. Review data-return provisions.
24. Review token portability.
25. Review deletion requirements.
26. Review termination support.
27. Document gaps.
28. Assign remediation owners and dates.
29. Evaluate residual risk.
30. Obtain appropriate approval.
31. Calendar the annual refresh.
32. Create event-driven review triggers.

Enterprise Payment Processor Due Diligence Checklist

• Inventory every processor service being used.
• Confirm the contracting legal entity.
• Map relevant processor affiliates.
• Obtain a current SOC 1 Type II report when financial-reporting relevance warrants it.
• Obtain a current SOC 2 Type II report when relevant.
• Confirm SOC type and reporting period.
• Review the service auditor’s opinion.
• Review relevant exceptions.
• Evaluate vendor remediation.
• Identify applicable CUECs.
• Assign CUECs to internal owners.
• Retain evidence supporting customer controls.
• Review subservice organizations.
• Determine inclusive or carve-out treatment where applicable.
• Obtain current applicable PCI DSS validation evidence.
• Confirm the AOC covers the services actually used.
• Confirm assessed legal entity.
• Check the PCI DSS version.
• Review assessor information where applicable.
• Determine whether additional PCI evidence is necessary.
• Review current insurance certificates.
• Confirm insured legal entity.
• Review BCP documentation.
• Review DR documentation.
• Obtain the latest relevant test date.
• Review high-level testing outcomes.
• Assess material unresolved findings.
• Compare RTO/RPO information with business requirements where provided.
• Review financial condition.
• Obtain the relevant subprocessor inventory.
• Review material fourth-party dependencies.
• Determine applicable data-processing locations.
• Review privacy and data-residency requirements.
• Review incident definitions.
• Review incident-notification timing.
• Review SLA calculations and exclusions.
• Review audit rights.
• Review regulatory cooperation.
• Review transaction data export.
• Review settlement and dispute history access.
• Assess token portability.
• Review deletion requirements.
• Review transition assistance.
• Request a bridge letter when the assurance-period gap requires it.
• Record findings.
• Record remediation.
• Assign internal owners.
• Approve residual risk.
• Record the review date.
• Record the next review date.
• Trigger reassessment after material changes.

Audit-Ready Vendor File Index

A well-organized processor compliance file can use this structure:

1. Vendor profile
2. Vendor criticality assessment
3. Service inventory
4. Legal entity mapping
5. MSA and amendments
6. SLA
7. Security exhibit
8. DPA/privacy exhibit
9. SOC 1 report and review
10. SOC 2 report and review
11. PCI AOC
12. Additional PCI evidence where applicable
13. Insurance evidence
14. BCP summary
15. DR summary and testing evidence
16. Financial review
17. Subprocessor list
18. CUEC mapping
19. Findings and remediation
20. Bridge letters
21. Annual approval
22. Exit and migration plan

The objective is to make evidence easy to reconstruct later.

For every artifact, record:

• document date;
• period covered;
• date received;
• reviewer;
• review conclusion;
• findings;
• remediation;
• approval;
• next review.

Do not assume a universal retention period. Align retention with the enterprise’s audit, regulatory, legal, record-management, and contractual requirements.

Frequently Asked Questions

Conclusion

A complete processor vendor file requires more than collecting a SOC 2 report.

SOC 1 and SOC 2 address different assurance questions, and the relevance of each depends on the services the processor provides. Report scope, legal entity, examination period, opinion, exceptions, CUECs, and subservice organizations can be as important as the report title itself.

PCI evidence requires the same scope discipline. The AOC should correspond to the entity, environment, and payment services the enterprise actually uses rather than merely demonstrating that some part of the corporate group has completed PCI validation.

Insurance, BCP/DR evidence, financial review, subprocessor analysis, privacy requirements, and data-residency evaluation fill gaps that SOC and PCI evidence cannot address. Bridge letters can help address reporting-period gaps but do not replace independent examination.

Finally, contractual controls make the assurance package operational. SLA definitions, incident notification, audit rights, data return, deletion, subprocessor provisions, token migration, and termination assistance determine what happens when a service fails or the relationship ends.

Combined with assigned ownership, remediation tracking, annual reassessment, and event-driven review, these payment processor due diligence documents become an ongoing enterprise control rather than a one-time procurement file.