Skip to main content

From decision logs to compliance evidence

Objective​

Explain at a high level how masked decision logs plus Writ replay produce evidence relevant to HIPAA, DORA, the EU AI Act, SOX, and SOC 2, and attribute framework requirements rather than restating them as product guarantees.

Concept​

Auditors do not ask to see your policy engine. They ask you to prove a control worked: that access was restricted, that the restriction was enforced, and that you can show it after the fact. A masked decision log is that proof in a durable form. Each event says who requested what, what the PDP decided, the reason, and the obligations, with sensitive identifiers already redacted.

Three properties of the decision-log model do the work:

  • Completeness. Continuous authorization logs every decision, so the evidence is a full record, not a sample.
  • Integrity. Writ collects signed decision logs, so an auditor can trust the log was not altered after the fact.
  • Replayability. Because the event captures input and the policy version, Writ can re-evaluate a past decision. That answers "was this access correct under the policy in force at the time," which is the question behind most access findings.

Here is how that maps to common frameworks, at a high level. Treat these as how the evidence lines up, and confirm exact control language with your auditor and the framework text; the requirements below are attributed to their frameworks, not asserted as EnforceAuth capabilities.

  • HIPAA (health data, US). The Security Rule calls for audit controls and access controls over electronic protected health information, and its minimum-necessary principle limits access to what a role needs. A decision log of clinical-record access, with SSN and MRN masked, is evidence that access decisions were made and recorded. The lab's care-team check models a minimum-necessary style rule.
  • DORA (financial entities, EU). DORA emphasizes ICT risk management and traceability of access to critical systems. Signed, replayable decision logs support the traceability and audit expectations it places on financial entities.
  • EU AI Act. For high-risk AI systems the Act calls for automatic logging of events and record-keeping over the system's lifecycle. Decision logs for AI-workload authorization, what an agent was allowed to do on whose behalf, are the kind of record that expectation points at.
  • SOX (financial reporting, US). SOX drives controls over access to financial systems and separation of duties. A complete allow/deny log is evidence that access controls over in-scope systems operated as designed.
  • SOC 2. The Trust Services Criteria include logical access controls and monitoring. Decision logs are direct evidence for the access-control criteria and feed the monitoring the criteria expect.

The common thread: the framework demands a durable, trustworthy record that access decisions were made, enforced, and reviewable. The decision-log model produces that record; masking keeps the record from becoming a new exposure; Writ makes it signed and replayable. What you attest to your auditor is your control, EnforceAuth supplies the evidence, it does not certify you compliant.

One caution on marketing claims. EnforceAuth blog material cites figures such as a very high ratio of non-human to human identities and named agent incidents to motivate continuous authorization. Those are marketing claims. Cite them as such when you use them to make the case for logging; do not present them to an auditor as measured facts from your environment.

Hands-on lab​

There is no new policy for this lesson; the evidence lesson reuses the lab you already ran. Re-run it and read the output as an auditor would:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/decision-logs-and-compliance-evidence -v

For each passing test, name the evidence it stands in for. These are teaching illustrations, not attestations: the framework language is attributed in the concept section, and a real attestation comes from your own logs reviewed with your auditor. test_care_team_member_can_read and test_non_care_team_clinician_denied together model a minimum-necessary access control of the kind HIPAA's Security Rule describes. test_break_glass_allows_with_justification shows an emergency-access path that still produces an obligation, exactly the kind of exception an auditor wants logged rather than hidden. test_mask_redacts_ssn_and_mrn_from_event shows the log itself does not carry the SSN or MRN, so the evidence does not become a new PHI exposure. Write one sentence per test connecting it to a framework expectation from the concept section.

Check for understanding​

  1. Name the three properties of the decision-log model (completeness, integrity, replayability) and, for each, one thing it lets an auditor do.
  2. Which framework's minimum-necessary principle does the lab's care-team check most directly model?
  3. EnforceAuth cites a high non-human to human identity ratio and named agent incidents. How should you present those numbers to an auditor, and why?