Data Centre Compliance Audit Methodology: What Auditors Actually Check

The Asset Inventory as a Compliance Foundation

Every major data centre compliance framework — NIS2, EN 50600, DORA, ISO 27001, SOC 2 — treats the asset inventory as a foundational control. Before an organisation can demonstrate that it is managing its infrastructure securely and resiliently, it must first demonstrate that it knows what infrastructure it has.

This sounds obvious. In practice, it is the requirement that most organisations fail first. When an auditor asks "can you show me a complete, current inventory of all ICT assets supporting your critical functions?", the answer is often a spreadsheet that is 18 months old, covers servers but not network equipment, and has no evidence of when it was last verified.

This guide explains what auditors actually check, what documentation they expect, and how to prepare an asset inventory that holds up to scrutiny under NIS2, EN 50600, and DORA.

What Auditors Check

Regardless of the specific framework, auditors evaluate asset inventories against three criteria.

Completeness — does the inventory cover all assets in scope? For NIS2, scope is defined by the organisation's risk assessment: which assets support critical or important functions? For EN 50600, scope is the physical data centre infrastructure. For DORA, scope is ICT assets supporting critical or important functions as defined by the financial entity's ICT risk management framework. An inventory that covers servers but not network equipment, or that covers production systems but not development and test systems that share infrastructure, will fail the completeness check.

Accuracy — does the documentation match physical reality? Auditors do not just read the inventory — they spot-check it. They will select a sample of records and ask to see the physical assets. If the inventory says a device is in Rack A12, U3, and the device is not there, that is a finding. If the inventory says the serial number is XYZ123 and the device label says ABC456, that is a finding. Accuracy requires not just that the inventory was correct when it was created, but that it has been maintained as the environment changed.

Currency — when was the inventory last verified? An inventory with no evidence of review is treated as potentially stale regardless of its actual accuracy. Auditors look for a documented review process: who reviews the inventory, how often, and what evidence is produced. A quarterly reconciliation report, a sign-off log, or a change management audit trail that shows the inventory is updated in real time are all acceptable evidence of currency.

NIS2 Asset Management Requirements

NIS2 (the EU Network and Information Security Directive 2, effective October 2024) requires organisations in scope to implement asset management as part of their cybersecurity risk management measures. The directive does not prescribe a specific format for the asset inventory, but the implementing guidance from ENISA (the EU Agency for Cybersecurity) and national regulators is consistent: organisations should maintain a documented inventory of all ICT assets, classified by criticality, with documented ownership and a regular review process.

For data centre operators, the practical requirement is an inventory that covers all physical and virtual assets supporting the services in scope, with each asset classified as critical, important, or standard based on its role in service delivery. The inventory should be reviewed at least annually, with evidence of the review retained for audit purposes.

EN 50600 Asset Classification Requirements

EN 50600 is the European standard for data centre facilities and infrastructure. It defines four availability classes (Class 1 through Class 4) based on the redundancy and resilience of the physical infrastructure. Class 4 is the highest availability class, equivalent to Tier IV in the Uptime Institute classification.

For asset management, EN 50600 requires that all physical infrastructure assets are documented and classified by their availability class and criticality tier. A power distribution unit that is part of a Class 3 redundant power path has a different criticality classification than a patch panel in a non-critical area. The inventory must reflect these classifications.

In practice, this means your DCIM platform needs to support asset classification at the device level, not just the site level. Each device record should carry a criticality classification that reflects its role in the availability class of the infrastructure it supports.

DORA ICT Asset Register Requirements

The Digital Operational Resilience Act (DORA) applies to financial entities operating in the EU from January 2025. It requires financial entities to maintain a complete, up-to-date register of all ICT assets supporting critical or important functions.

The DORA ICT asset register requirements are more prescriptive than NIS2 or EN 50600. The register must include: the asset's function and classification, its physical or logical location, the business processes it supports, its dependencies on third-party ICT service providers, and the date of last review. For data centre assets, this means the DCIM export needs to be enriched with business process mapping and third-party dependency data — information that is typically held in the CMDB, not the DCIM platform.

For organisations subject to DORA, the practical approach is to use the DCIM platform as the authoritative source for physical asset data (location, hardware specifications, status) and the CMDB as the authoritative source for logical asset data (business process mapping, service dependencies, third-party providers), with a documented integration between the two.

Preparing the Audit Pack

An audit pack for a data centre compliance audit typically contains four documents.

The asset register is the complete inventory of all assets in scope, in a structured format with all required fields populated. The register should be produced from the DCIM platform, not from a spreadsheet, to demonstrate that it is maintained as a living document rather than a point-in-time snapshot.

The chain-of-custody header documents who produced the register, when, what data sources were used, and what quality assurance process was applied. This is the single most credible thing you can add to an audit submission. An asset register with a chain-of-custody header that says "produced from NetBox on 15 March 2026, covering 1,247 active assets across 3 sites, reviewed by [name] on [date]" is far more credible than an undated spreadsheet.

The audit trail documents changes to the asset register over the review period. This can be a DCIM change log, a change management system export, or a reconciliation report showing the delta between the current register and the previous review.

The exceptions log documents assets that are in scope but not fully documented, with an explanation and a remediation plan. Auditors expect gaps — what they do not expect is gaps that the organisation is unaware of or has no plan to address.

Using Struktive for Compliance Audit Preparation

Struktive's Compliance Audit Pack export produces all four documents in a single operation. The export includes a chain-of-custody header with job ID, source file hash, normaliser version, timestamp, and record count. The asset register is structured to cover the field requirements of NIS2, EN 50600, and DORA. The exceptions log groups unresolved issues by type and severity. The audit trail records every normalisation transformation applied to the source data.

For organisations that need to produce a compliance audit pack on short notice, the ability to upload a raw asset spreadsheet and receive a structured, signed audit pack within minutes is the difference between a credible audit submission and a last-minute scramble.