What continuity actually is
Business continuity has an image problem. It sounds like a binder, a consultant, and a hundred pages nobody reads, produced for a business far larger than yours. That version exists and it is not what this page is about.
Underneath the apparatus, continuity is three questions with numbers for answers:
- What has to keep working for us to trade? Usually three things, not thirty.
- How long could we be without each one? An hour, a day, a week. The formal name is the recovery time objective, and it decides what you should spend.
- How much recent work could we afford to lose? The recovery point objective, and it is what your backup schedule should be derived from rather than guessed at.
That is it. The international standard for this, ISO 22301, calls the exercise of answering them a business impact analysis, and everything else in the discipline is prioritised against the answers. If you have those three numbers written down and agreed, you are ahead of most businesses your size, and you can make sensible decisions about everything below.
The backup nobody has ever restored
If you take one thing from this page, take this one. It is the highest-value hour on the list and almost nobody has spent it.
Backups fail quietly and in specific, repeatable ways. The job reports success while silently skipping the database. The retention was thirty days and the corruption started thirty-five days ago. The backup is in the same cloud account as the thing it protects, so whatever deleted one deletes both. The restore works but takes eleven hours, and nobody knew that until the day it mattered. The file restores and nobody can remember the passphrase.
Every one of those is invisible until somebody actually restores. A backup that has never been restored is not a backup, it is a hope with a schedule attached.
The part that is now law
Continuity used to be purely a commercial judgement in India. That changed with the DPDP Rules, and the link is more direct than most summaries make it look.
Among the enumerated reasonable security safeguards is reasonable measures for continued processing in the event of confidentiality, integrity or availability of personal data being compromised, such as by way of data-backups. The same rule sets one year as the retention period for logs and personal data unless another law requires otherwise.
So for any business holding personal data — which is very nearly all of them — continuity is not only an operational choice. It sits inside the security obligation. The DPDP readiness hub covers the rest of that regime.
Then there are the clocks, and there are two of them:
The CERT-In Directions carry no size exemption: they reach companies, startups and MSMEs operating in India alike. The six hours runs from becoming aware of a qualifying incident, not from the incident.
Six hours is the shorter clock and it is the one people have not heard of. It does not leave room to work out who decides. Both routes belong on one page, with a name against each, written before the day.
How this actually fails in an owner-led business
Not servers. In the businesses we work with, continuity fails in four recognisable ways and only one of them is technical.
- One person is the system. They know how the pricing sheet works, which supplier to call, how the month-end close goes. The business runs beautifully until they are unreachable for a fortnight, and then it does not run at all. This is the most common outage in a small business and it has nothing to do with computers.
- Nobody else can get in.The domain registrar is on one person’s personal email. The one-time passwords go to one phone. Access recovery, not system recovery, is usually the longest part of a real incident, and it is entirely preventable in advance.
- The knowledge is in a WhatsApp group. Which is genuinely a reasonable way to run a business until it is the only record of a decision, and then it is unsearchable, unbacked-up, and belongs to whoever has the handset.
- The backup was never restored. Covered above, because it deserves its own section.
We have written two pieces about specific versions of this — a database with no backup, and what breaks when a single-location business becomes a two-location one. They are linked beside this page.
What happens here on a bad day?
Ten questions, in the browser, nothing submitted. It reports where recovery is real, where it is assumed, and which single item would buy you the most if you did it this week.
What happens here on a bad day?
Ten questions, about two minutes. It reports where recovery is real, where it is assumed, and which single item would buy you the most if you did it this week.
Question 1 of 10
The checklist, yours to keep
The whole thing as a working document, in the order we would do it: decide what matters, make recovery real, remove the single points of failure, know the reporting clocks, then rehearse.
26 items across 5 stages, with what "done" looks like for each. One page, printable, no email required.
If you only do stage 2, you will have got most of the value on this page.
What we do, if you want help
Continuity work for a business this size is not a binder. It is a fortnight of unglamorous engineering, and most of it is things you could do yourself with the checklist above — we are saying so plainly because it is true.
What we are useful for:
- Running the restore test and telling you what the measured recovery time actually is, rather than what the plan says.
- Separating backups from the accounts they protect, and setting the schedule from your recovery point objective instead of the default.
- Getting the knowledge out of one person’s head and the WhatsApp group into something searchable.
- Writing the incident sequence, with both reporting routes and a name against each.
The price
There is no packaged product on this page, and we are not going to invent one to have something to sell you. What there is instead is the studio’s ordinary engagement ladder, published, and the same for everybody.
Thirty minutes. We look at where the work actually goes and tell you whether there is anything here worth building. No pitch on it.
The three numbers agreed and written down, a real restore test with the measured recovery time, backups separated from what they protect, the single points of failure documented, and the incident sequence written with both reporting routes in it.
Typical delivery window: four to eight weeks. Fixed fee, agreed before we start.
Keeping it true as the business changes: the restore test actually run on a schedule, and the documentation kept current rather than aging quietly.
Optional, and only after a first fix. It buys standing availability, not discounted build hours — anything beyond the monthly allowance is priced as a new fix.
If the honest answer after the call is that you do not need us yet, that is the answer you will get. Tell us what you are dealing with, or get in touch.
Where to read more
The two pieces beside this page are the specific ones. Alongside them:
- DPDP readiness— the regime that makes backups a security safeguard rather than a preference.
- Our case studies— including what we found in our own systems when we ran these checks on ourselves.
- Our research series— long-form, cited, and every number labelled measured, assumed or unknown.
- ERP systems and AI automation— because “it is all in a WhatsApp group” is usually a systems problem wearing a continuity costume.
Sources
Everything factual on this page traces to one of these. Where a link is absent it is because we did not have a stable public one to give, not because the source is vague — the reference number is there so you can look the instrument up yourself.
- ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements · International Organization for Standardization · 2019
- The Digital Personal Data Protection Rules, 2025 · Ministry of Electronics and Information Technology · 13 November 2025 · G.S.R. 846(E)
- Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 relating to information security practices, procedure, prevention, response and reporting of cyber incidents · Indian Computer Emergency Response Team (CERT-In) · 28 April 2022, effective 27 June 2022