ODK Encryption and Key Management Checklist

An ODK encryption plan has four parts: choose managed or self-supplied keys, protect the secret that can decrypt submissions, test the export path, and document recovery before fieldwork. Encryption protects finalized form data and attachments, but it does not replace HTTPS, device controls, access management, or a tested backup process.

Use this checklist before enabling encryption on a real project. For the implementation steps, see How to encrypt ODK forms.

1. Decide whether encryption is required

Start with the study's data classification and access model:

• What personal, health, protection, financial, or location data is being collected?
• Which people need to read the finalized submissions?
• Should the ODK Central server be able to decrypt data for normal exports?
• Where will the decryption secret be stored, and who can use it?
• What happens if the project needs an urgent export during fieldwork?

Encryption is useful when the server or infrastructure should not be able to read finalized submissions. It also changes the operational workflow: the team must preserve the right key or passphrase, test decryption, and explain how analysis tools will receive readable data.

2. Choose a Central encryption model

ODK Central supports two broad models:

Model	Key custody	Export path	Best fit
Project managed encryption	Central generates the key pair; the team protects the passphrase	Central can decrypt an export when the correct passphrase is supplied	Teams that want a simpler Central workflow and can protect a passphrase
Self-supplied key encryption	The research team generates and protects the private key	Use ODK Briefcase or the appropriate local workflow with the matching private key	Teams that require direct custody of the private key or already use this model

ODK's Central encryption guidance recommends project managed encryption for most cases because it avoids manual key-file handling. Self-supplied keys can still be the right choice when the team cannot trust the Central environment with the key material or needs compatibility with an existing workflow.

Do not mix the models casually. A form that already contains self-supplied encryption settings is handled differently from a form covered by project managed encryption.

3. Protect the secret that decrypts data

For managed encryption:

• Store the passphrase in an approved password manager or another controlled location.
• Make sure the recovery owner can access it during an incident without putting it in a shared chat or project workbook.
• Record a useful hint without recording the passphrase itself.
• Confirm that the passphrase is correct before the first field submission.
• Document who may request and approve a decrypted export.

For self-supplied keys:

• Keep every private key for every published form version that encrypted submissions.
• Never put the private key in the XLSForm, ODK Central, an App User QR code, or a field device distribution bundle.
• Store an encrypted backup of the private key separately from the live server and the submission exports.
• Record which public key and form version belong to each private key.
• Do not replace an old private key until all submissions that use it have been securely decrypted or are outside the retention period.

Use the ODK encryption key generator only for the self-supplied-key workflow. The encrypted forms guide explains where the public key belongs and how to use the matching private key later.

4. Test the full encrypted workflow

Use a test project or clearly labelled practice form before deployment:

1. Enable the selected encryption model.
2. Download the updated form to the same ODK Collect device type used in the field.
3. Complete and finalize a practice interview with representative answers and attachments.
4. Confirm the submission reaches Central while the server view shows only the metadata permitted by the encryption model.
5. Export the practice record using the intended Central or Briefcase workflow.
6. Decrypt it with the stored passphrase or matching private key.
7. Check the readable output, repeat tables, attachments, audit data, and instance ID.
8. Record the result and the people who can repeat the procedure.

Self-supplied encrypted submissions are not a normal OData workflow. ODK Central's encryption API guidance notes that OData returns only basic metadata for encrypted submissions, so test the actual analysis path instead of assuming a dashboard connection will work.

5. Plan form changes and key rotation

Enable project managed encryption before devices are in the field when possible. Central updates the affected form versions, so devices may need to download the updated form before they can submit successfully.

When a form changes:

• Record the form version and encryption model.
• Keep the old private key if earlier submissions used it.
• Test a new submission and a historical submission separately.
• Confirm the export can still produce the data the analysis team needs.
• Tell enumerators whether they need to update or re-download the form.

Key rotation is not the same as reusing a password. Treat each public and private key relationship as a versioned recovery dependency.

6. Include encryption in backups and review

An encrypted database backup is not the same as a readable research archive. Keep the encrypted backup, form definitions, submission exports, media, audit data, project documentation, and key or passphrase recovery instructions according to the study's retention policy.

Follow the ODK Central backup checklist and test restoration in a controlled environment. Then use the ODK submission review checklist to document what was received, exported, reviewed, and retained.

SurveyLoopr can manage the ODK Central hosting layer, but your team remains responsible for choosing the encryption model, controlling keys and passphrases, authorizing decrypted exports, and testing recovery. Review the hosting and data-processing terms for sensitive studies before procurement.

Deploy a managed ODK server

Configure encrypted ODK forms