Access Logging

Back to Data Center Management · Badge or Biometric Access · Visitor and Vendor Tracking · Cage or Rack-Level Restriction · Service Offerings

Access logging is a record of who entered and when, reviewable after the fact if something needs investigating. Most sites have the first half. The control is the second half, and it is the half that gets skipped.

A log nobody reads is not a control. It is evidence, available to whoever eventually goes looking, which is useful but entirely retrospective. What turns it into a control is somebody looking at it on a schedule, before anyone has a reason to.

1. What a Row Should Contain

• Who — the person, not the credential number. A log that requires a lookup table to be readable will not be read.
• When, from a clock synchronised with everything else you might correlate against. An unsynchronised door controller makes the CCTV comparison in section 4 guesswork.
• Which door, named the way people name it rather than as a controller address.
• Granted or denied, and for denials, why — unknown credential, valid credential without rights for that door, outside permitted hours.
• Direction, where readers exist on both sides. Entries without corresponding exits are how tailgating and shared cards become visible.

2. The Denials Are the Interesting Part

Granted entries are the bulk of the log and mostly tell you that the day happened. The rows worth a human's attention are the exceptions, which is what the illustration above is pointing at:

• Denied attempts, especially repeated ones, and especially a valid credential being presented to a door it has no rights to. That is either someone exploring, or someone whose access was set up wrongly — both worth knowing.
• Out-of-hours entries with no corresponding ticket or change record.
• First use of a dormant credential after months of silence.
• An entry with no exit, or an exit with no entry.
• Access by someone who should no longer have any, which is the leaver problem from badge access showing up in the log rather than in the access list.

Most of these can be alerted on rather than reviewed by eye, which is what makes the review sustainable. The monthly read-through then covers the pattern rather than the volume.

3. Retention Longer Than Discovery

The question a log answers is always asked later than the event. Set retention against how long it realistically takes to find out something happened — not against how long the system happens to keep by default, which is frequently thirty days and occasionally a fortnight.

• Twelve months is the usual floor, and it aligns with the observation period of a SOC 2 Type 2 examination, where this log is standard evidence.
• Export off the door controller. Many controllers keep a small circular buffer and overwrite silently. If the log lives only there, your retention is whatever the buffer holds.
• Check the retention is real by asking for a record from eleven months ago. Policies stating twelve months and systems holding thirty days coexist comfortably until someone tests it.

4. The People in the Log Must Not Control the Log

An audit trail administered by the people it records is not an audit trail. This is not an accusation of anyone; it is simply the property that makes the record worth anything.

• Export to a system under different administration — the same place your other log aggregation goes.
• Append-only storage, or at minimum a copy that facilities administrators cannot alter.
• Log the administrative actions too: credentials issued, rights changed, records deleted. Changes to who can enter are as interesting as entries.
• Alert if the feed stops. A door controller that quietly stopped reporting in March produces a clean log with nothing in it, which reads like a quiet period.

5. One Log Rarely Answers the Question

"Who was in the room when that server was unplugged" is not answered by door records alone. It is answered by lining several records up on a common timeline:

Which is the practical reason for the synchronised clock in section 1. Timelines that are four minutes apart are reconstructed by argument rather than by evidence.

6. In a Shared Facility, Half the Log Is Someone Else's

In colocation, the provider holds the records for the building and the hall; you hold the records for your own cage and cabinets, if you installed anything to produce them. Two things to settle in the contract rather than during an incident:

• That you can obtain the provider's records for entries to your space, within a stated time, including their own staff and remote hands.
• That you have your own at the cage and cabinet layer, so you are not entirely dependent on a third party's log for your own footprint.

How We Approach It

1. Find out what is recorded today, where it lives, and how long it genuinely survives — tested, not quoted from a policy.
2. Fix the fields, so a row names a person and a door and carries a synchronised timestamp.
3. Export to somewhere independent, with administrative actions logged too.
4. Define the exceptions worth alerting on, so the review is about patterns rather than volume.
5. Establish the review: who, how often, what they sign, and what happens to what they find.
6. Settle the colocation records you are entitled to, and close the gap at the cage layer.

What You Get

• A log whose rows name people and doors, on a clock that matches your other evidence.
• Retention proven by retrieval rather than asserted by policy.
• An independent copy that the administrators of the door system cannot alter, with their own actions recorded.
• Alerting on denials, out-of-hours entries, dormant credentials and missing exits.
• A documented review with an owner and a cadence, and a timeline procedure that lines the door log up with CCTV, visitors and change records.

The test is whether you could answer, next March, who was in the room at 02:17 last Tuesday — and whether anyone would have noticed at the time that someone was.