Safeguard 8.12: Collect Service Provider Logs

To meet the safeguard 8.12: collect service provider logs requirement, you must identify your in-scope third parties, contract for log access, and consistently ingest their security-relevant logs into your logging platform so you can detect, investigate, and prove activity affecting your environment. Operationalize it with a clear scope, standard integrations, and recurring evidence capture. (CIS Controls v8; CIS Controls Navigator v8)

Key takeaways:

• Scope first: define which third parties and which log types are mandatory, tied to your critical business services. (CIS Controls v8)
• Contractualize access: require log availability, retention, and delivery method in third-party agreements. (CIS Controls v8)
• Prove operation: keep repeatable evidence that logs are collected, reviewed, and usable for investigations. (CIS Controls Navigator v8)

Safeguard 8.12 focuses on a common blind spot: activity that happens “inside” a service provider’s stack can still impact your data, your users, and your incident response timeline. If you rely on SaaS, cloud infrastructure, managed security services, payment processors, customer support platforms, or any outsourced IT function, your ability to detect and investigate events depends on whether you can access and retain the right logs from those service providers.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat service provider logs as a requirement you can enforce through (1) scope and data classification, (2) third-party contracting standards, and (3) technical onboarding into your SIEM or centralized logging system. Your auditors will not accept “the provider has logs” as equivalent to “we collect them.” They will look for evidence that logs are consistently available, ingested, and usable.

This page gives requirement-level implementation guidance you can hand to Security Operations, IT, Procurement, and third-party risk teams, then track to completion with recurring evidence capture aligned to CIS Controls v8. (CIS Controls v8; CIS Controls Navigator v8)

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 8.12 implementation expectation (Collect Service Provider Logs).” (CIS Controls v8; CIS Controls Navigator v8)

Operator interpretation (what it means in practice):

• You must collect logs generated by service providers that support your environment or handle your data, and make those logs available for detection and investigation. (CIS Controls v8)
• “Collect” should be treated as your control, not the provider’s feature. If logs exist but you cannot retrieve them reliably, normalize them, or retain them according to your needs, you are not meeting the intent. (CIS Controls Navigator v8)

Plain-English interpretation

You rely on third parties to run critical systems and store or process sensitive information. Safeguard 8.12 expects you to bring relevant service provider logs into your logging program so you can answer basic incident questions quickly:

• What happened?
• Who did it?
• What was accessed or changed?
• When did it occur?
• Is the activity still ongoing?

This is a detection-and-investigation control, but it also supports third-party oversight: logs are how you verify that a provider’s actions match tickets, approvals, and SLAs. (CIS Controls v8)

Who it applies to

Entities

• Enterprises and technology organizations adopting CIS Controls v8. (CIS Controls v8)

Operational context (most commonly in scope)

Treat the following as in-scope when they can affect confidentiality, integrity, or availability of your systems or data:

• Cloud service providers (IaaS/PaaS) where you administer workloads, networks, identities, or storage
• SaaS hosting regulated or sensitive business data (HR, CRM, ticketing, finance, collaboration)
• Managed service providers (MSPs) and managed security service providers (MSSPs)
• Identity providers and SSO platforms
• Payment, messaging, customer engagement, and data pipeline providers
• Outsourced admin/support functions that have privileged access

A practical scoping rule you can use: if a third party has admin access, processes sensitive data, or is a dependency for a critical business service, you should be collecting their relevant logs. (CIS Controls v8)

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

1) Build the “service provider log scope” list

Create a register of third parties and mark which are in-scope for log collection. Minimum fields:

• Third party name and service
• Data types handled and system criticality
• Access model (end-user, service account, privileged admin, API)
• Native log types available (audit logs, access logs, admin logs)
• Log access method (API, export, webhook, SIEM connector)
• Constraints (tier/license requirements, regional limits)

Deliverable: Service Provider Logging Scope Register owned by GRC with Security as approver. (CIS Controls v8)

2) Define the minimum log types you require

Standardize requirements so Procurement and Security don’t negotiate from scratch each time. For most organizations, minimum categories include:

• Authentication and access: sign-ins, MFA events, token issuance, session activity
• Administrative actions: role changes, policy changes, configuration changes
• Data actions (where available): export, download, share, permission changes
• Security events: detections, alerts, quarantine actions, blocked events
• API activity: key creation/rotation, failed auth, high-volume calls

Make this a one-page standard: “Service Provider Logging Baseline.” (CIS Controls v8)

3) Contract for log access and retention (make it enforceable)

Add contract language (MSA/DPA/security addendum) that requires:

• Log availability for the required categories
• A delivery method you can operate (API access, integration, scheduled export)
• Retention commitments or a guarantee that you can export for your own retention
• Time synchronization expectations (timestamps with time zone/UTC)
• Support obligations during investigations (log extracts, chain-of-custody support where applicable)

If a provider will not provide logs, treat it as a risk decision with compensating controls and documented acceptance. (CIS Controls v8)

4) Implement technical collection into your logging platform

Pick one standard per provider:

• Native SIEM integration/connector (preferred when stable and supported)
• API polling into a log pipeline
• Event streaming/webhooks
• Scheduled export to storage you control, then ingest

Operational requirements you should enforce:

• Unique source identification for each provider and environment/tenant
• Parsing/normalization so analysts can query consistently
• Alert routing for high-risk events (privilege changes, suspicious sign-ins)

Deliverable: Integration runbook per provider (setup steps, credentials handling, failure modes). (CIS Controls Navigator v8)

5) Add monitoring for log pipeline health

This is where teams fail in audits: integrations silently break. Track:

• Last log received timestamp by source
• API errors and throttling
• Volume anomalies (sudden drops/spikes)
• Credential/secret expiration

Create an operational alert: “No logs from Provider X” routed to the owning team. (CIS Controls v8)

6) Prove you can use the logs (tabletop + investigation workflow)

Run a simple investigation test for each critical provider:

• Query a known admin change or login event
• Validate timestamps, user identity mapping, and event details
• Confirm you can export a bounded time window for evidence

Update incident response procedures to include: “Pull provider audit logs” as a required step when the provider is implicated. (CIS Controls v8)

7) Set recurring evidence capture (assessment-ready operations)

Map safeguard 8.12 to a control in your GRC system with recurring evidence, such as:

• Quarterly list of in-scope providers with onboarding status
• Screenshots or exports showing log sources active
• Sample log events for each provider
• Tickets showing remediation of broken ingestion

Daydream can help here by turning the requirement into a control workflow with scheduled evidence requests, attestation, and an audit-ready evidence packet aligned to CIS v8 language. (CIS Controls v8; CIS Controls Navigator v8)

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Governance & scope

• Service Provider Logging Scope Register
• Service Provider Logging Baseline (required log categories)
• Risk acceptances and compensating controls for exceptions

Contracting

• Security addendum clauses covering log access and support
• Any provider documentation confirming log availability (tier/feature notes)

Technical operation

• Architecture diagram of log ingestion path (provider → pipeline → SIEM/storage)
• Per-provider integration runbooks
• Monitoring evidence for pipeline health (dashboards, alerts, tickets)
• Sample raw log files/events and normalized fields
• Change records for connector updates or credential rotations

Assurance

• Investigation/test records demonstrating logs are searchable and exportable
• Incident records showing provider logs were used when relevant

Common exam/audit questions and hangups

Expect auditors to ask:

• “Which third parties are in scope, and why?”
• “Show me that Provider X logs are collected, not just available.”
• “What happens if ingestion fails?”
• “How do you ensure logs are complete and time-aligned?”
• “How do you handle providers that only retain logs for a short period?”

Hangups that trigger findings:

• No formal scope, only ad hoc integrations
• Contracts don’t guarantee log access, or only mention “reports”
• Collection exists, but no monitoring of pipeline failures
• Logs are collected but not accessible to incident responders (permissioning gaps)

Frequent implementation mistakes (and how to avoid them)

1. Treating “SaaS audit logs” as optional.
   Fix: classify core SaaS as production systems and require audit logging as a go-live gate. (CIS Controls v8)

2. Relying on screenshots instead of data ingestion.
   Fix: require machine-ingested logs for critical providers; allow screenshots only for low-risk tools with documented rationale. (CIS Controls Navigator v8)

3. No exception process for providers that can’t supply logs.
   Fix: create a formal exception with compensating controls (stricter access, reduced permissions, alternative monitoring) and an expiry date. (CIS Controls v8)

4. Ignoring identity mapping across tenants.
   Fix: standardize user identifiers (email/UPN), capture admin role changes, and document how provider identities map to internal identities. (CIS Controls v8)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard. Practically, failure to collect service provider logs increases:

• Detection gaps for account takeover, privilege misuse, and data exfiltration inside third-party platforms
• Investigation delays because you must request logs during an incident under time pressure
• Third-party oversight weaknesses because you cannot verify provider actions independently

Treat safeguard 8.12 as a resilience requirement: it reduces single points of failure in your visibility when the event happens outside your perimeter. (CIS Controls v8)

Practical 30/60/90-day execution plan

First 30 days (establish control and scope)

• Publish the Service Provider Logging Baseline (required log categories).
• Build the Service Provider Logging Scope Register and get Security sign-off.
• Identify top critical providers where lack of logs would block incident response.
• Draft standard contract language for log access and provider support. (CIS Controls v8)

Days 31–60 (onboard critical providers and evidence)

• Implement collection for the highest-risk providers first (privileged access, sensitive data, critical services).
• Create per-provider runbooks and assign system owners.
• Add pipeline health monitoring and ticketing for ingestion failures.
• Capture first-round evidence: log source active, sample events, monitoring dashboard. (CIS Controls Navigator v8)

Days 61–90 (expand coverage and operationalize)

• Expand onboarding to remaining in-scope providers; document exceptions.
• Run investigation tests and update incident response playbooks to reference provider logs.
• Start recurring evidence capture cadence in your GRC workflow (e.g., quarterly evidence packets) and align to CIS v8 assessments.
• If you use Daydream, configure automated evidence requests to system owners and attach artifacts to the safeguard record for audit readiness. (CIS Controls v8; CIS Controls Navigator v8)

Frequently Asked Questions

Which service providers should be in scope first?

Start with third parties that have privileged admin access, host sensitive data, or support critical business services. If a compromise there would trigger an incident response, put them in your initial scope. (CIS Controls v8)

What if the provider only offers audit logs on an expensive tier?

Treat log access as a security requirement in procurement: either buy the tier, select an alternative provider, or document a risk acceptance with compensating controls. Auditors will want to see the decision record and rationale. (CIS Controls v8)

Do we have to send all provider logs to a SIEM?

CIS 8.12 is about collection and availability for detection/investigation; a SIEM is the common path, but centralized storage with reliable export/search can work if operations can use it during incidents. Document the mechanism and prove it works with evidence. (CIS Controls v8)

How do we prove “collection” during an audit?

Show an in-scope provider list, the integration configuration or connector status, sample raw events with timestamps, and monitoring evidence that alerts on ingestion failure. Pair that with a runbook and a test record showing the logs are searchable. (CIS Controls Navigator v8)

What do we do with providers that cannot produce meaningful logs?

Document the gap, reduce the provider’s access where possible, add compensating monitoring on your side (network, identity, data access controls), and time-box an exception with an owner and remediation plan. (CIS Controls v8)

Who should own safeguard 8.12 operationally?

GRC should own scope, policy, and evidence; Security Operations should own ingestion and monitoring; Procurement/Legal should own contract terms. Name a single accountable control owner who can reconcile gaps across teams. (CIS Controls v8)