SOC 2 Type II has become a commercial prerequisite for Indian ITeS and BPO companies serving enterprise clients in North America and Europe. Enterprise procurement teams increasingly require a current SOC 2 Type II report before awarding contracts involving access to their systems, data, or infrastructure. For ITeS companies handling healthcare data, financial records, or personally identifiable information, the requirement is near-universal.

The distinction between Type I and Type II is not administrative. Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively over a defined period, typically six to twelve months. The operating effectiveness standard requires that controls produce consistent, structured evidence throughout the audit period, not only at the moment of assessment. An access review conducted once before the audit window opens does not satisfy Type II. An access review process that runs continuously and produces documented outcomes every cycle does.

Most Indian ITeS companies approaching SOC 2 for the first time underestimate the evidence infrastructure required for the Logical Access Controls criteria under CC6. CC6.1 through CC6.8 together require that logical access to systems is controlled, monitored, and reviewed throughout the audit period, with structured evidence of every control operating as designed. This blog covers the Trust Services Criteria most relevant to ITeS operations, what each criterion requires technically, and how IAM controls produce the continuous operating evidence SOC 2 Type II 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.

SOC 2 Framework Structure and ITeS Applicability

SOC 2 is structured around five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for all SOC 2 engagements. The other four categories are included based on the services provided and client requirements.

Trust Services Categories relevant to ITeS

Security is the mandatory category and contains the Common Criteria (CC) that apply to all SOC 2 engagements. The CC criteria run from CC1 through CC9 covering the COSO internal control framework, logical access, system operations, change management, and risk mitigation.

Privacy is increasingly included in SOC 2 engagements for ITeS companies handling personal data on behalf of clients. The Privacy criteria (P1 through P8) cover notice and communication, choice and consent, collection, use and retention, access, disclosure, quality, and monitoring and enforcement.

For most Indian ITeS companies, the Security category with CC5, CC6, and CC7 and the Privacy category covering P1 through P6 represent the primary compliance scope. This blog covers these criteria specifically.

Type I versus Type II evidence requirements

Type I requires evidence that controls are suitably designed at a point in time. An auditor reviews control documentation, policy descriptions, and a sample of control outputs to assess design suitability.

Type II requires evidence that controls operated effectively throughout the audit period. An auditor reviews control outputs across the entire period, typically testing samples from multiple points across six to twelve months. A control that worked correctly once but had gaps during the period does not satisfy Type II. Continuous, structured evidence generation is the operational requirement.

Logical Access Controls Under CC6

CC6 is the Logical and Physical Access Controls criterion cluster and is where most IAM-relevant requirements sit. CC6.1 through CC6.8 cover logical access security, user registration, access modification and removal, boundary protection, transmission controls, and malicious software prevention.

What the criteria require

CC6.1 requires that logical access security software, infrastructure, and architectures are implemented to protect against threats from sources outside the system boundary. This covers centralised identity management, MFA enforcement, and access control infrastructure.

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 registration and provisioning control. Every user must be registered through a formal process before access is granted.

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 is the access modification and removal control, covering role changes, access reviews, and deprovisioning.

CC6.6 requires that logical access security measures are implemented to protect against threats from persons acting outside the entity’s system boundaries. This covers boundary protection controls including MFA for external access and contextual access restrictions.

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 and endpoint restrictions on data movement.

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.

How Akku addresses it

CC6.1 is addressed through Akku’s unified cloud identity store, SSO infrastructure, and Adaptive MFA. Centralised identity management, consistent MFA enforcement, and contextual access controls together constitute the logical access security architecture CC6.1 requires. Akku’s SOC 2 mapping shows Cloud Directory addresses CC6.1 and CC6.2, SSO and IDP addresses CC6.1, and Adaptive MFA addresses CC6.1 and CC6.6.

CC6.2 is addressed through structured access request and provisioning workflows. Every user is registered through a formal process. Birthright access is assigned based on role. Additional access requires a documented request and approval. SCIM-based provisioning synchronises approved access to connected applications. The provisioning audit trail covers requester, approver, justification, timestamp, and downstream sync confirmation.

CC6.3 is addressed through automated User Lifecycle Management and access review campaigns. Role changes trigger re-provisioning. Departure triggers automated deprovisioning. Periodic re-certification campaigns send certification requests to managers and resource owners with timestamped, logged decisions. The Identity and Access Governance module addresses CC5.1, CC6.2, and CC6.3 across three mapping points. User Lifecycle Manager addresses CC6.2 and CC6.3.

CC6.6 is addressed through contextual access controls applying IP, device, geo-location, and time-of-day restrictions, combined with Adaptive MFA for external and remote access scenarios.

CC6.7 and CC6.8 are addressed through GPO Manager and MDM endpoint controls. USB restrictions, file sharing limitations, application launch controls, and software installation blocking address the data movement and malicious software prevention requirements. GPO Manager addresses CC6.1, CC6.7, CC6.8, and CC7.1 across four mapping points. Mobile Device Manager addresses the same four criteria.

Control Activities and Segregation of Duties Under CC5

CC5 covers the COSO principle of control activities and includes requirements for general controls over technology and segregation of duties. CC5.1 and CC5.2 are the criteria most directly addressed by IAM controls.

What the criteria require

CC5.1 requires that the entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. For IAM, this includes SoD enforcement, access reviews, and access governance processes that mitigate the risk of unauthorised access or fraud.

CC5.2 requires that the entity selects and develops general control activities over technology to support the achievement of objectives. This covers technology controls including logical access controls, change management controls, and system operations controls.

How Akku addresses it

CC5.1 is addressed through the IGA SoD rules engine. The engine defines conflicting role combinations, detects violations continuously, and triggers automated remediation. Access certification campaigns provide the periodic control activity that mitigates entitlement drift risk. Identity and Access Governance addresses CC5.1 alongside CC6.2 and CC6.3.

CC5.2 is addressed through Privileged Access Manager, which provides general control activities over technology systems. The session approval workflow, per-session ephemeral credentials, and SMARTAudit Trails together constitute the general technology controls CC5.2 requires for privileged system access. Privileged Access Manager addresses CC5.2, CC6.1, CC6.3, CC6.8, and CC7.2 across five mapping points, the highest single-module count in Akku’s SOC 2 mapping.

Anomaly Detection and Monitoring Requirements Under CC7

CC7 covers system operations and monitoring. CC7.1 and CC7.2 are the criteria relevant to IAM monitoring capabilities.

What the criteria require

CC7.1 requires that the entity uses detection and monitoring procedures to identify changes to configurations or new vulnerabilities, and conducts ongoing monitoring of the environment. For IAM, this covers endpoint configuration monitoring and authentication anomaly detection.

CC7.2 requires that the entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, or errors affecting the entity’s ability to meet its objectives. Authentication anomaly detection, MFA failure monitoring, and privileged session monitoring are the IAM-layer controls that address CC7.2.

How Akku addresses it

CC7.1 is addressed through GPO Manager and MDM, which enforce and monitor endpoint configurations. Policy violations, non-compliant device states, and configuration changes are surfaced through centralised dashboards. GPO Manager and Mobile Device Manager each address CC7.1 alongside CC6.1, CC6.7, and CC6.8.

CC7.2 is addressed through Akku’s identity and access security monitoring layer. AI-powered anomaly detection in Adaptive MFA evaluates each authentication event against the user’s behavioural baseline. MFA failure spikes, geographic anomalies, and access outside defined time windows generate alerts for administrator review. Real-time privileged session monitoring through AkkuReka allows instant detection and termination of suspicious sessions. Privileged Access Manager addresses CC7.2 alongside CC5.2, CC6.1, CC6.3, and CC6.8.

Privacy Criteria Requirements Under P1 to P6

The Privacy criteria are increasingly included in SOC 2 engagements for ITeS companies handling personal data. P1 through P6 cover notice, consent, collection, use, access, and disclosure of personal information. The CIAM Consent Manager module is the primary technical control addressing these criteria.

What the criteria require

P1.1 requires that the entity provides notice about its privacy practices to individuals whose personal information it collects. Notice must be clear, accessible, and cover the purposes of collection, use, and disclosure.

P2.1 requires that the entity communicates choices available regarding the collection, use, and disclosure of personal information and obtains implicit or explicit consent. Consent must be recorded.

P3.1 requires that personal information is collected only for the purposes identified in the notice. Collection must be limited to what is necessary.

P3.2 requires that the entity collects personal information only with the explicit or implicit consent of the individual.

How Akku addresses it

The CIAM Consent Manager addresses P1.1, P2.1, P3.1, and P3.2 directly, alongside CC6.1 across five mapping points, the joint highest single-module count with Privileged Access Manager in Akku’s SOC 2 mapping.

Centralised consent record storage maintains versioned, timestamped consent records tied to specific individual identities and specific processing purposes. Preference management across channels ensures consent preferences are consistent. Full consent audit trails for every update provide the evidence record P1.1 and P2.1 require. Collection limitation controls enforce P3.1’s data minimisation requirement at the identity layer.

How IAM Addresses SOC 2 Type II Operating Effectiveness Requirements

Akku’s SOC 2 mapping addresses 14 of the 61 top-level Trust Services Criteria with 31 overlapping mapping points across 11 modules. The operating effectiveness requirement of Type II means that evidence must be continuous, not point-in-time.

Every provisioning action, access review decision, privileged session record, authentication event, and deprovisioning action produces a timestamped, structured audit record as a byproduct of normal operations. This continuous evidence generation is what SOC 2 Type II auditors sample across the audit period. Controls that operate correctly but produce no structured evidence fail the operating effectiveness standard regardless of how well they are designed.

The practical implication for ITeS companies is that manual access management processes, email-based approvals, spreadsheet-tracked access reviews, and informally managed deprovisioning cannot produce the continuous, structured evidence SOC 2 Type II requires. The evidence infrastructure must be built into the operational processes, not assembled before each audit cycle.

Questions Indian ITeS and BPO Companies Ask About SOC 2 Type II Trust Services Criteria

What is the difference between SOC 2 Type I and Type II, and why does it matter for ITeS companies?

SOC 2 Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively throughout a defined audit period, typically six to twelve months. Enterprise clients in North America and Europe typically require Type II because it provides assurance of consistent control operation over time, not a snapshot. For ITeS companies, this means the evidence infrastructure must generate continuous, structured outputs throughout the audit period. Controls that work correctly but produce no structured evidence fail the Type II operating effectiveness standard.

Which SOC 2 Trust Services Categories should an Indian ITeS company include in its engagement?

Security is mandatory for all SOC 2 engagements. ITeS companies handling personal data on behalf of clients should consider including Privacy, as enterprise clients increasingly require it for data processing engagements. Availability may be required for ITeS companies providing infrastructure or platform services with uptime commitments. Processing Integrity applies to companies providing transaction processing services. The specific categories included should be determined based on client requirements and the nature of services provided.

What does CC6.3 require for access removal, and how quickly must access be revoked when roles change?

CC6.3 requires that access be modified or removed based on approved and documented access requests and the system of record for user entitlements. SOC 2 does not specify a defined revocation timeframe, but auditors assess whether the process operates consistently and produces documented evidence of timely action. In practice, automated deprovisioning triggered by HR system events, completing within the same business day, with a timestamped audit record of every account removed, is the standard that satisfies the operating effectiveness examination.

What evidence does a SOC 2 Type II auditor expect for CC6.2 user registration controls?

CC6.2 auditors typically look for evidence of a formal user registration process covering the full audit period. This includes access request records showing who requested access, what was requested, and who approved it; provisioning records showing that access was granted in accordance with approvals; evidence that access was granted only after formal authorisation; and a consistent process applied throughout the audit period. Auditors sample provisioning events across the period rather than examining only recent records, so the process must have operated consistently from the start of the audit window.

How do the SOC 2 Privacy criteria apply to Indian ITeS companies processing client data?

SOC 2 Privacy criteria apply when an organisation handles personal information on behalf of clients. For Indian ITeS companies, this covers BPO processing of customer records, KYC data handling, healthcare data processing for US clients, and any service involving personal data of individuals. P1 through P6 require that individuals receive notice of data practices, that consent is obtained and recorded where required, that collection is limited to identified purposes, and that individuals have access to their data. CIAM Consent Manager addresses these criteria for customer-facing consent and preference management.

Can a single IAM deployment support 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. SOC 2 CC6.3 and ISO 27001 A.5.18 both require periodic access rights review. SOC 2 CC5.2 and ISO 27001 A.8.2 both require controlled privileged access. SOC 2 CC7.2 and ISO 27001 A.8.16 both require anomaly detection and monitoring. A single IAM deployment implementing these controls produces compliance evidence for both certifications from the same audit trail and governance infrastructure, reducing the duplication of effort that separate compliance programmes create.