Every organization claims to own its data. Few can demonstrate that ownership in a way that satisfies a regulator. The gap between claiming data ownership and proving it is an architecture problem, not a legal one.
The schema is the policy. Data ownership means knowing where every piece of personal data resides, who accessed it, when it was modified, and whether the subject has exercised their rights. This information is either encoded in your database schema or it does not exist. A schema that stores customer data across seventeen tables with no unified identity column cannot fulfill a right-of-access request without a data mapping exercise that takes weeks. A schema designed with a canonical identity at its core can produce the same response in seconds.
Consent is a data structure. GDPR consent is not a boolean flag on a user record. It is a versioned, timestamped, purpose-specific, revocable authorization that must be tracked alongside every data processing operation. If your consent model is a single "agreed to terms" checkbox, you have a compliance problem. If it is a structured consent table with purpose codes, collection timestamps, and revocation events linked to processing logs, you have a compliance architecture.
The procurement angle. EU government tenders increasingly require bidders to demonstrate data protection by design. This is not satisfied by attaching a privacy policy to a proposal. It requires showing that the system architecture enforces data minimization, purpose limitation, and storage limitation at the schema level.
On the U.S. side, SAM.gov contract vehicles for data-heavy services now reference NIST SP 800-53 controls that map directly to data architecture decisions: access control boundaries, audit trail requirements, and data retention policies. The architecture that satisfies these controls is the same architecture that satisfies GDPR.
We have helped clients redesign data models not because their existing schemas were wrong, but because they made compliance impossible. The redesign always produces a simpler, more maintainable system as a side effect—because data ownership, when properly architected, eliminates more complexity than it introduces.