ISO 27001 Evidence from Okta System Logs

Why this matters for ISO 27001

ISO 27001 Annex A control A.9.4.2 (Secure Log-on Procedures) asks for direct evidence that log-on is controlled, monitored, and resistant to common attack patterns — exactly what an identity provider’s system log is built to capture. For organizations using Okta as their primary IdP, the System Log is typically the single evidence source an ISMS auditor will request first for the entire A.9 (Access Control) domain.

What evidence the Okta System Log provides

• A complete authentication audit trail supporting A.9.4.2, including failed attempts, lockouts, and successful sign-ins
• Evidence of network access restriction enforcement when paired with Okta’s network zone and device trust policies (A.9.1.2)
• A record that can demonstrate password policy and lockout threshold enforcement is more than a written policy — it’s an observed control
• Cross-application visibility, since Okta federates into every downstream SaaS app, making this one log source cover a disproportionate share of the access-control domain

How LogTriage maps this to ISO 27001

Credential-stuffing and brute-force detections map directly to A.9.4.2 (Secure Log-on Procedures), and detected reconnaissance or initial-access patterns map to A.9.1.2 (Access to Networks and Network Services). The mapping is generated deterministically for every report, independent of whether the event volume was high enough to trigger a full AI-generated narrative.

Evidence checklist

• Export Okta System Log coverage for the full ISMS evidence period, not just a sample
• Document lockout policy configuration and retain evidence it triggered during any detected brute-force attempt
• Confirm network zone restrictions are configured for sensitive applications, and retain evidence of zone-based denials
• Map each Annex A control you’ve selected in your Statement of Applicability to a specific, retrievable Okta log field
• Retain a documented record of any access-control incident investigation, tied to the specific log entries that triggered it