Incident Response Plan for a Compromised Business Account

Every business that holds verified accounts should have an incident response plan written down before it is needed. This article is that plan: what to do in the first hour, how to find out what happened, and how to come back safely. A compromised business account is a matter of hours, not days, so the plan is built for speed first and understanding second.

When you suspect a business account is compromised, the first hour matters more than the first day. Speed is not about fixing everything at once; it is about stopping the damage from spreading. Change the password from a clean device, sign out every active session, and pause any automated payments or transfers tied to the account. Do not wait until you understand what happened. Containment comes first, and understanding comes second, because every minute an attacker keeps access is a minute they can move money, copy data or lock you out.

Resist the urge to investigate from the compromised account itself. If the attacker is still logged in, they can see what you are doing and react to it. Use a different device, ideally one you know is clean, and work from the exchange's official site or app, which you open from your own bookmark rather than from any link in an email. If your team shares the account, tell the account owner and your finance lead immediately, so nobody makes a routine payment into a situation that is no longer routine.

Write down the time you first noticed the problem and what you saw. That note will matter later, when you reconstruct the timeline for the exchange, your bank or your insurer. A short factual note made in the moment is worth far more than a confident memory made a week later. Keep this habit through the whole incident: every action, every message, every reference number goes in the same place.

Once the account is contained, work out what the attacker did and how they got in. Check the login history and active sessions the exchange shows you, and look for sign-ins from places or devices your team does not use. Check whether the password, email or withdrawal address was changed, whether any API keys were created, and whether any transfers went out. If money moved, note the amounts, the destination addresses and the times.

Then widen the check. A compromised business account rarely stands alone: the same password may be used elsewhere, the same email inbox may be the recovery address for other accounts, and a team member's device may have been the way in. Check the recovery email account, any shared password manager, and any other exchange or payment account that shares credentials. If you find the same password in more than one place, treat every place as potentially affected.

Do not delete evidence while you investigate. Keep suspicious emails, keep screenshots of strange sessions, and do not wipe a device before someone has looked at it. If you later need the exchange or the police to act, the trail you preserved is what they will work from. The goal at this stage is a clear picture: how they got in, what they touched, and what is still safe.

Containment stops the bleeding; hardening makes sure it does not start again. Change the password to something long and unique, generated by a password manager rather than invented on the spot. Turn on two-factor authentication with an authenticator app, not text messages, and remove any old or unknown devices from the trusted list. Review the withdrawal allowlist and remove any address your team does not recognise.

Revoke every API key attached to the account, then create fresh ones only for the tools you actually need, with the smallest permissions each tool can work with. Check connected apps and third-party services, and disconnect anything the team does not recognise or no longer uses. If the account's recovery email was also affected, secure that first, because an attacker who controls the recovery email can undo everything else you do.

Finally, check who on the team can still reach the account and whether that list is still right. Shared logins are the usual reason a business account is hard to secure, so this is the moment to move to individual logins or a managed access list if the platform supports it. Write down who holds what, and make sure the list has an owner who keeps it current.

Start with the exchange. Use its official support channel and report the compromise, the time you noticed it, and what you have already done. Give support the facts, not a theory, and ask for a case number. If money was taken, ask what the exchange can do: freeze the destination if it is internal, flag the transaction, or start its own investigation. Be honest about what you do not know yet; guessing in a support ticket only slows the real work down.

Then tell your own organisation. Your finance lead needs to know before the next payment run, your manager needs to know the account is paused, and anyone who was about to use the account needs to know not to. Keep the message factual and short: what happened, what is affected, what is being done, and when the next update will come. Rumour fills a vacuum faster than facts do, so send the update even if it is brief.

If customer money or customer data was involved, take advice quickly on whether you have a duty to notify anyone else, such as customers, a regulator or your bank. The answer depends on where you operate and what was exposed, so do not guess. A short call with a professional now is far cheaper than a notification sent late or a notification that should never have gone out. Keep a record of who you told and when, because that record is part of the incident file.

A good incident record is written while the incident is happening, not from memory afterwards. Keep one document for the whole event: the time the problem was noticed, who noticed it, what was seen, every action taken and when, every message sent to the exchange and the replies, every reference number, and every decision with the name of the person who made it. Screenshots belong in the same folder, with the time in the filename.

This record has three uses. First, it keeps the team coordinated while the incident is live, because nobody has to ask what has been done already. Second, it is what the exchange, your bank or your insurer will ask for. Third, it is the raw material for the review afterwards, when you work out what failed and what to change. A team that documents well recovers faster and learns more.

Keep the record factual. Write what happened and what you did, not what you think the attacker intended or how you feel about it. If something is uncertain, say so and note what would settle it. The record is a working tool, not a report for outsiders, so plain language and exact times matter more than polished writing.

Recovery is not a single moment when the password is changed. Bring the account back in stages, and check at each stage that it is behaving normally. Start with a small test: sign in from a clean device, confirm the balance and the recent activity look right, and make one small transaction before resuming normal volumes. If anything looks wrong, stop and go back to the investigation instead of pushing on.

Before the team starts using the account normally again, confirm that every control is in place: two-factor authentication on, allowlist correct, API keys fresh, sessions clean, and the access list right. Then tell the team the account is back, and what has changed, so nobody is surprised by a new login step or a missing address. A quiet return to normal, with the changes explained, is better than a silent one.

Watch the account more closely than usual for the next few weeks. Check the login history and the transaction history more often than your normal routine, and treat any small anomaly as a reason to look, not as a reason to wait. Attackers sometimes return to an account they once held, and the second visit is usually quieter than the first. A few weeks of extra attention is a small price for catching it early.

Within a week of closing the incident, hold a short review with everyone involved. The question is not who made a mistake; it is which safeguard failed and what would have caught the attacker earlier. Work through the timeline and ask at each step what would have stopped it: a stronger password, two-factor authentication, an allowlist, a session review, a smaller limit. Pick the two or three changes that would have mattered most, and give each one an owner and a date.

Then update the plan itself. An incident response plan that has never been tested is a guess, and you have just tested yours. Write down what worked, what was slow, what was missing, and what you would do differently. Store the updated plan where the whole team can find it in a hurry, and make sure new team members read it when they join. The next incident will not wait for a convenient moment, so the plan needs to be ready before it arrives.

Finally, run a short drill. It does not need to be elaborate: pick a scenario, walk the team through the first three steps, and check that everyone knows where the plan lives and who to call first. A plan that the team has rehearsed once is worth far more than a plan that sits unread. If your business relies on verified accounts, the time to practise is now, while nothing is on fire. For related reading, the /blog index on this site covers account hygiene and ownership records, and the /buy-crypto-accounts pages explain how accounts are structured before you rely on them.