Module 3: Building Your SSOT

Module 3: Building Your SSOT

Learning Objectives

By the end of this module, you will have:

1. Assessed your current SSOT maturity (Level 0–3)
2. Mapped all data sources relevant to your SUI
3. Designed a minimum viable SSOT architecture for your company
4. Written your data governance policy (who can write, read, export)
5. 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:

1. Create a dedicated calculation file (Excel or Python notebook) that contains only your SUI calculation — not mixed with financial models or operational data
2. Document every input cell with a comment or adjacent cell containing: value source, source URL, year, geographic scope
3. 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)
4. Lock the formula cells: Only the input cells should be editable; calculation cells are password-protected
5. 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.