When Heights Finance discovered unauthorized access to its cloud-based platform on May 7, the breach had already exposed Social Security numbers, banking details, and personal data of 734,828 people. The company's statement reveals a pattern you've probably seen before: "This activity was limited to the cloud-based platform only." That qualifier tells the whole story. The breach didn't happen in their loan management systems. It happened in the vendor environment they thought was secure.
Why These Mistakes Keep Happening
Third-party cloud breaches follow a predictable path. Your team negotiates a contract, receives a SOC 2 Type II report, checks a box on the vendor risk assessment, and moves on. The vendor's security posture becomes a static artifact instead of a living control point. Meanwhile, your data flows into environments you don't monitor, protected by controls you don't verify, under an incident response plan you've never tested.
The gap isn't ignorance. You know third-party risk matters. The gap is execution: turning vendor security from a procurement checkbox into an operational discipline.
Mistake 1: Treating SOC 2 Reports as Security Proof
Why it happens: SOC 2 Type II reports arrive as polished PDF documents with clean opinions. They look definitive. Your procurement team accepts them as evidence of security, and the vendor moves into production.
The consequence: SOC 2 reports describe controls at a point in time, scoped to specific trust services criteria. They don't tell you whether the vendor patches within 30 days, how they segment customer data, or what happens when an employee leaves. The Heights Finance breach occurred in a cloud platform the company described as "hosted by a third party" but the public record doesn't show whether that vendor held current certifications or what controls were actually tested.
The fix: Read Section IV of every SOC 2 report (Complementary User Entity Controls). This section lists the controls you must implement for the vendor's controls to work. If the vendor's access management control assumes you'll review user permissions quarterly, and you don't, the control fails. Map these complementary controls to your own control framework and assign owners. Then verify the report's test period. A report dated January 2024 with a test period ending September 2023 tells you nothing about current security posture.
Mistake 2: Skipping Data Flow Mapping for Cloud Vendors
Why it happens: Your team knows the vendor receives customer data, but the contract doesn't specify data types, storage locations, encryption requirements, or retention periods. The vendor's generic DPA (Data Processing Agreement) says they'll protect data "in accordance with industry standards," which means nothing.
The consequence: When a breach occurs, you can't answer basic questions: What data was exposed? Where was it stored? Who had access? Should you notify regulators under the General Data Protection Regulation's 72-Hour Notification Requirement? The Heights Finance breach included "any personal information shared during customer service interactions," suggesting the scope expanded beyond what the company initially mapped.
The fix: Document data flows before the vendor goes live. For each integration, specify: data classification (public, internal, confidential, restricted), data elements transmitted, encryption in transit and at rest, geographic storage locations, access controls, and retention periods. Attach this as Schedule A to your vendor agreement. When ISO/IEC 27001 Annex A Control 5.23 requires you to establish requirements for cloud service use, this mapping becomes your evidence.
Mistake 3: Accepting Vendor Access Controls Without Verification
Why it happens: The vendor's security questionnaire says they enforce Role-Based Access Control and the Principle of Least Privilege. Your team assumes this means customer data is restricted to authorized personnel. You never ask for proof.
The consequence: Vendor employees often have broader access than necessary because the vendor optimized for operational convenience, not data segregation. When an attacker compromises one account, they move laterally across customer environments. The Heights Finance statement notes the breach "did not affect any of our loan management systems," which suggests the cloud platform lacked network segmentation that would prevent lateral movement.
The fix: Require evidence of access controls during onboarding and annually thereafter. Ask for: a list of roles with access to your data, the business justification for each role, screenshots of permission configurations, and logs showing access review completion dates. For high-risk vendors (those processing financial data, health information, or credentials), require Just-in-Time Access for privileged operations and quarterly access recertification. Build these requirements into your vendor contract as audit rights under NIST Cybersecurity Framework (CSF) 2.0 function GV.SC-05.
Mistake 4: Ignoring Incident Response Integration
Why it happens: Your incident response plan covers internal systems. The vendor has their own incident response plan. Nobody tests how these plans work together or who makes the call to notify regulators.
The consequence: When the vendor detects a breach, days pass while they investigate scope, notify your team, and debate disclosure obligations. You can't meet regulatory notification deadlines because you're waiting for information the vendor controls. Heights Finance discovered the breach on May 7 but didn't notify Texas regulators until months later, and the public notification came even later.
The fix: Add vendor breach scenarios to your tabletop exercises. Simulate: vendor notifies you of unauthorized access at 3pm Friday; vendor discovers data exfiltration but can't confirm scope; vendor's forensics team needs 72 hours to complete analysis. Who declares the incident? Who contacts your Computer Security Incident Response Team? Who drafts regulatory notifications? Document these answers in a vendor incident response playbook. Require contractual notification within 24 hours of vendor detection (not confirmation) and access to vendor forensics reports. For vendors processing GDPR-regulated data, specify that the 72-hour notification clock starts when the vendor detects the breach, not when they finish investigating.
Mistake 5: Conducting Annual Vendor Reviews Instead of Continuous Monitoring
Why it happens: Your vendor risk program schedules annual reviews because that's what the policy says. Between reviews, vendor security is invisible. You don't know if they've been breached, acquired, or changed their subprocessors.
The consequence: Vendor risk changes faster than annual reviews can detect. A vendor passes your 2024 assessment, then suffers a breach in June, gets acquired in August, and migrates to new infrastructure in October. Your next review won't happen until 2025. The Heights Finance breach shows how quickly cloud environments become targets when attackers identify vulnerable platforms.
The fix: Implement continuous vendor monitoring using security ratings services, breach notification feeds, and certificate monitoring. Set up alerts for: vendor data breaches reported to state attorneys general, changes in vendor security ratings, SSL/TLS certificate expirations, and changes in vendor ownership or subprocessors. For critical vendors (top 20% by data sensitivity or business impact), require quarterly attestations confirming no material changes in security posture, no unreported security incidents, and no changes to subprocessors. Treat vendor security as an operational control that requires ongoing validation, not an annual compliance checkbox.
Prevention Checklist
Before your next cloud vendor goes into production:
- Review SOC 2 Section IV and assign owners to complementary user entity controls
- Map data flows specifying classification, encryption, storage locations, and retention
- Verify vendor access controls with role lists, permission screenshots, and review logs
- Add vendor breach scenarios to your next tabletop exercise
- Document vendor incident notification procedures with 24-hour detection reporting
- Configure continuous monitoring alerts for vendor breaches and security rating changes
- Require contractual audit rights for access logs and security configurations
- Schedule quarterly attestations for critical vendors confirming no security changes
- Test vendor data deletion procedures before contract signature
- Verify vendor backup encryption and geographic storage locations
The 734,828 people affected by the Heights Finance breach didn't choose the company's cloud vendor. You make those choices for your customers every time you sign a vendor contract. Make them count.
