The General Data Protection Regulation (GDPR), which came into force on 25 May 2018, introduced a uniform framework for the protection of personal data across the European Union and the European Economic Area. Since then, organizations have been bound by strict requirements regarding the lawfulness and transparency of all processing activities, with the privacy rights of data subjects taking center stage. The GDPR establishes a comprehensive system of rights and obligations, ranging from core principles such as data minimization and purpose limitation to the individual rights of data subjects to access, rectify, erase, and port their data. These rights are not merely legal abstractions but require adjustments in IT systems, internal processes, and both contractual and organizational responsibilities to ensure end-to-end control of the processing chain from front-end to back-end.
At the same time, the introduction of this wide array of rights has presented significant challenges for executives and board members of both private companies and public authorities. The obligation to respond to requests within one month necessitates automated workflows for handling such requests and robust authentication methods to prevent fraud or identity verification issues without causing data leaks. Furthermore, conflicting requirements must be considered—for example, where the right to erasure clashes with legal retention obligations for tax or criminal law purposes. Striking a balance between these competing interests while maintaining public and regulatory trust requires decisive governance, significant investments in tooling, and a culture in which privacy protection is deeply embedded.
Right of Access (Article 15)
The right of access grants data subjects substantial control over their collected personal data by enabling them to receive a full copy of all processing activities. This includes not only the actual data sets but also information on the categories of data processed, the intended purposes, and the recipients or categories of recipients. Organizations must also disclose retention periods and, where data has not been obtained directly from the data subject, the source of that data. This requires seamless integration between customer relationship systems, marketing databases, HR platforms, and other data repositories to aggregate all processed attributes quickly and accurately.
Practical implementation of this right requires a robust request portal capable of authenticating submissions without introducing unnecessary barriers. At the same time, the portal must allow for bundling of documents, screenshots, and processing chain logs. Authentication methods must not expose other individuals’ data but must provide sufficient assurance that access is not being granted fraudulently. Technical solutions such as zero-knowledge proof techniques and privacy-preserving identity verification can help maintain this delicate balance.
Right to Rectification (Article 16)
The right to rectification allows data subjects to correct inaccurate or incomplete personal data, ensuring data quality and process accuracy. Organizations must implement procedures that validate each correction request against reliable source data or external authorities. This validation must not repeatedly expose personal data, but must provide conclusive evidence that the correction is justified—e.g., through automated cross-checks with government databases or certified data providers.
Once a rectification is approved, the correction must be propagated across all systems where the data resides. This often requires transaction-consistent replication across data lakes, analytics silos, and external reporting systems. Ensuring consistency requires event-driven architectures or batch-based synchronization routines, along with control mechanisms to detect if corrections have been implemented in one system but not another. All changes must also be logged for future auditing and accountability purposes.
Right to Erasure (Right to Be Forgotten) (Article 17)
The right to be forgotten enables data subjects to demand the deletion of their personal data when it is no longer necessary for the purposes for which it was collected, when consent is withdrawn, or when processing is unlawful. Operationally, this requires mapping all data at rest and data in transit so that deletions do not leave remnants in backups or archives. Organizations must have processes in place to ensure deletions are complete and irreversible, including cleaning up indexes and metadata records.
At the same time, legal retention obligations—such as tax-related retention periods or requirements for ongoing legal proceedings—serve as counterindications. In such cases, a deletion request must be denied or only partially fulfilled, with explicit communication to the data subject explaining the grounds for the exceptions. Technical measures such as automated retention policies and legal workflows for case assessments are essential to manage this delicate balance effectively.
Right to Restriction of Processing (Article 18)
In the case of a request to restrict processing, the organization must stop – suspend – the processing without fully erasing the data. The data remains retained, but further use is excluded. This is relevant, for example, during the period in which the accuracy of the data is being investigated. Technically, this should be covered by flags in the databases that block all operations once the restriction is activated. Applications and API calls must respect these flags, allowing only authorized administrators to lift the restriction.
Operationally, this requires service teams, from customer support to marketing and analytics, to be informed about which data is under restriction. Business processes need to be adjusted to prevent unintended emails from being sent or marketing campaigns from being executed using the restricted data. Moreover, reporting tools and dashboards must indicate that data is under restriction, so that management has real-time insight into the operational impact and the progress of the review process.
Right to Data Portability (Article 20)
The right to data portability requires organizations to provide personal data in a structured, commonly used, and machine-readable format, so that the individual can easily migrate the data to another controller. This calls for the production of export files in open standards such as JSON schemas or CSV formats with clear data dictionary metadata. Technical limits of API endpoints, file sizes, and the security of the transfer, such as through encrypted channels or time-limited download links, must also be considered.
The transfer must also be proportional: only data directly related to the service provided or the original purpose of data collection may be exported. Complex data sets from microservices environments, ETL pipelines, or analytics data platforms must be filtered on relevant fields. Automation with data masking or pseudonymization can help to exclude sensitive secondary data, such as internal audit logs or IP addresses, from the export.
Right to Object (Article 21)
The data subject can object to processing based on ‘legitimate interest’ or ‘public task,’ and organizations must then carry out a balancing test. This process requires a clear procedure: legal teams must perform a documented risk assessment outlining why the business interest outweighs or why the processing can continue unchanged. This balance must be transparently communicated and retained as an administrative document.
Operationally, transactional and analytical systems must be able to suspend all processing immediately after receiving an objection, including profiling and automated data-driven marketing. Processing applications must have a ‘pause button’ for specific records, linked to workflows that check whether and when the objection has been handled. Close coordination between compliance, IT security, and business units is essential.
Right Regarding Automated Decision-Making and Profiling (Article 22)
When decisions are made solely based on automated processing and there are legal or similarly significant effects, the data subject must have the right to request human intervention. Organizations must develop transparent explanation models that include the logic, data used, and the expected impact of the algorithm. This can be accompanied by interactive explanation portals where the data subject can view the key parameters and probabilities.
Additionally, there must be a robust escalation process: technical teams should make underlying code and training data available for forensic review, while compliance officers can review the final decision. These procedures must be documented in SLAs and internal policies so that, in the event of complaints or investigations, it is clear who played which role in the assessment and re-assessment of an automated decision.
Right to Withdraw Consent (Article 7)
Data subjects can withdraw consent for processing at any time, after which the processing that is solely based on that consent must be immediately halted. This requires organizations to maintain a centralized consent register in which all given consents, their scope, and the date of withdrawal are recorded. Automated on/off mechanisms must ensure that workflows, notifications, and data streaming services are immediately adjusted to the new consent status.
Underlying systems – from CRM platforms to analytics engines – must have integrations with the consent register so that the withdrawal of consent immediately affects real-time data processing. Additionally, downstream effects, such as ongoing email campaigns or scheduled analyses, must be considered, and a clear procedure should determine which actions may continue and which must be stopped immediately. All these changes must then be confirmed to the data subject, outlining the consequences for their service.
