DAT-006 Data Inventory and Records of Processing
Description
A current inventory of personal and sensitive data assets is maintained, documenting data categories, processing purposes, data flows, retention periods, legal basis for processing, and the systems and third parties involved. This record is reviewed and updated at least annually.
Rationale
A data inventory is the foundational accountability artefact for privacy compliance. It enables proportionate protection, supports DPIA scoping, facilitates data subject rights fulfilment, and is required by GDPR Art.30.
Applicability (9 profiles)
Art. 25(2)(e) and (f) need the inventory to reach beyond personal and sensitive data. The exhaustive specification of portable categories is drawn from it and so is the separation of provider-internal categories that may be exempted on trade secret grounds, which Art. 25(2)(f) allows only where the exemption does not impede or delay the switch.
Framework Mappings (16)
| DSP-03 | Data Inventory | full |
| DSP-05 | Data Flow Documentation | partial |
| DSP-06 | Data Ownership and Stewardship | partial |
| DSP-20 | Data Provenance and Transparency | informative |
| DSP-03 | Data Inventory | full |
| DSP-05 | Data Flow Documentation | partial |
| DSP-06 | Data Ownership and Stewardship | partial |
| EU-DA-Art.25.2.e | Exhaustive Specification of Portable Data and Digital Assets | informative |
| GDPR-Art.30.1 | Controller Records of Processing Activities (RoPA) | partial |
| GDPR-Art.30.2 | Processor Records of Processing Activities | partial |
| GDPR-Art.5.2 | Accountability Principle | partial |
| HIPAA-164.308.a.1.ii.A | Risk Analysis | informative |
| NIS2-CIR-12.4 | Asset Inventory | informative |
| CM-13 | Data Action Mapping | full |
| PM-18 | Privacy Program Plan | informative |
| C1.1 | Confidential Information Identification and Maintenance | informative |
Evidence (2)
Records of Processing Activities (RoPA) or data inventory documenting all personal data processing activities with required GDPR Art.30 fields.
Example: RoPA register (OneTrust / Confluence / spreadsheet), listing each processing activity with: controller identity, processing purpose, data categories, data subject categories, recipients, third countries, retention periods, legal basis, and technical/organisational measures, reviewed within 12 months
Test: Request the current RoPA or data inventory. Verify: (1) all active processing activities are represented, (2) each entry includes: purpose, data categories, legal basis, retention period, and any third-party recipients, (3) cross-border transfers are identified and transfer mechanisms documented, (4) register has been reviewed and updated within the last 12 months, (5) DPO or data owner approval is recorded.
Data flow diagram or automated data mapping output showing how personal data moves between systems and to third parties.
Example: Automated data flow map export from OneTrust Data Mapping, Securiti.ai, or equivalent, showing data flows from collection points to processing systems to third-party processors, with data categories annotated
Test: Request the data flow diagram or mapping tool export. Verify: (1) all major data collection touchpoints are shown (web app, mobile, API, support systems), (2) flows to all identified third-party processors are represented, (3) any cross-border flows are marked, (4) diagram is dated within 12 months.
Questions (2)
Does your organisation maintain a current Records of Processing Activities (RoPA) or equivalent data inventory documenting all personal data processing with the fields required by GDPR Article 30?
The RoPA must include: processing purposes, data categories, data subject categories, legal basis, retention periods, third-party recipients, cross-border transfers, and applicable safeguards. It should be reviewed and updated at least annually.
How is the data inventory or RoPA maintained?
Options run from the strongest record to the weakest. A privacy management platform discovers flows and raises the entries nobody has touched; OneTrust, Securiti and TrustArc are examples of the category. A register in a documentation or collaboration system such as Confluence, Notion or SharePoint holds up where the number of processing activities is small and one person owns the review. A spreadsheet is acceptable at that size and fails the same way a register does, by going stale between annual reviews with nobody watching.