Why DPOs and CISOs Keep Talking Past Each Other - And How to Actually Align a RoPA With an Asset Inventory

There is a conversation I have seen happen in organisations more times than I can count.

The privacy team says: “We need to know where personal data is being processed.”

The security team says: “We already have an asset inventory.”

Both teams pause.

Because, technically, both are right.

And yet, when the privacy team asks for the asset inventory, it rarely gives them what they need for a RoPA.

The security team, meanwhile, looks at the RoPA and wonders why there are 147 processing activities when they only have 62 applications in the CMDB.

This is where the two teams start talking past each other.

The problem is not that one team understands data and the other understands technology.

The problem is that

a RoPA and an asset inventory describe the same environment from two completely different perspectives.

And if you try to make one replace the other, both will fail.

A RoPA is not an application inventory

Let's start here.

A security asset inventory typically answers questions like:

• What applications and systems do we have?
• Who owns them?
• Where are they hosted?
• What infrastructure do they depend on?
• What is their criticality?
• What vulnerabilities or security controls apply to them?

A RoPA answers a different set of questions:

• What personal data are we processing?
• Whose data is it?
• Why are we processing it?
• What is the legal basis?
• Who receives it?
• Where does the data go?
• How long do we retain it?
• What processors are involved?
• What rights or risks are associated with the processing?

So when someone says:

“Can't we just map the RoPA to the asset inventory?”

The answer is:

Yes. But don't map them one-to-one.

That's the mistake I see most often.

One application can represent many processing activities

Take a simple example.

Your organisation uses Salesforce.

From a security perspective, that might be one application:

Salesforce → CRM → Business Owner: Sales

But from a privacy perspective, Salesforce could support:

• Lead management
• Customer account management
• Marketing communications
• Customer support
• Partner management
• Sales reporting
• Data subject requests

These are not necessarily six different applications.

They are six different processing activities.

And each activity may involve different:

• categories of data
• categories of individuals
• purposes
• recipients
• retention periods
• legal bases
• processors
• international transfers

So the relationship isn't: 1 application = 1 RoPA activity

It is more like: 1 asset → multiple processing activities → multiple data flows

That's the first mental model that needs to change.

The missing bridge: the processing activity

If you want privacy and security to work together, you need a common object between them.

I recommend using the processing activity as that bridge.

Think of the relationship like this:

Business Process --> Processing Activity -->Applications / Systems / Assets --> Data Stores --> Data Flows / Integrations

This creates a much more useful relationship between the RoPA and the asset inventory.

For example:

Now the security team can understand where the systems fit.

And the privacy team can understand what is actually happening with the data.

That's the bridge.

Start with the questions, not the tools

One reason these exercises become painful is that organisations start with:

“Let's reconcile the RoPA with the CMDB.”

I would start somewhere else. Ask:

1. What processing activities do we actually have?

Don't start with applications. Start with business activities.

For example:

• Hire an employee
• Pay an employee
• Manage customer accounts
• Provide customer support
• Run marketing campaigns
• Detect fraud
• Manage vendors
• Investigate security incidents

These are meaningful privacy activities.

2. What systems support each activity?

Now bring security/IT into the conversation.

For every processing activity, identify:

• Primary application
• Supporting applications
• Databases
• Data warehouses
• File storage
• APIs
• Third-party SaaS
• Infrastructure

3. What data actually moves between them?

This is where the exercise becomes much more valuable.

Don't just write:

“Customer data is stored in CRM.”

Ask:

Where does it come from?

Where does it go next?

Who can access it?

Is it replicated somewhere?

Is it exported?

Is it sent to a vendor?

Is it used for another purpose?

This is where privacy and security finally start looking at the same environment.

A simple mapping model that actually works

You don't need a massive transformation programme to do this.

Create a crosswalk with a few core fields.

Notice something important here.

Not every RoPA field should have an asset-inventory equivalent.

And that's okay.

The objective is not to force both inventories into one giant spreadsheet.

The objective is to establish relationships between them.

Start with the 80/20 approach

If you have 500 applications and 300+ RoPA activities, don't try to reconcile everything at once. Start with the processing that matters most.

Prioritise:

• High-risk: sensitive data, large-scale processing, profiling, AI/ML, financial data, children's data, employee monitoring, fraud detection and cross-border processing.
• Business-critical: customer, HR, identity, payment and support systems.
• Everything else: map later.

I'd rather see 20 high-risk processing activities mapped properly than 500 applications superficially.

Where the CISO benefits

This shouldn't become another privacy exercise that Security is asked to support.

A connected RoPA gives the CISO context around critical assets.

Knowing that Application X is critical is useful.

Knowing that it processes financial data for fraud detection, feeds three other systems, is operated by a third party and has cross-border restrictions is far more useful for risk prioritisation.

Privacy helps answer:

“Why does this asset matter?”

Security helps answer:

“Where exactly is this processing happening?”

That's the relationship you want.

Three identifiers are enough to start

If I were setting this up from scratch, I'd create three IDs:

• Processing Activity ID: PA-00124
• Application/Asset ID: APP-00452
• Data Flow ID: DF-00871

Then connect them:

PA-00124 → APP-00452 → DF-00871 → APP-00612 → Vendor X

Now you have something much more useful than two separate inventories: privacy-to-technology lineage.

Then decide who owns what

This is where many organisations struggle.

The biggest problem usually isn't missing fields.

It's unclear ownership of those fields.

My five-question test

Take any important processing activity and ask:

1. Which application performs this processing?
2. Where is the personal data stored?
3. What other systems receive it?
4. Who owns those systems?
5. If the purpose ends today, how do we actually delete the data?

That last question is my favourite.

It exposes the difference between having a retention policy and actually having retention implemented.

If you can't answer these five questions, don't spend time making the RoPA prettier.

Fix the underlying mapping.

Don't build another spreadsheet

The goal isn't to have two inventories that are both 98% complete.

The goal is connected information:

Business Process → Processing Activity → Application → Data Store → Data Flow → Third Party → Security Controls → Retention → Risk

The tool can be a GRC platform, CMDB, privacy platform, data catalogue or even a well-designed set of linked records.

The tool is secondary. The relationships are what matter.

What this changes for the DPO and CISO

The DPO no longer has to keep asking:

“Where does the data go?”

And the CISO no longer has to ask:

“Why does privacy have 147 records when we only have 62 applications?”

They're no longer trying to make two inventories look the same.

They're looking at the same environment through different lenses.

The RoPA tells you why personal data is processed.

The asset inventory tells you where that processing happens.

The data-flow layer tells you how the data moves.

And governance tells you who is accountable.

That's alignment.

Not one giant inventory.
Not another reconciliation exercise.
A connected model.

And once you have that, DPIAs, security risk assessments, vendor assessments, retention reviews, incident response and data subject rights can all connect back to the same underlying reality.

Devika Subbaiah

 is a Senior Privacy and AI Governance professional with 15 plus years of actual implementation experience. She writes about privacy operations, privacy engineering, and AI governance for practitioners who want to move from theory to execution.