Safeguard 15.2: Establish and Maintain a Service Provider Management Policy

Safeguard 15.2 requires you to create, approve, and run a documented service provider (third-party) management policy that governs how your organization selects, assesses, contracts with, monitors, and offboards service providers with access to your systems or data (CIS Controls v8; CIS Controls Navigator v8). To operationalize it quickly, define scope and ownership, tier third parties by risk, set required due diligence and contract clauses per tier, then collect recurring evidence that the policy is followed.

Key takeaways:

• The policy must be operational: it should drive intake, risk tiering, due diligence, contracting, ongoing monitoring, and offboarding (CIS Controls v8; CIS Controls Navigator v8).
• Examiners and auditors will look for proof the policy is executed, not just published, so build recurring evidence capture into the workflow.
• Start with a focused scope: service providers that store, process, transmit data, or connect to your environment, then expand coverage.

A “service provider management policy” is the backbone of third-party risk management (TPRM) because it turns ad hoc vendor reviews into a repeatable control. Safeguard 15.2 is not asking for a perfect program on day one; it is asking for an established and maintained policy that sets expectations and makes third-party risk decisions auditable (CIS Controls v8; CIS Controls Navigator v8).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to write a policy that is specific enough to run. That means: clear definitions (what counts as a service provider, what counts as “access”), explicit roles (who owns intake, who signs risk acceptances), and minimum required activities tied to risk tiers (what you must collect, when you must re-review, and what contract terms are non-negotiable). You then operationalize the policy through a workflow in your GRC tool, ticketing system, or procurement process so the evidence is created as work happens.

This page focuses on requirement-level implementation guidance for the target keyword “safeguard 15.2: establish and maintain a service provider management policy requirement,” with practical steps, audit-ready artifacts, and common failure modes to avoid, aligned to CIS Controls v8 (CIS Controls v8; CIS Controls Navigator v8).

Requirement: Safeguard 15.2 service provider management policy (CIS Controls v8)

Safeguard 15.2 expects you to establish and maintain a documented policy for managing service providers (third parties) (CIS Controls v8; CIS Controls Navigator v8). In practice, “establish” means the policy exists, is approved, is communicated, and is used. “Maintain” means you review/update it when the environment changes (new technologies, new data types, new threat patterns, new regulatory obligations) and you can show the current version is in force.

Plain-English interpretation

You need a written rulebook that answers:

• Which third parties must go through third-party risk management before onboarding?
• How do you classify third parties by risk, and what control checks are required for each class?
• What security, privacy, and resilience terms must be in contracts?
• How do you monitor third parties after onboarding (not just at renewal)?
• How do you offboard and verify access/data return or destruction?

If your policy does not change day-to-day behavior (procurement intake, security reviews, approvals, contracting, monitoring), auditors will treat it as shelfware even if it’s well-written.

Regulatory text

Provided excerpt: “CIS Controls v8 safeguard 15.2 implementation expectation (Establish and Maintain a Service Provider Management Policy).” (CIS Controls v8; CIS Controls Navigator v8)

What the operator must do:

• Write a service provider management policy that sets mandatory steps and decision points for third-party onboarding and oversight (CIS Controls v8; CIS Controls Navigator v8).
• Assign ownership and accountability so the policy is executable (for example: Procurement owns intake, Security owns security risk review, Legal owns contracting, the business owner owns performance and exit).
• Build recurring evidence capture into the process so you can prove the policy is followed (CIS Controls v8; CIS Controls Navigator v8).

Who it applies to

Entity types: Enterprises and technology organizations adopting CIS Controls v8 (CIS Controls v8; CIS Controls Navigator v8).

Operational context (what to scope in):

• SaaS providers that store or process your data (including HR, CRM, finance, support tooling).
• IT and security managed service providers (MSPs/MSSPs).
• Cloud providers and hosting providers.
• Contractors or consultants with network access, code access, or production admin access.
• Data processors, call centers, fulfillment partners, and other outsourced operations.

Practical scoping rule: If a third party can materially affect confidentiality, integrity, or availability of your systems/data, it belongs in the policy’s scope.

What you actually need to do (step-by-step)

1) Define terms and scope in one page

Include definitions you will reuse in procedures and tooling:

• “Service provider” / “third party”
• “Access” (network, application, admin, code repository, data access)
• “Sensitive data” (align to your internal data classification)
• “Subprocessor” (their third parties)

Decision point: whether the policy covers only service providers or all third parties. Many organizations title it “service provider” to meet 15.2, but apply it broadly to avoid duplicate policies.

2) Assign roles and decision rights (RACI)

Minimum roles to name:

• Third-party owner (business owner): accountable for need, fit, and ongoing relationship.
• Information Security: defines required security checks, reviews results, approves or escalates.
• Privacy (if applicable): confirms data processing terms and cross-border considerations.
• Legal/Contracts: ensures required clauses and addenda are signed.
• Procurement/Vendor Management: controls intake, ensures required steps are completed.
• Risk/Compliance: governance, exceptions, metrics, program assurance.

Make risk acceptance explicit: who can accept residual third-party risk, and what documentation is required.

3) Implement risk tiering that drives requirements

You need a tiering method that maps to action. Keep it simple:

• Criteria examples: data sensitivity, production access, privileged access, service criticality, external connectivity, reliance on subprocessors.
• Output: a tier (e.g., low/medium/high) that determines due diligence depth and approval path.

Auditor hangup to avoid: tiering that exists but does not change required controls.

4) Set minimum due diligence requirements per tier

Your policy should mandate what evidence you collect and review before contracting or access:

• Security questionnaire and documented review outcome.
• Independent assurance artifacts when available (for example, a SOC report) and a documented review summary.
• Basic checks: incident history disclosure, vulnerability management approach, access control model, encryption, logging, BCP/DR expectations, and subcontractor oversight.

Write the rule as “must” statements, then reference a standard operating procedure (SOP) or checklist.

5) Require contract controls and minimum clauses

The policy should state that the contract (or addendum) must cover, when applicable:

• Security requirements and right to audit/assess
• Incident notification expectations and cooperation
• Data ownership, permitted use, retention, deletion/return
• Subprocessor controls and change notification
• Access restrictions and MFA/least privilege for admin access
• Termination assistance and offboarding obligations

Keep the policy at requirement level; your templates and playbooks hold the clause language.

6) Build ongoing monitoring and re-assessment into operations

“Maintain” fails when monitoring is missing. Your policy should require:

• Periodic reassessment based on tier, material changes, or security events
• Triggers: scope change, new data types, new integrations, M&A, breach notification, negative assurance findings
• Tracking of open issues and remediation plans with deadlines and owners (deadlines can be defined in your procedures rather than the policy)

7) Define offboarding and access removal

Offboarding is frequently ignored. Policy requirements should include:

• Deprovisioning of accounts, keys, tokens, VPN access
• Confirmation of data return/deletion and retention exceptions
• Validation that integrations are removed and logs retained per your standards

8) Make evidence capture automatic (so audits are easy)

Operationalize through workflow. Daydream (or your existing GRC/procurement tooling) should enforce:

• Intake form completion before purchase order or contract signature
• Tiering result stored with rationale
• Required attachments per tier
• Approval log and exception workflow
• Review cadence tasks and reminders
• Offboarding checklist tied to contract end

This maps directly to the recommended control: “Map 15.2 to documented control operation and recurring evidence capture.” (CIS Controls v8; CIS Controls Navigator v8)

Required evidence and artifacts to retain

Store evidence centrally with version control and timestamps:

• Service Provider Management Policy (approved version, effective date, revision history) (CIS Controls v8; CIS Controls Navigator v8)
• Inventory/list of in-scope service providers with tier and owner
• Completed due diligence packages (questionnaires, assurance reports, security review notes)
• Risk decisions: approvals, rejections, risk acceptances, and exceptions with sign-off
• Contract artifacts: security addenda, DPAs, key security clauses checklist
• Ongoing monitoring records: reassessment tickets, issue logs, remediation tracking
• Offboarding records: access removal confirmation, data deletion/return attestations

Common exam/audit questions and hangups

Expect these questions:

• “Show me your policy, and show me where it is enforced in procurement or onboarding.”
• “How do you decide which third parties are high risk? Show the tiering method and a few examples.”
• “Pick three critical service providers. Show initial due diligence, contract requirements, and evidence of ongoing monitoring.”
• “How do you handle exceptions? Who approved them, and when do they expire?”
• “How do you ensure terminated vendors lose access and delete/return data?”

Common hangup: policy says “annual reviews” or “periodic monitoring,” but there’s no ticket trail, calendar, or assigned ownership.

Frequent implementation mistakes (and how to avoid them)

1. Policy is too generic to execute.
   Fix: add explicit must/shall statements tied to tiers, approvals, and required artifacts.

2. No single system of record for third parties.
   Fix: maintain a canonical inventory (even if it starts as a spreadsheet) with owners and tiers, then move into a GRC tool.

3. Security review happens after contracting.
   Fix: make “no contract signature and no access until due diligence complete” the default, with a documented exception path.

4. Offboarding is not controlled.
   Fix: require an offboarding checklist and make IT disable access a tracked step, not an email request.

5. Evidence is scattered across email.
   Fix: require uploads/links in the intake record and prevent closure without attachments.

Enforcement context and risk implications

CIS Controls v8 is a framework, not a regulator. The risk is practical: service providers are a common entry point for incidents, and auditors frequently treat weak third-party governance as a control design failure because it undermines multiple security objectives (CIS Controls v8; CIS Controls Navigator v8). The most defensible posture is a policy that is demonstrably followed, with consistent records and exception governance.

Practical 30/60/90-day execution plan

First 30 days: Establish the policy and minimum workflow

• Draft policy with scope, roles, tiering approach, minimum due diligence, contract requirements, monitoring triggers, and offboarding requirements (CIS Controls v8; CIS Controls Navigator v8).
• Get formal approval (CCO/CISO or equivalent) and publish in your policy repository.
• Stand up an intake workflow (GRC tool, procurement system, or ticketing) that captures: third party name, service description, data/access, owner, tier, required artifacts, approvals.
• Build an exceptions process with documented risk acceptance.

Days 31–60: Apply to your top risks first

• Create or clean up the third-party inventory; identify critical/high-risk service providers first.
• Run due diligence retroactively for the most critical providers where evidence is missing; document gaps and remediation plans.
• Standardize contract addenda/checklists and align Legal + Security review steps.

Days 61–90: Prove “maintain” with monitoring and metrics

• Launch recurring monitoring tasks based on tier (reassessments, attestations, review of assurance updates).
• Implement offboarding checklist and test it on a real termination or a tabletop exercise.
• Produce a monthly reporting pack: inventory by tier, open third-party issues, exceptions, overdue reviews, and upcoming renewals.

If you want this to run without heroics, Daydream fits best where you need repeatable intake, tiering, evidence capture, and audit-ready exports tied directly to Safeguard 15.2 (CIS Controls v8; CIS Controls Navigator v8).

Frequently Asked Questions

Do I need a separate “service provider management policy” if I already have a vendor risk management policy?

No, as long as your existing policy clearly covers service providers and meets the Safeguard 15.2 expectation to establish and maintain a service provider management policy (CIS Controls v8; CIS Controls Navigator v8). Many teams keep one third-party policy and align naming and scope to satisfy 15.2.

What counts as a “service provider” for scoping this policy?

Treat any third party that stores, processes, or transmits your data, or has logical access to your environment, as in scope. If a third party can materially affect your confidentiality, integrity, or availability, include it.

How detailed should the policy be versus procedures and playbooks?

Put mandatory requirements and decision rights in the policy (tiers, required approvals, required artifacts, exceptions). Put how-to details (questionnaire content, contract clause templates, review checklists) in procedures so updates do not require a full policy reapproval cycle.

Can we onboard a third party before due diligence is complete?

Your policy should make this an exception with documented risk acceptance, temporary controls, and a defined plan to complete due diligence. Auditors will focus on whether exceptions are governed and time-bounded.

What evidence is most persuasive in an audit?

A clean system of record that ties each third party to: tiering rationale, due diligence artifacts, approval logs, contract/security addenda status, monitoring tasks, and offboarding records. Screenshots help, but exported reports with timestamps are stronger.

How do we handle fourth parties (subprocessors)?

Require service providers to disclose subprocessors for in-scope services and to notify you of material changes. Track subprocessors as part of due diligence for higher-risk relationships, then document any required contractual flow-down obligations.