How can you implement GDPR's right to be forgotten in your data architecture?

Your organization should conduct a thorough data inventory, mapping the flow of data across systems and documenting data types. Collaboration with various departments, including IT, marketing, HR, and customer service, is essential to understand data handling practices.

To the best of my knowledge, I believe that a well-defined taxonomy, when correctly mapped to the organisation's data, is crucial for enhancing the explainability, interpretability and discoverability of business information at an enterprise level. Within our hierarchical taxonomy, we can define what constitutes, based on our business context, the unique identifier for customers, both in motion and at rest and determine which attributes, when combined, lead to sensitive information. It would also be beneficial to consistently document the entities, attributes, and overall data workload mappings within one enterprise and governance tool.

To implement GDPR's right to be forgotten, start with robust PII data identification using metadata tagging. Define clear deletion policies specifying retention periods. Deploy tiered deletion strategies: soft-delete for immediate removal from access, followed by periodic hard-delete processes. If using an AWS Ecosystem; leverage AWS Glue for data discovery, AWS Lambda for automation, and Amazon S3 for versioning and lifecycle policies. Leverage Amazon Athena for SQL-based querying of metadata. Strengthen security with AWS Key Management Service for encryption. Regularly audit and update policies to ensure compliance.

Glory be to God for dappled things – For skies of couple-colour as a brinded cow; For rose-moles all in stipple upon trout that swim; Fresh-firecoal chestnut-falls; finches’ wings; Landscape plotted and pieced – fold, fallow, and plough; And áll trádes, their gear and tackle and trim. All things counter, original, spare, strange; Whatever is fickle, freckled (who knows how?) With swift, slow; sweet, sour; adazzle, dim; He fathers-forth whose beauty is past change: Praise him.

The design aspect has to be taken care to Identify the right source of data along with the timestamps. That would avoid storing the data without the endorsement of third-party sites. As we design the data lineage, segregating the personally identifiable information from the huge reporting database eliminates the distribution of such data to large users. A dimension table in the data warehouse world would be extremely useful to manage such data to assign an encrypted key and store the changes corresponding to certain dates.

Architecting data platforms, addressing GDPR's RTBF requirement starts with implementing strong data lineage tracking and having clear deletion policies defined upfront. As we ingest datasets, we need to capture key metadata like data sources, usage, and refresh schedules. This allows us to map the downstream dependencies when a delete request comes in. We then evaluate if other regulatory needs justify retaining some data, and confirm the scope of personal data identified for deletion. Based on the evaluation, we execute deletion scripts to fully remove personal data from warehouses, lakes, and archives as identified. We provide confirmation to the individual on deletion while retaining only metadata needed to track compliance.

Clearly outline deletion criteria, automate processes when feasible, and prioritize secure data handling, including encryption during deletion. Incorporate robust audit trails, fortify user access controls, and deliver thorough employee training.

Defining specific criteria and conditions for accepting or rejecting such requests, outlining the roles and responsibilities of data controllers and processors, establishing a time frame and method for executing the deletion, and establishing a clear communication and confirmation process with the data subject. Additionally, it is essential to document the legal basis and justification for retaining any personal data that cannot be deleted, such as for compliance, contractual, or legitimate interests reasons. By implementing these policies and procedures, organizations can ensure a systematic and compliant approach to managing deletion requests and maintaining transparency with data subjects.

The cornerstone of effective GDPR compliance is a robust policy framework. In my tenure as a CTO, I emphasized creating deletion policies that were transparent and easily understandable, not only for our team but also for the end-users. A layered approach to policy implementation, where responsibilities and processes are clearly defined at each level, ensures a seamless execution of deletion requests. Moreover, maintaining a balance between legal obligations and ethical data handling practices is paramount. This balance can be achieved by regular policy reviews and updates, reflecting the dynamic legal and technological landscape.

It’s all come down to the data policies … once the data is defined as “personal data” then it’s should adhere to polices obtained on the source data level.

A safe strategy is always a great strategy. The main goal is to not lose the golden data and at the same time not to risk a data privacy breach. A 2-step (or multiple-step) strategy of deletion is a safer approach to reviewing any soft deletion based on flagging. An ideal approach would be to store the hard deletes and soft deletes in separate tables and then purge the appropriate tables if needed. Have an ideal retention policy by striking a balance between data storage and storage duration.

When choosing a deletion strategy for implementing GDPR's right to be forgotten, I typically evaluate a few key factors based on the data architecture. For large datasets in Azure data lakes, we leverage soft delete capabilities to efficiently mark data rows for deletion without physically removing them. For relational data, we physically delete records via stored procedures to completely erase info. Anonymization or encryption also works for retaining statistical data without personal identifiers. Overall, the deletion approach depends on data criticality, infrastructure costs, and recovery needs. As a rule of thumb, physical deletion while pseudonymization allows retaining analytical data use cases.

You need understanding legal requirements, categorizing data, and defining retention periods. Consider whether to employ selective deletion or a full purge and automate processes for consistency. Implement audit trails, strengthen user access controls, and align the strategy with business processes. Train employees on the chosen strategy, include it in the incident response plan, and communicate it to data subjects if applicable.

I was privileged to drive design for GDPR of a dara platform. I arrived at RTBF design that would not BE disruptive & run as independently serviceable request. All Data models use PIIs as part of keys or references, like PKs, FKs & constraints. It leads to data issues if simply replaced with nulls. Also, records would have been associated with valid transactions,simply deleting would lead to reconciliation issues, or report resubmission issues. Better design is to apply one way hash algorithm with minimal collision. This would permanently drop PII, but maintain data consistency. You would know, there was an anonymous data subject, did a few million dollars transactions. The transactions as a whole would reconcile to last penny in the org.

After identifying personal data sources and implementing deletion policies and procedures, the final step is to choose a deletion strategy that aligns with your data architecture and business requirements. different strategies available, including physical deletion, logical deletion or encryption. Each has its own advantages and disadvantages, depending on factors such as the type, volume, and complexity of the data of the deletion. When selecting a deletion strategy, consider the impact on data quality, integrity, and availability. assess the potential risks and challenges associated with data recovery. Careful planning, design, and execution are necessary to effectively implement the right under GDPR within your data architecture.

Beyond foundational steps you can implement a robust authentication, data anonymization, and pseudonymization techniques add layers of security. Consider cross-border data transfer implications, adhere to comprehensive data lifecycle management policies, and conduct Data Protection Impact Assessments.

Right to be forgotten, is a key capability for data platforms,? though the feature itself is a kin to erasing history by masking text from history books. You could only drop the PII from a working copy, never ever knowing the multitude of back ups posted on devices, hard disks, let alone tape backups in cold storage. Nevertheless, it enables individuals to exercise control on their own PII available with specific enties in rare conditions, like outcome based on a court ruling. The need for this feature as compliance indicates that regulatory bodies have gone to all possible depths to empower an individual to be on control of own PII and to handle the control of data back ti where it should have been to begin with.

from my experience there are a few other considerations to keep in mind when managing personal data and implementing data deletion practices such as Data Backup and Recovery regularly test your backup and recovery processes to ensure their effectiveness - Data Retention Policies These policies define how long personal data should be retained based on legal, regulatory, or business requirements-Data Subject Rights such as the right to access, rectify, or restrict processing of their personal data-Employee Training and Awareness to Provide regular training and awareness programs- Compliance with Local Regulations to Ensure that your deletion practices comply with the specific requirements.

An often-overlooked aspect of GDPR compliance is the cultural and organizational mindset. During my career, I've witnessed the transformational impact of fostering a data-respectful culture. This involves regular training, open discussions, and the promotion of privacy as a core value within the organization. By integrating GDPR compliance into the organizational ethos, companies can navigate the complexities of data privacy more effectively. Remember, GDPR compliance is not just a regulatory requirement; it's a commitment to respecting and protecting individual privacy.

Personal data is too crucial when comes to individual rights and as a data strategist we have to be compassionate towards others rights, as most of us are giving out our personal info without proper understanding of its long term implications.