3.3.1. Data Collection, Location, and Maintenance
💡 First Principle: Data that is never collected cannot be breached. Privacy by design — baked into Domain 3's secure design principles and every privacy regulation — starts with data minimization: collect only what you need, for the specific purpose you've defined, for no longer than necessary.
Data collection principles (drawn from GDPR and common privacy law):
| Principle | Definition | Security Implication |
|---|---|---|
| Purpose limitation | Collect data only for a specific, explicit, legitimate purpose | Cannot repurpose collected data without new legal basis |
| Data minimization | Collect only what is necessary for the stated purpose | Collecting less data = less breach exposure |
| Accuracy | Maintain data in an accurate, up-to-date state | Inaccurate data creates legal and operational risks |
| Storage limitation | Don't retain data longer than necessary | Retention schedules must be defined and enforced |
| Integrity and confidentiality | Protect data using appropriate technical/organizational measures | Classification drives the specific measures required |
Data security lifecycle: Create (classify at creation) → Store → Use → Share → Archive → Destroy (Cloud Security Alliance model). Classification is assigned when data is created or acquired because every later phase's controls depend on it; secure destruction is the terminal phase.
De-identification — minimization applied to data you already hold:
| Technique | What It Does | Re-identification Risk |
|---|---|---|
| Tokenization | Replaces values with random tokens; a separate vault keeps the 1:1 mapping | Protects the real values (e.g. shrinks PCI DSS scope) but records stay linkable — still pseudonymous personal data |
| Pseudonymization | Replaces direct identifiers with an alias whose key is held separately | Reversible by whoever holds the key; GDPR still treats it as personal data |
| Masking | Replaces identifying fields with realistic but fictitious values | Removes the real identifiers; unmasked quasi-identifiers can still re-identify |
| Aggregation | Releases group-level statistics instead of individual records | Low — no individual record is released (very small groups can still leak) |
| k-anonymity | Generalizes quasi-identifiers so each record matches at least k−1 others | Prevents singling out a person by attribute combination |
| Anonymization | Irreversibly removes the ability to identify anyone | Truly anonymous data falls outside GDPR (Recital 26) |
Quasi-identifiers — ZIP code, birth date and sex are harmless alone but identifying together (Sweeney found about 87% of the US population unique on 5-digit ZIP, birth date and sex). Removing names and SSNs is not anonymization while quasi-identifiers remain.
Data location and sovereignty — where data physically resides creates legal obligations:
- Data residency: Some regulations require data to stay within specific geographic boundaries (EU GDPR, Russian Federal Law 242-FZ, China PIPL). Cloud deployments must honor residency requirements.
- Data sovereignty: The jurisdiction where data is stored determines which laws apply to it. US cloud providers storing EU data in EU data centers may still be subject to US government access requests (CLOUD Act).
- Multi-tenancy risks: Cloud shared storage means your data coexists with other customers' data. Logical separation must be verified; regulatory requirements may require dedicated storage.
- Law follows the data subject: privacy laws attach to whose data it is, not only where it is stored — GDPR applies to organizations established in the EU or offering goods/services to, or monitoring, people in the EU (Art. 3), and CCPA/CPRA to California residents' data wherever it is processed. Multi-jurisdiction platforms therefore tag each record with the data subject's jurisdiction at ingestion, so consent, retention and data-subject-rights rules can be applied per record.
Data maintenance — keeping data accurate and current:
- Inaccurate personal data creates GDPR exposure (right to rectification)
- Inaccurate financial data creates SOX exposure
- Stale access control data (people who've left but retain access) is an insider threat risk
⚠️ Exam Trap: "Data location" on the CISSP means physical storage location (which jurisdiction, which data center) — not logical location (which database, which folder). The physical location determines sovereignty, residency compliance, and government access authority. Knowing only the logical location is insufficient for compliance.
Reflection Question: A US-based company processes EU customer orders through a CRM system. The CRM vendor stores data in US-based data centers with no EU option. The company's legal team has approved Standard Contractual Clauses. Is this arrangement legally compliant? What residual risk exists, and what would eliminate it?
