Skip to main content
AI & Technology

Make ESG a Monthly Operating Process with PrivacyHub

A practical design for monthly ESG data collection, evidence, review and approval using PrivacyHub governance foundations, with a clear line between capabilities that exist today and ESG functions that still need to be built.

ESGPrivacyHubSustainability DataData GovernanceISSBGHG Protocol
AI-generated editorial illustration of operations and ESG staff reviewing data documents in an office beside a factory; it does not depict real staff, premises or clients
AI-generated editorial illustration

Imagine the fifth working day of the month. The sustainability team starts chasing electricity, fuel, waste, training and employee turnover data. One department sends a file straight away. Another asks to reuse last month's number. A third has a total but cannot locate the invoice or calculation behind it.

This is not a reporting-screen problem. The organisation has no shared operating cycle that says who submits each measure, which unit applies, who checks it, when it becomes approved and how a reviewer can trace a reported value back to evidence.

PrivacyHub already has useful foundations for this work: tenant-scoped records, users and role-based access, configurable fields, imports, notifications, reports, audit history, risk records with owners and mitigation dates, and multi-party approval patterns in DPIA work. These are governance and workflow building blocks. They are not an off-the-shelf ESG module, a carbon calculator or automatic compliance with any disclosure standard.

A sound implementation would reuse those foundations, then add an ESG data model and monthly close designed around the organisation's own responsibilities and methods.

ESG needs an operating cycle, not a year-end form

The Stock Exchange of Thailand describes its ESG Data Platform as an end-to-end process for receiving, processing and publishing structured ESG information that can be analysed alongside financial data. Its examples include energy, resource use, greenhouse gas emissions, workforce data and board information (Stock Exchange of Thailand).

That description makes the work before disclosure visible. Every measure needs a definition, boundary, period, source and accountable owner. IFRS S1 is also broader than a KPI checklist. Its disclosure structure covers governance, strategy, processes for managing sustainability-related risks and opportunities, and performance against targets.

The system therefore needs to support a repeatable human process and retain the reasons behind decisions. Collecting numbers into a dashboard is only one part of the job.

What PrivacyHub can provide as a foundation

Several patterns in PrivacyHub can be reused for ESG without rebuilding the governance layer from scratch.

  • Tenant-scoped records and role-based access can control who sees, edits, reviews or approves each item.
  • Configurable fields can accommodate industry-specific data while keeping a stable core model.
  • Imports, notifications and workflow states can organise collection windows and overdue follow-up.
  • Reports and audit history can show who changed a record and when.
  • The risk register already uses concepts such as risk owners, mitigation actions and follow-up dates. DPIA workflows provide a pattern for sign-off by more than one responsible party.

These are reusable operating patterns. Renaming PDPA fields as ESG fields would not create an ESG solution. Sustainability information has its own meaning, calculations and control requirements.

What must be added for ESG

An ESG module needs a new domain model covering at least the following areas.

  1. Reporting periods and close cycles. Define months, quarters and years, submission deadlines and the status of each business unit.
  2. A metric register. Store the definition, owner, unit, organisational boundary, site and relevant reporting frameworks for each metric.
  3. Periodic values and evidence. Link every submission to its source system or document, submitter and source date.
  4. Calculation methods and versions. Record formulas, conversion or emission factors, references and effective dates so a reviewer can explain differences between periods.
  5. Targets and actual results. Keep baselines, targets, actual values and variance explanations distinct.
  6. Data-quality rules and exceptions. Identify missing documents, inconsistent units, unusual changes and overdue submissions.
  7. Approved snapshots. Lock the values, calculation version and evidence for a period, then build a traceable report pack from that approved version.

Work aligned to IFRS S1 must also connect measures to governance, strategy and risk-management processes. The product should not become a KPI store detached from management decisions.

For greenhouse gas information, GHG Protocol publishes the Corporate Standard, Scope 2 Guidance and Scope 3 Standard as distinct materials. An ESG specialist must select the boundary, category treatment and factors that fit the organisation. The system records the configuration, version and evidence for review.

How the data moves and where people remain accountable

The proposed monthly close below shows the hand-offs. The return path represents an item with missing evidence, a unit mismatch or an unresolved question. It goes back to the departmental owner before approval.

Monthly ESG workflow from source systems through departmental data owners, the ESG coordinator and business approval to a locked report pack, with supporting roles for ESG specialists, IT and suggestion-only AI

An example process to design with the organisation's actual owners. It does not represent a complete set of ESG features already available in PrivacyHub. Select the image to open the full-size version.

The ESG specialist defines material topics, organisational boundaries, metric definitions and methods. IT maintains connectors and access. Departmental data owners collect monthly values and evidence. The ESG coordinator checks units and completeness, then follows up on exceptions. An authorised business owner approves data that is ready for use.

Disclosure preparers, reviewers and assurance providers should receive permissioned access to the approved dataset, evidence and change history. If an issue appears after close, the process should open a new revision with a reason instead of silently overwriting the approved value.

AI can assist with invoice extraction, unit matching or anomaly suggestions. Its output must remain a suggestion. People still verify the source, select the method, resolve exceptions and approve the data. AI should be neither the approver nor the source of truth for a reported figure.

Connect ERP and Odoo without copying every record

ESG data usually spans several systems. Procurement and expense transactions may sit in an ERP or Odoo. Workforce data sits in HR. Utility invoices may arrive by email or through a building system. Supplier data often comes from external questionnaires and supporting documents.

The integration method should follow the data.

  • High-volume, recurring records are good candidates for an API or structured import with a site code and reporting period.
  • Unstructured documents may need the data owner to enter the required value and reference the source file.
  • Where another application remains the system of record, PrivacyHub should store a stable identifier and authorised reference rather than copy every field.
  • Any manual adjustment should require a reason and preserve the prior value in the audit history.

For example, an electricity transaction from Odoo Accounting may provide the supplier, invoice date, amount and document reference. The kWh value may still need to come from the invoice or meter. The factory data owner checks that the value and period belong to the right site before the ESG coordinator applies the approved method.

Workforce measures still carry privacy obligations

Many social measures start with HR data, such as headcount, tenure, gender, injuries, training or turnover. Some supporting records may contain personal or sensitive personal data. An aggregated disclosure does not remove the privacy risk in the source process (Thailand Personal Data Protection Act B.E. 2562, Office of the Council of State).

The organisation should establish its purpose and lawful basis, restrict individual-level access, collect only what the metric needs and apply its retention policy to supporting evidence. The ESG reporting team may only need an aggregate, while an authorised HR reviewer can inspect source records. When evidence is required, the workflow can reference a document in its authorised location instead of making uncontrolled copies of employee data.

Reusing PrivacyHub makes it possible to apply the same concepts of permissions, responsible owners, change history and data-risk review. The access boundary and retention period still need to be decided for each metric and its actual source material.

A monthly close that can be operated

A monthly cycle could work as follows.

  1. The system opens the period and creates the submissions due from each department according to the metric register.
  2. Data owners import a value or enter it in a form, then attach or reference the source evidence.
  3. The system checks format, unit, reporting period, completeness and the organisation's basic validation rules.
  4. The ESG coordinator reviews exceptions, overdue items and movements that need explanation, returning unresolved items to their owners.
  5. The authorised business owner approves the department's values. The system then locks the dataset with its calculation methods and evidence versions.
  6. The reporting team creates a report pack and gives reviewers permissioned access. Any post-approval correction opens a new revision with a stated reason.

Close rules should also name who may reopen a period, who approves a retrospective adjustment and which data version supports each published report. Without those decisions, a dashboard and a disclosure can drift apart after an edit.

A 12-week pilot shape

The following is a sample plan for a narrow scope, such as 8 to 12 metrics across two sites and two main source systems. Actual timing depends on data condition and the speed of organisational decisions.

  • Weeks 1 to 2: select metrics and agree their boundaries, units, methods, data owners, reviewers and approvers.
  • Weeks 3 to 5: configure the metric register, periods, permissions, evidence fields and data-quality rules.
  • Weeks 6 to 8: connect the first sources, test imports and have data owners inspect real records.
  • Weeks 9 to 10: rehearse one close, collect exceptions and adjust responsibilities.
  • Weeks 11 to 12: complete the pilot close, produce a report pack and ask a reviewer to trace approved values back to evidence.

The pilot should pass because the team can answer practical questions: Where did this value come from? Who certified it? Which method version was used? Which exceptions remain? If a prior period changes, does the original approved report still exist? Dashboard page count is not a useful acceptance measure.

The operating owner remains after launch

Once the workflow goes live, the organisation still needs to manage failed imports, overdue submissions, access changes when staff move, calculation-factor updates and reviewer findings.

A monthly support service can monitor connectors, organise exception queues, review access, rehearse the close and prepare method-version changes. Data approval and disclosure still follow the organisation's assigned authority, while any independent assurance engagement keeps its scope distinct.

A useful starting point is one period, one site and a short list of measures with real supporting evidence. Run those measures from collection to a locked report pack. Once the team can trace every approved value to its owner, method and source document, it has a controlled pattern that can be extended to the next dataset and department.

References

"Empowering Innovation,
Transforming Futures."

Contact us to make your project a reality.