⛺ Humanitarian Data Protection in Conflict Health Records

Patient Registration in a Conflict Zone — Collecting Data That Can Also Endanger

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.

• 600+: Documented attacks on health care, Syria 2011–2020 (Physicians for Human Rights)
• 2nd ed. 2020: ICRC Data Protection Handbook (core sector reference)
• 3 of 7: Sensitive fields modeled here (ethnicity, GPS, combatant status)
• 1990s: "Do no harm" doctrine (core humanitarian ethics principle)

The "do no harm" principle

"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.

What gets collected, and why each field is a decision

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.

Real documented risks that make this concrete

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.

Data Minimization — The First Line of Defense

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.

• Minimization: Core principle applied (ICRC / OCHA data responsibility)
• ~40–60%: Typical achievable field reduction (non-essential fields removed)
• 1 purpose: Purpose limitation rule (per data collection instance)
• shortest possible: Recommended retention default (time-bound, purpose-bound storage)

Minimization and purpose limitation as sibling principles

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 and proportionality in the field

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.

Retention limits close the loop

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.

Encryption at Rest — Making a Seized Device Useless to an Attacker

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.

• AES-256: Typical encryption standard (symmetric encryption at rest)
• common practice: Air-gapped field systems (in high-risk MSF/ICRC settings)
• >10¹⁸ yrs: Time to brute-force an AES-256 key (with current computing power)
• never on-device: Where the decryption key lives (separate storage / offline)

Encryption at rest and in transit

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.

Air-gapped and offline systems in high-risk settings

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 is necessary, not sufficient

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.

When Armed Actors Come Looking — Coercion, Raids, and Digital Intrusion

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.

• 2021: UNHCR–Myanmar biometric data disclosure (~830,000 Rohingya records affected)
• est. 2018: WHO Surveillance System for Attacks on Health Care (global incident tracking mechanism)
• 1,500+: Health-care attacks recorded worldwide, 2023 (WHO SSA, multiple conflict contexts)
• need-to-know: Governing access principle (role-based access control (RBAC))

Three attack vectors: raid, coercion, intrusion

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.

Need-to-know access control

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).

Documented cases of clinic data being sought as a weapon

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.

Aggregation Over Identification — Sharing Data Without Sharing People

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.

• case counts: Unit typically shared outward (not individual identifiers)
• est. 2014: Humanitarian Data Exchange (HDX) (OCHA-run open data platform)
• IASC standard: Health Cluster coordination system (aggregated inter-agency reporting)
• non-zero: Re-identification risk in small samples (requires k-anonymity safeguards)

The tension between protection and coordination

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.

Anonymization, de-identification, and pseudonymization — not the same thing

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.

How the aggregation pipeline actually works

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.

Data protection techniques and the risks each one mitigates