EU Taxonomy

Supporting businesses meet the new regulation through physical risk assessment

 

The EU Taxonomy for sustainable activities, in simple terms, is a classification system and a financial disclosure report where a company has to disclose how much of their business is aligned with the European Green Deal, primarily for the purpose of PR and attracting green investments. We knew that our customers needed help with the EU Taxonomy reporting, but with so many unknowns in the policy itself and with our current capabilities, we needed to validate the opportunity before bringing it to our reporting features.

To be classified under the EU Taxonomy, the user needs to prove that their business is aligned to one of 6 objectives outlined in the EU Taxonomy, while also demonstrating that they do no harm to the other 5. However, only 2 of the 6 are currently well specified; “Climate Adaptation” and “Climate Mitigation”.

The key opportunity we saw around this was the physical risk assessment that EarthScan could provide, catered to the EU Taxonomy requirements. There are 2 places where the physical risk assessment is needed during the process:

  • If the user’s business is aligned with the “Climate Adaptation” objective, then the users can use the physical risk assessment to support their adaptation plan.

  • If the user’s business is aligned with the “Climate Mitigation” objective, users can use the physical risk assessment to help demonstrate that they are doing no harm to the “Climate Adaptation” objective.

 

My role

In this project, I was the design lead but also acted as a project lead, responsible for making sure that the delivery of the project was successful. I was not only designing the product experience, but was also responsible for making sure the Science, Policy and Content teams were creating the right content for the best experience, in addition to the development of any materials (e.g. sales enablement deck, content of the final spreadsheet deliverable ) or internal processes (e.g. an internal blueprint for how our pilot programme would operate).

Problem space

EU Taxonomy is an interesting space as this is a new regulation and not many companies have gone through the process. There are a lot of unknowns from all sides; both the users and the services in this space are figuring out what is required to meet the regulation. So the customers were relying on us to tell them what their needs were, rather than the usual approach of asking for a service given their needs.

So our approach was to establish strong hypotheses and validate these through a pilot programme, where the physical risk assessment is performed manually(spreadsheet), so that we know we are building the right thing before we put a lot of engineering effort into this. Some assumptions and example hypotheses:

Assumptions:

  • Users who are reporting for EU Taxonomy already understand their business activities.

  • Users who are reporting for EU Taxonomy already understand which objective their business activities are substantially contributing to.

  • While we can’t provide the financial metrics, the physical assessment is still desirable enough for users to pay for our service.

  • Users want to get a physical risk assessment for only the hazards that are relevant to them, and for any irrelevant hazards to be screened out.

  • Users will find IPCC Climatic Impact Drivers Framework useful in understanding their assets, which provides information on the importance of various climate hazards for different types of assets.


Hypotheses:

  • We believe that including the screening step before the physical assessment to filter out relevant and irrelevant hazards will make the process of writing the Adaptation Plan easier for our users, because the physical assessment will only include information that the user needs focus on for the write up.

  • We believe that including a layer on the IPCC Climatic Impact Drivers framework within the Physical Risk Assessment for EU Taxonomy (when this is not required) will provide additional information to help the user understand which hazards are important for their assets, particularly with respect to the hazards which are not covered by EarthScan - and therefore will be useful when it comes to writing an Adaption Plan.

  • Although EarthScan cannot provide the business activity-related aspects of the Physical Risk Assessment, it can provide the location-based aspects of the Physical Risk Assessment as well as business function(IPCC climatic impact drivers) which we believe are more important to the user.


Designing the pilot programme

In order to understand what content and features to include in the pilot programme, we first needed to understand how we could merge the policy requirements together with what was feasible from a technical and scientific perspective. There were 3 main areas where I had to lead workshop facilitations in order to move forward with the process:

  1. High-level user flow needs based on EU Taxonomy requirements

 
 

To understand where in the EU Taxonomy process we should be involved and how our current science capabilities fitted in, in addition to what additional features would be required, I held a workshop to bring every team involved together for discussion, and facilitated to get answers for the next steps. These teams involved Science, Product, Policy, UXR, and Engineering.

One of the biggest findings we identified from this workshop was that for the reporting for EU Taxonomy, users needed a report on the physical risk assessment of their assets based on two aspects:

  • Is the asset located in an area that is prone to a specific hazard?

  • Is the business activity with which the asset is associated prone to a specific hazard?

In order to create a physical risk assessment that supported the above criteria, we identified 3 areas which we needed to further research and make decisions on: Hazards, Relevant Thresholds and IPCC Climatic Impact Drivers.

 

Mapping of EU Taxonomy hazards into EarthScan hazards

 
 

The hazards specified in the EU Taxonomy classification did not always match directly or one-to-one to the EarthScan hazards.

As a result, we had to go through each one together to understand what we were able to cover, both from our existing hazards and from hazards we could calculate but which were not yet in EarthScan.

Relevant and Irrelevant thresholds

One of the key questions for users was: At what level or threshold of risk would one say that an asset is prone to or at risk from a specific hazard?

Additionally, the EU Taxonomy requires this risk to be assessed across the economic lifespan of the asset in question - raising another question of what this would be?

This was further complicated by the fact that material risk is a subjective concept; what is material for one party may not be material for another, dependent on factors such as the industry, the business model and the risk tolerance of each party.

We needed to be able to guide users through these requirements and address these questions based on what we were able to offer. Together with our policy experts, we agreed that the time period of 2020 - 2060 was a good estimate of the typical economic lifespan of an asset, and that a rating of C or below (i.e. C - F) would constitute an indication of significant risk.

Putting this all together, we baselined the threshold of being potentially at material risk for EU Taxonomy reporting purposes as: whether the asset was rated C or below (i.e. C - F) in the time period between 2020 - 2060.

 

IPCC Climatic Impact Drivers

 
 

Assessing the physical risk for a given asset under the EU Taxonomy required answering not just whether an asset’s location was at risk from a specific hazard, but also whether the business activity with which the asset is associated is prone to a specific hazard.

In order to answer this question, this would require considering the number of employees, the power and water supplies, the production process, etc. This is not something we would be able to provide in a short time, and since this would require a lot of work to develop a mapping of e.g. the production process for laptops vs Lego and what hazards would impact each of these, we needed concrete validation of the value of this before committing to it - something we would ask about during the pilot programme.

However, we found that we could utilise the IPCC’s Climatic Impact Drivers to guide users through whether a hazard would impact their asset based on whether it is e.g. a building or an energy infrastructure such as a power station or windmill. Our policy team generated a mapping of the IPCC hazards against the EU Taxonomy hazards and our own EarthScan hazards, in order to use the Climatic Impact Drivers to provide this information in our EU Taxonomy offering.

This was another element added which allowed us not only to address the above question on whether the asset’s business activity was at risk from specific hazards, it also allowed us to provide information on hazards for which we weren’t able to generate physical risk ratings for.

Generating the manual Physical Risk Assessment for the pilot program

 

As a result of these discussions, we were able to create a manual version of the Physical Risk Assessment, which is what is sent to the user.

I worked with the Policy team to ensure that the spreadsheet not only contained all the necessary content, but also to ensure it was well organised for the user to understand the content and allow the user to write an adaptation plan. This also involved providing onboarding content, explanations of certain key aspects such as Materiality, and structuring the tables so that the information is easily digestible for the user.

Here, our analyst would get the data using our platform (both EarthScan and from recently developed signals not yet available in EarthScan), and put together the assessment by hand in a spreadsheet so that we could test our Assessment without significant engineering resource.

 
 

Getting ready for the pilot

As the manual spreadsheet was getting close to being finalised, I started to design the pilot programme into more detail. I had to consider all aspects of all of the touchpoints involved, both frontstage (customer-facing) and backstage (internal), such as how we are first interacting with customers, how to onboard them, coordination between internal teams such as Sales, Customer Success, Policy, Science and UXR, as well as designing all of the deliverables involved.

The key touch points were:

 
 

Step 1: Pilot recruitment

Provided materials to enable Sales to recruit customers for the pilot programme.

Step 2: Introductory call

Prepared a template for the intro call materials and collaborated with Customer Success to customise these based on the customer profile.

Step 3: Receiving asset information

Created the asset template for customers to fill in so we could receive relevant information on assets to be assessed from each pilot customer.

Step 4: Design internal process

Created a service blueprint describing the entire internal workflow, including who hands what data file over to whom, and any appropriate review processes. This was shared with everyone involved so all teams can understand when and where their roles are needed in the pilot.

Step 5: UXR session

The key component of the whole pilot programme - I worked with UXR on what we needed to ask and designed high fidelity prototypes for us to test with users.

As there were a lot of internal stakeholders involved, it was very important that we were all aligned and remained so throughout the process.

Cervest is a remote company with people all over the world, and finding times to schedule calls for everyone across various different time zones was difficult.

To address this, I created a a number of walkthrough and update videos on Loom (an video collaboration tool) to keep all stakeholders in sync during this process, which many of my colleagues found helpful:

“just wanted to reach out to say that I got time to watch the loom recording this morning of your recent work on the EU Taxonomy and I am blown away. All the prototypes look great and I cannot wait to see customers validating this hard work. I am meeting with (product lead) to coordinate this later today!”

Head of Customer Success

“Finally got around to watching this. Thank you  for putting together and great to see we can screen out certain hazards depending on the type of assets.
Wow - loving the sneakpeaks into the prototypes! I am very interested in hearing feedback on the ability to remove hazards that are likely to affect the asset.”

VP of Global Sales

 

“Great to see and also that we are in full swing on securing pilot customers - including ones actually looking to pay for this (helps us validate willingness to pay in addition to of course bringing in revenue). Really like the prototype screens and the 2 journeys - keen to hear feedback.”

COO

Getting ready for the UXR Session

While the analysts were creating the manual spreadsheet for our first pilot testers, our user researcher and myself started work on the user research session which we would use to validate our opportunity and hypotheses. While I cannot share the questions here, we focussed on how desirable our service would be, given that the physical risk assessment is a necessity for EU Taxonomy but is still only a small part of the entire process.

We also prepped for future product experience validation; we wanted to understand how users would use the ability to screen out irrelevant hazards to keep only the relevant ones, or even not use this ability - we would still like to have this information.

Here, I mainly worked on 2 ideas (but with three prototypes as one involved exploring different UI options) that could support the conversation with users and help to show what we were trying to achieve.

 

Key idea
Screening and Physical Assessment are two separate steps.

Pros:

  • By separating the Screening and Physical Assessment steps, the user will receive only the high risk/relevant information in the physical assessment, allowing them to focus on the highest priority information only.

  • An important aspect of this was that users had the ability to move any hazards to the “relevant” category (and vice versa) based on their knowledge of their asset.

  • Having 3 steps established a nice structure for the overall reporting framework.

Cons:

  • If users wanted to reference low risk/irrelevant hazards, they would have to either go back and forth, or download two versions of the report and cross reference them. This was something that we needed to test in the pilot.

  • Potentially more complicated as more explanations were required and more user actions required to iterate to get to their report.

  • There seemed to be a lot of content + interactions during the screening step, so that this step seemed very busy.

Key idea
Screening + Physical assessment content is combined into a single page, and therefore there is no separate UI for screening.

Pros:

  • By combining screening and physical assessment into a single page, the flow was actually more wholesome and required fewer explanations and user actions.

  • The journey was simpler as we are eliminating a step.

  • If the user wanted to reference both the screening results and the physical assessment, they wouldn’t need to flip back and forth between pages.

Cons:

  • Having steppers for only 2 steps could look a little odd - but this would also provide flexibility in scaling.

  • Would users not care about low risk hazards and want a simpler report?This was something that we needed to test in the pilot.

  • There is a lot of information on a single step since both steps are combined - even more so than the alternative prototype.

 

I also explored a third option involving both screening and physical assessment steps combined, but with a pop over for the onboarding rather than a stepper.

The rationale for this is the onboarding step is small and there is only one other (combined) step - and therefore there is technically no need for steppers.

 
 

Where we are now & next steps

We are currently going through our first pilot programme, where our analyst is preparing the first manual spreadsheets to validate our hypotheses.