Article 30 GDPR records of processing: evidence

What Article 30 of the GDPR requires for records of processing

If a customer, auditor or regulator has asked for your record of processing, the answer is that Article 30 requires it to be in writing, kept current and made available to the supervisory authority on request. The record is not a one-off project. It must describe what your organization actually does with personal data today, and it must be produced quickly when asked. Controllers and processors each keep their own version. A controller's record under Article 30(1) covers its contact details, the purposes of processing, the categories of data subjects and personal data, the categories of recipients, any third-country transfers, and, where possible, the planned erasure time limits and a general description of the Article 32 security measures. A processor's record under Article 30(2) is organized differently: it lists the categories of processing carried out for each controller, any third-country transfers, and, where possible, a general description of its security measures. Many organizations are both, so they need to keep two records that point to the same systems.

The record is the starting point for much of the other GDPR evidence. The purposes and categories you list determine the lawful basis analysis, the retention schedule, the data subject request workflow, the breach notification contacts and the decision on whether a DPIA is needed. If the record is wrong, those documents inherit the error. The hard parts are usually organizational rather than technical. Ownership is often unclear: the record touches IT, HR, marketing, finance and product, and no single function sees every processing activity. Keeping it current is harder still, because new SaaS tools, new data flows and changed retention rules appear without a formal trigger. Mapping systems to purposes is the most demanding step, since one application may serve several purposes and one purpose may span several systems. Confirm with your own data protection lead whether the Article 30(5) exemption applies to you before deciding how much effort to invest, and check the current status of the proposed amendment with the EUR-Lex text of the GDPR and your national supervisory authority.

Which processing and systems Article 30 records cover

Before drafting any entries, the organization has to settle who is responsible, where personal data sits and who does the work. Each decision below changes what appears in the record, so answer them in writing and keep the answers with the record itself.

Controller or processor per activity

The same activity can be recorded as controller processing in one context and processor processing in another, depending on who decides the purposes and means. Under Article 30(1) a controller records purposes, data subject categories and recipients, while under Article 30(2) a processor records only the categories of processing it carries out for each controller. Check each activity against the contract and the instructions actually followed, and confirm which legal entity in a group holds the role.

Systems and SaaS tools holding personal data

Personal data often sits in HR platforms, CRM tools, ticketing systems and collaboration suites that were never added to a central list. Use asset inventory and endpoint data as a starting point, then confirm with system owners which applications hold personal data and which fields they contain. Each system that holds personal data should map to at least one activity entry, with its recipients and storage location noted.

Backups, logs and archives

Backups, log stores and archives keep copies of personal data after the production system has changed or deleted it. Their retention periods often drive the erasure time limits the record must state where possible. Confirm which backup sets and log indexes contain personal data, how long each keeps it, and whether any copy is stored by a provider outside the organization's direct control.

Third countries receiving data

Any recipient outside the EU or EEA, including a support team, a sub-processor or a group company, must be identified in the record for transfers under Article 30(1)(e) and 30(2)(c). Remote access from another country counts as a transfer for recording purposes, even when the data stays hosted in the EU. Ask each vendor and internal team where personal data is viewed or processed, not only where it is stored.

Owning teams for each activity

Each entry needs an owner who can confirm its purposes, data categories and retention when the record is reviewed. Without named owners, entries go stale after reorganizations, new tools or changed vendors. Assign an accountable team per activity, record who maintains the entry, and set a review trigger for changes to systems, recipients or processing purposes.

Small-organization exemption thresholds

Article 30(5) exempts organizations under 250 employees unless processing is likely to risk individuals' rights, is not occasional, or includes special category or criminal offence data. Most organizations with routine HR, payroll or customer data will fall outside the exemption, even when they are small. Document the headcount, the processing types checked against these conditions and the reasoning, and confirm the position with counsel or the supervisory authority.

Does the under-250-employee exemption cover your organization?

Organizations with fewer than 250 employees are exempt from the Article 30 record-keeping duty, but only if none of three conditions applies. The exemption falls away where the processing is likely to result in a risk to individuals, where it is not occasional, or where it includes special category or criminal offence data. Headcount alone does not settle the question. A 40-person company that runs continuous customer profiling, or that holds employee health records, is covered. The EDPB's small business guidance says organizations need not record purely occasional activities, which is the narrow case where a small employer can leave an activity out. Most organizations that process special category data or run frequent processing cannot rely on the exemption.

Before relying on the exemption, list every processing activity and test each against the three conditions. Ask the business owners of HR, payroll, customer support, marketing and any monitoring tooling whether the activity recurs, whether it touches health, biometric, union or similar data, and whether it could create a meaningful risk if it went wrong. Also check the processor side: if your organization acts as a processor for customers, the exemption analysis must be run separately, because the duties for processors are framed by the processing carried out for each controller. Document the outcome of this analysis in writing, since you may need to explain it to a supervisory authority.

The Commission's Omnibus IV proposal, COM(2025) 501, would raise the threshold to fewer than 750 employees and tie the exception to processing 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. That text is not law until it is adopted and published, so keep the record for current processing regardless. Before planning around the change, confirm the procedure status on the European Parliament Legislative Observatory under procedure 2025/0130(COD), and confirm with your data protection adviser how any final wording would apply to your headcount and risk profile.

How an assessor tests the Article 30 record

This table compares what a supervisory authority or independent auditor typically does when testing the Article 30 record, the evidence they ask for, and the findings that come up most often. Read each row as a test step, then check your own record against the same questions before a request arrives. The main takeaway is that the record is judged by whether it matches real data flows, not by whether a document exists.

Test area	What the assessor does	Evidence requested	Common finding
Field presence (controller)	Checks each Article 30(1) field is recorded: contact details, purposes, data subject and data categories, recipients, transfers, erasure periods and security description	The written record, or its electronic export, showing every required field per processing activity	Erasure periods or security descriptions missing, or recorded as blank without a stated reason
Field presence (processor)	Checks the Article 30(2) fields: categories of processing for each controller, third-country transfers and the general security description	The processor record organized by controller, with transfer and security entries	Processor record kept only as a list of services, with no link to the controllers served
Sampling against systems	Selects a sample of recorded activities and traces each to the system that performs it, such as an HR platform or CRM	System names, owners, hostnames or application identifiers that match the record entry	Entries describe a purpose but name no system, or a system was retired while its entry remained
Sampling against contracts	Compares recipients and processors named in the record with vendor and processor agreements on file	Signed processing agreements, sub-processor lists and the contract dates behind each named recipient	Recipients in the record with no contract on file, or contracted vendors missing from the record
Data flow reconciliation	Walks through actual data movements and asks whether transfers, recipients and locations in the record match what happens in practice	Network or integration diagrams, data flow maps and sample transfer logs	Record lists an EU-only hosting location while support access or backups occur outside the EEA
Retention and erasure check	Compares recorded erasure time limits with system retention settings, backup rotation and deletion jobs	Retention schedule, configuration exports and evidence of recent deletion runs	Erasure periods stated as generic policy, with no matching configuration in the systems
Records on demand	Requests the record during an inquiry and checks it can be produced in a usable form within the time the authority sets	The current record in writing or electronic form, with version history showing when it was last reviewed	Record exists only as scattered spreadsheets, or cannot be produced in one consistent file
Breach documentation	Checks whether breach information is kept with the record and can be pulled out clearly when asked, as EDPB Guidelines 9/2022 describe	A breach register or section that is clearly identifiable, with facts, effects and remedial action for each incident	Breach facts are scattered across tickets and email, with no single identifiable register

How to build and maintain the Article 30 record

This sequence takes an organization from unclear roles to a written, owned and reviewable record of processing that a supervisory authority can request and read without reconstruction. Each step produces an artifact that feeds the next, so the final register is traceable to real systems and real decisions.

Confirm your role for each processing activity
Decide, activity by activity, whether the organization acts as controller, processor, or both, because Article 30(1) and Article 30(2) impose different content on each. Involve legal or privacy counsel and the business owners who decide why data is used. Where another party jointly decides purposes and means, note that relationship for later review against the joint controller arrangement. The output is a role table listing each activity, the role held, and the basis for that conclusion. The step is done when every activity has a documented role and a named person who agreed to it.
Inventory systems, data stores and data flows
Build a list of the applications, databases, file shares, SaaS services, backups, logs and endpoints that hold or move personal data. Use existing asset sources such as a CMDB, cloud account listings or endpoint inventory where they exist, and verify them against interviews with system owners because asset lists often miss shadow tools. Include hosting locations and any support access from outside the EEA. The output is a system inventory tied to each data flow. The step is complete when system owners have confirmed their entries in writing.
Map each activity to its required fields
For every activity, record the contact details of the controller or its representative, the purposes, the categories of data subjects and personal data, the categories of recipients, and any third-country transfers. Then add erasure time limits and a general description of Article 32 security measures wherever they can be stated. Where a field cannot be completed, record the reason so the gap is visible rather than silent. The output is a field-level register with one row per activity. The step is complete when a reviewer can read any row without asking the owner what it means.
Assign an accountable owner to each entry
Name one business owner and one technical owner for every activity, with a stated responsibility for keeping that row accurate. The privacy or compliance lead should hold the register itself and the approval workflow for changes. Document who may edit entries and who signs off. The output is an ownership column in the register and a short role statement for each owner. The step is complete when no row lacks an owner and the owners have accepted their responsibility in writing.
Link the record to related evidence
Connect each activity to the evidence that supports it: the DPIA where one exists, the processor contract for each processor or sub-processor, the transfer mechanism for each third-country flow, and the breach documentation that the EDPB says may sit within the record if it is clearly identifiable and extractable. Links should resolve to a stable location, not to a personal drive. The output is a cross-reference column or linked index. The step is complete when each external-facing activity can be traced to its contract and assessment without manual searching.
Set review triggers and a review cadence
Define the events that require an update: a new system or processor, a changed purpose, a new country of access, a new data category, a breach, or an org change that alters ownership. Add a periodic review that the organization sets for itself. Record the last review date and the reviewer on the register. The output is a documented trigger list and a change log. The step is complete when a change to any system has a defined route to the register owner.
Store the record in a format you can produce on request
Article 30(3) requires the record in writing, and electronic form is acceptable, and Article 30(4) requires it to be made available to the supervisory authority on request. Choose a format that can be exported in a readable form, keep version history so you can show what the record said on a given date, and restrict edit rights. Test an export before you need it. The output is a controlled repository with a tested export and a retrieval procedure. The step is complete when someone who did not build the register can produce the full record within a short internal drill.
Confirm the exemption position before relying on it
Organizations with fewer than 250 employees are exempt under Article 30(5) unless processing is likely to result in a risk, is not occasional, or includes special category or criminal offence data. Document the headcount basis, then test each activity against those three conditions. The EDPB guidance for small organizations says purely occasional activities need not be recorded. The proposed Omnibus IV text would raise the threshold to fewer than 750 employees, but it has not been adopted, so confirm its status with counsel before any change. The output is a written exemption assessment. The step is complete when the decision and its reasoning are signed off and filed with the record.

Which open-source tools can feed the Article 30 record

Article 30 records draw on facts about your systems, your data flows and your documentation. The four tools below can supply parts of that evidence, but none of them writes the record for you. Each one covers a different slice, and the activity register itself stays under the ownership of a named person in your organization.

GLPI for asset inventory

GLPI's Assets module tracks computers, software, network equipment, peripherals, printers, phones and racks, entered by hand or pushed by the GLPI Agent through its native inventory. For Article 30, this helps you identify the systems and locations where personal data is processed, which feeds the security and location fields of the record. It does not describe what processing happens on those assets, which purposes apply or who the recipients are. Confirm that your asset data is current enough to rely on. License: GPL-3.0-or-later.

Wazuh Syscollector for endpoint inventory

Wazuh Syscollector collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint and stores them in the Wazuh indexer. This gives you current, observed evidence of which applications and accounts touch systems that hold personal data, and it supports the general description of security measures. It does not determine whether a processing activity is lawful, what data it uses or how long it is kept. Confirm agent coverage across your estate before relying on the output. License: GPL-2.0-only.

CISO Assistant for the GDPR framework

CISO Assistant ships a GDPR framework and can run assessments against it, with automatic mapping between frameworks. You can use it to track which Article 30 requirements have an owner, an assessment status and linked evidence, and to keep the record's review date visible. It does not write the register entries for you and should not be treated as a source of legal conclusions. Check whether the framework version it ships matches the text you plan to assess against, and confirm how its mappings were produced before relying on them. License: AGPL-3.0-only.

XWiki for version-controlled records

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back. This is useful for the record itself, because a controller can show how a processing entry changed over time and who approved each change. EDPB Guidelines 9/2022 note that breach documentation can sit within the Article 30 record if it stays identifiable and extractable, which a wiki page can support. XWiki does not discover processing activities or enforce completeness. License: LGPL-2.1-or-later.

What evidence passes an Article 30 review and how to keep it current

An assessor reviewing an Article 30 record wants to see that the register is complete, owned, dated and traceable to the processing it describes. The core artifact is the signed activity register itself: one entry per processing activity with the Article 30(1) fields filled in, approved by a named owner, and supported by a version history showing what changed, when, and by whom. A register that exists only as a spreadsheet with no change record is hard to defend, because the regulator can ask how it looked at a past date. Where the organization acts as a processor, the equivalent artifact is the processor-version register under Article 30(2), kept for each controller client, listing the categories of processing performed for that client, third-country transfers, and the general security description where it is possible to give one. Confirm with your counsel which controller relationships your record must cover before you build it.

Transfer entries are where assessors look for substance. Each third-country transfer should name the destination, the transfer mechanism relied on (for example, an adequacy decision such as the EU-US Data Privacy Framework under Commission Implementing Decision (EU) 2023/1795, or standard contractual clauses), and any supplementary measures documented elsewhere. The export procedure matters as much as the content: the record must be producible in writing, including electronic form, for the supervisory authority on request under Article 30(3) and (4). Test the export end to end once a year by generating the full record as a regulator would receive it and checking that every entry resolves to a current owner and source document. Breach documentation can sit inside the same record, as EDPB Guidelines 9/2022 note, provided the breach entries are clearly identifiable and can be extracted on request. Use a distinct category label and a consistent reference format so extraction does not depend on manual searching.

Keeping evidence current between audits depends on review triggers rather than a calendar alone. Define events that force an entry update: a new system or vendor onboarded, a new purpose or data category, a change of hosting location, a new sub-processor, a retention change, or a breach. Pair these with periodic owner attestations, where each activity owner confirms in writing that the entry still matches reality, and keep the attestation dated and stored with the register. In a self-hosted stack, GLPI's Assets module and the Wazuh Syscollector inventory can help you spot systems that have appeared without a register entry, while XWiki's version control records the change history of narrative documents. These tools support the evidence trail but do not decide whether an entry is accurate. Ask any assessor you engage which artifacts they expect for your organization, because no set of artifacts is guaranteed to pass an individual review.

What an Article 30 record costs to build and maintain

This table breaks down the cost components of building and keeping an Article 30 record, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No price or duration is supplied for these components, so use the rows to structure a written quote and to ask each provider what it covers.

Cost component	One-time or recurring	Who is paid or who spends time	What drives it up or down
Staff time to inventory processing activities	One-time, then recurring	Privacy, IT and business owners who describe each activity, its purposes, data categories and recipients	Up: number of business units, systems and processors. Down: a maintained asset inventory and named activity owners
Tooling and licences	Recurring if commercial, one-time setup	Vendor licence for commercial tools; open-source tools have no licence fee but need hosting and administration	Up: user counts and add-on modules. Down: reuse of existing inventory or ticketing tools, confirmed with each vendor
Hosting and administration of open-source tools	Recurring	Internal platform or IT staff, or an implementation partner under a retainer	Up: high availability, backups and access control requirements. Down: a single shared platform with clear ownership
Implementation support	One-time	Implementation partner or consultant, if bought in, under a written scope	Up: custom integrations, number of record sources to connect, and workshops. Down: a defined template and fixed scope agreed before work starts
Processor and transfer mapping	One-time, then recurring on change	Procurement, legal and privacy staff, sometimes with supplier questionnaires	Up: many processors, sub-processors and third-country transfers. Down: a current contract register and standard supplier questionnaire
Special category and criminal offence data review	One-time, then recurring on change	Privacy team or DPO, with system owners for health, HR or criminal data flows	Up: number of systems holding such data. Down: segregating these flows so each is documented once
Recurring upkeep and change control	Recurring	System owners, privacy team and IT, reviewing entries on new systems, changes and retirements	Up: frequent change, many owners, weak change triggers. Down: linking record updates to procurement and change tickets
Breach documentation maintenance	Recurring	Security and privacy staff keeping breach entries clearly identifiable inside the record	Up: frequent incidents and multi-country notifications. Down: a standard breach entry template that can be extracted on request
External review by a DPO or consultant	Recurring or periodic	Outsourced DPO or consultant, billed under the agreed scope	Up: scope breadth, number of entities and review depth. Down: a defined review cycle and an internal owner who prepares the record first

Who owns the record, who prepares it and who assesses it

Your organization owns the Article 30 record. As a controller, you must hold a record covering your processing activities, and as a processor, a separate record covering the processing you carry out for each controller. Responsibility does not move to a vendor, consultant or tool because they helped build or host the register. Someone inside the organization must decide which processing activities exist, approve the purposes and retention periods, and keep the record current when systems, suppliers or business processes change.

Accountable owner: Name a person who answers to the supervisory authority for the record, usually in the privacy or compliance function with input from IT and business owners.
Business input: Application and process owners confirm purposes, data categories, recipients and transfers, because only they know what the processing actually does.
Change control: Tie new systems, vendors and processing changes to an update of the record before go-live.
Availability: Be able to produce the record to the supervisory authority on request, in writing or electronic form.
Exemption check: If you believe the under-250-employee exemption applies, document the reasoning and re-check it against the risk, regularity and special category conditions.

Check that your owner, your review cadence and your change triggers are written down before you engage anyone else.

Questions buyers ask about the Article 30 record

How much effort does the first Article 30 record take, and what drives it?

The first record usually takes the most effort because nobody has yet listed where personal data goes. Effort is driven by the number of systems and business processes that handle personal data, how many teams own them, whether processing records already exist in other documents, and how many third-country transfers and recipients must be documented. Supplier and hosting arrangements add work because each recipient and transfer needs a named entry. Ask any partner for a quote built from a written list of systems, processes and recipients, and check whether it covers both the initial build and later maintenance. The GDPR does not set a time or cost for this work, so treat any figure you see as something to verify against your own inventory.

Does a small company have to keep an Article 30 record?

Not always. Article 30(5) exempts organizations with fewer than 250 employees, but the exemption does not apply where the processing is likely to result in a risk, is not occasional, or includes special category or criminal offence data. Most organizations that process customer or employee data on a regular basis will therefore need a record even when small. The EDPB's small business guide says purely occasional activities need not be recorded. A proposed amendment in the Omnibus IV procedure would raise the employee threshold to 750 with a high-risk condition, but its text is awaiting Parliament's first-reading vote, so confirm its status with your counsel before relying on it.

Can the Article 30 record be kept in a spreadsheet or a wiki?

Yes. Article 30(3) requires the record to be in writing, including electronic form, so a spreadsheet, database or wiki can satisfy the format if it holds every required field and can be produced to the supervisory authority on request. A spreadsheet works for small inventories, but it needs an owner, access control and version history so you can show what changed and when. Wikis with page version control, such as XWiki, record who changed what and allow comparison and rollback. A compliance platform such as CISO Assistant includes a GDPR framework, though you should confirm how its record features fit your process. Whatever tool you choose, the record must be complete and current, not just stored electronically.

How long does it take to bring an existing record up to date?

The time depends on how far the existing record has drifted from reality. Start by comparing it with what systems actually process, using asset and software inventories where they exist. Gaps usually appear around shadow IT, recent integrations, changed hosting locations and processors added without a review. The work is mostly verification and correction, so a short, well-scoped review goes faster than a rebuild. Ask for a written scope that lists which processing activities, systems and recipients will be checked, and agree how changes will be reviewed and approved before updates are made. No duration is set by the GDPR, so the schedule should come from the scope agreed with your team.

What does the Article 30 work need from the business and IT teams?

The record describes business activity, so it needs input from both sides. Business owners must explain why each activity exists, which people and categories of individuals are involved, who receives the data and how long it is kept. IT teams must confirm where the data is stored, which systems and services process it, what security measures are in place and which transfers leave the EEA. Procurement or legal should supply processor contracts and sub-processor lists. Assign one accountable owner for the record and set a review trigger, such as new systems, new vendors or changed purposes, so the record stays accurate after the first build.

Can a partner build the record, and what stays in-house?

An implementation partner can prepare the record, gather technical evidence and document system-level details, but it cannot own the record or decide the purposes and lawful bases of processing. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, so it can help map systems and produce evidence from them under a written, fixed scope. Your organization stays responsible for the content, approval and ongoing maintenance of the record, and for the decisions it reflects. Ask any provider to confirm in writing which parts of the record they draft, which you must verify, and who signs off.

What will a supervisory authority ask to see?

Under Article 30(4), the record must be made available to the supervisory authority on request, so you should be able to produce a complete, current version promptly. An authority will typically check that each required element is present, that the entries match actual processing, that transfers and recipients are identified, and that the security description is consistent with your Article 32 measures. Keep a dated version history and be ready to explain how entries were verified. Where breach information is documented within the record, EDPB Guidelines 9/2022 expect it to be clearly identifiable and extractable on request. Regulators do not issue certificates for the record, so no independent attestation is needed to satisfy this requirement.

How DeployOpen prepares Article 30 records

DeployOpen helps organizations prepare the systems and written records behind Article 30 records of processing activities, inside the client's own infrastructure. The organization remains the controller or processor that owns the record, and DeployOpen does not certify or attest to its content.

How we scope

Agree in writing which processing activities, entities and roles the Article 30 record will cover.
Confirm which records are controller records, which are processor records, and which systems hold the source data.
Confirm with your counsel or DPO whether the under-250-employee exemption applies, and record that decision in the scope.

How we build

Configure self-hosted inventory tools to capture the assets and software that process personal data.
Map each processing activity to purposes, data categories, recipients, transfers and retention limits in a structured register.
Set up version-controlled documentation so changes to the record are traceable by date and author.

How we hand over

Deliver the register, its field definitions, the update procedure and the named owner for each entry.
Document where the record is stored and how it can be produced to a supervisory authority on request.
Provide a walkthrough so your team can maintain the record without ongoing DeployOpen involvement.

How we support

Fixed-scope engagements set deliverables and timelines in writing before work begins.
Ongoing support, upgrades and reviews of the record are available as a retainer.
Ask for the written scope and quote before engaging, and confirm each deliverable against your own records.

Article 30 Records of processing activities