Helpful first: Assets and the CIA triad: what we protect and how it fails
Key points
- Explain how a system can be 100% secure (encrypted and access-controlled) while still committing a severe privacy violation
- Distinguish Data Controller vs Data Processor obligations under GDPR and sector-specific rules (HIPAA, FERPA)
- Apply privacy engineering principles (purpose limitation, data minimization, retention schedules, and de-identification) at design time
Locked in a vault, yet still a privacy violation
Suppose Meridian Space & Robotics (chronos.) builds a mobile badge app so employees and visiting contractors can tap through turnstiles at the propulsion campus. Staff Infrastructure Engineer Kael Cho encrypts the backend database with AES-256, enforces TLS 1.3, and locks read access behind hardware MFA. From a pure security perspective, the database is a fortress.
Then VP of Legal & Compliance Sloane Sterling discovers that the mobile app silently collects 24/7 background GPS coordinates from every contractor’s phone - even on weekends - and shares that location history with an external workplace-analytics vendor without consent. Not a single hacker breached the server, yet Meridian just committed a severe privacy violation.
| Dimension | Information Security (CIA Triad) | Data Privacy (OECD / GDPR / NIST Privacy Framework) |
|---|---|---|
| Core Question | Can unauthorized actors read, alter, or destroy this data? | Should we collect this personal data at all, and are we using it only for the stated purpose? |
| Primary Threat Scenario | External intrusion, insider credential theft, tampering, or service outage | Over-collection, secondary mission creep, unconsented sharing, or indefinite retention |
| Key Technical & Admin Controls | Encryption (AES/TLS), least-privilege IAM, checksums, immutable backups | Data minimization, purpose limitation, consent/lawful basis, automated TTL deletion, k-anonymity/tokenization |
| Dependency | Can exist without privacy (e.g., securely hoarding unauthorized surveillance data) | Cannot exist without security (you cannot honor privacy promises if anyone can steal the database) |
Where security and privacy overlap - and where they diverge
Security is necessary for privacy, because if an unencrypted database leaks to the public internet, both confidentiality and privacy fail simultaneously. However, security is never sufficient for privacy.
Security controls guard the boundary between authorized and unauthorized principals. Privacy governance regulates the authorized organization itself: what personal data (PII / PHI) you collect, why you collect it (Purpose Limitation), how little you can keep to do the job (Data Minimization), how long you store it (Storage Limitation), and how individuals can inspect, correct, or delete their records (Data Subject Rights).
Controllers, Processors, and regulatory regimes (GDPR, HIPAA, FERPA)
Privacy regulations assign strict legal roles. Under the EU General Data Protection Regulation (GDPR), the Data Controller is the entity that determines the purposes and means of processing personal data (for example, Meridian deciding what employee data to collect), while the Data Processor is a third party that processes data on behalf of the controller (such as a cloud payroll vendor). Controllers bear primary regulatory responsibility and must bind processors via written Data Processing Addenda (DPAs).
In the United States, privacy often follows sectoral and state statutes: HIPAA protects Protected Health Information (PHI) held by healthcare covered entities and their business associates, FERPA protects student education records, GLBA governs consumer financial data, and CCPA/CPRA grants California residents statutory rights to know, delete, and opt out of the sale or sharing of personal information.
Privacy by Design: minimization and automated retention
The cheapest and safest personal record is the one you never collect. During architecture reviews at Meridian, Vera Vance and Sloane Sterling apply Privacy by Design: if an orbital telemetry API only needs an organization ID and a pseudonymous key hash for billing, the schema is forbidden from storing the engineer’s home address, date of birth, or raw IP address. And every table holding personal data must carry an automated Time-To-Live (TTL) purge job tied to the legal retention schedule.
CHECK YOUR JUDGMENT