Securely Connecting Third Parties to a Live Incident Without Exposing the Incident

Major incidents rarely exist within the information boundaries of a single organisation.

Police, ambulance and fire services may each be managing their own response through their own control rooms and incident management systems. Local authorities, hospitals, infrastructure operators and other agencies may be doing the same.

At the same time, valuable information may come from organisations that are not involved in running the incident at all.

Universities, research organisations, environmental monitoring systems, infrastructure providers and specialist modelling services may hold information that could materially improve situational awareness.

These are very different relationships, but they create a common problem:

How do you allow trusted third parties to contribute information to a live multi-agency incident without giving them unnecessary access to the central incident management system, and without requiring them to open their own systems in return?

That is one of the problems we are addressing with ORDU Studio and, specifically, ORDU Connect.

Information Sharing Does Not Require Shared Access

It is tempting to think about multi-agency information sharing as a permissions problem.

Add every participating organisation as a user. Give them accounts. Restrict what they can see.

Or approach the problem from the opposite direction and connect directly to each organisation's systems, giving the central platform permission to retrieve the information it requires.

Both approaches potentially expand the security boundary.

An active incident can contain highly sensitive operational information: internal decisions, personnel details, locations, vulnerabilities, communications, response plans and information supplied by other organisations.

Likewise, the systems operated by police, ambulance, fire, hospitals, infrastructure providers, universities and other organisations can contain information that has absolutely no reason to be exposed to a central multi-agency platform.

The requirement to share one piece of information should not become a requirement to expose an entire system.

ORDU therefore treats contributing information, receiving information and accessing another organisation's systems as separate concepts.

An organisation can contribute to the multi-agency operational picture without becoming a user of ORDU Console.

ORDU can receive information from an organisation without being given access to that organisation's internal systems.

That separation is fundamental to the architecture of ORDU Connect.

Secured Verified Third-Party Providers

Within ORDU Studio, we refer to trusted external information providers as Secured Verified Third-Party Providers, or SV3Ps.

An SV3P could be an operational organisation such as a police, ambulance or fire service running its own incident control room.

It could be a hospital, local authority, utility company or infrastructure operator.

It could equally be an organisation with no role whatsoever in coordinating the incident but which operates a specialist system, dataset or analytical capability that becomes relevant under particular circumstances.

A university running an earthquake-impact model is a good example.

These organisations have very different relationships with an incident, so ORDU Connect cannot assume that every SV3P should have the same level of access or exchange the same information.

Most importantly:

The SV3P controls what information it shares and when it shares it.

Connecting an organisation to ORDU does not mean opening that organisation's systems to ORDU.

Nor does it mean giving that organisation unrestricted access to information held within ORDU.

ORDU Connect provides a controlled digital channel between otherwise separate environments.

Three Doors, With ORDU Connect in the Middle

There is an important architectural difference between integration and access.

A traditional integration can require one organisation to open a digital door into its systems so another system can reach inside and retrieve the information it needs.

For incident management, particularly across organisational boundaries, that creates an uncomfortable security question:

How much of your digital environment do you need to expose so somebody else can obtain the small amount of information they actually require?

ORDU Connect takes a different approach.

Think of the architecture as three doors in a corridor.

The first door protects the external organisation's operational environment.

The third door protects the ORDU incident environment.

And between them is the second door:

ORDU Connect.

The external organisation does not give ORDU a key to its door.

ORDU does not give the external organisation a key to the incident.

Instead, both sides communicate through the controlled middle door.

ORDU Connect is the gatekeeper.

The originating organisation decides what information it wants to allow out of its environment and when it wants to share it.

That information is deliberately submitted through the middle door.

ORDU Connect authenticates the source, validates and handles the submission, associates it with the appropriate incident and makes the structured information available to ORDU Console.

The communication becomes:

Organisation → ORDU Connect → ORDU Console

rather than:

ORDU → open external system → search for information → retrieve data

That distinction matters.

ORDU does not need permission to roam through another organisation's systems looking for information.

The third party does not need access to ORDU Console to deliver information.

The doors protecting both operational environments remain closed.

ORDU Connect provides the controlled middle door through which approved information can pass.

The Sender Controls Its Door

This changes who controls the information-sharing relationship.

With a system designed around pulling information from another organisation, the receiving system is effectively asking:

"What am I allowed to retrieve?"

With ORDU Connect, the originating organisation instead decides:

"What do I want to share?"

and:

"When do I want to share it?"

This is particularly important when connecting operational organisations such as police, ambulance and fire services.

Their systems may contain large amounts of information that should never be exposed outside their own security boundary.

Connecting to ORDU should not mean granting ORDU access to those systems.

Instead, when an organisation determines that a particular operational update should form part of the multi-agency picture, it can publish that specific information through the middle door provided by ORDU Connect.

Everything else stays behind the originating organisation's own door.

Use Case One: Specialist Intelligence Without Incident Access

Our first SV3P integration provides a good example of an organisation that is not directly involved in managing an incident.

A university is modelling the potential impact of earthquakes on emergency services.

The university is not interested in every incident being managed through ORDU.

It is interested specifically in incidents involving natural disasters where the general location of the incident is within a defined distance of a detected earthquake.

That creates a very specific information relationship.

The university needs enough information to establish:

"Is there an incident relevant to our earthquake model?"

It does not need to ask:

"What is happening inside that incident?"

That distinction drives the information exchange.

Share Only Enough to Establish Relevance

ORDU Console is the protected operational environment where authorised teams coordinate an incident.

ORDU Connect provides the controlled boundary between that environment and external systems.

For the earthquake use case, the university does not need the incident timeline, operational decisions, personnel information, plans, messages or other sensitive information held within Console.

It needs only the limited information necessary to determine whether an incident falls within its area of relevance.

In this case, that could include factors such as the incident classification and a sufficiently generalised location.

The SV3P can compare that limited information against its own data:

Natural disaster incident → general location → detected earthquake → distance threshold → potential match

If those conditions are not satisfied, nothing further needs to happen.

The provider has received only the minimum information required to establish that the incident is not relevant to it.

If the conditions are satisfied, however, the external system can perform its specialist work.

Let Specialists Remain Specialists

Once a relevant incident has been identified, the university can run its earthquake-impact model using its own systems, datasets and specialist expertise.

ORDU does not need to replicate that capability.

This is another important architectural principle behind ORDU Connect.

An incident management system does not need to become a meteorological system, earthquake-modelling platform, infrastructure-monitoring platform, medical system, policing system and every other specialist system that could potentially contribute to an incident.

Those capabilities already exist.

The objective should be to allow their relevant outputs to contribute to the operational picture when required.

The detailed earthquake modelling therefore remains within the university's environment.

Once the analysis has been completed, the university can choose to submit the relevant results securely to ORDU Connect.

Turning External Intelligence Into Operational Information

Information received by ORDU Connect is not simply dumped into the incident.

Connect can process the submission and convert it into a structured message that ORDU Console understands.

That message can then be rendered within the Console dashboard for the relevant incident.

The incident team does not need to understand the university's underlying system, data structures or modelling platform.

They receive the information within the environment where they are already coordinating the response.

The flow becomes:

ORDU Connect → limited relevance information → SV3P

followed, where relevant, by:

SV3P → specialist analysis → ORDU Connect → structured message → ORDU Console

The external organisation remains outside the incident management environment while its relevant intelligence becomes part of the operational picture.

Bringing the Detailed Source Within Reach

Sometimes the structured information presented in ORDU Console will be enough.

Sometimes the people making a decision will need to investigate further.

An SV3P can therefore also include secure links back to information held within its own systems.

In the earthquake example, the university might maintain a specialist dashboard containing significantly more detailed modelling, visualisations, datasets or supporting information.

ORDU can surface a link to that resource alongside the information received through Connect.

Importantly, ORDU does not attempt to bypass the security controls of the external provider.

Most members of the incident team may not have permission to access that university dashboard.

That is expected.

Those who do have the appropriate credentials can follow the link and authenticate with the provider using the access controls already protecting that system.

This becomes particularly valuable during meetings, discussions and operational decision-making.

Rather than someone having to remember that another specialist system exists, find the appropriate application, locate the correct analysis and establish whether they have access, the source can be immediately available from the operational information that prompted the discussion.

ORDU provides the context. The external organisation retains control of the detailed information.

Use Case Two: Connecting Operational Control Rooms

The same architecture addresses a very different problem when the SV3P is itself responding to the incident.

Consider a major incident involving police, ambulance and fire services.

Each service may have its own control room, systems, procedures, security boundaries and operational responsibilities.

They may already have mature incident-management capabilities of their own.

ORDU Studio should not require those organisations to abandon their systems or force everybody involved in a multi-agency incident to work through one enormous application.

The requirement is different.

The multi-agency coordination team needs relevant information from those organisations.

And those organisations need a secure, reliable mechanism through which they can choose to provide it.

The Telephone Problem

Without digital integration, information exchange between control rooms can still depend heavily on telephone calls.

An operator in one control room reads information from their system.

They communicate it verbally to somebody in another control room.

The person receiving the call listens to it and records it in another system or incident log.

The information has effectively travelled through this chain:

System → person → telephone → person → system

Consider what has happened to the data.

It started digitally.

It was interpreted by a person.

It was converted into speech.

It travelled over the telephone.

It was heard and interpreted by another person.

It was then converted back into digital information by manually entering it into another system.

Every one of those stages introduces an opportunity for information to be misunderstood, abbreviated, incorrectly transcribed, mistyped or stripped of useful structure and context.

The person speaking may omit something they do not realise is significant.

The person listening may hear a number incorrectly.

A location may be transcribed incorrectly.

A time may lose its context.

Terminology used by one organisation may be interpreted differently by another.

And once that information has been entered into the central incident log, the incorrectly transcribed version can begin to look authoritative simply because it is now written in the system.

During a major incident, where information may be changing rapidly and operational decisions can depend on small details, that matters.

Digital Information Should Stay Digital

ORDU Connect provides another route.

Where systems can integrate digitally, structured information can be transmitted securely from an organisation's own environment into the multi-agency incident.

Instead of:

Control Room A → operator → telephone → operator → multi-agency incident log

the information can travel:

Control Room A → ORDU Connect → structured message → multi-agency incident

The information that leaves the originating organisation is the information that arrives.

Dates remain dates.

Times remain times.

Locations remain locations.

Coordinates remain coordinates.

References remain references.

Identifiers remain identifiers.

Structured fields remain structured fields.

The information does not have to be converted into a spoken description and then reconstructed manually at the other end.

This does not remove people from incident management.

Quite the opposite.

It allows people to spend more of their time understanding information, discussing its significance and making decisions rather than acting as human data-transcription interfaces between computer systems.

Preserve What Was Actually Said

There is another important advantage to structured digital communication.

The original submission can be retained.

That means there can be a distinction between:

what the originating organisation actually sent

and:

how that information is subsequently presented, interpreted or acted upon.

This is particularly important in an incident log.

If information is communicated verbally and manually typed into a log, the log may contain somebody's transcription or interpretation of the original information.

With structured digital communication, the original message can remain part of the audit trail.

That creates stronger provenance and provides a much clearer record of how information entered the multi-agency operational picture.

SV3Ps Choose What They Share

None of this means that an integrated police, ambulance, fire or other control room should automatically stream all of its incident information into ORDU.

That would defeat one of the central security principles behind Connect.

The SV3P decides what it shares.

The SV3P decides when it shares it.

Police may hold information that is inappropriate for wider distribution.

Ambulance services may hold confidential information that has no place in the wider multi-agency operational picture.

Fire and rescue services may have detailed internal operational information that does not need to leave their own control environment.

A university may have extensive research data when only a small part of its analysis is relevant to the incident.

Connecting these organisations to ORDU does not create unrestricted visibility across organisational boundaries.

It creates a controlled mechanism through which the originating organisation can say:

"This information is relevant to the multi-agency response, and we are choosing to share it."

That information can then pass securely through ORDU Connect.

Everything else remains inside the organisation's own security boundary.

Integration does not mean surrendering control of your data.

Trust the Source, Not Every Piece of Information

There is another important distinction.

A verified source does not mean that every piece of information it sends should automatically be treated as operational fact.

ORDU Connect can establish that a submission originated from a recognised SV3P.

That provides provenance.

But provenance and operational validation are different things.

A model is still a model.

A prediction is still a prediction.

An operational report may later be superseded.

Information can be incomplete or conflict with information received from another source.

Maintaining that distinction becomes particularly important during complex incidents involving multiple organisations.

The system should therefore be capable of answering questions such as:

• Who supplied this information?
• When was it submitted?
• Which verified integration submitted it?
• Which incident was it associated with?
• What information was originally received?
• How was that information presented within Console?
• Is there a source system containing further detail?
• Has newer information subsequently been received?

This creates an auditable information chain without requiring the external provider to enter the operational environment.

The Principle of Minimum Necessary Disclosure

The architecture is based on a straightforward security principle:

Expose only what another organisation needs in order to perform its role.

For the university earthquake model, that may mean knowing that a natural-disaster incident exists within a particular general area.

It does not require knowing which personnel are responding, what resources have been deployed, what decisions have been made or what other agencies have reported.

For an emergency service, it may mean sharing a structured operational update with the multi-agency team while retaining sensitive internal information within its own systems.

For the central incident team, it may mean receiving the output of a specialist model without being granted access to the provider's entire platform.

Each organisation remains responsible for protecting its own information.

ORDU Connect provides the controlled information exchange between them.

Secure Communication Without Opening the Network

This is ultimately what ORDU Connect is designed to provide:

a secure communication boundary, not an open integration boundary.

The goal is not to create deeper and deeper access between organisations.

It is not to create a central system capable of reaching into every connected organisation.

And it is not to require every organisation contributing information to become a user of ORDU Console.

The goal is to create a trusted route through which organisations can exchange exactly the information required to coordinate an incident.

Think again about those three doors.

Behind the first is the external organisation and the information it protects.

Behind the third is the ORDU incident environment and the sensitive operational picture it protects.

Between them is ORDU Connect.

The middle door exists so that neither of the other two has to be opened.

ORDU Connect becomes the gatekeeper between otherwise separate operational environments.

It knows who is communicating.

It controls the route into ORDU.

It can validate what is received.

It preserves the structure and provenance of the information being exchanged.

It associates that information with the appropriate incident.

And, critically, it allows the operational environments on either side to remain protected.

You do not have to open your systems to participate in the digital coordination of an incident. You only have to pass the information you choose to share through a controlled middle door.

From System Integration to Information Coordination

This changes how we think about interoperability in incident management.

The objective is not to put every organisation into one enormous system.

It is not to give everybody access to everybody else's data.

And it is not simply to connect as many APIs as possible.

The objective is to allow the right information to move securely between organisations, in a structured form, at the point where it becomes operationally useful.

Sometimes that means bringing specialist intelligence from a university or research organisation into the operational picture.

Sometimes it means allowing police, ambulance, fire or another responding organisation to send a structured operational update from its own control room directly into the multi-agency incident.

Sometimes it means providing authorised members of the incident team with a secure route back to more detailed information held within a specialist external system.

In every case, the principle remains the same.

The originating organisation retains control over what it shares and when.

The receiving organisation does not need unrestricted access to the originating system.

The external organisation does not need unrestricted access to the central incident.

The information remains digital and structured rather than being unnecessarily translated from system to speech and back into another system.

And ORDU Connect sits between those environments as the controlled middle door.

ORDU Console remains the protected environment in which the multi-agency incident is coordinated.

ORDU Connect provides the controlled bridge through which trusted organisations and systems can contribute to that operational picture.

Because effective multi-agency coordination depends on sharing information.

It should not require opening your digital doors.

And when information already exists digitally, it should not depend on reading it down a telephone and hoping it is written down correctly at the other end.