ISO 27001 does not require a business impact analysis. You can build an ISMS, pass your certification audit and never once ask the question "how long can we actually survive without this process?"
Plenty of organisations do exactly that. And then, in the risk assessment, they hit a wall.
Someone has to rate the impact of "ransomware encrypts the ERP system". A three? A four? On what basis? In most workshops I've sat in, the answer is a gut feeling from whoever spoke most confidently. The number goes into the register, the treatment plan is built on it, and the backup schedule under A.8.13 is justified by... nothing in particular.
That's the gap a BIA closes. It gives you the business justification for your information security requirements before you start assessing risks. The risk assessment then has something solid to stand on, and the availability side of your CIA triad stops being a guess.
Here is how it works. I'll use the same example I use in my ISO 22301 trainings: a brewery.
First, three terms you'll need
Before any analysis, you need a shared vocabulary. ISO 22301 gives you one.
MTPD / RTO / RPO timeline with minimum capacity
Picture normal operations at 100 %. Then the lightning strike: ransomware, fire, a supplier collapse, a power outage. Operations drop to zero.
The first management question is not "how fast do we get back to 100 %?" It's "what is the minimum we can live with?" A brewery doesn't need marketing running the day after a fire. It needs to brew and ship. That floor is the minimum acceptable capacity (older documents call it MBCO).
Three brackets sit on top of that picture:
MTPD (maximum tolerable period of disruption): the point after which the impact of not resuming an activity becomes unacceptable to the organisation. This is the pain threshold the business dictates.
RTO (recovery time objective): the target you set for resuming the activity at minimum capacity. RTO is always shorter than MTPD. As an auditor, that relationship is one of the first things I check.
RPO (recovery point objective): the only bracket that starts before the incident. It's the point in time to which you can restore data. In practice, RPO is what determines your backup frequency, which is exactly the number A.8.13 never tells you how to derive.
GRCLab is now a community
LinkedIn is drowning in AI slop. Countless GRC posts a day, none of them written by someone who has ever done the work.
And it's not just the feed. If your job is reciting clauses and filling templates, an AI is already doing it faster.
The practitioners who understand the business, make the judgment calls and defend them in front of an auditor are not getting replaced. That's the GRC practitioner AI can't replace, and it's what GRCLab is for.
P.S. Your first question in there could be about this BIA.
The BIA in three steps
1. Preparation: define the method
A BIA is only as good as its scale. Before you interview anyone, define the impact types that matter for your organisation. In the brewery example, those are financial impact, reputation, legal and regulatory consequences, life safety, business objectives and market share.
Then define what a 1, 2, 3 and 4 mean for each of them. "Financial impact is tolerable" versus "financial impact threatens the existence of the organisation" is a very different conversation from "medium" versus "high".
Finally, fix the time horizons you'll assess against. I use 24 hours, 3 days, 1 week, 2 weeks and 1 month. That gives you the second axis of the matrix.
2. Execution: assess impact over time
Now you sit down with the process owners. Not IT. The people who actually run the brewing line, sales, logistics.
For each activity, you walk through the time horizons and ask: if this stopped now, what is the impact after 24 hours? After 3 days? After a week? For the brewing process, the financial curve might look like this.
And reputation like this.
Put the two together and the MTPD falls out of the table. The first cell that hits the level you defined as "unacceptable" in preparation is your answer. For the brewery, that's one week.
Notice what just happened. Nobody guessed. The business told you, in its own terms, how long it can tolerate the brewing process being down. The RTO you set afterwards has to land inside that week.
3. Evaluation: map it to resources
This is the step that connects the BIA to your ISMS. Activities don't fail on their own. Resources do: hardware, software, network, people, premises, the organisation itself.
So you trace each prioritised activity back to the resources it depends on, and the activity's RTO becomes a requirement on each of them. The plant control system supports the brewing process, so it inherits a one-week RTO. The ERP system supports brewing and sales; sales has an MTPD of three days, so the ERP system gets the stricter value.
Now look at what you're holding. A prioritised list of activities. Their dependencies, including suppliers. A defensible RTO and RPO for every critical system. Contact persons. Single points of failure.
That is the input your risk assessment was missing.
Why this changes your risk assessment
When you assess "ransomware on the ERP system" after a BIA, the impact rating isn't a debate. The ERP system carries a three-day RTO, a defined RPO, and you know exactly which activities go dark if it fails. The impact score is derived, not negotiated.
The same logic feeds your treatment decisions. Why is the backup interval four hours and not daily? Because the RPO for the sales process says so. Why does the plant control system need a tested restore procedure? Because the brewing process has a one-week MTPD. Every availability control in your Statement of Applicability now has a reason that an auditor can trace back to the business.
ISO 27001 doesn't require any of this. But 8.2 of ISO 22301 describes it in a page and a half, and a first pass for a mid-sized organisation is a matter of days, not months. Given what it does for the quality of your risk register, I'd do it every time.