Why Root Cause Analysis Deserves a Permanent Place in Your Firm’s Incident Response Plan

Firm Management | August 10, 2026

Why Root Cause Analysis Deserves a Permanent Place in Your Firm’s Incident Response Plan

Root cause analysis works best when it's treated as a standing part of incident response rather than an occasional deep-dive reserved for major breaches.

Scott Carr

An employee’s email account gets compromised. IT resets the password, kills the session, and the alerts stop. Everyone breathes easier and moves on.

But one question rarely gets asked: why did it happen, and what’s stopping it from happening again — to a different employee, through a slightly different method, at the worst possible time of year?

That question is the entire purpose of root cause analysis (RCA). It’s the difference between putting out a fire and figuring out what’s been leaking gas into the building. For accounting and tax firms handling client financial data, filings, and audit trails, skipping that step isn’t just inefficient — it leaves the same underlying weakness in place, waiting to resurface.

Incident Response and Root Cause Analysis Are Not the Same Thing

Incident response is what happens in the moment: contain the threat, restore access, get the team back to work. Root cause analysis happens afterward, and it asks the harder questions:

  • Was this a phishing gap, a missing security policy, an unpatched system, or a training blind spot?
  • Was this an isolated event, or part of a broader pattern across the firm’s systems?
  • What specific configuration or behavior allowed the incident to succeed?

A recent example illustrates the gap well. In one documented case, an employee entered credentials on a fake login page that looked identical to a real Microsoft 365 sign-in screen. She completed her multi-factor authentication step normally — but the fake page was silently relaying everything to the real login servers in real time, capturing the authenticated session that followed. That session functioned like a hall pass: once the attacker had it, neither the password nor the MFA code mattered anymore. Days later, the attacker logged in from another part of the world, quietly created a mail rule to hide replies, and used the compromised account to send file-sharing invitations to external contacts.

Recommended Articles

Resetting the password would have stopped that specific account from being reused. It would not have explained how the session was stolen in the first place, or whether the same gap existed elsewhere in the firm’s environment. That’s what root cause analysis is for.

Action Steps for Firm Leadership and IT

Firms that want to move from reactive firefighting to durable security posture should consider building the following into their incident response process:

  1. Require a written root cause summary after any security incident — not just a “resolved” note in a ticket.
  2. Confirm monitoring covers session and location anomalies, not just failed login attempts. Attackers who steal a live session bypass traditional MFA alerts entirely.
  3. Enforce Conditional Access policies (or equivalent) to block sign-ins from unexpected countries or unmanaged devices.
  4. Shorten session lifetimes so a stolen session expires faster and has a smaller window of use.
  5. Tie staff training to the actual method used in the last incident, rather than relying on generic phishing reminders.
  6. Review mail rules periodically. Attackers frequently hide behind rules with punctuation-only names so they go unnoticed during a quick inbox scan.
  7. Confirm the firm’s written incident response plan includes session token revocation, not just password resets, as a standard containment step.
  8. Schedule a 30-day follow-up review to verify that the identified gap was actually closed, not just patched over.

The inclusion of a root cause step doesn’t need to slow down containment. Containment should always happen immediately. Root cause analysis is a structured follow-up — typically a short written summary or review call — that happens once the immediate threat is handled.

Questions Firm Leaders Are Likely Asking

If we have MFA in place, aren’t we already protected?
MFA blocks the vast majority of credential-based attacks. But session-hijacking techniques steal the authenticated session created after MFA succeeds, which means monitoring and Conditional Access policies need to work alongside MFA, not in place of it.

How would a firm even know an incident like this occurred?
Often the first indicator isn’t a failed login — it’s unusual outbound email activity, unexpected file-sharing invitations, or an external contact asking why they received a strange link. Proactive monitoring for session and behavioral anomalies typically catches this earlier than a client complaint does.

Is closing this kind of gap expensive?
In most cases, no. Conditional Access policies, session timeout settings, and monitoring configuration are typically adjustments to tools a firm already owns, not new purchases — provided the IT team or provider has the expertise to configure them correctly.

Does this apply to smaller firms, or only larger practices?
It applies broadly. Smaller firms often have less capacity to absorb a repeat incident, particularly during filing deadlines, which makes understanding the cause the first time even more valuable than it is for a larger organization with more redundancy.

Building This Into Firm Culture

Root cause analysis works best when it’s treated as a standing part of incident response rather than an occasional deep-dive reserved for major breaches. Firms that document root cause consistently — even for smaller, contained incidents — tend to see fewer repeat issues over time, because each review closes a specific gap rather than addressing only the symptom in front of them.

For firms serving clients who trust them with sensitive financial and tax data, that discipline isn’t just an operational nicety. It’s part of demonstrating the kind of due diligence clients, auditors, and regulators increasingly expect to see documented, not assumed.


Scott Carr, owner of Farmhouse Networking in Grants Pass, Oregon, is a veteran Network & Computer Systems Architect with over 30 years of IT experience. For over a decade, he’s led his team in delivering proactive, secure, and fully managed IT services to more than 80 businesses—including accounting and finance firms that rely on data security, compliance, and efficiency. Scott’s hands-on, jargon-free approach ensures every client understands their technology and gains confidence in their systems.

His firm is known for fast, responsive support—most issues are resolved within 15 minutes—and deep expertise in cybersecurity, network design, and IT compliance. Learn more about how Farmhouse Networking supports the accounting industry at https://www.farmhousenetworking.com/finance-it-support/.

Sign in to get access to this free resource, and all of our whitepapers and reports.

Download this content today!

Register to get free access to this content, as well as newsletters, continuing education, podcasts, and more…

Leave a Reply

Scott Carr

Scott Carr

Scott Carr, owner of Farmhouse Networking in Grants Pass, Oregon, is a veteran Network & Computer Systems Architect with over 30 years of IT experience. For over a decade, he’s led his team in delivering proactive, secure, and fully managed IT services to more than 80 businesses—including accounting and finance firms that rely on data security, compliance, and efficiency. Scott’s hands on, jargon free approach ensures every client understands their technology and gains confidence in their systems. His firm is known for fast, responsive support—most issues are resolved within 15 minutes—and deep expertise in cybersecurity, network design, and IT compliance. Learn more about how Farmhouse Networking supports the accounting industry at https://www.farmhousenetworking.com/finance-it-support/.