The compliance outcome is recoverable information
CGST Rule 57 requires proper electronic backup and preservation so that information destroyed by accident or natural causes can be restored within a reasonable period. It also requires relevant electronic records to be produced on demand, duly authenticated, in hard copy or an electronically readable format, with necessary file/access information. Merely storing a file called backup does not prove those outcomes.
Read the three requirements separately
The current ICAI GST bare-law compilation, Rule 57 and CBIC’s official rule text establish the framework checked on 26 October 2026. Subrule (1) concerns backup and restoration; subrule (2) concerns authenticated production; subrule (3) concerns file details, necessary passwords, explanations of codes, other access information and a sample print copy. This article addresses those electronic-record controls, not the separate duration-of-retention calculation under section 36.
Rule 57 does not prescribe one universal number of backup copies, a named storage product or a fixed 24-hour restoration limit. Select controls suitable for the actual records and document why they support restoration within a reasonable period. An internal recovery target is a management control, not a statutory safe harbour.
Prove that the restored population is complete
Define what belongs in the backup: relevant ledgers, invoices and other source documents, master data, adjustment histories and the information needed to interpret them. Link it to the taxpayer, period and relevant registrations or locations. Count unique records and check coverage dates. A copy of reports without the underlying data and explanations may not reproduce what a verification requires.
Use a controlled restoration test into a separate review environment. Compare restored records with an independently established expected population, investigate missing or duplicated identifiers, and reconcile financial totals. Equal record counts are not enough where values differ; equal totals are not enough where records of one period or taxpayer were substituted for another.
Readable and authenticated are different checks
An encrypted file may be securely stored but unusable if the required file key or password is unavailable. A spreadsheet may open but remain unintelligible if tax codes or document types are unexplained. Preserve the necessary decoding and access information and test production of an authenticated output in a usable format. Do not publish credentials in a routine shared report; maintain a controlled procedure for providing the access information required under a legitimate demand.
Authentication of produced records should identify the taxpayer, relevant period, source and responsible attestation. Do not invent a universal certificate format or insist that every acceptable output must be one particular file type. Subrule (2) permits hard copy or electronically readable form. Keep evidence of what was produced and how it relates to the retained electronic records.
Link recovery tests to changes in the system
Retest when software, encryption, file naming, master codes or storage arrangements change. Preserve the older interpretation material where older records depend on it. The ability to open this month’s database does not prove that an earlier archived year can be restored. Track exceptions with an owner and resolution evidence rather than closing them solely because the copy job ended successfully.
Use numerical tests without inventing legal tolerances
The examples below show population and timing diagnostics. They create no permitted missing-record percentage, no statutory recovery deadline and no compulsory software architecture. The internal target in the timing illustration is explicitly hypothetical. Restore the relevant actual information and resolve differences rather than treating a small percentage as an exemption.
Six worked illustrations
All facts and amounts below are fictional. Assumptions describe the model, not additional statutory rules.
Illustrative example 1: Successful copy, incomplete restore
The expected backup population is 5,000 unique invoices. Only 4,992 restore correctly. Eight invoices are missing, or 0.16% of the population. A “99.84% restored” result does not establish permission to omit those eight records.
Illustrative example 2: Reconstruct the expected closing population
Opening unique records are 10,000, with 500 valid additions and 200 valid removals from the relevant controlled population. Expected total is 10,300. A restored population of 10,280 leaves 20 records to reconcile. The scenario assumes the removals are lawful and their audit trail is retained; it does not authorise deletion of required records.
Illustrative example 3: Backup-date coverage gap
A usable backup covers through 30 September 2026. An incident occurs before the opening of business on 7 October, and records for 1–6 October are not in that backup. Six calendar days of activity need a supported recovery source. A file timestamp alone does not recover the missing transactions.
Illustrative example 4: Internal recovery target versus the legal wording
A hypothetical internal target is 24 hours. Restoration starts at 09:00 on 1 June and completes at 15:30 on 2 June: 30.5 hours elapsed, 6.5 hours beyond that target. This identifies a control exception; Rule 57 itself uses “reasonable period”, not a universal 24-hour deadline.
Illustrative example 5: Files open, code explanations missing
Of 100 relevant restored files, 75 can be interpreted with the retained code/key information and 25 cannot. The supported interpretable population is 75%, leaving 25 files for remediation. Encryption or code opacity is not cured merely by counting all 100 files as copied.
Illustrative example 6: Equal counts, different values
Both source and restored schedules show 1,000 records. The source balance bridge is ₹10,000 + ₹5,000 − ₹3,000 = ₹12,000, but the restored report closes at ₹11,900. The ₹100 difference requires value-level investigation even though the record counts agree.
Ten-step verification table
| Step | Action | Evidence |
|---|---|---|
| 1 | Define the statutory record population | Taxpayer, period, documents, masters and relevant registrations. |
| 2 | Map backup coverage | Files, dates and sources required to reconstruct the information. |
| 3 | Preserve access dependencies | Keys/passwords and code explanations under controlled custody. |
| 4 | Perform a restoration test | Separate environment and dated test evidence. |
| 5 | Compare unique record counts | Expected population, missing IDs and duplicates. |
| 6 | Reconcile financial totals | Source-to-restored balances and transaction amounts. |
| 7 | Check coverage gaps | Activity after the last usable backup and recovery sources. |
| 8 | Test readable production | Authenticated hard-copy or electronic output and sample print. |
| 9 | Assess reasonable restoration time | Documented internal target, elapsed time and unresolved causes. |
| 10 | Close and retest exceptions | Responsible owner, corrections and evidence after system changes. |
Sixteen practitioner FAQs
1. Is a backup filename proof of compliance?
No. Establish that the relevant information can be restored and produced as required.
2. Does Rule 57 prescribe a named cloud or ERP product?
No. Choose an appropriate supported implementation without inventing a prescribed brand.
3. Is 24 hours the universal statutory recovery deadline?
No. The rule uses restoration within a reasonable period; the 24-hour example is an internal target only.
4. Can a missing-record percentage be treated as an exemption?
No tolerance percentage is created by these examples or by the cited rule wording.
5. What population should the test cover?
The relevant required information, including the supporting data and interpretation material needed to reproduce it.
6. Are equal record counts sufficient?
No. Compare identifiers, periods and values as well.
7. Are equal totals sufficient?
No. Different or substituted records can still produce the same total.
8. Must encrypted files be readable by an unauthorised public user?
No. Maintain controlled access while ensuring the necessary information can be supplied under the applicable demand.
9. What does subrule (3) address?
File details, necessary passwords, code explanations, other required access information and a sample print copy.
10. Does an unexplained tax code become acceptable because the file opens?
No. Preserve the explanation needed to interpret the relevant records.
11. Is only paper output allowed?
No. Subrule (2) refers to hard copy or electronically readable format, duly authenticated.
12. Does this guide prescribe one authentication certificate?
No. It identifies the required outcome without inventing a universal form.
13. Why test older archives after a software change?
Older files may depend on a previous format, key or code mapping even when current files open correctly.
14. Can an old backup cover later transactions automatically?
No. Identify and recover the activity after its coverage date from supported sources.
15. Does the valid-removal illustration permit statutory records to be deleted?
No. Lawful population changes and retained audit history are explicit assumptions, not a deletion authorisation.
16. What should the final evidence file show?
The expected information, restored information, completeness/value tests, production capability, timing assessment and resolution of exceptions.
Conclusion
A backup is useful only if GST records can be restored and produced in an authenticated, readable form. Rule 57 requires proper backup and access information; test completeness, decoding and reconciliation instead of relying on a successful-copy message.