Processing activities register

Purpose

Create a traceable register entry for each distinct processing activity and expose evidence gaps before a privacy review. The register joins business purpose to systems, data categories, people affected, recipients, transfer paths, retention, security measures, and accountable ownership.

Scope

Cover controller or processor role as documented, activity name, purpose, process owner, system, data subjects, personal-data categories, sensitive categories, source, recipients, access roles, countries or transfer paths, retention rule, lawful-basis field where the company model requires it, security controls, contracts, and review status. Excluded: deciding legal basis, certifying compliance, changing system configuration, or inventing a transfer or retention period.

Data basis

• Application and system inventory: system owner, vendor, environment, data domain, integration, region, and lifecycle status.
• Data-flow diagrams, process maps, questionnaires, contracts, privacy notices, retention schedule, security control catalogue, and prior register.
• Record tables for customers, employees, suppliers, tickets, marketing leads, or other affected populations.
• Optional register_scope input for business area, system family, or refresh period.

Result

Produce a persistent processing-activities register with stable activity IDs and one row per activity, plus an evidence and gap sheet. Each row records the required fields, citations, last verified date, confidence, responsible owner, and review status. A summary document lists new, changed, duplicate, and incomplete activities.

Quality criteria

• Each activity has a business purpose distinct from the system name and is linked to at least one process owner.
• Data categories and recipients are supported by a flow, contract, questionnaire, or operational record.
• Duplicate activities are merged only with a cited equivalence rule; otherwise both remain visible.
• Retention, transfer, security, and legal-basis gaps are labelled “not evidenced,” not filled by convention.
• Every changed field cites current and prior evidence, and every register row has a review date.

Instructions

Use the company register schema and privacy glossary as authorities. Model a system that supports several purposes as separate activities when purpose, population, recipient, or retention differs. Preserve supplier names, system identifiers, and source wording. Treat “global,” “standard,” and “as needed” as insufficiently precise for a register field unless the governing policy defines them. Do not convert a control description into proof that the control operates; record the evidence type and date separately.

Adapt before use

• Add the register schema, privacy glossary, retention schedule, transfer framework, and security catalogue.
• Map system, owner, data-domain, recipient, region, contract, and activity identifiers.
• Define stable-ID rules, duplicate criteria, evidence age, review statuses, and escalation roles.