Data Residency vs One Resilience Program: The Federated Answer

A resilience program is judged as a whole. Boards and regulators ask whether critical services can stay within tolerance, wherever they run. But the data behind that answer is increasingly tied to where it was created. A multinational must keep employee and incident data in-country. A group of near-independent businesses wants each to run its own program. A public agency runs many independent operations on the same HR, IT and facilities. Each case pulls the data apart while the program still has to hold together.

Why one central database stops working

The default answer is one platform, one database, with access rules that keep each unit to its own records. That works well inside one jurisdiction. It stops working when:

• The law decides where data lives. Privacy, residency and sovereign-hosting rules can require personal and operational data to stay in the country. Access rules do not change where data is stored.
• Some sites cannot be connected. Defence, government and critical-infrastructure sites often run air-gapped. A central platform cannot reach them, and they cannot reach it.
• Units need real independence. A business being prepared for sale, or a government operation with its own mandate, needs its own platform, not a filtered view of someone else’s.

The opposite answer, a separate tool per country or unit, keeps the data local but loses the program. Each site defines “critical” differently, shared services are recorded several times, and the enterprise view becomes a spreadsheet assembled by hand.

What federation means

Federation sits between the two. Each jurisdiction, line of business or operation runs its own complete platform, hosted where its data must live. One platform acts as the hub. Records fall into three classes:

• Global: the method and the standards (risk scales, impact categories, BIA time buckets, the control library, plan templates) and the shared entities everyone depends on (enterprise applications, shared services such as HR and payroll, global vendors). These are owned once at the hub and flow down as read-only copies.
• Local: processes, sites, BIA, plans, risks, exercises and incidents. These stay in the local platform. An agreed summary flows up.
• Private: people, contacts, evidence files and restricted risks. These never leave the local platform at all.

The enterprise view is built from the summaries: every critical service’s recovery objectives, its dependency on shared services, its last exercise result, across every site, without the hub ever holding another country’s personal data.

Four design choices that decide whether it works

1. One owner per record. Every shared record has exactly one owning platform; everyone else holds a read-only copy. Nothing is ever merged, so two sites can never disagree about the same record. Change requests go to the owner.
2. Summaries, filtered at the source. Each summary field carries a data class, and the local platform decides which classes may leave before anything is sent. That is where data-protection officers can sign off the flow.
3. Standards first. An enterprise heat map only means something if every site uses the same scales. Sharing the standards is the first step of any federation, and the cheapest.
4. Signed bundles, customer-held keys. Updates move as signed, encrypted bundles in numbered order, so they work across an air gap as well as over a network. The organization, not the vendor, holds the keys.

Incidents need one more thing: a small, fast status channel. When a shared entity such as an enterprise ERP fails, its owner raises the incident once and every dependent site sees its own impact immediately, while the full incident record stays local.

Questions to ask before choosing a platform

• Where does each kind of record physically live: people, sites, incidents, evidence, restricted records?
• What exactly leaves a jurisdiction, and who can switch a field off?
• Who can edit a shared record, and what happens when two sites disagree?
• Who holds the signing and encryption keys?
• How do updates and incident status reach a site with no live connection?
• How does a business unit move to another site or platform after a reorganization?

eRMA and federation

eRMA, the resilience platform from eBRP Solutions, runs on the customer’s own infrastructure, including air-gapped networks, and takes in outside data as signed bundles rather than live connections. Access is granted through teams, sensitive risks can be restricted to the people who should see them, and a complete export pack carries a whole program from one platform to another. These are the foundations the federated model builds on.

The full model is set out in the whitepaper Federated resilience: one program, many jurisdictions (PDF).

Planning a multi-jurisdiction program? Talk to eBRP Solutions.