Research paper · Cyber, risk and resilience

Data Mediation for risk management: turning the impossible into the possible

Why fine-grained control can be enforced in the path between requester and source — making analysis possible across production data, IT and OT without defaulting to broad access or duplicate estates.

Context

Why this paper exists

Organisations possess data with enormous analytical value and equally significant risk. The usual response is to separate those facts: first move or copy the data into an analytical environment, then try to reconstruct control around the new copy.

This paper examines a different starting point. Data Mediation™ places fine-grained control in the interaction path between the requester and the source. The requester may be a person, a reporting system, a development environment, an AI model or an autonomous agent. The source may be a database, lake, SaaS platform, mainframe, historian or other IT or OT system.

The question is not whether data should ever move. It is whether broad access, replication and ingestion should remain the default prerequisites for analysis. If the organisation can govern the request, the result and the destination at the boundary, useful analysis can occur while authority over the source remains intact.

Risk is granular even when access is coarse

Many systems are good at answering a coarse question: may this user access this application or database?

Regulated work requires finer questions. Which records may the user retrieve? Which fields may they see? Which operation may they perform? Is the request consistent with their role and current purpose? Does it require approval? May the result leave the security zone? Can the same authority be given to an AI agent?

When the underlying system supports these distinctions natively, the problem is easier. When it does not, organisations tend to choose between two unsatisfactory positions. Restrict the access and lose analytical value. Or grant broad access and accept more exposure than the purpose requires.

The important architectural insight is that fine-grained control does not have to be a property of the source system.

Fine-grained control can be a property of the path.

The requester can be authorised to ask a specific question without acquiring broad authority over the system that answers it.

Analysis does not require ownership of the source

Data architecture has often equated analytical usefulness with consolidation. Copy the data into a warehouse. Ingest it into a lake. Export it into a notebook. Replicate it into a test environment. Build a vector store for an AI application.

Each pattern can be appropriate. Each also creates a new responsibility. The copied data must be classified, protected, retained, monitored and eventually deleted. Access entitlements have to be recreated. Freshness and lineage have to be understood. The analytical environment becomes another place where the organisation can lose control.

For IT data, the cost is often privacy, confidentiality and duplicated governance. For OT data, the consequences can be broader. Detailed process telemetry, engineering configuration and historian data can reveal how a physical system operates. A poorly designed analytical connection can also create an unintended route back towards the control environment.

The alternative is to start with the analytical purpose. What question needs to be answered? Which source is authoritative? What is the minimum result required? Which transformations must occur before the result leaves the source environment?

This shifts architecture from moving data first to governing the interaction first.

Data Mediation makes the analytical interaction governable

A Programmable Data Agent sits between the requester and one or more sources. It can establish identity, interpret the request, apply an approved query or capability, limit the fields and records returned, mask or transform sensitive values, restrict volume, enforce destination policy and retain an audit record.

The source remains authoritative. The requester receives the permitted result. The analytical capability is created in the path between them.

Requester → policy-bound question → Data Mediation → authoritative source → minimum approved result

The result moves because analysis requires an answer. The source does not have to be migrated, replicated or broadly exposed first.

This distinction is especially important for AI. A model rarely needs unrestricted ownership of the enterprise data estate. It needs the right context for the current task. Data Mediation can make the current user, model, purpose and destination part of the access decision, then provide only the permitted context.

The same pattern applies to a human analyst. The question can be approved while the underlying credentials and unrestricted database access remain withheld.

Request, approve, execute and audit is an established pattern

An early production implementation for a major insurance company provides a useful example. Analysts needed connected access to multiple production databases. Privacy and operational risk meant that broad direct access was not acceptable.

The mediation layer separated responsibilities. One role could define reusable query templates. Another could submit a query. An approver could review it and, for suitable read operations, test its potential effect. Execution was separately controlled. Submission, approval, rejection and execution were recorded in the audit database.

The databases were not redesigned to acquire this governance model. The control existed between the analysts and the sources.

The pattern is more important than the technology generation in which it was first implemented. It establishes that analytical authority can be decomposed. The right to formulate a question is not the same as the right to run it. The right to run it is not the same as the right to see every field in the result.

Modern Data Mediation extends the same logic to APIs, data lakes, SaaS, mainframe transactions, AI retrieval, OT historians and other forms of data in motion.

Human and machine requesters need different authority

A business analyst, a dashboard and an AI agent may ask for information from the same source. They should not automatically receive the same authority.

A human analyst may be allowed to run a set of approved templates and export a bounded result. A reporting system may have a service identity and a fixed data contract. An AI assistant may retrieve only information the current user is entitled to see. An autonomous agent may be allowed to read but not write, or may require human approval before a transaction is released.

Data Mediation makes those distinctions explicit at the boundary. Identity, purpose, requested operation, data classification, model destination and previous behaviour can all become inputs to the decision.

This is where risk management becomes operational. Policy stops being a document about who should have access and becomes executable control over what each requester can actually do.

Development and test are part of the production-data risk surface

Development and test environments are often treated as lower-risk because they are non-production. That assumption can fail when production data is copied into them.

A test environment may have broader administrator access, shorter-lived infrastructure, external development partners, more verbose logging and weaker retention discipline. A production snapshot can therefore carry production sensitivity into an environment that was never designed to carry production consequence.

Data Mediation provides another pattern. A development or test consumer can request data through a boundary that removes or substitutes sensitive fields, limits the cohort, tokenises identifiers, constrains volume and records the purpose before the data is released. In some cases the result can be synthetic or transformed rather than a copy of the original record.

Security can also be introduced while the application is still being built. A historical enterprise deployment used the mediation boundary to apply MFA, risk-based authentication and other controls during pre-release development. The security architecture did not have to wait for the application release to become active.

The principle is the same in both directions. Do not allow environment labels to determine risk. Govern the data interaction according to what the data is and what the requester intends to do with it.

IT and OT analytics require controlled connectivity, not broad trust

Operational data is valuable precisely because it describes the physical process. It can support reliability analysis, predictive maintenance, cyber detection, digital twins, simulation and AI. The same detail can increase risk if it exposes configuration, topology or operating behaviour to the wrong environment.

International OT guidance therefore emphasises deliberate connectivity, limited exposure, strong boundaries and separation between observation and control. The UK NCSC guidance, developed with international partners, explicitly recommends brokered connectivity and standardised, repeatable connection patterns rather than proliferating bespoke routes.

Data Mediation fits inside that design discipline. An OT historian can remain authoritative inside its zone while an approved analytical consumer receives a filtered result. A read path can be kept distinct from a control path. A model can receive selected telemetry without acquiring credentials that allow commands to be issued back into the process.

The same architecture can also govern cross-domain analysis where IT identity, cyber events and OT process signals need to be correlated. The point is not to collapse the security zones. It is to make the permitted exchange between them explicit, inspectable and reversible.

The organisation can analyse more by granting less

The common assumption is that analytical value increases with access. In a governed enterprise, the more useful question is whether the analysis can be performed with less authority, less replication and less uncontrolled exposure.

Data Mediation makes that possible by moving fine-grained control into the interaction path. The source remains where it is. The requester receives the minimum permitted result. Human and machine analysis can be governed through the same architecture without pretending that they carry the same risk.

Fine-grained control was not unavailable. It was being sought inside the systems rather than in the path that connects people and machines to them.

References

UK National Cyber Security Centre and international partners. Secure connectivity principles for operational technology ↗.

UK National Cyber Security Centre. Principle 3: centralise and standardise network connections ↗.

UK National Cyber Security Centre. Principle 5: harden your OT boundary ↗.

Australian Signals Directorate. CI Fortify ↗.

TomorrowX. Components, boundaries and non-functional requirements.

TomorrowX. Historical implementation records for controlled database access and approval workflows.

Next in Cyber, risk and resilience · Step 3 of 4

I’m 100% sure that we’re 67% secure

Continue the research path.

Read the next paper