JPCERT/CC's Checklist for Incident Investigation Reports: How to Read the Final Reports Japan Is Waiting For

Key takeaways

• JPCERT/CC, Japan's national computer emergency response team, published on November 11 two checklists for incident investigation reports: one for the organization that commissions an investigation, and one for the investigators who write the report, with a 42-page sample report based on a fictional case.
• It says outside investigations have become common as ransomware and data breaches increase, but many victims are handling an incident for the first time and cannot judge whether an investigation is adequate or when the incident is over.
• The checklists ask for things this year's breach notices rarely show: for each system and for any leak, a clear line between confirmed, possible, no trace found and cannot be determined; a cause specific down to the product version and CVE number; and fixes tied to what was actually found.
• Several of this autumn's largest breaches, including Yumil Link and Blastmail, have promised final reports once their outside investigators finish. The checklists are a good guide to what those reports should contain, and to what a public summary of them leaves out.

What JPCERT/CC published#

The material is on GitHub Pages in HTML and Markdown, under a Creative Commons license that allows reuse:

• Checklist for organizations commissioning an investigation: what to agree with the investigation company before work starts, and the minimum to check in the report you receive
• Checklist for report writers: from the first interview with the victim, through evidence preservation, to the report and its annexes, with each item marked required, recommended or optional
• A sample report: a 42-page final report on a fictional intrusion through a VPN device, showing how each item looks in practice

JPCERT/CC is clear about the limits. The checklists cover the minimum. They cannot confirm that an investigation or a report is technically right; for that, it suggests asking experts, including JPCERT/CC itself.

Before the investigation starts#

Most of the advice for victims is about agreeing things in advance, in writing:

• What the investigation is for. Recovery decisions, preventing a repeat, management decisions, legal action, explanations to customers and partners, public disclosure. The report's purpose shapes what it must contain.
• What comes first. Finding the way in, the scope, whether data left, containment or recovery. The checklist is frank that restoring systems quickly can destroy evidence, and that investigating first can delay recovery. That is a choice the organization should make knowingly.
• What may never be known. The way in and whether data leaked may not be determinable for lack of evidence. The investigator should say in advance which logs, systems or periods are missing and how that limits the result.
• When to hear more. Besides scheduled updates, ask for an immediate report if a new compromised system is found, if the assessment of a leak changes, or if containment turns out to be insufficient.
• Who will see the report. Regulators, the police, insurers, business partners or a parent company. Agree on that before it is written.

What a good report says#

The review items for victims, and the much longer list for writers, come down to a few demands:

The report should	In the checklist's terms
State for each system whether compromise was confirmed, no trace was found, or it cannot be determined	And show the logs or files behind each judgment
State for data whether a leak was confirmed, is possible, left no trace, or cannot be determined	And what was examined, even when nothing was found
Name the way in specifically	Systems, accounts and vulnerabilities down to CVE numbers and product versions; if it is an inference, say so and why
Explain what could not be determined	Missing logs, encryption, deleted files, systems outside the scope
Not assert what the evidence does not show	Inferences and hypotheses marked as such
Tie every fix to a finding	"Not only general recommendations", with priorities
Give indicators (IoCs) in a usable form	Separate text or spreadsheet files that can go straight into monitoring
Support any attacker name	With the basis, the source and a level of confidence

The sample report shows how careful this can be. In one example, attackers listed a file server's contents, the name of an archive file remains but the file itself is gone, a file transfer tool was run, and about 176 MB went to an outside address that night, encrypted. The report does not say data was stolen. It says that, taken together, these show a possibility of exfiltration, and lists exactly what it saw. Elsewhere, it warns that an outdated VPN firmware and an admin screen reachable from the internet are reasons to consider that a flaw was exploited, but not proof that it was.

Reading this year's notices with the checklist#

The checklists are about the report an investigator gives its client, not the notice a company posts. But a public notice is usually a summary of that report, and the gaps in this year's notices line up closely with the checklist:

• "May have leaked" covers four different answers. The checklist separates a confirmed leak, a possible one, no trace and no way to tell. Japanese notices almost always say only that data "may have" leaked, which can mean any of the last three. We discussed the effect in our analysis of 2026's largest breaches.
• Half do not say how the attackers got in. In our analysis, 18 of 37 organizations had not described the way in, and many that did said only "a vulnerability". The checklist expects the report to name the product, the version and the CVE, or to explain why it cannot. A public notice need not publish all of that, but it can say which kind of weakness it was.
• Assessments change, and the checklist expects them to. Yumil Link's count went from about 9 million to 51.63 million and then down to 47.86 million; JR Central and its partners, and the cinema chain Shochiku, were each told at first that their customers were not affected, and later that they were. The checklist asks investigators to report at once when the leak assessment changes. Clients of a vendor should ask for the same.
• Fixes should follow findings. "We will strengthen security" is a general recommendation. Yumil Link's third report is closer to what the checklist asks: it names the shared maintenance account that let attackers spread and removes it, and adds IP restrictions where none were set.
• Missing logs are a finding too. When a report cannot say how attackers got in because logs were not kept, that is itself a result, and the fix is to keep them. The Personal Information Protection Commission's draft security guideline now lists keeping and protecting logs among its examples.

Our view#

Decide what the investigation is for before it starts. The most useful page for a first-time victim is the first one. Restoring quickly and preserving evidence pull in different directions, and the cost of choosing badly appears weeks later, when the report says the way in "could not be determined". That trade-off belongs with management, made on purpose, not by default in the first night's rush to get systems back.

"Cannot be determined" is an honest answer, and notices should use it. The checklist's four-way distinction would make Japanese breach notices far more useful. A company that writes "we confirmed data was taken from these two servers; for this database the logs do not let us tell" tells customers and partners much more than "information may have leaked", and is no less careful.

The final reports are the test. Yumil Link and Blastmail have said they will publish final reports once their outside investigators deliver theirs. In our view, the public versions should follow the checklist's shape, even in summary: the way in, by type at least; what was confirmed, what is possible and what cannot be known; and which fix answers which finding. We will read them against it.

What this means for practitioners#

If you may one day commission an investigation:

• Read the user checklist now, not during an incident, and use it to agree the purpose, priorities, scope and reporting with your incident response provider or retainer.
• Decide in advance who chooses between fast recovery and preserving evidence.
• Ask for immediate reports when the scope or the leak assessment changes, and get every agreement in writing.
• Check the report you receive for the four-way distinction, traceable evidence and fixes tied to findings.

If you write the reports:

• Use the reporter checklist and the sample as a baseline, especially the required items: time zone, defanged indicators, no assertions without direct evidence, and a stated reason when the way in cannot be determined.

If you use a vendor that has been breached:

• Ask which of the four answers applies to your data, what was examined, and when the vendor's investigator will report.

Japanese terms at a glance#

Japanese	Reading	Meaning
インシデント調査報告書	inshidento chōsa hōkokusho	Incident investigation report
調査会社	chōsa gaisha	Investigation company
証拠保全	shōko hozen	Evidence preservation
初期侵入	shoki shinnyū	Initial access
横展開	yoko tenkai	Lateral movement
判断できない	handan dekinai	Cannot be determined
再発防止策	saihatsu bōshi saku	Measures to prevent recurrence
最終報告	saishū hōkoku	Final report