At 8:17 a.m., an accounts payable employee reports that a vendor payment portal is asking her to sign in again. The page looks familiar, but the address is slightly different. That small detail begins this cyber incident response example, and the next few hours determine whether the business experiences a contained security event or a costly disruption.
For small and mid-sized businesses, incident response is not an abstract cybersecurity exercise. It is the discipline that protects payroll, customer data, operations, and employee productivity when something goes wrong. The goal is not merely to remove malware or reset a password. It is to make informed decisions quickly, preserve evidence, limit damage, and restore normal operations with confidence.
A Cyber Incident Response Example: The Compromised Account
Consider a fictional but realistic scenario. A 75-person manufacturing company receives an email that appears to come from a longtime parts supplier. It asks the accounts payable manager to review an updated invoice through a shared Microsoft 365 document. The manager enters her credentials into a counterfeit sign-in page.
Within minutes, the attacker signs into the manager’s email account from an unfamiliar location. They create an inbox rule that moves vendor responses to a hidden folder, then search the mailbox for terms such as “wire,” “banking,” and “payment.” Their objective is business email compromise: impersonate the manager, redirect a legitimate vendor payment, and disappear before anyone notices.
The company has multifactor authentication enabled, but the attacker captures an active session token through the phishing page. This is a useful reminder that security controls reduce risk, but no single control eliminates it. The organization needs a response process that accounts for people, technology, and the business decisions that follow.
Detection: Treat the Alert as Credible
The employee reports the suspicious email to IT rather than simply deleting it. At nearly the same time, the company’s security monitoring platform flags an unfamiliar sign-in, a new mailbox forwarding rule, and unusual access to financial correspondence.
The initial response team does not assume a full breach, but it does not dismiss the warning either. They open an incident record, document the time of the report, preserve the phishing email, and identify the affected user account. A designated incident lead coordinates the work so that technical changes, internal communication, and decisions about vendor payments do not happen in isolation.
Early triage should answer a few practical questions: Is the account still active? Has the attacker accessed other systems? Did the account send messages internally or externally? Are there signs that payment instructions were changed? The answers shape the level of response.
Containment: Stop the Activity Without Creating More Damage
The first technical action is to revoke the manager’s active sessions and disable the compromised account temporarily. The team resets the password, removes the malicious mailbox rule, and reviews recent sign-in activity. They also block the phishing domain and search the email environment for other employees who received the same message.
Containment has a business trade-off. Disabling an account can interrupt work, especially if the employee manages active payments or customer requests. Leaving the account available while the investigation continues, however, may allow the attacker to send fraudulent messages or collect more data. In this case, the company chooses short-term inconvenience over ongoing exposure and assigns a backup employee to handle urgent vendor communication.
The team also contacts the finance leader. This is not a technical detail to be handled later. Because the attacker searched payment records, the finance department pauses outgoing wire transfers that were initiated by email. Staff independently verify any banking change with vendors using known phone numbers, not contact information included in an email.
That step may prevent the most expensive consequence of the incident. Many business email compromise losses occur not because an attacker accessed an inbox, but because a rushed payment process trusted a fraudulent instruction.
Scope the Incident Before Declaring It Over
With immediate activity contained, the response team investigates the scope. They review sign-in logs, mailbox audit records, endpoint activity, cloud storage access, and administrator events. They look for additional rules, delegated access changes, suspicious OAuth application approvals, and evidence that the attacker moved laterally into other accounts.
The investigation finds that the attacker accessed the manager’s mailbox for 42 minutes and viewed several invoice threads. No endpoint malware is detected, and no other accounts show the same suspicious session behavior. One vendor received an email from the compromised account asking for updated banking information, but the vendor did not respond.
This finding matters because it changes the response. If the attacker had reached file shares, accounting software, or administrator accounts, the organization would need broader containment, potentially including network segmentation, endpoint isolation, credential resets for multiple users, and assistance from legal counsel or cyber insurance partners. Incident response should expand based on evidence, not guesswork.
Eradication: Remove the Attacker’s Path Back In
Once the team understands the scope, it removes the conditions that allowed the compromise to persist. The affected account is rebuilt with a new password and verified multifactor authentication enrollment. All active sessions are revoked again after remediation. The malicious domain, sender indicators, and known phishing message characteristics are added to email protections.
The organization also reviews conditional access controls. Because the compromise involved a stolen session token, a basic password reset alone would not have been enough at the beginning of the incident. Session revocation, sign-in risk policies, device compliance requirements, and stronger phishing-resistant authentication options can all reduce the chance of repeat access. The right mix depends on the company’s applications, workforce, and budget.
The response team verifies that no unauthorized email forwarding, external sharing permissions, or third-party application connections remain. They document every change. Documentation is often neglected during an urgent event, yet it provides a reliable record for leadership, insurance carriers, auditors, and future investigations.
Recovery: Restore Operations With Verification
Recovery begins when the team can safely return the manager’s access and resume regular financial operations. Before doing so, they confirm the account is secure, mailbox rules are clean, and monitoring is active. The manager receives a brief explanation of what happened and clear instructions for accessing systems again.
Finance resumes payment activity, but with temporary additional controls. For the next several days, a second approver validates vendor banking changes and wires requested through email. The company contacts affected vendors directly to explain that a fraudulent message may have been sent and to establish a trusted communication method for payment-related requests.
This is also the point where leadership needs a concise, factual update. Effective communication does not require technical jargon or speculation. It should explain what was detected, what was contained, whether sensitive information or funds were affected, what actions are underway, and what employees should do. If notification obligations apply because regulated or personal data was exposed, legal and compliance guidance should direct the process.
A recovery plan is complete only when the business can operate safely, not simply when the alert disappears from a dashboard. That distinction is especially important for organizations dependent on cloud email, line-of-business applications, phone systems, and remote access.
What This Incident Reveals About Preparedness
The incident was contained because the employee reported a suspicious message, monitoring identified unusual activity, and the company had people who could make rapid decisions. Those capabilities are built before an event, not during one.
A practical incident response plan should identify who has authority to disable accounts, isolate devices, communicate with employees, pause payments, contact vendors, and engage outside experts. It should include current emergency contacts, a communication path that does not rely on a potentially compromised email account, and access to logs, backups, administrative credentials, and cyber insurance information.
It also needs to be tested. A tabletop exercise built around a phishing email, ransomware alert, lost laptop, or vendor payment fraud attempt exposes gaps that a written policy may hide. Can finance verify a payment change after hours? Does IT know which systems are most critical? Can leadership reach the right people if email is unavailable? These questions are operational, not theoretical.
For many organizations, a managed IT and cybersecurity partner provides added depth during these moments. Plasma Networks can help businesses establish response procedures, strengthen identity and email security, monitor critical systems, and bring coordinated technical support to an incident without forcing internal teams to manage every moving part alone.
The most useful outcome from a cyber incident is not a thicker binder of policies. It is a clearer ability to act: employees know how to report concerns, leaders know who decides, and the business can contain a threat before it becomes an interruption that customers, vendors, and employees feel.
