Introduction
GDPR Articles 15 through 22 establish eight rights for Data Subjects. Each right creates a corresponding technical obligation for the controller. The right to access personal data requires a self-service portal or fulfilment workflow capable of producing a structured summary of personal data and processing activities within one month. The right to erasure requires workflows that propagate deletion across every connected system where the Data Subject’s data is held. The right to data portability requires export in a structured, machine-readable format. The right to restriction requires a technical flag that prevents processing without deleting data.
Rights that exist on paper but lack technical fulfilment infrastructure cannot be exercised in practice. An organisation that describes its Data Subject rights commitment in a privacy notice but has no technical mechanism for fulfilling an access request within one month has not implemented the right. The supervisory authority will assess whether rights are technically exercisable, not whether they are described in documentation.
The scale problem makes this critical for organisations with large user populations. An organisation processing data for hundreds of thousands of customers cannot fulfil Data Subject rights requests through manual processes within GDPR’s one-month response window. At scale, manual fulfilment is operationally impossible. Technical fulfilment workflows are the only viable approach.
This blog covers what each of the primary GDPR Data Subject rights requires technically, what the fulfilment infrastructure must be capable of, and how each right interacts with the IAM and consent management infrastructure. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.
Right to Access Under Article 15
Article 15 gives Data Subjects the right to obtain confirmation of whether their personal data is being processed and, if so, access to that data and information about the processing.
What Article 15 requires technically
Article 15(1) requires that the controller provide confirmation of processing and, where processing is occurring, access to the personal data being processed, the purposes of processing, the categories of data, the recipients or categories of recipients with whom data has been shared, the envisaged retention period, the existence of other Data Subject rights, the right to lodge a complaint with a supervisory authority, and the source of the data where it was not collected directly from the Data Subject.
Article 15(3) requires that the controller provide a copy of the personal data undergoing processing. The copy must be in a format that the Data Subject can understand.
The one-month response window under Article 12(3) applies: the controller must respond within one month of receiving the request, with a possible extension to three months for complex or numerous requests.
What this requires technically
A self-service access request portal is required for organisations with large user populations. The portal must allow Data Subjects to submit access requests and receive structured responses without requiring manual processing by staff for each request.
The response must be assembled from all systems processing the Data Subject’s personal data. This requires a data mapping that connects the Data Subject’s identity to all systems holding their data, and a query mechanism for assembling the response from those systems.
The recipient disclosure under Article 15(1)(c) requires that the controller maintain a current record of every entity to whom each Data Subject’s personal data has been disclosed. This is a data governance record that must be queryable at the time of an access request.
Akku’s CIAM Consent Manager addresses Article 15(1) and (3) through Data Subject access request workflows, with the consent record providing the processing purpose and recipient information components of the required response.
Right to Rectification Under Article 16
Article 16 gives Data Subjects the right to obtain rectification of inaccurate personal data and completion of incomplete personal data.
What Article 16 requires technically
Rectification requests must update personal data across every connected system where it is held. A name correction applied in the CRM but not in the billing system, the support system, and the marketing platform is an incomplete rectification. The controller must ensure that the correction propagates across all systems holding the relevant personal data.
Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of the rectification, unless this proves impossible or involves disproportionate effort. For organisations using Data Processors who hold copies of the personal data, the notification workflow must reach every processor holding the data that was corrected.
What this requires technically
A rectification workflow must accept the correction from the Data Subject, update the primary record in the relevant system, propagate the correction to all connected systems holding the data, and notify Data Processors of the correction where required.
At scale, this propagation must be automated. A manual process requiring a staff member to update each system individually cannot operate reliably within the one-month response window for high volumes of rectification requests.
Akku’s CIAM Consent Manager and User Lifecycle Manager together address Article 16 through correction workflow capabilities and downstream propagation mechanisms.
Right to Erasure Under Article 17
Article 17 gives Data Subjects the right to erasure of their personal data, the right to be forgotten, under defined conditions including withdrawal of consent, completion of the purpose for which data was collected, and objection to processing.
What Article 17 requires technically
Article 17(1) specifies the conditions under which erasure must be fulfilled: the data is no longer necessary for the purpose for which it was collected, the Data Subject withdraws consent and no other lawful basis applies, the Data Subject objects to processing under Article 21 and there are no overriding legitimate grounds, the data was unlawfully processed, or erasure is required for compliance with a legal obligation.
Article 17(2) requires that where the controller has made personal data public, they take reasonable steps to inform other controllers processing the data of the erasure request.
Article 19 requires notification to recipients of the erasure, as with rectification.
What this requires technically
Erasure workflows must delete personal data from every system where it is held, not only from the primary database. The erasure must be verifiable: the controller must be able to demonstrate that the data was deleted from each system. Where data is held in backup systems, the erasure timeline must account for backup retention cycles and document when backup copies will be overwritten.
The erasure workflow must respect legal retention obligations that may override the erasure right. Where data must be retained for legal compliance, the controller may restrict processing rather than erase, pending the end of the retention period.
Downstream notification to Data Processors and other recipients must be automated for organisations with multiple processors. The notification must include the Data Subject identity and the scope of the erasure so that processors can take corresponding action.
Akku’s CIAM Consent Manager addresses Articles 17(1) and 19 through erasure workflow capabilities. The User Lifecycle Manager addresses Article 17 through automated deprovisioning workflows triggered by consent withdrawal under Clause 8(7)(b) of DPDPA, with equivalent functionality supporting GDPR Article 17 erasure workflows.
Right to Restriction Under Article 18
Article 18 gives Data Subjects the right to restrict processing of their personal data in defined circumstances: the accuracy of the data is contested, the processing is unlawful but the Data Subject prefers restriction over erasure, the controller no longer needs the data but the Data Subject requires it for legal claims, or the Data Subject has objected to processing pending verification of whether the controller’s legitimate grounds override.
What Article 18 requires technically
Restriction of processing means the personal data is retained but processing activities are suspended. The data must be flagged as restricted in every system where it is held. Processing operations that are not permitted during restriction, typically everything except storage, legal claims, protection of rights of another person, or public interest grounds, must be blocked for flagged records.
Restriction is technically more complex than erasure because it requires a persistent flag that modifies the processing behaviour of every system holding the data, rather than simply deleting it. The flag must persist until the restriction is lifted by the Data Subject or until the conditions for restriction no longer apply.
A restriction flag system must be queryable across all connected systems and must prevent processing of flagged records at the application layer.
Right to Data Portability Under Article 20
Article 20 gives Data Subjects the right to receive their personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller.
What Article 20 requires technically
Article 20(1) requires that the controller provide personal data in a structured, commonly used, machine-readable format where processing is based on consent or contract and is carried out by automated means.
The machine-readable format requirement means JSON, CSV, or XML, not a PDF. The Data Subject must be able to use the exported data in another system without manual reformatting.
The portability right applies to personal data provided by the Data Subject: data derived by the controller from the Data Subject’s data is not covered. A customer’s purchase history is portable. Analytics models derived from that history are not.
A self-service data export function that produces machine-readable output covering all in-scope personal data categories is the technical implementation of Article 20. The export must be generated from the controller’s data processing systems and delivered to the Data Subject securely.
Right to Object Under Article 21
Article 21 gives Data Subjects the right to object to processing of their personal data based on the controller’s legitimate interests or for direct marketing purposes.
What Article 21 requires technically
Article 21(1) requires that processing cease when a Data Subject objects, unless the controller demonstrates compelling legitimate grounds that override the Data Subject’s interests or the processing is for the establishment, exercise, or defence of legal claims.
Article 21(2) provides an absolute right to object to processing for direct marketing purposes, with no balancing test required.
What this requires technically
An objection workflow must receive the objection, assess whether compelling legitimate grounds apply for non-marketing processing, suppress the Data Subject’s records from marketing processing immediately and unconditionally, and propagate the suppression to all systems conducting the relevant processing.
The marketing suppression must be immediate and technically enforced. A marketing suppression flag that relies on staff to manually update mailing lists does not satisfy Article 21(2)’s absolute marketing opt-out right.
Akku’s CIAM Consent Manager addresses Articles 21(1) and 21(2) through objection and marketing suppression workflows, with the consent record data model supporting objection status per processing purpose.
The Common Technical Infrastructure Across All Rights
All six Data Subject rights require a common technical foundation: a Data Subject identity verification mechanism at the point of rights exercise, a structured rights submission portal, automated fulfilment workflows for each right type, cross-system propagation mechanisms for corrections and erasures, and an audit trail covering every rights request and fulfilment action.
Identity verification
Before fulfilling any Data Subject rights request, the controller must verify that the requester is the Data Subject or an authorised representative. Insufficient verification creates a risk of inadvertent disclosure to unauthorised parties. Excessive verification creates barriers that effectively deny the right.
The verification mechanism must be proportionate to the sensitivity of the data involved and the nature of the right being exercised. An access request for contact details requires lighter verification than an erasure request for financial records.
Audit trail for rights fulfilment
Every rights request and every fulfilment action must produce a timestamped audit record. The request receipt, the verification outcome, the fulfilment action taken, the systems updated, and the response sent must all be captured in a structured record.
The rights fulfilment audit trail is the evidence a supervisory authority will examine when a Data Subject complains that their rights were not fulfilled. It must demonstrate that the request was received, acted upon within the required timeframe, and fulfilled completely.
Akku’s CIAM Consent Manager produces a structured audit trail for every Data Subject rights exercise event. The audit trail is append-only and tamper-evident, constituting the demonstrability evidence that Article 5(2)’s accountability principle requires.
Diagnostic Questions
Can your organisation fulfil a Data Subject access request by producing a structured summary of all personal data held and all processing activities within one month, without a manual data compilation exercise across multiple system administrators?
When a Data Subject requests erasure, does the deletion propagate automatically to every connected system holding their personal data, and does the controller receive confirmation of deletion from each system?
Does your organisation maintain a restriction processing flag that can be applied to a Data Subject’s records across all connected systems, blocking non-permitted processing activities for flagged records?
Is your data portability export function capable of producing personal data in machine-readable format, covering all in-scope data categories, without requiring staff to manually compile and format the export?
When a Data Subject objects to direct marketing processing, is the suppression applied immediately and automatically across all marketing processing systems, or does it require manual update of individual mailing lists?
CTAs
See how Akku’s CIAM Consent Manager addresses GDPR Data Subject rights requirements across access, rectification, erasure, restriction, portability, and objection workflows.
Book a conversation with the Akku team to assess your current Data Subject rights fulfilment infrastructure against GDPR’s technical obligations.
FAQs
What is the one-month response window under GDPR Article 12, and when does it start?
Article 12(3) requires that the controller respond to Data Subject rights requests without undue delay and in any event within one month of receiving the request. The one-month period begins when the controller receives the request, not when they begin processing it. Where requests are complex or numerous, the controller may extend the period by a further two months, but must inform the Data Subject of the extension and the reasons for it within the initial one-month period. For high-volume organisations, manual fulfilment processes that require days to initiate will frequently fail to deliver responses within the one-month window, making automated fulfilment workflows necessary.
Does the right to erasure under Article 17 apply to all personal data a controller holds, or only to data in primary systems?
The right to erasure applies to all personal data the controller processes, regardless of where it is stored. This includes primary databases, backup systems, archive storage, third-party processors, and any other location where the controller’s personal data exists. For backup systems, erasure may not be immediately executable because backup media cannot always be selectively overwritten. The recommended approach is to maintain a suppression record that prevents the backup data from being restored and used after the erasure request is received, and to document when the backup copies will be overwritten through normal backup rotation. The controller must inform the Data Subject that complete erasure from backup systems will occur at the next backup rotation.
What does machine-readable format mean for Article 20 data portability, and what formats satisfy the requirement?
Machine-readable format means a structured format that can be processed by software without manual reformatting. JSON, CSV, and XML are the formats that satisfy this requirement. A PDF is not machine-readable for portability purposes because it cannot be processed by another system without format conversion. The format must be commonly used, meaning the Data Subject can use standard software to read and transfer the data to another controller. The portability export must cover personal data provided by the Data Subject and processed on the basis of consent or contract by automated means. Derived data, analytics models, and inferred attributes are not covered by the portability right.
How does the right to restriction under Article 18 differ from the right to erasure under Article 17?
Erasure removes personal data from all systems. Restriction retains the data but suspends most processing activities. The Data Subject may prefer restriction over erasure where they need the data for legal claims, where the accuracy is being contested and they want the data retained pending verification, or where the processing is unlawful but the Data Subject prefers to have it restricted rather than deleted. Technically, restriction requires a persistent flag that modifies processing behaviour across all systems holding the data, while erasure requires deletion. Restriction is more technically demanding because it requires ongoing enforcement across all systems, not a one-time deletion action.
What notification obligations arise when a Data Subject exercises erasure or rectification rights under Article 19?
Article 19 requires that the controller inform each recipient to whom personal data has been disclosed of any rectification, erasure, or restriction, unless this proves impossible or involves disproportionate effort. Recipients include Data Processors who hold copies of the data and other controllers to whom the data was disclosed. The notification must include the Data Subject identity and the scope of the rectification, erasure, or restriction so that recipients can take corresponding action. For organisations with multiple Data Processors, the notification workflow must reach every processor holding the relevant data. Manual coordination across multiple processors is not scalable for high-volume rights exercises. Automated notification workflows that propagate rights exercise events to connected processors are required at scale.
Can a single CIAM deployment address both GDPR and DPDPA Data Subject and Data Principal rights requirements simultaneously?
Yes. GDPR Articles 15 through 21 and DPDPA Clauses 11 through 14 share substantial overlapping requirements. Both require self-service access to personal data summaries. Both require correction and erasure workflows that propagate across connected systems. Both require withdrawable consent with automated processing cessation. Both require a rights submission portal with structured request and response records. Akku’s CIAM Consent Manager implements the rights fulfilment infrastructure that satisfies both frameworks from a single deployment. The consent record data model and audit trail architecture are extended to capture the specific fields each framework requires, and the fulfilment workflows handle both GDPR and DPDPA rights exercise events through the same operational infrastructure.
