dMRV data ownership: who controls your monitoring records?
dMRV data ownership is the question of who controls the records a digital monitoring system holds about a carbon or nature project: who may alter them, and who may see them or take them elsewhere. In most projects no single party owns that data by default. Contracts between the developer and the communities settle it, along with the platform's terms. What you can test before the first survey goes out is control. In community-led dMRV, the people collecting the data are often the people it describes, so those controls carry extra weight.
This guide breaks ownership into four practical questions and shows how one platform answers them in its published documentation. It ends with a checklist for your data agreement.
What dMRV data ownership means in practice
Ownership in the legal sense is about rights in a database and what the contracts say. Day to day, the questions are about control. A monitoring dataset usually holds several kinds of material:
Field observations, such as species records or meter readings.
Evidence files attached to those observations: photos and recordings.
Location data, from single GPS points up to whole site boundaries.
Personal data such as names in household surveys.
Derived results calculated from the raw records, for example diversity indices or SDG scores.
Several parties have a fair claim on this material. Community members collect it, and much of it describes their land and households. The project developer designs the surveys and runs the project. The validation and verification body (VVB) needs independent access to check the work. The platform stores everything, and outside services may process parts of it, such as photos sent for species identification. Buyers want to see the evidence behind what they pay for.
A clause saying "the developer owns all data" settles none of the questions a verifier or a community will ask. It does not show whether records could have been edited after the fact. Nor does it tell a household whether its survey answers can be published. That is why it helps to split ownership into controls you can inspect.
Why dMRV data ownership is now an integrity question
On 22 September 2026 the Integrity Council for the Voluntary Carbon Market (ICVCM) published a report on integrity requirements for dMRV, produced in a work programme it co-facilitated with the World Bank. ICVCM says the report "examines issues such as data ownership, privacy, Free, Prior and Informed Consent (FPIC)". Part of that work is about "ensuring that digital tools and technologies do not undermine the rights, interests and participation of Indigenous Peoples". The report also suggests that crediting programmes "explicitly address cybersecurity and data integrity within their anti-fraud frameworks".
The report sets out findings and recommendations. It is not a rule projects must follow today. Due diligence is moving the same way, though: the International Biochar Initiative's guide to digital MRV lists data ownership among its "Nine key evaluation criteria for assessing any dMRV system".
Two frameworks from outside carbon markets give a useful vocabulary. The FAIR principles, published by Wilkinson and colleagues in Scientific Data in 2016, ask that research data be easy to find and reuse. The CARE Principles for Indigenous Data Governance were released by the Global Indigenous Data Alliance and described by Carroll and colleagues in the Data Science Journal in 2020. GIDA presents CARE as a complement to FAIR. Data should be reusable, and the people it comes from keep a say in that reuse.
Four questions to ask any dMRV system
Question | Why it matters | What a good answer looks like |
|---|---|---|
Who can change or delete a record? | If records can be edited quietly, nobody can show what was collected in the field | Deletion is blocked on the server; faulty records are set aside with a reason and the original is kept |
Who can read the raw data? | A verifier who sees only the developer's reports depends on the developer | A read-only verifier role with direct access to records and media |
Who can take the data out, and in what form? | A dataset that lives inside one vendor's system is hard to re-check or move | Raw record exports in open formats such as CSV and JSON |
Who agreed, and to what? | Community data includes personal and sometimes culturally sensitive information | Consent recorded at collection, written limits on reuse, and a channel to object |
Change and delete. Ask the provider where deletion is blocked. A rule inside the phone app is weaker than a rule enforced on the server, because anyone with database access can go round the app. Then ask how corrections work. A good system flags a faulty record and keeps the original. The audit trail then shows what was collected and why it was set aside.
Read access. Find out whether the verifier gets its own login and what it can see. Reports and dashboards are summaries. The verifier also needs the underlying submissions, including any that were archived.
Export. Ask for a sample export before you sign. Check that it holds individual records with their timestamps and locations, and that the format opens in ordinary tools. An export is also how a community or a new partner can hold its own copy.
Consent. Ask what personal data the system stores and who can see names. Ask how a member can raise a concern without exposing themselves. Then make sure your consent process explains the answers in the community's own language.
How CitizenClimate answers the four questions
CitizenClimate publishes its rules in the Data Integrity & Methodology Protocol, written for VVBs (October 2026, app version 1.25). What follows describes those documented rules, not results from any project.
Change and delete. The Protocol states: "Submissions can never be deleted." The block sits in the database's security rules on Google's servers and applies to every role in the project. A project developer who thinks a submission is wrong can only archive it, with a reason from a fixed list: Duplicate submission, Incorrect data, Test submission, Incomplete submission, Fraudulent entry or Other. The original answers and photos stay in place. Editing a survey never changes data already collected. Community members cannot archive their own submissions.
Read access. The app has three roles, and the VVB role is read-only. According to the Protocol, VVBs have direct read access to all project data and do not rely on reports generated by the project developer. That covers archived submissions with their reasons, as well as AI species identifications and grievances.
Export. Project developers can export the raw data for any survey as JSON or CSV. The dashboards for SDG scores and biodiversity have their own exports in the same two formats (App Guide). The Protocol says all CSV and JSON exports include raw records rather than summaries alone. For projects enrolled in the Plan Vivo (PV Nature) module, each metric run also produces an audit bundle: a .zip with the data, code and results, so an auditor can re-run the calculation. CitizenClimate's data is structured to align with the monitoring requirements of Verra VCS, Gold Standard, Plan Vivo, Puro.earth and Carbon Standards International. CitizenClimate is not certified, accredited or endorsed by any standard body, and it does not issue credits.
Where the data lives. The platform is built on Google Firebase, and data is encrypted in transit and at rest. The field data collection app works offline. Submissions are saved to a local encrypted database on the phone and sent when a connection returns. The original field timestamp is kept, and the sync date is recorded separately.
Consent and personal data. Before a survey starts, the member ticks a box to confirm they agree to take part. Grievances cannot be deleted, and the member's name is not shown to the project developer or to other members.
Some personal data is visible by design, and your consent process should say so. Each species observation stores the observer's name. The leaderboard ranks members by points and shows each person's community. Photos and recordings sent for identification go to independent third-party AI services.
Members can delete their account from their profile. The App Guide does not describe how a deleted account's past submissions are handled, so ask us before you write that into a consent form.
None of this decides legal ownership. That belongs in the agreements between the developer and the communities, and in the platform terms you accept. The controls above make those agreements easier to check.
Community consent and Indigenous data governance
A tick box at the start of a survey records agreement to that survey. It is not Free, Prior and Informed Consent for the project. FPIC is the project developer's responsibility, and CitizenClimate does not offer a dedicated FPIC module. What the platform can do is keep the monitoring side consistent with what the community agreed to.
The CARE principles turn into practical choices:
Collective benefit. The Protocol says all three roles can see the same underlying records, and community members open the SDG and biodiversity dashboards in the same app. Show the community what its data says, in one of the app's 11 languages.
Authority to control. Agree in writing which fields may be published and who signs off. The site says verified data can be shared publicly through dashboards with personal information anonymised. What gets shared should be the community's decision as much as the developer's.
Responsibility. Explain how data is used and who receives exports.
Ethics. Every observation can carry a GPS point, and exports include coordinates. Think before publishing the locations of threatened species or sacred sites.
For more on how community monitors work alongside verifiers, see our page on community-based monitoring.
What to write into your data agreement
Use this list when you draft or review the data clauses of a project:
Who holds rights in the raw records, and who holds rights in results derived from them.
Who may read the data while the project runs. Name the VVB, and say how its access is granted and removed.
Export formats and timing, and the right of the community or its representative body to receive a copy.
What personal data is collected and how long it is kept.
How a member withdraws, and what happens to their past records.
Which fields may be published, at what location precision and with whose approval.
Which outside services process photos or audio, and what buyers may see.
How records are corrected (set aside with a reason, never overwritten) and how a member raises a concern.
What happens to the dataset when the project or the contract ends.
For the buyer's side of the same debate, read why dMRV matters for carbon credit quality.
Frequently asked questions
Who owns the data collected in a dMRV project?
There is no default owner. Rights are set by the contracts between the project developer and the communities, by the platform's terms, and by local data protection law where personal data is involved. Write ownership into those agreements explicitly. Then back it with controls you can check, starting with who can change a record and who can take it out of the system.
Can a project developer delete community records in CitizenClimate?
No. The Protocol states that submissions can never be deleted, and the rule is enforced in the database's security rules on Google's servers for every role. A project developer can archive a faulty submission with a reason from a fixed list. The original record stays intact with its photos, and VVBs can see archived submissions with their reasons.
Can a verifier see the raw data without going through the project developer?
Yes. CitizenClimate has a read-only VVB role. The Protocol says VVBs have direct read access to all project data and do not rely on reports generated by the project developer. That includes archived records and the photos behind each submission, so the verifier can check the evidence itself rather than a summary of it.
Can I export my project data from CitizenClimate?
Yes. Project developers can export each survey's submissions as CSV or JSON. The dashboards offer the same two export formats. The Protocol says exports include raw records rather than summaries alone. Projects in the Plan Vivo module can also download an audit bundle for each metric run, which holds the data, code and results.
Settle control before the first survey
Data agreements are easier to write before records exist than after a dispute. Ask the four questions of any system you consider, then write the answers into your agreements and your consent process. To see how permissions and exports work in practice, Download the free app and open the demo project, or see pricing for larger teams.
Comments