Protecting patient health records collected in a conflict zone from armed actors who could weaponize them against the wounded
Every humanitarian health record starts as an act of care: a name, a wound, a home town, written down so a clinician can treat the right patient correctly. But in a conflict zone, the very same record can become a targeting list. This is the founding tension of humanitarian data protection — data collected to help can be weaponized to harm if it reaches the wrong hands.
"Do no harm" is the foundational ethical commitment of humanitarian action: an intervention meant to help must not create new risks for the people it serves. Applied to data, this means every field collected on an intake form is a potential liability, not just an asset. A patient's name links a face to a body; a wound type can reveal whether someone was a combatant; a home address can be used to locate family members after the patient has fled.
In active conflict, health facilities are not neutral ground in practice even when they are neutral in law. Documented cases show armed groups specifically seeking out wounded fighters who sought treatment at hospitals, and regimes cross-referencing clinic intake lists against ethnic or political minority populations. The clinician's obligation to treat everyone without discrimination collides directly with the risk that the resulting paper trail can later be used to discriminate — or worse.
In 2021, Human Rights Watch revealed that UNHCR had shared biometric data on roughly 830,000 Rohingya refugees in Bangladesh with the Myanmar government for a repatriation-verification exercise, reportedly without fully informed consent. Advocacy groups warned the data could be used by the same authorities the refugees had fled to identify and target them — a textbook case of data collected for protection becoming a protection risk.
A conflict-zone intake form typically balances four competing needs: clinical care (blood type, wound type, allergies), continuity of treatment (name or a pseudonymous ID, age), epidemiological surveillance (aggregate case counts by cause of injury), and administrative accountability (who was seen, when, by whom). None of these strictly require an exact home GPS coordinate, an ethnic or political affiliation, or a combatant/non-combatant designation — yet all three are routinely asked for out of habit, funder reporting templates, or a desire for "complete" records.
Humanitarian data protection frameworks — chiefly the ICRC Handbook on Data Protection in Humanitarian Action and OCHA's Data Responsibility Guidelines — start from a simple question asked at the point of collection, not afterward: is this specific field operationally necessary for this specific purpose? If the answer is no, or "maybe useful later," the field should not be collected at all. The safest sensitive data is data that was never recorded in the first place.
This is not a hypothetical. In Syria, healthcare facilities treating wounded from all sides were repeatedly and deliberately struck; investigators and rights groups documented that patient and staff information from besieged medical points had, in several cases, plausibly been used to identify targets for follow-on attacks or arrest. Beneficiary lists collected by aid organizations for entirely legitimate purposes — food distribution, medical follow-up, vaccination campaigns — have on multiple documented occasions been alleged to have been accessed or demanded by state or non-state armed actors seeking to identify specific ethnic, religious, or political groups.
These cases are the reason humanitarian data protection is treated as a component of physical protection, not an IT afterthought. A spreadsheet compiled to organize a vaccination campaign and a targeting list are, technically, the same artifact — the only difference is who ends up holding it.
The single most effective protection against a data breach is data that does not exist. Data minimization — collecting and retaining only what is operationally necessary for a specific, defined purpose — is the first and cheapest control in the humanitarian data protection toolkit, and it has to be applied before a single byte reaches storage.
Data minimization never stands alone — it is paired with purpose limitation, the rule that data collected for one purpose (treating a wound) should not silently be repurposed for another (population screening, security vetting, donor reporting) without a fresh assessment of the risk. Together the two principles force an organization to answer, field by field: what is this for, and do I need it to do that?
In practice this is applied at the form-design stage, before any patient sits down at the intake desk. Sensitive fields with weak operational justification — exact home coordinates instead of a district-level area, a detailed affiliation question instead of a simple triage category — are removed from the template entirely. Fields that survive this review are the only ones a staff member is ever permitted to ask about.
Necessity asks whether a field is required at all; proportionality asks whether the level of detail is proportional to the risk it creates. A clinic can usually operate with an area-level location ("northern district") instead of GPS coordinates precise to a few meters, and with a broad injury category instead of a note that a wound pattern is consistent with combat rather than domestic origin. Precision is not free — every extra decimal place of location accuracy or every extra descriptive detail is a marginal increase in how identifiable, and how targetable, a record becomes.
Minimization strictness is not fixed — it is a dial that should move with context. In a stable, low-threat setting, more descriptive fields may be justified for better care coordination. As the threat level rises — active fighting nearby, a hostile checkpoint, a documented pattern of targeted attacks — the dial should be turned toward stricter minimization, even at some cost to administrative convenience.
Minimization is not only about what is collected but how long it is kept. Best practice sets a retention period tied to the purpose the data served: once the clinical episode is closed and any legally required reporting is complete, identifying fields should be deleted or irreversibly de-identified rather than accumulating indefinitely "in case they are useful." A growing archive of old, sensitive records is a growing liability with no corresponding operational benefit — every additional year of retained identity data is another year in which a raid, a device theft, or a change of local power could expose it.
Many field organizations therefore separate the record into a short-lived identifiable layer (deleted or minimized after a defined period) and a long-lived de-identified statistical layer (case counts, injury categories) that can be retained indefinitely for reporting without carrying individual risk.
Minimization reduces how much sensitive data exists; encryption protects what remains. Once a record has been through the minimization filter, every field that is kept is converted to ciphertext before it ever touches a disk — so that if the laptop, phone, or server is lost, stolen, or seized at a checkpoint, its contents are unreadable without a key that lives nowhere on the device itself.
Two distinct protections are usually bundled under "encryption": encryption at rest protects data stored on a disk, and encryption in transit (e.g. TLS) protects data while it moves over a network. In conflict settings, at-rest encryption is often the more critical of the two, because the realistic threat is frequently physical — a raid on a clinic, confiscation of equipment at a checkpoint, or theft of a laptop — rather than remote network interception.
A properly encrypted database means that a device seized intact still yields nothing without the separately-held key. This shifts the security problem from "prevent every possible physical seizure" (extremely hard in an active conflict zone) to "protect one small key" (comparatively tractable) — a much more defensible position for an organization operating under duress.
Many organizations working in the highest-risk contexts (MSF, ICRC, and others) deliberately run field data systems air-gapped — physically disconnected from the internet — precisely because network connectivity is also an attack surface, whether through remote hacking attempts or through compelled access via internet service providers under the control of a party to the conflict. An offline system can still be lost or seized, but it cannot be remotely breached, and encrypted offline storage removes most of the value even from a successful seizure.
When data does need to move — for example, aggregated statistics travelling to a coordination hub — it is deliberately handled as a separate, minimal, one-way export rather than exposing the full clinical database to any network at all.
Encryption at rest defeats a specific, common threat — device loss or seizure — but it does not defeat every threat. A coerced staff member who is forced to type in the password at gunpoint, a compromised device that is unlocked when seized while still running, or a poorly implemented system with the key stored alongside the data all defeat the protection encryption is meant to provide. This is why encryption is always deployed as one layer in a broader stack: minimization reduces what is at risk, encryption protects what is stored, and access control (covered next) limits who can ever unlock it in the first place, ideally with procedures for staff to plausibly and safely decline access under duress.
All the preceding safeguards exist for this moment: an armed actor — a raiding party, an intelligence service, a hostile checkpoint, or a remote attacker — actively attempts to obtain patient data in order to identify wounded combatants or targeted minorities. This stage tests whether minimization, encryption, and access control actually hold up under real pressure, not just on paper.
Threats to conflict-zone health data broadly fall into three categories. Physical raids seize devices, paper files, or entire servers by force. Coercion pressures staff — sometimes at gunpoint, sometimes through bribery or blackmail — into voluntarily unlocking systems or handing over information they would otherwise refuse to disclose. Digital intrusion uses hacking, phishing, or compromised network infrastructure to obtain data remotely, without ever physically entering the facility.
Each vector calls for a different mitigation: raids are defeated primarily by encryption at rest (a seized encrypted device yields nothing); coercion is mitigated by minimizing what any single staff member can access (need-to-know access control) and by having contingency plans, such as decoy accounts, for staff under duress; intrusion is mitigated by air-gapping or hardened network security plus the same encryption at rest that defeats a physical raid.
Role-based access control (RBAC) restricts each user to only the data required for their specific function: a triage nurse may see wound type and allergy information but not a patient's political affiliation field (which, ideally, was never collected in the first place per Stage 2); an M&E officer compiling program statistics may see aggregate case counts but never individual names. This "need-to-know" restriction has two benefits under a threat scenario — it limits how much any single compromised account or coerced staff member can expose, and it reduces the number of people who could be individually targeted or pressured because they are known to hold sensitive access.
Access control is enforced technically (permissions, audit logs, multi-factor authentication where feasible) and organizationally (clear policies on who is authorized to grant access, and to whom data may ever be disclosed).
The threat modeled in this stage reflects a documented pattern, not a worst-case hypothetical. Investigators covering the Syrian conflict recorded repeated attacks on and raids of health facilities treating wounded from opposing sides, with patient information from besieged medical points implicated in follow-on targeting. Rights organizations have documented allegations, in multiple conflict and post-conflict settings, that beneficiary or patient lists compiled by humanitarian actors were sought or accessed by state security services seeking to identify members of ethnic, religious, or political groups.
The WHO's Surveillance System for Attacks on Health Care, established to systematically track such incidents, recorded well over a thousand attacks on health facilities and workers globally in a single recent year — a scale that makes threat-resilient data handling a core operational requirement for any organization delivering health care in an active conflict, not an optional add-on.
The 2021 UNHCR–Rohingya biometric data case remains one of the starkest documented illustrations of this stage: data originally collected to protect and register refugees was shared with the government those refugees had fled, without robust consent safeguards — showing that even well-intentioned, well-resourced humanitarian actors can become the vector through which protected people are exposed to the very actor they feared.
Protecting individual patient data does not mean humanitarian coordination grinds to a halt. Response planners genuinely need to know how many people were wounded, of what kind, and where — but they never need to know who, by name. The resolution is aggregation and anonymization: individual-level data stays locked at the clinic, while de-identified, aggregate statistics flow outward to coordination bodies.
Humanitarian response is fundamentally a coordination problem: multiple agencies, clusters, and donors need a shared, reasonably accurate picture of needs to allocate scarce supplies, staff, and funding sensibly. That requires data — but the coordination system needs the shape of the crisis (how many wounded, what injury types, which districts, trending up or down) far more than it needs to know any specific patient's name. Conflating the two needs — treating "we must share information" as equivalent to "we must share identifiable records" — is precisely the failure mode that leads to incidents like the Rohingya biometric case in Stage 4.
These terms are often used loosely but describe distinct levels of protection. De-identification removes direct identifiers (name, exact address) but may leave enough combined indirect detail (age + injury type + small village + date) that a patient is still re-identifiable to someone with local knowledge — this is a real, documented failure mode in small-sample humanitarian reporting. Pseudonymization replaces identifiers with a code, but the code can be reversed by whoever holds the mapping key — useful for internal case tracking, not for external sharing. True anonymization removes or aggregates data such that no individual can reasonably be re-identified even by a well-informed adversary, typically by reporting only counts above a minimum threshold (k-anonymity) and by generalizing precise fields (exact age → age band, exact GPS → district).
Only genuinely anonymized, aggregated data — never merely de-identified or pseudonymized records — should leave the protected boundary of the clinic for external coordination purposes.
In practice, a clinic's protected local database periodically produces a one-way statistical export: total patients seen, broken down by broad injury category and district, with any category containing very few cases either suppressed or merged with a neighboring category to prevent re-identification by elimination. This export — and only this export — is transmitted to the relevant coordination mechanism, such as an inter-agency Health Cluster or a platform like OCHA's Humanitarian Data Exchange, where it is combined with equivalent aggregate submissions from other facilities to build the region-wide picture planners need.
The identifiable patient database that produced those numbers never leaves the facility, is never transmitted over the same channel, and is not accessible to coordination staff. The wall between the two is not just a policy — it is the entire point of Stages 2 and 3: minimization and encryption exist so that this wall can be enforced technically, not merely promised.
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Data Minimization | Excess sensitive fields existing at all; blast radius of any future breach | Collect and retain only fields with a defined operational purpose; delete or generalize the rest at intake | Does not protect data that is genuinely needed and retained |
| Encryption (at rest & in transit) | Device/server seizure, theft, and network interception | Convert data to ciphertext readable only with a separately-held key | Useless against coercion of an authorized user who unlocks the system |
| Anonymization / De-identification / Pseudonymization | Exposure of individual identity when data must be shared externally | Strip or generalize identifiers; report only aggregate counts above a safe threshold | Weak or reversible forms (pseudonymization, partial de-identification) can still permit re-identification |
| Need-to-know Access Control (RBAC) | Insider misuse, coercion of low-need-to-know staff, credential compromise | Restrict each role to the minimum data required for its function; log and audit access | Requires ongoing governance; ineffective if permissions are not actually enforced |