Safeguard 1.4 DHCP logging for asset inventory

What Safeguard 1.4 DHCP logging for the asset inventory asks for

Safeguard 1.4 asks the enterprise to enable logging on every DHCP server or IP address management (IPAM) tool, and to review and use those logs at least weekly so the enterprise asset inventory stays current. In plain terms, every address handed out on the network should leave a record that someone actually reads and feeds into the inventory. This is a paraphrase of the CIS text, not a quote, and the exact wording belongs in the CIS Controls v8.1 documentation. It is an IG2 and IG3 Safeguard, not an IG1 Safeguard, so organizations at IG1 are not expected to meet it to satisfy the baseline, although a DHCP log review is a practical habit for any network.

The risk is simple. A device that joins the network and receives an address is a device that can reach other systems, yet it may never appear in the inventory built from scheduled scans or manual lists. Active discovery (Safeguard 1.3) only finds what it probes, and passive discovery (Safeguard 1.5) only sees what generates traffic. DHCP logs record the moment an address was leased, often including a hardware address and hostname, so they capture devices that are quiet, newly connected or hidden from scanners. That complementary view is why CIS pairs the DHCP feed with the other discovery methods rather than treating any one of them as sufficient.

Several things make this hard in practice. Organizations often run more than one DHCP server, including on branch routers, firewalls or cloud virtual networks, so the logging must be enabled on each one and collected in one place. Statically addressed devices never appear in a lease log at all, so they need a separate reconciliation step. Short lease logs or aggressive log rotation can erase the history an assessor expects to see. Finally, the CMDB is only as good as the people updating it, and a DHCP feed that nobody reviews adds noise rather than accuracy. Confirm with your network team which servers and IPAM tools exist, how long logs are kept and who owns the weekly review before scoping the work.

Which DHCP servers, IPAM tools and CMDB records are in scope

Safeguard 1.4 only works if the log feed covers every place an enterprise asset receives an address and every system that stores the result. The decisions below set how many sources you must log, where the data lands, and who is responsible when a third party runs part of the network.

Every DHCP server and IPAM tool

Start with an inventory of every service that hands out addresses to enterprise assets, including on-premises DHCP servers, DHCP role instances on domain controllers or firewalls, and IP address management platforms. Each DHCP scope on each server is a separate source of lease events, so a site with many scopes produces more log streams to enable, collect and review each week. Ask the network team to export the scope list and compare it with the sources you actually log. Gaps usually appear at branch sites and in older scopes that nobody has touched since installation.

Cloud and virtual network DHCP services

Virtual networks in public clouds and hypervisor platforms often assign addresses through a provider-managed DHCP service that does not look like a traditional server. These services can be configured per virtual network or subnet, and their lease records may sit in a different logging pipeline than on-premises events. Confirm whether the provider exposes lease or event logs, how long it keeps them, and whether you can forward them to the same collector used for the rest of the estate. Workloads in these networks are enterprise assets and must appear in the inventory.

Wireless controllers and guest networks

Wireless controllers frequently act as the DHCP server for client networks, and guest networks often receive their own scope. The question for scoping is whether a guest scope hands out addresses to any enterprise-owned device, such as company laptops used on guest Wi-Fi, contractor equipment or managed IoT devices. If it does, those leases belong in the feed. If guest scopes serve only unmanaged visitor devices, document that decision and the segregation that supports it, so an assessor can see why those leases are excluded.

The CMDB or inventory system of record

The lease data has to land in a system that can match addresses to asset records, which is the CMDB or inventory in Safeguard 1.1. Identify the system that owns asset records, the fields it uses to match an IP address to a device (hostname, MAC address, owner, location), and who can change them. If the inventory is a spreadsheet or a tool without an API or import path, the weekly update will be manual and hard to evidence. Confirm this before choosing a collector, because it decides the integration work.

Third parties that run DHCP or IPAM

When a managed service provider, outsourced network operator or hosting partner runs your DHCP or IPAM platform, the provider holds the logs and the configuration. Your Safeguard 1.4 obligation still applies to the enterprise, so the contract or operating procedure must require log access, weekly delivery or review, and retention that meets your records needs. Ask who owns the log export job, who tests it after changes, and what happens to the feed when the provider changes platforms. Treat this as a service provider dependency and record it in your provider inventory.

How an assessor tests DHCP logging and the CMDB

This table sets out what an assessor inspects on DHCP servers and IP address management tools, how the weekly review is evidenced, and how log entries are reconciled to configuration management database records. Read each row as a test step, then check the common findings column against your own environment before the assessor arrives. The sample an assessor draws is their decision, so prepare evidence for every in-scope server.

Test area	What the assessor inspects	Common findings
Logging enabled on each DHCP server or IPAM tool	Logging configuration on every DHCP server, scope or IPAM tool in scope, including whether lease events are recorded, not just the server that is easiest to reach	Logging enabled on one server only, or on a primary server while a failover partner is left unconfigured
Log destination and integrity	Where logs are written or forwarded, who can change that setting, and whether the destination is protected from local edits	Logs written only to the DHCP server's local disk with no central copy, or write access granted to general administrators
Retention of DHCP logs	Retention period actually in effect compared with the period the organization documented, and whether older logs are still available for reconciliation	Logs rotated out before the review cycle could have used them, or retention set but never tested
Weekly review evidence	Dated records showing that someone reviewed the logs at least weekly, with the reviewer, the scope covered and any follow-up tickets	Gaps during holiday periods, reviews recorded as complete without a scope, or review notes that cannot be tied to a specific week
Reconciliation of log entries to CMDB records	A sample of new or changed lease entries matched to CMDB asset records, and a check that unknown addresses or hardware identifiers were investigated	Unknown devices logged but not added or escalated, or matching done by IP address alone when addresses are reassigned
CMDB field accuracy	Whether fields the log feed should update, such as address, hostname, owner and last seen date, match the logged values for the sampled assets	Stale addresses, missing owners or last seen dates that do not change after a device is replaced
Link to the Safeguard 1.1 inventory	Whether the asset inventory that Safeguard 1.1 requires is the same record the DHCP feed updates, and whether the two agree for the sampled assets	Two inventories maintained separately with no owner for resolving differences
Sample selection	The assessor chooses which servers, weeks and assets to test, so organizations should not assume a fixed sample size	Evidence prepared only for the newest or most visible server, leaving others unsupported

How the CIS assessment specification measures Safeguard 1.4

The CIS Controls Assessment Specification for v8.1 measures Safeguard 1.4 through seven measures combined into three metrics: DHCP logging quality, CMDB configuration quality and CMDB updating accuracy. The first metric asks whether DHCP servers or IP address management tools are logging the right events and whether those logs are actually reviewed at least weekly. The second asks whether the configuration management database (CMDB) is set up to receive and hold the data the logs produce. The third asks whether the CMDB is being updated from those logs accurately and in time. An assessor will look at all three together, because a complete log feed that never reaches the CMDB, or a well-kept CMDB fed by logs nobody reads, does not show that the asset inventory is kept current.

For an engineer, the practical question is whether a DHCP lease or IP address management record can be traced to a named asset. For an assessor, the question is whether the organization can show that trail for a sample of leases and CMDB entries. Confirm with your own environment which DHCP servers and IPAM tools hold leases for each network segment, whether each one logs lease grants, renewals and releases, and who owns the weekly review. Make sure the CMDB fields that receive DHCP data (IP address, MAC address, hostname, lease time) are populated consistently, because the accuracy metric depends on matching records rather than on the volume of logs.

Safeguard 1.1, the enterprise asset inventory, is a prerequisite for this measurement. The specification lists it because it typically produces the data the measurement needs: the asset records that DHCP entries must match. An organization without a maintained inventory will struggle to show CMDB updating accuracy, even with good logging. CIS states that the specification covers what to measure, not how, so the choice of DHCP server, IPAM product, CMDB and review workflow stays with the organization. Read the Assessment Specification for Safeguard 1.4 for the exact measures before you define evidence, since its wording governs how an assessor will test your setup.

How to implement DHCP logging for the asset inventory

This sequence turns DHCP and IP address management logs into a weekly, owned feed that keeps the asset inventory current, with each step producing a record an assessor can check.

Inventory every DHCP server and IPAM tool
Build a list of every DHCP server, DHCP service on network devices, and IP address management tool that issues addresses in the enterprise, including cloud and branch sites. Record the platform, location, owner, the subnets each one serves and whether it is the authoritative source for those scopes. Confirm the list against the network team's address plan and the scope configuration on each device. The output is a DHCP and IPAM source register. Any scope with no named source is a gap to resolve before logging can cover it.
Enable logging on each source and confirm fields
On each server or IPAM tool in the register, turn on lease and event logging and confirm that the captured fields include the assigned IP address, the hardware (MAC) address, the client hostname where available, and lease start and end times. Test by connecting a known test device and checking that its lease appears in the log. The output is a logging configuration record for each source that names the log path, the enabled event types and the fields verified in testing. Confirm vendor-specific field availability with each product's documentation, since fields differ by platform.
Set log retention and secure storage
Define how long DHCP logs are kept and who can read or change them. Restrict write access on the source systems, protect the log files from modification, and record the retention period in the logging configuration record. Retention should be long enough to support investigations of devices that connected in the past, and your legal or contractual obligations may set a minimum. The output is a retention and access statement approved by the asset owner, plus a permission check showing that only named administrators can alter the logs.
Forward logs to a central store
Send the DHCP and IPAM logs to a central store that the inventory team can query without logging into each server. Options include a SIEM, a log platform or a file share with read-only access for the review team. Confirm that forwarding continues when a source is restarted and that a gap in delivery raises an alert. The output is a documented data flow from each source to the central store, with a test record showing a known lease arriving there.
Define and document the weekly review
Write the review procedure with a named owner, a backup owner, and a checklist. The checklist should cover confirming that every source delivered logs during the week, listing new addresses and their hardware identifiers, checking for scope exhaustion or unusual lease volume, and recording the reviewer and date. Safeguard 1.4 expects review at least weekly. The output is a signed review procedure and a blank checklist template, approved by the owner of the asset inventory.
Map log-derived addresses to CMDB records
For each week's log extract, match hardware addresses and hostnames to existing configuration management database (CMDB) or asset inventory records. Update matches with the current address, last-seen date and source. Record discrepancies, such as a known asset with a different address or a hardware identifier that does not match its record. The output is a reconciliation report listing matched, updated and unmatched entries. Assessors look for evidence that the CMDB is corrected from this feed, so keep the report and the change record together.
Route unknown assets to the Safeguard 1.2 process
Any device that appears in the logs but not in the inventory must be handled as an unauthorized or unmanaged asset. Pass each one to the process defined under Safeguard 1.2, which decides whether it is approved for addition, removed, blocked or quarantined. Record the routing decision and the owner in the reconciliation report, so every unknown address has an outcome. The output is a ticket or log entry per unknown asset, linked to its final disposition.
Run a first full review and record results
Perform a complete review across all sources and all subnets in the register, not just the most recent week. Compare the full lease history against the CMDB, resolve or route every unmatched address, and correct the logging configuration where a source or field was missing. Record counts of sources reviewed, addresses reconciled, discrepancies found and items routed to Safeguard 1.2. The output is a baseline review report signed by the inventory owner, which becomes the reference for later weekly reviews and for any assessment of Safeguard 1.4.

Evidence that satisfies Safeguard 1.4 and how to keep it current

The evidence for Safeguard 1.4 is a chain: logging enabled on every DHCP server or IP address management tool, weekly reviews of those logs, and reconciliation of the results against the CMDB. Each artifact below should be refreshed on a fixed rhythm and owned by a named role, so an assessor can trace a device from its lease to a reviewed inventory record. Confirm the refresh intervals and owners against your own policy before the assessment starts.

DHCP and IPAM logging configuration exports

Export the logging settings from every DHCP server and IP address management tool in scope, including which lease events are written, where logs are sent and the retention setting. The assessor will check that no server is missing from the list, so keep the export tied to a current inventory of DHCP scopes. Refresh the export after any server change and at least once before each audit. The network engineering team owns the configuration, and the security or asset management lead signs off on completeness.

Sample lease log extracts

Keep dated extracts showing lease grants, renewals and releases with the MAC address, IP address, hostname and timestamp. A good extract lets the assessor pick a device at random and follow it from the DHCP log into the inventory. Refresh samples monthly during the period under review, and take fresh ones before the audit window closes. The network operations team produces the extracts, and the asset inventory owner confirms that sampled devices appear in the inventory.

Dated weekly review records

Safeguard 1.4 asks for review at least weekly, so every week needs a record with the date, the reviewer, the log sources checked and the findings. Findings should list new unknown MAC addresses, lease anomalies and any follow-up tickets. Empty weeks still need a record that shows the review happened. Keep the reviews continuous across the whole period, since gaps are the most common reason an assessor marks the measure as not met. The asset inventory owner or a delegated analyst owns the weekly review.

CMDB reconciliation reports and exceptions

Compare DHCP-derived devices against the CMDB and record each mismatch as an exception with an owner, a status and a closure date. The CIS assessment specification measures CMDB configuration quality and updating accuracy, so the reconciliation report is central evidence. Run reconciliation at the weekly review cadence and keep the exception log open until each item is closed. The configuration management or IT operations team runs the comparison, and the service owner of each exception closes it.

Change records for new DHCP scopes

Each new DHCP scope, reservation range or IPAM block should have a change record that names the requester, the approver, the date and the logging settings applied at creation. This shows that logging is not skipped when networks grow. Review the change log at each weekly review to confirm that every new scope appears in the logging export. The change advisory process and the network engineering team own these records.

Proof of log retention

Show that DHCP and IPAM logs are kept long enough to cover the review period, and that they cannot be altered without a trace. Evidence includes the retention setting, a sample of logs from the oldest date in the period and the storage location with access controls. Check retention at least quarterly and after any log platform change. The infrastructure or security operations team owns retention, and the compliance lead confirms the period matches the assessment scope.

What meeting Safeguard 1.4 costs in money and effort

This table lists each cost component of running DHCP logging for the asset inventory, who is paid for it, whether it is one-time or recurring, and what changes its size. Use it to build a quote request, since no price list is supplied and the figures depend on your DHCP estate and CMDB maturity.

Cost component	One-time or recurring	What drives it up	How to keep it down
Log storage and collection tooling	Recurring (licenses or hosting), with a one-time setup	Number of DHCP servers and IPAM tools, log volume, retention period, and whether logs are centralized in a commercial SIEM	Forward logs to a self-hosted collector or existing log platform, and confirm whether your current license already covers the volume
Engineering time to enable and standardize logging	One-time	Mix of DHCP server vendors, inconsistent log formats, and the number of sites or separate address scopes	Adopt one logging template for every DHCP server and IPAM tool, and document the settings so each new server is configured the same way
Weekly review of DHCP logs	Recurring	Lease churn across scopes, number of unmatched hostnames or MAC addresses, and whether reviews are manual or partly automated	Pipe lease events into the inventory tool so reviewers only handle exceptions, and record each weekly review with a named owner
Feeding logs into the inventory and CMDB	Recurring, with a one-time mapping step	Number of inventory sources, how much CMDB data is incomplete, and whether DHCP records can be matched to asset records	Agree the matching fields (for example MAC address, hostname, and IP lease) and keep import jobs in one place
CMDB data cleanup and upkeep	One-time cleanup, then recurring upkeep	Duplicate or stale records, unowned assets, and missing configuration fields that assessors measure	Clean the highest-impact records first, and set a standing review cycle tied to the weekly DHCP review
External review or testing, if bought	Usually one-time per assessment cycle	Scope count, number of sites tested, and whether the reviewer must inspect live DHCP servers	Limit scope to the in-scope DHCP servers and IPAM tools, and prepare evidence before the reviewer arrives
Auditor or assessor sampling effort	Recurring per assessment cycle	Number of periods and servers sampled, and gaps in weekly review records	Keep dated weekly review records and a log retention record so samples can be pulled without rework

Where organizations fall short on DHCP-based inventory

Safeguard 1.4 looks simple on paper: turn on DHCP logging and review it weekly. In practice, the gaps sit in scope, evidence and handoffs, such as which servers are covered, whether IP address management tools count, and whether the CMDB ever changes after a log is read. The cards below cover the failures assessors most often find and the action that closes each one.

Logging on the primary DHCP server only

Many enterprises run several DHCP servers, scopes or failover pairs, and logging is enabled only on the one that was set up first. Devices leasing addresses from the others never reach the inventory process. Confirm that every DHCP server and every scope that serves enterprise networks is listed, and that logging is enabled and retained on each one, with the list kept as evidence.

IPAM tools left out of scope

Organizations often treat IP address management platforms as network administration tools and leave them out of the asset inventory process. Where an IPAM tool holds the authoritative lease and address records, it is one of the sources Safeguard 1.4 names. Add each IPAM instance to the logging scope, document which feeds it sends to the inventory, and test that a new lease appears there.

Weekly reviews that leave no record

Teams often say the logs are reviewed weekly, but nothing shows who reviewed them, when, or what was found. An assessor measuring the review cadence needs dated records that link to actions taken. Keep a short review log with the reviewer, the review date, the number of new addresses seen and the inventory changes made from them.

Static addresses that bypass DHCP

Servers, network devices and some industrial systems use statically configured addresses, so they never appear in a DHCP lease log. Without a separate source, these assets are missing from the inventory that logs are supposed to keep current. Compare static address ranges against the inventory during each review, and record static devices through Safeguard 1.1 with their addresses and owners.

CMDB fields not updated from logs

A CMDB can hold a device record that looks complete while its address, hostname and last-seen fields are months old. Log reviews that never write back to the CMDB leave those fields stale, and the assessment specification measures both configuration quality and updating accuracy. Define which CMDB fields the logs update, set who updates them, and sample records against the logs to confirm the values match.

Log retention shorter than the review cycle

If DHCP logs roll over after a few days, a weekly review has nothing to read when a device stays offline for part of the cycle or a review is missed. Assessors look for retention that covers at least one full review cycle, with margin for missed reviews. Set the retention period on each DHCP server and IPAM tool to exceed the review interval, then test that a log from two weeks earlier can still be retrieved.

Who does what: your team, an implementation partner and the auditor

Your organization owns Safeguard 1.4 in full. The CIS Controls are a set of practices that the enterprise must run itself, so the decisions about which DHCP servers and IP address management tools are in scope, who reviews their logs each week, and what the CMDB is allowed to say about an asset all sit with your staff. An outside partner can build the pipeline, but it cannot decide that a device is authorized or retire a record on your behalf.

Scope decisions: list every DHCP server, DHCP relay and IPAM tool, including those run by cloud platforms or branch offices, and record the owner of each.
Weekly review: name an accountable role and a backup, and define what a reviewer does with new leases that match no CMDB record.
CMDB ownership: decide which fields are authoritative, who approves changes and how disputed records are resolved.
Exceptions: document any segment where DHCP is not used, such as statically addressed industrial networks, and the compensating method used.
Retained evidence: keep the signed review records and log retention settings that show the weekly cycle actually ran.

Before the assessment, confirm that someone in your team can explain the review cycle end to end without the partner in the room.

Questions buyers ask about DHCP logging for the asset inventory

Do organizations in IG1 have to use DHCP logging for the asset inventory?

No. Safeguard 1.4 is assigned to Implementation Groups 2 and 3 and is not part of IG1, so an IG1 organization is not expected to meet it to claim the CIS Controls at that level. Nothing stops an IG1 team from doing it voluntarily, and many do because DHCP logs are often already being produced by the network stack. Confirm the assigned Implementation Group for each Safeguard in the CIS Controls v8.1 documentation before writing it into a scope statement.

How much effort does the weekly DHCP log review take?

The effort depends less on the review itself than on how the logs are produced and routed. A review is a scheduled check that the logs are being collected, that new leases map to known inventory records, and that unknown addresses are sent into the unauthorized asset process in Safeguard 1.2. The main drivers are the number of DHCP servers or IP address management tools, the number of lease events per week, how many addresses are dynamic or guest-facing, and whether matching to the CMDB is automated. Ask for the effort split between one-time configuration and recurring review in any written quote.

How long does implementation take, and what does it depend on?

No duration is given here because it varies widely with the environment. Confirm with the implementation partner what the timeline depends on: the number of DHCP servers and IP address management platforms, whether logging is already enabled and retained, the state of the CMDB, and whether the Safeguard 1.1 inventory exists yet, since the CIS Controls Assessment Specification treats that inventory as a prerequisite for measuring Safeguard 1.4. Fixed-scope work should show these dependencies in the written scope before the start date is agreed.

Can we implement DHCP logging for the inventory with open-source tools?

Often yes, but confirm the capability against your own DHCP or IPAM product, because the logging options differ by platform. Open-source tools can receive, store and match the records. For example, GLPI's Assets module can hold computers, network equipment and other items and can be fed by its native inventory agent, while Wazuh's Syscollector can gather inventory data from endpoints for reporting. Neither replaces the DHCP feed itself, so check that your DHCP server can export lease or log events in a form your chosen tool can ingest. An implementation partner can build and test that path in your environment.

What do we need from our network and CMDB owners?

You need named owners for three things: the DHCP servers or IPAM platform, the CMDB or asset register, and the process that acts on unknown addresses. The network team must confirm which scopes exist, turn on logging, set retention, and agree how logs are exported. The CMDB owner must agree the fields that a lease record will update, how a new address is matched to an existing configuration item, and who approves new records. Without those agreements, the weekly review produces lists nobody acts on, which is the failure assessors look for.

Do DHCP logs alone satisfy Safeguard 1.4?

No. The Safeguard asks for DHCP or IP address management logs to be used to keep the inventory current, and the CIS Controls Assessment Specification measures the quality of that logging and of the CMDB as well. DHCP logs only see devices that request addresses dynamically, so statically addressed systems and devices that never renew a lease can be missed. That is why the DHCP feed complements active discovery in Safeguard 1.3 and passive discovery in Safeguard 1.5, and why the results are reconciled in the CMDB rather than kept in the DHCP server.

What will an auditor ask to see for Safeguard 1.4?

An assessor typically asks to see that logging is enabled on every DHCP server or IPAM tool in scope, that logs are retained and sampled, and that a documented weekly review exists with dated records of what was checked and what was changed. Expect questions about the CMDB too: how lease data updates it, how accurate and complete its records are, and how mismatches are resolved. The measures and metrics come from the CIS Controls Assessment Specification for v8.1, so check its Safeguard 1.4 section before the assessment. Note that DeployOpen prepares these systems and evidence but does not issue assessment results; an independent assessor does that.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, so DHCP and IP address management logs can feed the asset inventory under Safeguard 1.4. We prepare the logging, the weekly review routine and the CMDB records that an assessor will examine, while the organization keeps ownership of its controls and the independent assessor issues any conclusion.

How we scope

Confirm every DHCP server and IP address management tool in the written scope, including those in cloud, data center and air-gapped segments.
Agree which log fields, retention period and weekly review owner the organization will use for Safeguard 1.4.
Document how DHCP data links to the Safeguard 1.1 inventory and the Safeguard 1.3 and 1.5 discovery tools in the agreed scope.

How we build

Enable and verify DHCP or IPAM logging on each in-scope server, then forward those logs to a central collection point.
Configure an open-source inventory platform such as GLPI to receive and reconcile DHCP-derived records against the asset register.
Test that a newly leased address appears in the inventory within the weekly review cycle, and record the test results.

How we hand over

Deliver configuration records, log retention settings and the weekly review procedure written for the client's own staff.
Provide sample reconciliation reports and a measurement worksheet mapped to the Safeguard 1.4 measures in the CIS assessment specification.
Walk the client's owners through the evidence pack so they can show an assessor how each DHCP log was produced and reviewed.

How we support

Ongoing support, upgrades and continuous testing of the logging pipeline are available as a retainer after handover.
Review DHCP and CMDB evidence again after server changes, network re-addressing or a new IPAM deployment.
Confirm with the client's assessor which evidence formats they accept before the assessment window opens.