A threat model is a practical account of what you want to protect, who could harm it and how you will respond. For personal privacy, it helps you choose a manageable set of actions instead of trying to defend every piece of information against every possible observer. EFF’s security-planning guide makes the relationship between assets, adversaries, consequences and effort explicit.［1］

Key Takeaways

Describe a specific harm before choosing a tool.

Separate an adversary’s possible capability from evidence that a threat is likely.

Include recovery, trusted help and the cost of maintaining a measure.

Review the plan when circumstances change, rather than treating it as a certificate of safety.

Why does a personal threat model start with a concrete situation?

“Improve my privacy” is difficult to finish. “Keep a stolen laptop from exposing my client records” gives you a situation, an asset and an unwanted outcome. The narrower sentence does not claim that theft is certain; it helps you decide what protection and recovery would actually mean.

MDN discusses threat modeling for applications and websites, including the system, what can go wrong, responses and evaluation.［2］ A personal plan uses a smaller scope. You do not need to build a software architecture diagram, assign formal scores to every activity or become an expert in every threat framework to make a useful decision.

Keep one situation per row. An advertising company correlating visits and someone who can unlock your phone have different access. A single list saying “stop tracking” conceals that difference. For a broad map of accounts, devices and networks, use the digital privacy guide; use this worksheet to decide what you will do about one situation.

The plan itself can contain sensitive information, including names, relationships and weak recovery routes. Choose a storage location appropriate to the people you are concerned about. You can use role descriptions instead of names and avoid recording actual passwords, backup codes or private source identities. Sharing a worksheet widely is not required for it to be useful.

Step 1: What assets and data paths do you want to protect?

An asset is something you value. It might be access to your main email, private photographs, a contact’s identity or your ability to recover a work account. List where the information lives and who already has access. EFF includes both information and devices in this discussion.［1］

Follow one ordinary journey of that information. A document may exist on a laptop, in cloud storage, in an email attachment and on a colleague’s device. Protecting the laptop alone does not protect the other copies. Draw the path with words if that is easier: “phone → cloud account → shared folder → recipient.”

Field to fill in	Prompt	Illustrative entry
Asset	What would hurt to lose or expose?	Client contact spreadsheet
Copies and access	Where is it kept, and who can open it?	Laptop, cloud folder, two colleagues
Unwanted outcome	What harm are you trying to prevent?	Disclosure after the laptop is stolen
Current protection	What already limits that path?	Device lock; check encryption status
Unknown	Which assumption needs checking?	Whether an old sharing link still works

Do not put the spreadsheet’s real contents in the worksheet. A description is enough. Where a loss would affect another person, include their needs and consent in the plan. Our sensitive-data guide helps distinguish information whose exposure would have different consequences.

Step 2: Who could cause the harm, and what access do they have?

Describe an adversary by access and incentive. “A stranger with the stolen laptop” differs from “a colleague already invited to the cloud folder.” Neither description proves bad intent. It identifies a route that a particular protection would need to address.

Write observed facts separately from assumptions. “This person knows my old password” is a claim you may be able to verify; “they can bypass any device lock” is a much broader assumption. Mark uncertain capabilities instead of quietly treating them as established. A plan can remain useful while an uncertainty is unresolved.

For example, a shared recovery email may allow account recovery even after you replace the main password. A public-post audience may learn a location from a photograph without compromising any account. These are illustrative access paths, not evidence that either event happened to you.

The same distinction applies to technical tracking. If the concern is a site correlating browser visits, investigate browser fingerprinting. If the concern is someone holding your unlocked phone, changing browser attributes addresses a different route. Name the route before deciding that a privacy feature is relevant.

Step 3: How do you assess privacy risk without invented numbers?

Risk combines likelihood and consequence.［2］ You can use plain-language categories such as plausible, uncertain or unlikely, provided you record why you chose them. A percentage without supporting data makes the worksheet look precise without improving the decision.

Consider consequences first. Losing access for an afternoon and exposing a vulnerable contact’s identity are different harms even if the same account is involved. Ask whether the harm is reversible, whether others are affected and how quickly you would need help. A low-frequency event can still justify preparation when its consequences are severe.

Then note evidence of likelihood: a lost device, an unfamiliar account-recovery change or the way a folder is actually shared. Keep “possible in principle” separate from “observed in my circumstances.” Absence of evidence is not proof of impossibility, but it also does not support describing every imaginable capability as an active attack.

Pick a small number of priorities. EFF’s approach includes deciding what effort you can sustain and which threats you will take seriously.［1］ You can explicitly defer a low-impact concern, with a reason and a review trigger. Accepting a residual risk consciously is more useful than a long list of precautions you never use.

Step 4: Which personal privacy plan actions match the route?

For each priority, select a preventive measure, a way to check it and a recovery action. A reminder to “be careful” is not a measure you can verify. “Review who can open this folder” has a clear result; “confirm that a recovery method still belongs to me” has a clear check.

Situation	A measure to evaluate	A check	Residual limitation
Laptop loss	Device locking and storage encryption	Inspect the actual device’s protection state	A copy already sent elsewhere remains outside it
Account takeover	Unique credentials and additional authentication	Review recovery options and active sessions	A deceived user may still approve a malicious action
Browser correlation	Documented browser privacy controls	Compare the same profile and required services	Logging in supplies account identity
Network observation	Appropriate encrypted connections	Check the intended connection is in use	The destination and endpoint still have their own access

Network-path protection belongs in a model only where that path is relevant. AethoVPN can be considered for that layer, but it does not remove a recipient’s access to a shared document or secure an already unlocked device. The article what a VPN protects against hackers explains the boundary when choosing network measures.

Encryption also depends on where protection begins and ends. EFF distinguishes transport and end-to-end encryption and discusses the limitations of encryption when a device is accessible.［3］ Write down the observer you want to exclude, rather than assuming that the word “encrypted” excludes everyone along every route.

Check recovery before relying on a new restriction. If you remove a recovery method, make sure you still have an appropriate route to regain access. Keep recovery secrets out of the worksheet. Account lockout is a foreseeable cost of a plan that improves protection without considering how you will operate it.

For the account row, evaluate password-manager access and recovery safeguards before choosing how to store credentials. For the device row, list what each app is allowed to access, rather than treating every installed app as equally trusted. Record the relevant access route and a way to check it in the worksheet.

Step 5: How can different people adapt the worksheet?

These examples illustrate choices; they are not incident reports or universal prescriptions. Replace the assumptions with your own circumstances. A traveller, a freelancer and someone concerned about a known person do not need identical priorities merely because they all use the same phone.

A traveller might prioritise access to reservations and recovery after losing a phone. The asset includes the ability to continue the trip, not just secrecy. Check access from a backup route before leaving, reduce unnecessary document copies and choose whom to contact if the main device is lost. Do not assume every unfamiliar network is an attack already in progress.

A freelancer might prioritise client files and account recovery. The worksheet should include invited collaborators, exported files and old sharing links. A useful review can establish who retains access after a project ends. The network connection is only one part of that arrangement; it cannot withdraw a file that a recipient already downloaded.

Someone concerned about a known person’s access may need to consider shared devices, accounts and recovery channels. Changes can be visible to that person. If you feel at risk, seek trusted specialist support from a safe device before making changes that could increase danger. A generic worksheet does not replace a personal safety assessment or emergency help.

Include allies in every example. A trusted colleague can confirm access to a folder; a trusted friend may hold an agreed recovery contact; a support organisation may help assess safety. EFF includes allies as part of security planning.［1］ Choose them deliberately rather than assuming every contact should receive sensitive details.

Step 6: When should you review the model and test recovery?

Write a review trigger next to each important assumption. Losing a device, ending a collaboration, changing a relationship, enabling a new sharing feature or receiving a relevant alert can make the old model inaccurate. A regular reminder can supplement these triggers, but does not replace responding to an actual change.

Review evidence, not just whether you followed the checklist. Confirm that the intended access restriction exists and that recovery remains usable. A completed action with no check can leave an unnoticed gap. MDN’s evaluation stage asks whether the response was sufficient; the personal equivalent is checking the route you meant to change.［2］

Keep the plan short enough to revisit. Record unresolved assumptions and the limits of each measure. If an action costs more time, money or disruption than you can sustain, choose a smaller workable measure or consciously reconsider the priority. Privacy planning is an ongoing decision, not a one-time score.

Summary

Start with one asset and a specific unwanted outcome.
Map copies, access and recovery before selecting tools.
Distinguish observed capability, likelihood and consequences.
Match measures to the route, involve trusted help and review changed assumptions.

FAQ

Do I need technical expertise to make a threat model?

No. A personal model can use ordinary language and a small worksheet. Technical detail is useful when it changes the decision, but identifying assets, access and consequences is already a meaningful start.［1］

Is a threat model the same as a privacy checklist?

No. A checklist lists actions; a model explains which harms those actions address and what remains. You can use a checklist after identifying priorities, rather than applying every item without context.

Should I list every imaginable adversary?

No. Focus on relevant actors and plausible access, marking uncertain assumptions. An exhaustive list can consume effort without changing a practical decision, especially when it treats possibility as evidence of an active attack.［1］

Can a VPN solve my whole threat model?

No. It addresses a network layer where relevant. Account recovery, shared files, recipient access and unlocked devices remain separate routes that require their own measures and checks.

Where should I store the worksheet?

Choose a location appropriate to the access you are concerned about. Avoid writing secrets or unnecessarily identifying people, and do not assume a shared device is a suitable place for sensitive planning notes.

How often should I update the model?

Review it when an important assumption changes and use a reminder if helpful. A device loss, changed relationship, new sharing feature or relevant alert can justify reviewing it before a scheduled date.［2］

What if I cannot prevent a serious threat alone?

Include trusted allies and specialist support where appropriate. If personal safety is involved, use a safe route to obtain help; a general worksheet does not replace emergency assistance or an individual safety assessment.［1］

Sources:

EFF — Your Security Plan: https://ssd.eff.org/module/your-security-plan
MDN — Threat modeling: https://developer.mozilla.org/en-US/docs/Web/Security/Threat_modeling
EFF — What Should I Know About Encryption?: https://ssd.eff.org/module/what-should-i-know-about-encryption

Sources checked 5 October 2026.

What Is a Threat Model? A Simple Privacy Plan