Disaster Recovery and Business Continuity Policy
This policy explains how TSS keeps working, and gets its systems and data back, when something big goes wrong: a ransomware attack, a cloud outage, the office becoming unusable, or a key person being unavailable.
Document
Policy number
TSS-IT-08
Version
1.0
Effective from
1 September 2026
Next review
March 2027
Owner
IT Team
Approved by
Board of Directors
Applies to
Every employee, trainee and intern, all TSS systems and data, and the client systems we manage.
Issued by
Thakur Systems & Structures Private Limited, CIN U62011PN2026PTC254650
Related policies
Information Security Policy (TSS-IT-02), Incident Response Policy (TSS-IT-05), Remote Work and Telecommuting Policy (TSS-HR-03), Access Control Policy (TSS-IT-11)
1. WHAT WE AIM FOR
People’s safety comes first. No system matters more than anyone’s safety.
Keep serving clients during a disruption, even if only in a reduced way.
Never lose client code or critical data.
Restore normal operations within the target times below.
2. CRITICAL SYSTEMS AND RECOVERY TARGETS
Two numbers matter for each system. The recovery point is the most data we can afford to lose, measured in time. The recovery time is how quickly the system must be working again.
| SYSTEM | RECOVERY POINT | RECOVERY TIME |
|---|---|---|
| Source code repositories | Nothing lost: every commit is held by the hosting provider and mirrored daily | 4 hours |
| SYSTEM | RECOVERY POINT | RECOVERY TIME |
|---|---|---|
| Email and workspace | 24 hours | 8 hours |
| Client production systems we manage | As set in the client contract; otherwise 24 hours | As set in the client contract; otherwise 8 hours |
| Project management and documentation | 24 hours | 1 working day |
| Payroll and accounts | 24 hours | 3 working days |
| Employee laptops | Work is kept in company systems, not only on the laptop | As soon as a replacement device is ready, normally within 3 working days |
3. BACKUPS
Three copies, two kinds of storage, one kept apart. We keep at least three copies of critical data, on two different kinds of storage, with one copy kept separately, either offline or in a separate cloud account that everyday admin accounts cannot delete.
How often. Critical data is backed up daily. Code is held continuously by the repository host, with a daily mirror.
Encrypted. All backups are encrypted.
Protected. Backups are locked against deletion or change for at least 30 days, so that ransomware cannot destroy them.
How long. Daily backups are kept for 30 days and monthly backups for 12 months, unless a client contract or the law requires something different.
Tested. At least every three months, the IT team restores a sample of backups to prove they work, and records the result.
4. WHAT WE DO WHEN SOMETHING HAPPENS
| WHAT HAPPENS | WHAT WE DO |
|---|---|
| The office cannot be used (power cut, flooding, access problem) | Everyone works remotely under the Remote Work and Telecommuting Policy |
| Home internet goes down | Use a mobile hotspot, or come to the office |
| Office internet goes down | Use mobile hotspots; move to remote work if the outage lasts more than two hours |
| A laptop fails, is lost or is stolen | The IT team issues a replacement; work carries on from company storage; a lost device is wiped remotely |
| WHAT HAPPENS | WHAT WE DO |
|---|---|
| A cloud provider or tool goes down | Check the provider’s status page; switch to the backup or alternative in the recovery plan; keep clients informed |
| Ransomware or another major attack | Follow the Incident Response Policy; isolate the affected systems; restore from protected backups once the cause has been removed |
| A key person is unavailable | Critical access and knowledge are never held by one person alone (section 5) |
| A major disaster, such as a city-wide emergency | People’s safety first; the Directors set priorities and keep everyone informed; client work resumes as soon as it is safe |
5. NO SINGLE POINTS OF FAILURE
At least two people, one of them a Director, hold admin access to each critical system, each through their own separate account.
Emergency (“break-glass”) credentials for critical systems are kept in a restricted emergency vault in the company password manager. Only the Directors can open it, and every use is logged.
Domain names, cloud accounts and code hosting are owned by the company, not by individuals, and the Directors hold the billing and recovery details.
Systems and processes are documented well enough for someone else to run them.
6. COMMUNICATION DURING A DISRUPTION
A Director decides when this plan is put into action, and tells everyone by phone, SMS or email.
Keep your phone charged and reachable during working hours.
Affected clients are told by a Director or their project lead as soon as possible, and given regular updates.
An up-to-date contact list of employees, key clients and providers is kept in the emergency vault, and on paper with the Directors.
7. TESTING AND REVIEW
At least once a year, we test the plan by restoring a critical system from backup and walking through one scenario with the team.
The plan and its targets are reviewed each March, and after any real disruption.