Logs that show authentication but not policy outcome, device state, or the reason for allow and deny decisions are weak evidence. If investigators cannot reconstruct why access was granted, the audit trail is incomplete for compliance and incident review.
When access logs do not explain the decision
The clearest warning sign is a log that proves something happened, but not why it happened. If your audit trail only records successful authentication, a session start, or a generic “allowed” result, it may still fail the real test: whether a reviewer can reconstruct the policy outcome, the triggering condition, and the basis for allow or deny.
Usable audit evidence should let an investigator answer three questions quickly: who accessed the ePHI, what they were allowed to do, and which rule or condition caused that decision. If the record stops at identity verification and never captures the authorization result, it is weak evidence for both compliance review and incident analysis.
A related sign is that the evidence looks operationally present but substantively empty. Teams may have logs from the application, VPN, or SSO layer, yet still be unable to show whether access was permitted because of role membership, patient assignment, emergency override, or another policy condition. That gap is often more damaging than no log at all, because it creates false confidence.
What incomplete evidence usually looks like in practice
Practitioners usually see the problem when logs are too coarse, too technical, or too detached from policy. A record that shows login success without device state, context, or authorization outcome cannot demonstrate that access controls actually enforced the intended decision. If a control is supposed to limit ePHI access by role, location, device posture, or purpose, the audit trail should reflect that control point.
Another common sign is inconsistency across systems. The identity provider may show authentication, the application may show access, and the policy engine may be silent or absent. When those records cannot be correlated, the organisation cannot prove that the access control was operating as designed. That makes recertification, incident triage, and external audit response much harder than they should be.
This is where role design and authorisation design matter as much as logging design. NHIMG’s Authorisation Models Guide is useful because it shows how RBAC, ABAC, ReBAC and policy-based access control create different evidence expectations. If the policy model is attribute-driven or relationship-driven, the audit trail needs to capture the evaluated attributes or relationships, not just the final yes or no.
When poor audit evidence becomes a control failure
The control has failed when investigators cannot replay the decision path with enough fidelity to explain access. That usually means one of three things: the system is not logging the decision context, the logs are not retained or correlated, or the access control itself is too implicit to be audited. In ePHI environments, the last problem is especially serious because access often depends on contextual exceptions and time-bound decisions.
Weak evidence also shows up when reviews rely on screenshots, manual attestations, or export files that are not tied to actual access events. Those artefacts may support a process review, but they do not prove that the access control enforced the right decision at the right moment. Auditors and investigators need records that are tied to live events, not retrospective summaries.
For organisations that manage broader identity governance as well as access, NHIMG’s IAM and IGA Basics is a strong reference point because it connects provisioning, access review, entitlements, and governance. If entitlement data and review evidence do not line up with actual access decisions, the governance process exists on paper but not in defensible practice.
Risk and Threat Considerations
Weak audit evidence is not just a reporting problem. It creates blind spots for incident response, makes inappropriate access harder to prove, and can conceal privilege misuse or repeated access outside expected policy conditions. In regulated healthcare settings, that is a material exposure because the organisation may be unable to demonstrate control effectiveness after the fact.
Failure mechanism: The access system records authentication or session activity but does not preserve the policy inputs, decision outcome, or device and context attributes needed to explain the authorisation event. As a result, investigators cannot reconstruct why ePHI was exposed or denied.
Impact: Compliance evidence becomes weak, exception handling becomes hard to defend, and incident review loses the ability to determine whether access was appropriate, excessive, or abused.
For this reason, audit evidence should be treated as a control output, not a logging byproduct. NHIMG’s Ultimate Guide to NHIs , Regulatory and Audit Perspectives is helpful where machine or service access touches regulated data, because it emphasises that governance must produce evidence of policy enforcement, not just access activity.
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 sets the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | ePHI access evidence depends on logging the right events and decision points. |
| AU-3 — Content of Audit Records | The question centers on missing decision context in audit records. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Usable evidence must support investigation and review of access decisions. | |
| Recommendation — Define audit events that capture access decisions, not just logins. Record the policy basis, outcome, and context needed to explain each access decision. Review audit trails for reconstructability and gaps in authorisation evidence. | ||
| SOC 2 (AICPA) | CC7.2 — CC7.2 | Audit evidence quality affects monitoring and incident investigation over access controls. |
| Recommendation — Validate that monitoring evidence can support investigations and control operation. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging must preserve enough information to support audit and incident review. |
| Recommendation — Log access events with sufficient detail to reconstruct control decisions. | ||
Practitioner Guidance
What to verify: Confirm that each meaningful ePHI access event can be tied to a decision record showing the user or process, the resource, the policy basis, and the final allow or deny outcome. If you cannot reconstruct that path from the logs alone, the control is not producing usable evidence.
What good looks like: A reviewer should be able to trace an access event from authentication through authorisation to the policy condition that justified the result, with enough context to explain why access was permitted or blocked. That is the standard that matters during an audit or after a security incident.
Practitioner takeaway: If your evidence proves identity but not decision logic, you have telemetry, not auditability. For ePHI, the decisive question is whether the record explains the control, not merely whether the system recorded activity.