Link Search Menu Expand Document
Responsible data management toolbox

6.8 Retain, Archive, Delete


Case study: excessive retention of data

The situation

A focal point from HQ visits the isolated base of a field mission. The latter is far from the capital, difficult to access. In one of the offices that he visits, he discovers a significant number of papers stacked in multiple file cabinets. Between the different folders, loose sheets, binders, more than 6 cabinets are filled.

The local teams explain that these archived papers represent not only all of the field surveys, but also the various assessment missions, the lists of beneficiaries of activities carried out in the last projects, etc.

He is told that given the particularly humid climate of South-East Asia, it was made clear to them and repeated that it was crucial to keep all the proof of project completion safe and secure, to be able to justify the figures and activities carried out in a project in the event of a subsequent donor audit.

One may joke about the fact that the example highlights a situation where paper is used, but we must remember that in some contexts, it is relevant to keep paper collection procedures, and it is not because our practices are increasingly dematerialised that we are better protected/more organised. On the contrary, there is a general tendency to collect even more since “this does not take up space”.

The HQ focal point thereby wonders how to rationalise the retained data somewhat.

What are the potential risks?

  • Personal and sensitive data easily accessible as it is not secure
  • Risk of loss and destruction of data in case of fire or flood
  • Waste of time if a detailed inventory is needed or key documents need to be found quickly
  • Risk that this bad habit will anchor itself in team practices and become de facto a model of data retention without an archiving and destruction policy.

What to do?

In this type of situation, the first thing to do is to make an inventory and identify the documents and the type of data they contain, and to which projects they are attached. Also identify the donors involved in these projects and any audit procedures that are in place.

Despite appearances it is possible that there has already been a form of selection of archived documents. In this case, it is a question of trying to understand on what criteria this was carried out.

If a selection is required as a result of this inventory, it is important to define retention rules for all these documents: What do you really need in terms of auditing (and for how long)? And in terms of program monitoring? Organisational memory? Does part of the documents need to be digitized? Once this initial sorting is done, organise the destruction of the associated data.

How could the situation have been avoided?

One of the keys to preventing this type of situation from happening is that all relevant employees in your organisation are aware of the concept of minimisation and that the data collected during the various collections are really the data that will be used - without data being collected “just in case”/”for later”.

In addition, ensure that the benefits of both paper and paperless are known and understood. Refer to this resource in the mobile data collection toolbox to discuss it with your teams as needed.

Digitalisation (and even more broadly the creation of tools) is not the solution to all your problems (see this guidance on this topic), so always ask yourself the question of the relevance of the collection more widely!

Regarding the retention of data collected over time, after completion of a project, the often-used argument of potential subsequent donor requests must be put into perspective - it is never necessary to keep all files/documents related to a project. Sort out what is contractual (and thus review contracts if necessary), necessary (data from relevant past projects for example), interesting (outcomes of needs assessments for areas in which the NGO has not yet worked), and superfluous (all data from the post-distribution satisfaction questionnaire) to know what to do with what data.

Indeed, it is essential to align data retention rules across the organisation (and then apply it to the projects themselves): What do you really need in terms of auditing (and for how long)? And in terms of programs/organisational memory? Once this sorting is done, implement a real policy of systematic destruction, both for paper documents and for electronic documents. This procedure must be disseminated and known by all staff, and a timetable must be established to monitor compliance with the procedures in place on a regular basis. The final step is to systematise this procedure, and integrate it into a properly defined archiving policy

More generally, archiving, destruction, or retention must not be an isolated action, following an inspection, oversight, or discovery (as in the case of our example), but must be part of a data management cycle instituted in an organisation’s policy.

Case study: evacuation of the field team and sensitive data to be deleted

The situation

Due to the escalation of a conflict, the field team working with a population using narcotics and at risk of addiction, is forced to evacuate in an emergency. There is no contingency plan to allow the team to respond to this kind of situation in terms of how to manage the destruction of paper and electronic documents, some of which contain sensitive data such as names, addresses and certain medical information related to addiction. In particular, it is likely that, in the confusion and general chaos of the situation, local community workers have kept in their possession some of the beneficiaries’ case management papers.

What are the potential risks?

  • The program beneficiaries could be targeted, with risks of stigma and potentially retaliation
  • Social workers could also be stigmatised if they are apprehended by the authorities with case-monitoring records of populations using narcotics
  • If activities are planned as part of a future project, these could be compromised
  • Reputational risks, loss of confidence of these populations vis-à-vis your NGO and the sector in general
  • Personal and sensitive data accessible by third parties, which is not in accordance with humanitarian and data protection principles

What to do?

The short-term strategy should be to:

  • List as much as possible and evaluate all data that has not potentially been erased and what it represents in terms of risks to understand the consequences on people
  • Contact social workers and ask them to destroy all documents in their possession. It may be necessary to go with them so that the destruction is carried out correctly, without the possibility of data being recovered and without risk to their people
  • Inform the persons concerned of the nature of the incident and the potential risks
  • Define if some of these data are locatable, accessible and erasable (difficult to perform remotely, a field mission may be required)
  • Quickly implement corrective mitigation measures to protect the data and the people

How could the situation have been avoided?

In contexts with a risk of rapid political changeover and chronic instability, it is important to anticipate as much as possible (for example over 3 years) the potential security risks in areas identified as sensitive by carrying out a risk analysis.

Following this analysis, set up a contingency plan to provide a framework and guide the teams that find themselves facing this type of situation, which requires the deletion of data in an emergency. In situations like this, the security of individuals is of course paramount, and information management may be very low on the list of priorities and “fall by the wayside.” It is therefore all the more important to have a clear and precise protocol with which the teams are familiar so that they do not discover it upon having to apply it.

In terms of anticipation, try to make sure that data flow mapping not only exists but is also regularly updated. Having a procedure for archiving and destroying sensitive data that follows a schedule adapted to your project and / or organisation will allow, along the way, to minimise the amount of data that is retained. Indeed, in the event of an evacuation situation, the less data to erase, the better.

If certain data needs to be kept for the duration of the project, make sure that “off-site/online” backups are regularly performed (using secure means) to have as little data as possible locally.

Case study: too much time between project completion and when data is deleted

The situation

One year after the end of a project related to child protection in the Sahel, the donor informs you that an audit is planned to determine whether contractual obligations have been met. As the project manager has left the organisation, it is your responsibility to prepare this audit. You discover that all digital documents related to the project have been stored on an unprotected external hard drive as well as on the servers of an online storage service provider. How do you proceed?

What are the potential risks?

  • Personal and sensitive data accessible whereas the need does not exist
  • Risk of forgetting that these documents exist and loss of time when, eventually, it becomes necessary to erase this data because the members of the team having worked with these documents have gone and the collective memory on the importance of this data no longer exists.
  • Risk of developing a bad habit in data retention practices without an archiving and destruction policy.

What to do?

Start by making an inventory of the documents, the data they contain and assess whether they contain personal and sensitive information. Then proceed to the destruction of documents and data that do not need to be retained because they are unnecessary from a contractual point of view or for learning purposes.

How could the situation have been avoided?

The steps that must take place at the end of the data lifecycle are often overlooked, either because there is no procedure to follow, or because they are considered non-essential (or simply due to a lack of time). In terms of data retention, archiving and destruction, asking the right questions upstream, from the initial design of monitoring and evaluation methods, will deliver tangible benefits because the question of retention of the collected data will be integrated into the life cycle of said data. There are no fixed rules because these steps obviously depend on the context (which can evolve drastically), needs and existing structures (both internal and external to the organisation). In general, starting by mapping the places where the data is stored gives you a chance to reflect on their nature and on who has access to it.

In order to develop a data retention, archiving and destruction plan that is adapted to the needs and more easily adopted by the teams involved in the projects, it is recommended to consult the latter to better understand their needs, those of the donors and the legislation in force. The aim is to create a data destruction management system including a timetable, which while offering accuracy remains flexible to accommodate changing needs.

This is described in the document ‘Becoming RAD How to retain, archive and dispose of data responsibly’ produced by the Engine Room: It is about “combining responsibility with flexibility, seeking to create to create spaces for learning and reflection, while maintaining (and adapting!) an information management system that works for the whole team.”

Key resources

  • To implement such a policy, you can draw inspiration from the RAD documentation produced by the Engine Room and translated into French by CartONG. This will give you concrete elements for each step of the RAD cycle (Retain => Retention , Archive => Archiving, Destroy => Destruction).
  • This MERL Tech blog post can also give you an overview of the subject