How Indian CFOs Should Build an ESG Data Lineage File That Survives Both BRSR Assurance and Rating-Agency Queries

Indian listed companies now face two parallel external tests on the same ESG numbers. The first is the phased BRSR Core assessment or limited assurance. The second is the growing volume of rating-agency, lender, and large-buyer questionnaires that arrive with their own definitions, cut-off dates, and evidence expectations. The practical failure mode is not the absence of data. It is the absence of a short, CFO-owned lineage file that shows, for each material indicator, which system produced the number, which person owns the extraction, when it was last refreshed, and how an outsider can re-perform it six months later. Without that file, assurance teams and rating agencies receive parallel spreadsheets that cannot be reconciled, and the board discovers the gap only when an exception is raised.

This briefing is written for CFOs, controllers, finance business partners, and the sustainability leads who currently maintain separate workbooks. The setting is the Indian BRSR framework and the BRSR Core indicators that will be assured. The same discipline applies to unlisted groups that answer CDP, EcoVadis, or bank transition questionnaires. A number that cannot be traced to a source system the company already controls is not a disclosure. It is a communications risk that becomes expensive when two external parties test it at the same time.

1. Why data lineage is the missing control between BRSR Core and rating-agency questionnaires

Most Indian finance teams already know how to produce a trial balance that an auditor can re-perform. The same teams still treat ESG indicators as a year-end compilation exercise owned by sustainability. Energy consumption, water withdrawal, waste generated, and workforce diversity numbers are extracted from plant systems, HR platforms, or supplier portals, pasted into a workbook, and then reformatted for BRSR, for the annual report narrative, and for each rating-agency template that arrives. When the assurance provider samples a Core indicator, the team must reconstruct the extraction path under time pressure. When a rating agency asks for the same indicator under a slightly different boundary or cut-off date, a second extraction is performed. The two numbers rarely match exactly, and the difference is rarely explained in a controlled document.

The gap is not technology. Most Indian companies already have the source systems: ERP energy modules or utility invoices, HR information systems, waste-manifest registers, and capital-expenditure trackers. The gap is the absence of a standing lineage file that records the path from those systems to the published number. Without the file, every external query becomes a fire drill. The controller learns of the query only when the sustainability team forwards the questionnaire. The extraction logic lives in one person’s laptop. Base-year adjustments, plant openings, and acquisitions are handled ad hoc. Assurance findings and rating-agency data-quality flags follow.

Indian boards already apply this logic to non-GAAP financial measures. An adjusted EBITDA that is not reconciled to the audited profit is challenged. An ESG intensity ratio that is not reconciled to the assured BRSR Core indicator should face the same test. The difference is that the evidence is distributed across plants, HR systems, and external vendors rather than sitting in one general ledger. That distribution is the reason the lineage file must be designed as a controlled document, not as an after-the-fact explanation.

Further reading on DrDPKlass: how finance teams should prepare BRSR Core for limited assurance and how boards should set an ESG materiality threshold that survives auditor challenge. The lineage file sits between those two controls.

2. Designing the lineage file so it fits on a controller’s desk, not in a data lake

A usable lineage file is short enough that a controller can review it in one sitting and stable enough that the same cards can be updated every quarter. It is not a data-lake project. It is a controlled spreadsheet or simple database that contains one card per material indicator. Each card has six fields that can be completed by the existing finance and plant teams without new software.

The file does not need to cover every qualitative statement. It covers the quantitative indicators that will be sampled by assurance or that appear in rating methodologies. For most Indian companies that means the BRSR Core set plus the additional indicators that the company’s own materiality assessment has already flagged as high priority. Starting with ten to fifteen cards is sufficient. Adding more later is easier than trying to document every number in the first cycle.

3. Mapping BRSR Core indicators to the same source systems the auditor already tests

The fastest way to make the lineage file credible is to map each BRSR Core indicator to a source system that the statutory auditor already tests or that internal audit already samples. Energy and GHG indicators often sit in the same utility invoices or plant energy meters that feed the cost-of-goods calculation. Water and waste indicators frequently sit in the same registers that support environmental clearances. Workforce indicators sit in the HR information system that already feeds payroll. When the lineage card points to a system the auditor has already walked through, the assurance provider does not have to start from zero, and the rating agency can be told that the number is extracted from a controlled system rather than from a one-off survey.

Three mapping choices appear repeatedly in Indian files and should be decided once, then locked in the card. First, decide whether the boundary is operational control or financial control and write the rule on the card. Changing the rule mid-year without a bridge is how intensity ratios become incomparable. Second, decide the treatment of acquisitions and plant closures. A simple rule—include from the date of acquisition, exclude after the date of sale, and show the bridge—prevents later restatements. Third, decide how estimated meters or missing invoices are handled. A stated estimation method with a percentage threshold is better than an undocumented average. Each decision is written once on the card and then applied consistently to both the BRSR workbook and any rating submission.

When a Core indicator cannot be mapped to an existing controlled system, the card should say so. The residual risk is then visible to the board and to the assurance provider before the engagement letter is signed. Pretending the number is fully controlled when it is not is how limited-assurance findings become management-letter points that later appear in rating-agency commentary.

A lineage card that points to a system the statutory auditor has already tested is more persuasive to both an assurance provider and a rating agency than a new data platform that has never been walked through.

4. Handling rating-agency requests without creating a second set of numbers

Rating agencies, lenders, and large buyers often ask for the same indicators under slightly different definitions or cut-off dates. The temptation is to create a second extraction that matches the questionnaire. The result is two numbers that cannot be reconciled and a data-quality flag that is difficult to remove. The lineage file prevents this by forcing every external submission to start from the same card. Differences are shown as bridges, not as new numbers.

A practical protocol has three steps. First, the controller reviews the questionnaire and marks every quantitative request against the existing lineage cards. Requests that match a card are answered from the card, with the version number and refresh date cited. Second, requests that use a different boundary or cut-off are answered with the card number plus a short bridge that shows the adjustment. The bridge is stored with the card so the next request can reuse it. Third, requests that cannot be answered from any existing card are either declined with a clear statement or held until a new card is built and signed. Declining is cheaper than inventing a number that cannot be re-performed later.

Indian companies that have already faced rating-agency data-quality flags know that the flag is rarely about the absolute level of the number. It is about the inability to show how the number was produced and why it differs from the prior submission or from the BRSR filing. A lineage file that is updated every quarter removes the most common source of those flags. It also shortens the time the finance team spends answering follow-up questions, because the answer is already written on the card.

5. Assigning ownership so the file survives staff turnover and year-end pressure

A lineage file that lives only with one sustainability analyst or one plant engineer will break when that person leaves or when year-end close consumes the team. The practical ownership model uses roles the company already has and keeps the file inside the finance close calendar.

1. The controller owns the master file and the sign-off on each card. The file is stored in the same controlled folder as the BRSR Core workbook.
2. Each extraction owner (plant energy manager, HRIS administrator, EHS lead) is named on the card and is responsible for running the extract on the agreed cadence and for flagging any change in system or boundary.
3. The sustainability lead reviews the cards for technical consistency with the company’s published methodology notes and flags when a rating methodology or BRSR definition changes.
4. Internal audit or the risk team samples a small number of cards each quarter and reports exceptions to the audit committee before the assurance window opens.

The cadence is deliberately tied to the financial close. Cards for indicators that move with production or headcount are refreshed with the monthly or quarterly management accounts. Cards for indicators that are more stable are refreshed at least once before the assurance provider is engaged. Version control is simple: the date and the initials of the person who last signed the card. When staff turn over, the new extraction owner inherits the card and the source-system access, not a private spreadsheet. This is the same discipline finance teams already apply to the fixed-asset register or the tax computation.

6. Running a pre-assurance dry run that surfaces broken links before the external reviewer arrives

The final control is a dry run performed by the controller and one internal-audit resource before the assurance provider begins fieldwork. The dry run is mechanical. For each signed card the team attempts to re-perform the number from the named source system using the documented boundary and cut-off. Broken links are recorded as exceptions: missing access, changed system logic, undocumented estimation, or a number that cannot be reconciled to the BRSR Core workbook. Each exception is either fixed or accepted with a named residual risk before the external team arrives.

Three failure modes appear often in Indian files and are easy to catch in a dry run. First, the extraction owner has left and the new person cannot open the same report. Second, a plant has switched from manual meter reading to an automated system and the boundary has shifted without a bridge. Third, an acquisition has been included in the financial statements but not yet in the ESG extract, or vice versa. Each of these becomes an assurance finding or a rating-agency follow-up if it is discovered only during the external review. The dry run simply moves the discovery inside the company.

The dry-run report is one page. It lists only the cards that failed and the decision taken. Cards that passed are not discussed. The report goes to the audit committee as part of the pre-assurance pack. When the assurance provider later asks how management satisfied itself that the indicators were supportable, the minute can point to the dry run and the residual risks that were accepted. That is stronger evidence than a statement that “the sustainability team prepared the numbers.”

7. Field checklist before the next assurance window

Before the next BRSR Core assurance cycle or the next major rating-agency submission, the CFO should be able to answer the following questions from the lineage file alone:

• Does every BRSR Core quantitative indicator have a signed lineage card that names the source system, the extraction owner, the boundary rule, and the last refresh date?
• Can each card be re-performed from a system the statutory auditor or internal audit has already tested, or is the residual risk of estimation or incomplete coverage explicitly stated?
• Have rating-agency and lender questionnaires been answered only from signed cards or from bridges that start from signed cards?
• Has a dry run been completed and have broken links been either fixed or accepted with a named residual before the external reviewer arrives?
• Is the master file stored in the controlled finance folder, versioned, and owned by the controller rather than by a single sustainability analyst?
• Has the audit committee seen the one-page exception report so that residual risks are minuted before assurance or rating submissions are finalised?

A lineage file that meets these tests does not eliminate every data-quality question. It does ensure that the same number can be explained to an assurance provider and to a rating agency without creating parallel realities. In the Indian setting, where BRSR Core assurance is expanding and rating-agency and lender scrutiny is intensifying, that single control is the difference between a controlled disclosure process and a year-end reconstruction exercise that fails under the first external challenge.