Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →How to set recovery objectives you can defend, test them in a way that proves something, and keep a record an auditor will accept, without a continuity department.
A small team needs four things: a short business impact analysis that names the services the business cannot run without, an RTO and RPO agreed with the business and written down per critical service, a real restore test timed against the RTO, and a dated record naming who ran it, what was restored, how long it took, and what went wrong. The working cadence is a restore test at least annually and ideally quarterly, plus one continuity tabletop a year. The most common audit failure is not a missing plan. It is a plan with recovery objectives nobody derived, nobody approved, and nobody has ever tested against.
Every continuity and disaster recovery program is built on two claims, and the whole point of testing is to establish whether either is true. The first is that you can get the data back. The second is that the organization would decide to, in time, with the right people involved.
These fail independently and they are evidenced independently. A perfect backup architecture with nobody authorised to declare a disaster recovers nothing on a Sunday. A well-drilled decision process pointed at a backup that has never been restored recovers nothing at all. A program that tests only one of them has a gap that will not appear until it matters.
The distinction also determines what evidence you produce. The technical claim is evidenced by a restore test with an elapsed time on it. The organizational claim is evidenced by an exercise record with decisions in it, which is the subject of our tabletop exercise guide. Auditors ask for both, and offering one when asked for the other is a common and avoidable back-and-forth.
Small teams tend to over-invest in the first and skip the second entirely, because restoring a database is an engineering task with a satisfying end state and deciding who can take the product offline is a conversation nobody schedules.
A business impact analysis identifies what the organization does, which of those things it cannot stop doing, and how quickly each one has to come back. In a large organization this is a project. In a twenty-person company it is a two hour workshop and a table with six rows, and treating it as more than that is how it never gets done.
Work from business processes, not systems. The process is "customers can log in and use the product" or "we can invoice and collect payment" or "we can pay staff". Systems come afterwards, as the dependencies each process relies on. Starting from systems produces a list where the CI pipeline and the payroll system look equally important, because both are systems.
For each process, establish four things. What breaks for whom if it stops. How long the business can tolerate it being down before the damage changes in kind rather than degree. What the loss looks like in money, contractual exposure, or regulatory obligation. And whether there is a manual workaround, because a process with a viable workaround has a very different recovery objective from one without.
The output that matters is a ranking. Most small companies discover they have three to six genuinely critical processes and a long tail of things that can wait a week. That ranking is what stops the recovery plan from being an unusable document that treats every system as urgent.
Get it approved by someone who owns revenue. A business impact analysis signed only by engineering is an engineering opinion about business tolerance, and it will not survive the first executive who says the tolerance is actually two hours, not two days. It also will not satisfy the auditor question about whether continuity requirements came from the business.
Recovery time objective is how long a service may be unavailable before the impact becomes unacceptable. Recovery point objective is how much data you can afford to lose, measured as a period of time. They are different numbers, they are frequently confused, and confusing them produces a plan that protects against the wrong failure.
The practical guidance we work from on the ISO side is direct: agree RTO and RPO per critical service with the business and write them down. Both halves matter. Per service, because a single company-wide RTO is either far too aggressive for the low-value systems or far too relaxed for the important ones. And with the business, because a recovery objective is a statement about tolerance for harm, which is not an engineering judgment.
The test of whether a number means something is whether anything follows from it. If your stated RTO is four hours and your backup restores in nine, the number is aspirational and the gap is either a finding you accept in writing or a piece of engineering work. If your stated RPO is fifteen minutes and your database snapshots nightly, you have written down a commitment your architecture cannot keep. Auditors do not object to a long RTO. They object to an RTO the evidence contradicts.
Be careful about the relationship between your internal RTO and any availability commitment in a customer contract. If enterprise agreements promise a recovery window, the internal objective has to be at least as tight, and where it is not you have a contractual exposure that continuity testing has just discovered for you. That discovery is valuable and belongs in the risk register.
Write the numbers with their derivation next to them. "RTO four hours" is a number. "RTO four hours, because the two largest customers have a four hour credit threshold in their agreements and support volume becomes unmanageable beyond a half day" is a defensible position. The derivation is what an auditor is checking when they ask how you arrived at the objective.
Recovery plans fail on dependencies rather than on the primary system. The database restores fine and the application will not start because the secrets manager is in the same account that was compromised. The application starts and cannot send email because the transactional mail provider requires a domain verification nobody can complete. The environment comes up and no customer can reach it because the DNS is administered by a person who left.
For each critical process, list the dependencies in four categories. Infrastructure, meaning the compute, storage and network it runs on. Data, meaning the stores it reads and writes. Third parties, meaning the vendors whose availability you inherit. And people, meaning who is required to perform the recovery.
The third party column is the one that connects continuity to vendor management. If a subprocessor going down takes your product down, that is a continuity dependency and it should be reflected in how you tier that vendor and what you require of them. Our vendor and subprocessor register guide covers the criticality tiering side of that.
The people column is where small teams find their sharpest exposure. If one named engineer is the only person who has ever performed the restore, has the credentials, or knows the undocumented step, then your true recovery time is a function of that person's availability. Write that down honestly. A documented key person dependency with a plan against it is a managed risk. An undocumented one is the reason the test takes two days.
A restore test is not a check that the backup job reported success. Backup jobs report success constantly, and a backup that completes and cannot be restored is the normal failure mode, not an exotic one. The test has to end with usable data in a place where its usability can be confirmed.
A test that proves something does five things. It restores from the backup medium you would actually use in the disaster, not from a convenient local copy. It restores to a separate environment, so you learn whether the restore depends on the environment you are pretending has been lost. It is timed, from the decision to restore through to service usable, because elapsed time against the RTO is the entire point. Somebody verifies the restored data is correct and current rather than merely present. And the whole thing is performed by someone following the written procedure, ideally not the person who wrote it.
That last point is the highest-yield variation available to a small team and it costs nothing. Have the procedure executed by an engineer who has not done it before. The gaps between what the procedure says and what the author assumed are found in the first twenty minutes, and those gaps are exactly what turns a four hour RTO into a nine hour reality at 3am.
Test data verification explicitly. Restoring a database that comes up empty, or two weeks stale because the snapshot chain broke silently in March, is the outcome the test exists to catch. Define in advance what "correct" means: a row count within a stated tolerance, a known recent record present, a checksum, an application health check that exercises a real query.
Record the failures. A restore test that found three problems is a working test. A run of four consecutive quarterly tests where everything went perfectly is either a very mature environment or a test that is not being run against the real failure conditions, and a reviewer will consider the second possibility.
The evidence an auditor accepts for this control is a set of dated tests naming who ran them, what was restored, elapsed time versus the RTO, and the issues found. That sentence is close to a specification, and a record containing those five elements is rarely challenged.
Write down the scenario the test simulated. "Restored the production database to a clean staging account, simulating loss of the primary region" is a scenario. "Ran a restore" is not, and the difference determines whether the test speaks to the disaster your plan describes.
Capture three timestamps at minimum: when the restore was initiated, when data was available, and when a person confirmed the service was usable. The gap between the second and third is where teams routinely discover that data availability and service availability are hours apart, and a record that stops at the second timestamp overstates your recovery position.
State the comparison against the objective in the record itself rather than leaving it to the reader. "Elapsed 5h 40m against a stated RTO of 4h" is a finding. Do not delete the finding by adjusting the RTO afterwards, because an RTO that moves to match the test result is not an objective and an auditor comparing this year's plan to last year's will notice.
Every issue found becomes a tracked remediation item with a named owner and a due date, in the same list as your other findings. This is the same discipline that applies to any assessment run: an item that fails opens work rather than becoming a sentence in a report nobody reopens. Without it, the same three problems appear in four consecutive test records, which reads to a reviewer as a testing program that produces no improvement.
These three are often treated as a maturity ladder where you graduate from one to the next. They are better understood as three different instruments that evidence three different things, and most small teams should be running the first two indefinitely and the third rarely or never.
A continuity tabletop is a discussion of a disruption scenario against the written plan. It costs a couple of hours, tests the decision path, and finds the organizational gaps: who declares, who authorises spend, who tells customers, what the contractual notification obligations are. It cannot tell you whether the restore works.
A functional test executes one component of the recovery for real. A database restore, a failover of a single service, a rebuild of an environment from infrastructure code. It is the workhorse of a small program because it is bounded, safe, and produces a hard number.
A live failover moves real production traffic to the recovery environment. It is the only thing that proves the whole path, and it carries genuine risk of causing the outage you were insuring against. For most small teams it is not worth it, and saying so in the plan with a reason is a legitimate and defensible position. What is not defensible is claiming a failover capability in a customer contract or a trust page while having never tested it.
A fourth instrument is worth adding once the basics are running: the key person drill, where the individual who normally performs the recovery is declared unavailable and somebody else works the procedure. It is cheap and it tests the dependency that most often determines real-world recovery time.
The floor is an annual restore test, timed against the RTO. The cadence we advise, and the one that holds up best in a Type II observation window, is quarterly restore testing plus one continuity tabletop a year. Quarterly is not arbitrary: it means a broken backup chain is caught within a quarter rather than within a year, and it produces four records in a twelve month window, which is a much stronger sample than one.
Test records are contemporaneous. They only exist if they were made at the time, and that has a hard consequence for audit planning. A quarter in which no restore test was performed cannot be remedied in month eleven by running two tests. The record will show two tests dated three days apart, which evidences exactly what it looks like. The options at that point are a shorter observation window, a later report date, or an exception.
So the testing schedule is set when the observation window is set, not when someone has capacity. Put the first test in the first month of the window. That gives you room to fail it, fix the problem, and test again inside the same period, which is the strongest possible evidence: a documented failure followed by a documented correction and a passing retest.
Tie the schedule to a calendar with an owner rather than to intent. The single most common reason a quarterly control becomes an annual one is that nobody owned the date. If you are planning a window, the observation window planner is a free way to lay the recurring items against the period before you commit to it.
Continuity planning at small scale tends to import a threat model built for organizations with data centres. The failures that actually take down a twenty-person software company are narrower and more boring, and testing against the real ones is a better use of the time.
The cloud account itself is the first. A great deal of small company infrastructure lives in one provider account, with the backups in the same account. If the failure mode you are protecting against includes account compromise or accidental deletion by an administrator, backups inside the same account and the same credential boundary do not protect against it. Cross-account or cross-provider copies of the critical data are the standard answer and they are not expensive at small data volumes.
The identity provider is the second. If everything authenticates through a single identity provider and that provider is unavailable or compromised, you may be unable to log in to the systems you need for recovery. Break-glass credentials, stored offline, tested, and with their use alerted on, are the control. Testing that the break-glass account actually works is a ten minute exercise that fails surprisingly often.
The person is the third, and it is the one nobody writes down. The engineer who set up the infrastructure and holds the context is a genuine continuity dependency, and the honest way to handle it is a documented procedure plus a drill performed by somebody else.
The fourth is a critical vendor. A payments provider, an email delivery service, or a hosting dependency can take your service down without any failure on your side, and there is nothing to restore. The response is a documented degradation plan: what the product does when that vendor is unavailable, what customers are told, and by whom. We covered the broader question of what downtime actually costs a startup separately.
Testing tends to surface the same set of design problems, and knowing them in advance shortens the first cycle considerably.
Retention against the actual threat. If your backups are retained for seven days and a corruption or a quiet ransomware encryption is discovered on day nine, every backup you hold contains the problem. Retention has to exceed your realistic detection time, which for data corruption is frequently weeks rather than days.
Immutability and separate credentials. A backup that can be deleted by the same credential that administers production is a backup an attacker deletes first, and it is also the backup an engineer deletes by accident during a cleanup. Object lock, separate accounts, or a separate provider are the practical answers.
Coverage, meaning what is not backed up. Most teams back up the primary database and discover during a test that the object storage bucket holding customer uploads, the configuration held only in a running environment, or the state in a third party SaaS is not covered at all. Enumerate the data stores from the asset inventory rather than from memory, which is one of the reasons keeping the inventory true pays for itself.
Encryption key custody. Encrypted backups are correct, and a restore fails permanently if the key material was only in the environment that was lost. Where the keys live, and who can retrieve them under disaster conditions, is a question worth answering on paper before it is answered under pressure.
The requests are predictable. The continuity or recovery plan itself, approved and current. The business impact analysis or an equivalent statement of criticality. The recovery objectives per service. The test records for the period. And the corrective actions arising from the tests, with their status.
The plan is Tier 1 evidence in the sense that it either exists or it does not, and it can be sent on the day it is asked for. The test records are period evidence, which only exists if the control has actually been running, and that is the distinction that catches teams out. A polished plan with no test records behind it tells the reviewer the document was written for the audit.
Rejections cluster on four things. A test record with no elapsed time, which cannot be compared to the objective and therefore evidences an activity rather than a capability. A record with no named performer. A plan whose stated RTO is contradicted by the tests attached to it, with no finding raised about the gap. And a plan approved three years ago with no review since, which fails the currency test regardless of how good the content is.
One rejection is specific to small companies and worth pre-empting. If the plan names roles that do not exist in your organization, because it came from a template, the reviewer will read it as unadopted. Map every named role to an actual person, and where one person holds four roles, say so.
Starting from nothing, the sequence that works is impact first, objectives second, one test third, and the plan written last. Writing the plan first is the common instinct and it produces a document full of numbers nobody derived.
In the first two weeks, run the impact workshop and produce the ranked list of critical processes with their dependencies. In weeks three and four, agree the RTO and RPO per critical service with someone who owns revenue, and record the derivation. In weeks five and six, run one restore test on the single most critical data store, timed, performed by someone other than the person who built it, and write the record.
Then write the plan, using what the test taught you. The recovery procedure in the plan should be the procedure that was actually executed, with the corrections the test produced. A plan written this way is short, specific, and already evidenced.
In the last month of the quarter, run the continuity tabletop against the plan you now have, and open the findings as tracked work. At the end of a quarter you hold a business impact analysis, approved objectives, a timed test record, an exercise record and a corrective action list, which is a complete evidence set for the control and more than most companies present at their first audit.
Internally, the first cycle is roughly a week of senior time spread over a quarter. The impact workshop is two hours plus preparation. The objectives conversation is an hour. A first restore test is commonly half a day to a full day of engineering, and much less on subsequent runs once the procedure is written and the environment exists.
The recurring cost is smaller than teams expect. A quarterly restore test in a mature setup is one to three hours including the record. The reason it gets skipped is not cost, it is that nobody owns the date.
Externally, continuity and recovery testing is usually sold as a scoped exercise rather than a retainer. TrazTech runs this as a business continuity testing service line, and where it is bought as part of a readiness engagement it typically sits inside the remediation and evidence phase rather than being priced separately.
The comparison to make is against the loss the objectives themselves describe. If the impact analysis says a day of downtime costs the business a defined amount in credits, churn and staff time, then the annual cost of testing is trivially justified by any reduction in the probability of that day.
| Test type | Cadence and effort | What it proves, and what it cannot |
|---|---|---|
| Continuity tabletop | Annual. Two hours plus two to four hours preparation. | Proves the decision path, escalation and communications are understood against the written plan. Cannot prove any technical recovery works. |
| Backup restore test | Quarterly, annual at minimum. Half a day first time, one to three hours after. | Proves the data comes back, and gives an elapsed time to compare to the RTO. Cannot prove the full service path or that anyone would have decided to invoke it. |
| Restore to a separate environment | Annual. Half a day to a day. | Proves the restore does not secretly depend on the environment you are pretending was lost. Catches key custody and configuration gaps a local restore hides. |
| Environment rebuild from code | Annual. One to two days first time. | Proves the infrastructure can be recreated and finds the resources that only exist because someone made them by hand. Says nothing about data currency. |
| Key person drill | Annual. Costs only the substitution. | Proves the written procedure is followable by someone other than its author. The cheapest test available and the one that most changes real recovery time. |
| Break-glass credential test | Semi-annual. Ten to thirty minutes. | Proves you can still authenticate if the identity provider is unavailable or compromised. Fails more often than teams expect, usually on expiry. |
| Vendor outage drill | Annual. Two hours, usually as part of a tabletop. | Proves there is a degradation plan and a customer message for a dependency you cannot restore. There is nothing to fail over to, so this one is organizational by nature. |
| Single service failover | Annual to semi-annual. Half a day, plus a maintenance window. | Proves one component can move to its standby under controlled conditions. Does not prove the whole system fails over together. |
| Live production failover | Rare. Days of preparation and real risk. | The only test that proves end to end recovery under real traffic. Carries a genuine chance of causing the outage. Deciding not to run it is defensible if the decision and the reason are recorded. |
Recovery time objective is how long a service may be down before the impact becomes unacceptable, measured from the disruption to the service being usable again. Recovery point objective is how much data you can afford to lose, expressed as a period, so an RPO of one hour means you accept losing up to an hour of transactions. They drive different engineering. RTO is improved by faster recovery mechanisms and rehearsed procedures. RPO is improved by more frequent backups or replication. A plan that states one and not the other has only addressed half the problem.
Annually is the floor that most frameworks and auditors will accept, and quarterly is the cadence we advise because it limits how long a silently broken backup chain can go undetected. Quarterly also produces four records inside a twelve month observation window, which is a far stronger sample than a single test. If you can only manage one test a year, run it early in the observation window so there is room to fix what it finds and test again inside the same period.
No, and this is the most common misunderstanding in the area. A backup job reporting success establishes that data was written somewhere. It does not establish that the data can be read back, that it is complete, that it is current, or that anyone knows the procedure. Backups that complete cleanly and cannot be restored are the normal failure mode. An auditor asking for restore test evidence will not accept backup job logs, because the logs evidence a different control.
Ask a different question. Instead of asking for an acceptable downtime, ask at what point the consequences change in kind: when do customers start leaving, when does a contractual credit trigger, when does this become a public event, when do we have to tell a regulator. Those thresholds are much easier for a non-technical stakeholder to answer, and the earliest one becomes your objective. Record the reasoning next to the number, because the derivation is what makes the objective defensible.
Record the result exactly as it happened, raise it as a finding with an owner and a date, and decide between two paths: invest in shortening the recovery, or revise the objective with the business and document why the longer window is acceptable. What you must not do is quietly change the RTO in the plan to match the test result. Auditors compare plan versions, and an objective that tracks your test outcomes is not an objective. A documented miss with a corrective action against it is a healthy record.
At small scale, usually not. One document that covers the critical processes, the recovery objectives, the technical recovery procedures, the roles, and the communications is easier to keep current than two that overlap. What matters is that both dimensions are present: the technical recovery of systems and data, and the organizational continuation of the business including who decides and who tells customers. Splitting them into two documents is a convenience once they grow, not a requirement.
For most small teams, yes, and it is a reasonable engineering decision. A live production failover carries a real risk of causing the outage you are protecting against, and the preparation cost is significant. Record the decision and the reason in the plan, and be sure you are not making a claim elsewhere that only a live failover would support. If a customer contract or a public trust page promises a tested failover capability, then the claim and the testing program have to be reconciled, and the honest fix is usually to soften the claim.
Five things: the approved plan, a statement of what is critical and how quickly it must recover, the recovery objectives per service, dated test records naming who ran each test, what was restored, the elapsed time against the objective and the issues found, and the corrective actions arising from those issues with their current status. The plan can be produced on the day it is requested. The test records cannot, because they are contemporaneous and only exist if the testing was actually happening during the period.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We run the impact workshop, agree the recovery objectives with your business, and produce a timed test record an auditor will accept.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.