Most data centre specifications still treat insider threat as an access control problem. Tighten permissions, add a stronger credential, add another biometric layer, deepen the audit trail.
That’s too narrow.
Data centre resilience is usually designed around continuity: keeping the facility running while maintenance, upgrades and operational work take place. Physical security often gets specified to a lower bar than that resilience logic, and insider threat is where the gap shows. In a live data centre, insider risk sits in the relationship between people, movement and operational necessity, not in the door on its own. NPSA’s insider risk guidance treats it as a people and process issue, and its data centre material reflects the reality of a mixed-site population: operators, client engineers, security teams, cleaners and maintenance contractors all moving through the same space.
Harmful access rarely starts with a failed credential check. More often it starts with a design assumption. A zone model that’s too broad. A service route that’s too permissive. A maintenance path too close to a critical space. A quiet shift that changes the risk while the access model stays put.
So the real point is this: insider threat in a data centre is usually a zone design problem, a shift pattern problem or a maintenance access problem before it’s a reader problem.
Access hierarchy only works if the zone model is right
The market isn’t short of access control: layered permissions by role, location and time, biometrics, anti-tailgating, full audit visibility. All of it useful. None of it rescues a weak zone structure.
Put a strong hierarchy on top of lazy zoning and the system just enforces a bad decision more efficiently. We still see facilities split into broad buckets, perimeter, plant, white space, admin, with credentials left to do the rest. Tidy on paper. Less tidy once operators start moving through it.
Insider opportunity lives in the seams between zones. Service corridor to riser. Riser to plant. Plant to support area. Support to cabinet row. If those transitions aren’t designed around real task needs, supervision and dwell time, the hierarchy becomes permissive exactly where it matters. The more useful question isn’t “what readers go here?” It’s “what movements should never become routine?”
Shift pattern is a security control
This is where a lot of specs go quiet. They add layers at key thresholds but say little about how those controls behave on a night shift, a weekend maintenance window or a reduced-staffing period.
A zone that’s well controlled at 11:00 on a Tuesday can be weak at 02:30 on a Sunday. Fewer witnesses. More reliance on remote monitoring. More pressure to get the job done. Activity that would stand out in core hours looks normal out of hours.
So a spec benefits from defining more than access rights. Access conditions: by time, by supervision model, by operational state. Different rules for low-occupancy periods, dual authorisation for selected tasks, temporary rights that expire on task completion rather than end of day. Most platforms already support this. Specs often just don’t ask for it clearly enough.
Maintenance access is where good intent becomes broad exposure
This is the one most often underestimated. Everyone accepts maintenance access is necessary. Fewer specs treat it as its own insider risk.
In practice it creates pressure for convenience. Engineers need to move fast. Faults don’t respect zone boundaries. Temporary works create temporary routes. Escorts get stretched. Access groups widen because uptime matters.
That’s exactly why it needs its own logic, not a line in the O&M pack. Maintenance-only paths that avoid higher-sensitivity zones where possible. Temporary rights tied to the work order. A clear line between accompanied and unaccompanied access. Review triggered by actual use, not an annual policy cycle. That’s a stronger posture than another reader outside the white space.
What we’d do differently
In resilient data centre environments, insider threat needs to be treated as a design condition, not a hardware schedule. The threat assessment must account for route logic, zone segmentation needs to reflect task pathways, and the access model should recognise that maintenance activity, shift state and supervision can all change the risk condition.
Biometrics matter. Audit matters. Hierarchy matters. None of it works properly unless the zone model reflects how the building is actually used, and unless physical security is held to the same resilience logic as the rest of the data centre design.
That’s the shift. Insider threat isn’t something the access control package solves later. It’s better placed in the spatial and operational logic while the zones are still being drawn, where the risk actually reduces and the spec becomes more useful to the operator who has to live with it.
If that’s a conversation worth having on a project you’re working on, talk to our data centre team.
