GRI Source Register and Data Request

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Many reporting teams begin data collection with a spreadsheet headed only 'indicator', 'value' and 'owner'. That may be enough to chase a number, but it is not enough to establish whether the number answers the disclosure, uses the correct boundary, has been reviewed or can be located in the published report. As drafting progresses, methodology notes sit in email, evidence sits in shared drives, and page references are added manually after design. The same questions then return the following year.

A source register turns this fragmented process into a reporting system. It decomposes each disclosure into manageable information requirements, creates an accountable request, links the response to evidence and review, and carries the approved result into drafting and the Content Index. It also makes unresolved issues visible early enough to escalate them rather than discovering them in the final publication week or during assurance walkthroughs.

The register should allow a competent reviewer to answer five questions without searching through project correspondence: What exactly was required? Which population and period were in scope? Which source and method produced the information? What review and issue resolution occurred? Where is the approved information published? If one of those questions cannot be answered, the row is not complete.

Figure 1. Source-to-disclosure workflow for GRI reporting. The register links requirement, data request, source evidence, review, drafting and the Content Index, then carries the record into the next reporting cycle.

A disclosure can contain several sub-requirements, different owners and different sources. Treating the disclosure number as one row often conceals gaps. For example, a quantitative disclosure may require a total, breakdowns, methodology, assumptions and contextual explanation. One row may be sourced from an environmental system, another from finance, another from an approved methodology and another from management commentary. The register should be detailed enough to detect requirement-level gaps but not so fragmented that the team cannot manage it.

Figure 2. Anatomy of a practical GRI source-register record. The record should show what is required, who owns it, how the data are defined, where the evidence sits, what remains unresolved and where the approved disclosure is published.

Freeze the source set. Record the applicable GRI Universal, Sector and Topic Standards, editions and effective context before designing requests.

Decompose disclosures. Split each disclosure into requirement-level information needs, including quantitative breakdowns, methodology, narrative, omissions and contextual information.

Set applicability and scope. Define the reporting entities, impact population, metric boundary, period, unit, definitions and required disaggregation for each row.

Assign accountability. Name the data owner, methodology owner, preparer, reviewer, approver and drafting owner; avoid a generic team mailbox as the only owner.

Map existing sources. Link source systems, reports, policies, contracts, calculations, governance minutes and external datasets before issuing a new request.

Generate the data request. Send only the rows relevant to the recipient, with definitions, evidence expectations, due date and escalation route.

Review and resolve. Test completeness, accuracy, variance, methodology and evidence; open issues rather than silently correcting data in the master register.

Publish and lock. Carry approved wording and locations into the report and Content Index, retain the final evidence set, then create the next-year roll-forward copy.

The request should translate the technical row into an instruction the data owner can execute. A request asking only for 'GRI 2-7 employee data' assumes that the recipient knows the categories, basis of count, period, expected breakdown, estimate permissions and evidence requirements. The template below makes those expectations explicit.

The operational question, scope, date, breakdowns, methodology treatment, reconciliation, evidence, reviewer and due date are visible. The request does not ask the HR owner to decide whether an omission is permitted or to draft the Content Index; those judgements remain with the reporting and technical review team.

A single percentage-complete field is too weak for a controlled project. A row can contain a submitted value but still fail on scope, methodology, evidence or drafting. Use a status model that reflects the actual reporting gate.

The register shows the affected requirement; the issue log manages the resolution. An issue should be opened when the response cannot be corrected through an ordinary review comment or when the resolution needs cross-functional judgement, management decision or publication treatment. Keep the issue ID linked to every affected register row.

The reporting lead creates a source register with one row per meaningful information requirement and assigns stable IDs. The GRI 2, GRI 3 and material-topic rows are linked to the entity census and governance evidence. Topic metrics are linked to system extracts and calculation files. Narrative requirements are linked to approved policies, process evidence, minutes or management records rather than to a draft paragraph alone.

Each subsidiary receives a filtered request pack. A central methodology note defines employee categories, energy conversion, incident classification and acquisitions. The issue log identifies three recurring problems: local definitions that do not match the group manual, evidence stored only in email, and website disclosures whose URLs are not final. The group resolves definitions before consolidation, moves evidence to controlled folders, and delays the final Content Index test until the published site is available. At year end, the approved register is locked and copied forward with changed rows flagged for the next cycle.

A GRI data request should state the request and disclosure ID, the information needed, scope, population, period, unit, definitions, disaggregation, methodology or estimate treatment, evidence and reconciliation expectations, owner, reviewer, due date and escalation route. Generate it from the source-register row, leaving omission and Content Index judgements with the reporting and technical review team.

The source register is not the GRI Content Index. It is an internal control linking requirement-level data to owners, boundaries, methods, evidence, review, issues and final publication locations; the Content Index is GRI’s public locator and reporting-status record, which the source register helps the team produce.