Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated correctly over a defined period. The quality of that evidence determines the audit outcome. An organisation with strong technical controls but weak evidence infrastructure will produce an audit package that reflects what can be reconstructed rather than what actually occurred. An organisation whose controls generate continuous, structured evidence as a byproduct of daily operations will produce an audit package that reflects operational reality.
The evidence standard varies by framework. RBI Clause 15 requires forensic-grade audit trails suitable for dispute resolution. SEBI CSCRF GV.OC.S2(G3) requires on-demand log access in structured format. SOC 2 Type II requires continuous operating evidence sampled across the full audit period. ISO 27001 A.8.15 requires user activity logs, not authentication logs. DPDPA Clause 8(4) requires demonstrable proof that technical measures are operating. Each framework has specific evidence requirements, but the underlying infrastructure that produces the evidence is the same across all of them.
This blog covers the five categories of audit evidence that every major compliance framework requires, what each category must contain, what format and retention standards apply, and how IAM controls produce each category as a continuous output rather than a pre-audit compilation exercise.
Authentication event evidence is the foundational layer of every compliance audit evidence package. It establishes who accessed which systems, when, from where, and with what authentication assurance. Every framework reviewed in this series requires it.
A compliant authentication event record must contain actor identity tied to a unique, individual user account with no shared credentials. Timestamp with sufficient precision, ISO 8601 format with millisecond precision is the technical standard. Source IP address and resolved geographic location. Device identifier for sessions from managed endpoints. Authentication method including the specific MFA factor used. Outcome, success, failure, or blocked, with failure reason where applicable.
RBI Clause 15(a) requires authentication records with sufficient detail for forensic investigation. SEBI CSCRF PR.AA.S8 requires that every authentication event be logged. IRDAI ICS Items 54 and 55 require logging of failed authentication attempts and policy violations. ISO 27001 A.8.15 requires logging of security events including authentication failures. SOC 2 CC6.1 requires logical access security infrastructure that produces these records.
Authentication event logs must be stored in structured format, JSON or CSV, queryable by actor, system, time range, outcome, and MFA method. They must be append-only and tamper-evident. Retention periods vary by framework: most Indian regulatory frameworks expect a minimum of one year, with RBI-regulated entities typically maintaining two years for critical system access logs.
Every authentication event across all connected applications generates a structured log record automatically through Akku’s centralised authentication layer. The event stream is continuous, append-only, and exportable in JSON and CSV format via API or manual export. No manual compilation is required to produce authentication event evidence for any time period within the retention window.
Access provisioning and deprovisioning evidence covers the governance of how access was granted, modified, and removed. This is the evidence category that demonstrates need-based access, least privilege, and lifecycle management controls are operating as required.
A compliant provisioning record must contain the requester identity, the approver identity and approval timestamp, the justification for the access grant, the specific access being granted including system and role or permission level, the provisioning execution timestamp, and confirmation of downstream synchronisation to connected applications.
A compliant deprovisioning record must contain the trigger event, whether employment termination, role change, access review revocation, or consent withdrawal, the systems from which access was removed, the removal timestamp for each system, and where SCIM is used, the sync confirmation from each connected application.
RBI Clause 8(c) requires documented access governance with approval records. SEBI CSCRF GV.PO.S1 to S5 require technical enforcement of access policies with evidence. IRDAI ICS Item 6 requires controlled provisioning and removal of temporary and contractor accounts. ISO 27001 A.5.16 and A.5.18 require formal identity management and access rights processes. SOC 2 CC6.2 requires formal user registration evidence and CC6.3 requires access modification and removal evidence.
Provisioning and deprovisioning records must be structured and queryable by user, system, date range, and approver. Records must be retained for at least the duration of employment plus one year for deprovisioning records, and for at least two years for provisioning records covering access to critical systems. SCIM sync confirmation records must be retained alongside the IAM platform records to demonstrate end-to-end completion.
Every provisioning and deprovisioning event through Akku’s User Lifecycle Manager generates a structured record automatically. Access request and approval workflows capture requester, approver, justification, and timestamp at the time of the event. SCIM-based provisioning generates downstream sync confirmation records. Automated deprovisioning on exit generates a timestamped record of every account removed across every connected application at the time of the offboarding event.
Access review evidence demonstrates that entitlements were periodically examined and that access no longer appropriate was revoked. This is the evidence category that satisfies the periodic review requirements across every framework.
A compliant access review record must contain the review scope, which users and systems were included in the cycle. The review date and the identity of each reviewer. For each entitlement reviewed, the decision, certify or revoke, with a timestamp and the reviewer’s identity. For revocations, a corresponding deprovisioning record showing the access was actually removed following the revocation decision.
RBI Clause 23(a) requires periodic access reviews with documented outcomes. SEBI CSCRF PR.AA.S3 and PR.AA.S5 require periodic access reviews and recertification. IRDAI ICS Item 189 requires access reviews. ISO 27001 A.5.18 requires periodic review of access rights with documented evidence. SOC 2 CC6.3 requires that access be modified or removed based on the system of record for entitlements.
Access review records must be structured and queryable by review cycle, reviewer, user, and entitlement. For SOC 2 Type II purposes, review records from every cycle throughout the audit period must be available. Annual reviews produce a single evidence record that auditors can sample. Quarterly reviews produce four records per year, demonstrating consistent operation throughout the period.
Access review and re-certification campaigns in Akku generate timestamped records for every certification or revocation decision at the time of the review cycle. Campaign records capture scope, reviewer assignments, decision timestamps, and outcomes. Revocation decisions automatically trigger deprovisioning workflows, linking the review record to the corresponding access removal record.
Privileged session evidence is the evidence category that most organisations lack when they first approach compliance audits. Authentication logs confirm privileged sessions occurred. Privileged session evidence captures what happened during them.
A compliant privileged session evidence package must contain the session request and approval record including target system, access level, duration, justification, and approver identity. The session activity record at the protocol layer: keystroke logs for SSH sessions, SQL query capture for database sessions, screen recordings for RDP sessions. Session metadata including session ID, actor identity, target system, start and end timestamps, session duration, and termination reason and actor. Credential lifecycle events: credential generated, injected, and revoked, with timestamps.
RBI Clause 15 requires audit trails suitable for forensic investigation, which for privileged sessions requires session-level recording. SEBI CSCRF PR.AA.S12 requires that privileged session activity be logged with sufficient detail to reconstruct actions taken. IRDAI ICS Items 144 and 145 require session-level audit trail maintenance. ISO 27001 A.8.2 and A.8.15 together require privileged access control and user activity logging. SOC 2 CC5.2 and CC7.2 require general technology controls and anomaly monitoring for privileged sessions.
Session recordings must be stored encrypted. Keystroke logs and SQL query capture must be stored as structured data, searchable by timestamp, command string, or query text. Session metadata must be stored in structured format alongside or linked to recordings. Retention periods for privileged session recordings are typically two years for regulated entities, with longer retention for sessions involving access to regulated data categories.
SMARTAudit Trails capture every privileged session through AkkuReka at the protocol layer. SSH keystroke logs, SQL query capture for MySQL and PostgreSQL, and RDP screen recordings are generated automatically for every session. All recordings are stored encrypted, indexed for forensic search, and accessible from the Akku admin console. The session approval workflow record and AkkuArka credential lifecycle events are stored alongside each session record in the audit log.
For organisations subject to DPDPA and GDPR, consent and data principal rights evidence is a required evidence category covering how personal data processing was authorised and how Data Principal or Data Subject rights were fulfilled.
A compliant consent evidence record must contain the Data Principal or Data Subject identity, the notice version under which consent was given, the specific processing purpose, the consent timestamp, the channel, and the current withdrawal status with withdrawal timestamp if applicable. For each Data Principal rights request, the request type, submission timestamp, fulfilment actions taken, and fulfilment timestamp.
DPDPA Clause 6(7) requires that Data Fiduciaries maintain consent records. DPDPA Clause 8(4) requires demonstrable proof that technical measures are operating. GDPR Article 7(1) requires that controllers be able to demonstrate consent was given. GDPR Article 5(2) requires that controllers demonstrate compliance with data protection principles.
Consent records must be structured, queryable by Data Principal identity, processing purpose, notice version, and date range. They must be append-only: existing records cannot be modified, only new events added. Retention must cover the full period of processing plus sufficient time for regulatory examination. For DPDPA and GDPR, a minimum of three years after the last processing event is common practice.
Akku’s CIAM Consent Manager generates structured consent records for every consent event, update, and withdrawal. The consent record data model captures all required fields per Data Principal per processing purpose. The audit trail for every consent lifecycle event is append-only. Data Principal rights fulfilment workflows generate timestamped records of every request received and every action taken in response.
A complete audit evidence package for a regulatory examination draws from all five categories above. The assembly process is straightforward when the underlying evidence infrastructure generates continuous, structured outputs. It becomes a manual reconstruction exercise when evidence infrastructure is incomplete.
For an RBI IS audit, the package typically covers: authentication event logs for the examination period, provisioning and deprovisioning records for a sample of users including joiners and leavers, privileged session recordings for a sample of critical system accesses, access review records from the last review cycle, and MFA enforcement evidence showing consistent enforcement throughout the period.
For a SEBI CSCRF examination, the package adds: structured log exports in the format requested covering any period SEBI specifies, dormant account management records showing automatic disabling with timestamps, and endpoint compliance records from GPO Manager and MDM.
For an ISO 27001 certification audit, the package covers: user activity logs for privileged sessions across the audit period, access rights review records from each cycle in the certification period, provisioning records for all users onboarded during the period, and anomaly detection and monitoring records demonstrating A.8.16 operating effectiveness.
For a SOC 2 Type II audit, the package covers: provisioning records from across the full audit period sampled by the auditor, deprovisioning records for departures during the period, access review records from every cycle in the period, MFA enforcement evidence across the period, and endpoint control configuration records.
A defensible audit evidence package contains records generated at the time of each event, stored in tamper-evident format, with no gaps in coverage for the examination period. A reconstructed package contains records assembled before the audit from email threads, spreadsheet trackers, and log exports formatted for the occasion.
Auditors distinguish between the two through inconsistencies in timestamp formatting, gaps in coverage sequences, evidence that records were produced in batch rather than event-by-event, and inability to produce records for auditor-selected time windows outside the prepared sample.
The infrastructure difference is the same infrastructure this series has covered in each blog: a centralised IAM platform that generates structured, continuous, tamper-evident evidence as a byproduct of operating the controls it implements.
For any 30-day window within the last twelve months, can you produce a complete, structured authentication event log covering all connected systems without manual compilation from individual application logs?
For a sample of ten users who were onboarded and ten who departed during the last twelve months, can you produce the provisioning and deprovisioning records for each without reconstructing them from email history?
Do your access review records cover every cycle that ran during the last audit period, with timestamped decisions for every entitlement reviewed, or does evidence exist for only the most recent cycle?
For any privileged session to a critical system that occurred in the last 90 days, can you produce the session recording and structured activity log within the same business day of the request?
If a regulator requested a structured log export covering a specific 90-day period tomorrow, could your team produce it within 24 hours in a structured format ready for submission?
See how Akku generates continuous audit evidence across authentication events, provisioning records, access reviews, privileged sessions, and consent records from a single platform.
Book a conversation with the Akku team to assess the completeness of your current audit evidence infrastructure.
What makes an audit evidence package defensible versus one that will draw auditor scrutiny?
A defensible audit evidence package contains records generated at the time of each event, stored in append-only, tamper-evident format, with no gaps in coverage for the examination period. Records are structured and queryable, meaning the auditor can select any sample from any point in the period and receive a complete record. A package that draws scrutiny contains records assembled before the audit, with timestamps that suggest batch generation, gaps in coverage outside the prepared sample window, or formats inconsistent with records generated by operational systems at the time of events.
What is the minimum retention period for audit evidence across Indian regulatory frameworks?
Retention requirements vary by framework and record type. RBI-regulated entities typically maintain authentication event logs for two years and privileged session recordings for two years or longer for critical system access. SEBI CSCRF requires log retention sufficient for regulatory examination on demand, with industry practice at one to two years. IRDAI ICS requires retention defined in the organisation’s IT security policy, with one year as a common minimum. DPDPA and GDPR require consent records to be retained for the duration of processing plus a period sufficient for regulatory examination. Organisations subject to multiple frameworks should apply the longest applicable retention period for each evidence category.
How does SCIM connector failure affect the completeness of deprovisioning evidence?
SCIM connectors synchronise deprovisioning actions from the IAM platform to connected applications. A SCIM connector failure means that a deprovisioning action recorded in the IAM platform did not propagate to the connected application. The IAM platform record shows the deprovisioning occurred. The connected application still has an active account for the departed user. The deprovisioning evidence is incomplete because the record does not reflect the actual access state. Connector health monitoring detects these failures before they create access gaps, ensuring that the deprovisioning evidence in the IAM platform accurately reflects the access state in connected applications.
Why does SOC 2 Type II require evidence sampled from across the full audit period rather than a point-in-time sample?
SOC 2 Type II attests that controls operated effectively throughout the audit period, not only at a point in time. Auditors sample control outputs from multiple points across the period to verify consistent operation. A control that worked correctly for the month before the audit but has no evidence of operation for the preceding eleven months fails the operating effectiveness standard. The sampling approach is specifically designed to detect controls that are implemented for audit purposes but do not operate continuously. Continuous evidence generation throughout the period, not assembled before the audit, is the only way to satisfy the Type II sampling approach.
What structured export formats do Indian regulators typically require for log submissions?
SEBI CSCRF GV.OC.S2(G3) requires on-demand access to logs in a format accessible to SEBI for examination. In practice, structured formats including JSON and CSV are the standard for log submissions to Indian regulators. RBI IS auditors typically accept structured exports in either format. IRDAI examiners following the Annexure III checklist expect log evidence to be producible in structured format. The key requirement across all frameworks is that logs be queryable and exportable without manual reformatting, meaning the underlying log infrastructure must store events in structured format rather than unstructured text files.
Can audit evidence from Akku be submitted directly to regulators, or does it require additional formatting?
Akku’s audit log exports in JSON and CSV format are structured and contain all standard fields that regulatory submissions require: event ID, timestamp, actor identity, target system, event type, outcome, source IP, and geographic location. For most regulatory submissions, these exports can be submitted directly or with minimal formatting. For specific regulatory portals or reporting templates that require a defined schema, the structured export can be mapped to the required format. Session recordings from SMARTAudit Trails are accessible for in-browser playback and exportable for submission to auditors or regulators requiring forensic review of specific sessions.
Introduction GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be…
Introduction ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and…
Introduction SOC 2 CC6 is the Logical and Physical Access Controls criterion cluster and is where the majority of IAM-relevant…
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction SEBI CSCRF's Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…