Indian companies with EU customers, EU operations, or EU-based employees are subject to the General Data Protection Regulation regardless of where the company is incorporated. Article 3 of GDPR establishes extraterritorial scope: any organisation that offers goods or services to EU residents, or that monitors their behaviour, falls within the regulation. For Indian ITeS companies processing EU client data, Indian enterprises with EU subsidiaries, and Indian technology companies with EU users, GDPR is not a foreign regulation. It is an operational requirement.

The technical obligations under GDPR are substantial and specific. Article 25 requires data protection by design and by default, meaning privacy controls must be built into systems architecture, not added as an afterthought. Article 32 requires appropriate technical and organisational measures to ensure security of processing. Articles 15 through 22 create Data Subject rights that require technical fulfilment infrastructure. Article 17’s right to erasure requires automated deletion workflows across connected systems, not manual database cleanup.

Most Indian organisations approaching GDPR compliance focus on the policy and legal layer: privacy notices, consent forms, data processing agreements, and DPO appointment. The technical implementation layer is a separate and more demanding exercise. A privacy notice does not constitute a consent management system. A data processing agreement does not constitute an access control implementation.

This blog covers what GDPR specifically requires at the technical layer, article by article, across lawful basis and consent, access controls and security measures, Data Subject rights, and audit accountability. All article references are drawn directly from the GDPR and Akku’s GDPR compliance mapping documentation, which addresses 36 of the 53 actionable GDPR compliance items with 57 mapping points across 12 modules.

Lawful Basis and Consent Requirements Under Articles 5 to 9

Articles 5 through 9 establish the lawful bases for processing personal data and define the consent requirements where consent is the chosen basis. For organisations relying on consent as a lawful basis, the technical infrastructure requirements are specific and demanding.

What the articles require

Article 5(1)(a) requires that personal data be processed lawfully, fairly, and transparently. Article 5(1)(b) requires purpose limitation: data collected for specified purposes must not be processed in a manner incompatible with those purposes. Article 5(1)(c) requires data minimisation: only data adequate, relevant, and limited to what is necessary may be processed. Article 5(1)(e) requires storage limitation: data must not be kept longer than necessary for the purposes for which it was collected.

Article 5(2) requires that the controller be able to demonstrate compliance with Article 5(1), the accountability principle. This is a technical as much as a governance requirement: the controller must be able to produce evidence of compliance, not merely assert it.

Article 6(1) establishes the lawful bases for processing, of which consent is one. Article 7 sets the conditions for consent: it must be freely given, specific, informed, and unambiguous. Consent must be as easy to withdraw as to give. Article 7(1) requires that the controller be able to demonstrate that consent was given.

Article 9(2)(a) permits processing of special category data where the data subject has given explicit consent for one or more specified purposes.

How Akku addresses it

Akku’s CIAM Consent Manager is the primary technical control for lawful basis and consent management. It addresses Articles 5(1)(a), 5(1)(b), 5(1)(c), 5(1)(d), 5(2), 6(1), 7(1), 7(2), 7(3), 7(4), 8(1), 8(2), and 9(2)(a) across 28 mapping points, the largest single-module count in Akku’s GDPR mapping.

Centralised consent record storage maintains versioned, timestamped consent records tied to specific Data Subject identities and specific processing purposes. Each consent record captures the notice version under which consent was given, the purpose, the timestamp, and the channel. This is the evidence that Article 7(1) requires the controller to be able to demonstrate.

Withdrawal workflows allow Data Subjects to withdraw consent as easily as they gave it, triggering downstream processing cessation notifications. This satisfies Article 7(3)’s withdrawal requirement. Purpose-specific consent management enforces Article 5(1)(b)’s purpose limitation at the data collection layer.

Access Control and Security Measures Under Articles 25 and 32

Articles 25 and 32 impose direct technical obligations on data controllers and processors. Article 25 requires privacy by design and by default. Article 32 requires appropriate technical and organisational security measures. Both are technical engineering obligations, not policy statements.

What the articles require

Article 25(1) requires that the controller implement appropriate technical and organisational measures designed to implement data protection principles effectively and integrate the necessary safeguards into the processing. Data protection must be built into the system architecture by design, not added after deployment.

Article 25(2) requires that the controller implement appropriate technical and organisational measures to ensure that, by default, only personal data necessary for each specific purpose is processed. This is the data minimisation by default requirement. Access to personal data must be restricted by default, with explicit authorisation required to expand access scope.

Article 32(1)(b) requires implementation of appropriate technical measures to ensure a level of security appropriate to the risk, including pseudonymisation and encryption of personal data where appropriate.

Article 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures.

Article 29 requires that processors and persons acting under the authority of the controller process data only on instructions from the controller. This creates an access governance requirement: access to personal data must be role-scoped and limited to authorised processing activities.

How Akku addresses it

Article 25(2)’s data minimisation by default requirement is addressed through RBAC and contextual access controls. Access to personal data systems is restricted by default. Expansion of access scope requires formal authorisation through structured request and approval workflows. Access Manager addresses Articles 5(1)(f), 24(1), 25(2), 29, and 32(1)(b) across five mapping points.

Article 32(1)(b) is addressed across multiple modules. Adaptive MFA reduces the risk of unauthorised access through credential compromise. Contextual access controls restrict processing to authorised environments. GPO Manager prevents personal data exfiltration from endpoints through USB restrictions, file sharing limitations, and upload controls. Password Manager encrypts credentials in AkkuVault using AES-256-GCM. Each of these contributes to the appropriate technical security measures Article 32(1)(b) requires.

Article 32(1)(d)’s testing and evaluation requirement maps to access review and re-certification campaigns. Periodic access reviews assess whether current access scope remains appropriate, producing documented evidence of ongoing control effectiveness evaluation. Identity and Access Governance addresses Articles 24(1), 25(2), and 32(1)(d) across three mapping points.

Article 29’s access governance requirement is addressed through RBAC role definitions scoped to authorised processing activities, provisioning workflows that limit access to what the role requires, and the SoD rules engine that prevents conflicting role combinations. Privileged Access Manager addresses Articles 5(1)(f), 29, and 32(1)(d) across three mapping points.

Data Subject Rights and Technical Fulfilment Infrastructure

Articles 15 through 22 establish eight Data Subject rights. Each right creates a corresponding technical obligation for the controller. Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice, which constitutes a compliance failure regardless of policy statements.

What the articles require

Article 15(1) gives Data Subjects the right to obtain confirmation of whether their personal data is processed, and if so, access to that data and information about the processing. This requires a self-service access portal or structured request fulfilment workflow.

Article 16 gives the right to rectification of inaccurate personal data. Article 17(1) gives the right to erasure, the right to be forgotten, under defined conditions including withdrawal of consent and completion of the purpose for which data was collected.

Article 18(1) gives the right to restriction of processing under defined conditions. Article 20(1) gives the right to data portability: receipt of personal data in a structured, commonly used, machine-readable format. Article 21(1) gives the right to object to processing.

Article 19 requires that the controller communicate rectification, erasure, or restriction to each recipient to whom personal data has been disclosed, unless this proves impossible or involves disproportionate effort.

How Akku addresses it

The CIAM Consent Manager addresses Articles 15(1), (3), 16, 17(1), 18(1), 20(1), 21(1), 21(2), and 25(1) through self-service Data Subject rights management workflows. Data Subjects can request access to their data, initiate correction and erasure requests, manage consent preferences, and exercise objection rights through the consent management portal.

User Lifecycle Manager addresses Articles 5(1)(e), 7(3), 17(1), and 19 across four mapping points. Automated deprovisioning workflows triggered by consent withdrawal or purpose completion ensure that erasure requests propagate across connected systems, not only in the primary data store. Notification workflows inform connected processors of erasure actions, satisfying Article 19’s communication requirement.

Article 30(1) and (2) require controllers and processors to maintain records of processing activities. Akku’s centralised audit log and provisioning records provide the access governance layer of the processing records requirement. CIAM Consent Manager and Audit Logs together address Article 30(1) and (2) across multiple mapping points.

Accountability and Audit Evidence Under Article 24

Article 24 requires that controllers implement appropriate technical and organisational measures and be able to demonstrate that processing is performed in accordance with GDPR. This is the accountability principle operationalised as a technical evidence requirement.

What the article requires

Article 24(1) requires that the controller implement appropriate technical and organisational measures to ensure and be able to demonstrate that processing is performed in accordance with the Regulation. The ability to demonstrate compliance is as much a requirement as compliance itself.

Article 5(2) reinforces this: the controller shall be responsible for, and be able to demonstrate compliance with, Article 5(1).

How Akku addresses it

Akku’s append-only, tamper-evident audit log is the technical infrastructure that makes Article 24(1) demonstrability possible. Every access grant, access review decision, provisioning action, deprovisioning action, consent record, consent withdrawal, and privileged session event produces a structured, timestamped, unmodifiable audit record.

This audit trail is the evidence base that a GDPR supervisory authority examination would draw on. Access controls that operate correctly but produce no structured evidence cannot satisfy Article 24(1)’s demonstration requirement. Audit Logs addresses Articles 5(2), 24(1), and 30(1) and (2) across three mapping points.

Identity and Access Governance addresses Article 24(1) through access certification records that demonstrate ongoing review of access appropriateness. Privileged Access Manager addresses Article 32(1)(d) through session-level evidence of control operating effectiveness.

How IAM Addresses GDPR Technical Obligations

Akku’s GDPR compliance mapping addresses 36 of the 53 actionable GDPR compliance items with 57 mapping points across 12 modules. The CIAM Consent Manager carries 28 of the 57 mapping points, reflecting how central consent infrastructure and Data Subject rights fulfilment are to GDPR’s technical requirements for organisations relying on consent as a lawful basis.

The remaining 17 items outside Akku’s scope relate to organisational obligations including DPO appointment, data protection impact assessments, breach notification procedures, international transfer mechanisms, and contractual obligations with processors. Full GDPR compliance requires these technical controls combined with the legal and governance measures those items require.

An important scoping note for Indian companies: GDPR compliance requires both the technical controls IAM provides and the legal framework compliance requires. Appointment of a Data Protection Officer where required, maintenance of records of processing activities, execution of data processing agreements with processors, and assessment of international transfer mechanisms are legal obligations that sit alongside the technical controls this blog covers.

Questions Indian Companies Ask About GDPR Technical Obligations

Does GDPR apply to Indian companies with no EU office or EU employees?

Yes. Article 3 of GDPR establishes extraterritorial scope based on the location of Data Subjects, not the location of the controller or processor. An Indian company that offers goods or services to EU residents, processes EU resident data on behalf of EU clients, or monitors the behaviour of EU residents is subject to GDPR regardless of where it is incorporated or operates. For Indian ITeS companies processing EU client data, Indian technology companies with EU users, and Indian enterprises with EU operations, GDPR compliance is a direct obligation.

What is the difference between Article 25 data protection by design and Article 32 security measures?

Article 25 requires that privacy controls be built into system architecture by design and that data minimisation be the default configuration, meaning only necessary data is accessible by default without explicit authorisation to expand scope. Article 32 requires appropriate technical security measures to protect personal data against risks including unauthorised access, destruction, and disclosure. Article 25 is about architecture and design choices. Article 32 is about operational security controls. Both impose technical obligations, and satisfying one does not satisfy the other.

What does GDPR’s right to erasure under Article 17 require technically?

Article 17 gives Data Subjects the right to erasure of their personal data under defined conditions including withdrawal of consent and completion of the purpose for which data was collected. Technically, this requires erasure workflows that propagate deletion requests across all connected systems where the Data Subject’s data is held, not only in the primary data store. Article 19 additionally requires that the controller inform each recipient to whom data was disclosed of the erasure. At scale, manual fulfilment of erasure requests across multiple connected systems is not operationally viable within any reasonable timeframe.

What records does Article 30 require controllers to maintain, and how does IAM contribute to this?

Article 30 requires controllers to maintain records of processing activities covering the name and contact details of the controller, purposes of processing, categories of Data Subjects and personal data, categories of recipients, transfers to third countries, retention periods, and a general description of technical and organisational security measures. IAM contributes to this through access governance records showing who is authorised to process which categories of personal data, provisioning audit trails showing when access was granted and on what basis, and access review records demonstrating ongoing governance of processing authorisations.

How does GDPR’s accountability principle under Article 24 differ from simply implementing controls?

Article 24 requires not only that appropriate technical measures are implemented, but that the controller is able to demonstrate that processing is performed in accordance with GDPR. The demonstration requirement means that controls must produce structured, reviewable evidence of their operation, not merely function correctly. A technically effective access control that produces no audit record cannot satisfy Article 24(1) because its effectiveness cannot be demonstrated to a supervisory authority. The audit trail infrastructure that generates continuous, tamper-evident evidence of control operation is what makes the accountability principle technically satisfiable.

Can a single IAM deployment address both GDPR and DPDPA requirements simultaneously?

Yes. The overlapping technical controls are substantial. GDPR Article 7 and DPDPA Clause 6 both require that consent be freely given, specific, informed, and withdrawable with equivalent ease. GDPR Article 17 and DPDPA Clause 8(7) both require erasure when the processing purpose is no longer served. GDPR Article 25(2) and DPDPA Clause 8(4) both require data minimisation by default and access controls limited to authorised purposes. A single Akku deployment implementing consent management, access controls, lifecycle management, and audit trail generation produces compliance evidence for both frameworks from the same technical infrastructure.