Protection Data Principles
Protection data principles govern how organisations collect, store, share, and use information about individuals in vulnerable situations. These principles differ from general data protection requirements because protection data carries heightened risk: the same information that enables service delivery can, if mishandled, expose individuals to violence, discrimination, persecution, or death. Protection data principles establish the ethical and operational framework that subordinates data utility to human safety.
- Protection data
- Information collected in the course of protection programming that relates to individuals facing threats to their life, liberty, or physical integrity. This includes data about survivors of violence, persons with protection concerns, and individuals whose identification could place them at risk.
- Do no harm
- The principle requiring that humanitarian action, including data collection and use, must not increase the vulnerability of affected populations or expose them to additional risks.
- Survivor-centred approach
- A framework placing the rights, needs, and wishes of survivors at the centre of all decisions about their data, recognising survivors as the primary decision-makers about information concerning them.
- Data responsibility
- The duty to manage data in ways that respect the rights and dignity of individuals, minimise risks, and maximise benefits throughout the data lifecycle.
- Informed consent
- Agreement to data collection and use given freely, based on clear understanding of what data will be collected, how it will be used, who will access it, and what risks and benefits may result.
- Purpose limitation
- The restriction of data use to the specific, explicit purposes communicated at the time of collection, prohibiting secondary uses without additional consent.
The Do No Harm Imperative
The do no harm principle requires that every data decision undergoes assessment for potential negative consequences before implementation. In protection contexts, harm takes specific forms: physical violence against identified individuals, discrimination based on disclosed characteristics, persecution by state or non-state actors, family or community retaliation, and psychological re-traumatisation. Data practices that would be routine in commercial or administrative contexts become dangerous when applied to protection populations.
The mechanism of harm through data operates through several channels. Direct identification occurs when data reveals the identity of a protected person to hostile actors. A database of gender-based violence survivors, if accessed by perpetrators or their associates, becomes a targeting list. Indirect identification results from combining ostensibly anonymised data with other information sources to re-identify individuals. A protection assessment recording village of origin, age, and family composition may identify a specific household even without names. Pattern exposure happens when aggregate data reveals protection-seeking behaviour to authorities or communities. Reports showing that 47 women from a particular district sought services at a safe house inform perpetrators that women are leaving and where they are going. Future risk emerges when data collected today becomes dangerous under changed circumstances. Registration data gathered during a stable period becomes a targeting tool if political conditions shift.
+--------------------------------------------------------------------------------+| HARM PATHWAYS IN PROTECTION DATA |+--------------------------------------------------------------------------------+| || +-----------------------+ || | Data Collection | || +-----------+-----------+ || | || v || +-----------+-----------+ +-----------------------+ || | Storage/System +---------->| Unauthorised | || | Breach | | Access | || +-----------+-----------+ +-----------+-----------+ || | | || v v || +-----------+-----------+ +-----------------------+ || | Authorised but | | Direct | || | Inappropriate | | Identification +--------+ || | Sharing | +-----------+-----------+ | || +-----------+-----------+ | | || | v v || v +-----------------------+ +-----------+ || +-----------+-----------+ | | | Physical | || | Aggregate/ +---------->| Indirect | | Harm | || | Pattern Data | | Identification | +-----------+ || +-----------+-----------+ +-----------+-----------+ ^ || | | | || v v | || +-----------+-----------+ +-----------------------+ | || | Retention Beyond | | Future Risk +--------+ || | Need +---------->| Materialisation | || +-----------------------+ +-----------+-----------+ || | || v || +-----------------------+ || | Targeting & | || | Persecution | || +-----------------------+ || |+--------------------------------------------------------------------------------+Figure 1: Pathways through which protection data causes harm to individuals
Do no harm assessment requires systematic evaluation before collecting any data element. For each field in a registration form, case intake, or monitoring tool, the assessment asks: what harm could result if this specific data point were accessed by hostile actors? What is the likelihood of such access given current and foreseeable security conditions? Does the protection benefit of collecting this data outweigh the risk of harm from potential exposure? If the risk-benefit analysis is unfavourable, the data element should not be collected regardless of its analytical utility.
The temporal dimension of do no harm extends beyond immediate risks. Data collected during one phase of a crisis may become dangerous in a subsequent phase. Registration records from a refugee camp may be safe while an international presence maintains security but become targeting information if the camp falls under hostile control. Historical case files documenting protection concerns create liability if future governments or armed groups gain access. Do no harm requires organisations to project forward 5-10 years and consider what political, security, or technological changes could transform safe data into dangerous data.
Survivor-Centred Data Governance
The survivor-centred approach transfers decision-making authority about data from organisations to the individuals whose information it contains. This represents a fundamental shift from institutional convenience to individual rights. Survivors decide what information to share, with whom it may be shared, for what purposes, and for how long it may be retained. Organisations act as custodians executing survivor decisions rather than owners exercising institutional discretion.
Survivor agency over data manifests in concrete operational requirements. At intake, survivors receive complete information about data practices in language and format they understand, then decide which data elements to provide. Survivors may decline to answer specific questions without losing access to services. Throughout the service relationship, survivors may access their records, correct inaccuracies, restrict sharing, and request deletion. Upon case closure, survivors specify retention preferences within the bounds of legal requirements. No data about a survivor flows to any external party without the survivor’s explicit authorisation for that specific disclosure.
+--------------------------------------------------------------------+| SURVIVOR-CENTRED DATA MODEL |+--------------------------------------------------------------------+| || +-------------------+ || | SURVIVOR | || | (Decision-maker) | || +--------+----------+ || | || +--------------------+--------------------+ || | | | || v v v || +------+------+ +-------+------+ +-------+------+ || | Collection | | Access & | | Sharing & | || | Decisions | | Correction | | Retention | || +------+------+ +-------+------+ +-------+------+ || | | | || | Instructs | Requests | Authorises || v v v || +------+------+ +-------+------+ +-------+------+ || | Case Worker | | Data | | Data | || | (Collector) | | Custodian | | Custodian | || +------+------+ +-------+------+ +-------+------+ || | | | || v v v || +------+--------------------+--------------------+------+ || | | || | CASE MANAGEMENT SYSTEM | || | (Organisational custody) | || | | || +-------------------------------------------------------+ || |+--------------------------------------------------------------------+Figure 2: Data governance model with survivor as primary decision-maker
The practical implementation of survivor-centred principles requires acknowledging that survivors’ expressed preferences may conflict with organisational practices, donor requirements, or legal obligations. When conflicts arise, the survivor’s wishes take precedence except where legal mandates require otherwise. A survivor who does not consent to inclusion in donor reports is excluded from those reports even if this affects funding. A survivor who requests immediate deletion receives deletion even if standard retention periods have not elapsed, unless legal holds apply. Organisational interests in data never override survivor interests in data.
Survivor-centred governance addresses the information asymmetry inherent in protection relationships. Survivors often lack knowledge of data systems, legal frameworks, and institutional practices that would enable truly informed decisions. Bridging this asymmetry requires more than disclosure documents. Staff must explain data practices in concrete terms: “I will write down what you tell me about the incident. This information will be stored in our computer system. My supervisor can see it. Our donor cannot see individual records but receives statistics. You can ask me to show you what I wrote at any time. If you want us to delete your information after your case closes, we will do that.” Abstract privacy notices do not constitute meaningful communication.
Power Dynamics in Data Collection
Data collection in protection contexts occurs within pre-existing power relationships that constrain genuine consent and authentic self-determination. Individuals seeking protection services often depend on organisations for safety, legal status, material assistance, or access to other services. This dependency creates structural pressure to comply with data requests regardless of comfort level. Refusal to provide data may be perceived as risking service denial even when organisations commit to providing services regardless of data provision.
+--------------------------------------------------------------------+| POWER DYNAMICS IN DATA COLLECTION |+--------------------------------------------------------------------+| || HIGH POWER DIFFERENTIAL LOW POWER DIFFERENTIAL || <-----------------------------------------------------------> || || +----------------+ +----------------+ +----------------+ || | Registration | | Case | | Community | || | for essential | | Management | | Feedback | || | services | | Relationship | | Mechanisms | || +-------+--------+ +-------+--------+ +-------+--------+ || | | | || v v v || +-------+--------+ +-------+--------+ +-------+--------+ || | Survival needs | | Trust-based | | Voluntary | || | create strong | | but still | | participation | || | compliance | | asymmetric | | lower pressure | || | pressure | | relationship | | | || +----------------+ +----------------+ +----------------+ || || MITIGATION REQUIRED: || - Unbundle data from services || - Offer genuine alternatives || - Build in cooling-off periods || - Enable anonymous options || |+--------------------------------------------------------------------+Figure 3: Power differential across different data collection contexts
The mechanism of power distortion operates through several factors. Scarcity of alternatives means survivors may have no other source for needed services, making the data-providing organisation a gatekeeper. A refugee requiring resettlement referral has no meaningful choice about whether to provide data to the referring organisation. Information control positions organisations as experts on processes that survivors do not understand, creating deference to organisational requests. When a case worker says certain data is “required,” survivors lack the knowledge to question this claim. Repeat interactions mean that survivors who decline data requests fear affecting their ongoing relationship with service providers. A survivor who refuses to answer certain questions may worry about receiving less attentive service in future interactions. Cultural factors in many contexts create expectations of deference to authorities and reluctance to refuse requests from organisations perceived as powerful.
Mitigating power dynamics requires structural changes to data collection practices. Service provision must be explicitly decoupled from data provision, with survivors receiving clear communication that service quality and availability do not depend on answering all questions. Organisations should identify the minimum data required for service delivery and collect only that minimum during initial contact, with additional data collection occurring later when trust has developed. Staff training must address unconscious pressure behaviours: body language that signals disapproval of refusals, questions phrased as requirements rather than requests, and failure to pause meaningfully after indicating that questions are optional.
The power analysis extends to the design of data collection instruments themselves. Forms with extensive required fields communicate that data provision is expected. Intake processes that ask sensitive questions before establishing rapport exploit the compliance tendency present at first contact. Efficiency-oriented approaches that batch all questions together prevent survivors from processing implications. Power-conscious design uses progressive disclosure, asks sensitive questions only after relationship establishment, marks fields as genuinely optional with clear explanation of consequences, and builds in pause points where survivors can reconsider participation.
Risk-Benefit Assessment Framework
Every protection data decision involves trade-offs between potential benefits and potential harms. Benefits include improved service quality through better understanding of survivor needs, resource allocation through aggregate analysis, advocacy through documentation of patterns, and accountability through evidence of services provided. Harms include the exposure risks detailed in the do no harm discussion, plus psychological harms from intrusive questioning, dignity harms from reducing individuals to data points, and autonomy harms from expanding institutional surveillance of vulnerable lives.
The risk-benefit assessment mechanism requires systematic enumeration of both sides before any data collection decision. A proposed registration form adding 15 demographic fields for “better programme targeting” must demonstrate specific, concrete benefits from each field and weigh those against specific, concrete risks from each field. Abstract benefits (“improved understanding”) do not justify concrete risks (identifiable household characteristics in a database).
+--------------------------------------------------------------------+| RISK-BENEFIT ASSESSMENT MODEL |+--------------------------------------------------------------------+| || ASSESSMENT QUESTION: Should we collect [data element]? || || +------------------------+ +------------------------+ || | BENEFITS | | RISKS | || +------------------------+ +------------------------+ || | | | | || | Service delivery | | Identification risk | || | - Specific use case? | | - Direct exposure? | || | - Achievable without? | | - Indirect inference? | || | | | | || | Analysis/advocacy | | Breach consequences | || | - What decisions? | | - Who gains access? | || | - Alternative sources? | | - What could they do? | || | | | | || | Accountability | | Collection harm | || | - Required by whom? | | - Re-traumatisation? | || | - Minimum needed? | | - Dignity impact? | || | | | | || +------------------------+ +------------------------+ || | | || v v || +------------------------+ +------------------------+ || | Quantify: How many | | Quantify: What is | || | survivors benefit? | | probability of harm? | || | How significantly? | | Severity if occurs? | || +------------------------+ +------------------------+ || | | || +------------+---------------+ || | || v || +------------+---------------+ || | DECISION RULE: | || | Collect only if benefits | || | clearly exceed risks AND | || | no lower-risk alternative | || | achieves same benefit | || +----------------------------+ || |+--------------------------------------------------------------------+Figure 4: Structured risk-benefit assessment for protection data decisions
Quantification of risks and benefits, while imperfect, imposes rigour on assessments. A benefit of “better service targeting” that applies to 3% of cases differently than current approaches has limited value. A risk of “possible identification” that translates to a 0.1% probability of exposure per year with severe consequences requires multiplication: over 10 years with 1,000 survivors in the database, this represents an expected value of 1 person harmed. Whether that expected harm outweighs the aggregate benefit of modestly improved targeting for 30 people depends on severity of potential harm and magnitude of targeting benefit, but the framework forces explicit comparison.
The assessment framework applies at multiple levels: individual data elements within forms, entire data collection instruments, data sharing agreements, and analytical uses of aggregated data. A data sharing agreement with a partner organisation requires assessment of the partner’s security practices, staff vetting, and downstream sharing possibilities. An analytical project using protection data requires assessment of whether findings could enable targeting or whether publication could compromise source communities.
Default positions in risk-benefit assessment favour non-collection. When analysis is uncertain, when benefits are speculative, or when risks are difficult to bound, the precautionary position is to not collect. The burden of proof lies with those proposing data collection to demonstrate net benefit, not with those opposing collection to demonstrate net harm. This default reflects the severity asymmetry: data privacy breaches are difficult to reverse while uncollected data can be collected later if genuinely needed.
Data Minimisation in Protection Contexts
Data minimisation restricts collection to information directly necessary for specified purposes, excluding “nice to have” fields regardless of analytical interest. In protection contexts, minimisation serves both privacy and safety functions. Less data stored means less data at risk in a breach. Narrower data sets reduce re-identification potential. Shorter forms reduce survivor burden and the power dynamics of extensive questioning.
The operational mechanism of minimisation requires explicit justification for each data element. For a GBV intake form, each field must answer: what specific service delivery decision depends on this information? If a field captures information that is “useful context” but does not change any service decision, it fails the minimisation test. Staff members often resist minimisation because comprehensive data feels professionally valuable, but protection contexts require subordinating professional preferences to survivor safety.
Minimisation interacts with consent in important ways. A survivor who consents to data collection for service provision has not consented to data collection for research, advocacy, or donor reporting. Each additional purpose requires either explicit consent or legitimate basis under applicable law. Purpose expansion beyond the minimised scope violates the terms under which data was collected, regardless of whether the original consent form included broad language.
Worked example of minimisation analysis for a protection intake form:
| Proposed field | Service delivery use | Analysis use | Minimisation decision |
|---|---|---|---|
| Name or alias | Case identification, follow-up | None | Collect: necessary for service |
| Age | Service eligibility, appropriate referrals | Demographics | Collect: necessary for service |
| Village of origin | None direct | Geographic analysis | Do not collect: analysis benefit does not justify identification risk |
| Number of children | Dependent care planning | Household composition | Collect: necessary for service |
| Ethnic group | None direct | Demographic breakdown | Do not collect: sensitive attribute with minimal service relevance |
| Perpetrator relationship | Safety planning, referral decisions | Perpetrator analysis | Collect: necessary for safety |
| Perpetrator name | Investigation referral if requested | None | Collect only if survivor wants referral; otherwise do not collect |
| Income level | Material assistance eligibility | Socioeconomic analysis | Collect if material assistance offered; otherwise do not collect |
This worked example shows that minimisation is contextual. A field appropriate when connected to a specific service becomes inappropriate when the service connection is absent. Organisations should maintain different intake forms for different service combinations rather than a comprehensive form that collects everything possibly needed.
Purpose Limitation for Protection Data
Purpose limitation constrains data use to the specific purposes communicated at collection time. Data collected for case management cannot be repurposed for research without additional consent. Data collected for service delivery cannot be shared with law enforcement without legal compulsion. Data collected for one protection programme cannot flow to another programme in the same organisation without explicit authorisation.
The enforcement mechanism of purpose limitation operates through technical and procedural controls. Technical controls include database access restrictions limiting users to data needed for their function, logging of all data access for audit purposes, and system-enforced approval workflows for data exports. Procedural controls include documented purpose specifications for each data collection activity, regular audits comparing actual use against stated purposes, and staff training on purpose boundaries.
+-----------------------------------------------------------------------------------+| PURPOSE LIMITATION MODEL |+-----------------------------------------------------------------------------------+| || COLLECTION PERMITTED USES PROHIBITED USES || CONTEXT || || +---------------+ +-----------------------+ +--------------------+ || | | | Individual case | | Aggregate | || | Case |----->| decisions | | analysis | || | management | +-----------------------+ +--------------------+ || | intake | +-----------------------+ +--------------------+ || | |----->| Supervisor | | Donor | || +---------------+ | review | | reporting | || | +-----------------------+ +--------------------+ || | +-----------------------+ +--------------------+ || +------------->| Quality | | Research | || | assurance | | publication | || +-----------------------+ +--------------------+ || || || +---------------+ +-----------------------+ +--------------------+ || | Monitoring | | Programme | | Individual | || | visit (with |----->| statistics | | case | || | consent for | +-----------------------+ | decisions | || | statistics) | +-----------------------+ +--------------------+ || | |----->| Trend analysis | +--------------------+ || +---------------+ +-----------------------+ | External | || | sharing | || +--------------------+ || |+-----------------------------------------------------------------------------------+Figure 5: Purpose limitation restricting data use to collection-time purposes
Secondary use requests require fresh consent unless a legal basis applies. When a research team requests access to case management data, the organisation cannot grant access based on the original service delivery consent. Options include: returning to survivors for research consent (often impractical), using only properly anonymised data that falls outside personal data definitions, or declining the research request. The inconvenience of these options is the intended effect of purpose limitation.
Donor reporting creates recurring purpose limitation tensions. Donors may request individual-level data or granular breakdowns that exceed what survivors consented to share. Purpose limitation requires organisations to negotiate reporting requirements before data collection, build appropriate consent language into intake processes, or accept that some data cannot be reported to donors. Retroactive consent for donor reporting is ethically problematic because survivors may feel unable to refuse given ongoing service relationships.
Data Responsibility Across the Lifecycle
Data responsibility extends from the decision to collect through ultimate destruction, imposing obligations at each stage. This lifecycle perspective prevents organisations from addressing collection carefully while neglecting storage, sharing, or retention risks.
+-------------------------------------------------------------------------+| DATA RESPONSIBILITY LIFECYCLE |+-------------------------------------------------------------------------+| || COLLECT STORE USE SHARE || +----------+ +----------+ +----------+ +----------+ || | Minimise | | Encrypt | | Authorise| | Consent | || | Consent |----->| Access |----->| Log |----->| Verify | || | Document | | Control | | Audit | | Document | || +----+-----+ +----+-----+ +----+-----+ +----+-----+ || | | | | || +-----------------+--------+--------+-----------------+ || | || v || +-----------+ || | RETAIN | || +-----------+ || | Minimum | || | period | || | Review | || +-----+-----+ || | || v || +-----------+ || | DESTROY | || +-----------+ || | Secure | || | Complete | || | Verified | || +-----------+ || |+-------------------------------------------------------------------------+Figure 6: Data responsibility obligations across the full lifecycle
The collection phase responsibility requires implementing minimisation, obtaining appropriate consent, and documenting the terms under which data was gathered. Documentation must be specific enough to answer future questions about what purposes were communicated and what limitations were agreed.
The storage phase responsibility requires encryption at rest, access controls limiting who can view data, physical security for any paper records, and secure configuration of systems holding protection data. Storage responsibility includes ensuring that data cannot be accessed by unauthorised staff, cannot be extracted through technical vulnerabilities, and would not be readable if storage media were stolen.
The use phase responsibility requires authorisation checks before each access, logging sufficient to reconstruct who viewed what and when, and regular audits comparing access patterns against legitimate purposes. Use responsibility includes preventing authorised staff from accessing data outside their case assignments and detecting anomalous access patterns that might indicate misuse.
The sharing phase responsibility requires verifying that sharing is permitted under original consent terms, that the recipient has appropriate security practices, and that the transfer is documented for audit purposes. Sharing includes any disclosure to external parties: other organisations, government agencies, researchers, or donors.
The retention phase responsibility requires defining minimum and maximum retention periods based on service delivery needs and legal requirements, conducting periodic reviews to identify data eligible for deletion, and not retaining data simply because deletion requires effort. Retention responsibility acknowledges that data kept “just in case” accumulates risk without corresponding benefit.
The destruction phase responsibility requires secure deletion methods appropriate to the sensitivity of data, verification that deletion is complete across all copies and backups, and documentation of destruction for accountability purposes.
Implementation Considerations
Protection data principles implementation varies substantially based on organisational context, operating environment, and available resources. The following guidance addresses common implementation challenges across different situations.
For Organisations with Limited IT Capacity
Small organisations or those operating without dedicated IT staff can implement protection data principles through procedural rather than technical controls. Paper-based case files stored in locked cabinets with sign-out logs provide adequate security for many contexts. Access control through physical keys assigned to authorised staff substitutes for electronic permissions. Spreadsheet-based case tracking with password protection, while not enterprise-grade, exceeds no protection at all.
The key minimum practices for limited-capacity implementation: explicit consent conversations documented in case notes; locked storage accessible only to protection staff; no sharing of individual case information by email or messaging; annual review of files with destruction of those beyond retention period; staff understanding of what information can and cannot be shared with external parties.
For Organisations with Established Protection Programmes
Organisations with dedicated protection teams and IT support should implement technical controls reinforcing procedural ones. Case management systems with role-based access control limit visibility to assigned cases. Audit logging tracks all access for subsequent review. Encrypted databases protect against breach exposure. Automated retention management flags cases for review and schedules destruction.
These organisations should conduct annual risk assessments of their protection data holdings, identifying changes in operating environment that might affect the risk profile of stored data. Data that was safe to retain last year may require deletion if security conditions have deteriorated.
For Organisations Operating in High-Risk Environments
Operations in contexts with active conflict, authoritarian governance, or targeting of humanitarian actors require additional measures. Data minimisation should be extreme: collect only what is essential for immediate service delivery with no analytical fields. Retention should be short: delete case data within 90 days of case closure unless the survivor specifically requests retention. System security should assume compromise: design data architectures such that access to one component does not expose the full dataset.
Consider whether digital case management systems are appropriate at all in highest-risk contexts. A paper file system with physical security may carry lower risk than a database that could be copied wholesale if devices are seized. If digital systems are used, implement device-level encryption, remote wipe capability, and offline-capable systems that minimise data stored on servers accessible from networks.
Implementing Survivor-Centred Practice
Survivor-centred practice requires staff culture change alongside technical measures. Staff must genuinely believe that survivors have the right to control their data and must not resent survivor decisions that limit organisational convenience. Training should address staff members’ own feelings about data control, help them recognise when they are exerting subtle pressure, and provide language for genuinely voluntary consent conversations.
Organisations should establish mechanisms for survivors to exercise their rights in practice. A clear point of contact for data requests, a defined process for reviewing records, documented procedures for restricting or deleting data, and realistic timeframes for responding to requests demonstrate that survivor rights are operational rather than theoretical.
Field Deployment Considerations
Field contexts present specific implementation challenges. Connectivity limitations may prevent real-time access to centralised consent documentation, requiring offline-capable consent forms and local record-keeping synchronised when connectivity permits. Power constraints may limit encryption and automated control options, requiring procedural compensations. Staff turnover typical of field contexts requires continuous training investment rather than one-time orientation.
Mobile data collection introduces additional risks. Devices may be lost, stolen, or confiscated. Collection applications should minimise data caching, require authentication for each session, and support remote data deletion. Collected data should synchronise to secure systems at every connectivity opportunity rather than accumulating on devices.
Cross-border data transfer questions arise frequently in humanitarian operations. Data collected in one country may need to transfer to headquarters or regional offices in another. Transfer mechanisms must comply with both source and destination country requirements, which may include standard contractual clauses, binding corporate rules, or consent-based transfers depending on jurisdiction.