Data Lineage Tracking
Purpose
Map and document the complete lifecycle of personal data through organizational systems, from initial collection point through all transformations, transfers, and storage locations to final deletion or anonymization.
Prerequisites
- Data inventory or asset register identifying systems processing personal data
- Network architecture documentation showing system interconnections
- Access to system metadata, ETL configurations, and API documentation
- Records of Processing Activities (RoPA) under GDPR Article 30
Workflow
Step 1: Define Lineage Scope
Determine scope boundaries for the lineage mapping exercise:
- Data categories: Identify which personal data categories to trace (identity data, contact data, financial data, behavioral data, special category data under Art. 9)
- System boundaries: Define which systems are in-scope (production databases, data warehouses, analytics platforms, third-party SaaS, backup systems)
- Temporal scope: Determine whether to map current-state lineage only or include historical data flows
- Legal basis mapping: Link each processing activity in the lineage to its GDPR Article 6 lawful basis
Step 2: Identify Data Sources (Collection Points)
Document every point where personal data enters the organization:
- Direct collection: Web forms, mobile apps, point-of-sale terminals, customer service interactions, paper forms digitized via scanning
- Indirect collection: Third-party data providers, publicly available sources, data brokers, partner organizations
- Derived data: Data generated through processing (risk scores, customer segments, behavioral profiles)
- Inferred data: Data inferred from other data points (creditworthiness, health predictions, preferences)
For each source, record:
- Source identifier and type
- Data categories collected (referencing Art. 30(1)(c) categories)
- Legal basis under Art. 6(1) and, if applicable, Art. 9(2)
- Information provided to data subjects per Art. 13 or Art. 14
- Volume and frequency of collection
Step 3: Map Data Transformations
Document every transformation applied to personal data:
- ETL processes: Extract-Transform-Load pipelines moving data between systems
- Aggregation: Grouping individual records into summary statistics
- Pseudonymization: Replacing identifiers with tokens per Art. 4(5) and Recital 26
- Anonymization: Irreversible de-identification per WP29 Opinion 05/2014
- Enrichment: Combining data from multiple sources to create enriched profiles
- Format conversion: Changing data formats (CSV to JSON, database migration)
For each transformation, record:
- Input data categories and source system
- Transformation logic description
- Output data categories and destination system
- Whether transformation changes the identifiability of data subjects
- Retention period at destination per Art. 5(1)(e) storage limitation
Step 4: Document Data Flows and Transfers
Map all movements of personal data between systems and parties:
- Internal flows: Between departments, systems, databases within the organization
- Processor transfers: To data processors under Art. 28 agreements
- Third-country transfers: Cross-border transfers requiring Art. 44-49 safeguards
- Third-party disclosures: To independent controllers (regulators, partners, law enforcement)
For each flow, record:
- Source and destination system/entity
- Transfer mechanism (API, file transfer, database replication, manual export)
- Legal safeguard for international transfers (SCCs, BCRs, adequacy decision)
- Encryption in transit and at rest
- Frequency and volume
Step 5: Map Data Storage and Retention
Document where personal data resides at each stage:
- Primary storage: Production databases, CRM systems, HRIS
- Secondary storage: Data warehouses, analytics databases, reporting systems
- Archival storage: Long-term archives, cold storage, compliance archives
- Backup storage: Disaster recovery systems, backup tapes, cloud backup
- Temporary storage: Caches, message queues, log files, session storage
For each storage location, record:
- Storage technology and location (on-premises, cloud region)
- Retention period and legal basis for retention
- Access controls and encryption
- Deletion or anonymization mechanism at end of retention period
Step 6: Implement Automated Lineage Discovery
Deploy tooling to automate lineage tracking:
- Database-level lineage: Query log analysis, column-level lineage from SQL parsing
- Application-level lineage: API call tracing, service mesh observability
- Pipeline-level lineage: ETL tool metadata (Apache Airflow lineage backend, dbt documentation)
- Infrastructure-level lineage: Network flow logs, data lake audit trails
Use the scripts/process.py helper to parse system metadata and generate lineage graphs.
Step 7: Integrate with RoPA and Compliance
Link lineage data to GDPR compliance documentation:
- Art. 30 RoPA: Each lineage path should map to a processing activity in the RoPA
- DPIA triggers: Flag lineage paths involving Art. 35(3) processing (large-scale profiling, systematic monitoring, special categories)
- Data subject rights: Use lineage to locate all data for DSAR responses (Art. 15 access, Art. 17 erasure, Art. 20 portability)
- Breach impact scoping: Use lineage to determine affected data subjects and categories during incident response per Art. 33(3)
Step 8: Maintain and Validate
Establish ongoing lineage maintenance:
- Change management: Update lineage when new systems, data flows, or processing activities are introduced
- Periodic validation: Quarterly review to verify lineage accuracy against actual system behavior
- Stakeholder review: Annual sign-off from data owners, system architects, and DPO
- Completeness check: Cross-reference lineage against data inventory and RoPA to identify gaps
Verification
1---2name: data-lineage-tracking3description: Implements data lineage tracking for privacy compliance including origin tracking, transformation logging, access auditing, deletion verification, and cross-system lineage graphs. Covers source-to-sink mapping, GDPR Art. 30 RoPA integration, automated lineage discovery, and breach impact scoping. Keywords: data lineage, data provenance, data flow mapping, transformation logging, deletion verification.4license: Apache-2.05---67# Data Lineage Tracking89## Purpose1011Map and document the complete lifecycle of personal data through organizational systems, from initial collection point through all transformations, transfers, and storage locations to final deletion or anonymization.1213## Prerequisites1415- Data inventory or asset register identifying systems processing personal data16- Network architecture documentation showing system interconnections17- Access to system metadata, ETL configurations, and API documentation18- Records of Processing Activities (RoPA) under GDPR Article 301920## Workflow2122### Step 1: Define Lineage Scope2324Determine scope boundaries for the lineage mapping exercise:25261. **Data categories**: Identify which personal data categories to trace (identity data, contact data, financial data, behavioral data, special category data under Art. 9)272. **System boundaries**: Define which systems are in-scope (production databases, data warehouses, analytics platforms, third-party SaaS, backup systems)283. **Temporal scope**: Determine whether to map current-state lineage only or include historical data flows294. **Legal basis mapping**: Link each processing activity in the lineage to its GDPR Article 6 lawful basis3031### Step 2: Identify Data Sources (Collection Points)3233Document every point where personal data enters the organization:34351. **Direct collection**: Web forms, mobile apps, point-of-sale terminals, customer service interactions, paper forms digitized via scanning362. **Indirect collection**: Third-party data providers, publicly available sources, data brokers, partner organizations373. **Derived data**: Data generated through processing (risk scores, customer segments, behavioral profiles)384. **Inferred data**: Data inferred from other data points (creditworthiness, health predictions, preferences)3940For each source, record:41- Source identifier and type42- Data categories collected (referencing Art. 30(1)(c) categories)43- Legal basis under Art. 6(1) and, if applicable, Art. 9(2)44- Information provided to data subjects per Art. 13 or Art. 1445- Volume and frequency of collection4647### Step 3: Map Data Transformations4849Document every transformation applied to personal data:50511. **ETL processes**: Extract-Transform-Load pipelines moving data between systems522. **Aggregation**: Grouping individual records into summary statistics533. **Pseudonymization**: Replacing identifiers with tokens per Art. 4(5) and Recital 26544. **Anonymization**: Irreversible de-identification per WP29 Opinion 05/2014555. **Enrichment**: Combining data from multiple sources to create enriched profiles566. **Format conversion**: Changing data formats (CSV to JSON, database migration)5758For each transformation, record:59- Input data categories and source system60- Transformation logic description61- Output data categories and destination system62- Whether transformation changes the identifiability of data subjects63- Retention period at destination per Art. 5(1)(e) storage limitation6465### Step 4: Document Data Flows and Transfers6667Map all movements of personal data between systems and parties:68691. **Internal flows**: Between departments, systems, databases within the organization702. **Processor transfers**: To data processors under Art. 28 agreements713. **Third-country transfers**: Cross-border transfers requiring Art. 44-49 safeguards724. **Third-party disclosures**: To independent controllers (regulators, partners, law enforcement)7374For each flow, record:75- Source and destination system/entity76- Transfer mechanism (API, file transfer, database replication, manual export)77- Legal safeguard for international transfers (SCCs, BCRs, adequacy decision)78- Encryption in transit and at rest79- Frequency and volume8081### Step 5: Map Data Storage and Retention8283Document where personal data resides at each stage:84851. **Primary storage**: Production databases, CRM systems, HRIS862. **Secondary storage**: Data warehouses, analytics databases, reporting systems873. **Archival storage**: Long-term archives, cold storage, compliance archives884. **Backup storage**: Disaster recovery systems, backup tapes, cloud backup895. **Temporary storage**: Caches, message queues, log files, session storage9091For each storage location, record:92- Storage technology and location (on-premises, cloud region)93- Retention period and legal basis for retention94- Access controls and encryption95- Deletion or anonymization mechanism at end of retention period9697### Step 6: Implement Automated Lineage Discovery9899Deploy tooling to automate lineage tracking:1001011. **Database-level lineage**: Query log analysis, column-level lineage from SQL parsing1022. **Application-level lineage**: API call tracing, service mesh observability1033. **Pipeline-level lineage**: ETL tool metadata (Apache Airflow lineage backend, dbt documentation)1044. **Infrastructure-level lineage**: Network flow logs, data lake audit trails105106Use the `scripts/process.py` helper to parse system metadata and generate lineage graphs.107108### Step 7: Integrate with RoPA and Compliance109110Link lineage data to GDPR compliance documentation:1111121. **Art. 30 RoPA**: Each lineage path should map to a processing activity in the RoPA1132. **DPIA triggers**: Flag lineage paths involving Art. 35(3) processing (large-scale profiling, systematic monitoring, special categories)1143. **Data subject rights**: Use lineage to locate all data for DSAR responses (Art. 15 access, Art. 17 erasure, Art. 20 portability)1154. **Breach impact scoping**: Use lineage to determine affected data subjects and categories during incident response per Art. 33(3)116117### Step 8: Maintain and Validate118119Establish ongoing lineage maintenance:1201211. **Change management**: Update lineage when new systems, data flows, or processing activities are introduced1222. **Periodic validation**: Quarterly review to verify lineage accuracy against actual system behavior1233. **Stakeholder review**: Annual sign-off from data owners, system architects, and DPO1244. **Completeness check**: Cross-reference lineage against data inventory and RoPA to identify gaps125126## Verification127128- [ ] All personal data categories have documented source-to-sink lineage paths129- [ ] Each lineage node includes legal basis, retention period, and access controls130- [ ] Transformation steps document identifiability impact131- [ ] Cross-border transfers identified with Art. 44-49 safeguards documented132- [ ] Lineage integrates with Art. 30 RoPA entries133- [ ] Automated discovery covers at least database and pipeline layers134- [ ] Quarterly validation schedule established with responsible owners assigned