Japan’s Active Cyber Defense Law Goes Live October 1: What “Report Promptly, Detail in 30 Days” Demands From Your SOC

Japan passed its Active Cyber Defense legislation in May 2025. The formal name is the Act on the Prevention of Damage Caused by Unauthorized Acts Against Critical Electronic Computers, and in Japanese it is usually called the サイバー対処能力強化法. The law has been coming into force in stages. On October 1, 2026, its main body takes effect. From that date, designated critical infrastructure operators must report cyber incidents to the government. The government starts sharing its analysis back, and a confidential public–private council starts operating.

Most coverage has focused on the headline powers: government analysis of communications data, and police and Self-Defense Forces "access and neutralization" operations against attacker infrastructure. Those powers matter, but the provisions dated October 1 are the ones that change how private-sector SOCs work day to day.

This post doesn’t try to cover the whole law. It translates the reporting duty into SOC requirements: what the rules expect from detection rules, log pipelines, case records, and the humans who decide when an incident has been "recognized." Then it separates what Simplico’s open-source SOC platform, simpliSOC, ships today from what gets built per engagement.

This is general information, not legal advice. Whether your organization is in scope, and exactly how and when to report, depends on the final ordinances and guidance from the competent ministries.

1. What starts on October 1 and what doesn’t

Date	What takes effect
July 1, 2025	General provisions (Chapter 1)
April 1, 2026	The independent oversight commission for communications data
October 1, 2026	Main body: incident reporting by infrastructure operators, government information sharing, and the council
April 1, 2027 (expected)	First deadline for asset notifications, per PwC Japan’s analysis
By November 22, 2027	Government acquisition and use of communications data (Chapters 3–7); exact date still to be set by ordinance

2. The scope reaches past 257 companies

The directly obligated parties are the critical infrastructure operators designated under Japan’s Economic Security Promotion Act: 257 entities across 15 sectors, including power, gas, telecoms, water, finance, and aviation.

The reporting duty covers what the law calls "specified critical electronic computers." These are systems whose compromise could stop or degrade a critical facility. PwC Japan summarized the draft ordinances this way: besides the critical facilities themselves, the scope is expected to include firewalls and VPN devices at the internet edge, authentication servers, systems and DMZs that control access to critical facilities, and systems that store credentials or other critical data.

That list is almost exactly the first set of log sources most SOCs connect to a SIEM. Firewall, VPN, Active Directory: the systems you already monitor are the core of what must be reported on.

Analysts at PwC and NRI Secure have also pointed out that, depending on system architecture, equipment owned or operated by contractors, group companies, or cloud providers may fall in scope. Separately, the companion amendments add a new duty for IT suppliers under Japan’s Basic Act on Cybersecurity. Suppliers must make efforts to design for, and share information that supports, their customers’ security. The duty is phrased as an obligation to make efforts, not as a mandate with penalties.

In practice, if you run IT or OT for a Japanese infrastructure operator, or you are a Southeast Asian subsidiary or vendor in its supply chain, expect a request like this at some point: "Can you give us the technical details of this incident within 30 days?" Whether a given overseas system is in scope depends on its architecture and on how the operator and its ministry interpret the rules. Being able to answer the request is worth doing either way. It’s the other side of the vendor-access gap we covered in "Your SOC Watches Your Employees. It Doesn’t Watch Your Vendors." (Japanese edition).

3. Translating the reporting duty into SOC requirements

The clock starts at recognition, not occurrence

Deadlines run from when the operator recognizes the incident, meaning when it detects the incident or is notified of it. The incident itself may have happened earlier. That sounds lenient. The flip side is that you cannot report what you never detected. The worst SOC state under this law is not alert overload. It is silent log loss: a firewall that quietly stopped forwarding syslog, or a VPN appliance whose logging was reset during a firmware upgrade. If evidence surfaces later, the question becomes why you didn’t see it.

The event scope is wider than a typical incident definition

The draft ordinances list four reportable categories: malware execution, unauthorized access, service disruption such as DDoS, and the discovery of traces of any of these. For critical facilities, precursor events are also expected to count: receiving malware, attempted unauthorized access, and credential theft. Brute-force attempts against a VPN, password spraying, and connections from known-bad IPs are things many SOCs file as low-severity noise. Some of them may now need a reportability decision.

Two-stage reporting: promptly, then within 30 days

The draft rules call for a prompt initial report after recognition and a detailed report within 30 days. Both go to the minister responsible for the sector and to the Prime Minister. Operators only have to report what they know at the time of each report. Even so, "promptly" is only achievable if you have already decided who declares recognition, and on what criteria, including at 3 a.m. on a Sunday.

The detailed report is technical

The detailed report covers the event’s impact, the systems affected, and the response taken. It also includes technical attack details: method, source and destination for a DDoS, and intrusion vector and ransomware family for a ransomware case. The investigation record should already be the draft report. If you have to reconstruct it from raw logs on day 29, the process has failed.

Penalties are modest in yen but serious in reputation. An operator that fails to report and then ignores a corrective order faces a fine of up to ¥2 million. Failing to provide requested materials carries a fine of up to ¥300,000.

For teams that already operate under the EU’s NIS2 directive, the structure will look familiar. NIS2 requires an early warning within 24 hours, a notification within 72 hours, and a final report within a month. Japan’s draft uses "promptly" plus 30 days. The SOC discipline underneath is the same in both: detect, timestamp, decide, and document as you go.

4. From detection to detailed report

flowchart TD
  A["Log sources FW VPN AD ESXi Sysmon"] --> B["Wazuh detection rules and IOC matching"]
  A --> L["Log-loss monitoring"]
  L --> B
  B --> C["SOC Integrator dedups and opens IRIS alert"]
  C --> D["Analyst triage"]
  D --> E["Does it involve an in-scope system"]
  E -->|"Yes"| F["Record recognition time and decision owner in the case"]
  E -->|"No"| G["Normal incident handling"]
  F --> H["Initial report to sector minister and Prime Minister"]
  H --> I["Investigation IOCs assets timeline evidence in one case"]
  I --> J["Detailed report within 30 days of recognition"]

Two design choices matter most. A human owns the scoping decision (node E). Both reports are generated from the same case record, not written separately from scratch.

5. What simpliSOC ships, what we build per engagement, and what’s out of scope

Shipped (as described on the simpliSOC product page)

Reporting requirement	simpliSOC capability
Detection, which recognition depends on	50+ custom Wazuh rules covering FortiGate firewall, IPS and VPN logs, Windows AD authentication, VMware ESXi, and Sysmon
Traces and precursors	RDP brute force, port scans, password spraying, and privileged-account failures; auto-refreshed IOC feeds (Feodo Tracker, URLhaus, ThreatFox) matched through Wazuh CDB lists
No silent gaps	Log-loss alerting when no events arrive within a set window
Multi-stage attacks	Correlation rules across firewall, VPN, endpoint, and identity
Material for the detailed report	DFIR-IRIS cases holding the summary, notes, assets, IOCs, timeline, tasks, and evidence for each incident
Faster first-pass triage	A local LLM writes a plain-language explanation and a true/false-positive assessment for each alert. It never closes, merges, or suppresses an alert. An analyst makes every call.
Handling confidential information	On-premise or private-cloud deployment; logs and alert content stay inside your network

The last row matters for council members. Information shared in the council is confidential. Misuse or leaks can bring up to two years’ imprisonment or a ¥1 million fine. Before routing that threat intelligence into an overseas SaaS SIEM, it’s worth checking whether that is appropriate.

Built per engagement, not packaged features

• Mapping the ordinance’s event categories to your detection rules and severity levels
• A "recognition" runbook that defines who decides, on what criteria, and what gets recorded
• Export from IRIS case records into draft initial and detailed reports in the ministry’s format
• Extending coverage into OT segments, where many critical facilities sit, with passive network sensors designed for each site
• Preparing for asset notification: Wazuh agent inventory data is a useful starting point, but deciding which systems count as in scope is for the operator and its ministry

Out of scope

Legal determinations of reportability, filing reports on your behalf, and anything on the government side of the law, such as communications-data analysis and neutralization operations.

6. A practical checklist

1. Know your position: are you the operator, a contractor, a group company, or a supplier? If you’re not the operator, check your contracts and reporting obligations with the operator.
2. Confirm that in-scope systems are actually sending logs. Start with firewalls, VPNs, and authentication servers. Then confirm you would notice if they stopped.
3. Revisit low-severity rules. Brute force, spraying, and bad-IP attempts may now need a reportability decision.
4. Name the recognition decision-maker for nights and weekends too, and define what gets written into the case.
5. Rehearse a detailed report. Take a past incident and see whether you can produce method, source and destination, and intrusion path within 30 days.
6. Use one record for all regimes. If an incident also triggers privacy-breach notification under Japan’s APPI, or NIS2 in Europe, build every report from the same case record.

FAQ

We aren’t a designated infrastructure operator. Does this affect us?
Not directly. But if you operate or maintain an operator’s in-scope systems, or your equipment or cloud service is part of that architecture, the operator may ask you for information. IT suppliers also now have a statutory duty to make efforts to support their customers’ security.

How fast is "promptly"?
The draft ordinances we reviewed say "promptly" for the initial report and 30 days for the detailed report. Check the final ordinances and ministry guidance for specifics. Whatever the final wording, you need the decision process in place beforehand.

Does deploying simpliSOC make us compliant?
No tool does that on its own. simpliSOC provides the detection, log-loss monitoring, and case records that reporting depends on. Deciding whether to report, formatting the report, and filing it are the operator’s process. We can help design the runbook and the report export as part of a deployment.

Does the AI decide what gets reported?
No. simpliSOC’s local LLM is limited to explaining alerts and giving a true/false-positive assessment. It never closes or suppresses alerts, and every reporting decision stays with a human.

The bottom line

The reporting duty comes down to three questions. Did you detect it? Can you show when you recognized it? Can you explain the technical facts within 30 days? None of these is a new requirement. They are what a well-run SOC should already be doing. What the law changes is the cost of not doing them.

For background on how we approach detection engineering, see "How to Build a Lightweight SOC Using Wazuh + Open Source." To see what a case record looks like when it’s done well, read "3:47 AM: Inside a Real Incident Caught by an Open-Source SOC Stack." The build history is in "Building a SOC from Scratch."

Talk to us: hello@simplico.net (subject: "Active Cyber Defense readiness")
Phone: (+66) 97 496 6397 · WhatsApp: (+66) 83 001 0222 · LINE: iiitum1984

---

Sources:

• When does the Cyber Response Capability Enhancement Act take effect? — 法改正ナビ (Japanese)
• Impact of Active Cyber Defense on critical infrastructure operators, Part 1 — PwC Japan (Japanese)
• Cyber Response Capability Enhancement Act takes effect in October — Nikkei xTECH (Japanese)
• Cabinet Secretariat — cyber security policy page (Japanese)
• e-Gov law search — Act No. 42 of 2025 (Japanese)
• simpliSOC — Simplico