Carbon Accounting Data Governance for Australian...

The sustainability team has picked a carbon platform. The CFO has signed the business case. The vendor has sent through their standard MSA and a one-page security summary that reads like it was written for a US mid-market buyer. And now it is sitting in the CIO's inbox with a note asking for sign-off before the 1 July 2026 go-live.

This is the part of the AASB S2 rollout nobody put on the project plan. Carbon reporting used to be a spreadsheet the sustainability lead kept on their laptop. Now it is a regulated financial disclosure. That change quietly promoted a sustainability tool into the enterprise application portfolio, alongside the general ledger and the HRIS, without giving the enterprise architecture team a chance to weigh in on the shortlist.

Australian CIOs approving a carbon platform for AASB S2 Group 2 deployment want the same posture they demand of any system that touches financial disclosures. Enterprise SSO. SCIM 2.0 provisioning. MFA with stepup on high-risk actions. Seven-year audit retention. Australian data residency. Tenant isolation you can actually test. This post walks through what that looks like when the sustainability team hands you a shortlist and asks you to review it.

What AASB S2 Group 2 actually landed on the enterprise stack

Group 2 applies to entities meeting two of three thresholds: consolidated revenue of $200 million or more, gross assets of $500 million or more, or 250 or more employees. Every NGER reporter, regardless of size, is pulled in as well. The first Group 2 reporting periods start on financial years beginning on or after 1 July 2026.

That timeline matters for security review. If your financial year runs July to June, the AASB S2 controls need to be operating from day one of FY27. If you run calendar year reporting, you have until 1 January 2027 to have the platform, the data flows, and the security posture in production. Either way, procurement, security review, integration, and user acceptance testing all need to happen inside FY26.

For most Australian corporates that means a carbon platform is going through vendor risk review, TPRM assessment, penetration test evidence review, DPIA, and security architecture sign-off in parallel with the sustainability team building out the data model. It is a compressed timeline and the security review is where most projects stall.

The security posture your CFO expects, matched to what carbon platforms actually ship

The gap CIOs keep finding is that the carbon accounting category was designed for sustainability teams, not enterprise IT. Most legacy tools have a username-and-password login screen and an admin console. That is fine for a voluntary Climate Active submission. It is not fine for a regulated disclosure that a Big 4 assurance provider is going to test under ASSA 5010.

The bar we set for Carbonly is what the finance system in your organisation already has to meet. Enterprise identity federation. Provisioning automation. Session lifecycle management. Verified tenant boundaries. Immutable audit history. Region-locked data at rest. Not because it is nice to have, but because carbon is now a financial disclosure and the security posture has to match.

We are not going to pretend Carbonly is ISO 27001 certified or SOC 2 Type II attested. Those are governance targets, and the honest answer for a two-year-old Australian SaaS is that formal certification is a roadmap item, not a claim. What we can point to is the architecture, the controls built into the platform, and the audit history the assurance provider will actually look at. That is what a competent security review tests anyway.

Enterprise identity: SSO, SCIM, MFA, and session revocation

Every enterprise deployment of Carbonly runs behind the customer's identity provider. The enterpriseAuth service supports SAML 2.0 and OpenID Connect out of the box, which covers Microsoft Entra ID (formerly Azure AD), Okta, Ping, Google Workspace, and any other IdP that speaks either protocol. Just-in-time provisioning is on by default. Attribute mapping from IdP claims to Carbonly roles is configurable per tenant.

For provisioning at scale, we run SCIM 2.0 through the scimService. Users get created, updated, and deprovisioned in Carbonly the moment the same lifecycle event happens in the IdP. When a project engineer leaves the construction company, their access to the site-level emission data is revoked automatically, not on the next quarterly access review. Group-to-role mapping is configurable, so an "AASB S2 Approvers" security group in Entra ID maps to the Auditor role in Carbonly without any manual assignment.

MFA is enforced at the IdP layer by default and stepped up inside Carbonly for high-risk actions. Approving a period lock, restating a baseline, revoking an API key, or exporting the full evidence pack all trigger an MFA re-challenge. That is what "security stepup" means: the session is still authenticated, but the sensitive action forces a fresh factor. It is the same pattern your banking app uses for transfers over a threshold.

Session revocation is handled by the sessionRevocationService. Every session carries a token version. When an admin revokes a user, or the user changes roles, or the tenant admin triggers a global session revocation for incident response, the token version bumps and every outstanding session invalidates on the next request. There is no waiting for the JWT to expire.

Multi-tenant isolation, and how it is actually tested

Every carbon platform vendor will tell you they are multi-tenant secure. What that means in practice varies wildly.

Carbonly runs a shared-database, shared-schema architecture with tenant boundaries enforced at the query layer. Every row on every table carries a tenant identifier, and every query in the platform is scoped to the requesting user's tenant before it hits the database. That is the design; the harder question is how it is verified.

We run IDOR canary tests against every router in the codebase. Insecure Direct Object Reference is the failure mode where a user in Tenant A guesses or captures a resource ID belonging to Tenant B and gets a partial response back. The canary tests attempt exactly that on every endpoint: read, write, delete, list, export. The expected result is NOT_FOUND, not a redacted or partial response. Anything other than NOT_FOUND on a cross-tenant probe fails the test and blocks the deploy.

The reason NOT_FOUND matters is that some platforms return a FORBIDDEN or UNAUTHORIZED response to a cross-tenant probe. That leaks the existence of the resource, which is enough for a determined attacker to enumerate. The correct response to "this resource does not exist in your tenant" is that it does not exist. Full stop.

Audit trail architecture, and why seven years matters

Under the NGER Determination, records supporting a reported emission have to be kept for five years from the end of the reporting year in which they were reported. Under AASB S2 and the accompanying ASSA 5010 assurance standard, the effective retention period pushes out to seven years to cover the prior year comparative plus the reasonable assurance walk-through window.

Carbonly emits typed audit events for every state change on the emission ledger. There are over 27 distinct event kinds today, covering emission record creation, factor version changes, material match overrides, period locks, restatement approvals, target revisions, and administrative actions like SSO configuration changes, API key issuance, and SCIM sync events. Each event carries the actor identity, the tenant, the timestamp, a content hash of the resulting state, and the correlation ID that ties it to the originating request.

The content hash is what makes the audit chain useful under reasonable assurance. An assurance provider can pick any emission record on the ledger, walk the audit history backward, and verify that the state at each hop matches the hash. Silent changes are not possible because the hash of the current record has to be reachable from the hash of the prior version.

Retention is seven years from the event timestamp, not from the end of the calendar year. That aligns with the AASB S2 comparative window and gives the assurance provider room to trace any figure they pick without hitting a retention wall.

Australian data residency: what it means and what it does not

Every byte of customer data written to Carbonly at rest lives in Australia. Primary storage is in a Sydney region. Encrypted backups are in Melbourne for regional redundancy. Neither leaves the country.

Data residency is not the same as data sovereignty and CIOs get burned when vendors conflate the two. Residency describes where data is stored. Sovereignty describes which jurisdiction's laws can compel disclosure. For a Carbonly tenant, storage residency is unambiguously Australian, and the operating entity is Australian, which is the residency claim most Australian corporates care about for their vendor risk register.

There is one nuance the security review will surface. Some AI processing steps in the document engine invoke third-party inference APIs that operate globally. The data sent to those endpoints is scoped to the specific document being processed, not the full ledger, and no persistent training or storage occurs on the third-party side. That is documented in the DPIA pack we provide to enterprise customers. If your security posture requires zero cross-border data flow of any kind, we work through that during onboarding rather than pretending it does not exist.

Backups, disaster recovery snapshots, and cold storage all sit within Australian regions. Restore drills run on a schedule. RTO and RPO figures are in the technical annex of the MSA.

Five integration patterns for enterprise IT

The sustainability team is going to want the platform to receive data from every corner of the business. Utility bills. Fuel dockets. Waste invoices. Freight manifests. Refrigerant service reports. Concrete supplier delivery notes. The CIO's question is: how does that data actually arrive, and can I control it?

There are five access modes, and any enterprise deployment usually mixes several.

1. Web UI. Baseline. Users log in through SSO, upload documents through the browser, review AI extractions, approve emission records. Every action is captured in the audit trail against the SSO-authenticated identity.

2. Per-project email ingestion. Each project in Carbonly has its own inbound email address. A site manager forwards a supplier invoice from their phone, it lands in the project inbox, the AI document engine extracts the emissions, and the record posts to the ledger. From the CIO's perspective, this is an inbound-only email address on our domain, and every submission is logged with the sender.

3. OneDrive and SharePoint folder sync. Configured per project through the Microsoft Graph API integration. The sustainability team points Carbonly at a SharePoint folder, the platform polls it on a schedule, and any new documents are ingested. Graph API permissions are scoped to the specific folder, not the tenant. The consent flow is standard Microsoft admin consent, which means your Entra ID admin approves the exact scopes before anything syncs.

4. REST API and outbound webhooks. For customers with an existing data platform, the REST API supports both directions. Emissions data can be imported programmatically from any accounting or ERP system via CSV, Excel, PDF, or the API. On the outbound side, signed webhooks fire on emission events, period locks, and anomaly detections so downstream systems (a data lake, a BI platform, a compliance dashboard) can subscribe to changes. Webhook payloads are HMAC-signed and idempotency keys are included.

5. Model Context Protocol (MCP) server. Carbonly runs a first-class MCP server that lets an approved AI assistant, whether that is ChatGPT with connectors, Claude Desktop, or Cursor, read against the live emission ledger under OAuth 2.1 with PKCE. There are eight smart tools exposed today, each tier-gated and scoped to the user's permissions. The AI assistant only sees what the underlying identity is allowed to see. Enterprise IT can enforce MCP allowlisting at the identity provider layer, so only sanctioned assistants get through.

Every one of those five patterns hits the same audit trail. There is no "shadow" data path.

How the audit trail supports ASSA 5010 reasonable assurance walk-through

Reasonable assurance is where CIO governance and audit trail architecture collide. The assurance provider is going to pick a diesel figure inside the AASB S2 disclosure, walk it back to the underlying receipt, and check that every hop is traceable, timestamped, and unaltered. Under limited assurance the sample is small and the tests are largely analytical. Under reasonable assurance the test is a full derivation walk.

The typed audit events plus content hashes give the assurance provider a machine-readable trail. Carbonly exposes an Auditor Workspace and an Evidence Pack export that packages the source documents, the extraction confidence, the material match rationale, the emission factor edition used, the reviewer identity, and the audit history for any period the assurance team selects. That maps directly to what the ASSA 5010 checklist asks for.

None of that works if the audit trail is a UI event log. Which is what most carbon platforms actually have.

Data breach response and Privacy Act 1988 (Cth) obligations

Carbonly is subject to the Notifiable Data Breach scheme under Part IIIC of the Privacy Act 1988 (Cth). Financial services customers on APRA CPS 234 have additional notification obligations we honour through the MSA.

The platform captures every authentication event, every API call, every data access, and every administrative change against a persistent identity. When a suspected breach is being investigated, the on-call team can reconstruct exactly what was accessed, by which identity, from which IP, using which API key or session, in what order. That is the forensic requirement your incident response playbook expects. It is baked in, not an add-on.

Rate limits and abuse detection run at the edge. Anomalous access patterns, whether a spike in API calls or unusual document downloads, trigger alerts and can be configured to auto-revoke sessions or API keys. The abuse detection thresholds are tenant-configurable through the admin console.

API keys with scoped permissions and IP allowlists

For programmatic access, API keys are issued with scoped permissions and, optionally, IP allowlists. A read-only key for a BI dashboard can be issued that cannot write, cannot delete, and can only be called from your data platform's egress IPs. A write-scoped key for an ERP import job can be constrained similarly.

Every API call is logged against the specific key. If a key is compromised, the audit trail tells you exactly what it was used for during the compromise window. Revocation is instant.

The CIO's checklist before approving a carbon platform for AASB S2 Group 2

Ten things to demand before signing:

SAML 2.0 or OpenID Connect SSO with your existing IdP, JIT provisioning, attribute mapping to roles.
SCIM 2.0 provisioning with group-to-role sync and deprovisioning on IdP lifecycle events.
MFA enforcement at the IdP layer plus platform-side security stepup on high-risk actions.
Session lifecycle management with global revocation and token versioning.
Multi-tenant isolation verified by IDOR canary tests that expect NOT_FOUND on cross-tenant probes.
Typed audit events with content hashes and actor identity on every state change.
Seven-year retention aligned with the AASB S2 comparative window and ASSA 5010 assurance.
Australian data residency at rest for primary storage and backups, documented in the MSA.
API keys with scoped permissions, IP allowlists, and per-key call logging.
Signed webhooks with HMAC verification and idempotency keys for downstream integrations.

If a vendor cannot answer those ten in writing, they are not ready for Group 2. It is that simple.

Where a consulting partner fits

Most enterprise deployments run with a consulting partner leading the sustainability engagement, and that is a workflow Carbonly is built for, not around. The consulting practice owns the methodology, the materiality assessment, the strategy conversations, and the client-facing reporting. Carbonly is the platform under it. The RBAC model has an Auditor role designed exactly for that arrangement, so the consulting partner sees what they need to see without being provisioned as an admin.

If you are a CIO whose sustainability team has already engaged a consultant, do not treat the platform decision as a bypass of the consultant. Treat it as the infrastructure the consultant will use, and bring the consultant into the security review conversation. That is the pattern that works.

FAQ

Where is Carbonly hosted? Primary storage in Sydney, backups in Melbourne. Both are Australian cloud regions. Data at rest does not leave Australia.

Does Carbonly support SAML SSO and SCIM 2.0? Yes. SAML 2.0 and OpenID Connect are both supported for authentication. SCIM 2.0 handles user provisioning, updates, and deprovisioning against Microsoft Entra ID, Okta, Ping, Google Workspace, and any compliant IdP.

What is the audit trail retention period? Seven years from the event timestamp. That covers the AASB S2 comparative window plus the ASSA 5010 reasonable assurance walk-through, and exceeds the five-year NGER Determination requirement.

How is tenant isolation enforced? At the query layer with tenant identifiers on every row. Verified continuously by IDOR canary tests that probe every endpoint from a cross-tenant identity and require a NOT_FOUND response. Any other response fails the test and blocks the deploy.

Can data leave Australia? Data at rest, including backups and disaster recovery snapshots, stays in Australian regions. Some AI processing steps invoke third-party inference APIs that operate globally, and this is documented in the DPIA pack. No persistent training or storage occurs on the third-party side. If your security posture requires zero cross-border data flow of any kind, we address that during onboarding.

Getting your security review moving

If your sustainability team has put a carbon platform in front of you and the go-live is in FY27, the security review needs to start now, not in Q1. Ask the vendor for the ten items in the checklist above in writing. If they can answer, you have a platform ready for enterprise deployment. If they cannot, you have a spreadsheet with a login screen.

Carbonly runs on per-project pricing with a $100 per month workspace minimum, so you can put a real security review in front of a real workspace before making a broader commitment. Email hello@carbonly.ai to get the DPIA pack, the technical annex, and access to a review workspace for your team.

Carbon Accounting Data Governance for Australian CIOs: SSO, SCIM, Audit Trail, and Australian Data Residency