Part 3 of a series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals.

The first and second parts of this series described a recurring pattern. A company announces that it suffered a cyberattack, as though the identity of the attacker explains the scale of the damage. Public attention then settles on the breached organization while the larger system remains obscure: millions of smaller firms, public bodies, contractors, software suppliers, cloud platforms, and managed-service providers joined through dependencies that few customers can inspect and even fewer can replace quickly.

There is a second reality underneath that system. Poorly administered technology stacks are not peculiar to SMEs. Large organizations also run websites built by agencies that no longer answer, domains registered through accounts nobody checks, deprecated applications that cannot be touched without breaking something else, Excel workbooks that have quietly become operational databases, forgotten servers, shared drives, and remote-access tools installed for a project nobody now owns. Their scale often makes the neglect harder to see. More money, more staff, duplicate processes, and institutional inertia allow them to absorb years of waste and repeated failures without confronting the architecture that produces them.

Smaller organizations face the same control problem with less margin for denial. A ten-person manufacturer does not need the governance machinery of a bank, but it has a greater responsibility to modernize the few systems on which it depends because one failed order process, mailbox, website, or laptop can stop the company rather than become another loss absorbed by a larger balance sheet. A 2024 survey of 4,191 Japanese SMEs by the Information-technology Promotion Agency (IPA), an agency under Japan’s Ministry of Economy, Trade and Industry that publishes national IT security guidance, found that roughly 70 percent lacked an organized security structure and 62.6 percent had made no information-security investment during the previous three fiscal periods. Among companies in the survey that reported unauthorized access, 48 percent said an unpatched vulnerability or similar weakness had been exploited. These results do not show that every SME runs obsolete software, or that larger organizations administer technology well. They show why SMEs cannot safely inherit big-company neglect without big-company buffers.

It is easy to finish the diagnosis with a demand for more security. That would be almost useless. Some organizations already have policies, supplier questionnaires, contracts, passwords, backup services, audit reports, and people nominally responsible for IT. Others have little beyond antivirus software and a vendor’s phone number. In both cases, the issue is the same: can the organization show that the systems doing the work are supported, administered, recoverable, and owned? A policy cannot update an abandoned CMS. A certification cannot recover the registrar account held in a former contractor’s name. A backup subscription cannot restore an application nobody has documented.

Functional control has a stricter meaning. An organization has it when it can identify the systems and people on which an important operation depends, show who has authority over them, produce current evidence that the relevant protections work, detect when those protections fail, limit the resulting damage, restore the operation within an accepted period, and explain who had responsibility for each decision. This standard does not promise perfect prevention. No competent security program can. It distinguishes a managed risk from an unexamined dependency.

The neglected stack is the control problem

The public website is often the clearest example. An organization may regard it as a brochure rather than a system, so nobody budgets for maintenance after launch. The CMS, theme, plugins, PHP runtime, and hosting account keep aging even when the visible pages do not change. The developer may retain the only administrator account. Test pages and old campaign sites remain online. Contact forms continue collecting personal information into a mailbox. IPA’s website-management guidance warns specifically about unmanaged sites left online, unknown software components, overdue version updates, unused accounts, absent logs, and unclear divisions of responsibility with hosting providers. Its 2026 external-attack-surface study of 126 SMEs found exposed administrative panels at 18 companies and email-authentication-record deficiencies at 112. This was a bounded diagnostic sample, not a national prevalence survey, but the weaknesses are concrete rather than hypothetical.

The company domain is even easier to overlook because it works quietly until it does not. Domain registration, DNS, website routing, and email authentication may sit in different accounts, sometimes under the address of an employee or outside vendor who set them up years earlier. A missed renewal can remove the company from the internet. A stolen registrar or DNS account can redirect customers, disrupt email, or help mount a convincing impersonation. Weak SPF, DKIM, or DMARC configuration makes it easier for criminals to impersonate the brand. The Ministry of Internal Affairs and Communications reported that, across JP domains, SPF adoption had reached about 89.6 percent by December 2025 while DMARC adoption remained about 37.2 percent. That is not an SME-specific rate, but it shows how often control stops after the first configuration step. A domain is not a marketing accessory. It is part of the company’s identity and authority system.

Excel deserves a more precise criticism than the usual joke about spreadsheets. Excel is a capable analytical tool. It becomes a control failure when a workbook is also the order system, customer database, inventory ledger, approval workflow, and recovery plan. Copies accumulate in email attachments and local folders. Staff rename files with “final” and a date. Formulas change without review. Access depends on possession of the file rather than a defined role. There may be no reliable answer to which copy is authoritative, who altered a value, whether a departing employee retained it, or how today’s transactions would be reconstructed after a laptop or shared drive failed. The weakness is not the file format. It is asking a document to perform the work of a governed system without identity controls, transaction history, validation, backups, and a named owner.

Fax presents the opposite temptation. Its age and isolation can give it a smaller remote attack surface than an abandoned internet-facing CMS, and that narrow fact can make it feel safer. I do not accept the trade. Fax shifts risk into weak sender authentication, wrong-number disclosure, shared output trays, poor search, manual re-entry, and almost no useful operational audit trail. It also forces every adjoining process back through a person. Japan’s Digital Agency has acknowledged that many Japanese companies, particularly SMEs, still conduct orders and billing by telephone, fax, and paper, limiting data linkage across transactions. A competently administered modern system can provide encrypted transport, strong authentication, structured records, access control, backups, and logs while also removing duplicate work. Security and utility are not opposing choices. The choice is between systems that are administered and systems that are merely familiar.

ANN’s 2020 report, in Japanese, shows how long the government has been asking ministries to drop paper and fax. Video: 河野大臣「脱ハンコ」に続き　紙やFAX廃止を要請へ(2020年11月5日) from ANNnewsCH.

The same pattern appears elsewhere: unsupported PCs kept alive for one line-of-business application, shared mailboxes protected by one password, office routers with unknown firmware, cloud services purchased on an employee’s card, files synchronized into personal accounts, remote-support tools left permanently enabled, and local backups attached to the machine they are meant to protect. None of these requires a sophisticated attacker to become consequential. Large stacks can bury authority inside complexity, while small stacks often concentrate it. In a smaller firm, one mailbox may reset every other account, one laptop may hold the only current order book, and one outside technician may control the website, DNS, email, and backup. Fewer components can mean that each component carries more of the business.

Beige CRT computers and desk phones crowded into a disused office, with mannequin heads seated at the desks
Photographed in 2011. Image via Kevan on Wikimedia Commons (CC BY 2.0).

Begin with the operation, not the policy

Security inventories often become lists of laptops, software licences, and server names. Those lists are useful, but they do not describe the operating chain. A municipality’s website may depend on a communications department, a prime contractor, a web administrator, an email or form service, a cloud account, one hosting region, a domain registrar, a content repository, and several administrator identities. A retailer may depend on a storefront platform, payment provider, order database, warehouse integration, delivery API, customer-support mailbox, and marketing supplier. The service fails when any indispensable link fails, even if the organization does not own that link.

A functional inventory therefore begins with the operation that must continue. It records the systems, data, credentials, suppliers, subcontractors, locations, and management planes required to provide it. It identifies which components can expose personal data, which can change production systems, which can prevent recovery, and which have no practical substitute. It also records the dependencies that are not obvious from the customer-facing product, such as an outside email-delivery system or a subcontractor’s cloud account. IPA’s current guidance for SMEs now includes an asset-register template, a cloud-service guide, an incident-response guide, and backup as one of its basic security measures. These are useful starting points, but an inventory becomes control only when someone keeps it current and uses it to make decisions.

That distinction matters because a spreadsheet can be complete on the day of an audit and false six months later. Services move, contractors change, former employees retain access, new integrations appear, and a supposedly temporary data store becomes permanent. Each important operation needs a named owner with enough authority to reject an unsafe launch, remove obsolete access, require a supplier to remediate a finding, fund recovery work, and accept or refuse the remaining risk. “IT” is not an owner. Neither is a vendor. Ownership belongs to a person in the organization that bears the consequence.

The addition of a Govern function to the Cybersecurity Framework 2.0, published by NIST, the US National Institute of Standards and Technology, reflects this point. The framework places governance alongside Identify, Protect, Detect, Respond, and Recover, and treats cybersecurity as an enterprise risk that senior leaders must manage with financial and reputational risks. A security team can advise, test, and operate controls. It cannot decide by itself how much downtime a public service may tolerate, whether a company can survive the loss of a customer database, or whether the business should keep information that creates liability after its original purpose has ended.

Authority determines the blast radius

Organizations often discuss assets as though data were the only thing attackers want. Administrative authority can be more consequential. One privileged account may change infrastructure, read logs, create new identities, disable defenses, delete backups, or reach several customer environments. A managed provider may hold more practical authority over a customer’s systems than the customer’s own staff. The size of the eventual incident depends in part on what that authority can do after one identity, device, or management interface has been compromised.

Functional control restricts this authority before an incident. Administrative work uses separate named accounts rather than shared credentials. Privileges are limited to the systems and periods for which they are needed. Departed staff and former suppliers lose access promptly. Remote and privileged access requires strong multifactor authentication, preferably a phishing-resistant method where it is available. The current small-business guidance from CISA, the US Cybersecurity and Infrastructure Security Agency, recommends MFA across email, file storage, and remote access, beginning with administrators and people who handle sensitive data. The more important test, however, is not whether the policy says MFA is required. It is whether the organization can produce a current report showing every privileged account, its owner, its authentication method, its last use, and any exception.

Segmentation should impose similar limits on systems. A compromised website should not grant a direct route to backups. One customer environment should not provide reusable credentials for another. A monitoring account should not be able to alter the events it records. A provider’s management plane should not become the only route through which a customer can retrieve its data or recover its service. Joint guidance for managed-service providers and their customers recommends segregated logging, separation of customer environments, least privilege, explicit contractual ownership of security responsibilities, isolated backups, and regularly exercised response and recovery plans. These are not separate products. They are boundaries that determine whether one failure remains local or propagates through the organization and its customers.

Penetration testing belongs inside this model, but its meaning must remain precise. A test has a date, a scope, stated exclusions, an assumed level of access, and a method. It may examine an internet-facing application while excluding the identity system, management plane, backup environment, supplier connection, or lateral movement between internal zones. A competent test can therefore miss the route used in a later incident. The useful evidence is not a certificate saying that a test occurred. It is the scope, tester qualifications, findings, severity, remediation owner, correction date, and retest result. The same principle applies to audits. A report that identifies weaknesses without a tracked path to correction has documented risk, not controlled it.

Keep less, and know why the rest exists

Every retained record creates something to protect, recover, disclose, search, export, and eventually destroy. The operating default in many organizations is accumulation. Data stay because storage is cheap, because nobody owns deletion, because a supplier’s default retention period was never changed, or because the organization imagines that the information may become useful later. The benefit remains vague while the exposure compounds.

Japan’s Personal Information Protection Commission, the national regulator for personal data, states that organizations should delete personal data without delay when it is no longer necessary for its purpose, although the Act does not impose one universal retention period. The Commission has separately warned that proper deletion is important for preventing leaks, that deletion must make the data unrecoverable, and that an organization outsourcing disposal must still supervise the contractor appropriately. Functional control turns those principles into a retention schedule attached to actual systems. It states what is collected, for what purpose, where every copy is held, how long it remains necessary, which legal or operational requirement justifies any longer period, and how deletion is verified across production systems, exports, contractor copies, and backups.

This is especially important for identity documents and other information that a person cannot meaningfully rotate after exposure. A business that needs to verify an identity at one point in time does not automatically need to keep a reusable image of the credential indefinitely. The burden of justification should increase with the permanence and downstream power of the retained information. Encryption and access control reduce the probability of misuse, but deletion removes the future breach object altogether.

A backup is a recovery claim

The incident at IDC Frontier, the Japanese data-centre company that operates IDCF Cloud, provides a blunt test of this distinction. On October 8, the company reported that ransomware-related unauthorized access had stopped virtual servers in four zones of IDCF Cloud’s East Japan Region 1 and placed 495 corporate and municipal customers within the impact scope. It said data in those zones would be difficult to retrieve or restore and that, in its view at that time, restoration was possible only from backups held by customers themselves. The figure does not establish 495 separate intrusions or data theft from every customer. It establishes that one provider-level failure could leave hundreds of customers dependent on whatever recovery capability they had retained outside the failed environment.

NTV’s report, in Japanese, covers the IDC Frontier attack and its effect on 495 local governments and companies. Video: 【サイバー攻撃】狙われた政府“認定”クラウド 495の自治体・企業に影響 from 日テレNEWS.

Calling something a backup does not answer that problem. A copy may share the production account, region, credentials, control plane, network access, encryption keys, or provider. It may be incomplete, corrupted, too old, undocumented, or impossible to restore without software and configuration held inside the failed system. A backup service can report successful jobs every night while the organization remains unable to rebuild the operation that produced the data.

A display of old storage media including a hard-disk platter, tape reels, floppy disks, a data cartridge, and a CD
Generations of storage media on display at the University of Jyväskylä, photographed in 2023. Image via Unnerving duck on Wikimedia Commons (CC0).

CISA advises organizations to keep critical copies separately from primary systems and to perform scheduled recovery tests that verify integrity and refine recovery point and recovery time objectives. Those two objectives force management to make the business decision that ordinary backup language avoids. The recovery point objective states how much recent data the organization can afford to lose. The recovery time objective states how long the operation can remain unavailable. Both need owners, funding, and a technical design capable of meeting them.

The proof is a restoration exercise. A useful test assumes that production credentials and the primary provider environment are unavailable. It restores data, configuration, software, secrets, domain control, and necessary integrations into a clean or alternative environment. It measures the time required, records missing dependencies, verifies the restored service, and assigns every failure for correction. If the exercise can restore a database but not the application that uses it, the operation has not recovered. If only the incumbent supplier can perform the restoration, the customer has continuity assistance but not independent recoverability.

Japan’s Digital Agency makes the same distinction concrete in its local-government cloud migration procedure. Municipalities must prepare backup plans, confirm after migration that backups operate as planned, test disaster-recovery switching where applicable, and make the final determination on migration even when outside specialists support the work. The procedure also says that the municipality itself must verify the result of outsourced migration-completion checks. This is the correct allocation of authority: expertise may be contracted, but acceptance of the result remains with the public body.

Contracts must govern failure, not only normal service

Most technology contracts describe what the supplier provides when the service works. Functional control requires terms for the moment when it does not. The customer needs to know which party monitors which systems, who retains logs, how quickly suspected and confirmed incidents must be reported, what evidence will be preserved, which subcontractors and locations are involved, who can isolate a compromised connection, and how the parties coordinate public and regulatory communication. The contract should state backup responsibilities, tested recovery objectives, data-export formats, termination assistance, and the customer’s right to audit or obtain independent assurance.

A service-level agreement that promises ordinary availability does not resolve these questions. Nor does a clause saying that the supplier follows “industry best practice.” The obligation must be observable. If the supplier claims to test recovery, the customer should be able to obtain the date, scope, result, exceptions, and remediation status. If the supplier relies on another provider, the same evidence should follow the dependency rather than stop at the first contractual boundary. IPA’s current management-practice collection explicitly addresses defining what may be outsourced, securing IT-service controls through contracts and third-party verification, conducting incident exercises, and building coordination across supply chains.

Customers with little bargaining power may not obtain every desired term from a large provider. That does not make the dependency safe. It changes the decision. The customer can reduce the data placed there, keep an independently controlled export, add another communication route, choose a service with stronger contractual commitments, or accept the risk explicitly. Functional control does not require pretending that every risk can be negotiated away. It requires preventing a supplier’s refusal from disappearing into an unsigned assumption.

Municipalities have a higher duty than ordinary customers

A small business may face genuine limits in money, staff, and negotiating leverage. A municipal government occupies a different position. It is a public-data custodian and an essential-service operator with procurement authority, public funding, and a duty to maintain accountable administration. It may use contractors because specialist operation is efficient or necessary. That choice does not move the public obligation into the contractor’s private chain.

The Ministry of Internal Affairs and Communications’ FY2026 local-government guidance sets out policy, standards, procedures, organizational responsibility, asset classification, monitoring, emergency planning, and evaluation. For outsourced systems and cloud services, it says security requirements must be written into procurement specifications and contracts, supplier responsibility must be defined, compliance must be checked, and professional, objective audits should inform improvement. It also identifies contractor-management failure as a threat and says municipalities handling sensitive information must consider security across the full information flow, including the underlying platform.

This means a municipality should know its contractor’s providers and material subcontractors. It should require current assurance appropriate to the system, including qualified and scope-specific security testing, remediation evidence, strong privileged-access controls, incident notification deadlines, preservation of logs and forensic material, independent backup arrangements, tested restoration, and a route to migrate the service. Public communication also needs its own continuity design. If the municipal website is the place residents are told what happened, the emergency notice cannot depend entirely on the same contractor, account, domain path, and infrastructure that have failed.

This is not an argument that every municipality must operate its own data centre or employ every specialist directly. Concentrated platforms can provide capabilities that smaller governments could not reproduce economically. The control test is whether the municipality can inspect the dependency, challenge the evidence, preserve an independent route to continuity, and make the final risk decision in its own name. A procurement file proving that the approved process was followed is not enough if nobody can restore the public service.

Measure evidence, not the number of controls

A mature security report should not lead with the number of policies written, training sessions delivered, alerts generated, questionnaires completed, or products installed. Those are activities. Management needs to know whether important systems are inventoried, whether privileged accounts meet the authentication standard, whether serious findings remain open beyond their deadlines, whether suppliers have provided current evidence, whether logs can support an investigation, whether unnecessary data were deleted, and whether restoration met the agreed objectives.

The evidence should be dated. It should identify exceptions rather than averaging them away. A company with 99 percent MFA coverage may still have left the one administrator account that can change everything outside the policy. A successful annual recovery exercise may say little about a system that changed materially the following week. A certification may support confidence in a management system, but it cannot replace inspection of the architecture, operations, and recovery path relevant to a particular dependency.

Functional control must be proportionate, but proportionate does not mean permissive. A large organization needs to reduce the complexity that lets obsolete systems, duplicate vendors, and ownerless applications survive. A smaller organization does not need to imitate a bank or buy a miniature enterprise security department. It needs to modernize decisively because it cannot fund parallel systems forever or absorb a long interruption. The first stage is administrative recovery: put the domain, DNS, email, hosting, cloud subscriptions, and backup accounts under company-controlled identities; record who owns them; enable strong MFA; remove former staff and vendors; and store recovery credentials so that one person’s absence does not lock out the business. The second stage is maintenance: replace unsupported software, move a neglected brochure site to a supported managed platform where appropriate, define who patches what, and close services that nobody can justify keeping online. The third stage is operational: move work that has outgrown spreadsheets into a system with named users, permissions, validation, history, and usable exports. A fax line can remain temporarily for counterparties that require it, but incoming documents should enter a controlled workflow rather than begin another chain of printing and re-keying.

A small organization can then test the few systems that matter most. It can keep a protected copy outside its main failure domain, restore the customer list or order process on a clean machine, confirm that somebody other than the usual operator can follow the instructions, and agree in advance who calls customers, suppliers, insurers, regulators, and technical responders. This is not a shopping list. A well-administered set of ordinary services is safer and more useful than a pile of security products attached to obsolete operations. The stack can remain small. The claims still need proof.

That is the difference between nominal and functional control. In a large organization, nominal control may mean that a policy exists, a supplier was approved, an audit was completed, and a dashboard is green while the underlying system continues to decay. In a smaller firm, it may mean that the website still loads, the fax still rings, the spreadsheet still opens, and the outside technician can usually fix things. Functional control can show who owns each dependency, which software is supported, who can administer it, where authoritative data reside, which failures have been tested, what remains unresolved, and how the operation will continue when a device, employee, or trusted provider is unavailable.

A cyberattack may still succeed. The attacker is responsible for the attack. The organization remains responsible for the authority it granted, the data it retained, the obsolete systems it kept exposed, the dependencies it accepted, the evidence it demanded, and the recovery it prepared. Victimhood and custodial failure can coexist. The presence of a criminal does not answer whether the resulting damage was unavoidable.

Buying infrastructure is not governing a dependency. The ability to absorb damage is not evidence that the system is sound. Keeping old technology because its limitations feel familiar is not prudence. Outsourcing administration is not outsourcing accountability. Functional control begins when an organization can prove, before the incident, that its actual stack is known, supported, useful, and able to fail without taking the whole operation with it.

For what an outsider can already see about your stack, read the next part, Blood in the water: Japan’s neglected basics are visible from a mile away.

A practical first step is my external exposure check: a fixed-price review of what your domains show the outside world, with a written report within five business days.

This is the work MKUltraman does. A Diagnostics review establishes what the business actually runs and who controls it. The Digital Baseline puts domains, accounts, backups, and recovery under company control. For the asset checklist, read Digital asset ownership: a continuity checklist for Japan SMEs.

Sources