Introduction

GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be the default configuration. These are architectural requirements, not operational ones. They apply at the point systems are designed and deployed, not only when data is being processed. An organisation that deploys a system with broad default access to personal data and then attempts to restrict it through policy is operating in the opposite direction to what Article 25 requires.

Article 25 has two distinct obligations. Article 25(1) requires data protection by design: technical and organisational measures designed to implement data protection principles effectively must be integrated into processing activities from the outset. Article 25(2) requires data protection by default: by default, only personal data necessary for each specific purpose should be processed, and access to personal data should be restricted by default without requiring individual Data Subjects to take action to limit it.

For IAM specifically, Article 25 means that access to personal data systems must be restricted by default. Expansion of access scope requires explicit authorisation. The access control architecture must implement the data minimisation principle at the identity and access layer, not rely on users exercising restraint. A system where every user has read access to all customer records by default, with restrictions applied only for specific roles, inverts the Article 25(2) requirement.

This blog covers what Article 25(1) and 25(2) each require technically, how they apply to IAM architecture, and which controls satisfy each obligation. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.

Data Protection by Design Requirements Under Article 25(1)

Article 25(1) requires that controllers implement appropriate technical and organisational measures designed to implement data protection principles effectively and to integrate the necessary safeguards into the processing. The data protection principles in Article 5 are the reference point: lawfulness, fairness, and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality.

What Article 25(1) requires technically

The integrity and confidentiality principle under Article 5(1)(f) is the most directly relevant to IAM architecture. It requires that personal data be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical or organisational measures.

Implementing integrity and confidentiality by design means that access controls, authentication requirements, and audit trail generation are built into the system architecture from the point of deployment, not added as security layers after the fact. A system deployed without MFA, with the intention to add it later, is not designed with integrity and confidentiality in mind.

Article 5(1)(b)’s purpose limitation principle requires that personal data collected for specified purposes not be processed incompatibly with those purposes. By design, this means that the access control architecture limits which users can process personal data for which purposes, enforced technically rather than relying on users to self-limit.

Article 5(1)(e)’s storage limitation principle requires that personal data not be kept longer than necessary. By design, this means automated lifecycle management workflows that trigger data deletion or access cessation when processing purposes are fulfilled, rather than manual cleanup processes.

How Akku addresses it

The access governance infrastructure implements Article 25(1)’s by-design requirement across multiple controls. RBAC defines access entitlements at the role level, ensuring that access to personal data systems is scoped to the processing purposes each role requires, by design, from the point of user provisioning. The IGA SoD rules engine prevents conflicting access combinations that would enable a single user to process personal data across incompatible purposes, implementing the purpose limitation principle architecturally.

Adaptive MFA implements the integrity and confidentiality principle by design at the authentication layer. Every access to personal data systems requires authentication assurance proportionate to the sensitivity of the data, enforced through the identity layer rather than relying on application-level controls.

Automated deprovisioning implements the storage limitation principle at the access layer. When a user’s employment ends or a processing purpose is fulfilled, access to personal data systems is revoked automatically without requiring a manual deprovisioning action. The automated workflow is the by-design implementation of the storage limitation principle for access rights.

Akku’s GDPR mapping shows Identity and Access Governance addresses Articles 24(1), 25(2), and 32(1)(d). Access Manager addresses Articles 5(1)(f), 24(1), 25(2), 29, and 32(1)(b) across five mapping points.

Data Minimisation by Default Requirements Under Article 25(2)

Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed. Access to personal data should be restricted by default. Data Subjects should not have to take action to protect their privacy. The default configuration of systems must implement data minimisation without requiring user intervention.

What Article 25(2) requires technically

Article 25(2) applied to IAM architecture means that the default access state for any new user is no access to personal data systems. Access is granted explicitly, based on a documented processing purpose tied to the user’s role, through a formal authorisation process. The default is restriction, not access.

This is the opposite of many legacy system architectures where broad read access to customer or employee data is the default, with restrictions applied only for specific sensitive functions. Article 25(2) requires inversion of this default: restriction is the baseline, and access must be actively granted based on demonstrated need and authorised processing purpose.

The data minimisation requirement also applies to the scope of access within systems. A user whose role requires viewing customer contact details to process a service request should not by default have access to payment card data, health information, or other personal data categories held in the same system but irrelevant to their function.

How Akku addresses it

Akku’s default access model implements Article 25(2) architecturally. No user is granted access to personal data systems without explicit role assignment and provisioning through a structured workflow. Birthright access is defined at the role level, scoped to the processing purposes that role legitimately requires, and does not include access to personal data systems beyond what the role requires.

ABAC refines access scope within systems, limiting what data categories a user can access based on attributes beyond role, including their current active processing context. Contextual access controls add a further restriction layer, limiting access to authorised devices, networks, and time windows even for users with legitimate role-based entitlements.

The IGA who-has-access-to-what view provides administrators with continuous visibility into whether the data minimisation default is being maintained across all users and systems. Access that has accumulated beyond current processing requirements is surfaced through access reviews for revocation.

Akku’s GDPR mapping shows Cloud Directory addresses Article 25(2). The broader access control module stack, covering Access Manager, Adaptive MFA, Identity and Access Governance, and Privileged Access Manager, implements data minimisation by default across the full access lifecycle.

Article 25 and Privileged Access to Personal Data Systems

Article 25’s by-design requirement has specific implications for privileged access to systems that process personal data. Database administrators with direct query access to tables holding personal data, system administrators with file system access to personal data stores, and infrastructure administrators with access to the network segments where personal data systems reside are all processing personal data under Article 25’s scope.

What Article 25 requires for privileged access

By design, privileged access to personal data systems must be governed through the same data minimisation and purpose limitation principles as standard user access. A DBA should not have standing, unrestricted access to production customer databases by default. The by-design requirement means that the architecture prevents standing privileged access rather than relying on the DBA to exercise restraint.

Article 25(1)’s integrity and confidentiality requirement for privileged access means that every privileged session to a personal data system is authenticated with appropriate assurance, brokered through a session proxy that records activity, and governed through a formal approval workflow that documents the processing purpose for each session.

How Akku addresses it

JIT access implements Article 25’s by-design requirement for privileged access. No DBA, system administrator, or infrastructure administrator holds standing access to personal data systems. Access is granted for the duration of an approved, time-bound session with a documented processing justification. The architecture prevents standing privilege by design rather than relying on policy adherence.

AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, scoped to the access level required for the session’s processing purpose, and permanently revoked on session close. This implements the data minimisation principle at the credential layer: each privileged session has access only to what the approved purpose requires, not to everything the privileged account could potentially access.

SMARTAudit Trails record every privileged session to personal data systems at the protocol layer. This produces the audit evidence that Article 25(1)’s by-design integrity requirement implies: a demonstrable record that privileged access to personal data was governed, controlled, and logged throughout its duration.

Privileged Access Manager addresses Articles 5(1)(f), 29, and 32(1)(d) in Akku’s GDPR mapping.

Demonstrating Article 25 Compliance to a Supervisory Authority

Article 25 compliance is assessed through the accountability principle in Article 24 and Article 5(2): the controller must be able to demonstrate that processing is performed in accordance with the GDPR. For Article 25 specifically, this means demonstrating that data protection was built into the architecture by design and that data minimisation is the operational default.

What demonstration requires technically

Demonstrating by-design compliance requires architectural documentation showing that access controls, MFA, and audit trail generation were designed into the system from the point of deployment, not added retrospectively. It also requires operational evidence showing that the by-design controls are actually functioning: that no user accesses personal data systems without explicit authorisation, that privileged access to personal data systems is governed through JIT workflows, and that access minimisation is enforced through ongoing access reviews.

Demonstrating by-default compliance requires evidence that the default access state for new users is restriction, not access. Provisioning records showing that every user starts with no access to personal data systems and receives access only through a documented authorisation process constitute this evidence.

How Akku produces this evidence

The provisioning audit trail, covering every access grant with requester, approver, justification, and timestamp, is the evidence that by-default access minimisation is operationally maintained. The access review records, showing periodic certification or revocation of access to personal data systems, demonstrate that the by-default minimisation posture is continuously maintained rather than set once and left to drift.

The JIT access workflow records for privileged sessions, covering every session request, approval, scope definition, and credential lifecycle event, demonstrate that by-design privileged access governance is operating for every session to personal data systems.

Akku’s append-only audit log architecture ensures these records are tamper-evident, making them suitable for submission to a supervisory authority examination of Article 25 compliance.

Diagnostic Questions

Does the default access state for a new user at your organisation include any access to personal data systems, or is the default no access with explicit authorisation required for every grant?

Can you demonstrate to a supervisory authority that access to personal data systems was built into your architecture as a restricted-by-default model from the point of system deployment, rather than added as a security layer after deployment?

Do database administrators and system administrators with access to personal data systems hold standing credentials that allow them to connect at any time, or is privileged access to personal data systems governed through JIT workflows with documented processing justifications?

Are access reviews for personal data systems run on a defined cadence throughout the year, with documented evidence that access accumulated beyond current processing requirements is revoked, or does review occur only before audit events?

Can you produce, for any user currently holding access to a personal data system, the authorisation record showing which processing purpose justified the access grant and who approved it?

CTAs

See how Akku addresses GDPR Article 25 data protection by design requirements across access controls, privileged access governance, and audit trail generation.

Book a conversation with the Akku team to assess your current IAM architecture against GDPR Article 25’s by-design and by-default obligations.

FAQs

What is the difference between Article 25(1) data protection by design and Article 25(2) data protection by default?

Article 25(1) requires that technical and organisational measures implementing data protection principles be integrated into processing activities from the outset. It is about how systems are designed and built. Article 25(2) requires that, by default, only necessary data is processed and access is restricted without requiring Data Subject action. It is about the default operational state of systems once deployed. By design means the architecture implements protection from the start. By default means the starting configuration minimises data access without user or administrator intervention to restrict it.

How does the data minimisation principle under Article 5(1)(c) apply to IAM architecture?

Article 5(1)(c) requires that only personal data adequate, relevant, and limited to what is necessary for the processing purpose is collected and processed. Applied to IAM architecture, data minimisation means that each user’s access is scoped to the personal data their role requires for its authorised processing purposes, and no more. A customer service representative whose role requires access to contact details should not by default have access to payment card data or health information held in the same system. RBAC and ABAC implement data minimisation at the access layer by scoping entitlements to what each role’s processing purposes actually require.

What does Article 25 require for third-party and contractor access to personal data systems?

Article 29 requires that processors and persons acting under the authority of the controller process data only on instructions from the controller. Applied to third-party and contractor access, this means their access to personal data systems must be governed through the same by-design and by-default controls as internal user access. Contractors should not have standing access to personal data systems. Their access should be time-bound, scoped to the specific processing they are authorised to perform, and governed through the same JIT access workflows and session recording controls that apply to internal privileged users.

Does Article 25 apply to legacy systems that were deployed before GDPR came into force?

Yes. Article 25 does not exempt legacy systems from the by-design and by-default requirements. Controllers are expected to have reviewed and, where necessary, updated their systems to implement appropriate technical measures since GDPR came into force in May 2018. A legacy system that was deployed with broad default access and has not been updated to implement access controls appropriate to Article 25 is not compliant. The practical approach is to extend the IAM access control and governance layer to legacy systems, bringing them within the centralised authentication and access governance infrastructure even if the systems themselves cannot be modified.

How does Article 25 interact with Article 32’s security of processing requirements?

Article 25 covers the design and default configuration of systems. Article 32 covers the ongoing security measures applied to processing operations. Article 25 is satisfied by building access controls, MFA, and audit trail generation into the architecture from the outset. Article 32 is satisfied by the operational security controls including encryption, authentication assurance, and incident response capability that protect personal data during processing. Both apply simultaneously. An organisation can satisfy Article 32’s operational security requirements while still failing Article 25 if the default access configuration grants broader access than necessary before the Article 32 controls restrict it.

What evidence does a supervisory authority examination of Article 25 typically look for?

A supervisory authority examining Article 25 compliance typically looks for architectural documentation showing that data protection was considered at system design, access control configuration records showing that the default access state implements data minimisation, provisioning records demonstrating that every access grant to personal data systems required explicit authorisation, access review records showing that access minimisation is continuously maintained, and privileged access governance records demonstrating that administrative access to personal data systems is controlled and logged. The accountability principle requires that the controller can produce this evidence, not merely assert compliance.

Introduction

ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and regularly reviewed. The control is specific: user activities. Not login events. Not authentication outcomes. The activities a user performs after authentication succeeds.

Most organisations pursuing ISO 27001 certification have authentication logging in place. Every login attempt is recorded. MFA outcomes are captured. Failed authentication attempts generate alerts. This is necessary but it does not satisfy A.8.15. Authentication logs answer the question of who connected. A.8.15 requires evidence of what they did once connected.

The distinction becomes critical during post-incident investigation. When a privileged user accesses a production server and a configuration change is made that causes a system outage, an authentication log confirms the session occurred. It provides no evidence of which commands were run, which files were modified, or which configuration was changed. Reconstructing what happened requires session-level activity logs. Without them, investigation relies on inference rather than evidence.

ISO 27001 certification auditors examine A.8.15 by asking for samples of user activity logs, not authentication logs. An auditor who receives authentication event exports when they asked for user activity logs will raise a finding. This blog covers what A.8.15 requires technically, how user activity logging differs from authentication logging at the implementation level, and what evidence a certification audit expects.

What A.8.15 Requires and What Authentication Logs Provide

The gap between what A.8.15 requires and what most organisations have implemented is architectural, not configurational. It cannot be closed by adding more fields to an existing authentication log.

What A.8.15 requires

A.8.15 requires logs covering four categories. User activities: the actions a user performs within a system session, including commands executed, files accessed, queries run, and configuration changes made. Exceptions: events where normal processing did not complete, including access denied events, application errors triggered by user actions, and policy violations. Faults: system-level events including failed processes, service interruptions, and hardware faults relevant to security. Security events: authentication failures, privilege escalation attempts, policy changes, and account modifications.

The logging infrastructure must protect logs against tampering and unauthorised access. Logs must be retained for defined periods and available for investigation when security incidents occur. The review requirement means logs must be actively monitored, not only stored.

What authentication logs provide

Authentication logs record the login layer. Who attempted to authenticate, when, from which IP and device, using which authentication method, and whether the attempt succeeded. For sessions that succeed, the authentication log records the session start. For sessions that fail, it records the failure reason and any MFA outcome.

Authentication logs do not record anything inside an authenticated session. Once a user passes authentication and the session opens, the authentication log has no further entries for that session until the next authentication event. Everything that happens in between, every command, every query, every file operation, every configuration change, is invisible to the authentication log.

For standard end users accessing SaaS applications, this gap is partially acceptable because application-level activity logging within those applications captures the relevant user actions. For privileged users accessing servers, databases, and network devices directly, there is typically no application-level activity log. The session is a direct connection to a system, and without session-level recording, the activity inside it is unrecorded.

User Activity Logging Requirements for Privileged Access

A.8.15’s user activity logging requirement is most demanding for privileged access scenarios. A privileged user with SSH access to a Linux server, database administrator access to a production MySQL instance, or RDP access to a Windows server has the ability to make changes with significant impact. The activity logging requirement exists precisely because these are the sessions where the evidence of what occurred matters most.

SSH session activity logging

For SSH sessions, user activity logging requires keystroke-level capture per command. The log must record every command the user typed, the directory context in which it was executed, and the output produced. A screen recording that captures visual session activity satisfies part of this requirement but does not produce structured, searchable keystroke data. Full compliance requires both screen recording and structured keystroke logging.

The practical implication is that a Linux server administrator who runs a series of commands during a session, modifies a configuration file, restarts a service, and exits can be fully reconstructed from the keystroke log. Every command, every argument, every file path is in the record. An authentication log of the same session contains only the session start and end timestamps.

Database session activity logging

For database sessions, user activity logging requires capture of every SQL query executed during the session. The log must record the query text, the timestamp, the database and table context, and where possible the number of rows affected. This is the evidence base that satisfies A.8.15’s user activity requirement for database access and that supports forensic investigation when data integrity questions arise.

An authentication log of a database session records that a DBA connected to the database at a given time. It does not record whether they ran a SELECT on a customer table, executed a DELETE, or modified a stored procedure. Without query-level logging, the investigation of a data integrity incident in a database is severely hampered.

RDP session activity logging

For RDP sessions to Windows servers, user activity logging requires screen recording at sufficient resolution and frame rate to reconstruct what was done during the session. RDP sessions involve graphical interfaces where the activity cannot be captured as structured text. Screen recording is the appropriate logging mechanism, supplemented by session event logs capturing session open, active duration, and termination reason.

What Certification Auditors Examine for A.8.15

ISO 27001 certification auditors examining A.8.15 follow a consistent examination pattern. Understanding what they look for helps organisations assess whether their current logging infrastructure satisfies the control.

Evidence sampling approach

Auditors typically select a sample of privileged users and request the activity logs for a defined period, often the last 30 days. They examine whether the logs produced are user activity logs capturing session-level actions, or authentication logs capturing login events. An organisation that produces authentication logs in response to this request has demonstrated a gap in A.8.15 implementation.

For the sampled period, auditors verify that every privileged session to critical systems has a corresponding activity log entry. Gaps in coverage, sessions that occurred but have no activity log record, indicate incomplete deployment of the activity logging controls.

Log integrity examination

Auditors examine whether logs are protected against tampering. An append-only, tamper-evident architecture where existing records cannot be modified is what satisfies this requirement. Logs stored in standard file systems that can be modified by administrators with sufficient access do not satisfy the tamper protection requirement.

Review evidence

A.8.15 requires that logs be regularly reviewed. Auditors look for evidence that the review process operates, not only that logs exist. Risk and audit dashboards that surface anomalous events for administrator attention, combined with records showing that alerts were investigated and actioned, constitute review evidence. Passive log storage with no review mechanism does not satisfy the regular review requirement.

How SMARTAudit Trails Address A.8.15

SMARTAudit Trails capture every privileged session at the protocol layer through AkkuReka, producing the user activity logs A.8.15 requires across SSH, RDP, database, and web application sessions.

SSH session coverage

SSH sessions produce two complementary records. A full screen recording capturing the visual session at configurable quality. A complete keystroke log capturing every command typed with timestamp, providing structured, searchable activity data. The keystroke log is the user activity log A.8.15 requires for SSH sessions. The screen recording provides the visual context.

Database session coverage

MySQL and PostgreSQL sessions produce full screen recordings and a structured capture of every SQL query executed during the session. Each query record includes the query text and session context. This query capture is the user activity log A.8.15 requires for database sessions.

RDP session coverage

RDP sessions produce full screen video recordings at configurable frame rates. Session event logs capture session open, active duration, keystroke count, and termination reason.

Log architecture

All SMARTAudit Trail recordings are stored encrypted with AES-256. The audit log is append-only and tamper-evident. Records cannot be modified or deleted after creation. Recordings are indexed for forensic search by timestamp, command string, or SQL query and accessible for in-browser playback from the Akku admin console without requiring file downloads or external media players.

API access to audit logs supports integration with SIEM and log aggregation platforms. Structured export in JSON and CSV format supports auditor submission and forensic investigation workflows.

Akku’s ISO 27001 mapping shows Privileged Access Manager addresses A.8.3, A.16.2, A.16.6, A.16.7, and A.16.8. The Identity and Access Governance module, carrying 16 clause references, covers the broader access governance controls that complement A.8.15’s activity logging requirement.

Diagnostic Questions

When a system administrator runs commands on a production Linux server, is there a keystroke log capturing every command executed during the session, or only an authentication log confirming the session occurred?

When a database administrator connects to a production MySQL or PostgreSQL database, is there a record of every SQL query executed during the session, or only a record that the connection was established?

Are your privileged session activity logs stored in an append-only, tamper-evident format where existing records cannot be modified, or are they stored in a file system that administrators with sufficient access could modify?

Can you produce the complete activity log for any privileged session that occurred in the last 90 days, searchable by command string or SQL query, without requiring a manual log compilation exercise?

Is there a defined process for regularly reviewing privileged session activity logs, with evidence that anomalous sessions trigger investigation, or are logs stored passively without a systematic review mechanism?

CTAs

See how Akku’s SMARTAudit Trails address ISO 27001 A.8.15 requirements for user activity logging across SSH, RDP, and database sessions.

Book a conversation with the Akku team to assess your current logging infrastructure against ISO 27001:2022 A.8.15 certification requirements.

FAQs

What is the specific difference between an authentication log and a user activity log under ISO 27001 A.8.15?

An authentication log records login events: who connected, when, from which IP and device, using which authentication method, and whether the attempt succeeded. A user activity log records what happened after authentication: which commands were executed, which queries were run, which files were accessed, which configuration changes were made. A.8.15 requires the latter. An organisation that has authentication logging but no session-level activity logging for privileged users has a gap in A.8.15 compliance that a certification auditor will identify when they request user activity log samples.

Does A.8.15 apply equally to all users or primarily to privileged users?

A.8.15 applies to all users, but the practical implementation priority is privileged users. For standard users accessing SaaS applications, activity logging is often handled within the applications themselves, which log user actions at the application layer. For privileged users accessing servers, databases, and network devices directly, there is no application-level activity log. The session is a direct system connection, and without session-level recording through a PAM-layer proxy, the activity inside it is entirely unrecorded. A.8.15’s user activity logging requirement is therefore most demanding to implement, and most commonly unmet, for privileged access scenarios.

What does A.8.15 require for log protection, and how does an append-only architecture satisfy this?

A.8.15 requires that logs be protected against tampering and unauthorised access. An append-only architecture means that once a log record is written, it cannot be modified or deleted. New records can be added, but existing records are immutable. This is the tamper protection mechanism that satisfies A.8.15’s requirement. Logs stored in standard file systems where administrators with sufficient privileges can modify or delete records do not satisfy the tamper protection requirement. The append-only property, combined with access controls preventing direct human access to the raw log data, constitutes the technical implementation of A.8.15’s protection requirement.

How does A.8.15 interact with A.8.16 monitoring activities, and do they require separate controls?

A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced and kept. A.8.16 requires that networks, systems, and applications be monitored for anomalous behaviour and that appropriate actions be taken. A.8.15 is about log generation and retention. A.8.16 is about active monitoring and anomaly detection. They are complementary but distinct controls. A.8.15 is satisfied by a session activity logging infrastructure with tamper protection and defined retention. A.8.16 is satisfied by an active monitoring layer that evaluates events against baselines and generates alerts. Satisfying one does not satisfy the other.

What retention period should organisations apply to user activity logs to satisfy A.8.15?

ISO 27001:2022 does not specify a defined retention period in A.8.15. The control requires that logs be kept for defined periods sufficient for investigation purposes. In practice, most certification bodies and auditors expect a minimum retention period of one year for authentication event logs and user activity logs. For privileged session recordings, a two-year retention period is common in organisations handling sensitive data. The retention period should be defined in the organisation’s information security policy and consistently applied. Organisations subject to additional regulatory requirements, such as RBI or SEBI, should align their retention periods with the longer of the ISO 27001 internal policy requirement and the regulatory requirement.

Can SMARTAudit Trails evidence be used for both ISO 27001 A.8.15 certification and RBI Clause 15 forensic investigation requirements simultaneously?

Yes. SMARTAudit Trails produce session-level activity logs that satisfy both A.8.15’s user activity logging requirement and RBI Clause 15’s forensic audit trail standard from the same recordings. ISO 27001 A.8.15 requires user activity logs for privileged sessions. RBI Clause 15 requires audit trails suitable for forensic investigation and dispute resolution. Both are satisfied by keystroke logs for SSH sessions, SQL query capture for database sessions, and screen recordings for RDP sessions, stored in append-only, tamper-evident format and accessible for forensic search. The same evidence package serves both requirements.

Introduction

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

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.

What it must contain

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.

Format and retention standards

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.

How Akku produces it

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

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.

What it must contain

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.

Format and retention standards

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.

How Akku produces it

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 and Certification Evidence

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.

What it must contain

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.

Format and retention standards

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.

How Akku produces it

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

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.

What it must contain

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.

Format and retention standards

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.

How Akku produces it

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.

Consent and Data Principal Rights Evidence

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.

What it must contain

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.

Format and retention standards

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.

How Akku produces it

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.

Assembling the Evidence Package for a Regulatory Examination

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.

Evidence package structure by framework

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.

What separates a defensible package from a reconstructed one

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.

Diagnostic Questions

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?

CTAs

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.

FAQs

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

SOC 2 CC6 is the Logical and Physical Access Controls criterion cluster and is where the majority of IAM-relevant requirements in a SOC 2 engagement sit. CC6.1 through CC6.8 cover logical access security, user registration and authorisation, access modification and removal, external threat protection, transmission controls, and malicious software prevention. Together they define what an auditor expects to see from an organisation’s access control infrastructure throughout the audit period.

CC6 is also where most organisations find their largest evidence gaps when they first pursue SOC 2 Type II. CC6.2’s user registration requirement needs structured provisioning records covering every user onboarded during the audit period. CC6.3’s access modification and removal requirement needs evidence that access changes and deprovisioning occurred through a governed process, not ad hoc. CC6.6’s boundary protection requirement needs MFA evidence covering external access throughout the period. None of these can be satisfied by pulling records together before the audit. The evidence must exist continuously.

This blog covers what each CC6 criterion requires technically, what a SOC 2 Type II auditor examines for each, and how IAM controls produce the continuous operating evidence each criterion demands. All criteria references are drawn from the AICPA Trust Services Criteria and Akku’s SOC 2 compliance mapping documentation, which addresses 14 of the 61 top-level Trust Services Criteria with 31 overlapping mapping points across 11 modules.

CC6.1: Logical Access Security Software and Infrastructure

CC6.1 requires that logical access security software, infrastructure, and architectures are implemented to protect against threats from sources outside the system boundary. This is the foundational access control criterion covering the identity and authentication infrastructure itself.

What CC6.1 requires technically

CC6.1 requires that the organisation has implemented a logical access control infrastructure capable of restricting access to systems and data to authorised users. This covers the identity store, the authentication layer, the access control policy enforcement mechanism, and the monitoring infrastructure that detects unauthorised access attempts.

For IAM specifically, CC6.1 requires a centralised identity management system, consistent authentication enforcement including MFA, role-based access controls, and a logging infrastructure capturing authentication events and access decisions. The criterion does not prescribe specific technologies but auditors assess whether the implemented infrastructure provides meaningful protection against external threats.

What auditors examine

Auditors examining CC6.1 typically review the identity infrastructure architecture, verifying that a centralised identity system exists and that applications authenticate through it. They review MFA configuration, verifying that MFA is enforced for access to in-scope systems. They review access control policy documentation and verify that it is technically enforced rather than policy-stated. They sample authentication event logs to verify that the logging infrastructure is producing continuous, structured records.

How Akku addresses it

Akku’s unified cloud identity store, SSO infrastructure, and Adaptive MFA constitute the logical access security infrastructure CC6.1 requires. Cloud Directory addresses CC6.1 and CC6.2 across two mapping points. SSO and IDP addresses CC6.1 across one mapping point. Adaptive MFA addresses CC6.1 and CC6.6 across two mapping points. Access Manager addresses CC6.1 and CC6.6 across two mapping points.

CC6.2: User Registration and Authorisation

CC6.2 requires that prior to issuing system credentials and granting system access, the entity registers and authorises new internal and external users. This is the user provisioning control, and it requires a structured process producing a documented record for every user onboarded during the audit period.

What CC6.2 requires technically

CC6.2 requires a formal user registration process with documented authorisation before access is granted. Every user must be registered through a defined workflow. Access must be authorised, meaning approved by an appropriate authority, before credentials are issued. The process must apply consistently to all users throughout the audit period, not only at audit time.

For SOC 2 Type II purposes, this means every provisioning event during the audit period must have a corresponding record showing that the user was registered through the formal process and that access was authorised before it was granted. Auditors sample provisioning events from across the audit period. Provisioning events with no authorisation record, or with informal records such as email threads, do not satisfy CC6.2.

What auditors examine

Auditors select a sample of users onboarded during the audit period and request the provisioning records for each. They verify that each record contains a formal authorisation, an approved access request, and evidence that credentials were issued only after authorisation was complete. They also verify that the process was consistent across the sample, not applied only to some users or only for part of the period.

How Akku addresses it

Akku’s structured access request and provisioning workflows produce the formal authorisation records CC6.2 requires for every provisioning event. Every user registration captures requester identity, approver identity, justification, timestamp, and downstream provisioning confirmation. SCIM-based provisioning synchronises approved access to connected applications with a timestamped sync record. User Lifecycle Manager addresses CC6.2 and CC6.3 across two mapping points. Identity and Access Governance addresses CC5.1, CC6.2, and CC6.3 across three mapping points.

CC6.3: Access Modification and Removal

CC6.3 requires that the entity authorises, modifies, or removes access to data, software, functions, and other protected information assets based on approved and documented access requests and the system of record for user entitlements. This covers role changes, access reviews, and deprovisioning.

What CC6.3 requires technically

CC6.3 requires that access changes and removals occur through the same structured, documented process as initial provisioning. A role change that results in access being silently carried forward without review does not satisfy CC6.3. A user departure where access is removed only from some systems and not others does not satisfy CC6.3. Every access modification and removal must be authorised, documented, and traceable to the system of record.

The periodic access review requirement is the mechanism for identifying and correcting access that is no longer appropriate. CC6.3 requires that the system of record for entitlements be accurate and current. Access reviews certify that current entitlements reflect current requirements and revoke those that do not.

What auditors examine

Auditors examine a sample of role changes and departures from the audit period. For role changes, they verify that access from the previous role was reviewed and that entitlements no longer appropriate were removed. For departures, they verify that deprovisioning across all in-scope systems completed promptly and that a timestamped record of each account removal exists. They also examine access review records, verifying that reviews were conducted on a defined cadence throughout the audit period with documented outcomes.

How Akku addresses it

Automated User Lifecycle Management handles role changes and departures with full audit trail coverage. Role changes trigger re-provisioning workflows with documented review and approval. Departures trigger automated deprovisioning across all connected applications with a timestamped record of every account removed. Access review and re-certification campaigns run on a defined cadence, producing timestamped certification or revocation decisions for every entitlement reviewed. Privileged Access Manager addresses CC6.3 alongside CC5.2, CC6.1, CC6.8, and CC7.2 across five mapping points.

CC6.6: Boundary Protection Against External Threats

CC6.6 requires that logical access security measures protect against threats from persons acting outside the entity’s system boundaries. This covers external access controls including MFA enforcement for remote and external users, network boundary controls, and contextual access restrictions.

What CC6.6 requires technically

CC6.6 requires that access from outside the organisation’s network boundary is subject to additional security controls proportionate to the risk. For IAM, this means MFA is enforced for all remote and external access to in-scope systems. Contextual access controls restrict access based on device compliance, geographic location, IP reputation, and time of day. Access from unmanaged devices or high-risk locations is subject to additional challenge or restriction.

The boundary protection requirement also covers external users including contractors, partners, and clients who access organisational systems. Their access must be governed through the same registration and authorisation process as internal users, with equivalent security controls applied.

What auditors examine

Auditors examine MFA configuration and verify that MFA is consistently enforced for external and remote access throughout the audit period. They review authentication event logs to verify that no external sessions to in-scope systems occurred without a preceding successful MFA event. They also examine contextual access policy configuration, verifying that device compliance, location, and IP restrictions are technically enforced.

How Akku addresses it

Adaptive MFA applied through the centralised authentication layer enforces MFA for all external and remote access. Step-up authentication triggers for access from new locations, unrecognised devices, or outside normal hours. Contextual access controls restrict access by device compliance status, IP range, geographic location, and time of day. Adaptive MFA addresses CC6.1 and CC6.6 across two mapping points. Access Manager addresses CC6.1 and CC6.6 across two mapping points.

CC6.7: Transmission and Movement Controls

CC6.7 requires that the transmission, movement, and removal of information is restricted to authorised internal and external users and processes. This covers data transfer controls at the endpoint and network layer.

What CC6.7 requires technically

CC6.7 requires controls preventing unauthorised data movement from organisational systems. At the endpoint layer, this covers USB storage restrictions, file sharing limitations, personal cloud drive blocking, and print restrictions. At the network layer, this covers FTP restrictions, upload controls, and DNS-based filtering of high-risk destinations.

How Akku addresses it

GPO Manager enforces USB storage restrictions, file sharing limitations, personal cloud drive and personal email blocking, FTP restrictions, upload controls, and screenshot prevention at the endpoint layer. DNS-based filtering restricts access to high-risk web categories. MDM enforces equivalent controls on mobile endpoints through app whitelisting and data transfer restrictions. GPO Manager addresses CC6.1, CC6.7, CC6.8, and CC7.1 across four mapping points. Mobile Device Manager addresses the same four criteria across four mapping points.

CC6.8: Malicious Software Prevention

CC6.8 requires that the entity implements controls to prevent or detect and act upon the introduction of unauthorised or malicious software. This covers endpoint application controls and software installation restrictions.

What CC6.8 requires technically

CC6.8 requires that endpoints are protected against unauthorised software installation and execution. Application whitelisting or blacklisting controls restrict which software can be installed and run. Software installation blocking prevents users from installing unapproved applications. Browser and download restrictions limit the introduction of malicious content through web browsing.

How Akku addresses it

GPO Manager enforces executable and application launch controls, software installation blocking, and download restrictions at the endpoint layer. MDM enforces app whitelisting on mobile devices and restricts installation of unapproved applications. These controls address CC6.8 alongside CC6.1, CC6.7, and CC7.1. Privileged Access Manager additionally addresses CC6.8 through session-level controls preventing unauthorised software execution during privileged sessions.

How CC6 Evidence Satisfies SOC 2 Type II Operating Effectiveness

SOC 2 Type II requires that CC6 controls operated effectively throughout the audit period. Every provisioning event, every access modification, every deprovisioning action, every authentication event, and every endpoint policy enforcement action must produce a structured, timestamped record throughout the period.

Akku’s continuous audit trail generates this evidence as a byproduct of daily operations. Provisioning records are created at the time of each onboarding event. Access review decisions are recorded at the time of each certification campaign cycle. Deprovisioning records are created at the time of each offboarding event. Authentication event logs are generated for every login attempt across all connected systems. Endpoint policy enforcement records are generated by GPO Manager and MDM for every policy application event.

When a SOC 2 Type II auditor samples CC6 controls from across the audit period, every sampled event has a corresponding structured record available for examination without retrospective compilation.

Diagnostic Questions

For any user onboarded during the last twelve months, can you produce the provisioning record showing formal authorisation before access was granted, without reconstructing it from email history?

When a user departed your organisation during the last twelve months, can you produce a timestamped record of every account removed across every in-scope system, and verify that removal completed within the same business day?

Has your access review process run on a defined cadence throughout the last audit period, producing documented certification or revocation decisions at every cycle, rather than running once before the audit?

Does your MFA enforcement cover all external and remote access to in-scope systems consistently throughout the audit period, with an authentication event log that auditors can sample from any point in that period?

Are your endpoint data movement controls, USB restrictions, file sharing limitations, and software installation blocking, technically enforced through GPO or MDM with configuration records, or policy-stated without technical enforcement evidence?

CTAs

See how Akku maps to SOC 2 CC6 logical access controls requirements across user registration, access modification, boundary protection, and endpoint controls.

Book a conversation with the Akku team to assess your current IAM posture against SOC 2 Type II CC6 operating effectiveness requirements.

FAQs

What is the primary difference between SOC 2 CC6.2 and CC6.3, and why do both require separate evidence?

CC6.2 covers user registration and authorisation before access is granted. It requires evidence of a formal process producing documented authorisation for every user onboarded. CC6.3 covers modification and removal of access as circumstances change. It requires evidence that role changes and departures resulted in timely, documented access adjustments and removals. CC6.2 is satisfied by provisioning records. CC6.3 is satisfied by access change records, deprovisioning audit trails, and access review outcomes. Both require continuous evidence throughout the audit period, not point-in-time documentation.

What does CC6.6’s boundary protection requirement mean for remote workers and contractors accessing systems from outside the corporate network?

CC6.6 requires that access from outside the organisation’s network boundary is subject to security controls proportionate to the external threat. For remote workers and contractors, this means MFA is enforced for every session to in-scope systems regardless of location, device compliance is verified before access is granted, and contextual access restrictions apply based on location and IP reputation. The boundary is not a physical network perimeter but a logical access boundary. Every access attempt from outside that boundary requires the additional controls CC6.6 specifies.

How frequently should access reviews run to satisfy CC6.3’s operating effectiveness requirement for SOC 2 Type II?

SOC 2 Type II does not specify a mandatory review frequency. The operating effectiveness standard requires that the review process ran consistently throughout the audit period and produced documented outcomes. Quarterly access reviews are the most common cadence among organisations seeking to demonstrate robust CC6.3 compliance. Annual reviews conducted once in the pre-audit window do not satisfy the operating effectiveness standard because auditors sample from across the period and a single review produces evidence for only one point in time.

What does CC6.7 require for data movement controls, and how is this different from a data loss prevention solution?

CC6.7 requires that the transmission, movement, and removal of information is restricted to authorised users and processes. This covers endpoint-level controls including USB restrictions, personal cloud drive blocking, and file sharing limitations. A dedicated data loss prevention solution performs content inspection and classification, intercepting transfers based on the content of the data. CC6.7 can be satisfied without content-level DLP by enforcing endpoint controls that restrict the channels through which data can be moved, regardless of content. GPO Manager and MDM address CC6.7 through channel-level restrictions at the endpoint layer.

Can a single IAM deployment produce CC6 evidence for both SOC 2 Type II and ISO 27001:2022 certification simultaneously?

Yes. The overlapping technical controls are substantial. SOC 2 CC6.1 and ISO 27001 A.8.5 both require logical access security infrastructure. SOC 2 CC6.2 and ISO 27001 A.5.16 both require formal user registration and provisioning processes. SOC 2 CC6.3 and ISO 27001 A.5.18 both require periodic access rights review and documented modification or removal. SOC 2 CC6.6 and ISO 27001 A.8.5 both require boundary protection and MFA for external access. A single Akku deployment implementing these controls produces compliance evidence for both frameworks from the same audit trail and governance infrastructure.

What is the consequence of having CC6.2 gaps where some users were provisioned outside the formal process during the audit period?

In a SOC 2 Type II engagement, CC6.2 gaps where provisioning occurred outside the formal process are typically raised as exceptions or nonconformities. Auditors sampling provisioning events from across the audit period who find events without formal authorisation records will note these as instances where the control did not operate as designed. If the exceptions are isolated, the auditor may note them without qualifying the opinion. If they are systemic or frequent, the auditor may qualify the opinion on CC6.2. The operating effectiveness standard requires consistent operation throughout the period, and gaps in the evidence record directly affect the audit outcome.