CIO Brief: Third-Party Cloud Risk — Writing Security Into Vendor Contracts

Retrospective: this article looks back at events from July 2017, written in 2026 with the benefit of hindsight.

The short version: In 2017, a Verizon vendor exposed customer records — including account PINs used for phone support — in a cloud storage folder anyone could access. The vendor made the mistake; Verizon's customers carried the risk.

Why security belongs in vendor contracts

When a vendor processes your data, your contract is the main lever you have over how it is protected. Many contracts focus on price, service levels and liability caps, with security reduced to a generic clause. That is rarely enough.

What to require

• Specific controls: encryption, private-by-default cloud storage, multi-factor authentication for administrators, and logging.
• Breach notification within a defined number of hours, not "without undue delay."
• Audit rights or evidence: a current SOC 2 Type II report or ISO 27001 certificate, plus the right to ask questions.
• Data minimization and deletion: only the data needed, deleted when no longer needed or when the contract ends.
• Subcontractor controls: the same requirements flow down to their vendors.

Questions to ask your team

• Which of our vendors would cause the most damage if they exposed our data?
• What security terms do those contracts contain today?
• When did we last review their security evidence?

What good looks like

A standard security schedule attached to every contract involving sensitive data, with stricter terms for the highest-risk vendors and an annual review.

The decision

Ask legal and IT to draft a standard security schedule and apply it to every new or renewing vendor contract. It costs little and changes vendor behavior more than any audit.