Expectations around cyber recovery are getting tighter. 66% of CEOs expect to hear about an attack within 30 minutes, while 38% expect basic operations to resume within a day.
For many firms, that 24-hour window is achievable, though it does not mark the end of the incident. Establishing the full scope of a breach can take days or weeks, particularly when attackers move through multiple systems.
The focus for that first day is getting the most important services running safely. How realistic that is depends largely on the preparation already in place when an attack happens.
Why It Matters: A 24-hour recovery target puts technology resilience under a clear deadline. Infrastructure, backup systems and business continuity plans need to support that timeline before an incident happens. Testing can show where those plans fall short and give firms a concrete basis for deciding where to invest. If critical services cannot return within the expected timeframe, the business needs to account for that risk.
- Define Minimum Viable Operations: Each service relies on other technology to function, and those dependencies determine what teams need to restore first. A customer application may be online, for example, yet remain unusable while its identity service is offline. Mapping these relationships gives teams a recovery sequence based on what the business actually needs to operate.
- Pre-Authorize Containment Decisions: During an active attack, teams may need to isolate networks or shut down systems before they have the full picture. Requiring another round of approvals can give an attacker more time to reach other parts of the environment. Pre-approved thresholds establish when teams can act and how much authority they have. The decision still requires judgment, since disconnecting unaffected systems can add unnecessary disruption and make recovery harder. Plans should also cover false positives, including how teams return services to normal operation when containment turns out to be unnecessary.
- Check Backups Before Relying on Them: An attacker who reaches the backup environment may leave behind a vulnerability or another way into production. Restoring that backup can return the same security problem along with the data, leaving a firm dealing with another incident days later. Recovery procedures need to establish that backups are clean before teams use them and that important services return to an environment they can trust.
- Limit the Recovery Scope: Network architecture can determine how much work follows an attack. Segmentation can contain an intrusion within a smaller part of the environment, leaving fewer systems to investigate or rebuild. Asset visibility then helps teams establish what may have been reached and how affected systems connect. A contained group of workloads creates a very different recovery timeline from an incident that reaches a large portion of the network.
- Put the 24-Hour Target to the Test: Exercises can replace assumptions about recovery time with actual restoration data. They can show how long an essential service takes to return when systems are unavailable and expose dependencies that recovery documentation missed. Other issues may only become apparent under those conditions, such as response instructions sitting on inaccessible infrastructure or normal communication channels going offline. If the same service repeatedly takes longer than 24 hours to restore, firms have a specific recovery gap to address before an actual incident.
