Purpose
This starter kit turns "we should have a record of processing activities" into a working document. It gives you the columns, the decision rules, and the workflow to build a defensible data inventory — one row per business processing activity, not per system or per database table.
Pair it with the downloadable CSV template, which includes one clearly labelled example row (EXAMPLE-001) that you should delete before you start populating your own inventory.
How to use this kit
- Make a copy of the CSV (or import it into a spreadsheet or GRC tool).
- Delete the
EXAMPLE-001row once you understand the pattern it demonstrates. - List your ten highest-volume business processes first (support, payroll, sales, marketing, recruitment, product analytics are common starting points) — do not try to boil the ocean in week one.
- Interview the person who actually does the work, not only the system administrator. Workarounds, manual exports and shadow spreadsheets rarely appear in system documentation.
- Record what you can confirm. Where you cannot confirm something (e.g. an unclear retention setting), write "unconfirmed — follow up by [date]" rather than leaving the cell blank or guessing.
- Assign an owner and a review date to every row before moving to the next activity.
Field definitions
| Column | Definition |
|---|---|
| Record ID | Unique identifier for the row, e.g. ROPA-004. Never reuse a retired ID. |
| Processing activity | Plain-language name of the business process, not the system name (e.g. "Employee payroll processing", not "Workday"). |
| Business owner | The named role accountable for this activity — usually a department head, not an individual practitioner. |
| System/application | Primary system(s) where the data lives or is processed, including collaboration tools if used routinely. |
| Data subject categories | Who the data is about (customers, employees, applicants, website visitors, etc.). |
| Personal data categories | The types of data actually collected (name, email, financial details, health data, biometric data, etc.). |
| Special category data (Y/N) | Whether any data falling under a special/sensitive category (health, biometric, ethnicity, trade union membership, sexual orientation, criminal records, etc.) is present. |
| Purpose | Why the data is processed, in language a non-lawyer would understand. |
| Lawful basis / justification | The legal basis relied on (consent, contract necessity, legal obligation, legitimate interests, vital interests, public task), plus a one-line justification. |
| Source | Where the data originally comes from (direct collection, third party, public source, generated internally). |
| Recipients / vendors | Who else receives or accesses the data, including internal teams and external processors. |
| Cross-border transfer (Y/N) | Whether the data leaves the originating jurisdiction, including via a vendor's infrastructure. |
| Transfer mechanism | The legal mechanism relied on for any cross-border transfer (e.g. adequacy decision, standard contractual clauses, binding corporate rules). |
| Retention period | How long the data is kept and what triggers the retention clock (e.g. "3 years from last activity"). |
| Deletion method | How deletion actually happens — automated job, manual process, or vendor-managed. |
| Security controls | The main technical and organisational controls protecting this data (encryption, access restriction, MFA, logging). |
| Last reviewed | Date this row was last verified as accurate. |
| Next review | Date by which this row must be re-verified. |
Worked example (illustrative only)
The CSV includes this row, clearly marked so it is never mistaken for real data:
| Field | Value |
|---|---|
| Record ID | EXAMPLE-001 |
| Processing activity | EXAMPLE ROW — delete before use: Customer support ticketing |
| Business owner | Head of Customer Support |
| System/application | Zendesk |
| Personal data categories | Name, email, phone, order history, support transcript |
| Purpose | Respond to and resolve customer support requests |
| Lawful basis | Contract necessity |
| Retention period | 3 years after ticket closure |
This illustrates the level of specificity expected: a named system, a plain-language purpose, and a retention trigger tied to an event, not a vague duration.
Decision criteria: is this row complete enough to sign off?
A row is ready for sign-off when all of the following are true:
- The lawful basis is named and justified in one sentence — "we've always done it this way" is not a lawful basis.
- Special category data is explicitly marked yes or no, never left blank.
- Retention has both a period and a trigger event.
- Any cross-border transfer has a named mechanism, not just a "yes".
- An owner and next review date are populated.
If any of these are missing, mark the row's status as "in progress" rather than treating the inventory as complete — a partially reviewed inventory should not be represented as finished.
Risk flags to watch for
- Special category data with no documented justification.
- Retention period described as "indefinite" or "until we don't need it".
- Cross-border transfer marked yes with no transfer mechanism recorded.
- A vendor listed as a recipient with no corresponding entry in your vendor privacy assessment.
Ownership and maintenance
- Overall inventory owner: typically the privacy lead or the person accountable for the privacy program. This person maintains the master file and chases stale rows.
- Row owner: the business owner named in each row is responsible for confirming accuracy at each review and flagging changes as they happen — not waiting for the next scheduled review.
- Review cadence: review every row at least annually. Trigger an out-of-cycle review immediately when a new system, new vendor, new data category, or new jurisdiction is introduced for that activity.
- Change log: keep a simple version note (date, what changed, who changed it) at the top of the file or in a separate tab so that reviewers, auditors, or regulators can see the inventory is actively maintained rather than a one-off exercise.
Where this fits in your program
Building and maintaining this inventory is one of the first concrete steps in the Privacy Program 90-Day Roadmap. For the underlying concepts of lawful basis, purpose limitation and data minimisation, see Global Data Privacy Fundamentals. To move from a static spreadsheet to genuinely operational records of processing, see Practical Privacy Program Implementation. If you want a structured view of how mature your current inventory work is against the rest of your program, take the free assessment.
A reminder: lawful basis and retention rules vary by jurisdiction and sector, and this template is educational rather than legal advice — confirm jurisdiction-specific requirements before relying on any single row for a compliance decision.
Download formats
- CSV template (.csv) — the inventory/RoPA columns with one clearly labelled example row. Open it in any spreadsheet tool and delete the example before use.
- Guidance (Markdown .md) — this page, including column definitions and maintenance guidance.
- Print / Save as PDF — a clean print view of the guidance.
Nothing here is emailed — each option downloads or prints directly from your browser.