Business Continuity Planning: Defending Your Company from Cyber Attacks

Business continuity after a cyberattack is the ability to keep critical activities operating safely while systems are investigated, contained and restored. It is not a promise that an organization can immediately restart every server. Ransomware may make production systems untrustworthy; compromised identity infrastructure may block administrators; and a clean backup can still be unusable because a payment gateway, supplier interface or signing key is unavailable. A credible plan addresses business functions, information dependencies and the evidence required to make restoration decisions.

The best starting point is a business impact analysis (BIA). Operations leaders identify what must continue, the maximum disruption their business can tolerate, the amount of data loss a process can accept and how a degraded manual process would work. Security, infrastructure, legal and communications teams then design technical recovery to support those priorities. This is consistent with the long-standing contingency-planning concepts in NIST SP 800-34 Revision 1, while NIST SP 800-61 Revision 3 (finalized April 2025) brings incident response into the broader Cybersecurity Framework 2.0 context.

Start with the business process, not with the storage system

Suppose an online retailer has an order-entry service, warehouse dispatch, customer notification and invoicing. An IT-only recovery list might name the web server and database first. A business-led list asks whether warehouse staff can safely fulfill an already-paid order when fraud screening is offline, whether a shipment can be traced without the normal identifier service, and which customer promises must be paused. The answers reveal dependencies on identity, data integrity, network connectivity, staff, payment processors and third-party services.

Each critical function should have an accountable owner and a documented minimum service level. Record manual fallback procedures, who can authorize them, maximum safe duration, records to capture and how to reconcile those records after restoration. Manual workarounds can introduce new fraud or privacy risks, so they require controls and rehearsals. A paper list of customer addresses is not automatically an acceptable substitute for a protected dispatch system.

For the supporting systems, record where critical data resides, who is accountable for it, and how it is classified through its lifecycle. That work connects continuity planning with asset ownership and data lifecycle responsibilities: restoration teams cannot reliably prioritize services whose data stores and owners are unknown.

Recovery time and recovery point are different decisions

Recovery time objective (RTO) expresses the targeted time to restore a defined function or service after disruption. Recovery point objective (RPO) expresses the targeted age of the last recoverable state, usually in time. Neither guarantees actual performance. If a database is restored from a copy produced three hours before the attack, the data gap must be explained even when the server restarts quickly. If a replica contains the same unauthorized changes as the primary, a nominally zero-minute replication lag does not make the replica clean.

Set recovery priorities at business-process level and map them to an application dependency graph. A service can be technically online yet unusable if authentication, domain-name resolution, a payment partner or a critical data feed is missing. Define the evidence required to state that the recovery objective was met, including transaction reconciliation, correct authorization and representative user tests.

Choose a recovery architecture according to those documented constraints. Backup and restore, pilot light, warm standby, and multi-site recovery models differ in ongoing capacity, cost, achievable recovery targets and operational complexity. More replicas can improve availability, but can also carry corrupted data or compromised credentials into a second environment if isolation and restoration points are neglected.

Cyber recovery is not identical to routine disaster recovery

A power outage or failed disk may leave system trust largely intact. After a cyber intrusion, the operating system, backup consoles, directory services, administrator accounts and software build pipelines may all be suspect. Restoring from a replica without investigating that trust boundary may reintroduce the attacker. Incident response must therefore cooperate with recovery, even when business leaders are under severe pressure to bring services online.

Define the conditions for containment, forensic preservation, restoration and reactivation. Evidence that a server is malware-free is not simply a clean antivirus scan. Depending on the incident, the team may require rebuilt endpoints, independent credential rotation, protected backups, trusted images, updated detection coverage and review of known attacker persistence paths. Work with investigators to preserve evidence without unnecessarily delaying essential business functions.

The destructive NotPetya incident illustrates how software supply-chain compromise and wiper-like behavior can turn local compromise into large-scale operational disruption. Its lessons for incident recovery and supply-chain trust are useful because backup strategy alone is insufficient if identity, deployment channels and network boundaries remain exposed.

Protect backup systems from the production trust boundary

A recovery copy must be available when production administrators are locked out or compromised. Use separation of duties, limited administrative paths, strong authentication, retention protections, immutable or offline copies where appropriate, and independent monitoring of deletion or policy changes. Test restore operations with representative datasets and key material. An immutable copy that cannot be read because its encryption key is missing will not save the business.

Retention requires thought. Short retention can miss slow-moving intrusions, while indefinite retention can increase legal, cost and privacy exposure. Reconcile the business need, regulatory duties, forensics and expected attack dwell time. Treat the backed-up configuration and the instructions for rebuilding systems as protected assets, not as documents on the same file share as production.

For applications with user-generated transactions, record how to replay or reconcile data received between the backup’s recovery point and the disruption. Specify the party authorized to adjudicate conflicting orders, payments, identities or access logs. Recovering a database is different from proving that downstream business records remain accurate.

Assign real decision authority before an incident

A continuity plan should name the executive incident sponsor, business function owners, technical recovery lead, incident commander, legal/privacy contacts, communications owner, external suppliers and people authorized to activate fallbacks. It must also distinguish who may declare an incident, who may isolate production resources and who can approve returning a recovered system to service. When one decision-maker becomes unavailable, escalation and delegation must still work.

Maintain separate emergency communication channels and contact lists that do not depend entirely on the breached identity or email environment. Include regulator, partner and customer notifications as conditional legal and contractual obligations, not universal messages sent at a fixed hour. A clear internal status report distinguishes what is known, what is suspected, what is being tested and when the next decision will be made.

The plan should acknowledge human capacity. Continuous crisis staffing for days is unsustainable without relief and handover. Record shift-change notes, evidence custody, recovery dependencies and unresolved risks so critical decisions are not made only from memory.

Rehearse failure modes, not just restore commands

A useful tabletop might start with a ransomware alert shortly before a sales peak: monitoring indicates suspicious administrative access, the identity provider is unstable, and the newest backups may contain a compromised deployment. Ask which business services can be safely stopped, how customer obligations will be handled, what forensic evidence must be protected and which copies can be trusted. A technical exercise then verifies the chosen procedures in an isolated environment.

Measure more than whether an application eventually starts. Track time to identify a trusted recovery point, time to restore critical dependencies, verified data gap, test-user success, missing evidence, communications delays and manual transaction reconciliation. Assign owners and dates to corrective actions. Run another exercise after major application, cloud, identity, vendor or staffing changes.

The goal is not a flawless playbook. It is a realistic, practiced ability to protect people and records, maintain safe core services, and restore trustworthy operations when normal assumptions fail. Continuity maturity is demonstrated through repeatable evidence of recovery—not by the number of pages in the binder.

• Category: All Certifications CyberSecurity
• Tags: Attacks, Business, Cyber, Cyber Attacks, Planning