Defensible audit evidence for an access grant has a specific technical definition. It is not a confirmation that the access exists. It is not a record that the access was provisioned. It is a structured record of a formal authorization decision: the identity of the person who approved the access, their authority to approve it, the scope of access approved, the business justification, and the timestamp of the decision, all stored in a system that is queryable, tamper-evident, and independent of any individual’s inbox.
An email from a department head saying please give Rahul access to the finance system satisfies none of those requirements. It is a request. The IT manager acting on it is a provisioning action. Neither constitutes a formal authorization decision in the sense that ISO 27001:2022 Annex A Control A.5.18, SOC 2 CC6.1, or DPDPA Rules 2025 mean when they use that term.
The gap between what most organizations produce as access approval records and what those frameworks require is one of the most consistent findings in IT compliance audits. It persists not because IT teams are careless but because the tooling most organizations rely on was built to provision access efficiently. Recording the governance decision behind the provisioning action was never part of the design.
This blog covers exactly what defensible audit evidence for access governance requires technically, where informal approval processes fail against each framework standard, and what a structured approval workflow produces that an email thread cannot.
ISO 27001:2022 Annex A Control A.5.18 requires that access rights are provisioned based on a formal authorization process, and that the process is documented. The documentation requirement is specific: it must be possible to demonstrate, for any access grant, that an authorization process was followed. That demonstration requires a record with identifiable fields, not a message that may or may not contain the relevant information depending on how it was written.
The specific fields that constitute a defensible access authorisation record are: the identity of the requester and their role, the identity of the approver and their authority to approve access of the type requested, the system and permission scope being approved, the business justification for the access, the timestamp of the approval decision, the duration of the access where time-limited, and a reference to the access control policy or role definition the approval was evaluated against.
SOC 2 CC6.1 requires that logical access controls restrict access to authorized individuals and that the authorization can be demonstrated. The evidence standard for CC6.1 is a queryable record showing that each access grant was authorized by a person with the defined authority to grant it. An email buried in a former employee’s archived mailbox does not constitute a queryable record in any operationally meaningful sense.
DPDPA Rules 2025 require that access to personal data is granted on a need-to-know basis. At the evidence level, this means the organization must demonstrate on demand that each access grant to a personal data system was based on a documented business need, approved by an appropriate authority, and reviewed since it was granted. A supervisory review under DPDPA does not arrive on a scheduled basis. It can arrive following an incident. The evidence of access governance needs to be retrievable immediately, not reconstructed from historical communications.
An email approval lives in the approver’s inbox. When that person leaves the organization, the inbox is archived, restricted, or deleted depending on the organization’s data retention policy. Reconstructing an access decision made 18 months ago by a manager who left the organization 12 months ago requires locating the archived mailbox, obtaining access to it, identifying the correct thread, and confirming that the relevant approval is in the thread rather than in a separate conversation. This is an investigation, not a record retrieval.
A structured approval record stored in the identity governance platform is queryable by the compliance team regardless of whether the original approver is still with the organization. The record exists independently of any individual’s employment status.
An email approval has no schema. Whether it contains the information an auditor needs depends entirely on how the email was written. A subject line reading access for new joiner and a body reading please sort this out contains no approver identity in a queryable field, no scope definition, no business justification, and no reference to an access control policy. It contains a request. That is not the same as an authorization record.
A structured approval record has defined fields. Every record for every access grant contains the same information in the same format, regardless of who wrote the request or how formally they phrased it. The schema enforces the evidence standard at the point of approval, not at the point of the audit.
Email-based approvals routinely approve access at an application level without defining the role, permission set, or data scope within the application. Approving access to Salesforce without specifying whether that means read-only access to one regional pipeline or administrative access to the full CRM is not a scoped authorization. It is a vague grant that cannot be meaningfully reviewed for continued appropriateness because the original scope was never defined.
Under SOC 2 CC6.3, access reviews are supposed to evaluate whether existing access is still appropriate. If the original approval did not define the scope, the reviewer has no baseline against which to evaluate appropriateness. They are certifying that the access exists and that the user’s role appears to justify something. They cannot evaluate whether the specific access granted was appropriate then or remains appropriate now.
A structured workflow captures the approval decision in a defined schema at the point the decision is made. The requester, approver, access scope, business justification, and timestamp are all mandatory fields. The record cannot be created without them. This means the evidence standard is enforced by the system rather than by the discipline of the person writing the email.
The approval record lives in the identity governance platform, not in an inbox. It is queryable by system identifier, user identifier, approver identity, application, date range, and approval status. A compliance team preparing for an ISO 27001 audit can retrieve the complete approval history for any application in under a minute. The same query works whether the original approver is still with the organization or left three years ago.
When an access review runs under ISO 27001 A.5.18 or SOC 2 CC6.3, the reviewer sees the original approval record alongside the current access state. They can evaluate whether the business justification still holds, whether the scope of access is still appropriate given the user’s current role, and whether the duration of the access was meant to be time-limited. This is a genuine review of continued appropriateness, not a certification that the access exists.
For financial services organizations under RBI’s Cyber Security Framework and SEBI CSCRF requirements, structured access approval records satisfy the audit trail requirement at the individual access grant level. For ITeS and BPO organizations subject to client compliance audits with short notice, retrievable approval records change the audit response time from days to minutes.
Structured access approval workflows are one component of identity governance and administration that sits in front of the provisioning layer. The approval record triggers the provisioning action. The two records reference the same request identifier, so the full chain from approval to entitlement to periodic review to deprovisioning is traceable in a single audit trail.
For organizations using Akku IAM for provisioning, adding structured approval workflows closes the governance gap without replacing the provisioning architecture. The approval step sits in front of provisioning and produces the audit record that the provisioning action alone cannot.
For any five access grants made in the last 12 months to a sensitive system, try to retrieve the authorization record from your current systems. Check whether the record contains the approver’s identity, the scope of access approved, the business justification, and the timestamp of the decision, all in a queryable format.
If any of those five records requires searching an inbox, asking the original approver, or acknowledging that the record may not exist in a structured form, the gap between your current process and what ISO 27001 A.5.18 and DPDPA require is confirmed.
Explore Akku IGA Capabilities | See Akku IAM Provisioning | Talk to the Akku Team
Q: What is the difference between an access request and an access approval under ISO 27001?
A: An access request is an expression of intent: someone wants access to a system. An access approval is a formal authorisation decision: a person with defined authority has reviewed the request against the access control policy and made a documented decision to approve it. ISO 27001:2022 Annex A Control A.5.18 requires that access rights are provisioned based on a formal authorisation process, and that the process is documented. An email request that an IT manager acted on is a fulfilled request. It is not a documented authorisation process unless the approval decision itself was recorded in a structured schema with the approver identity, scope, business justification, and timestamp.
Q: What does DPDPA Rules 2025 require specifically at the access approval evidence level?
A: DPDPA requires data fiduciaries to implement technical and organisational measures ensuring access to personal data is granted on a need-to-know basis. At the evidence level, the organisation must demonstrate on demand that each access grant to a personal data system was based on a documented business need approved by an appropriate authority. The DPDPA does not prescribe a specific tool. It sets an outcome: the access decision must be demonstrable. An email in an inbox that may or may not be searchable after the approver has left the organisation does not satisfy this standard in a regulatory review or supervisory investigation context.
Q: What should a structured access approval record contain to satisfy audit requirements across ISO 27001, SOC 2, and DPDPA simultaneously?
A: The record should contain the identity of the requester and their business role, the identity of the approver and their authority to approve access of the type requested, the system and permission scope being approved, the business justification for the access, the timestamp of the approval decision, the duration of the access where time-limited, and a reference to the access control policy or role definition the approval was evaluated against. This structure satisfies the documentation requirement of ISO 27001 A.5.18, the authorization evidence requirement of SOC 2 CC6.1, and the access accountability requirement of DPDPA. For multi-level approvals, each approval step should have its own record.
Q: How does a structured approval workflow connect to the access review process under SOC 2 CC6.3?
A: SOC 2 CC6.3 requires periodic review of whether existing access is still appropriate. For that review to be meaningful, the reviewer needs to know what was approved, at what scope, and for what business justification. A structured approval workflow provides this baseline automatically. The reviewer sees the original approval record alongside the current access state and can evaluate whether the justification still holds. Without this baseline, the reviewer can only certify that the access exists, not that it remains appropriate. The quality difference between the two types of review is the difference between a compliance exercise and a genuine governance evaluation.
Q: How do you transition from email-based approvals to a structured workflow without disrupting operations?
A: Three steps. First, define the approval workflow for each category of sensitive system: who has authority to approve access, what information must be captured, and what the response time expectation is. Second, configure the identity governance platform so that provisioning actions for those systems require a completed approval record rather than an informal message. Third, make the new process at least as fast as the informal one for routine requests. A well-configured approval workflow for a standard access request should complete in under an hour. The operational disruption is minimal if the workflow is designed around the actual approval behaviour rather than around a theoretical governance model.
Q: What is the regulatory risk of continuing with informal access approvals under DPDPA and ISO 27001?
A: Under ISO 27001, informal access approvals are a control gap that affects certification. An auditor finding that access rights are provisioned without a documented authorization process is an A.5.18 nonconformity. Under DPDPA, the risk is potentially more significant because the data protection board has investigatory powers that are not confined to scheduled audits. An organization that cannot demonstrate structured access approval records for personal data systems is in a materially weaker position in any regulatory interaction, regardless of whether a breach has occurred. The absence of evidence is not evidence of absence in a regulatory investigation.
A provisioning record captures a point-in-time entitlement decision: this user was granted access to this application on this date. It…
If your SSO platform had a service disruption at 2am tonight, how would your team find out about it? For…
The IAM layer generates the earliest detectable signal of a credential attack. Before any account is compromised, before any privileged…
When did you last run a compliance evidence collection that did not surface something unexpected? Not a gap in your…
Your user authenticated this morning. They presented the right credentials. They completed the MFA challenge. Your access control system granted…
When you give someone SSH access to a Linux server, what exactly have you given them? Think about that carefully…