Introduction to Data Security & Privacy Management

The CIA triad applied to data

The CIA triad — Confidentiality, Integrity, and Availability — is the foundational model for information security objectives. Applied to data: Confidentiality means data is accessible only to authorized parties; Integrity means data is accurate, complete, and unmodified except through authorized processes; Availability means data is accessible when needed by authorized users and systems. A data security program must address all three — protecting only confidentiality while ignoring integrity creates systems where attackers can manipulate data without detection.

NIST SP 800-60 extends this with a fourth dimension important in government contexts: Non-Repudiation — the ability to prove that a specific action was taken by a specific party, which is essential for audit trails, digital signatures, and transaction accountability. Many modern data security programs add Privacy as a fifth dimension, acknowledging that data can be technically secure (confidential, intact, available) yet still misused in ways that violate individual rights.

The data lifecycle: security requirements at each phase

Data is not uniformly risky at every point in its existence. Security requirements should track the data lifecycle: how data is created or collected, how it flows through processing and use, how it is stored, how it is shared with third parties, how it is archived, and how it is ultimately deleted or destroyed. Different threats are dominant at different lifecycle stages — exfiltration risk peaks during transit and bulk-access scenarios; integrity risk peaks during processing; availability risk peaks during archiving and backup; and privacy risk peaks at collection (consent), sharing (third-party transfers), and deletion (right to erasure compliance).

The data threat landscape

The DBIR (Verizon Data Breach Investigations Report) consistently identifies three dominant data breach patterns: credential theft (phishing, credential stuffing, brute force enabling unauthorized access), misconfiguration (cloud storage buckets, databases, and APIs left publicly accessible without authentication), and insider threat (malicious exfiltration or negligent data handling by employees and contractors). Understanding which threat pattern is most prevalent in your environment determines which data security controls should be prioritized first.

Privacy as a fundamental right

Modern privacy law is grounded in the recognition that personal data has value beyond its commercial use — it shapes autonomy, dignity, and freedom. The OECD Privacy Guidelines (1980, revised 2013) established the foundational privacy principles that all major regulations follow: collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, and accountability. Every major privacy law in force today can be traced back to these eight principles.

GDPR (EU General Data Protection Regulation)

GDPR (effective May 25, 2018) applies to any organization that processes personal data of individuals in the EU/EEA, regardless of where the organization is established. It defines six lawful bases for processing (consent, contract, legal obligation, vital interests, public task, legitimate interests) and seven data subject rights (access, rectification, erasure, restriction, portability, objection, rights related to automated decision-making). GDPR requires Data Processing Agreements (DPAs) with all processors, mandates Data Protection Impact Assessments (DPIAs) for high-risk processing, requires a Data Protection Officer (DPO) in defined circumstances, and requires breach notification to supervisory authorities within 72 hours. Maximum fine: €20M or 4% of global annual turnover, whichever is higher.

CCPA/CPRA (California Consumer Privacy Act / Privacy Rights Act)

CCPA (effective January 2020, amended by CPRA effective January 2023) applies to for-profit businesses meeting any of three thresholds: annual gross revenues exceeding $25M, buying/selling/sharing personal information of 100,000+ consumers annually, or deriving 50%+ of annual revenues from selling personal information. CPRA created the California Privacy Protection Agency (CPPA) and added new rights including the right to correct inaccurate data, the right to limit use of sensitive personal information, and explicit rights around automated decision-making. CPRA also added obligations around data minimization and retention schedules.

HIPAA Privacy Rule

HIPAA Privacy Rule (45 CFR Part 164, Subpart E) applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates. It governs Protected Health Information (PHI) — any individually identifiable health information. Key requirements include: minimum necessary standard (only access/use/disclose the minimum PHI necessary), Notice of Privacy Practices (NPP) to patients, Business Associate Agreements (BAAs) with all business associates, individual rights to access and request amendment of PHI, and restrictions on marketing and sale of PHI. Violation penalties range from $100 to $50,000+ per violation (up to $1.9M per violation category annually).

Why classification is the foundation of data security

You cannot protect data you cannot categorize. Data classification assigns a sensitivity tier to data based on its potential harm if disclosed, modified, or destroyed — and triggers a defined set of security controls for each tier. Without classification, organizations apply the same controls to everything (inefficient) or apply controls inconsistently based on individual judgment (unreliable). A classification policy is the bridge between data and controls.

Most organizations use a three or four-tier model. NIST SP 800-60 defines three federal impact levels: Low, Moderate, and High. The US Government uses Controlled Unclassified Information (CUI), Classified, and Top Secret. Commercial organizations typically define: Public (freely shareable), Internal (for employee use), Confidential (restricted to named roles or business need), and Restricted/Highly Confidential (most sensitive; strict access controls, encryption required, audit logging mandatory).

Data labeling and enforcement

Classification without enforcement is policy theater. Labels must be applied consistently (at creation, by the creator, or by automated tools) and must trigger actual control differences — different access permissions, different encryption requirements, different handling procedures, different retention policies. Microsoft Information Protection (MIP), Google Cloud DLP, and similar tools automate label application and policy enforcement. The GDPR concept of "appropriate technical and organisational measures" (Article 32) is operationalized through classification-driven control application.

Data Loss Prevention (DLP)

DLP solutions inspect data in motion (network), data at rest (storage), and data in use (endpoint) for policy violations. DLP policies typically enforce: preventing transmission of Restricted data to personal email, blocking uploads of PII to unsanctioned cloud storage, alerting on bulk downloads of customer data, and preventing printing of classified documents on uncontrolled printers. NIST SP 800-171 Rev 3 (protecting CUI) requires DLP monitoring as part of media protection and access control controls.

Data catalog and inventory

A data catalog is an inventory of data assets with business context: where data lives, who owns it, what it contains, how sensitive it is, what it is used for, and how long it is retained. GDPR Article 30 requires a "Record of Processing Activities" (ROPA) — which is effectively a privacy-focused data catalog. Organizations that maintain a good general data catalog can generate their ROPA from it, rather than building a separate privacy inventory. Tools like Apache Atlas, Collibra, Alation, and AWS Glue Data Catalog provide automated data discovery and catalog maintenance.

Encryption: protecting data at rest, in transit, and in use

Encryption at rest uses symmetric algorithms (AES-256 is the current standard) to protect stored data from unauthorized access if storage media is stolen, mis-disposed, or physically accessed. Full-disk encryption (FDE) protects an entire storage volume; column-level database encryption protects specific sensitive fields (SSNs, card numbers) while leaving non-sensitive fields in plaintext for query performance. Encryption in transit uses TLS 1.2 or 1.3 to protect data moving between systems across untrusted networks — TLS 1.0 and 1.1 are deprecated. Encryption in use (homomorphic encryption, confidential computing, Intel TDX/SGX) protects data while it is being processed — this is an emerging area with real-world adoption in cloud environments for highly sensitive computation.

Key management is the critical companion to encryption: an encrypted system whose encryption keys are stored alongside the data is not significantly more secure than an unencrypted system. Key management best practices include key hierarchy (master keys protect data encryption keys), key rotation schedules (NIST SP 800-57 guidance), Hardware Security Modules (HSMs) for high-value key storage, and separation of duties (those who encrypt data should not manage keys).

Access control: the identity perimeter for data

The principle of least privilege (PoLP) is the most important access control principle for data security: every user, service account, and process should have the minimum access necessary to perform its function — and nothing more. NIST SP 800-53 AC-2 and ISO 27001 Annex A 5.15–5.18 establish requirements for access management, including provisioning, review, de-provisioning, and privileged access management. Role-Based Access Control (RBAC) assigns permissions to roles, not individuals — simplifying administration and supporting PoLP at scale. Attribute-Based Access Control (ABAC) extends RBAC with dynamic policy evaluation based on user attributes, data sensitivity, location, and time — enabling fine-grained access decisions appropriate for regulated data environments.

Tokenization, pseudonymization, and data masking

Tokenization replaces sensitive values (credit card numbers, SSNs) with randomly generated tokens. The original value is stored in a secure token vault; only the vault can reverse the token. PCI DSS recommends tokenization as an alternative to encryption for reducing scope. Pseudonymization (GDPR Article 4(5)) replaces identifying data with artificial identifiers — reducing risk while retaining data utility for analytics. Unlike anonymization, pseudonymization is reversible with the key. Data masking replaces sensitive data with realistic but non-sensitive substitutes for non-production use — preventing developers and testers from accessing real PII/PHI while maintaining data format integrity for testing validity.

Records of Processing Activities (ROPA) — GDPR Article 30

GDPR requires controllers (and processors with 250+ employees) to maintain a Record of Processing Activities (ROPA) containing: the name of the controller/DPO, the purposes of processing, data subject categories, personal data categories, recipient categories, third-country transfers, retention periods, and security measures. The ROPA is the backbone of privacy program operations — it maps what data the organization processes, why, on what legal basis, for how long, and with whom it is shared. A well-maintained ROPA also supports DPIA scoping, breach notification decisions, and DSAR responses. Most organizations maintain their ROPA as a structured inventory in a privacy management platform or structured spreadsheet reviewed quarterly.

Data Protection Impact Assessments (DPIA)

GDPR Article 35 requires a DPIA before undertaking processing that is "likely to result in a high risk to the rights and freedoms of natural persons." This includes systematic and extensive profiling, large-scale processing of special categories of data (health, biometric, genetic, racial origin, political opinions, etc.), and systematic monitoring of public areas. A DPIA is a risk assessment for privacy: it identifies the processing purpose, necessity and proportionality, risks to data subjects, and the controls that mitigate those risks. The EDPB Guidelines on DPIA (WP248) define nine criteria for mandatory DPIA triggers. Conducting a DPIA is not just a compliance checkbox — it is the mechanism by which Privacy by Design (Module 6) operates at the project level.

Consent management

Consent under GDPR must be freely given, specific, informed, and unambiguous — and must be as easy to withdraw as to give. Pre-ticked boxes, bundled consent, and consent buried in terms of service do not meet GDPR standards (EDPB Guidelines 05/2020). A consent management platform (CMP) manages cookie consent banners, records consent with timestamp and version, handles consent withdrawal, and provides evidence of consent for regulatory inquiries. Under CCPA/CPRA, the comparable mechanism is the opt-out of sale/sharing link ("Do Not Sell or Share My Personal Information"), managed through a Universal Opt-Out Mechanism (UOOM) recognized by the CPPA.

Data Subject Access Requests (DSARs)

GDPR Article 15 grants individuals the right to obtain a copy of their personal data and information about how it is processed — free of charge, within one calendar month (extendable to three for complex requests). CCPA provides similar rights. DSAR response requires identifying all personal data held across all systems (requiring a good ROPA and data catalog), exporting data in a portable format, reviewing for third-party data that must be withheld, and responding within the statutory timeline. Failure to respond within the GDPR deadline is independently penalizable, separate from any underlying data processing violation.

Breach notification

GDPR Article 33 requires notification to the competent supervisory authority within 72 hours of becoming aware of a personal data breach that risks the rights of data subjects. GDPR Article 34 requires notification to affected data subjects "without undue delay" when the breach is likely to result in a high risk. Breach notification procedures should document the clock-start event (when did "becoming aware" occur?), the notification decision tree (risk assessment to determine whether notification is required), the template notifications, and the post-incident review process. NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide) and ISO/IEC 27035 provide incident response procedures that integrate with breach notification workflows.

Privacy by Design: seven foundational principles

Privacy by Design (PbD) was developed by Dr. Ann Cavoukian and is codified in GDPR Article 25 as a legal requirement under the name "data protection by design and by default." The seven principles are: Proactive not Reactive (prevent privacy violations before they occur, not after), Privacy as the Default (the most privacy-protective settings must be the default — no action required from users), Privacy Embedded Into Design (privacy is a core system component, not an add-on), Full Functionality (Privacy does not mean trading off functionality — both-and, not either-or), End-to-End Security (privacy is protected across the full lifecycle), Visibility and Transparency (components and operations remain visible and verifiable), and Respect for User Privacy (user-centric design, giving control to individuals).

Practical PbD implementation means: data minimization fields in forms (collect only what is necessary), automatic data expiry in databases, strong defaults for privacy settings (opt-in for data sharing, not opt-out), DPIA completion before launch, pseudonymization of analytics data, and privacy review as a gate in the SDLC before deployment.

Third-party data processing risk and Data Processing Agreements

GDPR Article 28 requires that any organization using a third-party data processor (a vendor, SaaS tool, cloud provider, or contractor that processes personal data on your behalf) must have a Data Processing Agreement (DPA) in place. The DPA must specify the subject-matter and duration of processing, the nature and purpose, the type of personal data and categories of data subjects, and the obligations and rights of the controller. The DPA must also address sub-processors (the processor must get controller approval before engaging sub-processors), audit rights, return or deletion of data at end of contract, and security measures.

Third-party privacy risk management goes beyond DPAs. It includes vendor security questionnaires (using standardized formats like SIG or CAIQ), reviewing vendor privacy policies and sub-processor lists, verifying transfer mechanisms for international transfers, and periodic vendor re-assessment. The GDPR Schrems II ruling (2020) invalidated the EU-US Privacy Shield and elevated transfer impact assessment requirements for international data flows — organizations must assess whether the recipient country provides adequate protection and supplement SCCs (Standard Contractual Clauses) with technical measures where necessary.