Do No Harm Starts With Where You Keep the Data

In June 2025, a senior director from Microsoft France was asked under oath, in front of the French Senate, whether he could guarantee that French public data hosted in Microsoft's French datacentres would never be handed to US authorities. He could not. He explained that Microsoft challenges such requests where it can, and publishes the numbers. But the guarantee does not exist.

The transcript is public.

That was the day a comfortable assumption died. Many of us had been operating on the hopeful presumption that data residency was enough — that if the servers were in Frankfurt or Paris, our beneficiaries were covered and our operations were safe. Microsoft and Google both offer EU hosting and both take GDPR compliance seriously. That part is real.

Nothing against US services in particular. I use several of them myself and some are excellent. But we work in a sector with a first principle, and the principle is Do No Harm. In 2026, Do No Harm starts with where you keep the data.

Two risks, not one

When we talk about this, we usually mean confidentiality — who can read our beneficiary lists. That is real. But there is a second risk that gets much less attention and hits harder in the field: continuity.

US providers must comply with the Office of Foreign Assets Control (OFAC), and this is a very real concern. In August 2026, EU leaders had to publicly rally behind the International Criminal Court after a fresh round of US sanctions. A mandated international body, facing service exposure because of a decision taken in another jurisdiction entirely.

Now imagine that logic applied to a country office. One day just an email account that stops working on a Tuesday because a compliance team somewhere applied a rule you were never party to and cannot appeal. This is a more real possibility these days.

That is a programme risk, and it belongs on a risk register next to access negotiations and supply chain.

So what is actually in your cloud?

Start here, before any discussion about vendors or migrations.

Ask the question honestly: what is in there? Not what the policy says should be in there. What is actually in there.

In my experience the answer is always the same and always worse than expected. Beneficiary lists in Excel on SharePoint. Case notes in Word documents on OneDrive. Protection information in email threads. Registration data in a folder someone created for a 2019 response and never closed.

A file system cannot do what case data requires. Permissions are almost impossible to manage properly at scale. Changes are not tracked in any way that survives an audit. There is no archiving discipline, no retention that actually executes, no meaningful record of who looked at what and when. For protection data, that access history is often the part that made the holding defensible in the first place.

We got away with it for years because nobody could search across all of it at once.

That just ended.

Copilot did not create the problem, but it made it visible.

Copilot and Gemini surface anything the person asking has permission to see. Not what they knew they could see. What they can see.

Most NGO tenants have a decade of permission sprawl. Sites shared with "everyone in the organisation" during a surge. Folders inherited from a closed project. Files technically readable by three hundred people and practically buried where nobody would ever look.

Copilot un-buries them. A programme officer asking a reasonable question can now surface a protection case file that permissions always allowed and no one ever expected them to find.

And the feature arrived by release note, not by procurement decision. Nobody chose this. It appeared.

Before enabling any AI assistant on your tenant, run a permissions audit. It is cheap, it takes days not months, and it is valuable whether or not you ever switch the AI on — because the exposure already exists. Copilot only lit it up.

The shortcut that does not work

Some organisations reach for what feels like the safe answer: hyper-anonymisation. If we cannot protect the data, we will not hold the data. Strip the identifiers and sleep well.

I understand the instinct. It is still wrong, for three reasons.

Anonymisation breaks. Re-identification from combined attributes is well established and it gets easier every year. Location, age band, household composition, date of assistance — put enough weak identifiers together in a small caseload and you have a name. If your "anonymised" dataset leaks, or Copilot surfaces it, you are not off the hook.

Your donors will not accept it. Try explaining to an institutional donor that you cannot identify the people you served. Accountability to affected populations, verification, audit — all of it assumes you know who received what.

And it destroys coordination. Without identity you cannot deduplicate. You cannot deconflict with another agency working the same district, or with the line ministry, or with the cluster. So you get double registration in one place and gaps in another. That is not a privacy win. That is an operational failure with protection consequences, and the people who pay for it are the ones who were missed.

The answer is not to hold less. It is to hold it properly.

Extraordinary databases for extraordinary cases

This is a solved problem, and it was solved by our own sector.

If you run medical consultations, you need an electronic medical record — not a folder structure. If you run nutrition case management, DHIS2 exists and is the de facto standard across ministries of health. These tools are open source, field-proven at national scale, and they were built with the authentication, role separation, audit logging and archiving that caseload data actually requires.

I keep working demos if you want to see them rather than read about them: dhis2.baena.info and femr.baena.info.

The point is not these specific tools. The point is that purpose-built beats general-purpose, and that our sector already has purpose-built options that we routinely ignore in favour of a folder on SharePoint because it was already there.

Two traps on the way out

Trap one: adapting a commercial ERP. I have watched organisations contract enterprise ERP implementations or invest seriously in Power Apps development. Good luck.

The mismatch is structural. Commercial software is built for the business economy, which counts and invoices earnings. NGOs spend money. The whole logic runs in the opposite direction — grants, budget lines, donor restrictions, eligibility, reporting against a proposal. Every one of those has to be forced onto a data model designed for revenue. It always takes more work than the estimate, and the estimate was already the reason you chose it.

Trap two: building your own from scratch. We have been here before. Enormous development cost, and then a dependency — an Oracle licence, a proprietary framework — that made changing course mid-project impossible. So the organisation ran forward and poured in more money, because stopping felt like admitting that years of work and investment were wasted. Outsourced Power Apps development lands in the same place, just with a shorter runway.

What has genuinely changed is the cost of building. AI has made custom tooling dramatically cheaper to produce. NGO processes are more modular than they used to be. And mature open-source databases like PostgreSQL mean your data stays interoperable and portable instead of locked inside someone's licence.

So should you leave Microsoft and Google?

No. And I say that as someone who self-hosts almost everything.

For a mid-size organisation that has run on M365 or Workspace for a decade, migrating the whole estate is not realistic and not a good use of your political capital. Email, documents, finance admin, HR — leave them. Take the EU data boundary options, document what remains exposed honestly, and move on.

But do not leave it as it is either. Split the problem:

• Office tools stay. Caseload data moves. That is the line. General organisational data can live with your current provider. Beneficiary and case data goes to purpose-built systems on infrastructure you control, in a jurisdiction you chose deliberately.

Two things follow from that, and both are about continuity rather than confidentiality.

• Have a plan B, and write it down. If the tenant became unavailable organisation-wide tomorrow, what happens? Who holds a contact list that is not in Outlook? Which country office can still authorise a funds transfer? Most organisations have never asked the question. It takes an afternoon, it costs nothing, and it is the cheapest business continuity work available to you.
• And keep a copy under the mattress. Not everything — but the archive, the registration records, the closed-project files. The cloud should be redundancy, not the only copy.

In March 2026, Nine PBS, the public broadcaster in St. Louis, lost access to roughly 50 terabytes of material covering seventy years of local television history. Their cloud storage vendor went quiet, then defunct. In this case, it was not one of the hyperscalers but a small specialist provider they had renewed with annually since 2019. Fifty terabytes fits on a commercial NAS for less than the price of a laptop. That is the whole lesson.

Each organization operates differently, but the underlying principles apply universally. The world is evolving, and while a unified Humanitarian Cloud Service may eventually be the solution, its development does not excuse anyone from their immediate obligations.

There is a clock on the rest of it

The Microsoft grants already changed once. On 1 July 2025 the free Business Premium and Office 365 E1 grants for nonprofits ended, replaced by 300 free Business Basic seats and discounts of up to 75%. Organisations that waited until their renewal date got hurt. The lesson is not about pricing — it is that your entire operational stack was resting on a donation, not a contract, and donations are modified unilaterally. This transition is not going exactly smoothly: over 170,000 nonprofits have been affected, and Slate has asked whether Microsoft is to blame for the data loss.

Microsoft's recent licensing changes retire the free Business Premium tier, forcing NGOs to either pay for desktop applications and advanced security or downgrade to a web-only free tier that severely hinders offline field operations. Furthermore, Microsoft now strictly enforces an 85% active usage rule, where failing to maintain consistent account activity can trigger the revocation of an organization's entire donated license allocation. When these licenses are downgraded or revoked, the associated data is permanently purged within 30 to 90 days, making independent, self-hosted backup infrastructure essential to protect institutional memory.

Meanwhile the EU Data Act removes cloud switching charges entirely from 12 January 2027. The contract you sign this quarter will still be running on that date. If it bakes in old-world egress terms, multi-year lock-ins and auto-renewals, the deadline will arrive and find you still bound by the economics it was meant to dismantle.

I am writing a separate piece on AI sovereignty for NGOs. That one is a harder problem, and the good news is that it is also the layer where you still have room to move. Stay tuned.

I work with humanitarian organisations on data systems, sovereign infrastructure and applied AI. If you are looking at this and not sure where to start, the permissions audit is the first move and you can do it yourself.