Someone asks for everything a named contractor accessed in the second quarter.
It is not an unreasonable request. It is close to the most ordinary request in security operations, it comes up in audits, investigations and offboarding reviews, and most organizations can eventually answer it. The word doing the work in that sentence is “eventually”.
What comes back first
The first answer is a list of authentication events. This person connected at these times, from these addresses, with these methods, and the connection was permitted.
That is a real record and it is genuinely useful. It also does not answer the question that was asked. The question was what they reached; the answer describes that they were admitted.
The distinction is easy to lose because the system producing those records is usually called an access log. It is an admissions log. Everything it knows, it learned at the door.
Why the record stops at the door
This is not a logging deficiency, and it will not be fixed by increasing the log level.
If a product evaluates a request at connection time, establishes a path, and then steps out of the way, its records can only describe what it observed — and what it observed was the connection. The traffic that followed did not pass through it. There is nothing for it to withhold.
A component that remains in the path for the duration of the session is in a different position. Every request traverses it, so its record can describe resources rather than admissions.
Same question, two architectures, two different kinds of answer — and the difference is decided long before anybody configures logging.
So the answer gets assembled
Because the primary record is incomplete, the real answer is built from fragments. Everybody who has done this recognizes the shape of it.
Connection records from the remote access platform, to establish when the person was on. Application logs from each system they might have used, in whatever format each one produces. Directory group membership, to determine what they could have reached — though membership today is not membership in April. Jump server records, if there is a jump server. Possibly a ticketing system, to establish what they were supposed to be doing.
Then somebody correlates it. Timestamps in different zones, identifiers that differ between systems, a person whose account name changed when they moved teams.
It is skilled work, it takes days, and it is done under time pressure by people who had other commitments that week. The output is a narrative rather than a record — and a narrative assembled by inference is a weaker thing to hand an auditor than a record that was simply kept.
The gaps are structural
The harder problem is what correlation cannot recover.
If a session reached a system that produces no useful application logging — and the applications that resisted modernization are disproportionately in that group — then nothing anywhere recorded it. The remote access platform saw a connection. The application recorded nothing worth having. The access happened and left no trace.
The honest answer to “did they reach this system?” is then “we cannot tell”, which nobody wants to write down and almost nobody does. What gets written instead is what the evidence supports, with the systems that produce no evidence quietly absent from the report.
This is the part worth sitting with. The absence is invisible. A report assembled from the systems that keep records looks complete, because the systems that keep no records contribute nothing to it — including no indication that they are missing.
The three questions, and which ones you can answer
Audit requests reduce to three, and they have different evidentiary requirements.
Who had access to this system? Answerable from entitlements rather than logs, provided entitlements are reviewed and the review is evidenced. Most organizations manage this one.
Who used it, and when? Requires records tied to the resource rather than to the connection. This is where the assembly work starts.
What did they do while they were there? Belongs to the application, if it keeps such records and if they can be correlated to the person rather than to a service account.
An admissions log answers the first and gestures at the second. The gap between what the second question needs and what the connection record provides is the whole of the correlation exercise.
What a record kept at the right place looks like
If the enforcement point is in the path of every request, the request and the resource are in the same record, because it saw both.
That is the entire difference. Not a superior logging implementation — a position from which the useful facts are observable in the first place. Total Access Control terminates the session in front of the resource, so what it records is per-resource rather than per-connection, for every application it fronts.
The practical effect is that the quarter-of-a-contractor question becomes a query rather than a project. Which matters less for the audit than for everything else: the same record is what an investigation needs at two in the morning, and it is what a manager needs when somebody asks whether a leaver still had access to the thing they should not have.
A test worth running before someone asks
Pick a person and a quarter. Ask for everything they accessed, across every system, and note how long it takes and how many sources it draws on.
Then ask the harder half: which systems could they have reached that would not appear in that answer at all?
The first number tells you what an audit will cost. The second tells you what it will miss.