Data policy

An OpenBioMaps project should have a documented data policy describing how data are collected, managed, reviewed, accessed, shared, retained, and eventually archived or deleted. The policy helps contributors, project administrators, data users, and external partners understand what they may expect from the project and what responsibilities they have.

This page provides a framework for preparing a project-specific data policy. It is not itself a complete policy and does not constitute legal advice. The appropriate rules depend on the purpose of the project, the organisations involved, the categories of data being processed, the server operator, and the applicable law.

The technical access settings of an OpenBioMaps project should implement the published policy, but they do not replace it. Conversely, a policy must not promise restrictions, retention periods, backups, or services that are not actually implemented and regularly verified.

For information about configuring technical permissions, see Data access.

Relationship to other documents

A project data policy may be accompanied by several related documents. Their scope should be distinguished clearly.

Data policy

Describes the governance and lifecycle of project data, including collection, quality control, access, reuse, retention, and responsibilities.

Privacy notice

Explains how personal data are processed, identifies the relevant controller or controllers, and informs data subjects about their rights.

Terms and conditions

Define the contractual rules for using the server, project, application, or related services.

Cookie notice

Describes cookies or similar browser-side technologies used by the web application.

Licence or data-use agreement

Defines what recipients may do with data and any conditions attached to access or reuse.

Contributor agreement

Defines what a contributor is authorised to submit and what permissions they grant to the project.

One document can cover more than one of these subjects, but each rule should have a clear scope. Server-wide terms do not automatically define the governance policy of every project hosted on that server.

The public OpenBioMaps service provides examples of terms and conditions, a privacy notice, and a cookie notice. These documents are examples for a particular service and must not be copied to another server or project without checking the organisations, processing operations, jurisdiction, dates, and contact details.

Preparing a project data policy

A data policy should be prepared before routine data collection begins. It should be reviewed whenever the project purpose, database structure, access model, participating organisations, external integrations, or legal requirements change.

The policy should be written in language that its intended users can understand. If a project operates in several languages, the policy should state which version is authoritative and how translations are maintained.

At a minimum, the policy should answer the following questions:

• What is the project for?

• Which data does it collect?

• Who operates the project and who can be contacted?

• Who is authorised to submit, view, modify, validate, export, or publish data?

• How is data quality assessed and documented?

• Which records or fields are sensitive?

• Under which conditions can data be reused?

• How should the project and its contributors be cited?

• How long are data, attachments, logs, and backups retained?

• How can errors, rights concerns, security incidents, or removal requests be reported?

• How and when can the policy be changed?

Scope and purpose

The policy should begin by identifying the project and defining its purpose. This helps determine which data are relevant and prevents data collected for one purpose from being used silently for an incompatible purpose.

The scope should include:

• the public name and database identifier of the project;

• the scientific, conservation, educational, or operational purpose;

• the geographical, taxonomic, and temporal scope;

• the data tables and major data categories covered;

• the web, mobile, API, and external-client interfaces covered;

• any related databases or services;

• the intended users and beneficiaries; and

• activities that are explicitly outside the scope of the project.

If the project has experimental, test, and production environments, the policy should clarify which environments contain real data and which rules apply to each one.

Definitions

Terms used in the policy should be defined consistently. Depending on the project, useful definitions may include:

Project

The OpenBioMaps database, its configured interfaces, and the associated data-management workflow.

Server operator

The organisation responsible for operating the OpenBioMaps server and its underlying infrastructure.

Project operator

The person or organisation responsible for governing a particular project.

Contributor

A person or organisation that submits data to the project.

Data owner or rights holder

The person or organisation holding specified rights in submitted data. The exact meaning should be defined rather than assumed.

Data steward

A person responsible for maintaining data and metadata according to the project policy.

Validator or curator

A person authorised to review, annotate, accept, correct, or reject submitted data.

Data user

A person or application that views, queries, downloads, or otherwise processes project data.

Record

A row or logically connected set of rows representing an observation, event, taxon, location, sample, or other project entity.

Attachment

A file associated with a record, such as a photograph, sound recording, document, or data file.

Metadata

Information describing the project, its tables and columns, a data set, an upload, or an individual record.

Personal data

Information relating to an identified or identifiable person, as defined by the law applicable to the relevant processing operation.

Sensitive biodiversity data

Data whose disclosure could create a risk to a species, habitat, protected area, landowner, contributor, research activity, or conservation action.

Definitions should not imply that a project has acquired ownership of data merely because it stores them. Copyright, database rights, confidentiality obligations, employment agreements, and other rights can apply differently in different jurisdictions.

Governance and responsibilities

A project can involve several organisations and administrative levels. Responsibilities should be assigned explicitly rather than inferred from technical permissions.

The policy should identify responsibility for:

• operating and securing the server;

• governing the project;

• defining the database structure and metadata;

• approving contributors and group membership;

• creating and maintaining upload forms;

• reviewing data-access rules;

• validating and correcting records;

• responding to data-subject and rights-holder requests;

• reviewing export or data-access requests;

• maintaining licences and attribution information;

• backups, restoration, and disaster recovery;

• incident response;

• retaining or deleting data;

• maintaining external integrations; and

• reviewing and publishing policy changes.

Administrative access should follow the principle of least privilege. For example, user managers need not automatically receive permission to execute SQL, edit background jobs, or export all attachments.

For an overview of assignable administrative functions, see Administrative settings.

Data collection

The policy should describe which data can be submitted, by whom, and through which interfaces. OpenBioMaps projects may accept data through web forms, file uploads, mobile applications, the API, direct database connections, or automated imports.

For each collection workflow, document:

• the purpose of the collection;

• the expected data source;

• required and optional fields;

• permitted file and attachment types;

• applicable validation rules;

• required attribution and provenance;

• the legal or organisational authority to submit the data;

• whether anonymous or unauthenticated submission is allowed;

• the initial access classification of new records; and

• what happens when a submission is incomplete or rejected.

Contributors should submit only data that they are authorised to provide. This includes checking rights and confidentiality obligations associated with photographs, sound recordings, reports, data copied from another database, and information about identifiable people.

Upload forms are described in Upload form management.

Metadata and provenance

Data should be accompanied by enough metadata to make their meaning, source, quality, and permitted use understandable.

Project-level metadata should normally include:

• the project title and description;

• responsible organisations and contacts;

• geographical, temporal, and taxonomic coverage;

• data collection methods;

• quality-control processes;

• access and reuse conditions;

• licences;

• preferred citations; and

• update frequency.

Table- and column-level metadata should explain the meaning, units, allowed values, coordinate reference systems, taxonomic conventions, missing-value representation, and any transformations applied to the data.

Record- or upload-level provenance may include:

• the contributor or source organisation;

• the collector or observer;

• the original record identifier;

• the submission and observation dates;

• the upload form or import process used;

• the source data set and its version;

• transformations performed during import;

• validation status; and

• links to derived or superseded records.

Descriptions entered for database tables and columns form part of the project metadata. See Database tables and columns.

Data quality and validation

The policy should explain that storing a record does not necessarily confirm its correctness. It should define the available validation states and who may assign or change them.

Quality controls may include:

• required-field and data-type validation;

• controlled lists and range checks;

• taxonomic-name validation;

• date and coordinate consistency checks;

• duplicate detection;

• verification of coordinate reference systems;

• review of attachments or supporting evidence;

• expert identification;

• automated spatial or temporal checks;

• comparison with external reference data; and

• contributor or reviewer comments.

Corrections should preserve relevant provenance. Where feasible, the project should distinguish the originally submitted value from a later normalisation, interpretation, or correction.

Published data should carry appropriate qualifications. The absence of a warning or validation flag must not be presented as a guarantee of accuracy, completeness, fitness for a particular purpose, or current taxonomic interpretation.

Access and disclosure

The policy should state which data are public, restricted to authenticated users, restricted to groups, available only after approval, or accessible only to project administrators.

OpenBioMaps can combine:

• project-level access settings;

• row-level access rules;

• column-level restrictions;

• group membership;

• administrative roles; and

• export-authorisation workflows.

The effective technical configuration should be tested using accounts representing each relevant user group and, where public access is enabled, without authentication.

For details of the available controls, see Data access.

The policy should distinguish among:

• discovering that a record exists;

• viewing a record on a map;

• viewing its attributes;

• viewing its exact geometry;

• querying and filtering it;

• downloading it;

• viewing or downloading attachments;

• modifying or deleting it;

• obtaining it through the API;

• accessing it through SQL or an external application; and

• receiving it through an approved data request.

These actions can expose different amounts of information and need not have the same permissions.

Sensitive biodiversity data

Exact locations, collection methods, observer identities, or other attributes can create risks for threatened species, habitats, landowners, contributors, and conservation activities. A project should define how such risks are assessed and which protections are applied.

Possible protections include:

• withholding selected fields;

• restricting entire records to specified groups;

• hiding exact geometry from public users;

• publishing generalised coordinates;

• delaying publication;

• requiring individual approval for exports;

• separating public and restricted attachments; and

• recording a reason and review date for the restriction.

Restrictions should be proportionate, documented, and reviewed. A record should not remain restricted indefinitely merely because its status has never been reassessed.

The rules table supports sensitivity-related values such as sensitive, restricted, no-geom, and only-owner in some project configurations. Their exact behaviour must be verified before relying on them.

Personal data and privacy

Biodiversity data can contain personal data even when the project is not primarily intended to collect information about people. Examples may include:

• contributor, observer, collector, validator, and photographer names;

• email addresses and user profile information;

• precise locations linked to a person’s home or movements;

• mobile-application tracklogs;

• photographs, sound recordings, and free-text notes;

• IP addresses and application logs;

• record ownership and edit history; and

• comments or evaluations associated with users.

The applicable privacy notice should identify the relevant controller or controllers, processing purposes, legal bases, data categories, recipients, retention periods, international transfers, security measures, contact details, and data-subject rights as required by the applicable law.

The project data policy should refer to the applicable privacy notice rather than attempting to replace it. Statements about legal bases and statutory rights should be reviewed by a qualified person for the relevant jurisdiction.

Special care is required where data concern children, vulnerable people, private residences, employee monitoring, continuous location tracking, or special categories of personal data.

Rights, licences, and permitted reuse

The policy should state what rights contributors must have in submitted data and what permissions they grant to the project. It should also state the licence or other conditions under which recipients can reuse data.

Different rights may apply to:

• individual observations;

• compiled databases;

• photographs and sound recordings;

• reports and other attachments;

• taxonomic or geographic reference data;

• map tiles and base maps;

• metadata;

• software and form definitions; and

• content imported from an external source.

A project should not describe data as open unless recipients have clear permission to reuse them. Public visibility alone is not a licence.

Where several licences apply, exports should preserve enough information to determine the applicable licence and attribution for each record or attachment. Incompatible source licences should not be combined under a new licence without permission.

Citation and attribution

The policy should provide a preferred citation for the project and explain how contributors, source organisations, data sets, and OpenBioMaps should be acknowledged.

A citation should normally identify:

• the data publisher or responsible organisation;

• the project or data-set title;

• the OpenBioMaps server or repository;

• a version, publication date, or query date;

• the date of access;

• a persistent identifier, where available; and

• the applicable licence.

Where a data set or saved query has a DOI or another persistent identifier, that identifier should be preferred over a URL that may change.

Record-level attribution should be preserved when required by the applicable licence or contributor agreement. Users should not be instructed to publish personal contact details unnecessarily.

Data requests and exports

Some projects require users to request permission before downloading restricted data. The policy should describe:

• who may submit a request;

• what information the requester must provide;

• which criteria are used to decide;

• who makes the decision;

• expected response times;

• permitted and prohibited uses;

• required security measures;

• whether onward sharing is allowed;

• expiry and deletion requirements;

• reporting and citation requirements; and

• the process for appeal, amendment, or renewal.

Decisions should be consistent and recorded. Exported files should contain only the approved records and fields, and their download links should be protected and expire after an appropriate period.

Sharing and external integrations

Data may leave the OpenBioMaps web interface through downloads, APIs, direct SQL connections, QGIS, R, mobile clients, background jobs, interconnection services, or publication to external repositories.

The policy should identify regular data recipients and integrations, the data sent to them, the purpose, applicable access controls, update frequency, licences, and deletion or correction process.

Automated publication should not expose fields that would be hidden from the same user through the web interface. Credentials used by integrations should be assigned only the required permissions and should be rotated or revoked when no longer needed.

Retention, deletion, and archiving

The policy should define retention periods or review criteria for all major information categories, including:

• active project records;

• rejected and withdrawn submissions;

• record history;

• taxonomic and validation annotations;

• user accounts and profiles;

• invitations and group membership;

• interrupted uploads and temporary files;

• attachments and generated thumbnails;

• comments, evaluations, and messages;

• data-access requests and decisions;

• generated exports and download links;

• application and server logs;

• background-job logs;

• API tokens and sessions;

• backups; and

• archived project versions.

Deletion from the active database does not necessarily remove information from backups, external exports, logs, caches, or copies previously obtained by users. The policy should explain these limitations accurately.

Where long-term scientific reproducibility requires preservation, deletion may need to be replaced by restriction, pseudonymisation, withdrawal, or publication of a tombstone record. Such decisions should be based on a documented legal and scientific assessment.

Backups and restoration

A data policy should distinguish backups from archives.

A backup is maintained primarily to restore a system after accidental loss, corruption, or technical failure. An archive is retained for long-term preservation and continued interpretation of data. A backup is not a substitute for a documented archive, and a successful backup job does not prove that restoration will work.

The policy should state:

• which database objects and files are backed up;

• whether attachments are included;

• backup frequency;

• retention period;

• storage location and geographical jurisdiction;

• encryption and access controls;

• responsibility for monitoring backup success;

• restoration priorities and expected time frames;

• restoration testing frequency; and

• what happens to deleted or restricted data in retained backups.

The available example terms state that SQL project tables on certain OpenBioMaps services are backed up daily and retained for two weeks, while attachments are excluded. This must not be presented as a general OpenBioMaps guarantee without verification for the server in question.

Security and incident response

The policy should summarise the organisational and technical measures used to protect data without publishing information that would itself weaken security.

Relevant controls may include:

• encrypted network connections;

• secure authentication and session handling;

• least-privilege group and administrative access;

• protected database and API credentials;

• server and dependency updates;

• logging and monitoring;

• backup protection;

• restrictions on executable background jobs;

• file-type and attachment controls;

• periodic access reviews; and

• vulnerability and incident management.

A documented incident procedure should define how suspected unauthorised access, accidental publication, data loss, malicious uploads, compromised credentials, or incorrect access rules are reported and handled.

Changes to the policy

The policy should contain a version number, publication date, effective date, responsible editor, and change history. Material changes should be communicated before they take effect where required.

The project should define:

• who can approve a policy change;

• how affected users are notified;

• whether renewed acceptance is required;

• how acceptance is recorded;

• how previous versions remain accessible; and

• what happens if a contributor or user rejects the new terms.

Changes to technical access settings, licences, retention periods, purposes, or responsible organisations should trigger a policy review.

Suggested project-policy structure

A project-specific policy can use the following structure:

1. Document information — title, version, owner, approval date, effective date, and review date.

2. Project identity and purpose — project name, server, scope, and intended use.

3. Contacts and responsibilities — server operator, project operator, data steward, and request contacts.

4. Definitions — project-specific terminology.

5. Data collected — records, metadata, attachments, provenance, and personal data.

6. Submission rules — authorised contributors, accepted sources, and contributor responsibilities.

7. Quality management — validation, correction, history, and qualifications.

8. Access classification — public, authenticated, group-restricted, sensitive, and embargoed data.

9. Rights and licences — contributor permissions and recipient reuse.

10. Citation and attribution — preferred citations and persistent identifiers.

11. Requests and external sharing — exports, integrations, and approval workflows.

12. Retention and archiving — active retention, deletion, backups, and project closure.

13. Privacy and security — references to the privacy notice and incident process.

14. Complaints and requests — contacts and response procedure.

15. Policy changes — approval, notification, acceptance, and version history.

Implementation checklist

Before publishing a project data policy, the project operator should verify that:

• the project purpose and scope are accurate;

• responsible organisations and contacts are current;

• technical roles match the stated responsibilities;

• upload forms collect only intended data;

• required metadata and provenance are recorded;

• validation states and quality statements are understandable;

• public, authenticated, and group access have been tested;

• map, query, API, export, attachment, and SQL access behave consistently;

• sensitive records and fields receive the intended protection;

• licences and attribution are included in exports;

• personal-data processing matches the privacy notice;

• retention and deletion statements match actual system behaviour;

• backups include the promised database objects and files;

• a restoration test has been completed;

• external integrations are documented;

• incident and request contacts are monitored;

• the effective policy version is available to users; and

• a date has been set for the next review.

A policy should be tested against real workflows rather than reviewed only as text. In particular, administrators should use representative accounts to test upload, query, map, download, API, attachment, correction, and deletion operations.

Open questions

Several areas require confirmation in the OpenBioMaps application and governance model before this page can be considered complete:

• the exact relationship between server operators and project operators;

• the authoritative definitions of project and data-management roles;

• the complete access-resolution algorithm;

• the storage and presentation of licences and policy versions;

• the scope and retention of audit and history information;

• the treatment of personal data embedded in biodiversity records;

• the exact deletion behaviour of each interface;

• backup coverage and restoration guarantees;

• the propagation of corrections and deletions to external systems; and

• the supported lifecycle for closing or transferring a project.