AdTech platforms rarely stand still. New partners are onboarded, integrations evolve, data flows change, and processing activities expand as businesses introduce new technologies and services.
But while the technical infrastructure continues to evolve, privacy documentation does not always keep pace.
This creates a familiar challenge: a company may have a perfectly functional advertising ecosystem without having a complete and up-to-date picture of how personal data moves through it, who receives it, and for what purposes it is processed.
This is precisely where a Record of Processing Activities (ROPA) becomes more than just another GDPR requirement.
For AdTech companies, a well-structured ROPA can serve as a practical tool for understanding and managing data processing across the entire advertising ecosystem. It connects legal obligations with technical operations, provides visibility into data flows, and helps teams identify when changes to their infrastructure introduce new privacy considerations.
The real value of a ROPA, however, does not come from simply creating one. It comes from making sure the record reflects how the business actually operates and evolves alongside it.
Start with Processing Activities Your Team Can Recognize
Under Article 30 of the EU GDPR, controllers’ records cover why personal data is processed, the categories of people and data involved, recipient categories, and applicable international transfers. They also include relevant contact details and, where possible, planned deletion timeframes and a general description of security measures.
Processors keep a different record, covering the categories of processing they carry out for each controller, alongside applicable contact, transfer, and security information. Both records must be in writing, including electronic form, and available to the supervisory authority on request.
Those requirements give you the foundation. The structure determines whether anyone can use it.
Add the Information That Makes the Record Usable
The required fields describe the processing, but someone assessing a product change will also need to find the systems involved, the relevant controls, and the person responsible.
For examples of how to structure the record, see the Irish Data Protection Commission’s ROPA guidance.
Maintain practical fields alongside the required record:
Field | What it helps the team answer |
Activity ID and owner → | Which record are we changing, and who confirms the facts? |
Systems, sources, and destinations → | Where does this processing happen? |
Specific data categories and schema references → | Which fields are involved? |
Role and legal basis assessment → | What is our role, and what legal assessment supports the activity? |
Applicable consent or opt-out handling → | Which user choices affect the processing, and where? |
Retention implementation → | Which settings or jobs carry out the documented rule? |
Evidence, review date, and open issues → | What supports the entry, and what still needs checking? |
These are operational additions; Article 30 does not expressly require every field in this table. Where you act as a processor, document the relevant controller instructions and link to the assessment supporting that role.
Make the descriptions specific enough to guide a decision. If an entry says “identifiers,” specify which kinds and link to the relevant field definitions. For retention, include the period or criterion, when it starts, and the setting or job that carries it out.
Mark unresolved points openly. If a destination has not been verified, record what needs investigating and who will follow it up. That gives the next reviewer something concrete to work with.
Make Someone Responsible for Keeping It Useful
Even a well-connected ROPA will fall behind if everyone assumes someone else is maintaining it. Each activity needs an owner who can bring the right people into a review and follow an update through to completion. They don’t need to answer every legal or technical question themselves, but they do need to know whom to ask.
Updates should follow changes to the activity, with periodic reviews to catch anything missed along the way. Choose a cadence that fits how often the setup changes. During a review, check whether the entry still describes the systems in use, whether its references work, and whether outstanding issues have been resolved.
Over time, the ROPA becomes a reliable place to start when someone asks what happens to personal data in your platform. Keeping it useful takes ongoing work, but that work also reduces the effort of reconstructing the same answers for every release, customer request, or investigation.
If your ROPA is difficult to reconcile with your platform’s data flows, BidSafe One can help check whether it reflects your actual processing, identify missing or outdated information, and assess the relevant regulatory requirements. We then define the documentation updates and technical changes needed, giving your privacy, product, and engineering teams a clear scope of work to assign and prioritize.
You can always contact BSO to scope a ROPA review.