Here is a question worth asking your compliance team: how long would it take to produce the evidence package for your next ISO 27001 or SOC 2 audit if the auditor announced it today?
If the answer is measured in weeks, your organisation is not compliant. It is compliant-looking, periodically, when someone assembles the evidence. The compliance posture that exists between audit cycles, the one where access reviews are delayed, deprovisioning records are incomplete, and monitoring logs are available but unreviewed, is the actual posture. The packaged evidence is a retrospective reconstruction of something that may or may not reflect how controls operated during the period.
ISO 27001:2022 Clause 9.1 requires monitoring and measurement to evaluate ISMS effectiveness, with retained evidence. It does not say evidence assembled before the audit. SOC 2 CC7.2 requires continuous monitoring of system components for anomalies. DPDPA Section 10(2)(c)(ii) requires periodic audit measures for significant data fiduciaries. RBI Cybersecurity Framework clause 30(f) specifically describes a continuous auditing approach for critical systems.
None of these frameworks describes a quarterly scramble. They are describing a state. This blog covers what that state looks like architecturally, why most organisations are not in it, and what changes when the evidence is generated continuously rather than assembled on demand.
The Difference Between Compliance and Compliance-Looking
Compliance, in the sense that ISO 27001, SOC 2, and DPDPA mean it, is an operational state. The controls are configured correctly. Access reviews run at the required cadence. Deprovisioning happens when it is supposed to happen. Monitoring is active. The evidence of each of these exists in the system as a byproduct of the controls operating.
Compliance-looking is a documentation state. The evidence package submitted to an auditor accurately represents what the controls looked like during the evidence collection period. Whether the controls operated that way for the other ten months of the year is not visible in the package.
The practical distinction is who bears the risk. In a genuine compliance posture, gaps are discovered when they occur, because monitoring is active. In a compliance-looking posture, gaps are discovered during audit preparation, when the window for remediation has closed. A deprovisioning that was missed three months ago cannot be remediated retroactively. An access review that did not run in Q2 cannot be backdated to show that it did.
The evidence quality standard that ISO 27001 Type II and SOC 2 Type II audits are moving toward reflects this distinction. Auditors are increasingly looking not just at the evidence submitted but at whether the controls that produced the evidence were operating throughout the audit period. A quarterly access review completed once in the last week of the period is weaker evidence than four access reviews completed at regular intervals.
What Each Framework Actually Requires
ISO 27001:2022 Annex A and Clause 9
Annex A Control A.8.4 requires periodic review of user access rights, with documentation of the review. Periodic implies a cadence that runs regardless of audit timing. The Akku IGA access recertification report satisfies this requirement when it is generated at the defined cadence and stored in the audit log. The report captures the reviewer identity, the access scope reviewed, the timestamp, and the decision made for each entitlement.
Annex A Control A.8.2 requires access rights to be removed when employment terminates. The evidence is a User Lifecycle Management offboarding record with a timestamp showing that access was removed at the time of the termination event, across all connected systems. A record produced at the time of the event is different from a record assembled in response to an auditor’s request.
Clause 9.1 requires the organisation to retain evidence of monitoring and measurement results. This is the catch-all: the audit log exports, the access monitoring reports, the authentication event records. They need to exist as a continuous output of the controls operating, not as exports triggered by audit preparation.
SOC 2 Trust Services Criteria
SOC 2 CC6.3 requires that access is authorised, modified, or removed based on roles and responsibilities. The Type II audit evaluates whether this control operated throughout the audit period. The evidence is the access change log showing that modifications and removals occurred when the corresponding role changes and departures occurred, not at a point in time near the audit window.
SOC 2 CC7.2 requires monitoring of system components for anomalies indicative of malicious acts. The Akku PAM session recordings and security monitoring alerts contribute to this evidence base when they are generated continuously as an operational output. An anomaly detected in real time and logged in the audit trail is different evidence from an anomaly that would have been detectable if someone had reviewed the logs.
DPDPA Rules 2025
DPDPA Section 8(4) requires data fiduciaries to implement appropriate technical and organisational measures to ensure effective observance of the Act. At the access governance level, the evidence is the IGA access review records and the ULM deprovisioning records demonstrating that access to personal data systems was reviewed periodically and revoked when the basis for access ended.
For organisations classified as significant data fiduciaries, Section 10(2)(c)(ii) requires periodic audit measures. The evidence base for that audit is the access governance records generated during the audit period. An IGA access recertification report generated three weeks before the audit is weaker evidence than four quarterly reports generated throughout the year.
RBI Cybersecurity Framework
RBI clause 15(a) requires IT applications with access to critical or sensitive information to have audit and system logging capability, providing audit trails. Clause 15(c) requires a system for regularly monitoring audit trails and system logs to detect unauthorised activity. Clause 30(f) describes continuous auditing for critical systems as a recommended approach for regulated entities.
These requirements together describe an architecture where critical system access is logged, the logs are monitored continuously, and the monitoring produces evidence that can be queried at any time. Akku’s centralised audit log and identity and access security monitoring satisfy clauses 15(a) and 15(c). The Compliance Reporting API consolidates compliance data across authentication events, GPO configuration state, and threat detection activity into a structured JSON output that GRC platforms and SIEM tools can consume programmatically.
What Continuous Audit Evidence Looks Like in Practice
Access Reviews That Run on a Schedule, Not on Request
Akku IGA generates access recertification campaigns at configured intervals. Each campaign produces a report documenting the review timestamp, reviewer identity, scope, and decisions. The reports are stored in the audit log and are queryable by date range and application. A compliance manager preparing for an audit queries the IGA access recertification history and retrieves four quarterly reports. The question of whether the access reviews ran during the period is answered by the data, not by the compliance manager’s recollection.
Deprovisioning That Happens When the Event Happens
Akku’s User Lifecycle Management generates a timestamped deprovisioning record for every offboarding event, capturing the user identity, the systems from which access was removed, and the timestamp of removal. The record is written at the time of the event. When an auditor asks for evidence that a specific departed employee’s access was revoked, the query returns a record with a timestamp that either matches the departure date or does not. There is no room for reconstruction.
Current compliance Visibility, Not Assembled
Akku’s Compliance Control Checkpoints View shows the real-time pass/fail status of every compliance control with the timestamp of the most recent supporting evidence. The Compliance Score generates an organisation-wide score with per-framework breakdowns across ISO 27001, SOC 2, HIPAA, GDPR, and DPDPA, updated as controls are remediated. A compliance manager reviewing the dashboard on any given day sees the current state of every control, not the state as of the last evidence collection exercise.
The Diagnostic Question
For each framework your organisation is subject to, ask this: if the auditor requested the evidence package today, how much of it already exists in a timestamped, queryable format in your systems? For financial services organisations under RBI’s audit trail requirements and for ITeS and BPO organisations under client compliance obligations, the gap between what exists continuously and what would need to be assembled is the gap between a compliance posture and a compliance-looking posture.
If the answer requires assembling anything, the architecture is reactive. The evidence is available somewhere. It is not maintained as a continuous operational output.
Explore Akku IGA Capabilities | See Akku Compliance Reporting API | Talk to the Akku Team
Questions Compliance and IT Teams Ask About Continuous Audit Readiness
Q: What is the practical difference between ISO 27001 Type I and Type II audit evidence standards?
A: A Type I assessment evaluates whether controls are designed appropriately at a point in time. A Type II assessment evaluates whether those controls operated effectively throughout a defined period, typically six to twelve months. The evidence standard for Type II is significantly higher: the auditor is looking for a pattern of operation over time, not a snapshot. A quarterly access review completed once in the final week of the audit period satisfies neither the spirit nor the letter of a Type II assessment. Four quarterly reviews conducted at regular intervals throughout the period do. This distinction is why the architecture that generates evidence continuously is not optional for organisations pursuing SOC 2 Type II.
Q: How does Akku’s Compliance Reporting API differ from a standard audit log export?
A: A standard audit log export is a raw output from a single system, typically requiring manual filtering, formatting, and cross-referencing with other systems before it is useful as compliance evidence. Akku’s Compliance Reporting API consolidates compliance-relevant data across authentication events, GPO configuration state, threat detection activity, and access change records into a single structured JSON endpoint. The output is timestamped, audit-traceable, and formatted for direct ingestion by GRC platforms and SIEM tools. It does not require a human to assemble it. It is generated programmatically and is current as of the moment it is queried.
Q: What evidence does Akku IGA produce for ISO 27001 A.8.4 access review requirements?
A: Akku IGA generates access recertification reports documenting each periodic review of user access rights. Each report captures the review timestamp, the reviewer identity, the access scope reviewed, and the decision made for each entitlement under review. The reports are stored in the Akku audit log and are queryable by date range, application, and reviewer. For a twelve-month audit period with quarterly access reviews, the auditor receives four timestamped reports from the audit log. The evidence demonstrates both that the reviews occurred and that they occurred at the required cadence.
Q: How does DPDPA Section 10(2)(c)(ii) apply to organisations that are not classified as significant data fiduciaries?
A: Section 10(2)(c)(ii) requires periodic audit measures specifically for significant data fiduciaries, which are organisations designated by the government as processing large volumes of personal data or data that poses a significant risk to data principals. Organisations not classified as significant data fiduciaries are not subject to this specific requirement. However, Section 8(4) applies to all data fiduciaries and requires technical and organisational measures to ensure effective observance of the Act. At the access governance level, this requires access reviews and deprovisioning records for personal data systems regardless of significant data fiduciary status. The distinction is in the audit mechanism, not in the underlying access governance requirements.
Q: How does the Compliance Control Checkpoints View connect to the underlying evidence in the audit log?
A: The Compliance Control Checkpoints View displays the real-time pass/fail status of each compliance control derived from the evidence records in the Akku audit log. When a control shows a pass status, it is because the underlying evidence, such as a recent access recertification report, an active MFA configuration, or a completed deprovisioning record, exists in the audit log and meets the evidence standard for that control. When a control shows a fail or gap status, it is because the evidence does not exist, is outdated, or does not meet the standard. The dashboard is not a separate assessment layer. It is a view into the same evidence that would be submitted to an auditor.
Q: What RBI Cybersecurity Framework requirements does Akku’s continuous monitoring architecture satisfy?
A: Akku’s centralised audit log satisfies RBI clause 15(a), which requires IT applications with access to critical information to have audit trail capability, and clause 15(b), which requires audit trails to be detailed enough to serve as forensic evidence. Akku’s identity and access security monitoring satisfies clause 15(c), which requires a system for regularly monitoring audit trails to detect unauthorised activity. For the continuous auditing approach described in clause 30(f), Akku’s Compliance Reporting API provides the programmatic, real-time access to compliance data that continuous auditing requires. The API output covers authentication events, GPO configuration state, and threat detection activity in a structured format suitable for automated analysis.
