Japan's Government Guide to Web and App Breaches, Explained for Executives

Hello, this is Ryuta Hamamoto from TIMEWELL.

Yesterday, 5 November 2026, Japan's National Cybersecurity Office, part of the Cabinet Secretariat, published a document for businesses. Its title is "Countermeasures Against Unauthorized Access That Leads to Personal Information Leaks," and its subtitle reads "Thorough Basic Measures for Websites and Mobile Apps." It runs 13 pages. The last two are a list of reference materials, so the body is 11 pages¹.

Having read it through, my impression is that the content is very much on target, but that to an executive reading it for the first time it will look almost like code. A single page can hold "SBOM," "attack surface," "BOLA," "SSRF" and "SOAR" one after another. A specialist reads it and thinks everything necessary is there. Anyone else cannot see what they are supposed to do.

So in this article I read the 13 pages in order, replacing technical terms with everyday comparisons wherever I can. I write it for executives: which measure exists for what purpose, and what to ask your staff and contractors. It is a long article, because I cover every page of the document.

Key points

• The causes the government confirmed are not new techniques. They are gaps in basic measures: weak security when building apps, misconfigured websites, and continued use of software that is no longer supported or has known flaws left unpatched.
• The document rests on three pillars. Operations and management (knowing what you own and reducing entrances), design and development (building things safely from the start), and the supply chain (not leaving contractors and external components unattended).
• The document closes by asking top management to carry out a risk assessment based on the characteristics of their systems and the information they hold. The central message to executives is not to leave this entirely to the person in charge.
• Where the document gives a way of thinking rather than a to-do list, the decision belongs to executives. Deadlines for fixes, the bar for what may go public, and the level required of contractors are management judgments, not technical ones.
• You do not need to do everything at once. Counting your own entrances, closing the ones you do not need, and adding multi-factor authentication to management functions are three things you can start this week.

Terms to get straight first

Here are the terms the rest of the document builds on. I explain the other abbreviations where they appear.

Term	In everyday terms
Vulnerability	A weakness in software, like a design mistake in a door lock. Once one is found, the maker of the software releases a corrected version (a patch)
Attack surface	The number of doors and windows a building has. The more unused back doors and windows there are, the more places someone can get in
OSS and libraries	A way of assembling software from parts that other people made. In cooking, think of ready-made sauces and seasonings
API	Something like the order counter in a shop, connecting the app to the server behind it. The app places an order, and the server answers at that window
Backend server	The kitchen and storeroom behind a website or app. It checks logins and keeps member information
Supply chain	Not just your own company but the whole chain: contractors who build or maintain your systems, and the components you use

What the government asked for, and from whom

What page 1 says

Page 1 is the preface to the whole document, and it holds the government's entire line of concern.

The government says it has confirmed multiple cases, among the recent run of information leaks caused by unauthorized access, where the apparent causes were as follows. Security was insufficient when a mobile app was built. A website had a configuration flaw. Software that was no longer supported, or software with known weaknesses that nobody had patched, stayed in use. And these problems arose not only inside the company itself but also at contractors entrusted with building or operating the systems¹.

Put into words, none of this is surprising. The victims were not broken by some new attack method. The basics had not been done. That is the government's view, and it is why the subtitle says "thorough basic measures."

The document also describes how attackers behave. They run large-scale scans of Japanese websites and other assets exposed on the internet. They get into the sites where the scan finds a way in, and they appear to have stolen personal information that way. It is like a thief who walks through town trying every door handle and enters only the houses that are unlocked.

Here the document says it is highly likely that AI is being used to research targets and carry out intrusions. It goes on to say that there are cases where risks rated "relatively low" in past vulnerability assessments may have combined to become the cause of an intrusion. Each hole was small, but three of them lined up, and a person can walk through.

One more sentence matters. Because attacks have become easier to scale up, the document says, businesses of every size are thought to be targets. "We are too small to be targeted" does not hold up under this document.

Where this document sits

October, before the document appeared, was a month of repeated alerts. The Personal Information Protection Commission issued one on 7 October, JPCERT Coordination Center on 8 October, and the National Cybersecurity Office and the Ministry of Internal Affairs and Communications each on 9 October, all concerning unauthorized access. On 13 October, the threat analysis team at the National Institute of Information and Communications Technology (NICT) then published an alert explaining the attack technique in detail².

My reading is that this document follows from that run. It narrows its audience to businesses that run websites and mobile apps and handle personal information, and it goes as far as concrete examples of measures.

The document does not create a new legal duty. It is a request, phrased as "we ask you to." That said, the document itself says in its later pages that when a business entrusts the handling of personal information to another party, Article 25 of the Act on the Protection of Personal Information requires necessary and appropriate supervision of that party¹. The part that is a request and the part that is a legal obligation need to be understood separately.

For executives, and for staff

At the end of page 1 there is a guide to how to read the document. For executives and a wide range of people in the organization, the main text sets out the basic thinking behind each measure and its background, in what the document calls the lead paragraphs. For IT and cybersecurity staff, concrete examples of measures are set in boxed sections.

In other words, the opening text of each item is what executives read, and the boxes are the work list for staff. I write this article with the same division. First the way of thinking that executives need to grasp, then the boxed examples, put into words that make clear what each is for.

A map of the 13 pages

First, here is how each page maps to a section of this article.

Pages	Content	Section of this article
1	Preface (background and how to read it)	What the government asked for, and from whom
2 to 3	1(1) Knowing your digital assets and closing vulnerabilities	Pillar 1, item 1
3 to 4	1(2) Taking inventory of the attack surface and minimizing it	Pillar 1, item 2
4 to 6	1(3) Continuous diagnosis and monitoring, including with AI	Pillar 1, item 3
6 to 7	2(1) Security by design	Pillar 2, item 1
7 to 8	2(2) Protecting the APIs you use	Pillar 2, item 2
8 to 9	2(3) Vulnerability diagnosis before release	Pillar 2, item 3
9 to 10	3(1) Governing contractors and securing connection paths	Pillar 3, item 1
10 to 11	3(2) Managing OSS and external libraries	Pillar 3, item 2
11	Closing request (decisions by top management)	What executives should decide and ask
12 to 13	Reference materials and standards	References

Pillar 1: Keep reducing entrances in operations and management

The first pillar covers what happens after a system starts running. Three measures are listed, and all of them continue for as long as the system runs, not just until it is built.

Item 1: Know what you own, and close the weak points (pages 2 to 3)

The document begins by pointing out that in cases of information leaks through unauthorized access, weaknesses hidden in the libraries and frameworks used inside web applications are being exploited. It adds that weaknesses that can be exploited remotely over the internet are especially likely to be used as a foothold to get inside a company¹.

What I want executives to know here is that a software weakness is not fixed on the day you buy. A weakness no one noticed at introduction can be discovered and made public after the system is in operation. Weaknesses also appear not only in products you bought directly but in the open source components built into them.

Take a packaged snack. Suppose one of its ingredients is recalled. Unless the manufacturer can quickly look up which products use that ingredient, it cannot even begin the recall. Software is the same. You need to be able to answer immediately whether the problem component is in your system. That is why the document calls for a setup that keeps track continuously, gathers newly published information, and can quickly identify the impact on your own organization and respond.

There is also an order of priority. Servers and network devices that anyone can reach from the internet carry a high risk of being exploited, so the document says to deal with them first.

There are four example measures for staff. I explain what each is for.

Example 1: Keep track of the software configuration. Record the OS, middleware, frameworks and libraries you use, with product name, version and where each is used. As tools that create this record automatically, the document names the SBOM (software bill of materials) and SCA (software composition analysis). An SBOM is the software version of an ingredient label. It is a list of what components are included, in which versions, and the Ministry of Economy, Trade and Industry has published an introductory guide³. SCA is a tool that builds that list automatically and checks it against known weaknesses. The document stresses that an SBOM is not something you make and then forget. You have to secure the whole run of operations: matching against vulnerability information, identifying the scope of impact, and applying fixes or interim measures.

Example 2: Keep collecting vulnerability information and check the impact. The document is specific about where to collect it. The KEV list published by CISA in the United States is a list of weaknesses confirmed to be actually exploited⁴. It tells you that there are tens of thousands of weaknesses but these are the ones being used right now, so you first check whether any of them apply to your software. Other sources it names include announcements from each product's maker, the NVD in the United States, and Japan's JVN, a vulnerability database run jointly by JPCERT Coordination Center and IPA (the Information-technology Promotion Agency, Japan)⁵. Because people cannot keep up by hand, the document also says to use a management tool that automates the detection of weaknesses where needed.

Example 3: Decide priorities and deadlines in advance. If you debate which to fix first every time a weakness is announced, you will not be in time. The document asks you to settle in advance the criteria for judging four things: how severe the weakness is, whether it is actually being exploited, whether it can be exploited over the internet, and how important the system is and what it means for the business.

I think Example 3 is the part executives should decide for themselves. A deadline such as "fix within so many days anything confirmed to be exploited" is bound up with a business decision about whether to stop the system to fix it. When one staff member decides alone, they tend to be dragged along by a field that does not want to stop anything.

Example 4: Interim measures, and checking after the fix. There are cases where a patch cannot be applied right away. Then you look at the cautions from the product's maker and take temporary measures, such as turning off the affected function or limiting who can reach it. After applying a fix, you confirm that it is really working and keep managing what remains. For weaknesses already confirmed to be exploited in particular, the document says to check the related logs (records) and investigate whether you have already been broken into.

That last sentence is easy to miss. It is not "we fixed it, so we are fine." It is "did anyone get in before we fixed it?" Attackers may already be inside in the time between a weakness being announced and the fix being applied.

Item 2: Count the entrances visible from outside, and reduce them (pages 3 to 4)

The second item is about the attack surface, meaning the entrances visible from outside.

The document says that in some cases of leaks through unauthorized access, the cause was that functions or services not needed for the business were visible from outside. Specifically, there are cases where intruders got into the admin screen of a system exposed to the internet through guessable passwords, brute-force attacks, or bypasses that exploit weaknesses in authentication. It also confirms cases where debugging functions and system management interfaces that were never meant to be public could be reached from the internet¹.

A debugging function is a back door built during development so that you can look inside to investigate problems. It is convenient while you build. If you forget to close it at release, it becomes a kitchen door that anyone can enter from outside.

What the document stresses here is that an entrance you do not need gives attackers a new route in and a new chance to steal data. One more back door means one more place to guard. The fewer the entrances, the easier to defend. That is as true of buildings as of systems.

There are three example measures for staff.

Example 1: List your entrances. From network configuration information, cloud settings and asset registers, identify the IP addresses, domain names, services, communication ports, web applications and APIs you expose to the internet. Then use ASM (attack surface management) tools to find assets observable from outside the company, and compare them against your internal registers. ASM is easiest to understand as looking at your company from outside and counting, "so there was a back door like this." The Ministry of Economy, Trade and Industry has issued introductory guidance⁶. Comparing the two turns up assets missing from the register and things that were exposed unintentionally. For whatever you find, confirm the person responsible, the purpose and whether it needs to be public, and keep managing it.

Example 2: Stop public functions you do not need. On the application side, check whether admin screens, debugging interfaces, development and test environments, and database management functions can be reached from outside. In particular, check how the routing settings respond to paths you did not anticipate. The aim is to verify that functions that should not be public cannot be reached from outside. Functions you do not need are stopped or disabled, and those needed for management are protected by combining restrictions on where access can come from with multi-factor authentication.

Multi-factor authentication asks for a second kind of proof in addition to the password, such as a confirmation code on a smartphone. It is like needing a PIN as well as a key, so that a leaked password does not let someone in right away.

On the network and cloud side, check how widely things are exposed to the internet and how access is restricted. This covers the public settings of cloud storage (where data is kept), whether a firewall is letting through traffic it should not, and whether a web server is publishing files unintentionally. When you find a configuration flaw, fix it by removing public access or revisiting permissions, and then confirm from outside that it is really closed.

Example 3: Keep watching how your systems look from outside. When you build a new system, change it, or change its settings, new entrances or unintended exposure can appear. So the check does not end after one round. You continue it, comparing against past results and registers, detecting assets you did not know about and changes in exposure, and fixing what you find quickly.

Item 3: Keep checking and watching, with AI too (pages 4 to 6)

The third item is the watch kept after a system is built and released.

The document confirms that it has long been seen as important not only to take measures when building, but also to keep running diagnosis and checks once operation begins, find weaknesses and configuration flaws, notice suspicious activity by monitoring logs, and find signs of intrusion early enough to respond. It then voices concern that AI is being used in attacks and that attacks will become more sophisticated and efficient.

This is the newest point in the document. Alongside continuing and strengthening existing measures, it says that if attackers use AI, defenders should actively consider using AI as well. This comes with a condition: introduce it while thoroughly verifying its effectiveness, the scope of its application and its operational risks.

There is another point about how often to diagnose. The document says to keep carrying out diagnosis, checks and audits according to risk, not only before a website or mobile app goes public, but also at important changes involving authentication and authorization, APIs and the handling of personal information, and after operation begins, then to fix what is found and confirm the result. It is a warning against the habit of diagnosing once before release and calling it done.

There are three example measures for staff.

Example 1: Continuous diagnosis and checks. Run regular vulnerability diagnosis and penetration tests (tests that try to break in as a real attacker would) on web applications, APIs, network equipment and cloud environments, and diagnose again at important changes. Consider also using AI-based diagnostic tools. They are said to improve efficiency in exploring attack paths, creating tests, confirming weaknesses, analyzing impact and helping prioritize responses. The document states explicitly, though, that the grounds and validity of the AI's evaluations must be confirmed and that people make the final decision on how to respond.

Example 2: Continuously monitor logs and behavior. Collect logs from web servers, API entry points, authentication platforms and cloud services, and build a setup to monitor them. Three abbreviations appear here. A SOC (security operations center) is a monitoring base or organization, the equivalent of a security room. A SIEM is a mechanism that gathers logs from many places and cross-checks them, like a guard's monitor that shows security camera footage together. EDR is software that watches for suspicious behavior inside PCs and servers. With these, you continuously watch for suspicious authentication, improper use of privileges and large data retrieval. The document also says to actively consider using AI to analyze large volumes of logs and alerts across sources, detect signs of anomaly, link related events and rank what to investigate first.

Example 3: Speed up investigation and first response. When you find suspicious activity or signs of intrusion, build a setup that can quickly examine the related logs and system state and confirm whether there was unauthorized access and how far it reached. SOAR is a mechanism that automates investigation and response procedures, like teaching a system the guard's first-response manual. Having AI summarize alerts, collect and analyze related information and suggest response steps is also open for consideration. Here too, the document says to do it with appropriate verification and human oversight, with thought for the effect that false alarms or misjudgments could have on the business.

What the three share is an attitude: AI helps the person in charge, but the final decision is not handed over to it. I think that is reasonable. If an AI misjudgment stops a system that must not stop, the loss falls on the business.

Pillar 2: Build it safe from the start in design and development

The second pillar is about the stage when a system is built. The document observes that, given recent trends in cyberattacks, mobile apps, web clients and the servers behind them are often not designed with safe construction in mind.

Item 1: Security by design (pages 6 to 7)

"Security by design" means building something safe from the start, not defending it afterward. In terms of a building, it is putting emergency exits and fire walls into the blueprint, not adding them after completion.

The document says that if a weakness or configuration flaw is found after release, the cost of fixing it later increases greatly compared with preventing it at the design stage. It adds that it could also lead to a serious incident or information leak. For that reason, it asks for security to be built into every phase, from deciding requirements through operation⁷.

There are three example measures for staff.

Example 1: Think about safe construction at the requirements and design stage. The document names "threat modeling." It is the work of identifying, at the design stage, who could attack this system and how, and which entrances would be targeted. On that basis, you decide security requirements such as authentication and authorization, encryption, logging and access control. It also asks you to think from the design stage about a network layout that does not carelessly expose management and operations functions to the internet, and about access control based on "zero trust." Zero trust means dropping the idea of trusting someone because they are inside the company, and checking every time anyone accesses anything.

It also says to consider separating the application, the database and the operations management functions not only on the network but, depending on the system's importance and risk, along the boundaries of management, such as separate cloud accounts. The idea is that if one part is broken, the damage does not reach everything.

Design standards should include "non-functional requirements." These are the requirements that do not show up in specifications for screens and features: authentication, availability (not going down), logging, monitoring, response to failures, backups and data protection. When the builder and the client are not aligned on these, you easily end up with a system whose features work but whose defenses are empty. So the document asks you to make clear the items to confirm at each stage, from requirements through procurement, development, acceptance and operation.

Example 2: Automated checks at the build stage (SAST and SCA). SAST reads the program's source code without running it and finds dangerous ways of writing. The document says it can continuously reveal the use of dangerous functions, violations of secure coding practice, and known weaknesses in the OSS and libraries you use. SCA is the tool for checking the weaknesses of components, which appeared earlier. Where needed, you also use the SBOM. In cooking terms, this is the inspection of checking, partway through preparation, that no ingredient has gone bad.

Example 3: Automated checks at the testing stage (DAST and IAST). DAST sends requests from outside to an application that is actually running, as an attacker would, to look for weaknesses. IAST checks from the inside while the application is running, interacting with it. Using automated analysis, and manual confirmation where needed, you find flaws such as missing authorization, insufficient input validation and flawed login-state management, and fix them before release. If it suits you, you can build these checks into "CI/CD," the automated pipeline for building and releasing software, so that safety is confirmed continuously throughout development.

Item 2: Strengthen the protection of the APIs you use (pages 7 to 8)

This is arguably the heart of the document. The document says that in some cases of leaks through unauthorized access, the cause was improper operations through the APIs used by web and mobile apps, and it cites the "A2B attack" that NICT warned about¹.

A2B stands for "App-to-Backend," an attack from the app on the server behind it. According to the NICT threat analysis team's alert, the attacker first obtains and analyzes a publicly available app, and learns the connection destinations of the backend servers the app talks to, the API structure and the parameters used in communication. The attacker then builds an attack tailored to each server's configuration and the API specifications, based on what was collected, and goes after the weaknesses. What was actually confirmed was the technique of obtaining and analyzing an Android app published in the Japan region of Google Play².

Let me use a restaurant. What customers use is the menu (the app). A thief studies the menu closely and works out, "the counter that passes orders to the kitchen (the API) is here, and orders are written like this." Then, without using the menu, the thief puts a tampered order straight to the counter and tries to pull out what is in the kitchen and storeroom (personal information).

The key point in the NICT alert is this one. In this kind of attack, even if the app itself has no weakness, flaws such as missing authentication or authorization or insufficient input validation in the backend API can lead to personal information leaks and unauthorized access. And it is difficult to completely prevent a published app from being analyzed. What matters is to build and operate things so that the backend servers stay safe even when the contents of the app and the API specifications become known to the attacker².

NICT lists four kinds of weakness that are mainly being targeted. SSRF is a weakness that makes a server communicate in ways it was not meant to. RCE is a weakness that lets commands sent from outside be executed on the server. SQL injection makes a database execute improper commands through input. IDOR is a weakness that shows another person's information just by rewriting a user's identification number. To put IDOR in terms of a hotel, it is a room key that also opens the next room if you change one digit in its number. These four also come up again in the section on pre-release diagnosis.

We have in fact already seen cases of this kind. On 15 October 2026, Sourcenext announced that unauthorized access to an API that retrieves member information might have led to the leak of up to 22,519,960 records. In our article on the case, we separate what has been disclosed from what is still unknown, and organize how to protect such an API. Whether the cause of that incident was the same technique as in NICT's alert is not something I can confirm at this point. Please read what the Sourcenext case teaches about protecting member information APIs as well.

For API protection, the document says it is important to implement strong authentication and authorization, strict input validation, safe management of credentials, and detection and control of abnormal access. There are three example measures for staff.

Example 1: Remove missing authorization. Authorization is the check of whether this person may do this operation. It is different from authentication (confirming who someone is), and it is the one most often overlooked. Even a user who is logged in as themselves must not be able to see other people's information. The document asks the server side to confirm whether the user has legitimate rights to the functions and data an API request asks for, and to implement access control based on the "principle of least privilege." That principle means giving only the minimum privileges needed for the work. There are two kinds of authorization flaw. "BOLA (broken object level authorization)" and "BFLA (broken function level authorization)." BOLA is the same kind of flaw as the IDOR described earlier, one that lets someone reach other people's data. BFLA is a flaw that lets an ordinary user use functions meant for administrators. OWASP, a worldwide nonprofit organization, lists both among the serious API weaknesses⁸.

Example 2: Manage credentials safely. API keys, access tokens, private keys and database connection details are, in effect, duplicate keys. If they are written directly into source code or into an app, they are stolen when the source code leaks or the app is analyzed. It is like pinning a PIN to a signboard. The document asks that you not write these keys into source code, and that on the server side you manage them with a "secrets manager," a vault for keys. A key is given only the minimum permissions, has a set validity period, and is replaced regularly. In the development process too, set up automated checks (secret scanning) to make sure no key slips in when committing to source code management or in the CI/CD flow.

Example 3: Use API rate limits to prevent misuse. APIs become targets of automated tools that try passwords one after another in brute-force attacks and that harvest information. So when a large number of requests arrives in a short time, you limit what is accepted. It is like numbered tickets at a counter that say how many people are served per minute. Login and password reset in particular are functions that are easily targeted. The document asks for a mechanism that detects anomalies from the success and failure pattern and the access frequency, including distributed access from many IP addresses, and not only from the same IP address or the same account⁹.

Item 3: Diagnose weaknesses before you go public (pages 8 to 9)

The third item is like a preview day before a shop opens. The document says that leaks of information are occurring through attacks that exploit weaknesses such as SQL injection, OS command injection, remote code execution (RCE), server-side request forgery (SSRF) and directory traversal. The names are difficult, but all of them are weaknesses of one kind: tampering with input or requests sent from outside to make a server do something it was never meant to do.

For that reason, web applications and web systems that handle personal information need vulnerability diagnosis or penetration testing before release, so that potential weaknesses are found and fixed in advance. The document says to make clear the purpose and scope of the diagnosis, fix the weaknesses found, confirm the result, and only then go to the production environment.

There are two points that should not be missed. The first is the scope of diagnosis. Not only weaknesses already known in products and platforms but also design and implementation weaknesses specific to the backend functions of web and mobile apps developed by your company or your contractors must be diagnosed and corrected. Inspecting off-the-shelf software alone will not find the weaknesses of what you built yourselves. The second is that the technical verification items for a web application should be scoped according to the characteristics and risks of the target system. Rather than doing every item uniformly, you decide to suit your own system. As an international standard for deciding scope, the reference materials list OWASP's ASVS¹⁰.

There are two example measures for staff.

Example 1: Set a security standard. When you diagnose, decide in advance the level of risk you will accept, and set up operations that use it to judge whether release is permitted. For example, look at the severity of a weakness, how easy it is to exploit and the importance of the system, set a standard, and adopt a policy of not going into production while a risk above a certain level remains. Make clear who is responsible for fixing the results of a diagnosis and by when, and create a mechanism to prevent anything being left unfixed.

This too concerns executives. When the release date is close but weaknesses remain, who decides whether to go public or delay? Without that standard, the field gets caught between delivery dates and security every time. I think setting this standard is a job for management, not for technology.

Example 2: Choose a third-party diagnostic provider properly. When you outsource diagnosis, choose a provider with enough technical skill and a track record, taking into account the characteristics of the target system and the technologies it uses. In particular, check the provider's record, methods and organization in diagnosing web applications, APIs and mobile apps. The document also lists choosing a provider whose services conform to the "Information Security Service Standards." A provider recognized as meeting this standard is entered in the "Information Security Service Registry" under the review and registration scheme. The point that you should also check whether the provider does manual verification and diagnosis that considers business logic, not only automated diagnosis, is an important one. Holes specific to a company's operations, such as "points can be fraudulently increased," are hard to find with automated checks.

Pillar 3: Prepare for compromise through the supply chain

The third pillar is about what lies outside your company. It is especially important for businesses that outsource the development and maintenance of their websites and apps.

Item 1: Govern contractors and secure connection paths (pages 9 to 10)

The document says there are confirmed cases in which intruders used the environment of an outsourced contractor or maintenance provider as a foothold to get into the client's systems. In particular, it points out that the remote connection environments contractors use can become a way in using legitimate credentials.

Here the document places a weighty sentence. Even in such cases, the impact of a service outage or information leak falls on the client business itself. Even if a contractor was the entrance for the unauthorized access, from the customer's point of view it is the client company that caused the harm. You cannot settle it by moving responsibility to the contractor.

Legally too, when handling of personal information is entrusted to another party, Article 25 of the Act on the Protection of Personal Information requires necessary and appropriate supervision of that party¹¹. The document treats the entire supply chain including contractors as a target of management and control, and asks you to design measures as a pair: governance over contractors, and layered defense of connection paths.

At the same time, the document also turns its attention to the ordering side. When asking a contractor to take measures, it says to discuss the cost burden and the method of implementation thoroughly, and to take care not to impose the burden one-sidedly by using a stronger position in the transaction¹². If you only say "do it," the contractor cannot find the money, and the measures end up for show. Talking through even who pays is a condition for measures that work.

There are three example measures for staff.

Example 1: Protect the connection paths and accounts contractors use. Identify the connection paths contractors use, such as VPNs, remote desktops and maintenance lines, and apply multi-factor authentication. The document is realistic here. Switch over in stages, starting with the most important paths. For paths where multi-factor authentication is difficult, take substitute measures such as restricting source IP addresses, opening the connection only while work is under way, and keeping work records. Then take stock of accounts for contractors whose work has ended and of administrator privileges left permanently granted, and disable them or reduce them to the minimum.

Example 2: Make security requirements clear in contracts and procurement. Include in specifications for orders and in outsourcing contracts, in addition to confidentiality obligations, requirements such as the procedure for subcontracting, the duty to notify and the contact point when an incident occurs, and deletion of data when the contract ends. When selecting contractors, use objective evaluations such as third-party certification and the Ministry of Economy, Trade and Industry's "Security Measures Evaluation Scheme for Strengthening the Supply Chain (the SCS evaluation scheme)."

The SCS evaluation scheme shows the level of a business partner's security measures in a unified rating of stars. According to IPA, Star 3 is a method in which experts review a self-assessment, with a validity period of one year. Star 4 is a third-party evaluation with an on-site audit and technical verification by an evaluation body, with a validity period of three years. Star 5 is under consideration. Applications for registration are scheduled to open in March 2027. Obtaining a star is voluntary, and whether to make it a condition of business is for the parties to decide¹³. The scheme has not yet started, so it is not something you can use today, but it may become a common yardstick for choosing business partners.

Example 3: Control access with a zero trust way of thinking. Move away from relying only on perimeter-style VPNs where "once connected, you can reach a wide area of the internal network." Limit each contractor worker so that they can communicate only with the servers and functions they need, from approved devices. Think of an employee badge that gets you into the building, while each room still needs separate permission. IPA has published a guide to introducing zero trust¹⁴.

Item 2: Do not use open source and external libraries without knowing what is in them (pages 10 to 11)

In system development, using OSS and external libraries is unavoidable. At the same time, the document says that when a serious weakness is announced, attackers may search for it and exploit it within a short time. So continuing to use external components without knowing what is inside them has to be avoided. What this item asks is that you make components visible and build a setup that can respond quickly.

There are two example measures for staff.

Example 1: Decide in advance the first-response steps for when a serious weakness is announced. What the document has in mind is the situation where urgent action is needed: an alert about a weakness for which no fix has yet been provided (a zero-day vulnerability), or the announcement of a serious weakness. So it asks you to decide in advance steps that allow quick judgment, without leaving everything to the maintenance provider.

Specifically, for your main systems whose development or maintenance is outsourced, keep track in normal times of the OSS versions built into them and their end-of-life (EOL) status. Working with contractors, use public information to check quickly whether your systems are affected. Decide who is responsible for checking the impact, how roles are divided with contractors, and the criteria for reporting to the executive level. And decide the steps for judging interim measures, such as applying a fix, defending with a WAF (web application firewall, a protective wall that blocks improper traffic to a website), or stopping the function concerned.

This "criteria for reporting to the executive level" is an item I would like executives to review themselves. On the day a weakness is announced, what would cause a report to reach the president? If the criteria are vague, information that the field judged "no big deal" stays where it is.

Example 2: Have contractors submit an SBOM for outsourced development, and check it. When you outsource development or modification, set in the contract or specifications that the contractor must state which software components are used and submit an SBOM. At acceptance, compare the submitted SBOM with the design documents and confirm there are no known weaknesses or license violations. After delivery too, build a setup that keeps monitoring newly announced weaknesses with SCA tools and the like. The point is that this does not end at delivery: you also watch for weaknesses that surface after delivery.

The close on page 11, and the reference materials on pages 12 and 13

At the end of page 11 there is a passage that sums up the whole document. After noting that the measures so far focus on the string of recent attack techniques, it says measures need to be taken with other techniques in mind as well: attacks on weaknesses in network devices exposed to the internet such as VPNs, targeted email attacks, and DDoS attacks (attacks that stop a service with a flood of traffic), and further the possibility that the misuse of AI will make such attacks more sophisticated and more cunning.

And it ends this way. Bearing in mind that the impact of a cyberattack can grow into a management risk, the document asks that, under the judgment of top management, a risk assessment be carried out based on the characteristics of the systems being operated and the information held, and that the necessary cybersecurity measures then be strengthened¹.

This ending is the hinge of the whole document. Even with dozens of example measures for staff, it is not saying do all of them. Assessing risk against your own systems and holdings and setting priorities is, it says, the work of top management.

Pages 12 and 13 are a list of reference materials. They include the Ministry of Economy, Trade and Industry's SBOM introductory guide and ASM introductory guidance, IPA's "20 Articles for Safe Website Operation and Management" and "Security Guidelines for Building and Operating E-commerce Sites," its guide to introducing security by design, guidelines from the Digital Agency, NICT's alert, OWASP's top 10 API security risks, guidelines from the Personal Information Protection Commission, and sample rules from IPA's guidelines for small and medium-sized businesses. At the end, the unified standards for cybersecurity measures for government agencies and critical infrastructure are attached as "standards for basic measures." Executives do not need to read all of them, but they give you a shared vocabulary for asking staff and contractors, "are you working from this material?" For small and medium-sized businesses opening one first, IPA's "20 Articles for Safe Website Operation and Management" is probably the easiest entry point¹⁵.

What should executives decide, and what should they ask?

From here on, I organize things in my own way, building on the document. Please note that this is not the government's document itself.

Three things executives decide for themselves

What you should not leave to the person in charge is not the technical detail but these three judgments.

The first is the deadline for fixes. By how many days do you fix a weakness confirmed to be actually exploited? What do you do about a system in hours when it cannot be stopped? If one staff member decides alone, they are carried along by the circumstances of the field.

The second is the standard for what may go public. When diagnosis finds a weakness, at what level do you delay release? Decide in advance which comes first, the release date or safety.

The third is the reporting standard. When a serious weakness is announced, what happens that makes a report reach executives? How many hours after the report do you set up a place to make a judgment?

Ten questions to ask staff and contractors

Please put the following questions to your staff and contractors. Where the answers stall is where your company is weak.

Question	Corresponding item in the document
Do you have a list of the services and admin screens we expose to the internet?	Pillar 1, item 2
Are any unused functions, development environments or test environments reachable from outside?	Pillar 1, item 2
When a weakness is announced, within how many hours can you tell us whether our systems are affected?	Pillar 1, item 1
Are we still using software that is no longer supported?	Pillar 1, item 1
Do admin screens and cloud management functions have multi-factor authentication?	Pillar 1, item 2, and Pillar 3, item 1
Are logs being collected, and who would notice suspicious activity?	Pillar 1, item 3
Have you confirmed that the APIs behind our apps do not let a user reach other people's data?	Pillar 2, item 2
Does the diagnosis before release also cover the parts we built ourselves?	Pillar 2, item 3
Do contractors' connection paths have multi-factor authentication? Do you delete accounts once the work is done?	Pillar 3, item 1
For outsourced development, do you have contractors deliver the list of components used (the SBOM)?	Pillar 3, item 2

Where a small company should start

The document asks you to set priorities based on risk. Beyond that, for small and medium-sized businesses with limited people and budget, I will write down the order I recommend. This is not the order the document gives. It is my own view.

The first thing to do is to count the entrances. Write down the sites, apps, admin screens and cloud storage locations your company exposes to the outside. It costs nothing, and you can often find out by asking a contractor. Only by counting do you find out, "we were exposing this?"

Next, close the entrances you do not need. Admin screens you no longer use, old test environments and pages from past campaigns can be stopped the day you find them. If you worry that stopping one might cause trouble, simply making it invisible from outside is already effective.

Third is adding multi-factor authentication to management functions. Admin screens, cloud administrator accounts and contractors' remote connections come first. If these are broken, the damage spreads at once.

After that, set deadlines for fixes, and have contractors answer in writing about their connection paths and API authorization. For the measures that cost money, such as diagnosis and monitoring, decide where to apply them after seeing the results of this inventory, and you avoid waste.

If you are not sure where your company stands, one way is to start with an entry point that gauges understanding inside the company, like the AI literacy check. For how to act when an incident really happens, see our article on first response to cyber incidents. For preparation on PCs and endpoints, see the checklist for small and medium-sized businesses. And for the operations that prepare you for the day a weakness is announced, we set out the specifics in our article on the critical PHP vulnerability.

Closing

What struck me most reading this document was not the novelty of its content but how hard it is to keep doing the obvious things as a matter of course. Count what you own. Close the entrances you do not need. Fix what must be fixed. Do not leave it all to contractors. Everyone nods when they hear these measures.

And still incidents continue, I think, because these are not things you do once and finish. They have to be redone whenever the system changes and whenever people change. Add a feature and the entrances grow. Update a component and the weaknesses grow. Change contractors and the connection paths change. They are also the work that gets pushed back the busier the staff become.

That is why executive involvement is needed, and I take that to be the meaning of the document's last sentence. Deadlines for fixes, the bar for release and the rules for reporting get swept away by the field's busyness when one staff member tries to set them alone. Executives decide, and the field acts. Please check that division of labor this week.

And if you still have time, spend just one hour with your staff counting your company's entrances. I expect you will find something unexpected.

If you are unsure how to set up internal operating rules or how to handle exchanges with contractors, our WARP SECURITY is also an option. It is a training program that spends its time on everyday preparation, such as internal approvals and judgment calls at the moment of discovery, rather than on explaining attack techniques. You can reach us through a consultation request.

References

Footnotes

1. National Cybersecurity Office, Cabinet Secretariat, "Countermeasures Against Unauthorized Access That Leads to Personal Information Leaks: Thorough Basic Measures for Websites and Mobile Apps," 5 November 2026 (for businesses, 13 pages in total; Japanese). Unless otherwise noted, the statements of fact in this article are based on this document. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. National Institute of Information and Communications Technology (NICT), threat analysis team LETTICE, "[Alert] A Run of Information Leaks, and One Cause: 'Server Attacks Following App Analysis'," 13 October 2026 (Japanese). Its reference list cites alerts from the Personal Information Protection Commission (7 October), JPCERT/CC (8 October), the National Cybersecurity Office (9 October) and the Ministry of Internal Affairs and Communications (9 October). PDF (Japanese) ↩ ↩² ↩³

3. Ministry of Economy, Trade and Industry, "Guide to Introducing SBOM (Software Bill of Materials) for Software Management, ver. 2.0," August 2024 (Japanese). Ministry of Economy, Trade and Industry (Japanese) ↩

4. CISA (United States), "Known Exploited Vulnerabilities Catalog." CISA ↩

5. JVN, the vulnerability countermeasure information database run jointly by JPCERT Coordination Center and IPA. JVN (Japanese) ↩

6. Ministry of Economy, Trade and Industry, "ASM (Attack Surface Management) Introductory Guidance: Discovering and Managing Your Organization's IT Assets Using Information Visible from Outside," May 2023 (Japanese). Ministry of Economy, Trade and Industry (Japanese) ↩

7. IPA, "Guide to Introducing Security by Design" (Japanese). IPA (Japanese) ↩

8. OWASP, "API Security Top 10 2023 API1 Broken Object Level Authorization." OWASP ↩

9. OWASP, "API Security Top 10 2023 API4 Unrestricted Resource Consumption." OWASP ↩

10. OWASP, "Application Security Verification Standard (ASVS)." OWASP ↩

11. Personal Information Protection Commission, "Guidelines on the Act on the Protection of Personal Information (General Rules)" (supervision of entrusted parties; Japanese). Personal Information Protection Commission (Japanese) ↩

12. Ministry of Economy, Trade and Industry and Japan Fair Trade Commission, "Toward Building Partnerships with Business Partners to Improve Cybersecurity Across the Whole Supply Chain" (Japanese). Ministry of Economy, Trade and Industry (Japanese) ↩

13. IPA, "SCS Evaluation Scheme: Frequently Asked Questions" (Japanese). The methods and validity periods of Star 3 and Star 4, the start of applications for registration (scheduled for March 2027), and the fact that Star 5 is under consideration all rest on the statements on that page. IPA (Japanese) ↩

14. IPA, "Guide to Introducing Zero Trust: Introducing Zero Trust into Information Systems and Control Systems" (Japanese). IPA (Japanese) ↩

15. IPA, "20 Articles for Safe Website Operation and Management" (Japanese). IPA (Japanese) ↩