# Registry requirements ## User roles and access control ### **Roles & Permissions** The Rainbow Registry has the following four distinct user roles, which are built into the technical specifics of the registry and cannot be bypassed.
Role typesDescription
Registry administratorThe registry administrator has the highest level of permissions, including the management of RCCs, projects, and users. This role is held by the Secretariat.
Certification leadThe Certification lead is a member of the Rainbow Certification team is responsible for creating and managing projects within the registry. They issue and cancel RCCs. They upload project-related files and update project statuses.
Account holder administratorAccount Holder Administrators are designated by the Account Holder during the account setup process and are created by Rainbow. They have the authority to manage Users within their account and oversee RCCs, including transfers and retirements.
Account holder usercan access the registry, and manage RCCs (transfers, retirements) when appropriate
### **Account holder types** **Account holder organizations** on the Rainbow Registry are limited to one of the following **account holder types**:
Account holder typeDescriptionAllowed actions
General Account (Buyer)Organizations interested in purchasing Rainbow Carbon Credits for offsetting or sustainability reporting.
  • View and purchase Rainbow Carbon Credits
  • Access transaction history
  • Not allowed to issue or list projects
General Account (Trader)Organizations authorized to engage in the buying and selling of carbon credits (including brokers and agents).
  • Buy, hold, transfer, and sell carbon credits on behalf of themselves or a Project Developer
  • Must have valid and current authorization from the Project Developer
  • Not allowed to issue or list projects
Project DeveloperOrganizations responsible for developing carbon credit-generating projects following Rainbow methodologies.
  • List and manage project activities
  • Submit documentation for issuance of Rainbow Carbon Credits
  • View credit status, issuance, and retirements
  • Retire, transfer and sell carbon credits from managed projects.
Validation/Verification Body (VVB)Independent third-party entities accredited to validate and verify project performance.
  • View and validate documentations
Individual/natural person accounts are not permitted under any of the categories. ### **Account creation** #### Account Holder Account holders shall accept the [Terms of Use of the Rainbow Registry](https://docs.rainbowstandard.io/other/terms-and-contracts/terms-and-conditions-for-registry-users) and go through [KYC](https://docs.rainbowstandard.io/other/governance-and-integrity/kyc-policy) and [AML](https://docs.rainbowstandard.io/other/governance-and-integrity/anti-money-laundering-aml-policy) assessment. To open an account, the organization must submit all required documentation and identification information to Rainbow, including: * Account holder type * Legal entity name * Organization registration number * Organization phone number * Registration address (postal code, city, address) * Country * Industry/Sector * Website * VAT number (if relevant) Requests shall be sent through the website [here](https://rainbowstandard.io/get-started) or via email at . Following document verification, and confirmation that the organization is an eligible Account Holder type, Rainbow will submit KYC and AML assessment materials to the organization. Once the KYC and AML procedures are successfully completed, Rainbow will activate the account. Rainbow reserves the right to refuse account creation at its sole discretion. #### User account Once the Account Holder account is approved, **user accounts within that organization** may be created. The organization is responsible for: * Creating and managing user access within its organization account * Ensuring that each user operates under the appropriate role * Promptly revoking access when a user no longer represents the organization Each User must act on behalf of their organization and may not use the registry for personal or investment purposes. ### **User responsibilities** All users must: * Use their credentials securely and not share them * Comply with Rainbow Standard Rules, Procedures Manual and applicable laws * Avoid misuse of the platform (e.g., fraudulent activity, promoting unrelated services, system interference) Rainbow conducts periodic reviews of access rights and user activity. Rainbow may **suspend or terminate access** in cases of non-compliance, fraud, revoked authorization, or any activity that brings the platform into disrepute. Account Holders are expected to: * Review and update their user lists regularly * Notify Rainbow of any changes in user roles or legal authorizations ## Project documentation The Rainbow Registry is the central platform for publishing project information, ensuring transparency, traceability, and accessibility. All projects must provide a **minimum set of publicly available information** on their registry page. This information may appear **directly on the registry page**, or within **documentation linked from it**, as detailed in below sections. Exceptions apply if disclosure is restricted by confidentiality, proprietary rights, privacy laws, or data protection regulations. Project documentation and relevant data shall be preserved for more than three years beyond the end date of the monitoring period. ### Information on the registry The following information shall be available **directly on the Rainbow registry** for each project: * the name and type of the project * name and contact details of the Project Developer * the applicable methodology and version number * the location of the activity, including the geographically explicit location of the activity boundaries, respecting 1:5000 mapping scale requirements * the duration of the monitoring period and crediting period, including the start date and end date * compliance with any accreditation or regulatory schemes such as CRCF, ICVCM, CORSIA... * quantified co-benefits * type of credit (e.g. removal vs avoidance) * durability in years (if applicable) * certification status, including certificates of compliance and validation and verification audit reports * GHG quantification results (i.e. without application of the buffer pool and discount factor) * quantity and status of RCCs (e.g. issued, retired, expired, cancelled or allocated to a buffer) * end-use of the certified units, and the entity that uses the certified units. ### Project documents publicly available on the registry The following information must be publicly accessible in linked project documents available on the registry: * Demonstration of **project compliance with the Rainbow Standard Rules and the applicable methodology**. This includes, at a minimum: * Additionality template * ESS risk assessment template * Stakeholder consultation process and outcome * Sufficient detail on the quantification of issued RCCs to allow **independent replication of calculations** at validation and for all subsequent verification events/credit issuances, including but not limited to quantification spreadsheet exports displaying: * calculation formulas * default values/secondary data * assumptions, and * project input data/primary measurements. * The **Audit Reports** of every project validation and verification audit * The **Project Design Document** (PDD) and any subsequent **Monitoring Reports**, with the following minimum content:
Minimum requirements for the PDD PDDs shall contain, at a minimum, the following information: **General and scope description** * Non-technical description of the project operations, scope, Project Developer, location, and other relevant actors * Legal ownership and contact information of the Project Developer * If using a registration partner or a group of Project Developers, a description of if and how advisory services are provided to Project Developers * Technical description of the technology and project operations * Specific location of the project, including [georeferenced boundaries](#user-content-fn-1)[^1] and/or GPS coordinates of the mitigation activity * Compliance with any accreditations beyond Rainbow certification (e.g. CRCF, ICVCM..) * Start date of the project, and start and end dates of the crediting period * [Monitoring Plan](https://docs.rainbowstandard.io/rainbow-standard-rules/principles-and-requirements#monitoring) with parameters to be monitored * Site registration **Eligibility, principles and requirements** * Justification that the project meets all [Principles and requirements](https://docs.rainbowstandard.io/rainbow-standard-documents/rainbow-standard-rules/principles-and-requirements) described in the Rainbow Standard Rules, and the chosen methodology * Stakeholders identified and outcomes of the stakeholder consultation * Assessment of environmental and social risks, and demonstration of sustainability * Project specific buffer pool contribution (if issuing removal RCCs) **GHG quantification** * Source for GWP100 values (IPCC AR6 or other IPCC version) * Information on how the methodology was applied for the purpose of * determining the baseline, * demonstrating additionality and * quantifying GHG emission reductions or removals, including but not limited to assumptions, data sources, and emission sources/sinks, that are not already defined at the methodology level * Project-specific uncertainty assessment and discount factor * Future projections throughout the crediting period including: * Operational, production, delivery information * Expected total **gross** GHG emissions, carbon removals, and avoidance * Expected total **net** GHG emissions, carbon removals, and avoidance (after applying the discount factor and buffer pool contribution) PDDs shall be made publicly available on the Rainbow Registry upon completing [Validation](#validation). See the [Registry and documentation](#project-documentation) section for further instructions on publicly available documentation.
Commercially sensitive information may be redacted from publicly available documentation, where it can be proven that disclosure of such information is harmful. Such redaction shall be approved by the Rainbow team, and the information shall always be provided to the VVB. ### Procedure for requesting non-public information A thorough description of the project’s design, implementation, and assessment findings must always be publicly disclosed. However, the primary proof supporting these assessments (such as raw monitoring data, internal reports, or proprietary models) may contain commercially sensitive or confidential information. These documents are not required to be made publicly available, but must be **listed in the PDD and/or Monitoring Reports as proof**, and made available to the VVB and the Rainbow team. Stakeholders may request access to non-public documents by contacting either the Rainbow team at or the Project Developer via the contact details listed on the project page. If the request is made to the Rainbow team, they must forward it to the Project Developer within 5 working days. Access must be granted if the information can be shared without: * violating licensing agreements, * disclosing commercially sensitive information, * violating privacy and data protection restrictions, or * where it cannot be proven that disclosure of such information is harmful. The Project Developer must respond to the requester within 10 working days, either by granting access or providing a justification for non-disclosure. ## Registry IT security ### Security standards The following security measures are the minimum requirements for the Rainbow Registry: * Data transfers shall always use industry-standard encryption technology (SSL/TLS/HTTPS). * Application authentication shall be enabled and verified by a third-party provider that meets industry best practice, is internationally recognized, and is ISO27001 certified. * Backend service and database hosting shall be enabled by a third-party provider that enables encryption. * Administrative tools shall be provided 2FA for admin authentication and sign-in. ### Security audit The Rainbow Secretariat shall verify **at least twice per calendar year** that the IT security requirements are met, and summarize the findings in a report made publicly available on the Rainbow documentation hub. The following elements shall be verified: * Verify compliance with the above requirements * Verify security vulnerability status and upgrade all JavaScript dependencies with npm. * Review Authentication provider access * Review Cloud provider IAM accounts and access * Rotate database passwords, API keys (internal and external) * Review Database connection allowlist * Review repository history for leaked secrets * Verify application authorization rules Past IT security Audit Reports can be found in the [Administrative Oversight Record](https://docs.rainbowstandard.io/other/administrative-oversight#miscellaneous) section. ### Incident procedures #### Incident definition A technological incident is defined as: * Theft or loss of data * Transfer of data to those unauthorized to receive it * Attempts to gain unauthorized access to Rainbow data or systems * Unintended disruption of the availability of Rainbow systems * Other significant events or bugs that compromise Rainbow's position as a trusted actor in the VCM ecosystem #### Reporting incidents * The general public is encouraged to report suspected incidents or vulnerabilities to * Employees shall report incidents to the internal Rainbow oncall engineer, , or to their manager #### Incident response 1. Within one working day (24 hours) of being informed of a suspected incident, the oncall engineer shall confirm reception of the incident report and begin an investigation to verify and assess the scope of the issue. 2. If the engineering oncall finds that the issue qualifies as an incident, they shall set up a dedicated channel to coordinate a response, including members of relevant teams as dictated by the nature of the problem. 1. The response team shall then work to contain, eliminate and then recover from the problem as their highest-priority task. 2. The response team shall communicate information about the incident to all relevant parties affected by the incident, including but not limited to clients, certifying bodies, employees, during and after recovery. 3. The response team shall hold a post-mortem meeting to deeply understand the underlying causes of the incident and plan proportional follow-up tasks to prevent similar failures from happening in the future. Findings from the post-mortem shall be shared internally or externally as appropriate. [^1]: including, if applicable, codes from the national integrated administration and control system (IACS) and land parcel identification system (LPIS) pursuant Regulation (EU) 2021/2116 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rainbowstandard.io/rainbow-standard-documents/procedures-manual/registry-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.