Emergency Planning & Incident Response

When a security breach (an incident) or system failure (an event) hits your business, having a structured, documented and tested protocol turns potential chaos into a more orderly recovery process.
There are seven steps to the Incident Response process. The IR process actually begins before there is an incident.
Step 1 has two parts, The first part is to compile a set of proceedures for when an incident is first detected. There should be one or more printed documents in binders, preferrably stored off site. This procedure set should contain the followings:
- a list of needed contacts - people and organizations to contact when an event or incident is first detected.
- sets of forms for documenting the incident or event.
- hardware isolation procedures - what to do - and not do - until the "first responders" arrive.

Items Ranked by Priority

These items cover immediate triage procedures first, followed by forensic and regulatory readiness.

1. No Verified Contacts List

Why It’s a Threat: Lacking a clear, printed list of emergency contacts may lead to wasted hours and confusion when a cyber event is first detected.

Real-World Example: Staff discovers encrypted ransomware files on Monday morning and spend three hours searching for IT support numbers while the infection spreads to backup drives.

Solution: Maintain a printed "Emergency Recall Card" with direct phone numbers for IT support, insurance carriers, bank fraud units, law enforcement and legal advisors.

2. Cyber Insurance Not Evaluated

Why It’s a Threat: Operating without knowing whether your policy covers ransomware, legal fees, or business interruption leaves you exposed to unexpected recovery costs.

Real-World Example: A business files a claim after a ransomware attack, only to discover their general liability policy excludes cyber incidents entirely.

Solution: Review your insurance coverage annually with your agent to verify policy limits, deductibles, and required security controls.

3. Ransom Payment Policy Undefined

Why It’s a Threat: Lacking a clear executive policy regarding extortion demands leads to poor choices made under panic during an active attack.

Real-World Example: A panicked owner pays a cryptocurrency ransom demand directly, but extorters take the money and send back a broken decryption key.

Solution: Establish a clear executive policy focusing recovery efforts on isolated backups and law enforcement consultation rather than extorter negotiations.

4. Destruction of Evidence During Triage

Why It’s a Threat: Powering down infected machines or immediately reformatting drives erases the digital evidence needed to prove how the breach occurred or qualify for insurance payouts.

Real-World Example: An employee sees a malware popup and holds down the power button to shut down the PC, erasing RAM memory artifacts needed by forensic investigators.

Solution: Unplug the Ethernet cable or disconnect Wi-Fi to isolate the computer from the network, but leave the machine powered on until technical help arrives.

5. Lack of Pre-Drafted Breach Communications

Why It’s a Threat: Scrambling to write client notices during a crisis leads to inaccurate statements that increase legal liability.

Real-World Example: A firm sends a rushed email claiming "no client data was compromised," only for forensic analysis a week later to prove records were exposed, forcing an embarrassing retraction.

Solution: Prepare pre-approved notification templates for customers, staff, and regulators before an incident occurs.

6. No Manual Downtime Contingency Plan

Why It’s a Threat: Lacking paper workarounds means business operations grind to a complete halt if primary computers or internet lines go offline.

Real-World Example: A office scheduling system crashes during a cyber outage, and without paper appointment logs, staff must turn away clients all day.

Solution: Document offline workflows so staff can continue taking phone calls, processing manual orders, or servicing clients during a digital blackout.

7. Disabled System & Network Logging

Why It’s a Threat: Disabling event logs on routers and servers makes it impossible to trace an intruder's entry point or confirm what confidential files were accessed.

Real-World Example: An email account is hijacked, but because event logging was turned off in cloud settings, technical support cannot confirm what files were viewed.

Solution: Ensure basic security logging is active across all operating systems, office routers, and cloud platforms.

8. Log Retention Periods Set Too Short

Why It’s a Threat: Overwriting system logs every few days erases the historical record before technical investigators can analyze a long-term breach.

Real-World Example: An intruder is discovered six weeks after entering a network, but firewall logs overwrite themselves every 7 days, destroying all record of the entry point.

Solution: Configure log sizes and retention schedules to preserve system event records for at least 90 to 180 days.

9. Ignoring Legal Breach Notification Deadlines

Why It’s a Threat: Ignoring state reporting mandates regarding stolen personal data exposes your business to severe state regulatory fines and customer lawsuits.

Real-World Example: A firm quietly cleans up a database breach without notifying affected clients; months later, stolen records surface online and regulators fine the firm for missed reporting deadlines.

Solution: Identify state reporting laws ahead of time so you know exactly who must be notified and within what timeframe if data is exposed.

10. Untested Restoration Speeds

Why It’s a Threat: Assuming backups will restore systems instantly without testing recovery speeds leaves you unprepared for multi-day operational blackouts.

Real-World Example: A business attempts to restore 2 Terabytes of data from a cloud backup after a crash, discovering the slow download connection will take 9 full days to finish.

Solution: Conduct twice-yearly restore drills to measure the exact hours required to rebuild servers and recover data from backup drives.