DEV Community

早川徳一 for Exapolicy

Posted on Originally published at zenn.dev

List what you need to protect before you choose your defenses

Where this starts

Companies keep reporting leaks of their customers' personal data. In Japan, where we are based, the Digital Minister said at a press conference on October 6, 2026 that cyberattacks are not only a problem for companies and organizations, and asked individuals to take their own basic steps (Digital Agency, press conference summary, in Japanese).

Of course, once you have handed your information to a company, nothing you do afterwards gets it back. In an earlier post (in Japanese) we argued that this is exactly why you need a policy for the information you are about to share: split it into "never share", "check before sharing" and "fine to share".

But that policy is not enough on its own. If you don't also look after the environment you keep your information in — which accounts, which devices, which backups — the information you decided never to share can still leak without you meaning it to. If your PC is taken over, for example, the information you would never have shared walks out with it.

This post is about the step before you secure that environment: listing what you need to protect. It is the method we use to check our own company's information handling, rewritten so that individuals can use it.

1. Why start with a list

When we reviewed our own environment (the next post covers that), none of the gaps we found had been created at once. They had built up, one permission at a time, for convenience.

We noticed something else, too. The OS, the router and the apps all worked fine with their out-of-the-box settings. Because they worked, we didn't notice what was missing.

In another post (in Japanese) we wrote that apps should work the moment you install them, but deciding what to protect is up to the person using them. Security is the same. Working and being protected are two different things. Products get you as far as "it works". They don't decide what you need to protect in your setup.

You can't see what's missing until you write it down. So this is the policy we follow, and the one this post recommends:

Before choosing any defense, list what you need to protect — and keep that list alive.

The rest of this post is the rules that put this policy into practice: how to make the list (sections 2 to 5) and how to keep it alive (section 6).

2. Sort what you protect onto five shelves

For an individual, it helps to sort what you protect onto five shelves:

Shelf What goes on it (examples)
Accounts Email, bank and cards, app stores, social media, AI services, cloud storage, services you use for work
Devices PC, smartphone, router, NAS or external drives, smart home devices
Data Your own personal data, other people's data you hold (clients, partners, family), work files, passwords and keys
Exits Sign-up forms, social media, AI services, file sharing
Just in case Backups, account recovery (recovery email, phone number, recovery codes), who to contact in an incident

You don't need to write everything down at once. Start with your email account. Password resets for most other services arrive by email. Whoever controls your email can take over the rest.

3. For each shelf, write "fix it if this is true"

Once you have the list, write down for each shelf the states that need fixing. The trick is to phrase each row not as a goal ("do X") but as "if this is true, fix it". A goal is easy to tick off because you think you've done it. A state you can actually check against where you are now.

Shelf Fix it if this is true (examples)
Accounts Multi-factor authentication (or a passkey) is off on any important account
Accounts You reuse the same password across services
Accounts Your recovery options live on a single device, or only in your head
Accounts Accounts for services you no longer use are still open
Devices OS or router updates have stopped
Devices Some apps accept inbound connections even on public networks
Data You keep other people's personal data you no longer need, with no end date
Data Passwords or keys sit in plain text in notes, chats or screenshots
Exits You have no step to check, before sharing, for information you decided never to share
Exits You haven't drawn a line between what you may and may not give to AI services
Just in case Your backup is always connected and writable (so it gets encrypted along with the PC)
Just in case Losing or breaking one PC would take your keys, passwords and important files with it
Just in case You would reset a password or change payment details on a phone call or email alone
Just in case You haven't looked up what to do first, or who to call, if something happens

The three steps the Japanese Digital Minister asked people to take on October 6 map directly onto rows on the Accounts shelf:

The minister's ask What the summary explains (paraphrased) Row in your list
Stop reusing passwords If one service leaks, attackers can log in to other services with the same password. Use a different password for each service You reuse the same password across services
Use multi-factor authentication Even if your ID and password leak, phone-based verification or one-time codes make unauthorized logins much less likely Multi-factor authentication (or a passkey) is off on any important account
Watch out for suspicious email and SMS Phishing that impersonates real companies and government agencies is increasing. Don't open links casually; go through the official website or app You log in or enter details straight from links in email or SMS

None of the three is special. Written as rows in your list, each becomes something you can check yourself against.

For reference, this is what we actually do on our own Accounts shelf:

  • Two-step verification is on for almost all of our accounts
  • Passwords are kept in a password manager (no reuse)
  • We use passkeys where services support them
  • We don't click links in emails right away

None of this is special either. But put next to the rows in the list, "almost all" turns into a clear next step: find out which ones are left.

For the Data and Exits shelves, the three categories from the earlier post work as they are:

Category Examples
Never share National ID numbers, credit card numbers, passwords, images of ID documents (except to services that require them)
Check before sharing Phone number, email address, home address, date of birth, employer, names and contact details of clients
Fine to share What is already on your public profile

4. Record one of three states

We record the current state of each row as one of three:

State Meaning
Confirmed You checked that it's done, and have a record (a settings screen, a note)
Unchecked There is no record that anyone has checked
Undecided You haven't decided what to do yet

The important part: don't read "unchecked" as either "done" or "not done". It only means nobody has checked. If you fill those gaps with "probably fine", the settings you only think you have go straight into your list (it happened to us; the next post covers it).

When we first built this list for our own company, there were more "unchecked" rows than we expected. Not because things weren't done, but because we had never checked.

5. Another perspective

If you don't know what belongs on your list, look at it from another perspective: analyses of other people's incidents. We took seven perspectives from a report that analyzed corporate data-leak cases:

  1. How much data you keep, and when you delete it
  2. Authentication and accounts
  3. What you expose to the internet, and how you keep it updated
  4. The outside services you rely on
  5. How you use AI (the permissions you give it, the outside documents it reads, whether a person checks its output)
  6. Backups, and your first moves in an incident
  7. Scams aimed at people (phone calls, emails, changed payment details)

That report, however, had been put together by an AI, and its case numbers didn't all agree. So we used the perspectives and left the numbers alone. What you borrow is what to look at, not how often it happens.

6. Rules for keeping the list alive

The second half of the policy is "keep that list alive". A list starts going stale the day you write it. Decide when you'll look at it again:

When What to do
Once a month (pick a day) Go through the list from the top and update the states
When you start using a new service or device Add a row
When you change something Check it afterwards, and mark it "confirmed"

Add a row whenever you start using something new. Forget that, and permissions start piling up again outside the list.

One more rule: look up how to respond before anything happens. Incidents tend to arrive when you're busy. If you start researching then, you'll be slow — or make things worse with a well-meant move. Decide in advance what to do first and who to contact, and put it on one page (a later post in this series covers how).

7. The checklist (one A4 page)

We put all of this on a single printable page: the five shelves, the "fix it if this is true" rows, a column for the state (confirmed / unchecked / undecided), and space for notes and the next review date. Print it, fill it in, and add or remove rows to fit your own setup.

What to protect — inventory checklist

Summary

This post covered how to list what you need to protect before you work on securing your environment. The policy is: before choosing any defense, list what you need to protect — and keep that list alive. News of data leaks arrives almost daily, and we think an individual's setup could be targeted at any time. If you haven't done it yet, this may be a good moment to take stock of yours. In short:

  1. Before choosing defenses, sort what you protect onto five shelves (accounts, devices, data, exits, just in case). Start with email
  2. For each shelf, write "fix it if this is true"
  3. Record the state as confirmed / unchecked / undecided — and don't read "unchecked" as "done"
  4. Take another perspective from other people's incidents; check numbers before you use them
  5. Pick a review day, and add a row whenever you start using something new
  6. Look up how to respond before anything happens

If your policy decides how you share your information, this list is the map you apply that policy to.

This is the first post in a series on security steps an individual or a very small business can take. It was first published in Japanese on Zenn. The next post is a record of how we reviewed the "devices" and "just in case" shelves in our own environment.


Exapolicy LLC builds Covenant, an AI governance app for individuals that checks what you are about to send to an AI service against rules you define, on your own machine, before it is sent. This post adapts the way we check our own company's setup for individuals; using this list does not guarantee you won't be affected.

Top comments (0)