What Safeguard 8.12 collect service provider logs requires
Safeguard 8.12 asks an enterprise to collect audit logs from its service providers wherever the provider supports it. The events it points to are sign-in and authorization decisions, user management actions, and events where data is created or disposed of. For a regulated organization that runs most of its identity, email, storage and business applications in SaaS and cloud platforms, this means the provider's own records of who did what to sensitive data must reach the organization's monitoring, not stay locked in a vendor console that only the vendor and the auditor are likely to open.
The Safeguard sits in the Data asset class and the Detect security function, and CIS assigns it to Implementation Group 3 only, so it is not part of the IG1 or IG2 baseline. That placement fits its purpose: it extends detection beyond systems the enterprise runs itself, which mainly matters for enterprises with security specialists and sensitive assets exposed to targeted attacks. Before scoping it, check the service provider inventory from Safeguard 15.1 and the secure configuration process from Safeguard 4.1, because the Assessment Specification treats them as prerequisites for measuring 8.12. If those records are incomplete, the organization cannot yet show which providers are in scope.
The difficulty is rarely the decision to collect. Provider log formats differ, field names change between products, and some events are only available in premium tiers or through APIs with separate permissions. Retention is often short on the provider side, so exports must run on a schedule that the organization owns. Export access is the constraint most teams underestimate: the contract may give the enterprise an admin view but not a streaming feed, and the provider may limit how often logs can be pulled. Ask each provider in writing which sign-in, authorization, user management and data lifecycle events it records, how long it keeps them, and which export methods exist, then confirm those answers against the product documentation and a test export before relying on them.
Which providers and log events are in scope for 8.12
Safeguard 8.12 only reaches the providers and events you decide to include, so scoping comes first. The cards below cover which providers count, which event categories the Safeguard names, what "where supported" means in practice, and how to record providers that cannot send logs. The Safeguard applies only at Implementation Group 3, and its measurement depends on two earlier Safeguards.
Start from the provider inventory
Build the list of in-scope service providers from the provider inventory required by Safeguard 15.1 Establish and maintain a service provider inventory, not from memory or from procurement records alone. The assessment specification lists 15.1 as a prerequisite for measuring 8.12 because it usually produces the data the measurement needs. Check that each entry names the service, the tenant or account it runs under, and the business owner who can confirm log access. Providers that hold sensitive data or run critical platforms deserve the first review.
Sign-in and authorization events
Sign-in and authorization events are the first category CIS names for 8.12. For each in-scope provider, confirm whether it records successful and failed sign-ins, multi-factor challenges, session starts, and decisions to grant or deny access to resources. Ask the provider where these events are exposed, such as an audit API, an export feature or a log stream, and which of those feeds can reach your central log store. Record any gap as a scoping exception rather than assuming coverage.
User management events
User management events cover the creation, modification, role change, group membership change and removal of accounts inside the provider. These events show who gained or lost privileges, which matters for detecting unauthorized administrative changes. Map each provider's administrative actions to this category and confirm that the events carry the acting identity, the target account and a timestamp. Accounts that administer the provider should be recorded so their activity can be traced.
Data creation and disposal events
CIS also names events where data is created or disposed of. For a hosted platform, this usually means records of object creation, bulk export, deletion, retention purge and backup removal. Identify which data stores at each provider hold your sensitive data, then confirm whether the provider logs create and delete actions on them. Disposal events are often the hardest to obtain, so ask the provider whether deletions are logged with enough detail to show what was removed and by whom.
What "where supported" requires
The Safeguard applies only where the provider supports sending logs. Support is a fact about each provider and its service tier, so confirm it in the contract documentation or with the provider's account team, not from marketing material. Record the logging feature, the plan that includes it, the delivery method and the event types covered. Note whether logs are retained by the provider and for how long, because this affects how you answer retention questions for the same providers.
Recording providers that cannot send logs
When a provider cannot send logs, record it in the scope register with the reason, the events that are unavailable, the compensating measure (for example, periodic export reviewed by a named owner, or contract terms requiring event access on request) and an owner who revisits the decision on a set schedule. The exception should name the risk it leaves open and who accepted it. Assessors look for this record as evidence that the Safeguard was considered and not silently skipped.
How an assessor measures 8.12 coverage
This table walks through how the CIS Assessment Specification approaches Safeguard 8.12, from its three measures and their combined coverage metric to the evidence an assessor requests and the gaps they most often record. Read it as a guide to what to prepare, not as a copy of the specification, which remains the authoritative source for the measurement itself.
| Element | What the assessor looks for | Common finding |
|---|---|---|
| Combined metric | The three measures for 8.12 combine into one coverage metric that shows how much of the in-scope service provider footprint sends logs to the organization. | Coverage is reported as a yes or no for the whole environment, with no breakdown by provider. |
| Input: provider inventory | A list of service providers that hold or process organizational data or run business functions, usually produced under Safeguard 15.1, which the specification names as a prerequisite. | The provider list is missing SaaS identity, cloud or data platforms, so their logs are never in scope. |
| Input: provider log configuration | Evidence that each provider's audit or activity logging is enabled, and which event types it records, such as sign-ins, authorization decisions, user management and data creation or disposal. | Logging is assumed enabled because the provider offers it, but no configuration export or screenshot exists. |
| Input: log samples | Recent log entries from each provider showing that the expected event types actually reach the organization's collection point. | Samples are old, from a test tenant, or show only one event type from a provider that should record several. |
| Test approach | Compare the inventory against collected log sources and check whether each in-scope provider that supports log collection is sending the events named in the Safeguard. | Providers that support log export are excluded from scope without a documented reason or a supporting statement from the provider. |
| Evidence requested | Current inventory, provider log settings, a collection pipeline or SIEM source list, and dated log samples, together with the process that records exceptions. | Evidence predates the assessment period or cannot be tied back to the specific provider named in the inventory. |
| Exceptions | Documented justification for providers where logs are not available, with the compensating monitoring or contractual step the organization took instead. | Exceptions are recorded informally, with no owner, review date or contractual basis. |
| Reference mapping | The CIS Controls Navigator maps 8.12 to NIST SP 800-53 Rev. 5 AU-2 as a reference point only; it does not change how the CAS measures 8.12. | Teams treat the AU-2 mapping as the test itself and prepare evidence for AU-2 without checking the CAS measures. |
How to implement 8.12 in five steps
This sequence turns Safeguard 8.12 from a statement of intent into a documented, centrally collected and verified set of service provider logs, with every gap either closed or formally accepted. Each step produces an artifact an assessor can inspect.
Confirm the service provider inventory from 15.1
Start from the service provider inventory that Safeguard 15.1 requires, because the assessment specification treats it as a prerequisite for measuring 8.12. The security or IT governance lead confirms which providers hold sensitive data or run critical platforms, since those are the providers whose logs matter most. Output: a reviewed list of in-scope providers, each with a named business owner and the systems or data it touches. Done when every provider on the list maps to at least one logged business process.
Record the event categories and collection method per provider
For each in-scope provider, record which of the CIS example event categories it exposes: sign-in and authorization events, user management events, and events where data is created or disposed of. Note how each is available, such as a native audit export, an API, or a connector maintained by the provider or a third party. Confirm retention and access terms with the provider, since these vary and are not set by CIS. Output: a provider log matrix with one row per provider and category. Done when each cell states available, partially available, or not available, with the collection method.
Enable and route provider logs to the central store
Turn on the provider-side audit features that the matrix shows are available, then route the events into the central log store used for Safeguard 8.9. Administrators of each provider tenant or account usually make these changes, while the implementation team builds and tests the connectors or export jobs. Confirm that timestamps are normalized against the time sources from Safeguard 8.4 so events correlate across systems. Output: working ingestion pipelines and a configuration record for each provider. Done when a test action in each provider produces an event in the central store.
Verify coverage with sampled events per category
Test whether the events arrive for each category the matrix marks as available. Generate or select a sample of real sign-in, authorization, user management and data create or dispose events, then search for them in the central store and confirm the fields needed for investigation are present. This sampling evidence is what the assessment specification's three measures and coverage metric look for, so keep the queries, sample dates and results. Output: a coverage test record showing, per provider and category, the events sampled, the events found and any gaps. Done when every available category shows the expected events in the store.
Document exceptions with owners and review dates
Record every category that is not available, only partially available, or not collected, with the reason, the compensating measure if any, a named owner and a review date. Typical exceptions include providers with no audit export or logs that the provider holds without customer access. Put these into the service provider management process so contract renewals and provider reviews can request better logging. Output: an exception register approved by the risk owner. Done when each gap has an owner, a rationale and a scheduled review, and the register is linked to the 15.1 provider records.
How to collect provider logs when the provider offers no feed
Safeguard 8.12 only asks for service provider logs where the provider supports providing them, so the first decision is whether a feed exists at all. For each provider in the service provider inventory that Safeguard 8.4 and 15.1 work produces, record which of the three collection patterns is available: a native audit log export that an administrator downloads or schedules, an API pull that a job calls on a fixed schedule and writes to your log store, or a vendor-supplied connector that forwards events into your SIEM. Check the vendor's own documentation and your contract for the event types the Safeguard names: sign-in and authorization decisions, user management changes, and events where data is created or disposed of. Confirm the retention the provider keeps on its side, because a feed that rolls off after a short window will not support the review and retention Safeguards 8.10 and 8.11 expect.
Where a provider supports only a partial feed, collect what exists and document the gap for each missing event type rather than treating the whole provider as out of scope. Export and API jobs should record their own success or failure, and a failed pull should raise an alert, because a silent gap is harder to explain to an assessor than a known one. Store pulled logs in the same centralized location and under the same retention rules as your other audit logs, and keep the query or export configuration in version control so the collection method can be shown to be stable over time. Open-source tooling can run the scheduled pulls and forwarding, but the choice of product and connector is a separate decision from the collection design.
When a provider cannot supply a feed for an event type, the Safeguard's own qualifier becomes part of the evidence. Keep the provider's written statement that the log is not offered, the relevant contract or service terms, the date you checked, and a record of the compensating step you took, such as scheduled reports of user lists, periodic review of administrator actions in the provider console, or contractual notice of security-relevant changes. Ask the provider in writing whether logs can be made available and file the answer. This is a judgment about your own environment and is not a substitute for the assessor's view, so confirm with your auditor how they will test unsupported entries before relying on them.
Evidence that satisfies 8.12 and how to keep it current
Safeguard 8.12 is measured through coverage, so the evidence has to show which service providers send logs, which event categories arrive, and where gaps are owned. The cards below cover the artifacts an assessor can trace from a provider to a central store, and the routine checks that keep them accurate between audits.
Provider inventory with log capability
Export the service provider inventory from Safeguard 15.1 and add a column for each provider stating whether it offers sign-in, authorization, user management and data create or dispose logs, and how those logs are delivered. This is the denominator for coverage. Check that every provider holding sensitive data or running critical processes appears, because an omitted provider silently inflates the coverage figure.
Log forwarding configuration exports
Keep dated exports or screenshots of each provider's audit or activity log settings showing that streaming, export or API-based forwarding is enabled and pointed at the central store. Record the account or tenant identifier next to each export so an assessor can match it to the inventory. Re-export after any administrative change to the provider, since a tenant reconfiguration is the most common reason forwarding quietly stops.
Sample events from each category
For each provider, capture a small set of real events from each category (sign-in, authorization decision, user management, and data creation or disposal) as they appear in the central log store, with the query used to retrieve them. Redact personal data but keep timestamps, source identifiers and event types. Samples prove the logs arrive and are parseable, which a configuration screenshot alone cannot show.
Coverage register with exceptions
Maintain a register listing each provider, the categories it supports, the categories received, and an owner for each gap. Where a provider does not support a category, record the reason and the compensating control, such as periodic export or a contractual report. The wording "where supported" in the Safeguard means unsupported gaps are acceptable only when they are documented and accepted by a named owner.
Contract clauses granting log access
Keep the executed clauses that grant the organization the right to receive audit logs, define the retention the provider keeps, and state the delivery method and timeline. Procurement often holds these, so ask for them during onboarding rather than at audit time. Where a provider refuses log access, the clause or its absence explains the exception in the register.
Quarterly coverage checks
Between audits, run a quarterly check that compares the inventory, forwarding exports and central store ingestion for each provider, then updates the register and dates the results. Assign a named owner, and treat a provider that has stopped sending events for a set period as an exception to escalate. Retain each quarter's check record so the assessor sees the measurement repeated over time, not a single snapshot prepared for the audit.
What meeting 8.12 costs in money and effort
The first cost is configuration work that happens once for each service provider. Your organization pays its own staff, or a partner it hires, to find out which provider platforms expose sign-in, authorization, user management and data creation or disposal events, to enable those events in each provider's administration console, and to confirm the events arrive in a readable form. Connector or integration engineering is the second one-time component. Where a provider has no native export, someone must build a pull job, webhook receiver or parser, then test it and document it. The Safeguard's prerequisites in Safeguards 4.1 and 15.1 also imply one-time work on the secure configuration process and the service provider inventory if those records do not already exist.
- Provider discovery: Confirming which providers support log export, which events they can produce and at what level of detail.
- Native configuration: Turning on audit or activity logging in each provider's console and recording the settings in the secure configuration process.
- Connector build: Writing or configuring the ingestion path for providers without a standard export, including parsing and field mapping.
- Test and documentation: Proving each event type arrives and recording where it is stored and who can read it.
- Prerequisite gaps: Completing the service provider inventory and configuration records if they are missing.
Before accepting a quote, ask the provider for a written list of the event types each platform can export and for the connector method for each one.
Recurring costs continue for as long as the Safeguard is in force. The largest is usually log storage and SIEM ingestion, because provider logs add volume to a tool that is often priced or sized by data ingested or retained. Your organization pays the storage provider and the SIEM vendor, and any managed service that monitors the feed. Connector upkeep is also recurring, because provider APIs, export formats and event names change. Someone must watch for those changes and repair pipelines when they break.
- SIEM ingestion and storage: Recurring charges based on the volume of provider events kept and searched.
- Connector maintenance: Repairing ingestion jobs after provider API or schema changes.
- Platform licensing: Any fees for provider tiers that include the audit or activity logs you need, which can differ from the tier you already pay for.
- Ongoing coverage checks: Periodic confirmation that every in-scope provider still sends the required event types.
- Retention and review staff time: The analyst effort that follows from provider events entering the review process under Safeguard 8.11.
Ask the quote to separate ingestion, storage and connector maintenance so you can see which line changes when event volume grows.
Costs for Safeguard 8.12 rise with the number of providers in scope, the volume of events each one produces and the length of time you retain them. A provider with few sign-in and administrative events is cheap to cover. A provider that logs every data read is expensive to ingest and store. Retention is a multiplier: keeping provider logs for longer increases storage and search costs even when the event count stays flat. Costs fall when providers offer standard exports, when your existing SIEM already accepts the format and when the scope of data events is limited to the data classes your service provider inventory marks as sensitive.
- Number of providers: Each additional in-scope provider adds configuration, connector and checking work.
- Event volume: High-volume data events drive ingestion and storage charges more than sign-in events do.
- Retention period: Longer retention multiplies storage and search costs for every provider.
- Standard exports: Providers that expose a standard export or streaming feed reduce connector engineering.
- Existing SIEM: A SIEM that already parses the format avoids new parsers and dashboards.
Ask how each driver was assumed in the quote, including the event types and retention period, so you can compare quotes on the same basis.
Assessors measure Safeguard 8.12 against the CIS Controls Assessment Specification, which defines three measures combined into a coverage metric. An independent assessor will therefore sample providers, pick event types and test whether the logs exist and are complete. Preparing for that sampling takes effort inside your organization: producing the provider list, the enabled-event evidence and the records showing each feed was tested. The assessor's own fees depend on the assessor's scope and rate, which the assessor sets. DeployOpen prepares systems and evidence but does not issue assessment results or attestations.
- Sample preparation: Assembling provider lists, event-type lists and configuration screenshots or exports for the sample.
- Evidence of arrival: Showing logs from each sampled provider in the SIEM for a stated period.
- Gap explanations: Writing down providers that do not support export and the compensating method used.
- Assessor fees: Set by the assessor's own scope, so request a written scope before comparing quotes.
- Re-testing time: Effort to fix findings and present the corrected evidence to the assessor.
Ask the assessor to state the sample size and the period of evidence it expects before you commit to an engagement.
A useful quote for Safeguard 8.12 lists providers, event types and retention as separate inputs, and it separates one-time work from recurring charges. DeployOpen plans and implements in fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so the quote follows from the written scope. Ask for the same structure from any partner, and confirm which items you will own internally.
- Provider list: Each in-scope provider, its service type and whether it holds sensitive data.
- Event catalogue: The sign-in, authorization, user management and data create or dispose events covered for each provider.
- Connector method: Native export, API pull, webhook or manual process, with the effort for each.
- Recurring line items: Separate charges for ingestion, storage, connector upkeep and coverage checks.
- Acceptance criteria: The evidence that shows each provider feed is live and tested.
Confirm the assumptions behind each line with the partner in writing before signing, since changes to scope usually change the recurring cost.
Where organizations fall short on 8.12
Most gaps under Safeguard 8.12 come from the same weakness: nobody has a complete, current view of which service providers hold the organization's data or run its platforms. Each card below names a gap an assessor is likely to find, and the closure action that turns it into evidence.
No current provider inventory
Without a list of service providers, no one can say which ones support log export or which events matter. The assessment specification treats the service provider inventory from Safeguard 15.1 as a prerequisite, so a missing or stale list blocks measurement before logs are even discussed. Closure: build the inventory from accounts payable, single sign-on application lists and cloud subscriptions, then assign each provider an owner and a data classification. Confirm the inventory is reviewed on a set cycle.
Logs enabled but never forwarded
Many SaaS and cloud platforms let administrators turn on audit logging, yet the events stay inside the provider console and never reach the organization's log platform. An assessor will ask where the events are stored and who can query them, and a console-only setting rarely answers that. Closure: for each provider that supports export, configure a forwarding path to the central log store, then test it by generating a sign-in event and confirming it arrives.
Only sign-in events collected
Teams often start with authentication logs because they are easy to export, and stop there. Safeguard 8.12 names more event types: authorization decisions, user management changes, and events where data is created or disposed of. An assessor compares what is collected against what each provider offers. Closure: map each provider's audit categories to the four example types and record which ones are forwarded.
No record of unsupported decisions
Where a provider cannot export a given event type, the Safeguard still needs a documented outcome. An empty field in a spreadsheet looks like neglect, not a justified exception. Closure: for every gap, record the provider's name, the event type, the reason the provider does not support collection, the compensating control (such as a periodic report or a contract clause), and the person who accepted the risk. Confirm the decision is revisited when the provider releases new features.
Logs without retention or review
Forwarded provider logs that no one reads, or that expire after a short vendor default, do not show that the Safeguard works in practice. Control 8 links collection to retention and review, and provider logs should follow the same retention rules as internal sources. Closure: apply the organization's retention period to provider log indexes, assign reviewers for high-impact events such as privilege grants, and keep a sample of review records as evidence.
No provider access terms in contracts
If a contract does not require the provider to supply logs, collection depends on goodwill and on features that can change without notice. Procurement teams often sign before security reviews the logging terms. Closure: add a clause that names the event categories, export method and retention expected, and ask legal and procurement to confirm that renewal reviews check these terms against what the provider actually delivers.
Questions buyers ask about 8.12 cost, effort and scope
How much effort does Safeguard 8.12 take for a small SaaS estate?
The effort depends on how many provider services you run and how many of them expose logs you can export. Start by listing each service provider in your inventory, then record which sign-in, authorization, user management and data create or dispose events each one can send. Services that support log export or streaming need a configured feed and a place to store the events. Services that offer only a web console need a documented manual export or a stated reason for not collecting. Effort is mostly one-time setup and per-provider validation, followed by light recurring checks that feeds still arrive. The Assessment Specification treats Safeguards 4.1 and 15.1 as prerequisites, so expect some time spent on the configuration process and the provider inventory before collection work starts. Ask any partner to size the work from your provider list.
Is IG3 required to meet Safeguard 8.12?
Safeguard 8.12 is assigned to Implementation Group 3 only, so organizations that stop at IG1 or IG2 are not measured against it. CIS defines IG3 as the group for enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. Whether you must adopt it depends on your contracts, your regulator and your risk profile, not on size alone. Some frameworks that CIS maps to, such as those in the Navigator, may require equivalent logging of provider activity, so check each mapping against the framework you are obligated to meet. Confirm your obligations with your compliance lead before scoping.
Can our own staff do Safeguard 8.12, or do we need a partner?
Your staff can do it if they have access to each provider's admin settings, your log platform and the authority to change configurations. A partner is useful when many providers, several log formats or a regulated evidence requirement make the work heavy. Either way, the organization owns the control and the evidence. An implementation partner prepares feeds, parsing, retention and documentation, while only an independent auditor issues an assessment result. Fixed-scope work with a written list of providers and deliverables makes it easier to compare internal and external options. DeployOpen plans and implements self-hosted platforms inside your own environment, so the logs stay in your infrastructure.
How long does a provider log integration take to set up?
No duration figure is supplied for this work, so treat any timeline as something to agree in writing. The main drivers are the number of providers, whether each one offers native log export or streaming, the format and volume of events, and the level of parsing needed for your log platform. Providers with standard export options usually take less time than those that need custom API calls or manual retrieval. Access approvals from the provider and internal change windows also affect the schedule. Ask for a plan that lists each provider, the event types covered and the acceptance checks you will use.
Does a provider's SOC 2 report satisfy Safeguard 8.12?
No. A provider's SOC 2 report describes that provider's own controls, and it does not replace collecting logs in your environment. Safeguard 8.12 asks your organization to collect logs from its service providers where the provider supports it, covering sign-ins, authorization decisions, user management and data creation or disposal. A report can help you assess provider risk under Control 15, and it may show that the provider has logging controls of its own. It does not give you access to the events that happened in your tenant. Keep the report as third-party assurance, and keep the collected logs as the evidence for 8.12.
What must our team supply before a 8.12 engagement starts?
Before work starts, the team should supply the inputs the measurement depends on:
- The service provider inventory from Safeguard 15.1, with owners and the services each provider runs for you
- The secure configuration process from Safeguard 4.1, showing how provider settings are reviewed
- Administrative access or named contacts for each provider's audit log settings
- The log platform or SIEM where events will be stored, with its retention setting
- The list of events you require for each provider, mapped to sign-ins, authorization, user management and data create or dispose actions
Ask for a written scope that names these inputs and the acceptance checks. Confirm with each provider whether the events you need are included in your plan.
What does Safeguard 8.12 cost and what drives the price?
No price figure for this Safeguard is supplied, and DeployOpen does not publish prices. Costs come from three places: internal staff time for configuration and review, any licensing your providers or log platform charge for log export or storage, and fees for an implementation partner, which follow from a written scope. Costs that recur include log storage, ongoing feed monitoring and periodic review of provider settings. Costs rise with more providers, more event types, higher log volume and stricter retention. Ask every quote to itemize one-time setup, recurring operations, provider licensing and what is excluded.
How DeployOpen scopes and prepares 8.12 evidence
DeployOpen works on Safeguard 8.12 as an implementation partner: we help map which service providers can send logs, configure collection into the logging platform your organization runs, and document the evidence. Your organization owns the Safeguard, and only an independent assessor or certification body issues any report or certificate.
How we scope
- Written scope lists the service providers in your inventory and the sign-in, authorization, user management and data create or dispose events to collect.
- Scope records which providers support log export and which do not, so gaps are documented rather than assumed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We configure log collection from supported provider sources into your self-hosted, open-source logging stack inside your own infrastructure.
- We confirm each event type arrives with timestamps that align with the time synchronization configuration from Safeguard 8.4.
- We test that collected events are retained and searchable, then record the results for the coverage measure.
How we hand over
- You receive documentation of the provider log sources, collection configuration, event types and their owners.
- Handover includes test records showing sample events from each collected provider, for your assessor to review.
- Gaps for providers without log export are listed with options your team must decide on, such as contract changes or compensating monitoring.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover updating collection when a provider changes its log formats or adds new event types.
- Confirm with your assessor which evidence format and sampling they expect before the engagement starts.
