When did you last run a compliance evidence collection that did not surface something unexpected?
Not a gap in your controls. Something more mundane than that. A SCIM connector that failed three weeks ago that nobody noticed because there was no monitoring on it. A provisioning record that shows an offboarded user as deprovisioned, but the application itself still has the account active because the sync did not complete. A GPO configuration that drifted during a patch cycle and was never reverted. None of these are dramatic failures. They are the kind of thing that shows up when someone starts pulling data for an audit and the data does not match what the platform said it was.
The reason this keeps happening is not carelessness. It is architecture. The evidence that compliance audits require does not live in one system. Authentication logs live in the IAM platform. GPO configuration states live in Active Directory. Threat detection events live in the SIEM or the security monitoring layer. Provisioning records live in whatever system runs your identity lifecycle. Getting all of that into one place, in a format an auditor can use, requires a person to do it manually every single time.
That person assembles the evidence. They reconcile the formats. They discover the gaps. They fix what can be fixed before the package goes out. And the package that results reflects the state of the environment during the collection window. Not today. The window when someone was pulling data.
This blog is about why that architecture cannot satisfy what ISO 27001:2022 and DPDPA Rules 2025 actually require at the evidence level, and what changes when compliance data becomes something your systems produce continuously rather than something your team assembles under a deadline.
The Evidence Collection Problem Is Not a Process Problem. It Is an Architecture Problem.
Most compliance teams treat audit preparation as a sprint. In the weeks before an audit, the team runs harder, pulls more data, and patches what they can before the auditors arrive. The sprint is exhausting and it is built into the annual calendar as an accepted cost.
But the sprint is not the real problem. The sprint is a symptom of a compliance architecture where evidence only gets collected when someone needs it. Between audits, controls drift. Connectors fail. Policies get modified and not reverted. None of that is visible because nobody is looking. The audit creates the forcing function to look, which is why the looking almost always surfaces something.
The architecture problem has three specific components that compound each other.
No Unified Evidence Surface
The data that compliance audits require is distributed across systems that were not designed to produce evidence together. The Akku IAM platform holds authentication events and provisioning records. Active Directory holds GPO configuration states. Your SIEM holds threat detection events. Your ticketing system holds access request and approval records. Each of these is a valid data source. None of them produce a unified, audit-ready output without a person in the middle connecting them.
The practical consequence: every audit cycle requires someone to navigate each system, export data in that system’s native format, reconcile the exports, and reformat everything for the auditor’s requirements. For organisations managing compliance across ISO 27001, SOC 2, HIPAA, and DPDPA simultaneously, the same data gets extracted and reformatted multiple times for different framework requirements.
Evidence Is Always Retrospective
Manual evidence collection produces a snapshot. The snapshot is accurate at the time it is taken. By the time it reaches the auditor, the environment has continued to evolve. If your MFA enforcement policy was modified for a department two weeks after the evidence was collected, that modification is not in the compliance package. The auditor is reviewing a state that no longer exists.
ISO 27001:2022 Annex A Control A.8.16 requires ongoing monitoring for anomalous behaviour. The 2022 revision was explicit about this: the standard moved from periodic review to continuous monitoring. A compliance programme that collects evidence periodically and reviews it before audits does not satisfy A.8.16 as written in the current version of the standard. It satisfies the 2013 version’s intent. That distinction matters at recertification.
Gaps Are Found During Collection, Not Before
The most operationally damaging aspect of manual evidence collection is that it is often the first time anyone discovers that something went wrong. The SCIM connector failure that left offboarded users with active entitlements is discovered when someone cross-references the HR departure log against the provisioning records during audit prep. The GPO drift is discovered when someone exports the current configuration and compares it manually against the baseline. The discovery happens at the worst possible time, when the audit is imminent and there is no runway to investigate properly.
A compliance architecture that detects these gaps continuously rather than at collection time changes the operational dynamic entirely. The gap is found when it opens, not when the auditor is two weeks away.
What ISO 27001:2022, DPDPA Rules 2025 and RBI Actually Require at the Evidence Level
The frameworks that govern financial services, healthcare, and ITeS organisations in India are not ambiguous about what evidence they expect. But there is a meaningful gap between what the frameworks say and what most compliance programmes produce.
ISO 27001:2022: Continuous Monitoring Is the Requirement, Not the Aspiration
Control A.8.15 requires that event logs recording user activities, exceptions, and information security events are produced, stored, protected, and analysed. The key word is analysed. A log that is stored but only reviewed before audits has not been analysed in any operationally meaningful sense. The control requires active review, which implies continuous or near-continuous monitoring rather than periodic batch review.
Control A.8.16 is more direct. It requires ongoing monitoring of networks, systems, and applications for anomalous behaviour. The 2022 revision added this requirement specifically because the 2013 version’s periodic review approach was insufficient. An organisation that reviews authentication logs quarterly is not satisfying A.8.16. An organisation with a monitoring layer that evaluates authentication events continuously is.
The practical implication for compliance reporting: the evidence package that an ISO 27001:2022 audit expects is not a quarterly snapshot. It is evidence that the monitoring controls were operating continuously over the audit period. That evidence can only come from a system that was actually monitoring continuously, not from a system that collected data before the audit.
DPDPA Rules 2025: Access Accountability Has to Be Demonstrable on Demand
The Digital Personal Data Protection Act requires data fiduciaries to implement appropriate technical and organisational measures to protect personal data. The word appropriate is doing significant regulatory work here. Under DPDPA, an appropriate technical measure for access control is not a policy document and not an annual access review. It is a technical system that can demonstrate, at any point, that access to personal data is restricted to authorised individuals, that access rights are reviewed and kept current, and that access is removed when it is no longer required.
The data protection board under DPDPA has broad investigatory powers. A supervisory review does not arrive with six weeks of notice. It can arrive when something has gone wrong. If your ability to demonstrate access accountability depends on a manual evidence collection process that takes several days to run, your compliance posture for DPDPA is contingent on having time to prepare. That is not an appropriate technical measure. That is a documentation process.
DPDPA compliance for organisations handling personal data at scale requires that the access accountability evidence is continuously maintained and retrievable on demand. Not assembled when asked for it.
RBI Cybersecurity Framework: Near-Real-Time Is the Stated Standard
The RBI Cybersecurity Framework for scheduled commercial banks requires near-real-time log analysis and audit trails that support forensic investigation. For financial services organisations under RBI oversight, the expectation is that authentication anomalies, privileged access events, and configuration changes are being monitored as they occur. The audit trail exists as a byproduct of that monitoring, not as a separately assembled evidence package.
For organisations currently satisfying RBI requirements through periodic log review, the gap between the framework’s stated standard and the current implementation is a matter of regulatory record. The framework is explicit. The implementation is not matching it.
What Changes When Compliance Data Is Produced Continuously Instead of Collected Manually
The Akku Compliance Reporting API provides a single REST endpoint that returns consolidated compliance data programmatically, on demand or on a configured schedule. Rather than requiring a person to log into multiple systems and extract data, the API produces structured JSON output that covers the three evidence domains auditors request most frequently across ISO 27001, SOC 2, HIPAA, RBI, and DPDPA reviews.
Authentication Events and Login Activity
The API returns total login counts, success and failure rates, MFA failure events with method attempted and failure reason, account lockout events, and recovery attempt activity. Each event is timestamped at the millisecond level and tied to a user identifier. The output is structured JSON compatible with direct ingestion into GRC platforms like ServiceNow GRC and Archer, and into SIEM platforms including Splunk, IBM QRadar, and Microsoft Sentinel. For ITeS and BPO organisations that face client audits with short notice and need to produce structured authentication evidence quickly, this changes the response time from days to the duration of an API call.
GPO Configuration State and Change History
GPO configuration is one of the most frequently requested evidence categories in ISO 27001 and RBI audits. The auditor wants to know what policies are applied, whether they match the required baseline, and whether anything has changed since the last review. Currently, producing that evidence requires a manual export from the Group Policy Management Console, a comparison against a separately maintained baseline document, and a reconciliation of any differences.
The API returns the current GPO configuration state and change history in a structured format. The output identifies what is applied, what changed, when it changed, and what it changed from. The reconciliation step is eliminated because the change history is part of the output rather than a manual comparison.
Threat Detection Events
Threat detection events, authentication anomalies, privilege escalation attempts, and account lockout patterns form the evidence base for demonstrating that detection controls are operating under ISO 27001 A.8.16 and SOC 2 CC7.1. This data currently requires extraction from the security monitoring layer and manual formatting for audit packages. The API consolidates this into the same structured output as authentication events and GPO configuration. A single API call covers all three evidence domains.
How This Fits Into a Broader IAM and PAM Architecture
The Compliance Reporting API is a reporting surface. The quality of the evidence it produces depends on the quality of the controls generating the underlying data.
Authentication events come from the Akku IAM platform handling your organisation’s identity and access management. GPO configuration state comes from your Group Policy environment managed through Akku. Threat detection events include session-level activity captured by AkkuReka, the session proxy component in Akku PAM, which records command-level activity from privileged SSH, RDP, and database sessions.
For teams that have implemented IAM and PAM and are currently spending several days per audit cycle manually assembling evidence, the API eliminates the assembly step without requiring changes to the underlying architecture. The controls already exist. The API makes their output accessible in the format auditors need.
Before You Move On
Pull your last compliance evidence package. Pick any three controls in it that required authentication or access data.
For each one: how many systems did someone log into to collect that data? How long did the collection take? And when the package was complete, how confident was the team that the data reflected the current state of the environment rather than the state during the collection window?
If any of those controls are relevant to DPDPA, add a fourth question: if a data protection board review arrived tomorrow and required you to demonstrate access accountability for those controls as of today, how long would it take to produce that evidence?
The answers define the gap between your current compliance reporting architecture and what the frameworks you are audited against are starting to require. The Compliance Reporting API closes that gap at the data layer. The compliance score and control checkpoints are viewed at the monitoring layer. Evidence on demand is not the same as continuous visibility. But it is the starting point.
See Akku PAM Compliance Capabilities | Talk to the Akku Team
Questions Security and Compliance Teams Ask About Compliance Reporting APIs
Q: What is the difference between a compliance reporting API and a GRC platform?
A: A GRC platform manages compliance workflows: control assignments, evidence uploads, risk registers, and audit scheduling. It depends on evidence being fed into it, either manually or through integrations. A compliance reporting API is an evidence source. It produces structured, audit-ready data from live system state that can be fed into a GRC platform, a SIEM, or a custom dashboard without manual extraction. The two are complementary. The GRC platform is where compliance is managed. The reporting API is where the underlying evidence comes from. For teams that already have a GRC platform but are manually extracting evidence to feed it, the API addresses the extraction step, not the management layer.
Q: Which specific ISO 27001:2022 Annex A controls does the Compliance Reporting API produce evidence for?
A: The API produces evidence relevant to A.8.15 (Logging), which requires that user activity and security event logs are produced, stored, and analysed. It produces evidence for A.8.16 (Monitoring Activities), which requires ongoing monitoring for anomalous behaviour. It supports A.5.15 (Access Control) and A.5.18 (Access Rights) through the authentication event and provisioning record output. GPO configuration data supports controls in the A.8 group that require specific system hardening and configuration baseline management. The full control-to-evidence mapping for Akku’s compliance capabilities is documented on the Akku compliance use case page.
Q: What does the DPDPA Rules 2025 compliance requirement mean practically for how authentication evidence is stored and produced?
A: Under DPDPA, data fiduciaries must implement technical measures demonstrating that access to personal data is controlled, reviewed, and removed when no longer required. At the evidence level, this means the access record needs to show who had access, when access was granted, under what authorisation, and when it was removed. The access record needs to be producible on demand, not assembled when requested. The Compliance Reporting API produces authentication event data that includes user identifiers, timestamps, and access patterns in structured JSON. For organisations currently relying on manual log exports to satisfy DPDPA obligations, the shift to API-based evidence production changes the response time from days to seconds.
Q: How does the API handle evidence for organisations managing multiple compliance frameworks simultaneously?
A: The API output is framework-agnostic. The same structured JSON covering authentication events, GPO configuration state, and threat detection events is relevant to ISO 27001, SOC 2, HIPAA, RBI, SEBI CSCRF, and DPDPA. The difference between frameworks is which specific fields and time windows the auditor focuses on, not which underlying data is required. For organisations that currently run separate evidence collection processes for each framework, the API output serves all of them from a single call.
Q: What is the latency between a system event occurring and it being available through the API?
A: Events are written to the Akku audit log in near-real-time as they occur. The API reflects the current audit log state with low query latency. For compliance reporting purposes, the API supports both on-demand queries and scheduled retrieval. For monitoring use cases where near-real-time event data is needed for SIEM detection rules, the API supports real-time streaming retrieval. The authentication event output is the same data that feeds the MFA Failures and Login Metrics APIs, both of which are designed for near-real-time consumption.
Q: How does the Compliance Reporting API fit into the broader Akku compliance architecture?
A: The reporting API is one layer of a three-layer compliance architecture in Akku. The compliance score and per-framework breakdown provide the executive summary layer: a continuously updated score across ISO 27001, SOC 2, HIPAA, GDPR, DPDPA, RBI, and SEBI CSCRF, exportable for board reports. The control checkpoints view is the operational layer: every control, its live pass or fail status, the evidence behind it, and the specific fix action where a gap exists. The reporting API is the integration layer: structured evidence output consumable by external GRC platforms, SIEM tools, and custom dashboards. For organisations implementing all three layers, compliance evidence stops being something assembled before audits and becomes a continuous operational data surface.
