The first response to a phishing incident is often too narrow: change a password, delete the email and get back to work. That may be enough when nobody entered a password or opened an attachment. It is not enough when an attacker may have reached a mailbox, cloud account, payment process or shared documents. The aim is not to create panic. It is to stop further access, understand what changed and make a clear decision about who needs to know.
Contain first, but do it from a known-good device
If someone entered a password, approved an unexpected sign-in, downloaded a file or allowed an unfamiliar app, treat the account as potentially compromised. Use a device you trust, reset the affected account password and end active sessions through the identity provider or service console. If the same password was used anywhere else, change it there too. CISA advises people who suspect phishing to change account passwords immediately and report the message.
Do not assume a password reset is the end of the job. Check the account recovery email, registered phone number, multi-factor authentication methods and trusted devices. An attacker who added their own recovery method, session or authenticator can come back after the password changes. The exact controls differ between Microsoft 365, Google Workspace and other providers, but the question is the same: can anyone still recover or use this account without the owner knowing?
Keep the evidence that helps you find the real scope
A suspicious message should be reported through the mail service’s phishing control where possible, not repeatedly forwarded to colleagues. Save the message or its headers, the sender address, link or attachment name, the time of the interaction and a short account of what happened. Note whether a password was entered, a multi-factor prompt was approved, a download was opened or a browser extension was installed.
Then review the account’s recent sign-ins, sent mail, deleted items, inbox rules, forwarding settings and connected applications. Screenshots can help, but timestamps and audit records are more useful when they are available. NIST’s current incident-response guidance treats analysis and recovery as connected work: the information collected during the incident should improve the recovery decision, not become a folder nobody opens again.
Check what that account could have reached
A compromised mailbox can be used to read conversations, send convincing replies, reset other accounts and redirect invoices. Start with the practical routes the account had into the business. Look for new mail rules or forwarding, external app consent, unusual message sends, changed payment instructions, newly shared cloud files, password-reset messages and signs that a colleague or customer received something unexpected.
The scope may be smaller than feared. It may also be wider than one inbox. If the account had access to finance, customer data, an administrator console or a shared password manager, bring the responsible person in early. Review those systems before restoring normal access. A team should avoid broad, blind changes that interrupt every user, but it should be quick to restrict access that has a credible connection to the incident.
Tell the right people what is known, and what is still being checked
Internal communication should be factual. Say which account or device is involved, what has already been contained, what people should watch for and where to report suspicious follow-up messages. If an attacker may have sent email from a company address, alert likely recipients quickly and tell them not to trust new payment details, login requests or file links without a separate check.
If money may have moved, contact the bank or payment provider immediately. If customer or employee personal data may have been exposed, get appropriate privacy and legal advice without delay; reporting duties depend on the data, the jurisdiction and what actually happened. The NCSC also points organisations to formal incident reporting routes. Reporting is not an admission of failure. It can make it easier to get the right support and helps defenders track active campaigns.
Finish the recovery, then make the next incident less dramatic
Before closing the incident, remove unfamiliar authentication methods, revoke unneeded app access, patch and scan the affected device, and make sure email rules, forwarding and account recovery options are back to their intended state. Confirm that the user can sign in with a strong unique password and multi-factor authentication. If a device was involved, check whether it needs rebuilding rather than simply trusting that an antivirus scan found nothing.
Write a short record while the details are fresh: what happened, which accounts were affected, what access was removed, who was notified and what needs to change. For a small business, the useful improvement is usually modest and concrete: a clearer reporting route, stronger MFA, a payment-verification rule, better mailbox alerts or an off-network way to contact the team. The goal is not a thick incident manual. It is a response the business can carry out calmly next time.
Sources
This brianda.cloud article draws on the public guidance listed below. It is practical operational guidance, not a substitute for incident-specific forensic, legal, privacy or regulatory advice.
Sources consulted for this analysis:
- Phishing Guidance: Stopping the Attack Cycle at Phase OneCybersecurity and Infrastructure Security Agency (CISA) · 2025-03
- Phishing attacks: defending your organisationNational Cyber Security Centre (UK) · 2026
- SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk ManagementNational Institute of Standards and Technology (NIST) · 2025-04-03