incident responseemail phishinghuman risk

    September 22, 2026 · 8 min read · By Fensivo Team

    What to do if an employee falls for phishing: the first hour

    Leer en español

    What to do if an employee falls for phishing: the answer in one sentence

    If someone on the team has just clicked a fake email or typed their password into a page that was not what it seemed, the first move is not to investigate. It is to cut off the attacker's access: reset that account's password and revoke every active session, in that order, within the first few minutes. Auditing mailbox rules, finding out who else received the message and documenting the case all come next, and all of it fits inside the first hour. The step almost nobody takes is the one that closes the loop: weeks later, test that person again with an equivalent attack, because containing an incident does not prove that behavior changed.

    The urgency is arithmetic, not drama. Verizon's 2024 Data Breach Investigations Report measured that the median time to click a malicious link, once the email is open, is 21 seconds, and that only another 28 seconds are needed for the person to hand over their data: under 60 seconds in total. That number carries a design consequence that rarely gets drawn out: if the attacker wins in less than a minute, a procedure built around days of investigation is late by definition. The runbook is built in minutes or it is useless. That is the whole argument of this guide.

    The first minutes: contain the damage without blaming the person

    The first five minutes decide how big the incident gets. Four actions, in this order:

    Human risk is managed automatically.

    Turn human risk into your first line of defense.

    Book a demo

    Free demo · 30 minutes · No commitment

  1. Reset the affected account's password, rather than leaving it to the person to do when they get a chance. If the attacker is already inside, every minute with a live credential is free access.
  2. Revoke every active session for that identity, both in the mail provider and in the directory. Changing the password without revoking session tokens leaves the attacker in place, and it is the most common mistake on this list.
  3. Ask exactly what was typed. Not "what happened", but which fields were filled in: username, password, second-factor code, card details. The answer changes the rest of the procedure.
  4. Record the time of the click, not the time of the report. Everything that follows, from access logs to the scope of the campaign, hangs on that timestamp.
  5. One note on tone, and it is not cosmetic. Whoever makes that call is frightened and embarrassed, and if the first thing they hear is a reprimand, they will answer with less detail than the situation requires. The goal of those five minutes is complete information, fast, and that comes from calm, not from severity.

    Why a fast report is worth more than a reprimand

    The scarce resource in a phishing incident is not the security team's time. It is the window between the click and the alert. That window is controlled by the person who fell for it, not by the technical team. Any practice that stretches it, whether through fear or simple embarrassment, ends up widening the incident.

    It is worth recalling why this carries so much weight. CISA states that more than 90 percent of successful cyber attacks start with a phishing email, so email is not one front among many: it is the front door. And Cisco's 90-5-5 framework, which estimates that close to 90 percent of breaches involve a human factor, explains why the procedure has to be built around how people behave and not only around technical controls. Voice, text messages and QR codes add to that front rather than replacing it.

    There is also a newer reason to lower the volume on the reprimand: the bait got better. The Microsoft Digital Defense Report 2025 reports that AI-driven phishing is now three times more effective than traditional campaigns. When the lure reads better than a good share of the legitimate email that person gets every day, falling for it stops being a sign of carelessness and becomes a sign that the test got harder. Punishing that result does not correct it. It hides it, and it makes the next incident more expensive.

    What to check: credentials, sessions and mailbox rules

    With access cut off, the rest of the hour goes to answering a single question: what did the attacker manage to touch? Five checks, ordered by payoff:

  6. Forwarding rules and mailbox filters. This is the first thing an intruder sets up in a corporate mailbox: one rule that copies everything to an external address, another that sends anything mentioning invoices or transfers straight to the trash. It is the classic setup for business email compromise (BEC) fraud, and it survives a password reset because it lives in the mailbox configuration, not in the session.
  7. Sign-in logs from the past few hours, looking for access from locations, devices or IP addresses that do not match that person.
  8. Applications and OAuth permissions granted recently from that account. Consent given to a malicious application keeps the access alive even after the password changes and the sessions are revoked.
  9. Reuse of that password across other company services. If the credential also opened the billing console or the code repository, the incident is no longer about one account.
  10. Who else received the same email. It almost never lands on a single person. Searching the sender, the subject line and the link domain across the whole tenant turns an isolated case into a map of the campaign, and makes it possible to warn people before the second one falls.
  11. If in step three above the person confirmed that they typed a second-factor code, the case moves up a category: assume the attacker held an active session and treat the account as compromised, not merely exposed.

    The first-hour checklist

    MinuteActionWho runs it
    0 to 5Reset the password, revoke all sessions, ask what data was handed over, record the time of the clickSecurity or IT, with the person on the line
    5 to 20Audit forwarding rules and filters, sign-in logs and recent OAuth permissionsSecurity or IT
    20 to 40Search for the same email across the tenant, block the sender and domain, warn everyone who received itSecurity or IT
    40 to 55Assess credential reuse across other systems and decide whether the case escalates to a formal incidentSecurity lead
    55 to 60Close the loop with the person: what signals the email carried, what to do next time, and confirmation that reporting was the right callSecurity or IT

    The table does what any checklist does: it means nobody has to remember the order at eleven at night. It belongs somewhere reachable, pinned in the team channel rather than buried in a forty-page policy.

    After containment: why retraining is not enough and a retest is

    This is where incident response ends and human risk management (HRM) begins, the discipline concerned with measuring and reducing the odds that the same thing happens again to the same person.

    The usual reflex is to assign training and close the case. The problem is that the evidence does not support that conclusion. Two peer-reviewed studies from the IEEE Symposium on Security and Privacy, Ho and colleagues in 2025 and Lain and colleagues in 2022, found that completing training does not on its own predict that a person will fail less against a real attack. That does not mean training is pointless. It means completion is not the proof. It is an attendance record, not a measurement of behavior.

    What does prove something is putting the person back in the same situation. A retest is exactly that: weeks after the failure, a simulated attack of the same category and comparable difficulty, with a different pretext and a different template, to tell apart someone who learned to read the signals from someone who simply remembers the email they fell for. If they catch the second attempt, there is evidence of change. If they fall again, the case is still open, and that is information no course completion rate will ever give. The difference between remediating and validating is what turns a one-off incident into a measurable improvement in the risk score, and it is developed in full in what a retest is and why it proves behavior changed. On the cultural side, which decides whether people report at all, there is how to introduce phishing simulations without punishment.

    At Fensivo we work on precisely what is left once the incident is contained. We continuously monitor more than 680 public breach databases to flag when an employee credential shows up exposed, we deliver training specific to the attack the person failed, and three weeks later we send a simulation of the same category and sophistication with a different template, to validate that behavior changed rather than that an email was remembered. Containment itself is run by the internal team, with its own access and its own tools; what we add is the evidence that next time the outcome will be different. The detail is in our use cases.

    How long does it actually take today, measured rather than estimated, between an employee's click and the moment every one of their active sessions is revoked?

    Sources and references

    Verizon, "2024 Data Breach Investigations Report" (DBIR 2024). https://www.verizon.com/business/resources/reports/2024-dbir-data-breach-investigations-report.pdf

    CISA, "4 Things You Can Do To Keep Yourself Cyber Safe". https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe

    Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", May 27, 2025. https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity

    Microsoft, "Microsoft Digital Defense Report 2025". https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2025

    Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/11023357

    Lain, D., Kostiainen, K. and Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/9833766

    Human risk is managed automatically.

    Turn human risk into your first line of defense.

    Book a demo

    Free demo · 30 minutes · No commitment