Architecting a solution for global data privacy
All the Modern data privacy regulations, whether GDPR in Europe, CCPA in California, DPDPA in India, PDPA in Singapore and Thailand, PIPEDA in Canada, or HIPAA in the United States share a common shift in expectation: they move the bar from having policies (demonstrating intent) to proving how those policies are implemented in practice.
This moves organizations away from ad-hoc, spreadsheet and email-based approaches toward systematic, auditable execution. That is fundamentally a system design problem. Policies alone are not sufficient, they just “demonstrate intent.” Privacy must now be hardwired into your applications, data flows, and operational processes. It must be architected into the very code, data streams, and processes that drive the business, and you must have the ability to “demonstrate execution.”
Companies now need to build compliance directly into how their systems work, rather than asking users to sign forms after the fact. Do it right the first time.
When we start treating data privacy not as a policy problem but as a system design problem, we must begin by answering a few basic questions.
For every piece of personal data that we collect we need to look at:
Purpose limitation: Why are we collecting it? Personal data should be collected and used only for a clear, specific, and lawful purpose that has been communicated to the individual, and nothing beyond that. This is a core requirement under GDPR Article 5, CCPA, DPDPA, and virtually every other major privacy framework.
Data mapping and access control: Where is the data stored and who all have access to it. We need to identify and document what personal data are we collecting, where it comes from, why it is used, where it is stored, how it flows across systems, and who has access to it.
Retention: How long do we keep it? We should keep the data only for as long as it is necessary to fulfil the stated purpose for which it was collected or to meet legal obligations. Once the purpose is achieved and no lawful reason to retain the data exists, the data must be deleted.
Individual rights: How do we maintain, delete, or correct personal data on request? Individuals must have control over their personal data, including the right to access information about how their data is processed, request correction or erasure, withdraw consent, and seek grievance redressal. This right is recognized under all major privacy frameworks – referred to as “data subject rights” under GDPR, “consumer rights” under CCPA, and “data principal rights” under DPDPA.
If the solution that we are building does not answer these questions, then we can safely assume that we are Not Compliant, even if policies exist.
Having understood this part, lets look at the components/functionalities that you should put in place to build a privacy-compliant solution
Data Discovery & Classification
This inventory and classification layer comprises of Data Catalogues or data stores. These data stores could be logical entities and not necessarily a specific table in a database or a tool or a report.
Metadata tags are to be built on these data stores to easily identify their characteristics and categorize them. Make sure the tags propagate downstream (Database, cache, logs, backups).
Classification of datasets in line with applicable privacy regulations must be completed. This is covered in detail in an earlier blog. The principle is consistent across frameworks: if data is not classified, it should not be stored.
A provision to define clear ownership for each dataset should be in place to ensure accountability. Every dataset containing personal data must have a designated owner responsible for its accuracy, lawful use, access control, retention, and response to data principal requests or incidents. Clear ownership helps prevent gaps in compliance, enables faster decision-making, and ensures effective governance across the data lifecycle.
Purpose Limitation by Design
Privacy regulations across the board require that data is used only for the purpose for which consent was obtained. A Single data set (or user master) used by marketing, ops, analytics, ML or Shared without purpose boundaries is not acceptable under GDPR, DPDPA, CCPA, or PDPA
So, when designing the systems, you need to ensure you are not using the data anything other than what it was asked for. This needs to be enforced at code level and the APIs that you build, Service level authorizations that you put in place need to follow this.
Separate models are to be built around the same data set for operations, analytics and reporting, which ensures that the scope of access is not the same for all.
Net-net, you need to ensure the purpose is enforced by code, not policy PDFs.
Consent Management as a System Component
The consent management goes way beyond just a checkbox. It should be seen a service. A service that is managed centrally across different parts/modules of the solution and should be auditable.
The Consent should be Explicit and Purpose-specific. You should build versioning capabilities and put an audit trail in place using which you should be able to establish the version of consent, a particular user has signed on.
The consent should be revocable and automatically be applicable to all the places for which the consent was asked for.
To achieve this, you need to provide for a Consent UI, a data store for Consent and more importantly – to access any data across system, an access gateway should be in place. This gateway should check if the consent is present or not, is the consent valid (not revoked) and only then the access to the data should be given.
Any of the services that does not go through this gateway will be a candidate for a potential non-compliance.
Individual Rights (Access, Correction, Deletion)
You need to ensure that individuals have control over their personal data.
Provisions must be in place for them to:
- Access information about their personal data and how it is being processed
- Request correction of inaccurate or outdated data
- Seek deletion of data once the stated purpose is fulfilled or consent is withdrawn
These rights exist in some form under every major privacy regulation. GDPR‘s Articles 15–17 cover access, rectification, and erasure. CCPA gives consumers the right to know, delete, and correct. DPDPA provides data principals with similar rights to access, correct, and erase.
Audit Logs are to be maintained for each request; action taken and needs to be acknowledged.
If requested data updates or deletion requires manual DB queries, then it is safe to say you are not compliant, and this is where most systems fail.
Retention & Automated Deletion
Privacy regulations require keeping the personal data only as long as necessary. All the retentions rules should be configurable as per data classification and the consent sought.
You need to implement time-based background jobs to delete the data when the specified period is over. Provision for event based (e.g., deleting account) deletions should be built.
The defined backup lifecycle policies are to be implement and audited from time to time.
Access Control & Zero Trust
The architecture should ensure that access to personal data is reasonably safeguarded by following Zero Trust principles, where no user or system is trusted by default.
Access to personal data must be enforced through role-based or attribute-based controls, ensuring users can access only what is necessary for their defined purpose.
Personal data should be encrypted both at rest and in transit.
Credentials must be unique and not shared, and all access to personal data must be fully logged and auditable. Audit logs should clearly record who accessed what data, when it was accessed, and for what purpose, enabling accountability and compliance verification.
Breach Readiness (Beyond Prevention)
Privacy regulations do not just require breach prevention; they require breach readiness.
GDPR mandates notification to supervisory authorities within 72 hours of becoming aware of a breach. CCPA creates private rights of action for consumers affected by certain breaches. DPDPA requires notification to both the Data Protection Board and affected individuals. HIPAA has its own breach notification rule for covered entities.
Incident Response Playbook for every Security Event and Impact Assessment methodology should be present, and a notification workflow should be put in place.
Vendor & Processor Architecture
Even when personal data is processed or stored by third parties like cloud providers, SaaS platforms, analytics tools, your organization remains fully responsible. This is explicit under GDPR‘s controller-processor model, DPDPA‘s treatment of data fiduciaries and processors, and CCPA‘s service provider framework.
Appropriate safeguards must therefore be built into the architecture, including sharing only the minimum data required, enforcing purpose-bound contractual obligations, ensuring region-aware data storage where applicable, and applying techniques such as tokenization or masking before data is transferred.
These measures help maintain control, reduce risk, and ensure accountability across the vendor ecosystem.
To Summarise if the answer to following questions is Yes, then you are architecturally ready for compliance across major data privacy frameworks.
- Can we delete one user completely in <24 hours?
- Can we prove why we collected each field?
- Can we show consent history?
- Can we show who accessed personal data?
- Can we isolate data by purpose?
Organizations must embed privacy into application design by enforcing purpose limitation, data mapping, retention, consent, access control, and data principal rights directly in code and workflows.
Ultimately, compliance is proven not by policies, but by the ability to demonstrate control, accountability, and traceability across the entire data lifecycle.
