Picture this. It’s 2 AM, your incident channel is blowing up, and three systems are down at the same time. The CTO wants the client portal restored first. The VP of Sales is screaming about the CRM. The CFO says payroll is due tomorrow. And nobody has a pre-agreed answer to the question that matters most: what do we bring back first?
That’s what a Business Impact Analysis prevents. A BIA forces your organization to answer the hard questions before the crisis hits, so that when something breaks, the response is driven by business priorities instead of by whoever shouts the loudest.
CISO Assistant lets you attach security objectives and disaster recovery targets to every asset in your inventory. Once you’ve done that, you have a clear, pre-agreed map of what matters most and how fast it needs to come back. This guide walks you through actually doing it.
What you get out of a BIA
A completed BIA gives you recovery priorities - which systems to restore first when multiple things fail at once. It sets recovery time targets you can use for capacity planning and contract negotiations. It defines data loss tolerance, which directly determines backup frequency. It creates a security classification for every asset. It also gives you hard evidence for budget conversations when you need to justify redundancy, better backups, or higher SLAs.
Without a BIA, all of that is guesswork. With one, it’s a documented agreement.
The two dimensions CISO Assistant captures
BIA in CISO Assistant works through two complementary sets of objectives on each asset.
Security objectives
These rate how important each security property is for a given asset, on a 1-to-4 scale. The properties are Confidentiality (how bad is it if the wrong person reads this data), Integrity (how bad is it if someone modifies it without authorization), Availability (how bad is it if the system goes offline), Proof/Non-repudiation (do you need an audit trail), Authenticity (how important is it to verify the source), Privacy (does this handle personal data), and Safety (could a failure cause physical harm).
The scale runs from 1 (minimal impact) through 2 (noticeable but manageable) and 3 (serious impact on operations or reputation) up to 4 (severe harm, regulatory consequences, potential existential threat).
Disaster recovery objectives
These are the concrete time-based targets that drive your operational planning. RTO is how quickly you need to restore service. RPO is how much data loss you can tolerate, measured in time since the last backup. MTD is the absolute limit before the damage becomes permanent and irreversible.
The relationship between these three matters. Your RPO directly determines your backup frequency, and if your current backup schedule doesn’t match your RPO, you’ve found a gap. We see this mismatch in about half the organizations we work with.
Make sure your asset inventory is complete
Before you can analyze impact, you need to know what you’re protecting. Head to Context > Assets and make sure everything is registered. Your inventory should cover identity and security systems (password managers, identity providers, SIEM platforms), cloud infrastructure, code repositories and intellectual property, productivity and communication tools, business applications like your CRM, ATS, and invoicing system, documents and data categories, physical infrastructure including offices and network gear, devices, and external services like recruitment agencies and accounting firms.
If you haven’t built your asset inventory yet, start with our asset management guide. A BIA on an incomplete inventory is worse than no BIA at all, because it gives you false confidence.
Classify each asset’s security objectives
This is where the real work begins. Go to each asset, click Edit, and set the security objectives. We’ve organized this by category with our recommended ratings and, more importantly, the reasoning behind them.
Identity and security systems
Your password manager and identity provider are the keys to the kingdom. If these are compromised, everything else is exposed.
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| Password Manager (1Password) | 4 | 4 | 3 | 3 | 4 | 3 | 2 |
| Identity Provider (JumpCloud) | 4 | 4 | 4 | 3 | 4 | 3 | 2 |
Confidentiality and Integrity are both 4 because these systems store credentials for everything. A leak or tampering is catastrophic, full stop. Availability is 3-4 because people literally cannot work without authentication. Authenticity is 4 because you need to be certain these systems are genuine and not spoofed.
Cloud infrastructure
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| AWS / Azure / GCP | 3 | 4 | 4 | 3 | 3 | 3 | 2 |
Integrity gets a 4 because data modification in production could be catastrophic. Availability is 4 because cloud downtime means service outage. We keep Confidentiality at 3 rather than 4 because cloud providers have their own security layers, but a misconfiguration on your side is still very damaging.
Code repositories
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| GitHub | 3 | 4 | 3 | 4 | 3 | 2 | 1 |
Integrity is 4 because unauthorized code changes could introduce backdoors. Proof is 4 because you absolutely need an audit trail of who committed what and when. Privacy stays at 2 because code shouldn’t contain personal data (though we’ve seen plenty of repos with secrets committed by accident).
Financial systems
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| Finance Application / Invoicing | 4 | 4 | 3 | 4 | 4 | 4 | 2 |
Almost everything is high here because financial data is both sensitive and regulated. Financial records contain client data, tax IDs, transaction history. Every financial transaction must be auditable. There’s not a lot of room to cut corners.
Productivity tools
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| Google Workspace | 3 | 3 | 4 | 2 | 3 | 3 | 1 |
| Slack | 2 | 2 | 3 | 2 | 2 | 2 | 1 |
| Jira / Confluence | 2 | 3 | 3 | 3 | 2 | 2 | 1 |
The differences here are intentional. Google Workspace gets Availability 4 because email downtime halts all business communication. Slack is lower across the board because, while losing messaging is annoying, you can survive on email as a fallback. Jira’s Integrity is 3 because project data accuracy matters for delivery commitments.
Documents
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| Strategic/Legal/Financial Docs | 4 | 3 | 2 | 3 | 3 | 4 | 1 |
| Project Documentation | 2 | 3 | 2 | 2 | 2 | 2 | 1 |
| Sales Documents | 3 | 2 | 2 | 2 | 2 | 2 | 1 |
Strategic and legal documents are highly confidential and contain private information, but they don’t need to be available instantly. A few days without access is tolerable. Project docs have higher Integrity because incorrect specs lead to wrong deliverables, and that costs real money.
Physical locations and network devices
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| Office Locations | 2 | 2 | 3 | 2 | 2 | 2 | 3 |
| Network Devices | 3 | 4 | 4 | 3 | 3 | 2 | 3 |
Offices get Safety at 3 because people work there and physical safety matters. Network devices get Availability and Integrity at 4 because a network failure or compromise cuts everyone off from everything.
AI systems
| Asset | C | I | A | P | Au | Pr | S |
|---|---|---|---|---|---|---|---|
| AI Tooling (ChatGPT, Claude, etc.) | 3 | 3 | 3 | 2 | 3 | 4 | 1 |
Privacy is 4 here, and this is the one that catches people off guard. Employees share personal data and client information in AI prompts more often than anyone would like to admit. These tools are load-bearing walls in many organizations now, whether leadership officially acknowledges it or not.
Set disaster recovery objectives
Same edit form, different fields. For each asset, set your RTO, RPO, and MTD.
Identity and security systems need to come back fast because everything depends on them. If people can’t authenticate, they can’t work. We recommend an RTO of 4 hours, RPO of 2 hours, and MTD of 24 hours.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| Password Manager | 4 hours | 2 hours | 24 hours |
| Identity Provider | 4 hours | 2 hours | 24 hours |
Cloud infrastructure needs to be back within a business day. An RPO of 4 hours means you need at minimum 4-hourly snapshots or continuous replication.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| AWS / Azure / GCP | 8 hours | 4 hours | 48 hours |
Code repositories have more tolerance because developers can work from local copies for a day. The real risk is data loss, and losing 8 hours of committed code across teams would be painful but recoverable.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| GitHub | 24 hours | 8 hours | 72 hours |
Productivity and communication tools fall in the same tier. People can survive a day with workarounds, but beyond that things start breaking down.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| Google Workspace / Email | 24 hours | 8 hours | 72 hours |
| Slack / Teams | 24 hours | 8 hours | 72 hours |
| Jira / Confluence | 24 hours | 8 hours | 72 hours |
Financial systems can tolerate slightly longer downtime, but data loss is expensive.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| Finance / Invoicing | 24 hours | 8 hours | 72 hours |
| External Accounting | 72 hours | 24 hours | 1 week |
Network devices need fast recovery because they’re the backbone. Workstations and mobile devices have more flexibility.
| Asset | RTO | RPO | MTD |
|---|---|---|---|
| Network Devices | 8 hours | 4 hours | 48 hours |
| Workstations | 24 hours | 8 hours | 72 hours |
| Mobile Devices | 72 hours | 24 hours | 1 week |
Documents, physical locations, and external services are the most tolerant, with RTOs ranging from 72 hours to a week.
Validate with the people who actually use the systems
The numbers above are starting points, not gospel. The real BIA requires uncomfortable conversations with business owners. For each critical asset, ask them: if this went down right now, what would stop working? How long before it becomes a real problem, not just an inconvenience? How much data could you afford to lose? What’s the absolute worst case?
We’ve seen plenty of surprises come out of these conversations. The IT team might think the knowledge base can wait a week, but the onboarding team needs it within 48 hours because new employees can’t start without it. Those disconnects matter, and the only way to find them is to ask.
Put BIA results to work
Once your BIA is complete, it should drive actual decisions. Your RPO values directly determine backup frequency. An RPO of 2 hours means you need backups at least every 2 hours. If your current backup frequency doesn’t match, that’s a gap you need to close immediately.
Your RTO tells you what SLA you need from each provider. A 4-hour RTO means you need a premium SLA with guaranteed response times. A 24-hour RTO means standard business SLA is probably fine.
When multiple systems fail simultaneously, your RTO values give you the recovery order. Identity and authentication first (4h), then cloud infrastructure and network devices (8h), then email and communication (24h), then business apps and workstations (24-48h), then documents and archives (72h+).
And for budget conversations, BIA results are hard evidence. “Our password manager has a 4-hour RTO but our current disaster recovery plan takes 12 hours to restore it” is a concrete argument for investing in hot standby capability.
How BIA connects to everything else
Your BIA feeds directly into risk assessment. An asset rated C=4, I=4 that’s linked to an “Unauthorized Data Access” risk scenario carries more weight than the risk scenario alone. It shows auditors and management exactly why that risk matters and what the real-world consequences would be.
In CISO Assistant, this connection happens automatically once you set security objectives and DR targets on your assets, link those assets to risk scenarios, and link applied controls to those same scenarios. The result is a complete chain from asset (with business impact values) through risk scenario to the controls that mitigate it.
When to revisit
Do a full BIA review annually as part of your ISMS cycle. But also revisit it whenever you adopt a new system rated criticality 3 or 4, after any real incident that tested your recovery capabilities, when business processes change significantly, and before major infrastructure moves like cloud migrations or vendor switches.
After a real incident is actually the most valuable time to revisit. Nothing reveals whether your estimates were right like actual downtime.
Your BIA is a practical agreement about what matters most to your organization and how fast you need it back. Get it right, and incident response becomes a plan instead of a panic. Get it wrong, and you’re back to 2 AM arguments about whose system matters more.
With your BIA complete, the natural next steps are building risk scenarios around your highest-impact assets and creating your Statement of Applicability to document the controls that protect them. If third-party services scored high in your BIA, our vendor security management guide will help you assess and monitor those dependencies.
