CIS service provider management policy template (Control 15) guide

What a CIS service provider management policy template must cover

If a customer or regulator asks for a CIS-aligned third-party policy, the honest answer starts with scope: CIS's free policy templates cover only IG1 Safeguards, and the Control 15 policy itself is Safeguard 15.2, which CIS places at IG2. An IG1 enterprise therefore has one Control 15 obligation, the provider inventory in Safeguard 15.1, and the written policy becomes required once the enterprise moves into IG2 and IG3, where Control 15 grows to seven Safeguards in total (1 at IG1, 3 added at IG2 and 3 added at IG3).

Start with the inventory, because every later element depends on it. Safeguard 15.1 asks for a list of all known service providers, their classification or classifications, and a designated enterprise contact for each. Confirm before drafting that the list is complete, that each provider has a named owner inside the organization, and that the classifications reflect what each provider actually holds or runs. Your Implementation Group determines whether the written policy must address classification, inventory, assessment, monitoring and decommissioning, and whether the contracts must carry the security requirements described in Safeguard 15.4, such as minimum security program requirements, incident notification, encryption and data disposal. Read the CIS Controls Assessment Specification for Control 15 to see how each Safeguard is measured before you decide how deep the policy needs to go.

The organization owns this policy, its provider classifications and every decision to onboard, retain or exit a provider. An implementation partner can help prepare the inventory, draft the policy, map contract clauses and assemble the records an assessor will ask for, but it cannot decide the classifications or issue assessment results. Those come from your own review and from an independent assessor you choose. Before you commit to a plan, ask for the written scope to name the Safeguards and Implementation Group it covers and the evidence each deliverable will produce.

How the Control 15 policy grows across IG1, IG2 and IG3

At IG1, Control 15 asks for one thing: a working list of every known service provider. Safeguard 15.1 requires the inventory to show each provider's classification or classifications and a designated enterprise contact for each one. The list is the foundation for every later step, because a policy, contract review or decommissioning process cannot be applied to providers the enterprise does not know it has. Teams usually build the first version from accounts payable records, single sign-on applications, cloud subscriptions and contract registers, then assign each provider to a named owner inside the business.

Complete list: Include every provider that holds enterprise data or runs IT platforms or processes, not only the large or obvious ones.
Classification field: Record the classification or classifications that describe what each provider handles or operates.
Enterprise contact: Name a single accountable internal person for every provider entry.
Discovery sources: Reconcile the list against finance, procurement and identity records to catch providers added outside formal channels.
Ongoing upkeep: Update the inventory when providers are onboarded or retired, so it reflects current reality.

Before relying on the inventory, confirm the exact field names and expected detail in the CIS Controls Assessment Specification for Safeguard 15.1.

Which parts the policy must address: classification, inventory, assessment, monitoring and decommissioning

Safeguard 15.2 asks for a service provider management policy covering classification, inventory, assessment, monitoring and decommissioning, and Safeguard 15.4 requires contracts to carry security requirements consistent with that policy. The cards below take each element in turn, with the evidence an assessor would expect to see and the Safeguard it supports.

Classification of providers

The policy should define the tiers used to classify each service provider, based on the sensitivity of the data they hold and the criticality of the IT platforms or processes they run. Classification drives how deep every later step goes, so the criteria must be written down and applied the same way to every provider. Evidence is a classification field on each inventory record and a rationale for the assigned tier. Safeguard 15.1 requires the classification in the inventory, and 15.2 requires the policy to address it. Confirm the expected classification detail in the CIS Assessment Specification.

Provider inventory and contacts

The policy should require a single inventory of all known service providers, with each provider's classification and a designated enterprise contact who owns the relationship. Without a named owner, reviews and offboarding tend to stall. Evidence is the inventory itself, showing every provider, its tier and its contact, with a record of when it was last reviewed. Safeguard 15.1 sets the inventory requirement at IG1, so this element is the one part of Control 15 that applies to every enterprise.

Assessment before and during engagement

The policy should state when a provider is assessed, what the assessment covers for each tier, and who approves the outcome. Assessment usually runs before contract signature and again when the provider's scope changes. Evidence is a completed assessment record for each provider in scope, with findings, a decision and any agreed remediation. Safeguard 15.2 names assessment as a policy element. Ask your assessor or the CIS Assessment Specification which assessment depth it expects for each classification.

Contract security requirements

The policy should set the minimum security terms every provider contract must include, such as security program requirements, incident notification, data encryption and data disposal. Contract terms are the enforcement point for everything else in the policy. Evidence is the contract clause set for each tier and a record of the annual contract review that Safeguard 15.4 expects. CIS lists these terms as examples, so your policy should name the specific requirements your organization needs and confirm them with legal counsel.

Ongoing monitoring of providers

The policy should define how provider performance and security posture are monitored between assessments, including who reviews provider reports, how security events involving a provider are escalated and how often reviews take place. Monitoring turns a one-time assessment into a current view of risk. Evidence includes review notes, provider security reports on file, and records of issues raised and closed. Monitoring is a policy element named in Safeguard 15.2. Confirm the monitoring expectations for your classification tier in the CIS Assessment Specification before setting review intervals.

Secure decommissioning

The policy should describe how a provider relationship ends: access revocation, return or disposal of data, confirmation that the provider has removed copies, and closure of the inventory record. Decommissioning is the step most often skipped, which leaves live accounts and retained data behind. Evidence is an offboarding ticket showing access removed, a data disposal certificate or written confirmation from the provider, and the updated inventory entry. Safeguard 15.2 names decommissioning as a policy element, and the disposal terms in contracts under 15.4 should support it.

What Safeguard 15.4 expects contracts to say

Safeguard 15.4 asks that service provider contracts include security requirements consistent with the enterprise's service provider management policy. The policy should not stop at principles. It should define the minimum set of security terms that must appear in every contract with a provider in scope, so that a contract signed by procurement cannot quietly fall short of what the policy requires. In practice, the policy becomes the checklist that legal and procurement work from, and the contract is where those requirements become enforceable.

CIS gives four example contract requirements: minimum security program requirements that the provider must maintain, security incident and data breach notification and response obligations, data encryption requirements, and data disposal commitments. A policy can turn each into a clause standard. For example, it can state the notification window the enterprise needs to meet its own incident response process, the encryption standard for data at rest and in transit, and how the provider must return or destroy data at exit. The organization should confirm these values with its incident response and data management owners before they go into the template, since the right thresholds depend on its own obligations and regulators.

CIS also asks that contracts be reviewed annually. The policy should name who runs that review, which contracts it covers, and what triggers an earlier review, such as a change in the provider's services, a material incident or a change in the data the provider holds. The organization's legal team sets the final wording of every clause, so the policy should describe the required content and the approval path rather than draft the language itself. Teams preparing for an assessment should keep the signed contracts, the review records and the clause checklist together as evidence that the Safeguard is operating.

What a Control 15 policy project costs and who gets paid

This table lists who is paid for each part of a CIS Control 15 policy project, whether the cost is one-time or recurring, and what drives it up. Read it to decide which work stays in-house and which parts a quote should price separately. The main takeaway is that the CIS policy templates and Controls carry no license fee for internal use, so most spending goes to people, review cycles and any independent assessment.

Component	Who is paid	One-time or recurring	What drives the cost
CIS policy templates and Controls	No fee supplied for the Control 15 template; CIS Controls are free for internal use	Not applicable	Commercial use, such as selling the Controls as a service, requires CIS prior approval. Confirm licensing with CIS before any external use.
Internal policy owner	Your staff (salary or time allocation)	One-time drafting, then recurring ownership	Number of providers in scope, number of business units that buy services, and how many approvals the policy needs
Legal and contract review	Internal counsel or outside counsel	One-time for template clauses, recurring for renewals	How many contracts must be amended to carry the Safeguard 15.4 security requirements, and how many are non-standard
Procurement review	Internal procurement staff	Recurring with each new or renewed provider	Volume of new vendors, and whether procurement checks security requirements before signing
Implementation partner (optional)	Partner firm, under a written fixed scope if chosen	One-time for inventory and drafts, optional recurring for reviews	Size of the provider inventory, condition of existing contract records and the depth of the policy requested. Ask for the scope, deliverables and timeline in writing.
Inventory tooling and tracking	Software vendor or open-source tooling run by your team	Recurring licenses (if commercial) and upkeep	Number of providers, fields tracked per provider (classification, enterprise contact, data held) and integration with procurement or asset records
Provider monitoring and annual contract review	Internal risk or security staff, sometimes provider questionnaire services	Recurring every year and at each renewal	Number of providers in each classification and how often each is reassessed
Independent auditor or assessor (if requested)	Independent auditor or assessor, not DeployOpen or the partner	One-time per assessment cycle	Scope of the assessment, number of providers sampled and whether the requesting party needs a formal report

How the policy moves from inventory to an assessed program

The sequence turns a provider list into a governed program: each phase produces a record that a reviewer can check against Safeguards 15.1, 15.2 and 15.4 and the wider Control 15 expectations.

Build the service provider inventory
Start by listing every known service provider, including those that hold sensitive data or run critical IT platforms or processes. For each entry, record its classification and a designated enterprise contact who owns the relationship. Procurement, finance and business units often hold contracts that IT does not see, so reconcile the list against accounts payable, software purchasing and cloud subscriptions. The step is done when the inventory lists all known providers with classification and contact fields filled in, which is the evidence Safeguard 15.1 asks for.
Classify providers by data and criticality
Assign each provider a classification based on the sensitivity of the data it touches, its access to systems and how much the business depends on its service. Agree the classification categories with data owners and security leads so they are applied the same way across departments. Record the rationale next to each classification so an assessor can see why a provider sits in its tier. The output is a classified inventory and a short written classification method that the policy will reference.
Adapt the CIS template to the enterprise
Use the CIS policy template as the starting structure, then add the enterprise's own roles, approval paths, classification labels and review cycle. Remove nothing that the Safeguard 15.2 scope requires, which covers classification, inventory, assessment, monitoring and decommissioning. Map each section to a named owner, such as the enterprise contact or the third-party risk function. The output is a draft policy with a version number, an owner and a clear statement of which providers it applies to.
Approve the policy and communicate it
Route the draft through the governance body that approves security policies, usually including legal, procurement and the business owners who manage providers. Record the approval date, the approver and any conditions. Then brief the enterprise contacts and the teams that sign contracts so they know which requirements apply before a new engagement starts. The step is complete when a signed or recorded approval exists and the policy is published to the people who use it.
Align contract security requirements
Review the contract templates and the existing agreements for high-classification providers. Add security requirements consistent with the policy, such as minimum security program expectations, incident and breach notification duties, encryption requirements and data disposal commitments, which are the example contract requirements Safeguard 15.4 cites. Legal should confirm the clauses are enforceable in the jurisdictions involved. For existing contracts, plan amendments at renewal or through a negotiated addendum. The output is a clause library and a contract register showing which agreements contain the requirements and which still need them.
Assess providers before and during engagement
Before a provider is onboarded, assess it against the requirements that match its classification, using questionnaires, evidence such as independent reports where the provider holds them, and interviews for critical providers. Record the findings, the risk decision and any compensating conditions. Schedule contract reviews on the annual cycle that Safeguard 15.4 describes. The output is an assessment record per provider, with the date, the reviewer and the decision, which an assessor will sample.
Monitor providers and log exceptions
Track each provider against its assessed conditions. Monitoring methods vary by classification and may include reviewing security notices, tracking incidents reported by the provider, and checking that the contact still matches the inventory. Log every exception, its owner and its closure date. Feed findings back into the inventory and the classification so the records stay current. The output is a monitoring log and an exceptions register that show the program operates after onboarding.
Document decommissioning and offboarding
When a provider relationship ends, follow a documented process that confirms data return or disposal, revokes system and network access, closes accounts and updates the inventory to show the provider as retired. Keep the offboarding checklist and the disposal confirmation with the provider's file. The step is complete when the inventory, access records and contract register all reflect the end of the relationship, which gives the assessor a traceable offboarding record.

Who owns the policy, who prepares the evidence and who assesses it

The enterprise owns the service provider management program and every decision inside it. Leadership approves the policy, decides which providers hold sensitive data or run critical IT platforms, accepts the residual risk of each relationship and signs the contracts. Those decisions cannot be delegated to a consultant, because the contract and the accountability sit with the enterprise.

Policy approval: A named owner, usually in security or risk, approves the written policy and its annual review.
Provider classification and risk acceptance: The enterprise decides each provider's classification and documents who accepts any remaining risk.
Contract terms: Legal and procurement include the security requirements the policy sets, such as incident notification and data disposal, in every relevant agreement.
Operational monitoring: Named staff in each business area keep the inventory current and watch provider performance.
Enterprise contacts: Each provider in the inventory needs a designated internal contact, as Safeguard 15.1 requires.

Confirm that your named policy owner and the business contacts for each provider are written down before any outside party starts work.

Why Control 15 projects stall and how to avoid it

Most delays on a Control 15 project come from a handful of gaps: policy scope, inventory completeness, contract sequencing, and the lifecycle steps after onboarding. Each card below names one gap, what it does to the project, and the check that closes it before an assessor or auditor asks.

Treating the IG1 template as full coverage

CIS's free policy templates cater exclusively to IG1 Safeguards and do not address IG2 or IG3 Safeguards. Safeguard 15.2, the service provider management policy, sits in IG2, so an organization that adopts the template unchanged has a policy that stops short of what IG2 asks. Check the policy against 15.2 and the Safeguards added at IG2 and IG3 before calling the policy done.

Inventory without an enterprise contact

Safeguard 15.1 asks for an inventory listing every known service provider, with its classification and a designated enterprise contact for each. Projects often produce a list from procurement records that omits the business owner, so no one answers when a provider has an incident or a contract comes up for review. Require a named owner on every row before the inventory is accepted.

Contracts signed before the policy exists

Safeguard 15.4 asks that provider contracts carry security requirements consistent with the enterprise's service provider management policy. When contracts are signed first, the terms reflect whatever the provider offered, and retrofitting them later means renegotiating each agreement. Approve the policy and its minimum security terms first, then use them as the starting clause set for new and renewing contracts.

No annual contract review

CIS asks that contracts be reviewed annually, which many teams miss because the review sits outside the renewal calendar. Without a dated review, breach notification terms, encryption requirements and disposal commitments drift out of date as the provider's services change. Assign each contract an owner and a review date in the inventory, and keep the review record as evidence.

No decommissioning steps for exiting providers

The policy must cover decommissioning, yet many organizations only write steps for onboarding. When a provider leaves, data may remain with the provider, access may stay active and the inventory may still list the relationship. Write a closure checklist that confirms data return or disposal, revokes access and updates the inventory before the contract ends.

Disputes over which providers count

Teams often disagree about whether a cloud tool, a contractor or a managed platform belongs in scope. Without a written test, the inventory becomes either padded or incomplete, and the assessment stalls on each argument. Define scope by the provider's access to sensitive data or its role in running critical IT platforms or processes, then record the decision for each borderline provider.

Questions buyers ask about the Control 15 policy

Do IG1 organizations need a Control 15 service provider management policy?

Not as a Safeguard. Safeguard 15.1, the provider inventory, is the only Control 15 Safeguard in IG1. The written policy is Safeguard 15.2, which CIS places in IG2, so it applies to IG2 and IG3 enterprises. An IG1 organization still needs the inventory, and a short written policy is a sensible first step because it gives the inventory a rule for what gets listed and who owns each provider. Check your customer contracts and regulators, since they may ask for the policy even when the CIS Safeguard does not.

What must a CIS service provider inventory contain?

Safeguard 15.1 asks for an inventory of all known service providers, with each provider's classification or classifications and a designated enterprise contact for each. In practice, record the provider name, the services it delivers, the data types and systems it can reach, its classification, the business owner, and the enterprise contact who manages the relationship. Review the list whenever a provider is onboarded or retired. The assessment specification checks whether the inventory is complete, so capture shadow IT purchases such as SaaS tools bought on corporate cards, not only contracted vendors.

Can we adopt the CIS policy template as is?

CIS publishes its policy templates as a starting point for the Controls, and the Control 15 template is built for the Safeguards CIS assigns to IG1, which does not include the policy itself. Treat the template as a skeleton. Your provider classes, approval authority, review cycle and decommissioning steps must reflect your own business, data and regulatory obligations. A policy copied without local decisions will not show the assessor that someone owns the process. Confirm the current template terms with CIS before reusing or redistributing text, because CIS content is licensed for non-commercial use with prior approval for commercial use.

How do contracts change when Control 15 applies?

Safeguard 15.4 asks that service provider contracts include security requirements consistent with your policy. The contract is where the policy becomes enforceable. CIS gives minimum security program requirements, security incident and data breach notification and response, data encryption requirements and data disposal commitments as example terms. Review existing contracts against these terms, and add a review cycle, since CIS asks for contracts to be reviewed annually. Expect legal and procurement time for renegotiation, and ask any outside partner to separate contract drafting, which needs counsel, from the technical controls behind each clause.

What work must our own team do?

Your team owns the policy, the inventory, the classification decisions, the contract terms and the risk acceptance for each provider. These are business decisions that an assessor expects to see made by named people. Your team also runs the ongoing work: keeping the inventory current, collecting provider security evidence, reviewing contracts each year, and tracking notifications. Plan for these as recurring effort, because the inventory and reviews decay if they are treated as a one-time project. Staff with procurement, legal, security and the business owners of each service should be involved from the start.

Do we need an outside partner to build this?

Not necessarily. Many organizations write the policy and inventory in house and bring in help only where the gaps are technical. An implementation partner can prepare the systems and evidence that support the policy, such as a tracked inventory, workflow for provider onboarding, and evidence collection in self-hosted tools that run in your environment. A partner does not own your controls and does not issue audit reports or certifications. If you engage one, agree the scope in writing before work starts, since most engagements are fixed-scope with deliverables and timelines agreed in advance.

How does an assessor check the Control 15 policy?

An assessor looks for evidence that the policy exists, is approved, and is applied. They will compare the inventory against your procurement records, accounts payable and network or identity data to test completeness, then sample providers to confirm the classification, named contact, contract security terms, and recent review. CIS's Assessment Specification defines the inputs, operations and measures for each Safeguard, but it describes what to measure rather than how. Ask your independent auditor which evidence they accept for each test, and keep dated versions of the policy, approvals, and review records so the trail is easy to follow.

How to check a partner or assessor before signing

Choosing who helps with CIS Control 15 evidence is a decision that shapes how credible your service provider management records look to a reviewer. The four checks below cover independence, experience, accreditation and written scope, and each one exposes a different risk if skipped.

Confirm independence from the build work

Ask whether the firm that assesses your service provider management process also designed, configured or operated any part of it. An organization cannot obtain an independent view of work its own advisers built. Under CIS Control 15, the policy, provider inventory and contract clauses are owned by your enterprise, so an implementation partner may prepare them, but an independent assessor should test them. Ask for the firm's conflict statement in writing before work starts, and confirm which named individuals will perform each role.

Check CIS Controls experience

Ask for examples of prior work that mapped evidence to specific CIS Controls v8.1 Safeguards, such as Safeguard 15.1 (provider inventory) and Safeguard 15.2 (service provider management policy). Generic security experience does not show familiarity with how the CIS Controls Assessment Specification measures each Safeguard. Request the names and roles of the staff who will do the work, and ask how they would test a provider inventory for completeness against your procurement records. Ask them to describe the evidence they would expect for a contract security review under Safeguard 15.4.

Ask about CIS Controls Accreditation

Ask whether the firm holds CIS Controls Accreditation, which CIS runs with CREST for SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. Accreditation is not a legal requirement for every engagement, so ask whether your scope actually calls for it. If the service includes assessment, confirm the accreditation status of the specific individuals or practice performing the work. Confirm current status directly with CIS, since accreditation status can change.

Require a written scope first

Before any work begins, require a written scope listing the deliverables, the Safeguards in scope by Implementation Group, the systems and provider records covered, and the evidence each deliverable will contain. For Control 15, a scope should state whether the work covers only IG1 Safeguard 15.1 or extends to IG2 items such as the policy in Safeguard 15.2 and contract requirements in Safeguard 15.4. Ask who owns each deliverable, what happens if scope changes, and how review and acceptance are recorded. Most engagements of this kind are fixed-scope, so a written scope also gives you the baseline for a quote.

How DeployOpen prepares the Control 15 inventory and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the systems and records that a Control 15 review will examine. The organization owns its policy, provider decisions and controls, and only an independent auditor or assessor issues any report or certificate.

How we scope

Agree in writing which service providers and platforms the Control 15 inventory will cover before work starts
Confirm which Safeguards apply at the client's Implementation Group, separating IG1 Safeguard 15.1 from IG2 and IG3 additions
Name the enterprise contact and classification fields the inventory must hold for each provider
Set out the deliverables and timeline for each engagement in the fixed-scope document

How we build

Structure the provider inventory so each entry records classification and a designated enterprise contact
Draft the service provider management policy around classification, assessment, monitoring and decommissioning, for the client to review and approve
Prepare standard contract security requirement clauses for the client's legal team to adapt to each provider
Configure self-hosted platforms so provider access, logs and data handling produce records a reviewer can sample

How we hand over

Deliver the inventory, policy and supporting records as documents the client owns and can maintain
Map each evidence item to the Safeguard it supports, so the client and its assessor can trace the proof
Walk the client's team through the documented process and the annual contract review steps
Confirm which assessment steps and evidence the client must still confirm with its chosen auditor

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Revisit the provider inventory and policy when new providers, contracts or Implementation Group targets change
Support the client through its assessor's questions, while the assessor alone issues findings or reports
Request a quote from the written scope, since DeployOpen does not publish a price list