When a third party hosts your customer data in the cloud, you don't outsource accountability. Heights Finance learned this in May when unauthorized access to a vendor's cloud platform exposed Social Security numbers, banking details, and government IDs for approximately 734,828 customers. The breach never touched their internal loan management systems, yet the damage was complete.
This checklist helps you verify that your third-party cloud relationships won't become your next disclosure to regulators.
Checklist Overview
This checklist is an operational readiness assessment for any cloud platform that stores, processes, or transmits customer financial data through a third-party vendor. It covers contractual controls, technical validation, incident response coordination, and regulatory compliance specific to vendor-hosted environments. If you rely on a SaaS platform, cloud storage provider, or managed service for any part of your customer data lifecycle, this applies.
Prerequisites
Before starting this checklist, ensure you have:
- A current inventory of all third parties with access to cardholder data, Social Security numbers, or banking information.
- Executed contracts with data processing addendums for each vendor.
- Access credentials to review vendor security configurations (or documented evidence they've provided this to your security team).
- Authority to request penetration test results, SOC 2 reports, or equivalent attestations.
If you're missing any of these, your third-party risk program has a foundational gap that this checklist will expose but cannot fix.
Checklist Items
1. Vendor maintains current PCI DSS validation appropriate to their service scope
Request the Attestation of Compliance (AOC) and confirm the validation date is within the last 12 months. If they're a service provider storing, processing, or transmitting cardholder data, they need either a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire with quarterly network scans from an Approved Scanning Vendor.
2. Data segmentation is contractually defined and technically verified
Your contract must specify which data elements the vendor can access, where that data resides geographically, and whether it's logically or physically isolated from other tenants. Then verify it. Request architecture diagrams showing network segmentation and ask how they prevent lateral movement if one tenant environment is compromised.
3. Encryption at rest uses FIPS 140-3 validated modules with customer-managed keys
The vendor should encrypt sensitive data at rest using modules validated under FIPS 140-3. More importantly, you should control the Key Encryption Key (KEK), not them. If they manage the Key Encryption Key (KEK), they can decrypt your data without your knowledge or consent.
4. Access logs are forwarded to your SIEM within 15 minutes
Real-time log aggregation is the difference between detecting a breach in hours versus months. The vendor should stream authentication events, data access logs, and administrative actions to your security information and event management system.
5. Vendor performs annual penetration testing with results shared within 30 days
An annual penetration test by a qualified third party should cover the specific services you use. The vendor should share the executive summary and any findings rated high or critical, along with their remediation timeline.
6. Incident response plan includes notification within 24 hours of discovery
Your contract must require the vendor to notify you within 24 hours of discovering unauthorized access to your data. This isn't negotiable and it's often missed. Many standard SaaS agreements promise notification "without unreasonable delay," which means nothing during a regulatory investigation.
7. Role-Based Access Control limits vendor staff access to defined job functions
The vendor should enforce least privilege through Role-Based Access Control. Ask how many employees can access production customer data, what approvals they need, and whether access is logged and reviewed.
8. Multi-Factor Authentication is required for all vendor administrative access
Any account that can modify configurations, access encryption keys, or view customer data must use Multi-Factor Authentication. This should be enforced at the identity provider level, not left to individual user preference.
9. Data retention and destruction procedures match your regulatory obligations
If you're required to delete customer data after seven years, your vendor needs to delete it too. Confirm they can execute deletion requests within your required timeframe and provide certification of destruction.
10. Business continuity plan includes your data with tested recovery time objectives
The vendor should back up your data separately from production and test restoration quarterly. Ask for their Recovery Time Objective and Recovery Point Objective, then confirm these meet your regulatory and operational requirements.
Common Mistakes
Treating SOC 2 Type II as sufficient validation. A SOC 2 report tells you the vendor has controls. It doesn't tell you those controls protect your specific data or meet your regulatory requirements. You still need to map their controls to PCI DSS, GLBA, or whatever framework governs your operations.
Accepting "we're compliant" without evidence. Compliance is not a state, it's a point-in-time validation. If a vendor claims PCI DSS compliance but won't share their AOC, they're either lying or their assessor told them not to share it (which means the assessment has caveats you need to know about).
Skipping segmentation testing after the initial implementation. Networks change. A vendor might have properly segmented your data in 2023, but a new feature rollout in 2024 could have introduced a shared processing layer. Request annual segmentation testing or perform it yourself if your contract allows.
Next Steps
If you checked fewer than 8 items, you have material third-party risk that needs executive attention. Start with items 1, 3, and 6, these address the most common breach scenarios and regulatory violations.
If you checked all 10 items, schedule quarterly reviews to confirm nothing has degraded. Vendor acquisitions, platform migrations, and staff turnover can invalidate controls you verified six months ago.
For any vendor who cannot meet these requirements, document the gap, the compensating control you've implemented, and the risk acceptance from your Chief Risk Officer. When regulators ask why you chose that vendor, "they were cheap" is not an acceptable answer. "We documented the risk and implemented monitoring" is.
