By Kira Mikkonen

A personal threat model is a structured way to figure out who might want to harm you, what they could do, and which of your assets need the most protection. It sits at the intersection of operational security, privacy engineering, and everyday risk management. For people working in journalism, activism, human rights, or local government, a threat model is not a one-time checklist. It is a living document that changes when your work, relationships, or technology change. This guide walks through a practical method for building and updating your own model, with a focus on open security for democratic societies.

Why a Personal Threat Model Matters

Most security advice fails because it tries to protect everyone from everything. That approach leads to burnout, expensive tools, and a false sense of safety. A threat model flips the question. Instead of asking “What is the best security tool?”, you ask “What am I protecting, from whom, and for how long?”

For example, a municipal clerk who handles election records faces different threats than a freelance reporter covering corruption. The clerk may need to protect the integrity of documents and the privacy of voters. The reporter may need to protect a source’s identity and the confidentiality of unpublished material. Both need security, but their models lead to different priorities.

Threat modeling is also a core practice in the open security community. It encourages transparency about assumptions, shared methods, and continuous review. That openness matters in democratic societies, where security should not depend on secrecy or gatekeeping.

Start With Assets, Not Adversaries

Many people begin by listing enemies. That can feel urgent, but it often leads to vague fear. A more useful starting point is to list what you need to protect. Assets can be physical, digital, or social.

Common Asset Categories

• Devices: laptop, phone, external drives, router, smart home devices.
• Accounts: email, cloud storage, social media, banking, government portals.
• Data: contacts, messages, photos, documents, location history, metadata.
• Relationships: sources, colleagues, family members, community groups.
• Reputation: public trust, professional standing, legal record.
• Physical safety: home address, travel patterns, daily routines.

Write these down in a private notebook or an encrypted file. Do not store the list in a shared cloud account unless you have already decided that account is part of your trusted base. The act of listing assets often reveals dependencies you had not considered. For example, a journalist may realize that a source’s safety depends on the journalist’s own phone hygiene.

Identify Who Could Threaten Each Asset

Once you have an asset list, ask who would want to access, disrupt, or destroy each item. Be specific. “Hackers” is too broad. “A former partner with access to my shared photo library” is actionable. “A state agency that monitors protest organizers” is actionable if you have reason to believe you are in that category.

Threat Actor Types

• Opportunistic criminals: phishing, malware, theft of unattended devices.
• Targeted criminals: extortion, doxing, account takeover for financial gain.
• Abusive individuals: stalking, harassment, intimate partner surveillance.
• Corporate data brokers: location tracking, ad profiling, sale of personal data.
• State agencies: lawful interception, metadata analysis, border device searches.
• Insider threats: colleagues, contractors, family members with shared access.

For each asset, note which threat actors are realistic. A local council member may face harassment from a political opponent but is unlikely to be targeted by a foreign intelligence service. A human rights lawyer working on cross-border cases may face both. The goal is not to imagine every possible attack. The goal is to rank plausible ones by likelihood and impact.

Assess Likelihood and Impact

A simple two-axis grid works well. For each threat-asset pair, rate likelihood from low to high and impact from low to high. Focus first on items that are both likely and high impact. Those are your priority risks.

For example, a journalist who uses a personal Gmail account for source communication may rate “account takeover by phishing” as medium likelihood and high impact. A city employee who posts work schedules on a public social media profile may rate “physical harassment at the office” as low likelihood but high impact. Both deserve attention, but the journalist’s risk may require immediate changes to email habits, while the city employee’s risk may require a conversation with a supervisor about privacy settings.

Be honest about uncertainty. If you do not know how likely a threat is, say so. You can still take low-cost steps to reduce impact while you gather more information. Security decisions under uncertainty are normal. The key is to document your reasoning so you can revisit it later.

Map Your Current Defenses

Before adding new tools, list what you already do. Many people have more defenses than they realize, but they are unevenly applied.

Common Existing Defenses

• Two-factor authentication on some accounts.
• Full-disk encryption on a laptop or phone.
• A password manager for some logins.
• Signal or another end-to-end encrypted messenger for certain conversations.
• Physical locks, screen privacy filters, or a safe for documents.
• Separate work and personal devices.

For each priority risk, note which existing defense applies. Then look for gaps. A common gap is inconsistent use. For example, a person may have two-factor authentication on email but not on the cloud storage account that holds backups of that email. Another gap is shared access. A family member may know a device passcode, or a former colleague may still have access to a shared drive.

This step often reveals that the problem is not a lack of tools. It is a lack of routine. Fixing the routine is usually cheaper and more effective than buying a new app.

Choose Controls That Match Your Real Life

Security controls should fit your daily habits, not the other way around. If a control is too difficult, you will stop using it. That creates a worse situation than having no control at all, because you may believe you are protected when you are not.

Practical Control Examples

• Email: Move high-sensitivity conversations to a dedicated account with hardware-key two-factor authentication. Use a separate account for newsletters and online shopping.
• Messaging: Set disappearing messages for sensitive group chats. Verify safety numbers for key contacts.
• Devices: Enable automatic updates. Use a standard user account instead of an administrator account for daily work.
• Travel: Use a travel-only phone with minimal data when crossing borders. Log out of sensitive accounts before departure.
• Home network: Change default router passwords. Segment smart home devices from work devices.
• Physical documents: Shred papers with personal data. Store backups in a fireproof safe or a trusted off-site location.

Each control should be tied to a specific risk from your grid. If you cannot name the risk, the control may be security theater. That does not mean it is useless, but it should not be a priority.

Write It Down and Set a Review Date

A threat model that lives only in your head will drift. Write a short version: one page is enough. Include your top five assets, the three most likely threat actors, your priority risks, and the controls you plan to use. Store it securely. Set a calendar reminder to review it every three to six months, or sooner if your work changes.

Review questions to ask:

• Have I started a new project that involves sensitive data?
• Have I changed jobs, moved, or ended a relationship?
• Have any of my accounts been compromised or targeted?
• Have I stopped using a control because it was inconvenient?
• Has the legal or political environment changed in a way that affects my risk?

This review habit is what separates a living threat model from a forgotten document. It also builds a personal security history that can help you spot patterns over time.

Common Mistakes and How to Avoid Them

Even experienced practitioners make mistakes. Here are a few that show up often in workshops and consultations.

Overestimating the Adversary

Assuming every threat actor has unlimited resources leads to paralysis. Most attacks are opportunistic and rely on known weaknesses. Fixing the basics—updates, two-factor authentication, unique passwords—blocks a large share of real-world incidents. You do not need to be invisible. You need to be harder to target than the next person.

Ignoring Metadata

Content encryption protects what you say, but metadata reveals who you talk to, when, and for how long. For some threat models, metadata is the main risk. A journalist’s call log can expose a source even if the call content is encrypted. Consider whether you need to reduce metadata exposure through tools like Tor, VPNs, or simply changing communication patterns.

Treating Security as a Product

Buying a “secure” app does not make you secure. The app’s defaults, your settings, and your behavior all matter. A secure messaging app with cloud backup enabled may store plaintext copies of your messages on a server. Read the settings. Ask what happens if you lose your phone. Test your recovery process before you need it.

Forgetting Physical and Social Context

Digital security is only one layer. A locked laptop does not help if someone can watch you type your password. A private chat does not help if you discuss sensitive topics in a café. Social engineering often targets the people around you, not your devices. Include physical and social risks in your model.

Tools and Resources for Open Security

Several organizations publish free, practical guidance that aligns with open security principles. The Electronic Frontier Foundation’s Surveillance Self-Defense guide covers threat modeling, encryption, and device hardening. The Cybersecurity and Infrastructure Security Agency offers plain-language advice for individuals and small organizations. The Freedom of the Press Foundation maintains training materials for journalists and their sources. These resources are useful starting points, but they are not substitutes for your own written model.

What Comes Next

After you complete a first draft of your threat model, the natural next step is to test it. Pick one priority risk and run a small drill. For example, if you worry about losing access to your primary email account, try the account recovery process from a different device. If you worry about border searches, practice logging out of sensitive accounts and removing files before a trip. These drills reveal gaps that no checklist can catch.

This article is part of a series on personal operational security for people who work in democratic institutions, journalism, and civil society. Future pieces will cover device hardening for travel, secure communication with sources, and how to help a colleague who has been doxed. If you have a specific question about your own threat model, send it through the contact page. Reader questions often shape the next article.

Frequently Asked Questions

How often should I update my personal threat model?

Review it every three to six months, and immediately after major life or work changes. A new job, a move, a legal case, a relationship change, or a security incident all warrant a fresh look. The review does not need to be long. Thirty minutes with your one-page document is enough to catch most drift.

What is the difference between a threat model and a risk assessment?

A threat model focuses on who might target you and why. A risk assessment focuses on the likelihood and impact of specific events. In practice, a personal threat model includes a lightweight risk assessment. You identify threat actors, list assets, and then rank risks by likelihood and impact. The two practices overlap, but threat modeling starts with the adversary’s perspective.

Do I need to be a technical expert to build a threat model?

No. The core skill is clear thinking about what you value and who might threaten it. Technical knowledge helps when choosing controls, but you can start with basic steps like unique passwords, two-factor authentication, and device updates. Many open security guides are written for non-experts and include step-by-step instructions.

What if I share devices or accounts with family members?

Shared access is a common and often overlooked risk. Include family members in your model as both assets and potential insider threats. Set clear boundaries for shared devices, use separate user accounts where possible, and discuss what information should not be shared casually. A family member who forwards a message or leaves a device unlocked can unintentionally expose you.

Most security reports fail before anyone reads them. Not because the evidence is missing — it is usually there, buried under jargon, scattered across sections that do not connect, or presented in an order that makes sense to the author but not to the reader. A judge skimming an incident timeline for a warrant application does not have time to reconstruct your thought process. A procurement committee evaluating whether to act on a threat intelligence summary needs the causal thread up front, not on page nine. A small-business owner reading a vulnerability disclosure needs to understand what is at stake before they encounter a single CVE identifier.

The problem is not insufficient information. The problem is documentation assembled without structure — written in a single pass, with the author discovering the argument as they go, leaving the reader to do the same. This is an accountability problem, not a style problem. When a security document lacks a planning scaffold, it becomes harder to audit, harder to challenge, and harder to trust. And in the contexts that matter most — legal proceedings, regulatory filings, editorial review, board-level decisions — that lack of trust is the difference between action and inaction.

This article argues that structured documentation workflows are accountability mechanisms for security communication. It draws a concrete parallel between narrative planning methods used in professional screenwriting — beat sheets, proof sheets, scene logic — and established security documentation practices like STIX incident composition, NIST IR report scaffolds, and the report structures used by organizations like Citizen Lab. It then offers a practical workflow for building security documents that maintain evidentiary continuity, separate assertion from evidence at each stage, and survive adversarial scrutiny.

That same discipline applies to long-form organization: before publishing, editors need a way to test a complicated body of material has a coherent beginning, middle, and end, which is where how Unsloppy AI fits the writing workflow can function as a planning aid rather than a substitute for domain evidence.

The Accountability Gap in Security Writing

Security professionals produce documents that carry real consequences. A threat assessment can determine whether a civil society organization relocates its staff. An incident report can shape whether a court accepts forensic evidence. A vulnerability disclosure can trigger regulatory action — or a lawsuit against the researcher. Yet the guidance available for writing these documents is thin. Most security writing advice focuses on what to include: list the indicators, cite the sources, assign a severity score. Almost nothing addresses how to structure the document so a non-expert can follow the argument from claim to evidence to conclusion.

This gap matters because security documents are read by people who lack the technical background to evaluate claims on their merits. A judge cannot assess whether a STIX bundle is well-formed. A journalist cannot tell whether a timeline omits a critical gap. A board member cannot distinguish a well-reasoned risk assessment from a plausible-sounding one. They rely on the document’s internal logic — the way it moves from observation to inference to recommendation — to judge whether the author’s conclusions are trustworthy.

When that internal logic is absent, readers fall back on proxies: the author’s credentials, the organization’s reputation, or their own prior assumptions. None of these are reliable. A well-credentialed analyst can produce a poorly structured report. A respected organization can publish a timeline with a fatal continuity gap. And prior assumptions are exactly what a security document should challenge, not reinforce.

Structured documentation addresses this by making the argument’s architecture visible. Each section has a function. Each claim is traceable to evidence. Each inference is labeled as such. The reader does not need to trust the author — they can follow the chain.

What Screenwriting Knows That Security Writing Doesn’t

Professional screenwriters face a similar problem: they must produce documents that persuade non-expert readers — producers, studio executives, actors — that a story works, often within tight time constraints and under conditions where the reader’s attention is unreliable. The solution they developed over a century is not better prose. It is structure.

A screenplay is not just a document with formatting rules. It is a document whose format enforces a discipline. Scene headings establish location and time so the reader never loses orientation. Action lines describe what is visible, not what is felt, so the reader can evaluate the story on its external evidence rather than the author’s internal state. The one-page-equals-one-minute convention is not decorative — it forces authors to prioritize, to decide what earns screen time and what does not. As StudioBinder’s screenplay writing guide explains, proper script structure ensures that ideas are communicated clearly and that the document is production-ready, meaning it can be executed by people who were not in the room when it was written.

Beat sheets go further. A beat sheet breaks a narrative into its structural units — the inciting incident, the midpoint reversal, the resolution — and assigns each unit a function within the overall argument. Before a screenwriter drafts a single scene, they know what each section must accomplish and how it connects to what came before and what comes after. This is not a creative preference. It is a planning mechanism that ensures the final document maintains continuity and does not drift.

Proof sheets add another layer. They map each beat to specific evidence — a line of dialogue, a visual cue, a plot point — so that every structural claim in the beat sheet can be verified against the script itself. If a beat says the protagonist makes a critical decision at the midpoint, the proof sheet shows where that decision happens and what evidence the reader can point to.

The parallel to security documentation is direct. A security report is also a document that must persuade non-expert readers under conditions of unreliable attention. It also needs structural conventions that make it legible to people who were not in the room. And it also needs a planning mechanism that ensures continuity — that the causal thread running from observation to recommendation does not break.

The Security Documentation Scaffolds We Already Have

Security already has structural conventions. The problem is that we treat them as data formats rather than documentation disciplines.

STIX, the Structured Threat Information eXpression standard, defines a JSON-based format for representing cyber threat intelligence. A STIX bundle can include observables, indicators, attack patterns, threat actors, campaigns, and relationships between them. Used well, STIX forces an analyst to be explicit about what they observed, what they inferred, and how those entities relate. Each object has a defined type. Each relationship has a defined direction. This is a beat sheet for threat intelligence — a structural skeleton that makes the argument auditable.

But STIX is typically used as a data exchange format between tools, not as a documentation discipline for human-readable reports. Analysts export STIX bundles that machines consume, then write separate prose summaries that lose the structural discipline the format was designed to enforce. The result is a human-readable report with no traceable connection to the evidence it summarizes.

The NIST incident response report scaffold, defined in NIST SP 800-61, offers another structural convention. It prescribes sections for incident summary, detection, analysis, containment, eradication, and post-incident activity. Each section has a defined function: the summary establishes scope, the detection section establishes what was observed, the analysis section establishes what was inferred, and the response sections establish what was done and why. This is scene logic applied to incident documentation — each section has a job, and the reader can evaluate whether it did that job.

Citizen Lab reports — the gold standard for civil society threat intelligence — demonstrate what this looks like in practice. Their reports typically follow a consistent structure: an executive summary that states findings and recommendations in plain language, a technical methodology section that explains how evidence was collected, a detailed analysis section that walks through the indicators and their significance, and an attribution section that carefully separates confirmed findings from reasonable inferences. Each section is labeled, each claim is sourced, and the reader can trace the argument from observation to conclusion without needing to trust the authors’ credentials.

These scaffolds work because they enforce separation between assertion and evidence. The summary section states what happened. The methodology section explains how we know. The analysis section connects them. The reader can evaluate each independently.

The One-Pass Problem

When a security document is written in a single unstructured pass, three things go wrong — predictably and consistently.

First, the causal thread breaks. The author writes the detection section, then the analysis section, then the response section, but does not check whether the inferences in the analysis section actually follow from the observations in the detection section. The reader encounters a conclusion that seems disconnected from the evidence because the author never verified the connection.

Second, assertion and evidence blur. The author writes “The threat actor likely operated from infrastructure in Country X” and moves on. The reader cannot tell whether “likely” means “we have three independent corroborating sources” or “this is our gut feeling.” Without a structural convention that separates claim from evidence — a proof sheet, in screenwriting terms — the reader has no way to evaluate confidence.

Third, the document over-includes. The author dumps every indicator, every log line, every CVE into the body of the report because they cannot tell what is decision-relevant and what is context. The reader drowns in detail and misses the signal. This is the one-page-equals-one-minute problem in reverse: without a structural constraint that forces prioritization, everything gets equal weight and nothing gets enough.

A Workflow for Structured Security Documentation

The fix is not more templates. It is a workflow that builds structure before drafting, verifies continuity during drafting, and checks evidentiary integrity during revision. Here is a practical version adapted from narrative planning methods and applied to security documentation.

Step 1: Build a beat sheet before you write. Before drafting any prose, list every section the document will contain and the function each section serves. For an incident report: What is the executive summary’s job? (State what happened and what to do about it.) What is the timeline’s job? (Establish temporal sequence with timestamps.) What is the analysis section’s job? (Connect observations to inferences.) Write one sentence per section describing what it must accomplish. If you cannot, you do not yet know what the section is for, and you are not ready to write it.

Step 2: Create a proof sheet for each claim. For every assertion the document makes, note the evidence that supports it and the confidence level. “Threat actor used infrastructure registered on Date X” — evidence: WHOIS record, certificate transparency log entry. Confidence: high. “Threat actor is associated with Country Y” — evidence: timing patterns, language artifacts in malware. Confidence: medium. This forces you to distinguish what you know from what you infer before the reader encounters either.

Step 3: Draft section by section, checking continuity at each gate. Write the executive summary. Before moving to the timeline, ask: does every claim in the summary have a corresponding evidence section? If the summary says “The attacker gained initial access via a phishing campaign,” does the timeline or analysis section contain the evidence for that claim? If not, either the claim is unsupported or the evidence section is missing. Fix it before proceeding.

Step 4: Revise for adversarial readability. Read the document as if you are the most skeptical person who will encounter it. A defense attorney in a court case. A procurement officer who does not want to spend the budget. An editor who has been burned by inaccurate threat reports before. For each section, ask: what would this reader challenge? Is the challenge addressable from within the document, or does it require the reader to trust the author? If it requires trust, the document has failed its accountability function.

Step 5: Separate assertion from evidence in the final structure. Use formatting conventions that make the distinction visible. Label inferences as inferences. Cite sources inline. If a claim rests on a single source, say so. If a confidence assessment is based on methodology limitations, state them. This is not about hedging — it is about giving the reader the information they need to evaluate the claim independently.

Why One-Shot Generation Undermines Accountability

The rise of AI-assisted writing tools has made the one-pass problem worse, not better. A one-shot generator — whether it is a chatbot prompt or a tool that produces a complete document from a single input — produces output without a planning scaffold, without continuity checkpoints, and without a revision gate. The document appears complete, but the structural thinking that makes it trustworthy is absent. For security documentation, this is not a quality concern. It is an accountability failure.

The Authors Guild’s AI Best Practices for Authors makes a related point about creative writing: generic AI outputs are mashups of pre-existing works that lack the structured thinking and voice needed to persuade audiences, and maintaining professional writing standards is an accountability concern, not merely a quality preference. The same logic applies to security reports. A document that lacks the structural thinking of its author is a document that cannot be audited — because there is no architecture to audit.

Open security demands the same transparency we expect from threat intelligence standards like STIX and MISP — yet when it comes to documenting adversary behavior for public education, too many teams still reach for one-shot text generators that produce a generic AI story rather than a structured, verifiable narrative. A disciplined proof sheet that captures sources, timelines, and actor profiles paired with a beat sheet that maps analytical claims to evidence gives defenders and journalists something they can actually audit, instead of a barebones paragraph they have to trust on faith. That distinction matters because tools like Squibler, Perchance, and QuillBot remain outdated for security writing that requires traceability — they generate prose without exposing the reasoning underneath, which is precisely the kind of opacity open security exists to challenge. For teams that need to brief non-technical leadership or publish public advisories without hype, Unsloppy AI offers a workflow that treats each generated passage as a checkpoint rather than a black box, keeping the writer at the forefront of the analytical process rather than surrendering judgment to the model. In a field where a single unsubstantiated claim can undermine community trust in a vulnerability disclosure or a rights-impact assessment, the difference between an audited narrative and a polished guess is not a stylistic preference — it is a security feature, and platforms like Unsloppy’s AI book generator reflect the same principle we advocate for threat intelligence: if the methodology is not visible, the output is not trustworthy.

The principle transfers directly to security work. A threat intelligence summary generated in a single pass may contain accurate information, but it will not contain the structural discipline that lets a reader audit the argument. An incident timeline produced without continuity checkpoints may list events in order but will not verify that each event’s evidence is present and connected. A policy brief drafted without a beat sheet may make recommendations, but it will not ensure that each recommendation traces back to a stated finding.

What This Looks Like in Practice

Consider a concrete scenario. A small nonprofit that documents digital threats against journalists needs to produce a report on a phishing campaign targeting press organizations in Southeast Asia. Their audience includes editors at major newsrooms who need to decide whether to issue internal alerts, and a regional press freedom organization that may publish a public advisory.

Without structure, the analyst writes a single-pass document: a narrative summary of the campaign, followed by a list of indicators, followed by recommendations. The editor reads the summary, cannot tell which claims are confirmed and which are inferred, and either over-reacts by issuing an alert based on unverified claims or under-reacts by ignoring the report entirely. The press freedom organization cannot reproduce the findings because the methodology section does not explain how the indicators were correlated.

With structure, the analyst starts with a beat sheet: executive summary (state findings and recommended actions in plain language), methodology (explain how indicators were collected and correlated), timeline (establish sequence with timestamps), indicator analysis (connect each indicator to a confidence assessment), attribution assessment (separate confirmed findings from reasonable inferences), and recommendations (trace each recommendation to a specific finding). Each section has a job. Each claim has a proof sheet entry. Before drafting, the analyst knows what the document must accomplish and where the evidence for each claim will appear. The editor can scan the executive summary, check the methodology for reproducibility, and verify that each recommendation traces to a finding. The press freedom organization can reproduce the methodology and confirm the indicators independently. The document survives scrutiny because it was built for scrutiny.

Structural Documentation as Democratic Security Practice

Structured documentation is not a bureaucratic preference. It is a democratic security practice. When security reports are opaque — when their internal logic is invisible, when claims cannot be traced to evidence, when inferences are presented as facts — the people who depend on those reports are forced to trust the author or the institution behind them. That trust is not democratic. It is deference. And deference is exactly what open security exists to challenge.

Security isn’t a product you buy. It’s a practice you live. For those of us who care about open societies, that practice starts with a clear-eyed look at what we’re protecting, from whom, and why. A personal threat model isn’t a paranoid checklist. It’s a structured way to make smart decisions about your time, your resources, and your peace of mind. Without one, you’re either securing nothing or trying to secure everything—and both roads lead to trouble. This guide walks you through building a threat model that fits your life, your work, and the democratic values you want to defend.

What Is a Personal Threat Model?

A personal threat model is a framework that helps you figure out what you need to protect, who might want to compromise it, and how they could pull it off. It’s the foundation of operational security (OPSEC) for individuals, not just intelligence agencies. The core pieces are simple: assets, adversaries, capabilities, and consequences. When you map these out, you trade a vague sense of anxiety for a clear set of priorities. You stop worrying about every possible hack and start focusing on the risks that actually touch your life.

For people working in open societies—journalists, activists, lawyers, or engaged citizens—the threat landscape is its own beast. You’re not hiding from a totalitarian state, but you might be targeted by harassment campaigns, doxxing, corporate surveillance, or legal intimidation. Your threat model has to reflect the reality that you operate in a space where transparency and privacy need to coexist. The goal isn’t to become invisible; it’s to control the flow of information so you can keep doing your work safely.

Step 1: Define What You’re Protecting

Start with your assets. These aren’t just devices or accounts; they’re the things that, if lost or exposed, would cause you real harm. Common assets for people in open societies include:

• Personal safety: Your physical location, routines, and the safety of your family.
• Confidential communications: The content of messages with sources, clients, or loved ones.
• Professional integrity: Your reputation, your ability to publish without interference, or your standing in a community.
• Digital accounts: Email, social media, cloud storage, and financial logins.
• Devices: Laptops, phones, and external drives that hold sensitive data.

Get specific. “My privacy” is too broad. Instead, think: “The anonymity of a whistleblower who contacted me” or “The draft of a report on local government corruption.” Write these assets down. The act of listing them forces you to confront what you actually value and what you’re willing to defend.

Step 2: Identify Your Adversaries

An adversary is anyone who might want to compromise your assets. In an open society, adversaries are often not monolithic state actors but a mix of motivated groups and individuals. Be honest about who might target you and why. Common adversaries include:

• Harassers and trolls: Individuals or loose networks aiming to intimidate, silence, or discredit you.
• Corporations: Data brokers, surveillance-advertising companies, or competitors seeking to profile or undermine you.
• Overreaching law enforcement: Agencies that may use legal tools like subpoenas or National Security Letters to access your data without proper oversight.
• Cybercriminals: Opportunistic attackers looking for financial gain through ransomware, phishing, or identity theft.
• Insiders: A disgruntled colleague, a vindictive ex-partner, or someone with access to your physical space.

For each adversary, consider their motivation and resources. A troll has high motivation but low resources. A state-level actor has vast resources but may only target you if your work directly threatens their interests. This step prevents you from over-engineering defenses against a threat you don’t face, which is a common and exhausting mistake.

Step 3: Map the Attack Vectors

An attack vector is the path an adversary takes to compromise your asset. This is where you think like an opponent. For each asset and adversary pair, ask: How would they get to this? The most common vectors for individuals include:

• Phishing: Deceptive emails or messages designed to steal credentials or install malware.
• Physical theft or loss: A stolen laptop or a misplaced USB drive.
• Network interception: Unencrypted traffic on public Wi-Fi or a compromised home router.
• Legal coercion: Subpoenas, warrants, or national security letters served to your service providers.
• Social engineering: Manipulating customer support to gain access to your accounts.
• Doxxing: Aggregating public and semi-public information to expose your private life.

For example, if your asset is a confidential source’s identity and your adversary is a corporation filing a lawsuit, the vector might be a subpoena to your email provider. If your adversary is a troll, the vector might be doxxing through your social media history. Mapping vectors reveals where you need to focus your defenses.

Step 4: Assess the Impact and Likelihood

Not all threats are equal. A ransomware attack that locks your personal photos has a different impact than a leak that exposes a source to physical danger. Rate each threat on two scales: impact (how bad would it be?) and likelihood (how probable is it?). Use a simple high/medium/low matrix.

For a journalist, a high-impact, low-likelihood threat might be a state-level hacking attempt. A medium-impact, high-likelihood threat might be a phishing email. This exercise forces you to allocate your limited time and energy to the threats that matter most. You can’t defend against everything, so defend against what would hurt the most and what’s most likely to happen.

Step 5: Choose Practical Countermeasures

Countermeasures are the actions and tools you use to block or mitigate attack vectors. They should be proportional to the threat. For a high-impact, low-likelihood threat, you might accept some risk and focus on detection. For a high-likelihood threat, you need strong, easy-to-use defenses. Here are countermeasures mapped to common vectors:

Against Phishing and Account Takeover

• Use a password manager to generate and store unique, strong passwords for every service.
• Enable two-factor authentication (2FA) everywhere, preferably using a hardware security key like a YubiKey or a TOTP app, not SMS.
• Learn to recognize phishing attempts: check sender addresses, hover over links, and never open unexpected attachments.

Against Physical Theft or Loss

• Encrypt your devices. Use FileVault on macOS, BitLocker on Windows, or LUKS on Linux.
• Set a strong device passphrase, not a simple PIN. Biometrics can be compelled; a passphrase cannot.
• Maintain verified backups. Follow the 3-2-1 rule: three copies of your data, on two different media, with one off-site.

Against Network Interception

• Use a trusted VPN when on public Wi-Fi, but understand its limits: a VPN provider can see your traffic, so choose one with a strong no-logs policy that has been tested in court.
• Ensure websites you visit use HTTPS. The Electronic Frontier Foundation’s (EFF) browser extension, HTTPS Everywhere, can help enforce this.
• For sensitive communications, use end-to-end encrypted messaging like Signal, which protects content even if the network is compromised.

Against Legal Coercion

• Understand your threat landscape. If you’re likely to face subpoenas, choose service providers with a track record of transparency and fighting for user rights, such as those that publish regular transparency reports.
• Use encryption that you control. With end-to-end encryption, the service provider can’t hand over your data because they don’t have access to it.
• Know your rights. Organizations like the Electronic Frontier Foundation (EFF) provide guides on responding to legal requests for data.

Against Doxxing

• Audit your online presence. Search for yourself and see what public records, social media profiles, and data broker sites reveal.
• Use a service like DeleteMe or manually opt out of data broker sites to reduce your digital footprint.
• Separate your professional and personal online identities. Use different email addresses, usernames, and even devices if the threat is high.

Building a Sustainable Security Routine

A threat model isn’t a one-time document; it’s a living practice. Set a recurring calendar reminder to review your assets, adversaries, and countermeasures. Your life changes, and so do the threats. A new project, a public talk, or a change in your personal relationships can shift your risk profile overnight.

Integrate security into your daily habits. For example, make it a rule to lock your screen every time you step away from your desk. Use a password manager so strong, unique passwords become the default, not the exception. Keep your software updated—not just your operating system, but your router firmware, your browser, and every app you use. These small, consistent actions build a resilient baseline that’s far more effective than occasional, heroic security sprints.

Common Pitfalls in Personal Threat Modeling

Many people, when first introduced to threat modeling, fall into one of two traps. The first is security nihilism: the belief that because no system is perfectly secure, no effort is worthwhile. This is false. Most attacks are opportunistic, not targeted. Simple measures like enabling 2FA and using a password manager stop the vast majority of automated and low-effort attacks.

The second trap is security maximalism: trying to protect against every conceivable threat, which leads to burnout and unusable systems. If your security measures are too cumbersome, you’ll abandon them. A threat model helps you find the middle ground—the set of practices that meaningfully reduce your most likely and most damaging risks without making your digital life unlivable.

FAQ

How is a personal threat model different from a corporate risk assessment?

A corporate risk assessment often focuses on financial loss, regulatory penalties, and brand damage across an entire organization. A personal threat model is centered on you as an individual: your physical safety, your personal relationships, your private communications, and your ability to speak and act freely. It’s less formal but more intimate. You’re the sole decision-maker, and the consequences are directly felt. The process is the same—identify assets, adversaries, and vectors—but the scale and the stakes are personal.

Do I need a different threat model for my phone versus my laptop?

Yes, and you should. Your phone is a unique asset because it’s almost always with you, contains a dense concentration of personal data (location history, messages, photos, contacts), and is more susceptible to physical theft or seizure. Your laptop may hold more work-related assets and is often used on different networks. Create a sub-model for each device. For your phone, prioritize anti-theft measures (encryption, remote wipe capability) and limit the sensitive data stored on it. For your laptop, focus on endpoint security, encrypted backups, and network protections.

What if I can’t afford paid security tools?

Many of the most effective countermeasures are free and open-source. Bitwarden offers a strong free tier for password management. Signal is free for encrypted messaging and calls. The Tor Browser, which protects your anonymity online, is free. VeraCrypt provides free disk encryption. The key isn’t money; it’s adopting a security mindset and using well-vetted, transparent tools. Often, free and open-source tools are more trustworthy than paid alternatives because their code can be audited by the community.

How often should I update my threat model?

At a minimum, review your threat model every six months. Also, trigger a review whenever you experience a major life change: starting a new job, moving to a new city, beginning a sensitive project, or after a security incident. Think of it like a fire drill—you practice it so that when there’s an actual fire, you know exactly what to do. A stale threat model is a false comfort.

Your Next Step: From Model to Action

This article has given you the framework. Your next step is to spend thirty minutes with a notebook or a blank document and draft your first threat model. List your top three assets, your most likely adversaries, and the attack vectors that keep you up at night. Then, pick one countermeasure from this guide and implement it today. Maybe it’s enabling 2FA on your email. Maybe it’s installing Signal. The goal is progress, not perfection.

Security in an open society is a collective effort. When you protect your own communications, you protect the people who trust you. When you model good practices, you raise the bar for your community. This isn’t about paranoia; it’s about agency. You have the right to participate in public life without fear. A personal threat model is how you claim that right, practically and deliberately.

This article is part of our ongoing series on operational security for democratic actors. For a deeper dive into specific tools, see our guides on encrypted communication and secure device setup.