Software security now has a shared-responsibility map.

Where does a vendor's security responsibility end when the customer also operates the system? For a foreign team entering or operating in Japan, that question now has a more concrete answer.

METI and the National Cybersecurity Office published Japanese and English guidelines on March 31, 2026 for providers that develop, supply, or operate software and for their customers. The headline change matters, but it is not the whole operating story. Japan's new guidelines make the handoffs between developer, supplier, operator, and customer more legible without turning the framework into a certification.

The easier response is to assign the development to legal or compliance and wait for a form, policy, or filing date. That approach misses the evidence problem. A rule becomes expensive when the business cannot identify the activity it governs, the data that proves scope, the person who owns a decision, or the moment an exception must be escalated. The useful question is therefore not only "what does the rule say?" It is "which recurring business process must become more observable because of it?"

Start with the boundary, not the headline

The document is guidance, not proof that a product is secure, approved, or compliant with every customer or sector requirement. This distinction protects the article from two familiar errors. The first is overreach: treating a public announcement as proof that every company, product, employee, or transaction is covered. The second is complacency: assuming that a threshold, transition, exception, or future date makes preparation unnecessary.

A boundary memo should be short enough to use. It should state the relevant entity, activity, customer or worker relationship, effective date, scale measure, exception, and unresolved fact. It should also identify who may change those facts. A product manager can change a payment flow. Procurement can change a manufacturing site. Sales can promise a service level. Corporate development can change control rights. A boundary that is not connected to those decisions will go stale while still looking authoritative.

The official source provides the starting point: Guidelines on the Roles Expected of Cyber Infrastructure Providers. It should be read as primary evidence of the framework, not as individualized advice or approval.

The rule is really a handoff problem

The framework organizes expected responsibilities and specific measures into six areas, supported by annexes and evaluation checklists across software supply chains. Each noun in that sentence points to a handoff. Data moves from an operating system into a report. Responsibility moves from a vendor to a customer, or from a frontline worker to a supervisor. Authority moves from a representative to an approved user. Money, goods, information, or rights move across a boundary that the business may previously have treated as informal.

Handoffs are where global templates usually break. A headquarters team may own the policy while the Japan entity owns the facts. A contractor may perform the work while the company retains the duty. A local partner may hold the operational evidence while the foreign brand makes the commercial claim. None of those arrangements is inherently wrong. The weakness appears when each participant assumes another participant is measuring, retaining, or escalating the same thing.

The commercial value is a shared responsibility map that can be reflected in contracts, onboarding, secure defaults, vulnerability handling, update commitments, and end-of-support decisions. This does not require a new enterprise platform on day one. It requires a common record with stable definitions. The record should show what happened, which rule or decision it relates to, who reviewed it, what changed, and when the next review is due. If the business later automates the workflow, the automation should preserve those meanings rather than merely moving fields faster.

Build the control before the deadline

1. Map product lifecycle roles from development through retirement. This is not a documentation exercise performed after the operating decision. It is a way to make the decision testable. Record the source, owner, review date, exception route, and evidence that would show the control is working. Where the answer depends on a regulator, partner, platform, employee, or counterparty, record that dependency instead of converting it into an internal assumption.

2. Identify controls that depend on customer configuration. This is not a documentation exercise performed after the operating decision. It is a way to make the decision testable. Record the source, owner, review date, exception route, and evidence that would show the control is working. Where the answer depends on a regulator, partner, platform, employee, or counterparty, record that dependency instead of converting it into an internal assumption.

3. Attach evidence and response times to contract language. This is not a documentation exercise performed after the operating decision. It is a way to make the decision testable. Record the source, owner, review date, exception route, and evidence that would show the control is working. Where the answer depends on a regulator, partner, platform, employee, or counterparty, record that dependency instead of converting it into an internal assumption.

4. Run a joint vulnerability-and-update tabletop exercise. This is not a documentation exercise performed after the operating decision. It is a way to make the decision testable. Record the source, owner, review date, exception route, and evidence that would show the control is working. Where the answer depends on a regulator, partner, platform, employee, or counterparty, record that dependency instead of converting it into an internal assumption.

These steps deliberately combine legal, operational, commercial, and human questions. A control owned by one function can still fail at the next handoff. Finance may model cost without knowing the product flow. Legal may define a boundary without seeing the interface. Operations may collect data without knowing which exceptions matter. People teams may publish a policy without giving a worker a safe action during a live incident. The design review should therefore use one concrete scenario and ask every owner to show what they would do next.

Counterargument: the existing system may be enough

A detailed matrix can become paperwork if nobody tests the handoffs. The map only works when each obligation has evidence, an owner, and a customer-visible escalation route.

That counterargument deserves more than a ritual paragraph. New compliance work often creates duplicate approval, passive dashboards, and documents that are maintained for inspection rather than decisions. A mature existing system should be reused when it already preserves the required boundary, evidence, ownership, and escalation. The burden is not to create something new. It is to demonstrate that the old system answers the new question.

The opposite mistake is to equate familiarity with adequacy. A long-standing vendor arrangement, payroll rule, certificate process, contract template, or customer-service custom may work under normal conditions and still fail precisely when an exception occurs. The practical test is an evidence walk-through: select one representative case and one adverse case, follow them from initiation to closure, and identify where the record or authority becomes ambiguous.

What remains unknown

The guidelines do not determine the risk tolerance, procurement minimum, architecture, or liability allocation for a particular customer relationship.

Unknown does not mean unknowable. It means the official source establishes a framework while the company must supply entity-level facts. Labeling those facts as unknown prevents estimates from hardening into policy. It also makes the next research or test proportionate. A team may need a Japanese professional opinion, a partner attestation, a system test, a workforce census, a facility audit, a transaction diagram, or a regulator update. Those are different tools for different gaps.

Time is another unknown. Guidance, orders, Q&A, portals, and implementation practice can change after an article is published. The owner should therefore record both the legal or operational effective date and the last date the source was checked. A calendar reminder without an owner is not a control; an owner without a source and scope is only a name in a spreadsheet.

The practical operating decision

Turn the six responsibility areas into a customer-facing control map and test every provider-customer handoff against one realistic incident.

Use that decision as a release gate, not as a slogan. Ask whether the team can show the boundary, the evidence, the owner, the exception path, and the next review. If any element is missing, narrow the launch, add a manual control, obtain the missing advice, or delay the dependent promise. A narrow, observable first version is usually safer than a broad policy that nobody can execute.

The broader lesson is not that Japan requires a special process for everything. It is that a global process becomes credible in Japan when local facts can change the decision. A translated policy that cannot absorb a different role, threshold, customer behavior, authority model, or evidence source is not localized. It is merely legible text around an unchanged assumption.

Source limitation

This analysis relies on Ministry of Economy, Trade and Industry's official material available and checked on 2026-08-12. It is research-based editorial analysis, not legal, tax, investment, employment, security, food-safety, or other professional advice. The document is guidance, not proof that a product is secure, approved, or compliant with every customer or sector requirement. Publication-day verification is required for live dates, scope, transition rules, and later guidance.