Carbon Accounting Data Governance for Australian...

If you are the CIO being asked to sign off, the output you need is ten items answered in writing by the vendor before go-live, from SAML SSO to Australian data residency at rest. This post gives you that list and says where Carbonly stands on each.

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 to set for any carbon platform 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 young 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.

Who can log in, and how fast a leaver is out (SSO, SCIM, MFA, session revocation)

Start with identity. A platform touching a financial disclosure should run behind your identity provider over SAML 2.0 or OpenID Connect, which covers Microsoft Entra ID (formerly Azure AD), Okta, Ping, Google Workspace, and any other IdP that speaks either protocol, with just-in-time provisioning and attribute mapping from IdP claims to platform roles. Ask each vendor to show this working with your IdP rather than accepting a tick in a questionnaire.

For provisioning at scale, ask for SCIM 2.0. Users should be created, updated, and deprovisioned in the platform when the same lifecycle event happens in the IdP. When a project engineer leaves the construction company, their access to the site-level emission data should be revoked automatically, not on the next quarterly access review. Group-to-role mapping means an "AASB S2 Approvers" security group in Entra ID can map to an auditor role without any manual assignment.

MFA should be enforced at the IdP layer and, ideally, stepped up inside the platform for high-risk actions, such as approving a period lock, restating a baseline, revoking an API key, or exporting the full evidence pack. 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.

Then ask about session revocation. A sound design gives every session 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, with 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.

A common design is a shared-database, shared-schema architecture with tenant boundaries enforced at the query layer: every row carries a tenant identifier, and every query is scoped to the requesting user's tenant before it hits the database. The design is the easy part; the harder question is how it is verified.

Ask whether the vendor runs IDOR canary tests against every endpoint. 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. A canary test attempts exactly that on every endpoint: read, write, delete, list, export. The expected result is NOT_FOUND, not a redacted or partial response, and anything else on a cross-tenant probe should fail the test and block 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.

An audit history the assurer can walk, kept for seven years

Under section 22 of the NGER Act, records supporting a report have to be kept for five years from the end of the reporting year. AASB S2 and ASSA 5010 do not set their own retention period, but comparatives and assurance look-backs argue for keeping records longer, and seven years matches the period the Corporations Act sets for financial records.

Carbonly writes typed audit events on emission ledger writes, so changes such as period locks and restatements leave a record behind them. Whichever platform you review, check that each event carries the actor identity, the tenant, the timestamp and, ideally, a content hash of the resulting state.

A content hash is what makes an audit chain useful under reasonable assurance. An assurance provider can pick any emission record, walk the audit history backward, and verify that the state at each hop matches the hash, so a silent change shows up as a break in the chain.

Carbonly's internal retention policy is seven years, above the NGER Act's five, which 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

Carbonly's Australian customer data at rest is hosted on AWS Sydney (ap-southeast-2).

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. 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.

Ask any vendor where backups and disaster recovery snapshots sit, and what RTO and RPO they commit to in writing.

Five ways data arrives, all landing in the same audit trail

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.

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. Ask which Graph API permissions the integration requests; with standard Microsoft admin consent, your Entra ID admin approves the 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. If you need outbound events into a data lake or BI platform, ask the vendor to show signed webhooks with idempotency keys in writing.

5. Model Context Protocol (MCP) server. Carbonly offers an MCP server so an approved AI assistant can read against the emission ledger. For any MCP access, the questions are whether the assistant only sees what the underlying identity is allowed to see, and whether enterprise IT can restrict which assistants get through.

Whatever the pattern, check that every path lands in the same audit trail, with no "shadow" data path.

What the assurance provider gets for an 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.

Carbonly's evidence pack for assurance packages the source documents behind each record, with the emission factor version used and the audit history, for the period the assurance team selects. Compare what any vendor exports against the ASSA 5010 checklist.

None of that works if the audit trail is only a UI event log, so ask to see it.

Data breach response and Privacy Act 1988 (Cth) obligations

The Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth) applies to entities it covers, and financial services organisations under APRA CPS 234 carry their own notification obligations. Ask how a vendor's contract supports both.

Your incident response playbook will expect the platform to reconstruct what was accessed, by which identity, from which IP, using which API key or session, in what order. Ask whether authentication events, API calls, data access and administrative changes are all logged against a persistent identity, and whether rate limits and abuse detection run at the edge.

A BI key that can read but never write, and only from your IPs

For programmatic access, Carbonly issues API keys with scoped permissions and IP allowlisting. A read-only key for a BI dashboard can be limited so it cannot write or delete and can only be called from your data platform's egress IPs. For any vendor, ask whether every call is logged against the specific key, so a compromised key can be traced and revoked.

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? Australian customer data is hosted on AWS Sydney (ap-southeast-2). Some AI processing steps call third-party inference APIs, covered in the next answer.

Does Carbonly support SAML SSO and SCIM 2.0? Treat SSO and SCIM as items to be demonstrated against your own IdP during the security review, and get the current position from every vendor on your shortlist, including us, in writing.

What is the audit trail retention period? Carbonly's internal policy is seven years, which exceeds the five-year record-keeping requirement in section 22 of the NGER Act.

How is tenant isolation enforced? Carbonly isolates tenants at the database level. Whichever vendor you assess, ask how isolation is tested, for example with IDOR canary tests that probe every endpoint from a cross-tenant identity and require a NOT_FOUND response.

Can data leave Australia? Australian customer data at rest is hosted on AWS Sydney. Some AI processing steps invoke third-party inference APIs that operate globally; the current list of processors and their data-handling terms is part of the security documentation. 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.

You can put a real security review in front of a real workspace before any broader commitment, because Carbonly runs on per-project pricing with a $100 per month workspace minimum. Email hello@carbonly.ai for the security documentation and a review workspace for your team.

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