Prepare HR reporting data without circulating personal records

Ask HR for a defined aggregate reporting schedule and a controlled route for checking its underlying evidence. Keep the employee-level source records with authorised custodians. Most routine reporting coordination needs the definition, population, calculation and review trail, rather than a copy of the entire personnel file.

This guide is for HR, sustainability and reporting teams preparing workforce disclosures. It suggests a data-preparation workflow. It does not determine privacy-law obligations, retention periods or whether a particular disclosure may lawfully be shared.

Define the reporting population first

Write down the entity boundary, reference date or period, employee/worker categories, contractor treatment and the metric's denominator. A year-end count, average population, hours worked and training attendance are different inputs.

For example, BRSR's general workforce disclosure asks for employee and worker details at financial year-end, with specified categories; other indicators use their own definitions. Source: SEBI master circular, Annexure 16, section A, question 20; Annexure 17, corresponding guidance. Do not use one convenient payroll headcount for every people-related question.

Separate the source, review and reporting layers

• Source layer: HR or another authorised owner maintains the relevant employee-level system or records and their access controls.

• Review layer: authorised reviewers check the extraction, definitions, duplicates and reconciliations through an agreed controlled route.

• Reporting layer: the reporting team receives approved aggregates, methodology notes, coverage, exceptions and evidence references needed for the disclosure.

The layers can use existing systems. This is a suggested responsibility and access arrangement, not a requirement to buy software. A reviewer may legitimately need more detailed evidence for an agreed engagement; arrange that access deliberately rather than including personal records in every project folder.

Specify an aggregate handover

For each metric, request the following:

1. Disclosure reference and plain-language definition

2. Entity/site coverage and reference date or period

3. Category totals, numerator and denominator where relevant

4. Inclusion/exclusion rules and treatment of transfers or status changes

5. Source-system name and controlled extract/version reference

6. Reconciliation results, missing records and other limitations

7. Preparer, HR checker and approval date

8. Contact and authorised route for evidence questions

Do not include names, personal contact details, identity numbers, bank details or medical records merely because they are present in the source export. If person-level matching is necessary, restrict the working identifiers and lookup to the authorised team. Replacing names with codes does not automatically make a file anonymous.

A hypothetical headcount handover

Fictional example, not a Nitium client case. At the agreed year-end date, HR confirms mutually exclusive, reviewed categories containing 48 permanent employees, 12 other-than-permanent employees, 30 permanent workers and 20 other-than-permanent workers.

The reporting schedule contains 60 employees and 50 workers, with a combined arithmetic check of 110 people across those example categories. It also records the date, entity coverage, category definitions and the controlled source reference. HR has checked that transfers between two sites have not duplicated people.

The reporting coordinator receives those aggregates and the review note. The underlying names and employment records remain with HR, available to an appropriately authorised reviewer through the agreed route. The figure 110 is only a reconciliation check for this illustration, not a replacement for the required category disclosures.

Before a wider release, HR notices that an optional table would isolate a two-person department together with a sensitive characteristic. The owner sends that output for privacy and disclosure review. The team does not assume that removing names makes it safe, nor suppress a required disclosure without checking the applicable requirement and a permissible treatment.

Review small groups and combinations of fields

Aggregated or de-identified information can still carry identification risk when combined with other information. NIST's technical guidance recommends assessing the release purpose and disclosure risks before relying on de-identification. Source: NIST SP 800-188 overview and its technical explanation of aggregation and identification risk. This is general technical context, not an Indian statutory privacy test.

Ask whether a person could be singled out by the combination of site, role, age band, incident or other characteristic. There is no universal safe group-size threshold supplied by this guide. Have the appropriate privacy, HR and reporting owners assess the specific release.

Before circulating the schedule

• The population and period match the metric

• Employee/worker and other categories have been reviewed

• Transfers, duplicate records and missing data have been checked

• Only necessary fields are included for the recipient's task

• Small groups, free-text notes and combinations of fields have been reviewed

• Underlying evidence remains traceable through controlled access

• The approved version and intended recipients are recorded

Nitium's BRSR reporting support helps structure data requests and identify reporting gaps. Discuss a workforce-data reporting request or email contact@nitium.in with the required metric and population. Do not include employee-level or sensitive personal records in the initial enquiry.

Sources checked 5 October 2026. Aggregation does not by itself establish anonymity, lawful sharing or regulatory compliance. Obtain appropriate specialist advice for privacy, employment-law and disclosure conflicts.