Data Privacy, Security & Compliance

Data privacy, security, and compliance architecture classifies sensitive data and applies the controls needed to protect it and meet legal obligations.

At a glance

• What it is: Classifying data by sensitivity (PII, PCI, confidential), applying access controls, encryption, and masking, and mapping regulatory obligations (GDPR, CCPA, PCI-DSS) to concrete handling requirements.
• Why it matters: A privacy breach or compliance failure is a legal and trust problem, not just a technical one — and it’s far more expensive to fix after the fact than to design in from the start.
• For developers: if a new field could identify a real person, classify it and decide on encryption/retention before it ships — retrofitting classification onto data already in production is much harder.
• When to use it: For any system that stores or processes personal, financial, or otherwise sensitive data.
• When not to use it: Fully anonymous, non-identifying data has lighter requirements, but should still be reviewed to confirm it’s genuinely non-identifying.
• Prerequisites: Data Governance & Stewardship.

Mental model

graph LR
    Data["New data field"] --> Classify["Classify sensitivity\n(PII / PCI / confidential / public)"]
    Classify --> Controls["Select controls\n(encrypt, mask, restrict access)"]
    Controls --> Obligations["Map to regulatory\nobligations (GDPR, PCI-DSS)"]

Classification comes first — you can’t choose the right control or know which regulation applies until you know what kind of data you’re actually holding.

Step-by-step walkthrough

1. Classify each data field by sensitivity level (public, internal, confidential, PII, PCI).
2. Apply access controls (role-based access) scoped to who genuinely needs each classification level.
3. Apply encryption at rest and in transit for sensitive classifications.
4. Apply masking or tokenization where full values aren’t needed (e.g. non-production environments, support tooling).
5. Map each classification to the regulatory obligations it triggers (GDPR, CCPA, PCI-DSS, industry-specific rules).
6. Build support for data subject rights requests — access, correction, and erasure.

Worked example

A Northwind customer submits a GDPR right-to-erasure request, but their payment transaction history is scattered across four systems — the payment gateway, the order database, the fraud-detection log, and the finance archive — one of which has a legal retention hold on tax-related records.

• Input: one erasure request, four systems, one legal retention obligation that conflicts with immediate deletion.
• Process: classify each system’s holdings, apply per-system handling — delete data with no retention obligation, anonymize (rather than delete) data under the tax retention hold so it can no longer identify the customer while still satisfying the legal requirement, and log the request and actions taken for audit.
• Output: the customer’s identifiable data is removed everywhere it legally can be, the tax record is retained in anonymized form, and there’s an auditable record proving the request was honored appropriately.

public async Task AnonymizeAsync(Guid customerId)
{
    var record = await _taxArchive.GetAsync(customerId);
    record.CustomerName = "REDACTED";
    record.Email = null;
    record.CustomerIdHash = Hash(customerId); // keeps the record analyzable, no longer identifying
    await _taxArchive.SaveAsync(record); // retained for the legal hold, no longer PII
}

On Azure, sensitive columns (email, card data) use Always Encrypted in Azure SQL Database, encryption keys are managed in Azure Key Vault, and non-production copies apply Dynamic Data Masking so support engineers never see real customer values. The SQL server itself has no public endpoint — it’s reachable only via a private endpoint inside the application’s virtual network, so “is this database reachable from the internet at all” is answered by network topology, not just firewall rules.

resource sqlPrivateEndpoint 'Microsoft.Network/privateEndpoints@2023-11-01' = {
  name: 'pe-northwind-sql'
  location: resourceGroup().location
  properties: {
    subnet: { id: appSubnetId }
    privateLinkServiceConnections: [{
      name: 'sql-connection'
      properties: { privateLinkServiceId: sqlServerId, groupIds: ['sqlServer'] }
    }]
  }
}

Common use cases

Use case	When to use	Notes
PII field classification	New system stores personal data	Classify at design time, not after launch
Encryption at rest	Any confidential or regulated data store	Pair with key management, not just “turn on encryption”
Masking non-production data	Test/staging environments using copies of production data	Never expose real customer data in lower environments
Subject access/erasure requests	GDPR/CCPA-covered data	Requires a per-system handling plan, not just a database delete

Advanced details

• Tokenization vs. encryption: tokenization replaces sensitive values with a non-reversible reference usable for processing (e.g. payment tokens); encryption preserves the original value, recoverable with the right key.
• Data residency: some regulations require data to remain within specific geographic or jurisdictional boundaries — this constrains storage and pipeline architecture choices.
• Anonymization vs. pseudonymization: anonymization removes identifying value irreversibly; pseudonymization replaces identifiers with a reversible reference — only pseudonymized data can typically still be “re-identified,” which matters for compliance classification.
• Audit logging: compliance obligations typically require proof of who accessed or changed sensitive data and when, not just that access controls exist.
• Network isolation as a control: classification-driven access control is necessary but not sufficient — pairing it with network isolation (private endpoints, no public database/storage endpoints) removes an entire class of exposure risk that access policy alone can’t fully close.

Quick reference

Term	Meaning
PII	Personally Identifiable Information
PCI	Payment Card Industry data (e.g. card numbers)
Classification	Labeling data by sensitivity level to drive control decisions
Encryption	Protecting data so only holders of a key can read it
Masking	Obscuring or substituting sensitive values for lower-risk use
Right to erasure	A regulated individual’s right to request deletion of their personal data
Private endpoint	A private IP inside a virtual network for a PaaS resource (e.g. SQL, Storage), removing its public endpoint

Troubleshooting

Symptom	Likely cause	Fix
Sensitive field found unclassified in a report	No classification step at design time	Add classification as a required step before a new field ships
Erasure request blocked by a legal hold	Conflict between deletion obligation and retention obligation not resolved	Anonymize rather than delete where a legal hold applies, and document the decision
Real customer data found in a test environment	No masking policy for non-production data copies	Mandate masking/tokenization before data is copied to lower environments

Check your understanding

• Why might anonymizing a record satisfy both a GDPR erasure request and a tax retention requirement at the same time?
• For a system you know, is there a documented classification for every field that stores personal data — or would you have to guess which fields are sensitive?

Related pages

Part of Introduction to Data Architecture. See also Data Governance & Stewardship for who decides classification policy, Data Lifecycle Management for retention and deletion scheduling, and the Glossary for term definitions.