Threat modeling is a structured process for identifying what could go wrong in a system before an attacker finds it, then deciding what to do about each risk. This guide covers threat modeling fundamentals in a step-by-step format any small practice can use, whether the system is custom software or the everyday mix of tax software, an EHR, email, and cloud storage most accounting, tax, and healthcare offices run on. The method is the same at any scale: define what you're protecting, list what can go wrong, decide on a response, and check your work.
Threat modeling differs from penetration testing. A penetration test checks whether a vulnerability can actually be exploited in a system that's already live. Threat modeling happens earlier, during design or planning, where fixing a gap costs a fraction of post-breach remediation. NIST's draft Special Publication 800-154 addresses this kind of data-centric threat modeling directly, describing it as a way to identify how sensitive data could be exposed or manipulated before a system goes into production.
Quick Answer
Threat modeling is a four-step process: define what you're protecting, identify what can go wrong using a framework such as STRIDE, decide on a mitigation for each risk, and document and review the result. For a small accounting, tax, or healthcare practice, that means mapping where client or patient data lives, tax software, an EHR, email, cloud storage, and running those same four questions a software team would use. A two-hour session covering them produces a usable risk list; an enterprise threat modeling platform is not necessary for most small practices.
Key Takeaways
- Threat modeling answers four questions: what are we protecting, what can go wrong, what will we do about it, and did we do a good enough job.
- STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most widely used framework and applies to everyday IT systems, not just custom software.
- A whiteboard session mapping your practice's data flows is enough to start; you don't need an enterprise platform.
- Threat modeling output supports, but doesn't replace, the risk assessment required under the FTC Safeguards Rule, the HIPAA Security Rule, and a written information security plan (WISP).
- Revisit your threat model whenever you add a vendor, change how staff log in, or take on a new category of client or patient data.
The stakes are measurable. According to IBM's 2024 Cost of a Data Breach Report, the average data breach now costs $4.88 million and takes 258 days to identify and contain. Verizon's 2024 Data Breach Investigations Report found that 68% of breaches involve a human element, such as a phished credential or a stolen password, which is exactly the kind of risk a threat modeling session is built to catch early.
Security researcher Adam Shostack, who helped build Microsoft's internal threat modeling program and wrote Threat Modeling: Designing for Security, distilled the discipline into four questions. They apply whether the system under review is a web application or a three-person tax office's network, and they work with any framework you choose.
The Four Questions Applied to a Small Practice
What are we protecting?
List the systems that hold client or patient data: tax prep software, an EHR or practice management platform, email, cloud storage, and remote access tools. Note which vendor hosts each one and who on staff can reach it.
What can go wrong?
Walk through each system using a framework such as STRIDE or MITRE ATT&CK to list realistic threats: a phishing email compromising a staff login, a misconfigured cloud folder exposing client files, a lost laptop with unencrypted data.
What are we going to do about it?
For each threat, pick a response: add a control (MFA, encryption, access restrictions), accept the risk with a documented reason, or remove the exposure by shutting down an unused integration.
Did we do a good enough job?
Review the list against what actually happened in any incident or near miss, and update it whenever you add a vendor, change software, or bring on a new category of client data.
These four questions align with the OWASP Threat Modeling methodology and with the risk assessment controls in NIST SP 800-53. The security properties behind them, confidentiality, integrity, and availability, are the same ones covered in our guide to the CIA triad, which explains how each property maps to a specific control.
Once the four questions are clear, these six steps turn them into a documented, repeatable process.
The Step-by-Step Process
Define scope and what's at stake
Pick one system to start: your tax software, your EHR, or your email environment. Document what data it holds, who can access it, and which regulation applies. A tightly scoped review of one system is more useful than a vague review of everything at once.
Map your data flows
Sketch where data enters, moves, and leaves: client intake forms, your tax or EHR platform, cloud backup, email attachments, and any remote access. Mark every point where data crosses from one party to another; those crossing points carry the highest risk.
Identify threats with STRIDE
For each crossing point, run through STRIDE's six categories: could someone spoof a login, tamper with a file, deny a transaction happened, expose data, knock a system offline, or gain access they shouldn't have. MITRE ATT&CK's documented adversary techniques add real-world detail to each category.
Score and prioritize
Rate each threat by likelihood and impact. A simple high, medium, or low scale works for most small practices. Fix the high-likelihood, high-impact items first.
Define mitigations
Assign a specific control to each prioritized threat: <a href="/tax/two-factor-authentication">multi-factor authentication</a> for login threats, <a href="/blog/endpoint-detection-and-response-for-small-business">endpoint detection and response</a> for malware and ransomware, encrypted backups for data loss, and role-based access for over-privileged accounts.
Document and revisit
Write down the system, the threats, and the mitigations. This becomes supporting evidence for your written information security plan or HIPAA risk analysis. Revisit it whenever your systems change.
Microsoft developed STRIDE as part of its Security Development Lifecycle, and it remains the most widely used threat modeling framework for both software and everyday IT systems. Each letter names a threat category and the security property it threatens.
Two other frameworks come up often enough to know the names. PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology that ties technical threats to business impact. It's built for larger, regulated organizations running structured annual risk assessments, and it requires a dedicated security practitioner to facilitate. LINDDUN focuses specifically on privacy threats, such as whether anonymized records can be re-linked to a person, and matters most for organizations building products that process personal data under GDPR or CCPA. It was developed by researchers at KU Leuven and is documented on the LINDDUN project website.
Most small accounting, tax, and healthcare practices get more value from STRIDE's six categories than from either PASTA or LINDDUN. If a software vendor you're evaluating mentions running PASTA or LINDDUN assessments internally, that's a reasonable sign of a mature security program worth noting in your vendor review.
MythThreat modeling only applies to companies that build their own software.
Threat modeling only applies to companies that build their own software.
Any practice running tax software, an EHR, email, or cloud storage has data flows worth mapping. You're not writing code, but you're still deciding what data lives where and who can reach it, which is the core of the exercise.
MythYou need an enterprise platform like IriusRisk or ThreatModeler to do this.
You need an enterprise platform like IriusRisk or ThreatModeler to do this.
Those platforms exist for software teams managing dozens of applications at once. A single session walking through STRIDE's six categories covers what a typical small practice needs.
MythA threat model satisfies your regulatory risk assessment on its own.
A threat model satisfies your regulatory risk assessment on its own.
The FTC Safeguards Rule, HIPAA Security Rule, and IRS WISP requirements each call for their own documented risk assessment. A threat model can support that documentation, but it isn't a substitute for it.
Threat modeling produces documentation that supports several existing requirements rather than replacing them. The FTC Safeguards Rule (16 CFR Part 314) requires covered financial institutions, including paid tax preparers, to conduct a periodic risk assessment of their information systems. The HIPAA Security Rule at 45 CFR §164.308(a)(1) requires covered entities and business associates to conduct a risk analysis covering where electronic protected health information is created, received, maintained, or transmitted. IRS Publications 4557 and 5708 direct tax professionals to maintain a written information security plan (WISP) built on that same kind of system inventory and risk review.
None of these requirements mandate a specific methodology like STRIDE or PASTA. What they require is evidence that you identified where sensitive data lives, assessed what could go wrong, and documented your response, which is what the four-question process above produces. Our FTC Safeguards Rule checklist walks through the specific documentation most tax and accounting practices need on file. Legal questions about how a specific requirement applies to your practice should go to your compliance advisor or counsel.
Does This Apply to Your Practice?
Tap the ones that sound like you.
Tap every statement that applies to you.
Get Your Free Cybersecurity Evaluation
Bellator Cyber Guard can walk through this process with your practice and turn the output into audit-ready WISP or HIPAA risk assessment documentation.
Frequently Asked Questions
Threat modeling is a structured process for identifying and prioritizing the ways a system, application, or IT environment could be attacked, before that happens. It involves mapping what you're protecting, listing realistic threats using a framework such as STRIDE, scoring them by risk, and assigning a mitigation to each one. The output is a documented risk list that supports both day-to-day security decisions and compliance evidence.
STRIDE is a threat categorization framework Microsoft developed for its Security Development Lifecycle. The name stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category threatens a specific security property, for example Spoofing threatens authentication and Tampering threatens integrity, and is applied system by system to find realistic threats.
Threat modeling identifies likely risks at the design or planning stage, before a system is built or fully deployed. Penetration testing validates whether a known or suspected vulnerability can actually be exploited in a system that's already running. The two are complementary: threat modeling tells a tester where to focus, and test findings can update the threat model.
Review a threat model at least once a year, and update it immediately after any material change, such as adding a new vendor or cloud service, changing how staff log in, or taking on a new category of client or patient data. A threat model that reflects last year's systems can create false confidence about this year's risk.
Threat modeling output can support the risk assessment required under the FTC Safeguards Rule and the risk analysis required under the HIPAA Security Rule, but it doesn't replace either one on its own. Both requirements call for their own documented process and, for tax preparers, a written information security plan. Confirm specific documentation requirements with your compliance advisor.
Most small accounting, tax, or healthcare practices don't need a platform like IriusRisk or ThreatModeler, which are built for software teams managing many applications. A session covering your practice's systems, walked through STRIDE's six categories, produces a usable risk list without licensing an enterprise tool.
From requirement to defensible practice
Turn the requirement into a security plan people can follow
A useful compliance path makes the obligation clear, identifies the evidence to retain, and connects written policy to the safeguards used every day.
People also look for
Keep exploring HIPAA security
Connect HIPAA requirements to the safeguards, assessments, and everyday decisions a healthcare practice can actually implement.
- Common question: HIPAA cybersecurity requirementsUse the plain-language HIPAA guideUnderstand administrative, physical, and technical safeguards without sorting through legal language.
- Common question: HIPAA security risk assessmentPrepare for a HIPAA risk assessmentIdentify vulnerabilities, document risk, and prioritize the gaps that matter most.
- Common question: HIPAA Security Rule explainedReview the HIPAA Security RuleSee how the standards and implementation specifications fit together.
- Common question: healthcare ransomware protectionReduce healthcare ransomware riskProtect patient data and keep clinical operations recoverable after an attack.
- Common question: HIPAA endpoint securityProtect practice workstations and devicesApply managed endpoint detection to the devices that access protected health information.
