Which access logs and audit evidence you need for ISO 27001 certification, and how they integrate with the SIEM

For ISO/IEC 27001 certification you do not need to "have logs": you need to be able to demonstrate, for each Annex A control concerning access, which event constitutes its evidence, with which fields, for how long it is retained and who cannot alter it. The minimum core is successful and failed authentications, second-factor events, session lifecycle, changes to access rights and administrative actions — each with actor, object, UTC timestamp, origin, outcome and tenant and project context.

Step 1 — From controls to events

The Annex A controls of the 2022 revision do not list log events: they describe objectives. The work is translating each objective into the evidence that demonstrates it, and this table is the document worth taking into the audit.

Step 2 — The fields every record must carry

A log missing one of these fields is not useless, but it is not correlatable: and correlation is what separates an archive from a control.

{
  "id": "evt_7c1e2f",
  "type": "subject.authentication_failed",
  "createdAt": "2026-09-10T09:24:00Z",
  "tenant": "https://tenant.example.com",
  "data": {
    "subjectId": "sub_9f2a7c",
    "project": "prj_12ab",
    "outcome": "failed",
    "reason": "invalid_second_factor",
    "sourceIp": "203.0.113.42",
    "sessionId": "ses_1a9c4d"
  }
}

The subject is an opaque reference, not a name: the association with the person lives in the customer tenant. That is a useful property for the SIEM too, because it allows correlation without replicating personal data into a second system.

Step 3 — Retention, without the myths

One clarification that saves arguments: ISO 27001 does not mandate a log retention period. It mandates that the period be defined against business, legal and contractual requirements, that it be documented and that logs be protected throughout. The durations circulating as mandatory come from other frameworks or sector practices.

The middle column holds reference values, not prescriptions: the point is that your organisation picks its own, justifies them and honours them. An auditor accepts a justified 6 months; they do not accept 24 months declared and 30 days in practice.

Step 4 — Integrity: the forgotten control

Control 8.15 requires logs to be protected from tampering and unauthorised access. Translated into verifiable requirements:

• Append-only writing: no application path modifies or deletes an already recorded event.
• Separation of duties: whoever administers the system does not administer the log store.
• Immediate forwarding to a third system, so a compromise of the source does not erase the history.
• Time synchronisation via NTP, otherwise the timeline reconstruction of an incident does not hold.
• Tracing access to the logs themselves: consulting them is an event too.

Forwarding to a third system is the most effective requirement and the most often skipped: if logs stay only in the system producing them, whoever takes control of that system also controls the evidence.

A special case: actions the system does not allow

In architectures where certain operations do not exist — in LoginMaster no administrator can reset a password or disable a user's second factor — the corresponding control is demonstrated differently and more strongly: not with the log of an authorised action, but with the absence of the function from the system. You bring the architectural description to the auditor, and the question "who reset this credential?" needs no answer because it has no possible cases. Details on authentication vendors that cannot read passwords.

Step 5 — Getting events into the SIEM

LoginMaster records all security-relevant event categories — authentication, second-factor verification, sessions, administration, security — and makes them available to applications through HMAC-SHA256 signed webhooks and REST APIs. The native connector to enterprise SIEMs, with Syslog CEF over TLS and per-category selection, is on the roadmap: the current status is on the SIEM integration page. In the meantime forwarding is implemented by consuming the webhooks and relaying events to the collector, which is the pattern most custom integrations use anyway.

POST /v1/projects/prj_12ab/webhooks HTTP/1.1
Host: api.loginmaster.it
Authorization: Bearer ak_live_••••••••
Content-Type: application/json

{
  "url": "https://collector.example.com/hooks/loginmaster",
  "events": [
    "subject.authenticated",
    "subject.role_changed",
    "subject.deactivated"
  ]
}

Field normalisation is the step that makes events usable alongside other sources. The minimum mapping to the most common schemas:

Step 6 — The correlation rules to enable

Control 8.16 is about monitoring, not archiving: a SIEM that receives events and does not correlate them satisfies logging, not monitoring. These are the rules covering the most relevant access scenarios, and the ones an auditor expects to find active.

Every rule should be exercised with a controlled test and the result archived: proof that the rule works is more convincing than the rule itself.

Audit day: what gets asked

1. 1'Show me every access by this user in the last 90 days.' It must be a query, not a manual extraction.
2. 2'Who assigned this administrative role, and when?' You need the actor, not just the change.
3. 3'How do you prove nobody altered these logs?' Append-only, separation of duties, external forwarding.
4. 4'Show me the last periodic review of access rights.' The dated reconciliation report.
5. 5'What happens when someone attempts a brute-force attack?' Active rule, alert raised, test outcome.
6. 6'How long do you retain these events and where is that written?' The policy, and evidence it is honoured.
7. 7'Who can reset a user's credentials?' If the answer is 'nobody, the function does not exist', the entire following family of questions falls away.

The reconciliation report mentioned in point four comes from automating the lifecycle: the procedure is in User provisioning and lifecycle via REST API and SDK. The overall compliance picture, including NIS2 and GDPR, is on compliance.

Comparing collection approaches

Who wrote this guide

LoginMaster is the IAM platform of CDBKR S.r.l., an Italian company that designs and operates authentication infrastructure for software houses, MSPs and European enterprise organisations, with specific attention to European compliance requirements. The event categories cited are those published on SIEM integration, and the full regulatory picture is on compliance. To discuss a certification path: contact us.