An organization's security minimum: six priorities worked back from Japan's 2026 breaches

VPN appliances, remote desktop gateways, firewall admin panels — list every device reachable directly from the internet, with model, version and who owns updating it. In Japan's National Police Agency statistics, 61 of 92 valid responses on ransomware entry points were VPN appliances.

First step: for each device on the list, set one number — how many days you allow before closing a vulnerability once it is confirmed exploited (KEV). Patching "in turn" is the same shape as the Digital Agency case. More in VPN appliances are the biggest way in.

Every organization has accounts belonging to people who aren't staff — maintenance vendors, contractors, people who have left. They tend to get broad permissions for convenience, and it is unclear who owns them.

First step: list every non-staff account and give each an internal owner and an expiry date. Then enable only when in use, restrict source addresses, and require phishing-resistant two-factor authentication. Put account shutdown on the same form as onboarding.

In Aflac's case the attack looked the same as normal use. If each query is individually valid, checking each query won't stop it. What remains is how many records left per hour and activity at night and on weekends.

First step: on the one feature that returns the most customer data, add a per-account hourly cap and an alert that reaches a named person at 80% of it. On file servers and cloud storage, alert on bulk downloads several times above normal. Design guidance is in rate limiting and abuse control.

In Sakura Internet's case, the unauthorised access began about three years earlier. Without logs for that period, you can say neither what happened nor what didn't.

First step: keep three kinds for at least 12 months — authentication (successes and failures), data queries and exports, and admin actions — using the payment-card standard PCI DSS as a yardstick. If storage is tight, protect these three before web access logs.

In Gyazo's case the leaked metadata was mostly information attached to images uploaded years earlier. The size of a breach is set by how much data you held at that moment. Data you don't have can't leak.

First step: for each kind of customer data, write one line: what it is for and how long you keep it. Anything you can't write that line for is a candidate for deletion or anonymisation. Also check that data on cancelled users isn't lingering (in Sakura Internet's case, member data was kept after cancellation unless the member separately withdrew).

With Adobe Commerce, the bulletin at release said "priority 2, not aware of exploits", and 44 days later CISA confirmed exploitation. For WordPress core it took three days.

First step: set up one way to get notified when a product you run is added to KEV, and make "re-order the patch queue" the rule when it happens. The decision process is in prioritising with CVSS, EPSS and KEV.