Look for logs that capture actual user activity, not only the fact that a connection occurred. For shell, database, and Kubernetes sessions, the useful evidence is command, query, and protocol-level detail that supports forensic review and accountability.
What counts as real audit evidence in an access platform?
Real audit evidence shows what an actor actually did, not just that a session existed. For security teams, that means the platform must preserve the commands, queries, or protocol events that occurred during the session, along with enough context to reconstruct who did what, when, and from where.
A connection-only record can prove access happened, but it cannot usually support forensic review or accountability. The evidentiary test is whether a reviewer can trace meaningful user activity back to a specific session and distinguish normal use from suspicious or unauthorized behavior.
For shell access, that means command capture or replay. For databases, it means query and transaction detail. For Kubernetes and similar administrative planes, it means API and control-plane actions that show the substance of the session, not just the login event.
Why connection logs are weaker than activity logs
Connection logs are useful for presence and timing, but they are not enough when an investigation needs to answer the harder questions. A session start, tunnel establishment, or successful authentication tells you that access occurred; it does not tell you whether the user ran a harmless status check or exfiltrated sensitive data.
That distinction matters because access platforms are often adopted specifically to reduce blind spots in privileged and remote work. If the product only records entry and exit, the organization still lacks the audit trail needed for incident response, supervision, and post-incident review.
When assessing a platform, look for evidence that supports reconstruction of intent and effect, not just connectivity. In practice, that means the log record should be detailed enough to survive a challenge from auditors, investigators, or internal reviewers who need to verify the sequence of actions.
What to verify before you trust the audit trail
Check whether the platform captures session content in a way that is attributable, searchable, and retained under policy. A defensible audit trail usually includes the actor identity, time stamps, target system, command or query text, and enough session metadata to correlate the record with other security telemetry.
Also verify that the evidence is tamper-resistant and retrievable at the point of need. If logs are easy to delete, cannot be exported, or lose meaningful detail after short retention windows, they may be operational logs but not reliable audit evidence.
For session types that support sensitive operations, the strongest test is simple: can a reviewer answer “what changed” from the log alone? If the answer is no, the platform may be recording access, but it is not yet giving you meaningful audit evidence.
Risk and Threat Considerations
When an access platform only records connection events, it creates an accountability gap that can hide misuse, make investigations inconclusive, and weaken deterrence. The same gap also makes it harder to prove that elevated access was used appropriately during a security incident or privileged maintenance window.
Failure mechanism: The control captures authentication and session establishment but omits the underlying actions, so later reviewers cannot reconstruct behavior or separate legitimate work from abuse.
Impact: Security teams lose forensic value, auditors may reject the evidence as insufficient, and adversaries who obtain valid access can operate with less chance of detection or attribution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Session activity evidence depends on recording meaningful audit events. |
| AU-12 — Audit Record Generation | The platform must generate records rich enough for forensic review. | |
| AU-9 — Protection of Audit Information | Audit evidence must remain trustworthy and resistant to tampering or deletion. | |
| Recommendation — Log session actions, not just connections, so reviewers can reconstruct user behavior. Generate audit records that capture commands, queries, and control-plane actions. Protect audit logs from alteration, deletion, and unauthorized access. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Audit logs must be collected and retained with enough detail for investigation. |
| Recommendation — Centralize and retain detailed session logs for investigation and accountability. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging control selection fits the need for actionable session evidence. |
| Recommendation — Require logs that capture user actions and support review of security events. | ||
Practitioner Guidance
What to prioritise: Treat command, query, and control-plane capture as the minimum evidence standard for shell, database, and Kubernetes access. A platform that cannot preserve the substance of the session should be treated as a visibility layer, not a control that closes the audit gap.
What to verify: Test a real session end to end and confirm you can retrieve the exact activity, correlate it to the authenticated user, and retain it long enough for investigation and review. If the evidence cannot support a basic “who did what” question, it is too thin for audit use.
Common mistake: Teams often accept “session recorded” as equivalent to “audit-ready,” then discover during an incident that the recording has no usable detail or cannot be searched efficiently.
Practitioner takeaway: The platform is only giving you real audit evidence if it captures the action, not just the access, and does so in a form that can be reviewed, retained, and trusted under scrutiny.
Related resources from NHI Mgmt Group
- How can security teams tell whether an access platform is actually reducing risk?
- How can security teams tell whether their access tracking is good enough for audit?
- How should security teams evaluate whether an access governance platform can handle real-world access changes end to end?
- How can security teams tell whether NHI access reviews are missing the real risk?