Safeguard 8.7 Collect URL request audit logs: evidence

What Safeguard 8.7 requires for URL request logs

If an assessor or customer has asked for evidence of CIS Safeguard 8.7, the short answer is this: you must collect URL request audit logs from enterprise assets where that is appropriate and the asset supports it, and you must be able to show that those logs exist and are usable. The Safeguard sits in Control 8, Audit log management. In v8.1 it belongs to the Data asset class and the Detect security function, and it is assigned to Implementation Groups 2 and 3 only, so an IG1 enterprise does not carry it as a baseline requirement. Its purpose is visibility into web activity, so that the security team can detect suspicious browsing, command and control traffic, data exfiltration to web destinations and malicious downloads, and can reconstruct what a user or system requested during an investigation.

The usual difficulty is not switching on a web proxy or firewall log. It is deciding which assets are appropriate and then proving the logs are complete. Appropriateness depends on your asset inventory and data classification: endpoints used for general browsing, servers that make outbound web requests, and privileged administrative workstations carry different risk. Your organization owns that decision and should document the reasoning in the audit log management process, and the CIS Controls Assessment Specification expects the enterprise asset inventory (Safeguard 1.1) and the secure configuration process (Safeguard 4.1) to be in place first, because they produce the data the measurement relies on. Confirm with your assessor how they will test scope before you finalize the asset list.

To evidence the Safeguard, collect a set of artifacts that show configuration, coverage and retention together. Keep the list of in-scope assets with the rationale for each exclusion, configuration exports from the logging sources (for example, the admin_audit app's logfile_audit setting for Nextcloud, or IDS and proxy log output), a sample of recent URL request records traced back to named assets, and the destinations and retention period for those logs. The assessment specification measures three items combined into a configuration coverage metric, so a single screenshot is weak evidence. Platforms such as OPNsense can forward Suricata EVE JSON records, including HTTP transactions, to a log management tool, but a self-hosted platform only produces evidence once you confirm that the HTTP event type is enabled, that records reach the central store, and that the coverage gap list is kept current. Confirm each capability in your own environment rather than assuming it from the product name.

Which assets and teams fall under URL request logging

Safeguard 8.7 applies only where URL logging is appropriate and the asset supports it, so scoping is the first decision that changes the work. The cards below cover the asset types that usually qualify, the Implementation Group that applies, and the inventory and configuration data that the assessment specification relies on.

Web gateways and proxies

Forward proxies and secure web gateways see every outbound HTTP and HTTPS request that passes through them, which makes them the most direct source of URL request logs for enterprise web traffic. Check whether the device records full URLs or only domains, whether TLS inspection is in place, and whether logs leave the device in a form your log management tools can ingest. Confirm these capabilities with the vendor or your own configuration before counting the device as in scope.

Endpoints with browsers

Managed workstations and laptops generate much of the web activity an organization needs to investigate, including activity from remote users who never cross the office gateway. Logging on endpoints depends on the browser, the operating system and the endpoint management tooling, so each browser fleet needs its own check. Record which endpoint builds support URL logging and which do not, because the assessor will ask for that list.

Firewalls with inspection

Next-generation firewalls and intrusion prevention systems can record application and web session data, which may serve as URL request logs when the device exposes it. OPNsense, for example, runs Suricata, whose EVE output records HTTP transactions in JSON that can be sent to syslog. Confirm which protocol fields your firewall exports, since HTTPS URLs are often hidden without decryption.

Which Implementation Group applies

Safeguard 8.7 belongs to Implementation Groups 2 and 3, not IG1, so an organization that has adopted only the IG1 baseline does not owe this Safeguard yet. Organizations that hold sensitive information or operate with more complexity should confirm their IG level with the CIS Controls documentation before scoping. Record the decision in writing, because an assessor will test whether the scope matches the chosen IG.

Inventory data from Safeguard 1.1

The CIS Controls Assessment Specification lists the enterprise asset inventory from Safeguard 1.1 as a prerequisite for measuring Safeguard 8.7, because the inventory defines the population the coverage metric is calculated against. Without a current inventory, the team cannot show which assets were excluded and why. Link each web-facing asset in the inventory to its logging status and owner.

Secure configuration data from Safeguard 4.1

Safeguard 4.1 covers the secure configuration process, and the assessment specification treats its output as a prerequisite for measuring URL logging. Configuration baselines show whether URL logging is enabled, where logs are sent and which settings were approved. Any asset that cannot support URL logging must have a documented justification and an approved exception, not a silent omission from the scope.

How an assessor tests URL request logging

This table walks through how the CIS Controls Assessment Specification approaches Safeguard 8.7, from the three measures that feed one configuration coverage metric to the evidence an assessor asks for and the gaps that most often cause findings. Read it as a preparation checklist: each row names what the assessor looks for and what your team should be able to show before the assessment starts.

Assessment element	What the assessor checks	Evidence to prepare
Measures and metric	Three measures are combined into one configuration coverage metric for Safeguard 8.7, so both the scope of assets and the quality of the logs count toward the result.	A written measurement approach that maps each measure to a data source and states who owns the calculation.
Prerequisite inputs	Safeguards 1.1 (asset inventory) and 4.1 (secure configuration process) typically supply the asset list and configuration baseline the measurement depends on.	The current enterprise asset inventory and the documented secure configuration process, dated and version controlled.
Log source configuration	Whether URL request logging is enabled on in-scope assets where the asset supports it, and whether the setting matches the documented logging requirements.	Configuration exports or screenshots from each in-scope system, with the setting name, value and the date it was checked.
Sample exports with URL fields	Whether a real sample of records shows the requested URL, the requesting asset or user, the time and the outcome, not only a service heartbeat.	Redacted sample exports from a recent period, with a note on which fields are present and which are absent.
Asset-to-log coverage listing	Whether every in-scope asset that supports URL request logging appears in the coverage listing, and whether each entry points to a log destination.	A reconciled list that matches the asset inventory to the logging destination for each asset, with the exclusion rationale for any gap.
Unexplained coverage gaps	Assets that are in scope and supported but missing from the logging listing, with no documented reason. This is one of the most common reasons for a finding.	A gap register that records each excluded asset, the reason it is unsupported or out of scope, and the approval owner.
Logs that lack request detail	Log entries that show a connection or a generic event without the full URL or request context, which limits detection and investigation.	Evidence that the logging format captures the full request path, method and status, tested against a known sample request.
Consistency over time	Whether logging stayed enabled across the assessment period, including after updates, rebuilds or configuration changes.	Change records or configuration history that show the setting was kept and any interruptions were logged and resolved.

How to implement URL request logging step by step

This sequence takes URL request logging from scope confirmation to documented coverage, so that web activity from in-scope assets is visible for detection and investigation and every gap has a recorded reason.

Confirm scope from the asset inventory
Start from the enterprise asset inventory produced under Safeguard 1.1, which the CIS Controls Assessment Specification treats as a prerequisite for measuring Safeguard 8.7. Filter it to assets that handle web traffic, such as user workstations, proxies, web gateways and internet-facing applications, and mark which ones the Safeguard's 'where appropriate and supported' wording applies to. The output is a written scope list with an owner for each asset, reviewed against the current inventory before any configuration changes begin.
Select the logging point for each asset class
For each in-scope asset, decide where URL requests are best recorded: on the endpoint, at a network gateway or proxy, or in the web application itself. Safeguard 8.7 sits in the Data asset class and Detect function, so the choice should be justified by which point sees complete request records and can be forwarded centrally. Document one logging point per asset class with the reason it was chosen. The output is a logging point decision table that the security team and asset owners have signed off.
Enable URL request logging with investigation fields
Turn on URL request logging at each chosen point and confirm that the records include the fields an investigator needs, such as timestamp, source address, requesting user or host where available, destination host, requested path and response status. Use the secure configuration process from Safeguard 4.1 so the setting is captured in the baseline and changes are controlled. The output is a configuration record per asset and a test request whose log entry shows every required field.
Forward logs to the central store
Send URL request records from each logging point to the central log store using the audit log management process defined under Safeguard 8.9, and follow the storage and retention rules set for the Control 8 process. Confirm the transport is protected, the records arrive with correct timestamps, and the store can be searched by host and URL. The output is a forwarding configuration and a sample search result showing URL records from each asset class in the central store.
Verify coverage across in-scope assets
Compare the list of assets that actually appear in the central store against the scope list from the first step. Look for missing sources, dropped records, stopped forwarders and assets that log only some requests. Repeat the test after configuration changes or new deployments. The output is a coverage report that states, for each in-scope asset, whether URL requests are arriving and how complete they appear.
Document exclusions with reasons
Record every in-scope asset or traffic type that cannot produce URL request logs, along with the reason, such as the platform not supporting the feature, a vendor limitation, or encrypted traffic that the logging point cannot read. For each exclusion, note the compensating control or the planned review date set by the owner. The output is a signed exclusion register that assessors can compare with the scope list and the coverage report.

How open-source platforms produce URL and protocol logs

The strongest self-hosted source of web request evidence for Safeguard 8.7 is the network layer, not the applications. On OPNsense (BSD-2-Clause), the built-in intrusion detection and prevention system runs Suricata (GPL-2.0-only), and Suricata's EVE JSON output records HTTP and DNS transactions alongside alerts, flows, TLS and file information. Enabling EVE output and sending it to syslog in EVE JSON format gives an assessor a repeatable record of web activity crossing the firewall. The output can be split into separate files by event type, so HTTP transactions can be routed to a log management tool without the rest of the stream. Before relying on it, confirm which event types are enabled in your deployment, where the files are written, how long they are kept locally, and whether HTTP fields such as host, URL and user agent appear for the traffic you care about. Encrypted sessions may limit what the sensor can read, so confirm that behavior for your traffic mix.

Application platforms add narrower evidence. Nextcloud's admin_audit app logs additional event information to audit.log in the data directory, or to a path set with logfile_audit, which records actions taken inside the file platform. OpenBao audit devices write a detailed JSON log of every API request and response, including errors, with most sensitive values hashed with HMAC-SHA256. These logs show what users and services did within those applications, and they are valuable for investigation. They are application-level logs, not a full URL record: they do not capture arbitrary browsing from enterprise assets, traffic to sites outside those applications, or requests that never reach them. An assessor testing Safeguard 8.7 will expect network-level coverage for the assets in scope, so treat these logs as complements to the sensor output rather than replacements for it.

Decide where URL evidence must be produced before you configure anything. List the enterprise assets and network segments in scope, mark which ones the sensor can observe, and record the gaps, such as remote endpoints that bypass the firewall. Then confirm with your assessor how they will accept evidence, including sample exports showing HTTP records from a defined period, retention settings that match your log management process, and the measure of configuration coverage described in the Assessment Specification. Use the CIS Controls Assessment Specification for v8.1 to check what the Safeguard asks you to measure, and keep the configuration records that show each logging point was enabled and tested.

Evidence that passes a Safeguard 8.7 review

An assessor testing Safeguard 8.7 looks for proof that URL request logs are collected from the assets where they are appropriate and supported, and that the coverage is documented and current. The artifacts below connect the configuration, the coverage record, the sample data and the exceptions, so each one can be traced to the others during a review.

Documented logging configuration per asset

For each in-scope asset, keep a record of the exact setting that enables URL request logging, the log destination and the format used. For open-source platforms, this is often a configuration file or admin setting, such as the audit log path set in Nextcloud with logfile_audit. Check that the record names the version and the date it was last verified, because a configuration that changed after an upgrade may no longer match what was reviewed.

Coverage register linking assets to URL sources

Build a register that maps each asset from the enterprise inventory to the URL log source that covers it, or records why none applies. The Safeguard 8.7 measures are combined into a configuration coverage metric, so an assessor will compare this register against the asset inventory from Safeguard 1.1. Gaps, such as an asset missing from the register, are the most common reason a coverage claim fails.

Sample exported URL records

Keep recent exports that show URL request records with a timestamp and source address, pulled from the log platform rather than the asset itself. Suricata's EVE JSON output records HTTP transactions, so a sample from a sensor on the monitored path can show the fields an assessor expects. Store the query used to produce each export so the sample can be reproduced during the review.

Retention and forwarding settings

Document where URL logs are forwarded, how long they are kept at each stage, and which system holds the authoritative copy. Assessors check that the retention on the log store supports the Safeguard 8.10 minimum and that forwarding from the source to the central store is configured and monitored. Capture the forwarding configuration and a recent check showing that events are arriving.

Exception records with approvals

Where URL logging is not appropriate or not supported on an asset, record the reason, the compensating control, the risk owner who accepted it and the review date. Without an approved exception, an unlogged asset reads as a gap, and an exception with no review date tends to outlive the reason for it. Revisit each exception whenever the asset changes or the platform is upgraded.

Scheduled exports and change-linked updates

Keep the artifacts current by exporting the coverage register and configuration snapshots on a fixed schedule, and by updating them whenever a change ticket touches a logging setting, a new asset or a retired asset. Store each export with its date so the evidence set shows continuity between audits. Confirm with your assessor which cadence they expect, because the Safeguard does not fix one.

What meeting Safeguard 8.7 costs in money and effort

This table breaks down the cost components of collecting URL request logs under Safeguard 8.7, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to shape a written scope and to check that a quote covers operations as well as software.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for in a quote
Tooling and licenses	Software vendors, or no license fee for open-source components	Recurring if commercial support or subscriptions apply	Open source removes license spend but not support, patching or operations. Ask whether support subscriptions are quoted separately.
Configuration of URL logging on proxies, firewalls and web servers	Implementation partner or internal platform engineers	One-time, with later changes	Number of web-facing assets and log sources in scope. Ask for a list of each source and the logging settings to be applied.
Parsing, normalization and field mapping	Internal engineers or implementation partner	One-time build, then recurring maintenance	Log formats such as EVE JSON HTTP records and how many fields the SIEM must map. Ask how schema changes are handled.
Log volume, storage and retention	Client infrastructure or cloud account owner	Recurring	Traffic volume and how many assets send URL requests. Ask for a storage sizing estimate based on your own traffic sample.
Evidence upkeep	Control owner, with partner support if retained	Recurring	Frequency of configuration exports, review records and coverage reports. Ask for the evidence list and who produces each item.
Measurement against the CAS configuration coverage metric	Control owner, internal audit or partner	Recurring at each review cycle	Number of assets measured and the three measures in the assessment specification. Ask how coverage gaps are tracked and reported.
External review and auditor sampling	Independent auditor or assessor	Recurring at each assessment	Sample size chosen by the assessor, scope of web assets and evidence quality. Ask the auditor for the sampling approach before fieldwork begins.
Privacy and data handling review	Legal, privacy and security staff	One-time review, then recurring checks	URLs can contain personal data. Ask who approves retention periods and access to URL logs.

Who owns URL logging, who helps and who audits

The organization owns Safeguard 8.7. That means it decides which enterprise assets are in scope for URL request logging, records where logging is not appropriate or not supported, approves those exceptions, and accepts the risk they carry. The control, its documentation and its operation stay with the organization even when outside parties do the technical work. Assessors will ask the organization, not a vendor, to explain its scope decisions.

Scope decisions: Naming which web proxies, gateways, firewalls and hosts log URL requests, and why others are excluded.
Exception records: Documenting assets where URL logging is not supported or not appropriate, with an approver and a review date.
Process ownership: Tying URL logging to the audit log management process from Safeguard 8.1 and the review cadence from Safeguard 8.11.
Operational accountability: Someone inside the organization who reviews detections and owns the response to them.
Exception acceptance: Signing off on residual risk for any gap between the asset inventory and what is actually logged.

Before any outside work starts, confirm that an owner is named for each of these items and that the owner can produce the scope and exception records on request.

Where Safeguard 8.7 programs usually fall short

Safeguard 8.7 looks simple on paper: turn on URL request logging where it fits and keep the records. In practice, programs tend to fail on coverage, forwarding, field completeness, documented exclusions and the review and retention steps that make the logs useful. The cards below cover the gaps assessors most often find and the first action to close each one.

No coverage register

Without a written list of which enterprise assets are in scope for URL request logging, nobody can show that the Safeguard was applied where it is appropriate. Build the register from the asset inventory produced under Safeguard 1.1, and mark each asset as logging, not applicable, or pending, with a named owner for each decision. Ask the assessor which evidence they expect to see for that list before the review starts.

Logs enabled but not forwarded

A proxy, firewall or application may record URL requests locally while the records never reach the aggregation platform. The log then exists only on the device, where it can be overwritten or lost during an incident. Check each in-scope source by pulling a sample event from the central store, not from the device, and confirm the timestamp and host name arrive intact.

Missing source and full URL fields

Some sources log only the domain or a truncated path, or omit the requesting host and user. That breaks investigations that need to tie a request to a device and a time. Compare a test request against the stored record and confirm it includes the source address, the full requested URL, the response outcome and a timestamp synchronized under Safeguard 8.4. Record any field that is missing as a finding with a fix date.

Undocumented exclusions

Teams often filter out noisy destinations, internal health checks or entire subnets to reduce volume, and the reason is rarely written down. An assessor can read an undocumented exclusion as a gap in coverage. Keep a short exclusion register that names the rule, the owner, the business reason and a review date, and make sure the change log for the filter is retained.

Logs not reviewed or retained

URL logs collected for detection need someone to look at them, and they need to survive long enough to be used. Confirm that the review cadence in Safeguard 8.11 covers web activity and that the retention period meets the Safeguard 8.10 minimum on the aggregation tool, not just on the source device. Ask the platform owner to show a query that returns records from the oldest day in the retention window.

No owner for the Safeguard

When URL logging spans a firewall team, a cloud team and an application team, each assumes another group handles it. The Safeguard then has no accountable owner, and changes to log sources go unrecorded. Name one owner in the audit log management process from Safeguard 8.1, define how each asset owner reports status, and schedule a check of the coverage register against the current asset inventory.

Questions about Safeguard 8.7 cost, effort and scope

What drives the cost of collecting URL request audit logs?

The main cost drivers are the number of enterprise assets that produce web traffic logs, how many of them support URL request logging, and how much log volume the destination must absorb and keep. Organizations usually pay for four things: the time to identify which assets and proxies or firewalls can emit URL records, the configuration work to enable them, the storage and log management capacity to hold them for the retention period set in the audit log management process, and the review effort that makes the logs useful. Costs that are one-time include the initial scoping and configuration. Recurring costs include storage, licensing for any log platform, and ongoing review. Ask any quote to itemize these components and to state which assets and log sources are in scope.

Can our own team implement Safeguard 8.7 without outside help?

Yes, an internal team can implement it if it has people who understand the network, the web gateways and the log platform. The Safeguard depends on prerequisites from Safeguard 1.1 (the enterprise asset inventory) and Safeguard 4.1 (the secure configuration process), so an organization without a current inventory or documented configuration process will spend effort building those first. Outside help is most useful for scoping, for configuring self-hosted platforms consistently, and for preparing evidence an assessor can test. Whatever the approach, the organization owns the control. An independent assessor, not an implementation partner, decides whether the evidence meets the assessment specification.

How long does URL request logging usually take to set up?

The duration depends mostly on scope: how many assets and gateways are involved, how mature the inventory and configuration baseline already are, and how many log destinations need to be connected and tested. A narrow scope covering one web gateway and one log platform is a very different job from a multi-site estate with several proxies, cloud workloads and retention rules to reconcile. No duration is stated here because none has been researched for this Safeguard. Ask any provider for a timeline tied to a written scope with named assets, log sources and deliverables, and confirm which prerequisites are already met.

Do IG1 organizations have to collect URL request logs?

No. Safeguard 8.7 is assigned to Implementation Groups 2 and 3 and is not part of IG1. An IG1 organization is still expected to meet the IG1 logging Safeguards, so it should confirm which of them apply before deciding whether URL logging is worth adding early. IG2 and IG3 organizations that hold sensitive information or face more complex operations should plan for this Safeguard. Confirm your Implementation Group against the CIS Implementation Groups pages and your own risk profile, since regulators or customers may ask for logging beyond the IG assignment.

What does the partner need from our organization to start?

The partner needs written access to the people and systems that define the scope: the owner of the audit log management process, the administrators of web gateways, firewalls and endpoints that can emit URL records, and the owner of the log platform. It also needs the current asset inventory, any existing configuration baselines, retention requirements, privacy and legal constraints on storing web activity, and a decision on who reviews the logs. Ask the partner to list these inputs in the written scope before work begins, and to confirm that the organization remains responsible for its controls and for the evidence it presents.

Do URL request logs alone satisfy Safeguard 8.7?

Not necessarily. The Safeguard asks for URL request logs from enterprise assets where that is appropriate and supported, so the measurement depends on which assets are in scope and whether the logs are actually collected from them. Assessors look at configuration coverage across those assets, and a single gateway with logging enabled will not show coverage across the estate. Confirm the scope and the asset list, check the measures in the CIS Controls Assessment Specification for Safeguard 8.7, and test that logs arrive at the central destination. A log source that is enabled but not retained or reviewed may not satisfy the broader Control 8 expectations.

How DeployOpen prepares URL request logging evidence

DeployOpen plans, builds and documents the URL request logging that Safeguard 8.7 asks for, inside your own infrastructure, on the assets where your scope says it applies. We prepare the systems and evidence an assessor will examine, while your organization keeps ownership of the Safeguard and the independent assessor issues any report.

How we scope

We agree in writing which enterprise assets fall under Safeguard 8.7 and which are excluded, with reasons.
We confirm whether each in-scope asset supports URL request logging before any build work starts.
We map dependencies on the asset inventory and secure configuration process so measurement data is traceable.

How we build

We enable URL request logging on the agreed self-hosted platforms and document the exact settings used.
We configure log output so URL request records reach the log destination your audit log process names.
We test that sample web requests produce the expected records, and we record the results for the assessor.

How we hand over

We deliver configuration records, test results and a coverage view showing which assets log URL requests and which do not.
We document the review and retention steps your team must run to keep the evidence current.
We walk your team through the handover so the staff who operate the logs can explain them to an assessor.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if coverage must be kept current.
Your organization owns the control and its assessment; DeployOpen does not issue audit reports or certifications.