In John Wick: Chapter 4 (2023), the High Table does not operate on goodwill. Every obligation is written, formalized, and binding. The marker system works because the terms are explicit and non-negotiable. Nobody at the High Table closes a deal with a handshake and a smile, because a vague agreement in that world gets you killed. Your vendor contracts work the same way: if security requirements are not in writing, they do not exist.
What Is Ensure Service Provider Contracts Include Security Requirements?
This safeguard is about closing the gap between what you assume your vendors are doing and what they are actually required to do. It requires that every service provider contract contains explicit security obligations, not implied ones.
The CIS definition puts it plainly: "Ensure that all service provider contracts include security requirements. Example requirements may include minimum security program requirements, security incident notification and response procedures, data encryption requirements, and data disposal commitments."
In other words, if your vendor processes your data, stores it, or touches your systems, the contract should spell out exactly how they are expected to protect it.
Why It Matters
Vendors are a significant source of breach exposure. The 2020 SolarWinds attack, the 2023 MOVEit exploitation, the ongoing parade of third-party incidents: these are not edge cases. They are the pattern.
When a breach happens through a vendor and your contract does not include security requirements, you have no recourse, no remediation timeline, and sometimes no notification obligation. You find out when the news breaks, not when it matters.
Security requirements in contracts do not prevent every incident. They do establish expectations, create accountability, and give you something to act on when things go sideways.
Key Details or How It Works
- Minimum security program requirements define the baseline: things like MFA, patch management cadence, and access controls the vendor must maintain.
- Incident notification clauses establish how quickly a vendor must tell you about a breach or suspected breach. Seventy-two hours is a common baseline; some frameworks require less.
- Data encryption requirements specify how your data must be protected at rest and in transit, and which encryption standards are acceptable.
- Data disposal commitments define what happens to your data when the contract ends or when it is no longer needed. "We will delete it" is not sufficient. You want specifics.
- Right-to-audit clauses give you the ability to verify compliance, either directly or through a third-party assessment.
- Liability and indemnification language matters too. It does not belong in a security review alone, but security teams should ensure legal understands what is at stake when these clauses are weak or missing.
How to Implement Ensure Service Provider Contracts Include Security Requirements
- Build a standard security addendum. Work with legal and security to create a reusable contract exhibit that covers the core requirements: incident notification, encryption standards, access controls, data disposal, and audit rights. This becomes your baseline for every new vendor engagement.
- Tier your vendors by risk. Not every vendor needs the same level of scrutiny. Vendors with access to sensitive data, critical systems, or customer information warrant stricter requirements. Vendors selling you office supplies do not. Segment accordingly and apply the right addendum to the right tier.
- Review existing contracts. New requirements are straightforward. Legacy contracts are where organizations get surprised. Pull your current active agreements and flag which ones are missing security language. Prioritize by vendor risk tier and begin renegotiating at renewal.
- Define your non-negotiables. Some requirements should be deal-breakers: no MFA, no deal. No incident notification clause, no deal. Know your hard lines before you enter negotiation so legal is not making security decisions on the fly.
- Assign ownership for ongoing compliance. Contracts with security requirements are only useful if someone is verifying them. Assign a vendor owner who reviews compliance annually or at renewal and escalates gaps to security leadership.
- Integrate this into your procurement process. The best time to enforce security requirements is before a vendor is selected, not after the contract is signed. Build security review into procurement so requirements are addressed at the start of the relationship.
Final Thoughts
John Wick's world runs on consequence. The marker works because everyone knows exactly what it means and what happens if it is ignored. There is no ambiguity, no room for interpretation, and no "we assumed you meant." Your vendor relationships need the same clarity. A contract without security requirements is an agreement that lets your vendor set their own standards. That is not a contract. That is a hope.
Resources
Here is a link to the Policy Templates provided free of charge from the fine folks at the Center for Internet Security.
Looking for even more detail? Here you go. If this still does not satisfy your curiosity, DM me.
Official CIS Text
CIS Control 15: Service Provider Management Develop a process to evaluate service providers who hold sensitive data, or are responsible for an enterprise's critical IT platforms or processes, to ensure these providers are protecting those platforms and data appropriately.
CIS Safeguard 15.4: Ensure Service Provider Contracts Include Security Requirements Ensure that all service provider contracts include security requirements. Example requirements may include minimum security program requirements, security incident notification and response procedures, data encryption requirements, and data disposal commitments.
Shameless Marketing Information
At Gotham Technology Group, we help organizations build vendor risk programs that actually hold up, including contract review, security addendum development, and third-party risk assessments. If your vendor contracts could use a security checkup, let us know.