Can Your Business Operate Safely While Systems Are Partly Down?

Most continuity planning imagines two states: working and down. Real incidents rarely cooperate. Ransomware takes out one system and spares another. A vendor outage slows a service without stopping it. A recovery gets the database back before the application that depends on it. For hours or days, the business runs in between: partly degraded, partly fine, and improvising.

That in-between state is where the hard calls get made. Can the warehouse keep shipping at half capacity? Can the clinic see patients without the scheduling system? Can support answer tickets on a spreadsheet? Each answer trades customer harm, safety, and control risk against revenue and reputation, and it gets made under time pressure by whoever happens to be in the room.

Degraded operations are a cyber resilience discipline of their own. The organizations that handle partial outages well decided the rules in advance. The ones that struggle are deciding them live.

TLDR

• Partial outages are the norm in serious incidents, not the exception. Resilience planning that only covers full stops leaves the most common case unmanaged.

• The key question is not "can we keep going?" but "how degraded can this service get before the harm is unacceptable?" That line should be set in advance, not improvised.

• Manual workarounds keep service running but quietly bypass controls. Every fallback needs its own minimum control set and a stop condition.

• Someone must own the degraded-operations decision in the moment, with defined authority to slow, stop, or continue. Ambiguity defaults to "keep going," which is not always right.

• The board's role is to confirm the decision framework exists before it is needed: service-by-service minimums, stop conditions, named authority, and review intervals.

Why "partly down" is harder than "down"

A full outage is miserable but simple. Everyone knows the service is down, the incident plan runs, and the goal is restoration. A partial outage is ambiguous. The website works but payments time out. Email is back but the file shares are not. The ERP runs, but nobody trusts the data in it yet.

That ambiguity creates pressure to declare victory early. Customers are being served, so the incident feels contained. But degraded service carries its own risks: orders processed without fraud checks, patient records updated on paper and keyed in later, payments approved without the usual second review. The harm accumulates quietly while the organization congratulates itself on staying open.

Degraded operations cyber resilience is the discipline of deciding, service by service, how much degradation is tolerable, under what compensating controls, for how long, and who can call a stop. It sits between the incident response plan and the continuity plan, and in most organizations it belongs to no one.

The decision card every important service needs

The practical tool is unglamorous: a one-page decision card per important service, written in peacetime. Five things belong on it.

• Minimum safe service. The lowest level at which the service can run without creating unacceptable harm. Not "business as usual but slower": a specific definition, such as "counter sales only, no new account opening, card transactions capped at $500."

• Manual controls. The compensating checks that replace the automated ones. If the system normally validates every transaction, the paper process needs a named second person reviewing a sample, a daily reconciliation, or both.

• Stop conditions. The triggers that end the fallback: error rates, customer complaints, a control failure, or simply a time limit. A workaround that was acceptable for eight hours may not be acceptable for eight days.

• Decision authority. The named role that can activate the fallback, extend it, or shut the service down entirely - reachable in an incident, not a committee.

• Review interval. How often the situation is reassessed while degraded: every four hours, every shift, daily. Drift is the enemy; review intervals force the question back onto the table.

If writing this card for a service feels difficult, that is the finding. The difficulty exists in the operation whether or not the card exists.

Workarounds are control gaps with a good reason

Every manual fallback quietly suspends the controls the system enforced. Segregation of duties, automated validation, logging, access limits - the paper version of the process usually has weaker versions of all of them, or none. That is sometimes the right trade. It should be a conscious one.

Two disciplines keep workarounds honest. First, time-box them: a fallback approved for 48 hours requires a fresh decision, at a higher level, to extend. Second, reconcile them: whatever happened on paper gets entered, checked, and audited once systems return, and someone owns that cleanup. Incidents end; unreconciled workarounds linger.

A worked example (fictional)

A regional distributor loses its order management system to a ransomware event on a Tuesday. The warehouse management system still works, so the team starts taking orders by phone and email, keying them into spreadsheets, and printing pick lists. Customers are served. Morale is high.

The degraded-operation decision card for "order promise to customers" says otherwise. Minimum safe service caps phone orders at existing customers with credit already on file; the spreadsheet process has no credit check, so new-account orders are supposed to wait. The card requires a four-hour review cycle and a stop condition: if the fallback runs past 72 hours, the COO decides whether to continue. On Friday, the review surfaces two new-account orders shipped on credit that was never checked, and the 72-hour decision is made with actual facts rather than optimism. The service keeps running, on narrower rails, until the system returns the following week.

What the board should ask

• For each important service, have we defined the minimum safe level of operation during a partial outage?

• What manual controls apply when automated controls are unavailable, and who designed them?

• Who can authorize a degraded operating mode, who can end it, and how quickly can they be reached?

• What are the stop conditions and time limits on our fallback processes?

• In the last incident or exercise, how long did we run degraded, and what did the reconciliation afterward find?

If the answers describe the incident plan but not the in-between state, the organization has recovery covered and improvisation ungoverned.

Frequently asked questions

What are degraded operations in cyber resilience?

Degraded operations are the state where a business service keeps running during or after an incident but at reduced capability: slower, partially manual, or with some functions unavailable. Cyber resilience planning treats this as its own mode, with defined minimum service levels and controls, rather than assuming a clean binary of working versus down.

Isn't running on manual workarounds better than shutting down?

Sometimes, but not by default. Manual processes usually bypass the controls the system enforced - validation, segregation of duties, logging. The right answer depends on the service, the harm a degraded version can cause, and how long the fallback must run. That judgment should be made in advance and revisited on a set interval, not assumed.

Who should decide whether to keep operating in a degraded state?

A named role with defined authority, typically the executive who owns the service outcome, advised by risk and technology. The decision needs to be reachable during an incident and explicit about what they can authorize: continue, narrow, or stop. Deciding by consensus in the moment defaults to continuing, which is not always the safe choice.

How is this different from business continuity planning?

Continuity planning focuses on recovering failed functions to normal. Degraded-operations planning governs the period before recovery: how much service to offer, under what compensating controls, for how long, and under whose authority. The two plans should reference each other, but they answer different questions.

Closing

The next serious incident will probably not take everything down. It will leave the business half-running, with people making judgment calls under pressure. The organizations that come through well are the ones that made those calls calmly, months earlier, on a single page per service.