Safeguard 15.4 Security requirements in provider contracts

What Safeguard 15.4 asks for in provider contracts

If your provider contracts were signed before security terms became standard, Safeguard 15.4 is asking you to close that gap. The safeguard requires that service provider contracts include security requirements consistent with the enterprise's service provider management policy, and that those contracts be reviewed annually. A contract that says nothing about security leaves you with little recourse when a provider suffers a breach, loses data, or stops meeting your expectations. Your compliance lead should start by pulling the contracts for providers classified as holding sensitive data or running critical processes and checking what each one actually obligates the provider to do.

Writing these requirements is harder than it sounds for two reasons. First, contracts are negotiated by procurement and legal teams who often work from their own templates, so security terms have to be added to those templates deliberately. Second, the requirements must be consistent with a service provider management policy, which means the policy (Safeguard 15.2) and an inventory of providers (Safeguard 15.1) must exist first. Without them, there is no agreed standard to write into the contract, and the assessment specification treats a missing security requirement in the policy as a failing score. Confirm with your own assessor which policy artifacts they will ask to see before drafting contract language.

Safeguard 15.4 is an IG2 safeguard, so it applies to enterprises in Implementation Group 2 and 3 but not to IG1 organizations. For those in scope, the practical work is to define a standard set of clauses covering a minimum security program, incident and breach notification and response, data encryption, and data disposal, then apply them to existing contracts at renewal or through amendment. Schedule the annual contract review as a recurring task with a named owner, and record each review's outcome. The assessment specification scores this safeguard by the share of providers with up-to-date contracts, so a dated review log is the evidence most likely to be requested.

Which contracts and teams 15.4 reaches

Safeguard 15.4 only works on the providers that the earlier Control 15 steps have already identified and sorted. The inventory, the policy and the classification decide which contracts need security clauses, and which teams must agree on the wording and keep it current.

Providers in the 15.1 inventory

Safeguard 15.4 starts with the inventory from 15.1, which lists every known service provider with its enterprise contact. Contracts that are not in that inventory tend to be the ones without security terms, so the first check is whether procurement records, purchase card spend and business unit tools reconcile against it. Ask who signs off when a provider is missing from the list.

Sensitive and critical providers

The classification from 15.3 sets which providers carry the heaviest contract requirements. Providers that hold sensitive data, run critical processes or affect availability should receive the full clause set, while low-impact vendors may need a lighter baseline. Check that each classification tier has a documented clause set in the 15.2 policy so that the tier, not the buyer, determines the wording.

SaaS and hosted platforms

Software as a service and hosting agreements are often click-through or standard vendor paper, which is where security terms are most often missing. Review these for data location, encryption, subprocessor notice, breach notification and data return or deletion at exit. Where the vendor will not change standard terms, record the gap and the compensating control so the exception is visible at the annual review.

Managed services and consultants

Managed service providers and consultants often gain administrative access to systems and hold copies of data during projects. Their statements of work should carry minimum security program requirements, personnel screening where the policy requires it, and notification duties for incidents affecting the enterprise. Confirm that the statement of work, not only the master agreement, carries these terms, since project-level paperwork is often signed outside procurement.

Contract owners across teams

Procurement usually runs the negotiation, legal owns the clause language, security defines the technical requirements, and the business owner accepts residual risk. Assign one accountable owner per contract and record who approved any deviation from the policy clauses. Ask each team to name its reviewer in the policy so the annual contract review has a defined list of people to convene.

Policy before contract language

The 15.2 policy must define the security requirements before contracts can reflect them, because 15.4 measures contracts against the policy. Under the CIS Controls Assessment Specification, a missing security requirement in the policy produces a failing score for 15.4. Note that Safeguard 15.4 is in Implementation Group 2, so IG1 enterprises are not assessed against it, though they may still adopt the clauses voluntarily.

How an assessor tests Safeguard 15.4

This table walks through what the CIS Controls Assessment Specification checks for Safeguard 15.4, from prerequisites and scoring to the evidence an assessor will request. Read it as a checklist of what must exist before an assessment starts and where findings usually arise.

Assessment element	What the assessor checks	Evidence to prepare
Prerequisites	Safeguards 15.1 (provider inventory) and 15.2 (provider management policy) must be in place before 15.4 can be measured	Current provider inventory and the approved, dated service provider management policy
Policy content	The policy sets security requirements for providers; a policy with none scores as a failure	Policy section listing minimum security program, incident notification, encryption and data disposal requirements
Compliance metric	Share of service providers with up-to-date contracts that carry the required security terms	Inventory cross-referenced to executed contract dates and clause coverage per provider
Sample of contracts	Assessor selects providers and reads executed agreements and amendments for the policy requirements	Signed master agreements, data processing addenda, and any amendments or renewals for sampled providers
Annual review records	Evidence that contracts are reviewed at least annually, with outcomes recorded	Dated review minutes or tickets, updated clauses, and sign-off by the named contract owner
Contracts predating the policy	Older agreements may lack required terms; the assessor looks for a documented plan to bring them in line	Gap register listing legacy contracts, target renewal or amendment dates, and owners
Policy with no requirements	A policy that omits security requirements for providers fails 15.4 regardless of contract quality	Policy revision history showing when requirements were added and approved
Reviews not performed	Missing or overdue annual reviews are a common finding, even where contract terms are sound	Review calendar, reminders, and records for each reviewed provider

How to bring provider contracts up to the 15.4 standard

This sequence turns the policy and inventory behind Safeguard 15.4 into contract clauses that are applied to real providers, reviewed on a set calendar and recorded so an assessor can trace each requirement to a signed agreement.

Confirm the 15.1 inventory and 15.2 policy exist
Before drafting any clause, check that the service provider inventory from Safeguard 15.1 lists every known provider with its classification and an enterprise contact, and that the service provider management policy from Safeguard 15.2 is approved and sets security requirements for providers. The assessment specification treats both as prerequisites for measuring 15.4, and a policy with no security requirements scores as a failure. Owner: the GRC or security lead, with procurement. Output: a signed-off policy version and a dated inventory extract that together form the baseline for the rest of the work.
Define the minimum requirements the policy calls for
Turn the policy's security requirements into a short, testable list. CIS gives four example categories for 15.4: minimum security program requirements, security incident and data breach notification and response, data encryption requirements, and data disposal commitments. For each, write what the provider must do, the evidence it must give you and who on your side receives it. Security, legal and privacy staff should agree the list. Output: a requirements register that every later step refers back to, so each clause can be traced to a policy statement.
Map each requirement to standard clauses or addenda
Translate each requirement from the register into contract language, either as a standard clause for the template agreement or as a security addendum for existing contracts. Keep the wording specific enough to test, such as a named notification window agreed in the contract or a stated encryption standard, rather than general promises to protect data. Legal counsel drafts and approves the wording; the security team checks that each clause produces the evidence the register names. Output: a clause library with one entry per requirement, plus a short mapping table showing which clauses satisfy which policy statement.
Prioritize high-sensitivity providers for amendment
Use the classification from Safeguard 15.3 to sort the inventory. Providers that hold sensitive data, run critical platforms or have broad access to your systems go first, followed by lower-risk providers. Confirm for each provider whether the current contract already contains the required clauses, needs an addendum or must wait for renewal. Be clear with procurement about which providers will be asked to sign an addendum now and which will be updated at renewal. Output: an amendment tracker listing each provider, its tier, its current clause gaps, the agreed route (addendum or renewal) and the owner for each action.
Negotiate and execute the amendments
Send the addendum to each prioritized provider and record the response. Where a provider cannot meet a requirement, log the gap, the compensating control you accept and the person who approved that exception under the policy. Do not treat an unsigned addendum as complete. Output: executed amendments or documented exceptions, stored with the contract record and linked to the tracker so an assessor can see the date each clause took effect.
Set the annual contract review calendar
Safeguard 15.4 expects contracts to be reviewed every year, so each provider needs a review date tied to its contract record. Assign an owner for each review, define what the review checks (clauses still present, contacts current, requirements still matching the policy and the provider's classification) and schedule reviews so that high-sensitivity providers are not left to the end of the year. Confirm with the policy owner how reviews interact with the reassessment cycle in Safeguard 15.5. Output: a review calendar with one entry per provider and a documented owner for each review.
Record each review in a review log
After each annual review, write a short entry in the review log: the date, the reviewer, the contract version checked, the clauses confirmed, any gaps found and the decision taken. Keep the log in a versioned location, so every change to the clause library and the tracker has a history of who changed what and when. Confirm that the wiki or document system you use can keep that history. Output: a review log that, together with the clause library and amendment tracker, shows the 15.4 process operating over time, not only at one point.

What the security clauses should cover

Safeguard 15.4 asks that service provider contracts carry security requirements consistent with your service provider management policy, and CIS names four example categories: minimum security program requirements, security incident or data breach notification and response, data encryption requirements, and data disposal commitments. The clauses should translate each category into obligations the provider can be held to. The specific thresholds, such as which notification window applies, which encryption standards are acceptable and how long data may be retained after exit, must come from your own policy and your legal and regulatory obligations, not from this page. Have counsel review the final wording, because the enforceability of these terms depends on the governing law and the rest of the contract.

For the minimum security program clause, the question is what the provider must maintain and how you will see it. Name the security frameworks or attestations the provider must hold, the controls it must operate for the data or systems it touches, and the right to receive evidence such as a SOC 2 report or PCI Attestation of Compliance where those apply. For incident and breach notification, specify who the provider must tell (your named security contact, not a general mailbox), the window in which it must do so, what details it must provide at first notice and updates, and what cooperation it owes during investigation, including access to logs and forensic findings. Ask counsel to confirm how the window interacts with your own reporting duties under any regulation that applies to you. Encryption clauses should state the requirement for data in transit and at rest, including key management responsibilities, so that the provider cannot choose a weaker default than your policy allows.

Data disposal is where many contracts are vague. The clause should say what happens to your data at termination: return in an agreed format, deletion from production, backups and subprocessors, and written certification of disposal within a stated period. Confirm with the provider how long backups persist and whether legal holds can override deletion. Plan the evidence you will need for the annual contract review that Safeguard 15.4 calls for: a current copy of each contract, a list of changes since the last review, and a check that the clauses still match the policy. Records of these reviews also feed the Compliance measure in the CIS assessment specification, which scores the share of providers with up-to-date contracts.

Evidence that shows 15.4 is met

Safeguard 15.4 is tested through the contracts themselves and the way the enterprise keeps them current. The cards below cover the policy, the clause library, the executed agreements, the register, the review records and the change history that connect a written requirement to a signed agreement. Confirm the exact form each artifact must take with your assessor before you build it.

Policy security requirements section

The service provider management policy is the source of the contract requirements, and the assessment specification treats a policy with no security requirements for providers as a failing result. Keep a dedicated section that lists the minimum security program expectations, incident and breach notification, encryption and data disposal commitments, and the annual review rule. Each requirement should name the provider classes it applies to, so the contract team can see which clauses a given provider must carry. Confirm with your assessor that the section is approved and dated.

Contract clause library

A clause library is a set of approved wording for each policy requirement, such as breach notification timing, encryption standards and data return or deletion at termination. Procurement and legal reuse these clauses so that each contract starts from the same security baseline rather than from ad hoc drafting. Record the owner, the approval date and the policy requirement each clause supports. An assessor will compare the library against the policy to confirm that every required topic has approved wording.

Executed contracts and addenda

Assessors usually select a sample of service providers and ask for the signed agreement, including any security addenda or amendments. They check that the contract contains the security requirements the policy calls for, not only a general reference to security. Where an older contract predates the policy, look for a signed addendum that brings it into line. Store the signed copies with the provider record so the sample can be pulled quickly.

Contract register with review dates

A contract register lists every provider agreement with its classification, owner, start and end dates, renewal date and next review date. Safeguard 15.4 is scored with a compliance measure based on the share of providers with up-to-date contracts, so the register is the easiest way to show that figure. Include a column that flags agreements past their review date. Build the register from the inventory maintained under Safeguard 15.1 so no provider is missing.

Annual review records with sign-off

CIS asks for contracts to be reviewed annually. Each review record should name the contract, the reviewer, the date, the requirements checked, any gaps found and the approver who accepted the outcome. A review that finds no change still needs a record. Assessors look for evidence that reviews happened on schedule and that gaps were tracked to closure, so keep open actions linked to the record until they are resolved.

Change history for amended clauses

When a clause changes, the assessor needs to see what changed, when, who approved it and which contracts were affected. Keep the clause library and contract templates under version control so that earlier wording can be compared with current wording. Wiki platforms such as XWiki keep a record of every page change, including author and time, and allow any two versions to be compared. Confirm that the platform's history is retained for the period your audit cycle requires and that access to edit approved clauses is restricted.

Where the cost of 15.4 actually sits

Most of the cost of Safeguard 15.4 is internal time, not an outside invoice. Writing security requirements into provider contracts draws on legal counsel, procurement, the security team and, for high-sensitivity providers, the data owner who knows what the provider will hold. Each of these roles spends hours drafting the security schedule, agreeing which minimum program requirements apply, setting notification windows for incidents and breaches, and defining encryption and data disposal commitments. Counsel fees and internal hourly rates vary widely by organization and jurisdiction, so confirm them with your own finance and legal advisers before you budget. Ask any outside firm you engage for a written scope that lists the contracts in view, the standard clauses being adapted, and the approval steps before anything is signed.

The cost recurs every year because 15.4 requires annual contract review. Renewal dates, changes in the provider's services, new sub-processors and shifts in regulation all mean the security terms need checking, not just filing. The effort grows with the number of providers classified as high sensitivity, since each one carries its own schedule, amendment history and negotiation. Plan for the first pass to be the heaviest, with later reviews smaller if the contract library is kept current. Prerequisites in Safeguards 15.1 and 15.2 also need upkeep, and their upkeep adds to the recurring load.

Renegotiation is the cost most organizations underestimate. Providers with standard terms often resist amendments, especially large cloud and software vendors whose agreements are not negotiable line by line. Expect longer cycles, escalations to the provider's legal team, and some decisions to accept a weaker clause or to replace the provider. Build that possibility into your planning by identifying, before negotiations start, which providers will need a formal addendum and which can accept a standard security exhibit. Confirm internally who has authority to accept residual risk when a provider refuses a requirement, because that decision is often the slowest part of the process.

What meeting 15.4 costs in money and effort

This table lists each cost component of writing security requirements into provider contracts, who carries it, whether it is one-time or recurring, and what moves it up or down. Read it as a budgeting checklist: the one-time items front-load effort, while the annual register review and provider negotiations at renewal determine the ongoing load. No fee figures are given because none were supplied for this safeguard, so ask for each line item in a written quote.

Cost component	One-time or recurring	What drives it up	How to keep it down
Legal review of clause templates	One-time, revisited when law or policy changes	Multiple jurisdictions, regulated data types, bespoke legal wording per contract	Maintain one standard security addendum reviewed by counsel, with approved fallback positions
Security team time to define requirements	One-time, then periodic updates	Large number of service provider categories, unclear policy from Safeguard 15.2	Tier requirements by classification from Safeguard 15.3 so each tier has a fixed clause set
Amendment negotiation with existing providers	One-time per provider, recurring at each renewal	Provider leverage, large or standard-form vendors that refuse changes, many contracts due at once	Stagger renewals, prioritize high-sensitivity providers, and accept provider security documentation where it meets the clause
Contract register and review upkeep	Recurring, at least annually	Number of providers, contracts held in email or unlinked folders, missing expiry dates	Keep one register with expiry, clause version and owner fields in a self-hosted wiki or document tool with version history
Annual contract review	Recurring, at least annually	Number of contracts, manual comparison of clauses against the template, no record of prior reviews	Use a checklist per contract and record each review's date and reviewer in the register
External legal or assessor review of clauses	Variable, typically project-based or per engagement	Novel data types, high-regulation sectors, requests for independent sampling of contract files	Scope the external review to the template and high-risk contracts, and ask for fixed-scope quotes
Compliance mapping and evidence collection	Recurring when a framework audit runs	Several frameworks requiring the same clause, manual cross-referencing	Use open-source GRC tooling such as CISO Assistant to track assessments and mappings in one place
Software licensing for register and wiki tools	Recurring if commercial	Per-seat or per-module commercial licenses	Choose self-hosted open-source tools (for example XWiki or BookStack) to remove license spend for these functions, while still paying for hosting and administration

Who owns 15.4 and what can be outsourced

Your organization owns Safeguard 15.4 in full. The service provider management policy, the security requirements it sets for providers, the contracts themselves and the annual review decisions all sit with you. Legal and procurement carry out the negotiation, but the security owner should set the minimum clauses the policy requires and approve any deviation from them. Signatures stay with authorized signatories in your organization.

Policy ownership: Define the minimum security program requirements, incident notification expectations, encryption and disposal commitments in Safeguard 15.2 terms before negotiating individual contracts.
Negotiation and signature: Legal and procurement negotiate, and only your authorized signatories accept terms.
Deviation decisions: Record who approved each exception to a standard clause and why.
Annual review: Assign a named owner to review each contract at least once a year and decide whether to renew, amend or exit.
Prerequisites: Keep the provider inventory (15.1) and the policy (15.2) current, because 15.4 is measured against them.

Confirm that your policy names the clauses required for each provider classification and that the contract owner can produce a current list of contracts on request.

Where provider contracts usually fall short of 15.4

Most contracts miss Safeguard 15.4 for reasons that sit upstream of the contract text itself: a policy with no security requirements, contracts that predate the policy, and no register to measure them. The cards below pair each gap with a closing step that an assessor can check, starting with the policy because the other fixes depend on it.

Policy has no security requirements

The service provider management policy under Safeguard 15.2 often describes intake and onboarding but never states what a provider must do for security. Under the CIS assessment specification, a policy with no security requirements for providers fails Safeguard 15.4 at the root, before any contract is read. Closing step: add a section listing minimum security program requirements, incident notification, encryption and data disposal expectations, then approve it as the source for every contract template.

Contracts predate the policy

Agreements signed before the policy existed rarely reference its requirements, and renewals often copy the old wording forward. An assessor comparing the policy with a sample of executed contracts will find the gap quickly. Closing step: map each active contract against the policy requirements, then issue an amendment or addendum for every missing clause, prioritizing providers classified as sensitive under Safeguard 15.3.

No contract register

The Compliance metric for Safeguard 15.4 is the share of service providers with up-to-date contracts, and that share cannot be calculated without a register of contract dates, owners and review status. Many organizations keep contracts in procurement folders that no one reconciles with the provider inventory from Safeguard 15.1. Closing step: add contract start, end, review date and responsible owner fields to the provider inventory, and reconcile the two sources each quarter.

Annual review skipped at renewal

CIS asks for contracts to be reviewed annually, but a contract that auto-renews often escapes review because nobody owns the calendar date. The review is what keeps security terms aligned with changes in the provider's services, data flows and the enterprise's own policy. Closing step: set a recurring review task tied to each contract's anniversary, and record the reviewer, the date and any changes made.

Breach notice without response duty

A clause that requires the provider to notify the enterprise of a breach, with no obligation to contain, investigate or cooperate, leaves the enterprise learning of an incident without the means to respond. This gap matters for Safeguard 15.4 because the CIS examples cover both notification and response. Closing step: specify notification timing, a named contact, cooperation on forensic information and a duty to share root cause findings after containment.

Disposal terms missing

Contracts that say nothing about returning or deleting enterprise data leave Safeguard 15.7 impossible to meet when the relationship ends. Providers may hold backups, logs or replicas that no one can locate or verify later. Closing step: add clauses covering data return formats, deletion timelines, treatment of backups and a written certificate of disposal, so the decommissioning steps have a contractual basis.

Questions buyers ask about Safeguard 15.4

Does Safeguard 15.4 apply to IG1 enterprises?

No. Safeguard 15.4 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. IG1 covers essential cyber hygiene and includes only Safeguard 15.1 from Control 15, the service provider inventory. Even so, an IG1 organization that already signs contracts with providers holding sensitive data often adds security clauses anyway, because the inventory it must keep is the starting point for that work. Confirm your own Implementation Group against the CIS Controls Implementation Groups pages before you scope the work.

How much effort does amending provider contracts take, and what drives it?

Effort depends mostly on the number of contracts, how much standard terms can be changed, and how many legal entities must agree. Costs are split between internal legal and procurement time, which recurs at each renewal, and any outside help you buy. Common drivers include whether providers use their own paper or accept an addendum, how many contracts carry sensitive data, and whether your policy under Safeguard 15.2 already defines the minimum requirements. Ask any partner for a written scope that lists the contracts in scope, the clauses to be drafted, and who approves them.

How long does a contract review take, and what does the team need to provide?

Duration depends on the size of the provider portfolio and the state of the existing records, so no fixed figure applies. CIS asks for contracts to be reviewed annually, so the review is a recurring activity after the first pass. The team needs the current service provider inventory, the policy that sets minimum security requirements, a list of contracts with their renewal dates, and the owner for each relationship. Confirm with your legal team how long they need to review redlines before you plan the timeline.

Can our legal team do this without an outside partner?

Yes, in most organizations the core work is internal. Legal and procurement own the clauses, the wording, the negotiation and the signature, and the enterprise owns the policy the clauses come from. Outside help usually covers narrower tasks, such as preparing the inventory and contract register, building a tracking system for renewal and review dates, and assembling the evidence an assessor will ask for. Before you decide, confirm that your team has time for an annual review cycle, because the requirement recurs.

What does a consultant need from us to help?

A consultant needs read access to the service provider inventory, the service provider management policy, a sample of signed contracts, and the names of the people who own each relationship. They also need your legal team's current standard security addendum, if one exists, and the record of past contract reviews. DeployOpen plans, implements and documents systems and evidence inside your environment, and works from a written scope agreed before work starts. It does not draft legal advice or issue reports on your contracts.

Will an auditor certify our contracts as compliant with Safeguard 15.4?

No. Independent auditors and assessors test controls and report on what they find, and certification bodies issue certificates. Your organization owns its contracts and its compliance position, and a partner can only prepare the records and evidence. An assessor will typically sample contracts, check that clauses match the policy, and confirm that reviews happened on schedule. Ask your assessor which evidence format they expect before you prepare it.

How does Safeguard 15.4 relate to 15.2 and 15.5?

Safeguard 15.2 is the service provider management policy, and it must define the security requirements that 15.4 places into contracts. CIS lists 15.1 and 15.2 as prerequisites for measuring 15.4, so the policy and inventory come first. Safeguard 15.5 covers assessing providers against the policy and their classification, using reports such as SOC 2 or questionnaires. Contract clauses give you the right to request that evidence, so 15.4 and 15.5 work together. Confirm the exact wording of each requirement in the CIS Controls Assessment Specification before you map your records.

How DeployOpen prepares 15.4 evidence

DeployOpen plans, implements and documents the systems and records that show Safeguard 15.4 Security requirements in provider contracts is met, inside your own infrastructure. Your organization owns its controls and contracts, and only an independent auditor or assessor issues any report or certificate.

How we scope

Written scope names the contract types, provider classes and the policy clauses that 15.4 requires to be reflected in contracts.
Scope confirms the prerequisite records for 15.1 and 15.2 exist before contract work starts.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.

How we build

Contract clause library covering minimum security program, incident notification, encryption and data disposal requirements.
Contract register in your own platform that tracks each provider's contract date, review date and clause status.
Review workflow and version history so every change to a contract template or clause is traceable.

How we hand over

Documented procedure for the annual contract review, including who reviews, what is checked and how exceptions are recorded.
Evidence pack mapped to the Compliance metric: the share of service providers with up-to-date contracts, with source records.
Handover session so your staff can run the register and review cycle without ongoing dependence on DeployOpen.

How we support

Ongoing support, upgrades and reviews of the register are available as a retainer.
Support can cover updating clause language when your service provider management policy changes.
Confirm with your independent assessor which evidence format and sampling approach they will accept before handover.