ISO 27001 Controls for Data Centre Security

ISO 27001 does not prescribe a universal data centre design. It requires the organisation to assess information-security risks, select necessary controls and operate an effective ISMS. A private facility, colocation suite and public-cloud region therefore require different treatment even when they support the same service.

The strongest approach treats the data centre as a chain of physical, environmental, technology and supplier dependencies. This guide shows how to select controls, assign shared responsibilities and build audit evidence without assuming that equipment in a secure building is automatically secure.

Define the service and responsibility boundary

Begin with what the facility enables, not only its address. Identify:

• services and information supported;
• rooms, cages, racks, circuits and network zones in scope;
• operational and security teams;
• property owner, colocation operator, carriers and maintenance suppliers;
• customer-managed and provider-managed layers;
• remote administration paths;
• dependencies on power, cooling, fire protection and communications; and
• alternate processing or recovery arrangements.

In a shared facility, provider certification does not transfer accountability for customer equipment, identity decisions or configurations. Obtain the provider’s scope and assurance information, then map it to the contractual responsibility model.

The supplier audit guide explains how to test outsourced activities rather than relying on a badge.

Select controls from risk scenarios

ISO’s official overview explains that ISO/IEC 27001 establishes requirements for an ISMS. Control selection follows the organisation’s risk process; Annex A is used as a reference during treatment.

Write scenarios that connect a threat, weakness, event and business consequence. Examples include:

• unauthorised entry to a rack leading to equipment tampering;
• loss of cooling causing service interruption and hardware damage;
• a single carrier route defeating assumed network redundancy;
• misuse of a remote administration account;
• fire suppression failure affecting availability;
• an untracked component leaving the secure area; or
• a maintenance supplier connecting an unmanaged device.

Record existing safeguards, consequence and likelihood, treatment choice, owner, planned evidence and residual risk. Use the risk score calculator for consistent scoring if it matches the approved method, not as a substitute for judgement.

Design physical protection in layers

Physical security should create successive barriers and useful detection. The appropriate layers depend on risk and site design.

Perimeter and entry

Consider site boundaries, external doors, loading areas, reception, visitor controls and separation from public space. Evidence may include approved access groups, visitor records, alarm tests and investigations of forced-door or door-held-open events.

Secure zones

Define zones such as common facility space, customer cage, network room and media store. Authorisation should become narrower as sensitivity increases. Avoid access profiles that grant every infrastructure technician entry to every zone.

Equipment and media

Protect racks, consoles, removable media, spares and retired equipment. Establish custody when assets enter, move within or leave the facility. Destruction certificates are useful only when they identify the asset population and authorised supplier.

Visitor and maintenance activity

Pre-authorise purpose, sponsor and permitted area. Verify identity, issue time-bound credentials and record escort requirements. Emergency access should be fast but still attributable and reviewed afterwards.

Protect the operating environment

Availability relies on more than duplicate servers. Evaluate:

• utility feeds, generators and uninterruptible power;
• fuel and maintenance dependencies;
• cooling capacity and environmental monitoring;
• water detection and drainage;
• fire detection and suppression;
• equipment placement and rack loading;
• cabling routes and physical separation; and
• alarm escalation during staffed and unstaffed periods.

Design evidence includes capacity analysis, diagrams, supplier specifications and approved thresholds. Operating evidence includes preventive maintenance, load or failover tests, alarm history, fuel checks and completed repairs.

Do not infer resilience from “two of everything.” Verify common dependencies. Two network providers may share a duct; two power feeds may converge upstream; redundant cooling may depend on one control panel.

Control network paths and administration

Physical control cannot compensate for an exposed management plane. Network safeguards commonly address:

• segmentation between production, management, backup and office networks;
• tightly controlled administrative entry points;
• strong authentication and privileged-session accountability;
• secure device configuration and change control;
• firewall and routing-rule governance;
• vulnerability and patch management;
• protection of network services and carrier interfaces;
• monitoring, time synchronisation and log protection; and
• detection and response for unusual activity.

Use architectural diagrams that reflect deployed paths. Validate them through configuration and traffic evidence. A diagram labelled “isolated” is weak if routes, jump hosts or emergency connections are not represented.

The Annex A control lookup can help teams explore relevant control themes before confirming exact treatment decisions in the licensed standards.

Integrate resilience and recovery

Data-centre controls should support service recovery objectives defined by the business. Identify which failures are absorbed locally, which require recovery elsewhere and which exceed the approved design.

Test credible scenarios: loss of utility power, carrier failure, cooling degradation, access-control outage, facility evacuation or corrupted configuration. Record assumptions, observations, recovery results, unexpected dependencies and improvement actions.

A generator test proves only the conditions exercised. It does not automatically prove sustained operation, cooling continuity, fuel availability or application recovery.

Govern suppliers and remote support

Contracts should reflect the risk and responsibility model. Relevant provisions may cover:

• permitted access and subcontracting;
• incident notification and cooperation;
• maintenance and emergency response;
• service levels and capacity;
• evidence and audit rights;
• asset return and secure disposal;
• change notification;
• continuity and exit arrangements; and
• protection of customer information.

Monitor actual performance. Review incidents, access populations, maintenance results, assurance exceptions and unresolved actions. When the provider controls evidence, agree in advance what can be shared securely.

Build a data-centre evidence map

For each material risk, identify control owner, operator, source system, review frequency and retention. Keep design and operating evidence distinct.

Area	Design evidence	Operating evidence
Physical access	Zone design and role rules	Access events, recertification and exception review
Environment	Capacity and alarm design	Sensor trends, alarm response and maintenance
Power	Resilience architecture	Load tests, generator runs and corrective work
Network	Approved segmentation and rule standards	Configuration samples, rule reviews and alerts
Suppliers	Contract and responsibility map	Service reviews, incidents and action closure
Recovery	Recovery design and dependencies	Exercise results and improvements

The evidence register guide shows how to index sources without collecting unnecessary copies of sensitive records.

Audit sampling that tests operation

Choose samples based on risk, change and previous weakness. A useful audit may:

1. select several active access holders and trace role approval;
2. sample leavers and role changes for timely removal;
3. inspect visitor and emergency-access events;
4. select environmental alarms and follow response to closure;
5. compare diagrams with device configurations and observed routes;
6. inspect maintenance work and supplier access; and
7. trace recovery-test findings into risk and improvement.

For outsourced sites, combine provider assurance with customer-side evidence. Confirm report period, scope, locations, exceptions and complementary customer responsibilities.

Pass

Risks reflected the real facility and service boundary. Physical, environmental, network and supplier controls had accountable owners, and samples showed consistent operation plus timely handling of exceptions.

Partial

Layered controls operated, but a carrier-path assumption was unverified and visitor records did not consistently identify the sponsor. Assurance was present but incomplete.

Fail

The organisation relied solely on facility certification, had no shared-responsibility map and could not produce current access reviews, environmental response records or network configuration evidence.

Common gaps

Watch for:

• scope that ends at the rack and ignores remote access;
• access groups copied forward without role review;
• visitor logs with no purpose or sponsor;
• alarms recorded but not investigated;
• nominal redundancy with common failure points;
• diagrams that do not match deployed routes;
• privileged accounts not attributable to individuals;
• supplier reports accepted without scope analysis; and
• tests completed without tracking lessons to closure.

The incident management evidence guide explains how events should feed risk, response and improvement.

The practical conclusion

Data-centre security under ISO 27001 is a risk-based system of layered safeguards and accountable operation. Define the complete service boundary, make shared responsibilities explicit, test common dependencies and connect physical protection with network administration, suppliers and recovery.

Auditable confidence comes from records across time: access decisions, alarms, changes, maintenance, tests, incidents and corrective work. A secure building matters, but sustained evidence that the whole service chain works matters more.

The subject perspective was informed by Advisera’s discussion of physical and network controls for data centres, with current ISMS purpose checked against ISO sources.