Safeguard 15.5: Assess Service Providers

Safeguard 15.5 focuses on a common failure mode: organizations buy or outsource critical services, connect them to core systems, then treat the third party as “out of scope” for security control verification. CIS v8 positions service provider assessment as a practical control: identify which service providers matter, assess their security posture relative to the risk they introduce, and keep it current as relationships and integrations change. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn 15.5 into an operating rhythm: (1) an intake gate that prevents unmanaged onboarding, (2) risk tiering that determines assessment depth, (3) a due diligence package aligned to access type (data, networks, privileged admin, production pipelines), (4) contract minimums, and (5) a recurring reassessment schedule with triggers for re-review. Your exam readiness depends less on the exact template and more on being able to show consistent execution and documented risk decisions over time. ¹

Requirement: Safeguard 15.5 — Assess Service Providers

Goal: Confirm that your service providers’ controls and practices are appropriate for the level of access, data sensitivity, and operational dependency they introduce, and that you can prove you did this assessment and acted on the results. ¹

Plain-English interpretation

You need a formal process to:

• Know who your service providers are (not just “strategic vendors,” but any third party with meaningful access or operational impact).
• Evaluate their security posture before onboarding and periodically after.
• Decide and document: approve, approve with conditions, require remediation, restrict scope, or reject.
• Keep evidence that these steps happen as a normal business process. ¹

A practical test: if an auditor asks, “Show me how you assessed your top service providers and what you did about the findings,” you should be able to produce a consistent record quickly.

Regulatory text

Excerpt (as provided): “CIS Controls v8 safeguard 15.5 implementation expectation (Assess Service Providers).” ¹

Operator translation: CIS expects you to implement an assessment mechanism for service providers. “Assessment” means more than collecting a questionnaire once; it means a documented review tied to risk, with follow-through and recurring evidence capture so you can demonstrate the control operates. ¹

Who it applies to

Entity scope

• Enterprises and technology organizations adopting CIS Controls v8 as a security baseline or as part of an audit/exam program. ¹

Operational scope (what relationships count)

Include any service provider that can materially affect:

• Confidentiality: processes, stores, transmits, or can access your sensitive data.
• Integrity: can change production systems, code, configurations, or security tooling.
• Availability: provides infrastructure or services you depend on to operate (for example, hosting, identity, monitoring, payments).
• Security administration: has privileged access (interactive or API) into your environment.

If you only assess “IT vendors” and ignore outsourced business processes (payroll, customer support platforms, marketing tooling with customer lists), you will miss the intent of 15.5.

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

1) Build the service provider inventory (make it auditable)

Outputs:

• Master third-party register (system of record).
• Ownership fields (business owner, technical owner, contract owner).
• Data classification and access notes.

How to execute:

• Start from AP/spend, SSO app catalog, cloud marketplaces, and contract repositories.
• Normalize naming (one provider, many subsidiaries/products).
• Mark “unknown” fields explicitly; unknown is a remediation item, not a blank.

Control objective: no unmanaged onboarding.

2) Tier providers by risk (so effort matches exposure)

Create a simple tiering matrix your teams will actually use. Example criteria:

• Type of access: none, data-only, admin, network connectivity, production pipeline.
• Data sensitivity: public, internal, confidential, regulated.
• Operational dependency: inconvenience vs business interruption.

Deliverable: a tier score and tier label in the register, with a short rationale.

Audit tip: Tiering must be consistent. Two similar providers should land in the same tier unless you can justify the difference.

3) Define the assessment package per tier (standardize)

Build “assessment bundles” so the process is repeatable:

Low-risk tiers (typical evidence):

• Basic security questionnaire
• Confirmation of MFA and access controls for your tenant/account
• Incident notification commitments in contract

High-risk tiers (typical evidence):

• Independent assurance artifacts (for example, SOC reports if available from the provider)
• Vulnerability management and patching overview
• Secure SDLC or change management practices (if they touch code or integrations)
• Data protection practices (encryption, retention, deletion)
• Subprocessor/fourth-party disclosure
• Business continuity and incident response alignment

Keep the bundle defined in a procedure so different assessors get consistent results.

4) Run assessments at onboarding and at defined triggers

Operationalize two event types:

A. Onboarding (pre-contract or pre-production where possible)

• Require intake submission (service description, integration diagram, data types).
• Complete tiering.
• Collect assessment bundle based on tier.
• Record findings and required actions.
• Approve or reject, with named approver.

B. Reassessment triggers Typical triggers you can enforce operationally:

• Material scope change (new data types, new regions, new integration)
• Privilege change (new admin/API permissions)
• Notified breach affecting your data
• Contract renewal
• Significant control failures observed (outage patterns, audit issues)

5) Decide, document, and track remediation (this is where most programs fail)

For each assessed provider, you need a recorded decision:

• Approved (no material gaps)
• Approved with conditions (constraints like IP allowlisting, reduced scopes, extra monitoring)
• Remediation required (with due dates and owner)
• Exception accepted (with expiration and compensating controls)
• Rejected/offboarded

Minimum documentation for exceptions:

• Risk statement (what could happen)
• Business rationale (why proceed)
• Compensating controls (how you reduce risk)
• Approver (risk owner) and expiration

6) Map 15.5 to documented control operation and recurring evidence capture

CIS implementations tend to fail in audits because teams have a policy but cannot show operation across time. Create a control narrative that ties:

• Intake → tiering → due diligence → decision → reassessment cadence
• Evidence captured each cycle and where it is stored
• Roles and responsibilities (GRC, security, procurement, legal, business owner)

This aligns directly with the recommended control: “Map 15.5 to documented control operation and recurring evidence capture.” ¹

Where Daydream fits naturally: Daydream is useful when you need a single workflow that links the provider record, tiering, due diligence requests, issue tracking, and recurring evidence capture, so your exam package is generated from operational data rather than assembled manually at the end of the year.

Required evidence and artifacts to retain

Keep evidence in a consistent repository with clear naming, versioning, and retention rules. Typical artifacts:

• Third-party register with risk tiering and ownership
• Completed due diligence questionnaires and supporting documents received
• Review notes and assessment summary (what you reviewed, what you concluded)
• Approval records (ticket, workflow log, or sign-off)
• Risk exceptions with compensating controls and expiration
• Remediation tracking (open/closed issues, communications, proof of closure)
• Reassessment schedule and evidence of completed reassessments
• Contract artifacts relevant to security (security addendum, incident notification clause, audit rights if used)

Design your filing so you can answer: “Show me the last assessment and the last reassessment for Provider X” without hunting across email threads.

Common exam/audit questions and hangups

Expect questions like:

• “Show your universe of service providers and how you know it is complete.”
• “How do you determine which providers are critical/high risk?”
• “Pick a high-risk provider: show initial assessment, decision, remediation, and last reassessment.”
• “Where are exceptions documented, and who approved them?”
• “What happens when a provider will not provide assurance artifacts?”
• “How do you handle subcontractors/fourth parties disclosed by the provider?”

Hangups auditors repeatedly focus on:

• Evidence of recurring reviews versus one-time onboarding
• Inconsistent tiering logic
• Approvals that lack a named risk owner

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Inventory built from procurement only	Misses “shadow” tools bought on cards or adopted by IT	Reconcile AP, SSO app catalog, and contract repo into one register
Same questionnaire for every provider	Creates fatigue and low signal	Tier first, then request tier-based evidence
No documented risk decisions	Work happens, but nothing is provable	Require an approval/exception record for every high-risk assessment
Findings tracked in email	No accountability, no closure evidence	Track in a ticketing/GRC workflow with due dates and artifacts
Reassessments ad hoc	Can’t show control operation	Define triggers + cadence and store reassessment outputs

Enforcement context and risk implications

CIS Controls v8 is a framework, not a regulator. The practical risk is still real: service providers frequently become the path for data exposure, ransomware propagation, availability outages, or integrity failures through integrations and privileged access. A weak 15.5 program shows up operationally as unknown access paths, unclear accountability, and inability to demonstrate due diligence to customers, auditors, or business partners. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable program)

• Assign RACI for third-party assessment (GRC owner, procurement partner, security reviewer, business risk owner).
• Create the third-party register structure and populate an initial list from AP/spend and SSO catalogs.
• Define tiering criteria and apply it to the initial population.
• Publish an intake requirement: no new onboarding without a register entry and tier.

Days 31–60 (make it real: run assessments on the riskiest providers)

• Define assessment bundles by tier (questionnaire + required artifacts + contract checks).
• Pilot on the highest-risk providers first and record decisions and exceptions.
• Set up issue tracking for remediation and exception expiration.
• Draft the control narrative for safeguard 15.5 and align evidence locations.

Days 61–90 (operationalize recurring reviews and reporting)

• Establish reassessment triggers and a recurring schedule tied to tier.
• Build reporting: high-risk providers, overdue reassessments, open issues, expiring exceptions.
• Run a tabletop audit: select a sample provider and compile the full evidence package from intake through reassessment.
• Formalize the storage and retention approach so evidence remains accessible across staff changes.

Frequently Asked Questions

Do we have to assess every vendor or only “critical” ones?

Scope should include any service provider that can affect confidentiality, integrity, or availability in a meaningful way. Use tiering to scale effort so low-risk providers get lighter due diligence while high-risk providers get deeper assessment. ¹

What counts as an “assessment” for safeguard 15.5?

An assessment is a documented review of the provider’s security posture appropriate to their risk tier, plus a recorded decision (approve/mitigate/reject) and follow-up on gaps. A one-time questionnaire without risk decisions and tracking is usually not enough to show control operation. ¹

What if a provider refuses to share SOC reports or detailed security evidence?

Document the refusal, record the residual risk, and decide whether compensating controls (reduced scope, additional monitoring, encryption, tenant restrictions) make the risk acceptable. If the risk remains too high, treat it as a sourcing decision and reject or replace.

How do we handle subcontractors and fourth parties?

Require disclosure during due diligence and capture it in the provider record. If a subprocessor has access to sensitive data or critical operations, treat it as part of the risk picture and add contract requirements for notification of subprocessor changes.

How often should we reassess service providers?

Set a cadence by risk tier and define triggers for out-of-cycle reviews (scope changes, privilege changes, incidents, renewals). The key is consistency and evidence that reassessments happen as designed. ¹

What evidence is most persuasive in an audit for 15.5?

Auditors want to see the full chain: inventory → tiering → due diligence artifacts → decision/approval → remediation or exception tracking → reassessment proof. A clean, repeatable evidence package for a sample of high-risk providers is usually decisive. ¹

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8