Player Two Has Entered the Game: Records of Processing Activities Are No Longer Just for the EU

For years, the Records of Processing Activities, or RoPA, has been the domain of European privacy teams. Article 30 of the GDPR made it a requirement for controllers and processors to maintain a detailed record of what they do with personal data, and most companies outside of Europe looked on from a distance, quietly grateful it wasn't their problem. That's all changing.

Minnesota's Consumer Data Privacy Act took effect on July 31, 2025, and while it isn't a carbon copy of the GDPR, it carries a requirement that should feel very familiar. The law includes a unique requirement to create and maintain a data inventory reflecting the personal information that must be managed to comply with the security requirements. It also imposes an unusual requirement that controllers document and maintain a description of the policies and procedures that they adopt to comply with the Act.

In other words: write it down, and know what you're doing with data.

Minnesota isn't alone in this direction, and it almost certainly won't be the last. What we're watching is the gradual migration of European-style accountability requirements into North American law. If you've been putting off building an activity register because "that's a GDPR thing," it's time to revisit that decision.

Activities First, Systems Second

Here's where I see people go wrong when they start this exercise. They pull up a list of their software tools, their databases, maybe their cloud environments, and they try to build a data map from there. The systems become the anchor, and everything else hangs off them. This is how many, many software tools to manage privacy handle this.

I feel it’s the wrong starting point.

The word in "Records of Processing Activities" is doing a lot of work. An activity is something you do. It's a verb: recruiting, onboarding, billing, marketing, providing support, running analytics. These are the things your business actually performs, and personal data flows through them as a consequence.

Start with the activities, and the systems, data categories, and retention periods will follow naturally. Ask: what do we actually do that involves someone's personal information? Not what systems do we use, but what are we trying to accomplish, and whose data touches that process?

Once you have your activities listed, you can layer in the additional detail that makes a register genuinely useful: what categories of data are processed, who the data belongs to (employees, customers, prospects), how long you keep it, what your lawful basis is for having it, and whether it gets shared with third parties.

The EU Got There First, So Use What's There

North American regulators haven't yet published detailed guidance on exactly how these registers should be structured, but the EU's supervisory authorities have had years to refine what good looks like. The Article 30 requirements, and the guidance that has come from regulators across Europe, give you a solid template to work from. It covers purpose of processing, categories of data subjects, categories of personal data, recipients, transfers, retention periods, and security measures.

Is it perfect for a Canadian or American context? Not verbatim. But it's a far better foundation than starting from scratch, and as more North American laws move in this direction, having a well-structured register now means you're extending an existing asset rather than building a new one every time a new state law arrives.

The Practical Value Goes Beyond Compliance

A well-built activity register isn't just a regulatory artefact. It becomes the backbone of your DSAR response capability, your vendor risk assessments, your privacy impact assessments, and your breach response. When something goes wrong, the first question is always "what data was involved and where does it live?" Teams with a register answer that in hours. Teams without one answer it in weeks, if at all.

If you need a hand getting this off the ground, whether that's running a working session with your team to map your activities, building the register structure, or just pressure-testing what you already have, reach out through rossgsaunders.com. It's also a session I'm happy to run directly with your team.