Incident Response Plan for Businesses: The Complete Guide

At 1:30 a.m., the owner of a distribution company in Lampung is woken by a call from his night-shift employee. "Sir, all the files on the warehouse computers have turned into .encrypted. There's a message on the screen demanding a ransom in Bitcoin." He sits on the edge of the bed, trying to think. Who should he call? His IT person is on leave. How long can operations stay down? Is customer data encrypted too? What will he tell customers in the morning? He has no answer to any of those questions.

Cyber incidents never arrive during office hours. They arrive as a strange email, a duplicate invoice from an unknown vendor, a login from another city at three in the morning, or a server that suddenly becomes slow. And when they do, the most expensive question is not "why did this happen?" but "who does what next?"

The answer to that question is not born when the incident happens. It is born earlier, in a document most Indonesian businesses do not yet have: an incident response plan (IRP).

This article is a complete guide to building an incident response plan for your business: what it contains, who is responsible for what, how each response phase works, a runbook template you can adapt, estimated costs, and the common mistakes that make even a good plan fail in the field.

What Is an Incident Response Plan

An incident response plan is a written document containing procedures to detect, respond to, contain, and recover from security incidents. It answers the practical questions that suddenly become critical in the middle of a panic: who gets called first, who has the authority to shut systems down, how customers are notified, and when the business can resume operations.

Note the difference from regular security guidance. Security guidance is about prevention: how to install firewalls, update systems, manage passwords. An incident response plan is about "after the failure": what happens when prevention is not enough. The two complement each other like a seatbelt and an airbag. The seatbelt (prevention) reduces the risk of a crash. The airbag (IRP) determines whether you survive once the crash happens.

A single incident handled poorly can turn a small technical problem into a legal, financial, and reputational crisis all at once. Conversely, a well-rehearsed response can compress recovery from weeks to days and stop the damage from spreading to systems that were still safe.

Why "We Will Think About It Later" Always Fails

There is a recurring pattern in many businesses: "We are a small team; cyber incidents are a big-company problem." The data says otherwise. The Verizon Data Breach Investigations Report, published every year, shows that a large share of successful breaches actually hit smaller organizations, and most breaches involve a human element, such as an employee falling for a phishing email or misconfiguring a system. Attackers do not choose targets by size; they choose targets by ease.

In Indonesia, the National Cyber and Crypto Agency (BSSN) continues to record hundreds of millions of attack attempts against digital infrastructure every year. Most fail or cause no harm, but a single success is enough to halt operations for days. Global research from IBM estimates the average cost of a single data breach at millions of US dollars, with average time to identify and contain an incident stretching for months. During that whole period, data keeps flowing out unnoticed.

These numbers tell you two things. First, an incident is a matter of "when," not "if." Second, the largest cost of an incident usually comes not from the attack itself, but from a slow, chaotic response caused by having no plan. It is like a fire: a small flame put out in the first five minutes has a very different fate from a fire left burning while people look for the extinguisher.

Without a plan, decisions get made under pressure, by whoever has the loudest voice, without clear authority. With a plan, decisions were already made long ago, with a clear head, and just need to be executed.

Which Incidents Should Be in the Plan

A good incident response plan does not only cover hacker attacks involving malware. The following list covers the incident types most common in Indonesian businesses, and each deserves its own procedure:

• Malware and ransomware. A device or server gets infected, files get encrypted, or systems behave strangely. This is the most common incident type and the most expensive to recover from.
• Successful phishing. An employee enters credentials into a fake page or downloads a malicious attachment. This is often the entry point for a larger incident.
• Data breach. Customer or employee data is exposed, whether through hacking, a misconfigured cloud storage left open to the public, or a lost device.
• Account takeover. Email, social media, or internal system accounts get hijacked. This includes business WhatsApp accounts used to send scam messages to customers.
• DDoS attacks. Your services are flooded with traffic until they become unreachable. Sometimes accompanied by extortion.
• Financial fraud. Unauthorized money transfers, fake invoices, or payment manipulation by insiders or outsiders.
• Third-party incidents. A vendor or service provider suffers an incident that drags your data along with it. This is becoming more common as more businesses depend on cloud services.

Each incident type has a slightly different response pattern, but they all follow the same phase framework. That framework is what we will build next.

The Incident Response Team: Who Does What

A plan without owners is just paper. This is where many IRPs fail: the document is thick and neat, but no names are mentioned.

For small and medium businesses, the incident response team does not need to be large. What matters is that roles are clear. Here is a structure that generally works, noting that one person can hold more than one role:

The two roles most often forgotten: scribe and backup. A timeline recorded from the first minute becomes review material and legal evidence if the case goes to court. Backup roles matter because incidents never care who is on leave. In a small team, make sure every role has at least two people who know the job.

In the plan, write names, job titles, and personal phone numbers for every role holder, not office numbers that go unanswered at 2 a.m. Update this list every time there is staff turnover.

Four Severity Levels: So Not Everything Is an Emergency

One classic mistake of teams that just got an IRP: every incident is treated with the same urgency. A phishing email sitting in the spam folder gets the same response as ransomware locking the production server. Energy drains away on small stuff while the big one runs unmanaged.

The solution is a severity classification agreed on in advance:

The rule of thumb: if an incident touches customer data, money, or the availability of public services, it is at least level 2. Do not wait for complete evidence before raising the level — it is safer to overreact than to underreact and regret it.

The Emergency Contact List You Must Have

This is the section of the IRP most often used and least often updated. Keep the list in two places: a printed copy held by leadership, and a digital version accessible without logging into the system that may be under attack. It should include:

• Internal team: every role holder (personal numbers, not office extensions).
• Hosting and domain providers: support numbers that handle incidents, not sales.
• Cloud service providers: priority support channels if you have them.
• Maintenance vendors or IT consultants: including an incident response retainer contract if you have one.
• Payment gateways and banks: hotlines for handling unauthorized transactions.
• Legal counsel: to assess UU PDP obligations and reporting decisions.
• Authorities: BSSN and the Presidential Staff Office have cyber incident reporting channels; Kominfo also receives reports related to UU PDP (official mechanisms continue to be refined as implementing regulations are issued).
• Cyber insurance: claims number, if your policy covers cyber incidents.

Test this list once a year: call every number and confirm it still works. You do not want to discover a dead number on the night of your first incident.

The Six Phases of Incident Response

The most widely used framework in the industry comes from NIST (National Institute of Standards and Technology): Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. These six phases apply to businesses of every scale, from a small digital shop to a public company.

1. Preparation

This phase happens before any incident: drafting the document, training the team, and preparing the tools. Good preparation makes every later phase faster. It includes:

• A written IRP approved by leadership, not just a draft on the IT person's laptop.
• Minimum tooling: tested backups, log monitoring, managed admin access with two-factor authentication, and emergency accounts activated only during incidents.
• Regular training and simulation (covered in detail later).
• An asset inventory: a list of all systems, databases, and critical data that must be prioritized during recovery. Without an inventory, the team will debate mid-incident about which system matters most.

2. Identification

An incident is detected. This phase's job: confirm it is a real incident and not a false alarm, then assess its scope and severity level.

Practical steps:

• Gather initial evidence: screenshots, logs, emails, suspicious files. Do not delete anything, including the attacker's messages.
• Record the time of discovery, symptoms, and affected systems.
• Answer three questions: What happened? How wide is the impact? How fast is it spreading?
• Determine the severity level and activate the plan at that level.

The common mistake in this phase: either dismissing it too quickly ("probably just a normal virus") or panicking and shutting everything down without evidence. Good identification needs speed and calmness at the same time. If the internal team is not sure, do not hesitate to call in external help — a wrong identification at the start cascades into every later phase.

3. Containment

This phase has one goal: stop the spread. The fire must be cut off before it is put out.

Common containment steps:

• Isolate affected systems from the network (disconnect from the internet or the internal network), but do not power them off before evidence is secured — memory and processes lost during a reboot can destroy critical evidence.
• Rotate credentials for systems that may be affected: passwords, tokens, login sessions.
• Block suspicious IP addresses and domains at the firewall.
• If the attack is active, take affected services offline temporarily. A few hours of lost sales is far cheaper than a breach spreading for days.

Containment decisions are often hard on the business side: shutting down a server means stopping order intake. That is why this decision must be delegated in advance. The Incident Commander has the authority to shut systems down without waiting for a committee meeting — the value of the plan is that you already approved this decision long before you needed it.

4. Eradication

The cause of the incident is removed from the systems. This is not just deleting a malicious file; this is making sure the root cause is truly clean:

• Remove malware and suspicious files, including the backdoors attackers often leave behind.
• Close the exploited gap: patch systems, update plugins, fix configurations.
• Check other systems that may have been silently infected — attackers rarely stop at one machine.
• Restore data from clean backups made before the incident. Make sure the backup itself is tested and was not infected too.

Many businesses skip this phase and simply restore from an old backup that still contains the same vulnerability. The result: the same incident repeats within weeks.

5. Recovery

Systems return to normal operations, in a controlled way. The key: slow and verified, not all at once with fingers crossed.

• Bring back the most critical systems first, with extra monitoring.
• Verify data integrity: is the restored data complete and undamaged?
• Watch for indicators of compromise: suspicious logins, strange outbound connections, file changes. The first few days after recovery are the most fragile period.
• Communicate recovery status to customers and employees according to the communications plan.

6. Lessons Learned

This is the most skipped phase and the one that most determines the future of the business. One to two weeks after an incident is resolved, hold a review meeting and ask five questions:

• What happened, with the full timeline?
• What went well in the response?
• What went badly, and why?
• What gap was exploited, and how do we close it?
• What needs to change in the plan, the team, or the tools?

The output of the review must be actions with deadlines and owners, not just meeting notes. A business that does not learn from its incident will repeat the same incident at a higher cost.

Runbooks: Procedures You Can Execute While Panicking

The ideal IRP document in the real world is one that can be executed by a person shaking at 3 a.m. Long theory does not help; concrete steps do. That is where runbooks come in.

A runbook is a step-by-step procedure per incident type. The format is simple: the step, who does it, and what output is expected. Here is a sample ransomware runbook structure:

1. Detect (first responder): record the time, symptoms, and affected systems. Screenshot the ransom note. Do not reboot. → Output: initial record.
2. Activate the plan (Incident Commander): set the severity level, call the core team. → Output: active level status.
3. Contain (first responder): disconnect affected systems from the network while preserving evidence. → Output: spread stopped.
4. Notify (Communications + Legal): prepare internal messages, assess reporting obligations to customers and authorities under UU PDP (no later than 3 x 24 hours for personal data protection failures). → Output: approved messages.
5. Recover (first responder): check clean backups, restore priority systems, verify. → Output: systems running.
6. Review (everyone): identify the entry point, close the gap, update the runbook. → Output: scheduled follow-ups.

Build a runbook for every incident type listed at the start of this article. Six to eight pages of dense, practical procedure beats a hundred pages of theory. Many teams keep runbooks somewhere quickly accessible: a shared folder, a board in the server room, or a team notes app.

Communication During an Incident: Rules to Agree On in Advance

The aspect that most often destroys a business's reputation after an incident is not the technical side but the communication: denials that turn out to be false, silences that turn out to be harmful, or statements that get misinterpreted.

Set communication rules from day one:

• One voice. All outgoing information goes through one person (the Communications role) or through messages it approves. Other employees are asked not to comment on the incident on social media, even with good intentions.
• Facts first, analysis later. State what is known: the incident type, when it was detected, what is being done. Analysis of the cause ("believed to be...") should only be shared if supported by evidence, always with a timeframe.
• Never blame. Publicly pointing at an employee as the culprit destroys the reporting culture, which is exactly what delays the next incident's discovery.
• Tailor to the audience. Customers need answers to "is my data safe and what should I do" — not technical details. Authorities need reports in the applicable format. Employees need clear instructions on expected behavior.

If an incident involves personal data, communication rules shift from ethics to legal obligation: UU PDP requires data controllers to notify the failure of personal data protection in writing to data subjects and relevant authorities no later than 3 x 24 hours, stating what data was exposed, when and how it was exposed, and the handling and recovery efforts undertaken. Delaying or hiding is not just unethical; it opens the door to administrative sanctions of up to two percent of a legal entity's annual revenue.

Practice: Tabletop Exercises for Small Teams

A plan that has never been tested is an assumption. Training does not have to be expensive or complex; the most effective format for small businesses is the tabletop exercise: a half-day meeting where a facilitator reads an incident scenario and the team answers "what do we do now?" step by step.

A sample scenario: "Monday morning, three employees report a strange email asking them to re-login to their office email accounts. Two of them already entered their passwords. An hour later, one of those accounts sends a fake invoice to three major customers. What do you do?"

During the exercise, pay attention not only to the answers, but to the questions that arise: "Which hosting vendor contact do we have?", "Who is allowed to talk to customers?", "When was the last backup?" — every question the team cannot answer is a gap in the plan that needs patching.

Schedule tabletop exercises twice a year. Between sessions, update the plan whenever something major changes: switching service providers, new people in key positions, or new systems holding customer data.

In-House or Outsourcing: Estimated Costs in Indonesia

The second most common question after "where do I start" is "how much does it cost?". There is no fixed price, but here are the ranges commonly seen in the Indonesian market, ordered from small to large:

These figures are market estimates, not quotes. Read the direction: prevention and readiness investments are almost always far smaller than the cost of one prolonged incident. Compare that with global research putting the average cost of a single data breach in the billions of rupiah once recovery, customer churn, and sanctions are counted — and you will see that a plan is not an expense but a discount on losses.

One note: an incident response retainer contract is best signed before an incident, not after. A vendor that arrives while you are panicking knows you have no bargaining power. A vendor that already knows your systems from normal conditions can work far faster — and speed is what determines the size of the damage.

Common Mistakes That Make an IRP Fail

Many businesses already have a plan, but the plan fails when tested. The failure patterns we see most often:

• The document is stored on the system under attack. An emergency plan must be accessible without logging into the internal network. Print a copy, or store it in a separate cloud account with dedicated credentials.
• No names. A plan that refers to "the IT team" without names and personal phone numbers cannot be executed at 2 a.m.
• Never practiced. A plan only read during audits is decoration. Without simulation, people do not know their roles when adrenaline peaks.
• Stale contacts. Vendors with changed contacts, employees who moved on — an outdated contact list is a silently dead plan.
• Technical tunnel vision. A plan that ignores customer communication, legal obligations, and business aspects produces technically successful recovery with a ruined reputation.
• Blame after the incident. A team punished for reporting mistakes will hide the next incident until it is too late. A learning culture beats a witch-hunting culture — always.

Start with a Simple First Version

As the saying goes, half of a good plan is a plan that exists. The first version of an IRP does not need to be perfect. Start with ten pages: a short introduction, the team and roles with contacts, severity classification, an emergency contact list, the six phases on a single page, and three runbooks for the most likely incidents (malware, successful phishing, and data breach). Distribute it to all role holders, ask for feedback, then test it with a two-hour tabletop exercise.

From there, the plan grows on its own: every real incident and every exercise teaches something that refines it. What cannot grow is a plan that was never started.

If you want to build an incident response plan but your internal team has no incident experience, consider guidance from people who have handled real cases. The Kartech team in Bandar Lampung has experience building and maintaining systems for various businesses, including drafting incident response procedures and training client teams to run them. Start from the contact page to discuss your needs, or explore the scope of our services.

Good prevention does reduce how often incidents happen, but it never eliminates them. An incident response plan is not an admission that you will be attacked; it is an acknowledgment that you take the business you built seriously. In a world where incidents never wait for office hours, readiness is an advantage that cannot be bought at the moment of need — it can only be built in advance. For a broader security foundation, also read the website security guide for businesses and the guide to hiring IT consultants. If your systems run in the cloud, the cloud migration guide will help you understand the risks that come with it.