Written byHubSecure Climate & Compliance Team

Practical guides on governed climate execution, audit trails, and enterprise compliance workflows.

Reviewed byHubSecure Security & Compliance Review

Reviewed for accuracy, regulatory context, and product positioning.

Last updatedJuly 17, 2026

Checked against current HubSecure product positioning and regulatory landscape.

"One permission model" is frequently described as a technology feature. In practice, it is an accountability architecture. It answers a fundamental question: who is authorised to see, enter, review, approve, and export each type of climate-relevant data — and can you prove that the right person did so?

For CSRD and ISSB S2 compliance, that question is not rhetorical. Assurance providers check that material data points have been reviewed and approved by qualified individuals. If the permission model does not enforce that — if anyone in the organisation can approve a supplier declaration regardless of their role or region — the governance trail is broken.

The Permission Problem in Global Operations

Global operations create permission complexity at every level. A sustainability manager in Singapore should see the full Asia-Pacific inventory but not the EU data that may be subject to intra-group transfer pricing restrictions. A country procurement manager should be able to submit supplier declarations but not approve them. A group CFO should see the financial implications of carbon credit purchases but not the supplier relationship records. An external auditor should have read-only access to a specific audit pack, not the full ledger.

When permissions are managed at the system level — one permission per system, different permissions in different systems — the result is a patchwork that cannot be consistently enforced and cannot be audited. Someone with admin rights to the shared drive can access documents they are not authorised to approve. Someone without rights to the ERP cannot see the financial transaction that is the source document for a material emission entry.

What RBAC Means at Global Scale

Role-based access control (RBAC) assigns permissions to roles rather than individuals. Individuals are assigned roles. When a person's role changes, their permissions change automatically. When a new employee joins, they are assigned a role and immediately have the right permissions — and none beyond them.

At global scale, this means roles are defined across multiple dimensions: organisational level, geographic scope, data type, and action type. A "Country Sustainability Reviewer" role might grant read access to the full country emissions inventory, write access to add records, and approve access for submissions up to a defined materiality threshold — but no access to another country's data, and no access to carbon credit transactions.

The Four Dimensions of a Global Permission Model

DIM 01

Organisational scope

Which entities, subsidiaries, and business units a role can access. A group-level role sees everything; a country role sees only its own entity. Enforced at the data layer, not just the UI.

DIM 02

Geographic scope

Which countries, regions, and facilities are accessible. A country manager sees their country; a regional manager sees their region; a group manager sees all. Hierarchically inherited, not manually maintained.

DIM 03

Data type

Which categories of data a role can see: emissions records, supplier declarations, energy data, carbon credits, financial reconciliation, or audit packs. Not everyone who can see emissions data should see supplier contracts.

DIM 04

Action type

What actions a role can take: read, create, update, approve, export, delete, or admin. Separate from data type: a reviewer can read and comment but not approve; an approver can read and approve but not delete.

Climate-Specific Permissions: Who Approves What

RoleSubmissionsApprovalCredit transactionsAudit pack
Facility managerCreateNoneNoneRead (own facility)
Country sustainability managerCreate, updateUp to thresholdNoneRead (own country)
Group sustainability teamCreate, updateAllCreateRead (all)
Group sustainability directorCreate, updateAll + materialApproveExport (all)
External assuranceNoneNoneNoneRead (assigned scope)
Group CFONoneNoneApprove (budget)Read (financial data)

Implementing a Global Permission Model

  • Map your organisational hierarchy: legal entities, subsidiaries, countries, regions, facilities
  • Define the climate data types that need separate permission control
  • Define the action types required: read, submit, review, approve, export, admin
  • Design the role matrix: which roles exist and what combination of scope, data type, and action they have
  • Assign roles to individuals — not permissions to individuals — so that permission changes when a role changes
  • Audit the permission model quarterly: are the right people in the right roles? Has anyone's role changed without a permission update?
  • Provide external assurance access through a separate, time-limited read-only role — not through a shared admin account

HubSecure's permission model is hierarchical and multi-dimensional: organisational scope, geographic scope, data type, and action type are all independently controlled at the role level. Country teams operate with local permissions; group teams see everything; auditors get a scoped, time-limited read-only view.

HubSecure

Climate Execution Platform

HubSecure captures climate evidence at the point of work — every action, approval, and supplier declaration becomes part of a continuous, verifiable audit trail. No annual scramble. No evidence gaps.

Book a demo → View modules