> For the complete documentation index, see [llms.txt](https://guides.gresb.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.gresb.com/data-center-assessment/2.-completing-gresb-assessment/supporting-information/defining-the-reporting-portfolio.md).

# Defining the Reporting Portfolio

Indicators [RC3](/data-center-assessment/2.-completing-gresb-assessment/data-center-assessment/entity-and-reporting-characteristics/reporting-characteristics.md#rc3-entity-geography) (Location) and [RC4](/data-center-assessment/2.-completing-gresb-assessment/data-center-assessment/entity-and-reporting-characteristics/reporting-characteristics.md#rc4-business-model-and-entity-composition) (Business Model and Entity Composition) define the scope of the reporting portfolio in the Data Center Assessment.

Together, they determine where the portfolio is located and how it is structured, including the business models and sites that are included in the assessment. Completing these indicators correctly is critical, as they directly affect the how GRESB scores and benchmarks the assessment response.

This page will help you:

* Understand the key concepts used in these indicators (e.g., site, region)
* Apply a consistent approach to defining and, where relevant, splitting the organization's portfolio into reporting entities

***

## Key Concepts

### What are the UN M49 Regions?

> A standard classification of countries and areas developed by the United Nations for statistical purposes, which groups the world into regions and sub-regions based on geographic and statistical considerations. As defined by the United Nations, this classification is “used to arrange countries or areas into regions and subregions for statistical convenience.”

<details>

<summary>List of geographic regions</summary>

<table><thead><tr><th width="158.7408447265625">Continent</th><th width="343.8148193359375">Region</th><th>M49 Code</th></tr></thead><tbody><tr><td><strong>Africa</strong></td><td></td><td></td></tr><tr><td>Africa</td><td>Northern Africa</td><td>015</td></tr><tr><td>Africa</td><td>Sub-Saharan Africa</td><td>202</td></tr><tr><td><strong>Americas</strong></td><td></td><td></td></tr><tr><td>Americas</td><td>Latin America and the Caribbean</td><td>419</td></tr><tr><td>Americas</td><td>Northern America</td><td>021</td></tr><tr><td><strong>Asia</strong></td><td></td><td></td></tr><tr><td>Asia</td><td>Central Asia</td><td>143</td></tr><tr><td>Asia</td><td>Eastern Asia</td><td>030</td></tr><tr><td>Asia</td><td>South-Eastern Asia</td><td>035</td></tr><tr><td>Asia</td><td>Southern Asia</td><td>034</td></tr><tr><td>Asia</td><td>Western Asia</td><td>145</td></tr><tr><td><strong>Europe</strong></td><td></td><td></td></tr><tr><td>Europe</td><td>Eastern Europe</td><td>151</td></tr><tr><td>Europe</td><td>Northern Europe</td><td>154</td></tr><tr><td>Europe</td><td>Southern Europe</td><td>039</td></tr><tr><td>Europe</td><td>Western Europe</td><td>155</td></tr><tr><td><strong>Oceania</strong></td><td></td><td></td></tr><tr><td>Oceania</td><td>Australia and New Zealand</td><td>053</td></tr><tr><td>Oceania</td><td>Melanesia</td><td>054</td></tr><tr><td>Oceania</td><td>Micronesia</td><td>057</td></tr><tr><td>Oceania</td><td>Polynesia</td><td>061</td></tr></tbody></table>

</details>

### What is a site?

> A discrete physical location containing one or more data centers or a group of structures/buildings that support data processing, storage, networking, power, cooling, security, and connectivity.
>
> The intent is that a site is homogeneous with respect to controlling local authority, physical electricity supply, resource management issues, and land use context (e.g., rural, suburban, urban).
>
> A site should occur entirely within a single political boundary (e.g., city, county, or equivalent administrative division), utility service territory, and major water resource management area.
>
> Ultimately, these decisions seek to help investors and other data users understand the distribution of business models and control that influence opportunities and constraints on sustainability management and performance measurement.
>
> In this context, a participant needs to consider several factors:
>
> 1. Sites are intended to be discrete physical locations that are homogeneous with respect to key factors influencing sustainability management and performance.
> 2. This may allow for the aggregation of multiple facilities or even campuses if they share similar business models and patterns of operational control.
> 3. Alternatively, this may require splitting campuses or even facilities if they differ materially in business models and patterns of control.
>
> This information is essential for investors and other stakeholders to understand what a developer or operator can and cannot control across their portfolio. This facilitates a constructive, actionable dialog between stakeholders.
>
> \
> In the GRESB Data Center Assessment, a site is reported at one of three levels: [Facility](/data-center-assessment/2.-completing-gresb-assessment/supporting-information/terminology.md#facility), [Campus](/data-center-assessment/2.-completing-gresb-assessment/supporting-information/terminology.md#campus), or [Multi-Campus](/data-center-assessment/2.-completing-gresb-assessment/supporting-information/terminology.md#multi-campus).

<details>

<summary>Levels of sites</summary>

1. **Facility**

> A single data center building operated as one unit, with dedicated power, cooling, security, and IT infrastructure.

2. **Campus**

> A group of multiple data center facilities located in the same physical location and sharing common infrastructure such as substations, fiber connectivity, security, water systems, and operations.

3. **Multi-Campus**

> Multiple campuses located within the same metropolitan area or regional cluster, often under common ownership or operation. Campuses may not share physical infrastructure but are linked through network, operational, energy procurement, or customer ecosystems.

</details>

### What are business models?

> The operational and commercial structure through which a data center entity develops, owns, leases, manages, or delivers data center infrastructure and services to customers. In the context of the GRESB Data Center Assessment, business models can be one of the following:
>
> * Owner-Operator (Single-tenant)
> * Owner-Operator (Multi-tenant)
> * Developer-Hold Landlord (Powered Shell)
> * Developer-Hold Landlord (Turnkey Lease)
> * Developer-to-Sell / Merchant Developer
> * Managed Operator

<details>

<summary>Business model definitions</summary>

1. **Owner-Operator (Single-tenant):**

> A data center operated by an enterprise for the sole purpose of delivering and managing services for its employees and customers.

2. **Owner-Operator (Multi-tenant):**

> A data center in which multiple customers locate their own network(s), servers and storage equipment. The owner, a third party, or colocation may physically manage the equipment.

3. **Developer-Hold Landlord (Powered Shell):**&#x20;

> A data center where the landlord/developer provides a shell building with key site infrastructure such as exterior improvements, substation/switchyard, fiber points of entry and security, but the tenant completes the data center fit-out.

4. **Developer-Hold Landlord (Turnkey Lease):**

> A data center where the landlord/developer delivers a more complete, ready data center product, including MEP equipment, telecommunications systems, air handlers, power distribution units, intermediate distribution frames, & security.

5. **Developer-to-Sell / Merchant Developer:**

> A data center developer who follows a plan–lease–build–sell model, developing assets to a stabilized state and then selling them to monetize value and recycle capital into new developments.

6. **Managed Operator:**

> A data center offering server and data storage services, where the customer pays for a service and the vendor provides and manages the required ICT hardware/software and data center equipment. This management service includes the co-hosting of multiple customers, which may take the form of a cloud application environment.

</details>

***

## How to Define **Your** Reporting Portfolio

Defining the reporting portfolio is a critical step in the GRESB Data Center Assessment, as it determines how GRESB scores the assessment and benchmarks its results.

Each assessment represents a **single reporting entity**, defined by:

* A **single location**
* One or more business models&#x20;

Use the steps below to define the reporting portfolio for the assessment.

{% stepper %}
{% step %}

### <mark style="color:$primary;">**Step 1 – Define the Geographic Scope**</mark>

**You can only select one location per assessment.**

This defines the boundary of your reporting entity. All data reported in the assessment must relate only to sites within the selected location.

{% hint style="info" %}
If your portfolio spans multiple regions, you must submit separate assessments per region.
{% endhint %}

<p align="right"><a href="/pages/4clZfHHOhyHSVtjyZkcn#rc3-entity-geography" class="button secondary">Reported in indicator RC3</a></p>

***

{% endstep %}

{% step %}

### <mark style="color:$primary;">**Step 2 – Define the Portfolio Composition**</mark>&#x20;

Report the composition of the portfolio within the selected location.

* Indicate the **portion of the overall organization** represented by this reporting entity.&#x20;
  * If the reporting entity is part of a larger company or organization, indicate the portion of Capacity (MW) that the reporting portfolio represents
* Select the applicable **business model(s)**
  * Report the corresponding **capacity (MW)** and **number of sites** for each

All information must align with the location selected in RC3 and include only sites within that region.

<p align="right"><a href="/pages/4clZfHHOhyHSVtjyZkcn#rc4-business-model-and-entity-composition" class="button secondary">Reported in indicator RC4</a></p>

***

{% endstep %}

{% step %}

### <mark style="color:$primary;">**Step 3 – Decide Whether to Split the Portfolio**</mark>

Depending on the structure of the portfolio, the reporting entity may be reported as a single assessment or split into multiple reporting entities.

* Required: Split by region (one assessment per RC3 location)
* Recommended: Split by business model when multiple models are present

{% hint style="info" %}
Splitting by business model is optional, but can improve the relevance and accuracy of benchmarking insights. It is part of the standard submission process and does not incur additional costs.
{% endhint %}

***

{% endstep %}
{% endstepper %}

### Example Reporting Structures

<details>

<summary><em>Scenario 1: Single region, single business model</em></summary>

**Description**\
The organization operates within a single region and uses a single business model across all sites.

**Reporting approach**

* 1 assessment (required)

***

> ***Example***\
> \&#xNAN;*An entity operates only in Western Europe, with all sites classified as Owner-Operator (Multi-tenant).*

<figure><img src="/files/pWsiPNXDfG8OAUki13Md" alt="" width="375"><figcaption></figcaption></figure>

</details>

<details>

<summary><em>Scenario 2: Single region, multiple business models</em></summary>

**Description**\
The organization operates within a single region and includes multiple business models across its sites.

**Reporting approach**

* 1 assessment (allowed)
* 2+ assessments (recommended)

***

> ***Example***\
> \&#xNAN;*An entity operates only in Northern America, with 40% of capacity classified as Owner-Operator (Multi-tenant) and 60% as Developer-Hold Landlord (Powered Shell)*.

<figure><img src="/files/JcPY365mdAqtRpxif2cs" alt="" width="563"><figcaption></figcaption></figure>

</details>

<details>

<summary><em>Scenario 3: Multiple regions, single business model</em></summary>

**Description**\
The organization operates across multiple regions but uses a single business model across all sites.

**Reporting approach**

* 2+ assessments (required)

***

> ***Example***\
> \&#xNAN;*An entity operates Owner-Operator (Single-tenant) sites across two regions, with 30% of capacity in Western Europe and 70% in South-Eastern Asia.*

<figure><img src="/files/lz9MkyInduYnAbNeKAep" alt="" width="375"><figcaption></figcaption></figure>

</details>

<details>

<summary><em>Scenario 4: Multiple regions, multiple business models</em></summary>

**Description**\
The organization operates across multiple regions and includes multiple business models.

**Reporting approach**

* Minimum: 2 assessments (split by region, **required**)
* Up to 4+ assessments (split by region and business model, **recommended**)

***

> ***Example:***\
> \&#xNAN;*An entity operates across Northern America and Western Europe, with 70% of capacity classified as Owner-Operator (Multi-tenant) and 30% as Developer-to-Sell / Merchant Developer **in each region.***

<figure><img src="/files/jPF397DplhFveOrRhEaU" alt=""><figcaption></figcaption></figure>

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://guides.gresb.com/data-center-assessment/2.-completing-gresb-assessment/supporting-information/defining-the-reporting-portfolio.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.