Finding RoPA and Data Inventory Gaps: A Practical MCP Use Case

In our article on the context gap in privacy operations, we explored why privacy teams spend so much time reconstructing information that already exists across the organisation. Our privacy maturity model then examined how programmes can progress from fragmented, manual work towards connected, context-aware operations.

The next step is to make that progression practical.

Consider a question that sits at the centre of RoPA maintenance:

What is missing from our understanding of how the organisation uses personal data?

Checking for empty fields can answer part of that question. It will not necessarily reveal a system that appears in the data inventory but has never been connected to a processing activity. Nor will it explain why an assessment describes a data flow that the RoPA does not mention.

Those questions require comparison across records, an understanding of their relationships and a way to distinguish a genuine omission from information that is simply documented differently.

RoPA and data-inventory gap analysis provides a useful starting point for exploring how AI assistance, supported by MCP, could make that work easier. The objective is straightforward: help privacy professionals identify where to investigate, bring forward the relevant context and ask the business more focused questions.

The gaps that a completed record can hide

A RoPA and a data inventory describe related parts of the organisation.

Processing records explain how personal data is used. An inventory identifies the systems and repositories involved. Connecting activities to data categories, repositories and responsible teams makes it possible to examine how those descriptions fit together. TrustWorks’ RoPA guidance explicitly includes these relationships and their validation with business owners.

Consider a customer-support operation.

Its processing record describes the handling of customer enquiries. The inventory lists the main support platform. A separate assessment mentions a translation service that receives customer messages.

Each record might look reasonable when reviewed independently. Together, they raise a question: is the translation service reflected in the documented support process, including the data it receives and what happens to the translated content?

Several explanations are possible. The service may be covered by an existing activity but lack the relevant link. Its record may use a different name. The assessment may describe a proposed implementation that never went live. Alternatively, the organisation may have introduced processing that has not yet been documented.

The same apparent gap can therefore require very different responses.

The purpose of discovery is to identify the question that needs resolving, together with the evidence needed to resolve it.

Creating another record immediately could introduce duplication. Ignoring the finding could leave a real omission unresolved.

What MCP changes in the review

MCP is an open standard for connecting AI applications to external data sources and tools. A configured connection can make selected information and capabilities available to an assistant, allowing it to work with context beyond the material entered into a conversation.

Applied to RoPA review, this creates the possibility of asking questions across the records made available through that connection.

Instead of preparing separate exports and manually assembling the background for each question, a privacy professional could ask an authorised assistant to retrieve relevant records, compare their contents and prepare a set of findings for review.

The contribution of each part should remain clear. The underlying platform holds the records and relationships. The MCP connection exposes the supported information and tools. The assistant uses that access to help investigate the question.

The quality of the result still depends on the available context. An assistant cannot identify an application that is absent from every source it can access. It also needs to distinguish information it could not retrieve from information that is genuinely missing.

Permissions and controls require equal attention. MCP does not automatically make an integration secure or auditable. Access restrictions, consent, permitted actions and appropriate safeguards must be implemented in the connected applications.

For a first use case, a scoped, read-only review offers a practical boundary: identify potential gaps and prepare evidence without changing the underlying records.

Five discovery questions for RoPA and data-inventory reviews

The following questions illustrate how an MCP-enabled review could work. The exact answers depend on the records, documents, relationships and tools exposed by the configured integration.

Begin by defining the scope, such as a business function, legal entity or group of systems. Ask the assistant to state which sources it reviewed and which relevant sources were unavailable.

1. Which assets have no linked processing activity?

Review the assets in scope and identify those with no linked processing activity. Show their recorded purpose, owner and available evidence of personal-data use. Separate confirmed information from assumptions.

This question tests whether the systems the organisation knows about are connected to its description of processing.

The useful output should explain the missing relationship. For example, an asset may have a recorded business owner and an assessment describing customer-data use, but no connection to the relevant processing activity.

That gives the reviewer a specific starting point.

The next step is to establish whether the asset supports an existing activity, represents a different use or falls outside the scope of the review. Avoid treating every unmatched application as a reason to create a separate RoPA entry.

2. Which documented systems are missing from the inventory?

Review the processing records and assessments in scope. Identify systems, repositories or services mentioned in them that cannot be matched to an inventory record. Flag possible naming differences or duplicates before treating them as missing.

The comparison should also run in the opposite direction.

Suppose an assessment describes a file-transfer service used to share information with an external partner, but the service cannot be found in the inventory. Reviewing inventory entries alone would not expose that omission.

The finding should preserve the reference to the original document and explain why no reliable match was found.

A business owner may confirm that the service has been retired, that it appears under another name or that it was never added to the inventory. Each outcome improves the record, but each requires a different action.

3. Which records lack the information needed for review?

Check the processing activities in scope against our organisation’s review requirements. Identify missing or unclear information and show whether related records contain information that could help resolve it. Do not fill gaps with unsupported assumptions.

Some gaps are visible within a record: an unclear purpose, an unassigned owner or incomplete information about data categories, recipients or retention.

A useful review goes further than listing empty fields.

It should distinguish between information that is missing, information explicitly marked as not applicable and information that appears elsewhere but has not been validated for this activity.

For example, a vendor document may describe a standard retention period. That can support a follow-up question, but it should not automatically become the retention period for the organisation’s particular use.

The practical benefit is a more focused request to the business: confirm this specific point using the context already available.

4. Where do related records disagree or appear out of date?

Compare the processing records with their related assets, assessments and available supporting documents. Identify conflicting descriptions or recorded changes that may require review. Show the sources, dates and the specific point that needs confirmation.

Completeness and consistency are different tests.

In the customer-support example, the RoPA might describe a limited set of customer information, while a related assessment also refers to message attachments. An older review might describe one recipient, while a more recent document introduces another.

Those differences deserve investigation, but the newest document should not automatically be treated as the correct account of operational reality.

The documents could concern different services, configurations or periods. A newly advertised capability might not be enabled.

The finding should therefore explain the discrepancy and ask what would establish its significance. Where dates, versions or implementation status are unavailable, that uncertainty should remain visible.

5. Which gaps deserve attention first, and what should happen next?

Group the findings by the decision needed. Using our review criteria and the available evidence, suggest a priority, identify the recorded owner and draft the questions required to resolve each finding. Explain uncertainty and leave ownership unassigned where it cannot be established.

A useful review should help the team decide where to spend its attention.

Compare two hypothetical findings. One concerns inconsistent naming for an otherwise well-documented internal tool. Another concerns a service that may receive sensitive information, has no confirmed owner and cannot be connected to a reviewed processing activity.

Treating both as equivalent would hide the difference that matters.

Ask for the basis of each proposed priority and distinguish a documentation correction from a matter requiring further risk assessment. The privacy professional should review that recommendation before work is assigned or escalated.

From a flagged gap to a completed review

Return to the customer-support example.

Assume the records available to the assistant show a translation service in the asset inventory, an assessment mentioning customer-message processing and a support activity that does not link to the service.

A useful finding could bring those three references together and explain the unresolved question:

The translation service appears in the inventory and its assessment describes processing customer messages. No relationship to the customer-support activity was found in the records reviewed. Confirm whether the service is in use, which information it receives and whether the existing activity covers that use.

This is a finding for investigation, rather than a final conclusion.

The privacy professional reviews the evidence and sends focused questions to the recorded support owner. The owner confirms that the service is active, explains which messages are sent and clarifies how translated outputs are retained.

The team can then decide what needs updating. It may be sufficient to connect the asset to the existing activity and correct the processing description. Other findings may justify reviewing the assessment or involving another specialist.

The completed outcome should preserve the original finding, the owner’s confirmation, the reviewer’s decision and the changes made.

That sequence changes the stakeholder interaction. The business owner receives a specific question with relevant background, rather than a broad request to describe the entire process again.

Keep evidence and human control in the workflow

Conversational access should make the review easier to conduct without weakening the standards applied to its conclusions.

First, define the technical boundary. A read-only review should use read-only permissions. An instruction in a prompt to avoid changes should not be the only restriction preventing them. The MCP specification places responsibility for access controls and safe tool use on implementers.

Second, require findings to remain connected to their sources. Reviewers should be able to distinguish a recorded fact from an extracted statement, a possible match or an inference.

An asset appearing in an inventory supports the statement that it is recorded there. It does not necessarily establish that the asset is currently used, that every available feature is enabled or that the documented purpose remains accurate.

Third, keep approval and follow-through explicit. A suggested correction should pass through the appropriate review process. A task should have a confirmed owner. A finding should remain open until the required evidence or decision has been recorded.

These distinctions allow AI assistance to reduce preparation work while preserving the decisions that belong with privacy professionals and business owners.

Start with one part of the programme

A first review does not need to cover the entire organisation.

Choose a bounded area where there is enough information to compare and a clear route to the people who can validate it. Customer support, recruitment or a defined vendor group could provide a manageable starting point.

Agree on what the review is intended to establish. Then use the discovery questions to examine missing relationships, incomplete information and inconsistencies within that scope.

Evaluate the findings as well as the effort involved. Were the suggested gaps meaningful? Did the source references help reviewers validate them? Were business owners asked fewer repeated questions? Did confirmed findings lead to completed updates?

Track false positives and unavailable information too. These reveal where naming conventions, record relationships or source coverage need improvement before the approach is expanded.

The most useful measure is the time and effort required to move from uncertainty to an evidenced resolution.

Making connected context useful in day-to-day privacy work

TrustWorks provides foundations for this approach through its data-mapping and RoPA capabilities. Its data-mapping gap assessment compares the asset inventory with processing records, while its RoPA model connects activities to repositories, data categories and responsible teams.

An MCP-enabled approach can build on that foundation by making supported context accessible through an authorised assistant. The opportunity is to help privacy professionals investigate operational questions without repeatedly reconstructing the same background.

The discovery questions provide a way to evaluate that opportunity in practical terms.

Can the team identify an unexplained relationship? Can it see the evidence? Can it ask the right person a focused question? Can it turn the answer into a reviewed update or accountable action?

Those are the outcomes that make a gap review valuable.

Book a demo with TrustWorks to explore how connected data inventories, processing records and AI-assisted workflows can help your team identify gaps and reduce manual review work.