DSC Signing for BRSR Reports — Authorised Signatory, Assurance Certificate, and Filing Workflow

Why DSC signing matters for BRSR

A BRSR filing is not accepted by the stock exchange portal without a valid Digital Signature Certificate (DSC) on the submission. The DSC is what binds the filing to the authorised signatory and gives it legal standing as a regulated submission under SEBI LODR. Without a DSC that matches the authorised-signatory framework, the BRSR submission fails at the portal level — and the filing window for the Annual Report has no slack for a multi-day DSC re-procurement.

This guide walks through the DSC mechanics for a BRSR engagement: which DSC is needed, who signs what, the two distinct DSC signing events in an assurance-attached BRSR, and the practical pitfalls that recur across filing cycles.

For BRSR with assurance, two separate DSC signings are involved: the partner CA firm’s signing partner signs the assurance certificate under their own DSC, and the entity’s authorised signatory signs the BRSR PDF / XBRL submission under the entity’s authorised-signatory DSC. Both signed artefacts go into the filing package.

What a BRSR filing actually consists of

A BRSR submission to the stock exchange portal includes:

• BRSR PDF — the human-readable BRSR report, typically published as part of the Annual Report or filed alongside it
• BRSR XBRL — the same content in machine-readable XBRL format, generated using the NSE / BSE BRSR XBRL utility (compatible across both exchanges)
• Assurance certificate (where applicable) — for entities within the BRSR Core reasonable-assurance phase-in, the partner CA firm’s signed assurance certificate is attached. The entity’s BRSR PDF references the assurance opinion; the signed certificate is included in the filing package.

Per SEBI / exchange guidance, BRSR is typically submitted on the same day as the Annual Report. The PDF, XBRL, and (where applicable) assurance certificate together form the BRSR filing package.

The portal path on NSE NEAPS is commonly NEAPS > Common XBRL Upload > Business Responsibility & Sustainability Report. On BSE, the filing goes through BSE Listing Centre. Refer to the latest NSE / BSE BRSR filing circulars for current portal paths and any procedural amendments.

DSC class and authorised-signatory rules

Per SEBI’s July 2020 circular on the use of digital signature certifications for filings to stock exchanges and the broader CCA framework that governs DSC issuance in India, the standard for stock exchange filings is a Class 3 individual Digital Signature Certificate issued by a CCA-licensed Certifying Authority (eMudhra, Sify, NSDL e-Gov, Capricorn, (n)Code, IDSign, etc.).

Key practical points on Indian DSC architecture for entity filings:

• DSCs are issued to natural persons, not entities. The certificate is in the name of the individual; the organisational role (Director, CFO, CS, etc.) is specified within the certificate. The authorised signatory’s individual DSC is what signs the entity’s filing.
• Class 3 is the common standard for regulatory filings. Class 3 DSCs require physical or video-KYC verification by the Registration Authority and are referenced across MCA, GST, Income Tax, and SEBI / exchange filing portals as the typical class for filings of this nature. Confirm the specific class requirement against the latest applicable circular for the filing.
• DSC validity is typically 1-3 years. Renewal must be done at the CCA-licensed CA before expiry; expired DSCs are not accepted by filing portals.

The list of who is authorised to sign on behalf of the entity flows from the Board resolution authorising filings under SEBI LODR Regulations — typically including the MD / WTD / CEO / CFO / CS, with the specific designations subject to the entity’s authorisation framework. The BRSR signatory should match the authorisation framework reflected in the entity’s filing register.

The two DSC signing events in an assurance-attached BRSR

For BRSR Core (or extended-scope) assurance engagements, two distinct DSC events occur in the filing workflow:

Event 1 — Partner CA firm signs the assurance certificate

The signing partner of the partner CA firm executing the BRSR Core assurance engagement signs the assurance certificate / opinion under their own individual DSC (issued in the partner’s name with the firm’s affiliation). The signed assurance certificate goes onto the partner CA firm’s letterhead and is delivered to the entity for inclusion in the BRSR filing package.

This event is independent of the entity’s BRSR submission — the assurance partner does not log into NEAPS / BSE Listing Centre to file anything. They sign the assurance opinion on their own infrastructure and deliver it.

Event 2 — Entity’s authorised signatory signs the BRSR submission

The entity’s authorised signatory — typically MD / CEO / CFO / CS, per Board authorisation — logs into the relevant filing portal (NEAPS / BSE Listing Centre) and signs the BRSR PDF + XBRL submission under their individual DSC. The signed assurance certificate from Event 1 is attached as part of the submission package.

The two signing events are sequential: assurance partner signs first (so the assurance certificate exists), entity signatory signs and submits second (with the assurance certificate attached).

This separation matters because the partner CA firm’s DSC never appears on the BRSR PDF or XBRL submission itself — only on the attached assurance certificate. The BRSR filing is the entity’s filing under the entity’s signatory DSC, with assurance attached.

Filing workflow — practical sequence

The below describes the commonly observed sequence for an assurance-attached BRSR filing. The exact portal mechanics evolve across NSE / BSE circular updates; refer to the latest circulars for current step-by-step.

1. Audit completion — the partner CA firm completes the assurance procedures over the BRSR Core KPIs (or extended scope) and concludes on the assurance opinion.
2. Assurance certificate signed — the signing partner signs the assurance certificate on the partner CA firm’s letterhead, under their own DSC. The signed certificate is delivered to the entity.
3. BRSR PDF finalised — the entity finalises the BRSR PDF with the signed assurance certificate referenced and / or attached.
4. XBRL generation — the entity generates the BRSR XBRL using the NSE / BSE BRSR XBRL utility from the finalised PDF content. Most entities run a pre-validation pass to catch tagging / structure issues before submission.
5. Authorised signatory signs the submission — the entity’s authorised signatory logs into the relevant filing portal, attaches the BRSR PDF + XBRL + signed assurance certificate, and signs the submission under their individual DSC.
6. Acknowledgement — the portal returns a filing acknowledgement; the entity records the acknowledgement against the filing register for audit-trail purposes.

For dual-listed entities, steps 5-6 are repeated on each exchange’s portal.

Common DSC-related pitfalls observed in BRSR engagements

These are common practice patterns observed in filing-window BRSR engagements — not SEBI-recognised categories of finding. Each is framed as an observation, not a categorical rule.

1. DSC expiry mid-cycle is the single most common DSC issue. Authorised signatory’s DSC expiring days before the filing deadline is a recurring near-miss. Build the DSC validity register into the BRSR engagement plan; flag any DSC expiring within 60 days of the expected filing window for renewal.

2. DSC role mismatch between certificate and document. Indian DSC architecture issues certificates to individuals with their organisational role specified in the certificate. If the person whose DSC signs is not the person named in the BRSR document as the authorised filer (a common edge case after a CFO / CS transition mid-cycle), the filing fails or carries a remediation note.

3. Late DSC procurement for newly-appointed signatories. A newly-appointed CFO / CS typically takes 1-3 working days to procure a Class 3 DSC from a CCA-licensed CA. If the appointment is recent (post-Board meeting that approved the BRSR), build the DSC procurement timeline into the filing-window plan.

4. Multi-signer workflow timing. When the assurance partner DSC and entity signatory DSC are needed sequentially, the engagement letter should reflect the sequencing — assurance partner needs to sign first so the certificate exists for attachment; entity submits second. Compressed filing windows where both happen on the same day require coordinated scheduling.

5. Cross-portal DSC compatibility. A DSC valid for NEAPS may need to be re-registered / activated on BSE Listing Centre (and vice versa) depending on the platform’s user-management framework. Pre-validate DSC registration on every relevant exchange portal before the filing-day rush.

6. DSC password / token misplacement. Class 3 DSCs are typically issued on USB cryptographic tokens (eMudhra, ePass, ProxKey, etc.) with a token-specific PIN. Loss of the token or the PIN inside the filing window requires re-issuance, which is a multi-day blocker. Maintain an authorised-signatory DSC inventory with the PIN handling per the entity’s IT-security policy.

Where Batchwise fits in the DSC workflow

Batchwise coordinates the BRSR engagement end-to-end (data collection, AI-structuring, partner CA assurance, filing-package assembly) but does not sign any DSC itself. The DSC workflow stays with the entity (for the BRSR submission) and the partner CA firm (for the assurance certificate). Batchwise’s role in the DSC workflow is:

• Engagement timeline that flags the assurance certificate signing event and the entity’s filing-day signing event as distinct dependencies
• DSC validity check at engagement kick-off (to flag any DSC expiry risk in the filing window)
• Pre-validation of the BRSR XBRL output before the entity logs into the portal
• Coordination of the signed assurance certificate delivery from the partner CA firm to the entity
• Filing-package assembly (PDF + XBRL + assurance certificate, ready for the entity’s authorised signatory to attach and sign)

The signed assurance opinion always comes out under the partner CA firm’s letterhead and signing partner’s DSC — Batchwise’s name does not appear on the assurance opinion.

What this guide captures and what it doesn’t

Captures:

• The two DSC signing events in an assurance-attached BRSR
• DSC class and authorised-signatory rules at the practical level
• The common pitfalls that recur in filing-window BRSR work
• Where Batchwise’s coordination role sits relative to the DSC workflow

Doesn’t capture:

• The procedural details of any specific Certifying Authority’s DSC issuance flow (eMudhra, Sify, NSDL e-Gov, etc. each have their own portal flows — refer to the CA’s own user manual)
• BRSR Core assurance methodology (covered in the BRSR Core Assurance service page)
• BRSR XBRL taxonomy itself (covered in the XBRL Taxonomy for BRSR methodology page)
• Stock exchange portal user-management for new entities — refer to the NSE / BSE portal onboarding documentation

Related reading

• XBRL Taxonomy for BRSR — the underlying XBRL structure that the filing utility produces
• Document Evidence Requirements — what the partner CA firm reviews before signing the assurance certificate
• BRSR Core Assurance Service — engagement scope including the assurance certificate that gets attached to the filing
• Materiality Assessment Walkthrough — earlier in the BRSR engagement timeline
• Scope 3 Emissions for Service Companies — Leadership disclosure prep that may sit alongside the BRSR Core assurance engagement