Module 3: Building Your SSOT

Module 3: Building Your SSOT
Module Overview: The SSOT is the infrastructure that makes SUI verification possible. This module guides you through assessing your current data architecture, designing a minimum viable SSOT, and planning the path to audit-readiness. Allow 2–3 hours.
Learning Objectives
By the end of this module, you will have:
Assessed your current SSOT maturity (Level 0–3)
Mapped all data sources relevant to your SUI
Designed a minimum viable SSOT architecture for your company
Written your data governance policy (who can write, read, export)
Identified the tools and resources needed to reach SSOT Level 2
3.1 The SSOT Maturity Self-Assessment
Answer these questions honestly. The goal is to find your current state — not to impress anyone.
Level 0 Indicators (Fragmented)
[ ] Impact data lives in multiple spreadsheets maintained by different team members
[ ] There is no single place where someone new to the team could find all the data behind your impact claims
[ ] Different presentations use different numbers for the same metric
[ ] You could not produce a complete history of your impact events from the last 12 months in one hour
Level 1 Indicators (Consolidated)
[ ] All impact data is in one central place (even a single well-maintained spreadsheet)
[ ] The data is dated — you know when each entry was added
[ ] Access is controlled — not everyone can edit the master file
[ ] A new team member could find and understand the data without a guided tour
Level 2 Indicators (Automated)
[ ] Data flows automatically from source systems (ERP, IoT, CRM) to the central repository
[ ] Manual data entry is minimised or eliminated
[ ] Changes are logged with timestamps and the identity of who made them
[ ] Errors create a correction record, not an overwrite of the original
Level 3 Indicators (Audit-Ready)
[ ] Records are cryptographically immutable once verified
[ ] Role-based access control with access logging in place
[ ] Verifiers can access underlying data directly without company staff assistance
[ ] Structured export in verifier-specified format is automated
[ ] SOC 2 or equivalent security certification in progress
3.2 Data Source Mapping
For every data element in your SUI calculation, identify:
Data Element
Current Location
Update Frequency
Owner
Gap to SSOT
Application event record (count)
[e.g., Sales ERP, manual CSV]
[daily/monthly]
[Sales team]
[needs automated export]
Outcome measurement (observed value)
[e.g., Lab report PDFs in Dropbox]
[per batch]
[R&D team]
[needs ingestion system]
Baseline value
[e.g., Static value in spreadsheet]
[annual]
[Impact lead]
[needs version control]
Conversion factors (emission factors)
[e.g., Hardcoded in Excel model]
[annual IPCC update]
[Impact lead]
[needs versioning and update trigger]
Complete this table for every data element. Gaps represent your SSOT development roadmap.
3.3 Minimum Viable SSOT Design
For most CTH portfolio startups at seed or Series A stage, the minimum viable SSOT has four components:
Component 1: The Central Repository
Choose one of the following, based on your technical capacity:
Option
Technical Level
SSOT Level Achievable
Annual Cost
Google Sheets (structured, access-controlled)
Low
Level 1
$0 (Workspace included)
Airtable or Notion database
Low-Medium
Level 1–2
$10–$50/month
PostgreSQL (self-hosted or Supabase)
Medium
Level 2–3
$25–$100/month
Dedicated impact data platform (Proof of Impact, Persefoni, Greenly)
Low (managed)
Level 2–3
$500–$5,000/month
CTH recommendation: Start with Airtable or a structured Google Sheet at Level 1. Build the data governance discipline before investing in technology. Most startups over-invest in tooling before establishing the human processes that make any tool work. Plan the path to PostgreSQL or equivalent at Series A.
Component 2: The Ingest Protocol
Define how data gets from each source system into the central repository:
For each source system, specify: who extracts the data, in what format, at what frequency, and how they upload it to the central repository
For automated sources (IoT, API): define the integration (webhook, API pull, ETL pipeline)
Include a validation step: what checks run when data is ingested to catch errors before they enter the record
Component 3: The Change Log
The most important single addition to any existing data system. Implement a simple rule: no record is ever overwritten. Corrections are new records with a reference to the original. Every change carries a timestamp and the identifier of who made it. This can be implemented in Google Sheets with a formula-protected "corrections" tab — no engineering required.
Component 4: The Access Control Matrix
Document who has what access to the SSOT:
Role
Access Type
What They Can See/Do
Impact Lead
Write
Add new records, update baseline values (with change log entry)
CEO / CFO
Read
All aggregated data; no write access to underlying records
Board / Investors
Read (aggregated)
Impact dashboard; not raw records
Third-party Verifier
Read (full, time-limited)
All records including raw data, during audit window only
External (public)
None
No access to SSOT
3.4 The Digital Twin: Your Minimum Viable Version
Your Digital Twin does not need to be sophisticated at this stage. A minimum viable Digital Twin is a version-controlled calculation model with documented inputs. Here is a 5-step protocol:
Create a dedicated calculation file (Excel or Python notebook) that contains only your SUI calculation — not mixed with financial models or operational data
Document every input cell with a comment or adjacent cell containing: value source, source URL, year, geographic scope
Version control it: Save as "SUI_Model_v1.0_[date].xlsx" each time you make a material change. Store all versions (never delete old versions)
Lock the formula cells: Only the input cells should be editable; calculation cells are password-protected
Run a sensitivity analysis: Identify which inputs have the largest impact on the SUI magnitude; document which ones you monitor most closely
3.5 Module 3 Deliverable
Produce a 2-page SSOT Architecture Document containing:
Current maturity level (with evidence for each indicator checked)
Data source map (completed table from section 3.2)
Central repository choice and rationale
Ingest protocol (one paragraph per data source)
Access control matrix
Target maturity level and timeline (with resource requirements)
Submit to CTH with your SUI Specification Document for joint review.
Next: Module 4: Connecting Impact to Finance — translating your verified SUI into investor conversations.