This section identifies the "who" and "why" behind the data collection to establish accountability.
Process Name (e.g., Payroll Processing, Marketing Newsletter, Customer Support):
Data Controller (Entity determining the purposes and means of processing):
Data Processor (Any third-party service providers involved):
Data Protection Officer (DPO) / Lead - Name of the internal stakeholder responsible for this dataset:
Lawful Basis for Processing:
Consent
Contractual Necessity
Legal Obligation
Vital Interests
Public Task
Legitimate Interests
Understanding whose data you have and where it travels is vital for risk assessment and international compliance.
Data Subject Categories (e.g., Employees, Prospects, Active Customers, Minors):
Geographic Origin of Data (Where the data subjects are located):
International Data Transfers: Is data transferred outside the EEA / UK?
Recipients of Data (List of internal departments or external agencies that have access to this specific inventory):
This table tracks the specifics of the data life cycle.
Data Type | Data Category | Storage Location | Date Collected | Retention Period (Years) | Scheduled Deletion Date | Status / Alert | |
|---|---|---|---|---|---|---|---|
Email Address | PII | AWS - Region West | 5/20/2024 | 3 | 5/20/2027 | Active | |
Medical History | Health (Special) | Encrypted Local Server | 1/10/2023 | 5 | 1/10/2028 | Active | |
GDPR requires you to document how you are protecting the data listed in Section 3.
Encryption Status: Is data encrypted at rest? In transit? (AES-256, TLS 1.3)
Access Controls: List who has "Least Prvilege" access (e.g., Role-Based Access Control)
Anonymisation / Pseudonymisation: Are identifiers replaced with artifical identifiers?
Data Minimisation Review: Describe why this specific data is the "minimum necessary" to achieve the stated purpose.
This section serves as a living log for audits and Data Protection Impact Assessments (DPIAs).
DPIA Requirement: Has a formal impact assessment been conducted for this process?
Risk Level: (Low, Medium, High) based on the sensitivity of the "Data Type" column:
Breach History: Reference IDs for any past security incidents involving this specific data
Review Frequency: How often is this specific inventory entry audited? (e.g., Annually, Quarterly)
Form Template Insights
Please remove this form template insights section before publishing.
This section outlines the architectural logic and functional characteristics of the GDPR Data Inventory form. These insights describe how the form is structured to meet regulatory documentation requirements.
The form is structured to create a direct link between a specific processing activity and its legal owner. By requiring a Process ID and a Lead Stakeholder, the template eliminates ambiguity regarding who is responsible for the data's lifecycle. It functions as a centralized "source of truth" for both internal audits and external inquiries from Data Protection Authorities.
The core of the template is built around temporal logic. By capturing the 'Date Collected' alongside a fixed 'Retention Period', the form transforms from a static list into a dynamic schedule. This structure is designed to visualize the transition of data from "active use" to "mandatory deletion," ensuring that data is not held longer than the stated purpose justifies.
The data inventory utilizes a classification hierarchy. By distinguishing between General PII (Personally Identifiable Information) and Special Categories (such as health or biometric data), the form identifies which rows require higher levels of security and more rigorous lawful bases. This categorization dictates the complexity of the security measures described in later sections.
The template captures the flow of data across borders and between entities. It documents the relationship between the Controller, the Processor, and any Third-Party Recipients. This ensures that the documentation accounts for the entire supply chain of data, including the legal safeguards (like SCCs) that allow data to move between different jurisdictions.
Rather than treating security as a separate document, the form integrates Technical and Organizational Measures (TOMs) directly into the data record. This provides a holistic view of the safety protocols applied to specific data types. It also includes a historical record for Data Protection Impact Assessments (DPIAs) and breach logs, making the form a comprehensive history of the data's integrity and any past vulnerabilities.