Testing and defence led by a published security researcher with six CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, CPCSC, 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 →Most companies have a business continuity plan. Far fewer have evidence that anybody has ever run it, and the requirements name the test rather than the document. ISO 27001 A.5.30 puts testing inside the control. SOC 2 A1.3 asks the entity to test recovery procedures. We facilitate the exercise, run the restore, and produce the record.
Scope a testAvailability obligations are the ones companies most often discover late, usually because a customer asked for uptime commitments the architecture was never tested against.
| Framework | Status | What it requires | Evidence expected |
|---|---|---|---|
| ISO/IEC 27001:2022A.5.29 | Required | Information security must be maintained during disruption. The organisation must plan how to maintain security at an appropriate level during a disruptive event, rather than allowing controls to lapse in an emergency. | Documented arrangements, and evidence they have been verified rather than assumed. |
| ISO/IEC 27001:2022A.5.30 | Required | ICT readiness for business continuity must be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements. Testing is written into the control itself. | Test records, results, and the plan revisions that followed. |
| SOC 2A1.2 and A1.3 | Required | Where Availability is in scope, the entity must authorise, design, develop, implement and maintain environmental protections, software, data backup processes and recovery infrastructure, and must test recovery plan procedures supporting system recovery. | Backup configuration, restore evidence, and a dated test of the recovery procedures. |
| HIPAA Security Rule45 CFR 164.308(a)(7) | Required | A contingency plan is required, including a data backup plan, a disaster recovery plan and an emergency mode operation plan. Testing and revision procedures, and applications and data criticality analysis, are addressable specifications. | The three required plans, plus a documented decision and rationale on the addressable specifications. |
| PCI DSS v4.012.10.1 | Required | The incident response plan must include business recovery and continuity procedures, and the plan must be tested at least once every twelve months. | A plan covering continuity, and the annual test record. |
| ISO 22301Full BCMS standard | Conditional | Where a customer or regulator asks for a certified business continuity management system rather than the continuity controls inside ISO 27001, ISO 22301 is the standard that applies. | A full BCMS. Worth confirming that this is genuinely what was asked for, because it usually is not. |
Availability is a scoping decision with a long tail. Adding Availability to a SOC 2 report brings A1.2 and A1.3 into play, which means your backups, your recovery infrastructure and your recovery testing all get sampled. It is often the right call, particularly for infrastructure products where leaving it out invites the question of why. It should be a decision rather than a default, and we work through it during SOC 2 scoping.
The after-action report is the deliverable auditors sample. Everything else exists to make that report worth something.
Which processes matter, what they depend on, and what an hour of downtime actually costs. Everything downstream, including your recovery targets, is guesswork without this.
Recovery time and recovery point objectives your architecture can actually meet. A four-hour RTO written against nightly backups is a commitment you will miss in front of an auditor or a customer.
Step by step, written so somebody who was not there when it was designed can follow it at 3am. That constraint is the whole test of whether it is any good.
A facilitated scenario walked through with the people who would run it, capturing the decisions, the gaps and the assumptions nobody knew they were making.
Actually restoring from backup and confirming the data is usable. An untested backup is a hypothesis, and a surprising number of them turn out to be wrong.
What was tested, what happened, what failed and what changed as a result. This is the artifact auditors sample under SOC 2 A1.3 and ISO 27001 A.5.30.
The plan updated from what the test found, because a test that changes nothing was a rehearsal of the wrong thing.
What we do not do. We do not operate your infrastructure or run your failover in production. We facilitate the exercise, work alongside your engineers on the restore, and document what actually happened. If the test shows your architecture cannot meet the objectives you have committed to, we will say so in the report rather than around it.
If Availability is in scope, yes. A1.3 requires the entity to test recovery plan procedures supporting system recovery to meet its objectives. If your report covers Security only, it is not directly required, though backup and recovery still surface through the common criteria. This is one of the better reasons to think carefully before adding Availability to your scope.
Annually is the baseline nearly everywhere, and PCI DSS 12.10.2 makes twelve months explicit. ISO 27001 A.5.30 requires testing without naming an interval, which means you set one and then have to meet it. A significant architecture change generally justifies a test outside the normal cycle, because the plan you tested was written for an architecture you no longer run.
A tabletop is a facilitated discussion: the team walks through a scenario and says what they would do. It is cheap, it surfaces assumptions and gaps quickly, and it does not prove the technology works. A functional test actually restores data or fails over. Most programmes need both, and most only do the first. Auditors increasingly ask which one you did.
Usually not. ISO 27001 A.5.29 and A.5.30 cover information security continuity and ICT readiness, which satisfies most customer requirements. ISO 22301 is a full business continuity management system with its own certification, and it is worth pursuing when a customer or regulator has specifically asked for it. We will tell you which one you were actually asked for before you spend anything.
RTO is how long you can be down: the time between the disruption and service being restored. RPO is how much data you can afford to lose: the time between your last usable backup and the disruption. They are set by the business impact analysis, not by what your current setup happens to achieve, and the gap between the two is usually where the investment decision sits.
Automated backups are not the same as tested restores. The common failures are backups that complete successfully but exclude a critical volume, restores that take far longer than the RTO assumes, and encrypted backups whose keys live only in the system that is down. None of these are visible until somebody tries, which is why the restore test is the deliverable rather than the backup configuration.
Not because a framework demands it, and we will not pretend otherwise. It is because the people who wrote the runbook cannot find the steps they assumed, since they are the ones who assumed them. An outside facilitator asks the naive questions and records what actually happened rather than what was supposed to happen. Where genuine independence is required, that is internal audit work.
They overlap and they are not the same. Incident response handles a security event: containment, eradication, notification. Business continuity handles loss of availability whatever the cause, including causes with no attacker at all. PCI DSS folds continuity into the incident response plan; ISO 27001 keeps them as separate controls. Most companies need both, and our incident response work covers the other half.
Track record
We are deliberately not a large firm, and we would rather show you the work than a wall of logos. Here is what is behind the advice.
Before founding traztech, Jacob was Head of Operations at Humera, a venture-backed US security company whose bot-detection platform sits in the request path of its customers' applications, and he built its compliance programme in-house: no report, no policies, no documented controls at the start. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15, having inventoried 60-plus assets and put a five-stage change-approval flow in front of production.
The platform stayed at 99.9% uptime and sub-100ms latency throughout, which is the part most readiness projects get wrong: controls are easy to design and hard to add to a system people are already depending on. That programme is why we sell fixed windows rather than open-ended retainers.
For a Waterloo data centre operator we scoped and assessed SOC 2 Type II (Security, Availability and Confidentiality) against ISO 27001:2022 including the Climate Action Amendment, run together rather than one after the other. Scope covered the production campus, a datacenter platform, an AI compute platform and a self-hosted collaboration stack, written so further Ontario and Quebec sites enter as they reach production. Findings delivered and remediated.
For an Ontario medtech company putting an AI clinical assistant in front of practitioners, we ran the gap analysis and built the evidence programme behind their SOC 2.
Before you go
Short notes on the evidence behind common controls, including what a recovery test record needs to contain. Unsubscribe in one click, and replies reach me directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.