How to build a GDPR record of processing activities (ROPA) for your organization
A customer, contract or regulator asking for your Article 30 record usually wants one thing: a current written or electronic document that lists how your organization uses personal data. The GDPR requires no certificate for it, and no fixed price or duration applies to building it. The organization owns the record, keeps it up to date and must make it available to the supervisory authority on request. How much work the build takes depends on three things: the number of processing activities you run, whether you act as controller, processor or both for each activity, and whether the exemption in Article 30(5) is available to you. Most organizations find the exemption narrower than they expected, because it falls away whenever processing is likely to create a risk, is not occasional, or includes special category or criminal offence data.
The cost components are the time your staff spend interviewing process owners, the time spent checking each entry against the systems that actually hold the data, and any outside help you buy. Outside help usually covers the inventory workshops, the draft record and the evidence set behind each entry, such as data flow diagrams, system owner confirmations and processor contracts. That work is one-time at the start and recurs whenever a new system, vendor or purpose appears, so ask any partner to separate the initial build from the ongoing maintenance in a written quote. DeployOpen prepares the inventory and evidence for systems it implements or hosts, but the organization keeps the record and makes the decisions it contains. No auditor issues a certificate for the record. Confirm with your supervisory authority and your own legal counsel how they expect it to be presented.
Start by listing every activity that touches personal data, using the EDPB small business guide as a checklist for common examples such as recruitment, payroll, training, badge and access management and prospect lists. For each activity, confirm the fields Article 30 names, including purposes, data subject and data categories, recipients, third-country transfers, erasure time limits where possible and a general description of security measures. Assign a named owner for each entry, typically the business manager, and keep breach records in the same document, clearly labeled so they can be extracted on request. Check the EDPB small business guide on being compliant for the current recommended approach, and confirm with counsel whether the proposed Omnibus IV headcount threshold of 750 employees, still awaiting Parliament's first-reading vote, would change your position.
How to inventory processing activities step by step
This sequence turns a vague sense of where personal data lives into a complete, owned list of processing activities, each described well enough to become a record under Article 30.
Define the scope and the owner
Confirm which legal entity or entities act as controller or processor, and name the manager who is accountable for the record. Agree the systems, teams and business units in scope, including any affiliates and shared services. The output is a short scope note signed off by that manager, so later gaps can be traced back to a decision someone made. Ask whether a DPO will also maintain the record, since guidance allows the DPO to be assigned this task, but accountability stays with the organization.
Start from the EDPB examples
Begin with the activities most organizations run in some form: recruitment, payroll, training, badge and access management, and prospect lists. The EDPB's small business guide uses these as a starting point. Ask each department lead which tools, forms and spreadsheets they use that involve people, and add anything they name. The output is a draft activity register with one line per activity, including the team that runs it.
Find processing in systems and vendor contracts
Check the activity list against what actually runs. Review the application inventory, identity provider, HR and CRM exports, logging platforms, backup targets and vendor contracts. Processing often sits in tools nobody reported, such as analytics plug-ins or support ticket systems. The output is an updated register with each new activity linked to the system or contract that performs it, which is the evidence that the list is complete rather than assumed.
Remove duplicates and occasional activities
Merge activities that share a purpose, data set and system into one entry, so the record stays readable. Mark any one-off activities separately, because the EDPB's guide says small organizations need not record purely occasional activities, while the Article 30(5) exemption depends on whether processing is occasional. Decide and document this judgment for each borderline case. The output is a deduplicated register with a note on every occasional item that was excluded and why.
Complete the fields for each activity
For each activity, record the purposes, categories of data subjects and personal data, categories of recipients, and any transfers outside the EEA. Add the storage period where it is possible to state one, and a general description of the Article 32 security measures that apply. Where a value is unknown, mark it as an open item rather than leaving it blank. The output is a field-complete entry per activity, with open items listed separately for follow-up.
Verify entries with the system owners
Send each entry to the person who runs the system or process and ask them to confirm the data categories, access list and retention in practice. Compare their answers with what the configuration or contract says, and correct the register where they differ. Resolve every open item or record why it remains open. The output is a verified register where each entry names the checker and the date they confirmed it.
Obtain the manager sign-off
Present the complete register to the accountable manager, along with the open items and the scope note. Ask them to approve it, confirm the responsible owner for each entry, and set how the record will be updated when new processing starts. The output is a signed, dated version of the record, stored in a form that can be produced to the supervisory authority on request.
Which fields the Article 30 record must contain
Article 30 splits the record into two lists: one for controllers and one for processors. Most fields are required outright, while a few apply only where possible, and the cards below explain each one in plain terms so you can build the record field by field.
Controller contact details
Record the name and contact details of the controller, and of any joint controller, representative or data protection officer where one applies. This tells the supervisory authority who answers for the record. Check that the entries match your current privacy notice and registration details, and that a named owner receives updates when people or entities change.
Purposes and data categories
For each processing activity, state why you process the data and which categories of data subjects (for example job applicants, customers or site visitors) and categories of personal data are involved. Keep purposes specific enough to match your lawful basis and retention decisions. Broad phrases like 'business operations' tend to fail review because they do not show what data is actually used.
Recipients and third-country transfers
List the categories of recipients who receive the data, including processors and sub-processors, and record any transfer to a country outside the EEA along with the safeguard relied on. Pull these entries from your processor contracts and cloud configuration rather than memory. Transfers often hide in support tooling and analytics, so check those systems explicitly.
Erasure time limits where possible
Record the envisaged time limits for erasure of each category of data where you can set them. Where a fixed period is not realistic, record the criteria used to decide how long the data is kept, and link the entry to your retention schedule. This field is marked where possible, but auditors still look for the blank cells and ask why they are empty.
Article 32 security measures
Give a general description of the technical and organizational security measures applied to the activity, such as access control, encryption, logging and backup. The entry should point to the detailed security documentation rather than repeat it. It is also marked where possible, yet a short, accurate description is usually expected for any system holding sensitive data.
Processor categories and security
A processor records, for each controller it serves, the categories of processing carried out, any transfers to third countries, and where possible a general description of its security measures. A managed service provider or SaaS vendor should keep one entry per customer relationship. Confirm that the processing categories match the instructions in each processing agreement.
Who owns the record and who maintains it
The EDPB's guide for small businesses places the record of processing under the responsibility of the organization's manager, and the record must be available to the data protection authority on request. In practice this means the person with executive authority signs off on the scope, approves the categories of data and recipients the organization declares, and decides what resources the work receives. The manager does not need to type the entries, but the organization cannot delegate away the fact that the controller is accountable for an accurate record.
- Scope approval: Confirm which entities, products and business units the record covers before inventory work starts.
- Resourcing: Assign named time from data owners and the security team, and decide who signs off updates.
- Sign-off cadence: Set a review point, often tied to new systems or vendors, and record who approved each version.
- Escalation: Decide who resolves disagreements about whether an activity is in scope or how a recipient is described.
- Regulator response: Name the person who will produce the record and answer questions when the authority asks.
Check that the manager can name the record owner, the approver and the person who answers regulator requests, and that these names appear in the document itself.
Each business function knows its own processing better than anyone else. Recruitment knows which applicant data is kept and for how long, payroll knows which payroll providers receive data, and the team running prospect lists knows where contacts are stored. The EDPB's small business guidance lists examples such as recruitment, payroll, training, badge and access management and prospect lists, and asks for the categories of data, who has access, transfers outside the EEA and, where possible, the storage period. These owners supply those facts for their own activities.
- Activity identification: Name each process that handles personal data, including informal spreadsheets and shared mailboxes.
- Data categories and subjects: Describe the people concerned and the kinds of data collected.
- Access and recipients: List internal roles and external recipients, including processors.
- Transfers and retention: Flag any destination outside the EEA and the storage period or the reason it cannot be stated.
- Change notice: Tell the record maintainer when a process, vendor or purpose changes.
Check that each owner has confirmed their entries in writing, since the owner is the person who knows whether an entry is still true.
The Article 29 Working Party's guidelines on data protection officers (WP243 rev.01) state that nothing prevents the controller or processor from assigning the DPO the task of maintaining the records of processing operations under its responsibility. Where a DPO is designated, this is a common arrangement, because the DPO already reviews processing for advice. Maintenance can also sit with a privacy lead, a compliance function or an external implementation partner such as DeployOpen, which can prepare and update the document from the facts the business supplies.
- Document upkeep: Keep the entries current, version the record and track each change.
- Consistency checks: Compare entries against system inventories, vendor lists and DPIAs.
- Extractability: Keep breach documentation identifiable within the record so it can be pulled out on request, as EDPB Guidelines 9/2022 describe.
- Advice, not decisions: Flag gaps and risks to the controller, who decides what to do about them.
- Independence: Where a DPO maintains the record, confirm that the role does not create a conflict with the DPO's oversight duties.
Check that the maintainer's appointment is written down and that the controller's approval step remains separate from the maintenance work.
Maintaining the record and being accountable for it are different things. A DPO, a consultant or DeployOpen can draft entries, run inventory workshops, reconcile systems and keep the document in order, but none of them takes over the controller's or processor's obligations under the GDPR. Accountability for accuracy, lawful processing and answers to the supervisory authority stays with the organization. Outside help also does not produce a certificate or audit report for the record, because the GDPR requires neither and only independent bodies issue such outputs.
- Controller accountability: The organization remains liable for an inaccurate or missing record.
- Partner limits: Implementation partners prepare the document and evidence but do not sign it on the organization's behalf.
- Contract terms: Put the scope of maintenance support, the review cycle and handover responsibilities in writing.
- Access to facts: Make sure the maintainer can reach system owners and vendor records, not only policy documents.
- Exit planning: Confirm that the organization keeps a copy it can update if the maintainer changes.
Check the engagement letter or internal role description to see whether it states who approves, who maintains and who answers the regulator.
Does the 250-employee exemption apply to your organization?
The 250-employee exemption in Article 30(5) is narrow, and most organizations that think they qualify for it do not. Organizations with fewer than 250 employees need not keep a record of processing unless the processing is likely to result in a risk to individuals, is not occasional, or includes special category or criminal offence data. Each of those three conditions is an exception that can switch the obligation back on, so the test is not headcount alone. Ask whether any activity is recurring, such as payroll, access management or customer onboarding, and whether any system handles health, biometric, union membership or criminal records data. If either answer is yes, the exemption does not cover that activity, whatever the headcount.
The EDPB's guide for small business says organizations in this group need not record purely occasional activities. Treat that carefully. An activity is not occasional merely because it runs rarely. A one-off survey of staff, for example, may still carry risk if it involves sensitive data. Build the inventory first, mark each activity against the three conditions, and record the reasoning for each decision. That note is your evidence if a supervisory authority asks why an activity sits outside the record.
The Commission's Omnibus IV proposal, COM(2025) 501, would move the threshold to organizations with fewer than 750 employees, unless processing is likely to result in a high risk under Article 35. A text was agreed in interinstitutional negotiations on 26 June 2026 and awaits Parliament's first-reading vote under procedure 2025/0130(COD). The GDPR text has not been amended as of October 2026, so the 250 threshold still governs. Do not plan around the 750 figure until the amendment is adopted and published. Confirm the current status with your counsel or data protection officer before relying on any exemption, and record the date of that check alongside your inventory.
Keeping breach records alongside the ROPA
EDPB Guidelines 9/2022 allow breach documentation to sit inside the Article 30 record, but only if breach information is clearly identifiable and can be extracted on request. The choice is how to structure that: a separate register cross-referenced to the ROPA, or a tagged section within it. Each card covers one decision or check that makes the breach evidence reviewable.
Choose a separate register or a tagged section
A separate breach register linked to the ROPA keeps incident detail away from routine processing entries and is easier to export as a single list. A tagged section inside the ROPA keeps everything in one file but needs a consistent marker, such as a breach identifier column, so entries can be pulled out on request. Pick one approach, document it, and apply it the same way to every incident.
Cross-reference each breach to affected processing
Every breach entry should name the ROPA activities whose personal data was involved. Without that link, a reviewer cannot tell which purposes, data categories and recipients were affected, or whether the activity record was accurate when the incident happened. Check that activity identifiers are stable, so a renamed or split activity does not break old references.
Record the facts the authority will ask for
A breach entry should capture when the breach occurred, when the controller became aware of it, the nature and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and the reasons for any delay in notifying. Record notification decisions too, including why a breach was judged unlikely to risk individuals and so not reported. These fields let an authority review the decision without asking for a rebuild.
Log processor-reported incidents
When a processor discovers a breach, it must tell the controller without undue delay, and the controller's register should show when that notice arrived. Record the processor's name, the date of its notice, and the link to the processing agreement clause that required it. Confirm that managed services and hosting providers report to a named mailbox or ticket queue, not a general inbox that nobody watches.
Keep breach entries current and extractable
Breach entries change as investigations progress, so each update should carry a date and author rather than overwriting earlier facts. Test the extraction before an inspection: pull every entry for a chosen period and confirm the output includes the linked activities, the decisions and the timeline. Store breach records under the same access controls and retention rules as the ROPA, and confirm the retention period with your legal team.
Assign ownership between the DPO and incident team
The ROPA owner and the incident response lead should agree who writes and who approves each breach entry. Where the DPO maintains the records, WP243 rev.01 confirms that this task can be assigned to the DPO. Document the handover from detection to closure, so the breach record shows who decided what and when, and the register does not drift from the incident tracker.
Your team, an implementation partner and the regulator
The organization owns the record of processing. Article 30 places the duty on the controller or processor itself, and the EDPB's guide for small business says the record falls under the responsibility of the organization's manager. Ownership means someone senior is accountable for the register, named business owners approve the entries for their activities, and the register is kept current when systems, vendors or purposes change. The organization also decides what counts as an activity, which data it covers and how it answers questions from the authority.
- Accountable executive: a named manager signs off the register and its review cycle.
- Activity owners: heads of HR, finance, marketing or product confirm the entries that describe their work.
- Change control: new systems, vendors and purposes trigger an update before go-live.
- Data protection contact: if you have a DPO, WP243 rev.01 notes the DPO may be assigned the task of maintaining the records, but the controller remains responsible.
- Retention of the record: keep it available in writing or electronic form for the supervisory authority.
Confirm internally who signs off the register and how often each owner reviews their entries.
An implementation partner such as DeployOpen can prepare the inventory and the technical side of the record, but it does not decide the purposes, lawful bases or retention periods, and it does not approve the register on the organization's behalf. Work is usually scoped in writing before it starts. Typical contributions include running inventory workshops with business owners, mapping systems and data flows, building the register in a self-hosted tool inside your own environment, and preparing extracts for the authority or internal review.
- Inventory workshops: structured sessions that walk each department through its personal data activities.
- Register build: a self-hosted tool deployed in your cloud account, data center or air-gapped network, so the record itself stays under your control.
- Technical mapping: linking entries to the systems, processors and transfers that actually handle the data.
- Extracts and reports: exports showing the record for a given activity, processor or breach log.
- Handover documentation: a runbook explaining how to maintain and update the register.
Ask any partner which decisions remain with your staff and whether the register stays in your environment after the engagement ends.
The supervisory authority reviews the record on request. Under Article 30(4) the controller and processor must make the record available to the authority when asked, and the authority may use it when investigating a complaint or a breach. The record is not published, and the GDPR does not require any audit, attestation or certificate for it. No auditor or certification body issues a report or certificate for the record, and the GDPR does not require any third party review of it. Customers and procurement teams may still ask for it during due diligence, and an independent assessor may check it as part of wider work, but that is a contractual or internal choice rather than a legal requirement.
- On request only: there is no scheduled submission to the authority.
- No certificate for the record: a certificate under Article 42 concerns a broader processing operation, not the register alone.
- Consistency checks: the authority may compare the record with privacy notices, DPIAs and breach files.
- Customer questions: processors often share a summary of the record with customers under contract.
- Independent review is optional: if you choose one, scope it in writing and treat it as a voluntary check.
Confirm with your data protection authority which format and level of detail it expects if it asks for the record.
Common questions about building a GDPR ROPA
Is a ROPA template enough to meet Article 30?
A template gives you the structure, but it does not give you the content. Article 30 asks you to record the purposes, data categories, recipients, transfers, erasure time limits where possible and a general description of security measures for each activity you run. Those facts come from people who run the systems, such as HR, finance, marketing and engineering. A template with blank rows still leaves the work undone. Use a template as a starting point, then have each process owner confirm what their activities actually do with personal data, where the data goes and who can access it. The EDPB's guide for small business describes the record as a list of activities that involve personal data, so the template should be filled from that inventory.
Can a small team build the ROPA without outside help?
Often yes, provided someone has the time and the authority to ask questions across the business. The EDPB's guide for small business says the record falls under the responsibility of the organization's manager. The effort depends on how many systems hold personal data, how many teams use them and how much of the data is already documented. Teams with a clear application inventory and a named owner for each system usually move faster. Teams that discover shadow spreadsheets, unmanaged SaaS accounts or data sent to third parties during the inventory will spend more time. If you bring in a partner, ask for the work to be defined in a written scope that states which activities, systems and interviews are covered.
How many processing activities does a typical organization list?
No reliable number applies across organizations, so treat any figure you see as unverified. The count depends on how you group activities. One record per business process, such as payroll or recruitment, is common, while splitting by system or by purpose produces a longer list. The drivers that raise the count are the number of departments that handle personal data, the number of SaaS tools and vendors, marketing and sales activities, customer support, and any monitoring such as badge or access logs. To estimate your own count, list the business processes first, then check each against the systems that support it. Agree the grouping rule before you start so the record stays consistent.
Does the ROPA have to be published?
No. The EDPB's guide for small business states that the record of processing need not be made public. Article 30(4) instead requires that the record be made available to the supervisory authority on request. Keep it in a controlled location, with version history and access limited to the people who maintain it and those who must answer regulator questions. Publishing the full record could expose security measures and vendor details, so keep any public-facing information in your privacy notice, which is a separate obligation.
Does a processor have to keep a ROPA as well?
Yes, if the processor falls within the scope of the Article 30 obligation. Article 30(2) requires a processor to keep a record of the categories of processing carried out for each controller, any transfers outside the EEA and, where possible, a general description of its security measures. This is separate from the controller's record. A service provider that hosts or supports systems for customers should map each customer relationship, the processing category, the locations where data is stored or accessed, and the sub-processors involved. The same small-business exemption rules apply, so check whether the processing is occasional, carries risk or involves special category data before assuming you are excluded.
What does an implementation partner do for the ROPA, and what stays with us?
An implementation partner can run the inventory workshops, draft the record fields, map systems and data flows to activities, set up a register in a self-hosted tool and document how breach records will sit alongside it. Your organization still owns the controls, makes the decisions about purposes and lawful bases, confirms the facts with process owners and approves the final record. A partner does not issue audit reports or certificates, and no ROPA review by a partner replaces a review by your data protection officer or your supervisory authority. Ask any partner to state in writing who signs off each entry, how changes are approved and what handover covers after delivery.
How DeployOpen prepares the record and its evidence
DeployOpen works on the record of processing activities as part of a wider implementation inside your own infrastructure. We scope the activities, prepare the systems and evidence the record points to, and hand over documentation your organization owns and maintains. An independent assessor or auditor, not DeployOpen, decides whether the record meets what a regulator or contract expects.
How we scope
- We agree in writing which processing activities, systems and business units the record will cover before work starts.
- We identify the systems, cloud accounts and platforms that hold personal data and need entries in the inventory.
- We confirm with you who owns each activity, who approves changes and whether the Article 30(5) exemption applies to your organization.
How we build
- We draft the record fields for each activity, including purposes, data categories, recipients, transfers and retention where known.
- We map the entries to the technical systems that hold the data, so access and storage details come from configuration rather than memory.
- We document the security measures described for each activity and flag gaps where a field cannot be completed from available facts.
How we hand over
- We deliver the record in writing and in electronic form, with an owner, review date and version history for your team to maintain.
- We include breach documentation fields in the same record, clearly labeled so entries can be extracted on request.
- We provide a list of open questions, with the person in your organization who should confirm each answer.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if the record needs regular review as systems change.
- We can help your team prepare evidence for an independent assessment, but we do not issue audit reports, attestations or certifications.
- We recommend confirming responsibilities for the record with your manager or DPO, since they remain accountable for it under your governance.
