IAM audit readiness: access evidence for audits
IAM audit readiness is the ability to answer an auditor's access question from records that already exist. Keymate records every access decision with the policy version that made it and any approval behind it, so "who could do this, and who approved it?" is a lookup, not a log search.
The audit question, in the words auditors use
Auditors and supervisors ask much the same four access questions in every sector:
"Who could approve payments above the limit in March, and who approved that rule?"
"This user opened these records on the 14th. Was that allowed at the time, and by which rule?"
"When the contractor's engagement ended, when did the access end?"
"Show me every change to this access rule in the last year, with who made it and who signed it off."
None of them is a login question. Each asks who has access to what at a given moment, and who approved this access. A report of current role assignments shows who has access today, not at the moment the auditor asks about. It does not show who approved that access.
What access evidence looks like
Access evidence is a record that ties one access decision to the rule that made it and to any approval of that rule. Nobody can change it afterwards. Access control evidence for auditors has to pass three tests. It covers the period asked about. It shows the rule and any approval, as well as the outcome. It can be reproduced from the store instead of retyped into a spreadsheet.
Application logs usually do not show the approval. They show that a request succeeded, not which rule allowed it or who approved that rule. Keymate writes audit evidence for access control at the decision point, the component that allows or denies each request. It is the only place where the outcome, the rule and any approval are known at the same moment. Architecture shows where the decision point and the audit pipeline sit.
What one evidence record contains
Access decision logging in Keymate writes one evidence record for every allow and every deny. One record, as an example:
Example evidence record: decision deny with a decision identifier; user ana@acme-north.example of organization acme-north tried to approve a 72,000 payment; 14 March 2026 at 10:03 UTC; policy payments-approval version 14; why: the amount is above the approval limit of 50,000; approved by the risk lead on 2 March 2026
The policy change record. Each policy is a version-controlled access policy: every version is recorded with its author, the exact lines changed and the reason, and a version that has gone live is never rewritten. You can require an approver before any policy change reaches production, and the approval is stored with the version it approved. That gives the audit trail for policy changes the same shape as the decision record.
Time-bound grants. A grant made under time-bound access carries its end date and its approval from the day it is approved, so the question about the contractor is answered by the grant itself.
What Keycloak records on its own, and what Keymate adds
Keycloak records two kinds of events. User events cover logins and failed logins. Keycloak admin events cover changes made through the admin console or the admin API. Both are off in a new realm, and you choose how long each is kept. Turned on, they are a useful Keycloak audit log for sign-ins and configuration changes.
Those events are not Keycloak audit evidence for access decisions. They do not record each authorization decision with the policy version behind it. A change to a Keycloak authorization policy takes effect when it is saved, so there is no approval to record. For Keycloak compliance in an access audit, Keymate adds the two records that are missing: one for each decision, and one for each policy change, with any approval.
Evidence for your DORA and NIS2 conversations
DORA and NIS2 both ask regulated organizations to control access and to show that they do. Keymate supplies the access part of that evidence. It does not make an organization compliant, and it holds no DORA or NIS2 attestation: compliance is assessed for your organization, by your auditors and supervisors.
- DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) applies to financial entities in the EU. As part of ICT risk management, Article 9(4)(c) requires them to limit access to what legitimate and approved functions require. The technical standards under it (Delegated Regulation (EU) 2024/1774, Articles 20 and 21) set out identity management and access control in detail. Questions about DORA ICT risk identity management trace back to these articles. DORA access control requirements turn into questions such as "show that this access was approved, and show when it ended."
- NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across sectors. Its cybersecurity risk-management measures include access control policies (Article 21(2)(i)), which is where NIS2 identity and access management questions sit. NIS2 access control requirements turn into questions such as "show your access policy, and show that it is what was enforced."
| What the conversation asks | The evidence Keymate supplies |
|---|---|
| Access is limited to approved functions | Each decision with the policy version that made it, and any approval of that version |
| Changes to access rules are controlled | The policy change record: author, lines changed, reason and any approver |
| Access ends when the reason ends | Time-bound grants with their end date and approval |
| The record can be trusted | An immutable store on your infrastructure; records cannot be edited after they are written |
| Incidents can be traced | The decision identifier in your monitoring, linked to the record |
- What the conversation asks
- Access is limited to approved functions
- The evidence Keymate supplies
- Each decision with the policy version that made it, and any approval of that version
- What the conversation asks
- Changes to access rules are controlled
- The evidence Keymate supplies
- The policy change record: author, lines changed, reason and any approver
- What the conversation asks
- Access ends when the reason ends
- The evidence Keymate supplies
- Time-bound grants with their end date and approval
- What the conversation asks
- The record can be trusted
- The evidence Keymate supplies
- An immutable store on your infrastructure; records cannot be edited after they are written
- What the conversation asks
- Incidents can be traced
- The evidence Keymate supplies
- The decision identifier in your monitoring, linked to the record
For Keycloak DORA compliance and NIS2 alike, Keycloak's own events answer questions about logins and admin changes. Questions about who was allowed to do what, and who approved the rule, need Keymate's decision and policy change records.
Where the records live and how auditors receive them
Evidence records are kept in an immutable store on your infrastructure. How long they are kept follows your own retention policy, and nothing reports back to us. The audit pipeline masks personal data before a record is stored, so a record sent to an auditor or a monitoring team carries less about a person.
Decision observability is a live stream of every allow and deny, exported over OpenTelemetry to the monitoring you already run. Security tools that need the evidence records themselves, such as your SIEM, subscribe to audit events through Keymate's event subscription API, over gRPC or REST.
Auditor reports are built from the same records, so a report and the records behind it always agree. A report lists the decisions, the policy versions in force and any approvals behind them, and every line can be traced back to its record.
What an audit request involves today, and what changes
Today: role exports, application logs and an approval ticket are reconciled in a spreadsheet. With Keymate: one query returns the decision, the policy version and any approval in one record
Today, an auditor's access question usually starts a collection exercise. You export role assignments from each system and search application logs for the requests. You find the ticket or email where the rule was approved. Then you reconcile the three in a spreadsheet. The work repeats for every request, and the result is only as good as the logs that happened to be kept.
With Keymate the three facts are written together when the decision is made. Answering becomes a query against one store, and the decision, the policy version and any approval come back as one record. The same query answers the next request.
Further reading
- Keycloak security mistakes: eight common Keycloak security mistakes, most of them defaults, each checked on Keycloak 26.8, including user and admin events, which are off in a new realm.
- What is identity and access management: the four jobs of an IAM system, and the four access questions that come up in every regulation, from GDPR to DORA.
Questions
How do I get an audit trail of authorization decisions in Keycloak?
An audit trail of authorization decisions in Keycloak has to come from a decision point that records each allow and deny. Keycloak's own events record logins, token issuance and admin changes, but not each authorization decision with the policy version that made it. Keymate records every allow and deny for the realms you move into Keymate's own Keycloak build, with the user, the resource, the policy version and any approval behind it, in an immutable store on your infrastructure.
How do I prove access control compliance under DORA?
You show that access is limited to approved functions, that changes to access rules are controlled, and that access ends when its reason ends, with records for the period under review. Keymate supplies those records for the access part: each decision with its policy version and any approval, every policy change with any approver, and time-bound grants with their end date. Keymate does not make an organization compliant; the assessment is your auditors' and supervisors'.
What evidence does an auditor want for access decisions?
An auditor wants to see, for a given period, who was allowed to do what, under which rule, and who approved that rule, in a record that cannot have been edited since. Application logs rarely show the rule or the approval. A Keymate evidence record holds the decision, the policy version that made it and any approval of that version, so they come back together.
How do I demonstrate NIS2 access management compliance?
NIS2 Article 21(2)(i) lists access control policies among the risk-management measures, so you demonstrate it with the policy itself, evidence that it was the policy enforced, and a record of how changes to it were approved. Keymate keeps the policy as versioned objects, with any approval of each version, and records every decision against the version in force, which covers the access control part of the NIS2 risk-management measures. Keymate holds no NIS2 attestation; the evidence supports your organization's own assessment.
Which platforms show audit-ready logs of every access grant and revocation automatically?
Look for three things: records written at the point of decision, not only as role changes in a directory; each allow and deny tied to its policy version and any approval; and an end date on every time-bound grant. Keymate meets all three, and records them automatically. A revocation shows up twice: as the policy version or expired grant that removed the access, and as the first deny that followed. Our IAM platform comparison sets several platforms side by side.
How do I answer "who can do what" across multiple Keycloak instances?
Answer it from one evidence store instead of an export from every instance: move each Keycloak instance's realms into Keymate's own Keycloak build with Keycloak's realm export and import, and every allow and deny is then recorded in one place with the user, the resource and the policy version. Authorization Governance covers how the rules themselves are governed.
See the record an auditor gets for every access decision.
Evidence records, auditor reports and time-bound access are part of Authorization Governance.