Response Flow When a Data Breach Occurs

This section outlines the legal and operational challenges that arise immediately after a data breach is discovered, and explains why rapid action is required.

It was a Friday evening when Company B, a web system development contractor, received an external report pointing out a vulnerability in a customer management system. The engineer in charge simply replied "we'll check on that" and postponed the detailed investigation until Monday. Upon investigation Monday morning, it emerged that approximately 3,000 customer personal records may have already been exfiltrated. This delayed judgment later caused serious problems. The contractor explained that they "didn't want to report until confirmation was obtained," but the client interpreted this as an attempt to conceal the incident, and the trust relationship between both parties completely collapsed.

The moment a data breach is discovered, multiple clocks start running simultaneously.

First, there is the legal clock. Under the 2022 amendments to Japan's Act on the Protection of Personal Information, data breaches of a certain scale require both a preliminary report (within approximately 3 to 5 days) and a full report (within 30 days) to the Personal Information Protection Commission. Failure to report can result in orders, recommendations, and in cases of non-compliance, criminal penalties.

Second, there is the social clock: containment work to prevent further damage. Before leaked data can be repurposed or resold, operational containment measures must be taken—changing access controls, requesting deletion of affected data, and similar steps. This is a race against time.

Third, there is the contractual clock. Outsourcing agreements and non-disclosure agreements typically impose notification obligations, often stating that the other party must be notified "promptly upon discovery." Delayed notification can itself constitute a breach of contract.

Whether you are a contractor or a client, the single most important thing to avoid in data breach response is the attitude of "let's wait and see until we have confirmation." Initial breach response requires action even before certainty is established.

This section provides a concrete, step-by-step breakdown of actions to execute within 72 hours of breach discovery, from the perspectives of both contractors and clients.

Phase 1: Within One Hour of Discovery

Beginning Containment

When an incident suggesting a breach is recognized, the first thing to do is "prevent the damage from spreading."

1. Restrict or temporarily suspend access to the affected system or service
2. Invalidate or change credentials, API keys, and connection information associated with the suspected issue
3. Conduct an initial assessment of scope: what data, over what time period, and through what pathway may have been exposed

At this stage, stopping the spread takes priority over fully identifying the root cause. Business impact from a service suspension is typically far less severe than the harm from continued data exposure.

Establishing the First Reporting Line

Report immediately to the internal incident response lead (CISO, information security officer, executive leadership, etc.). Do not handle this alone—bring in a decision-maker early.

For contractors, it is strongly recommended to send a first notification to the client at this stage. Even a message like "Currently investigating. Will provide details within X hours" is sufficient. Notification obligations may already apply even without confirmed evidence, and you should avoid the risk of later being found to have "known but not reported."

Phase 2: Within Six Hours

Evidence Preservation

A common mistake is destroying evidence in the rush to investigate and fix the issue. Access logs, error logs, and system logs must be backed up to a separate medium before they can be overwritten or altered. These are indispensable for later root cause analysis, legal proceedings, and insurance claims.

Identifying the Scope of Impact

Confirm, to the extent possible, "how many records, of what type, and over what time period" were exposed. This figure directly affects whether statutory reporting obligations apply.

Under Japan's Act on the Protection of Personal Information, "sensitive personal information" requiring heightened protection includes race, creed, medical history, criminal history, and disability information. The reporting requirements differ from cases involving only standard information such as names, email addresses, and addresses.

Establishing an External Communication Policy

Determine a unified organizational response policy covering media contacts, social media handling, and methods for notifying customers. If individual staff members release information independently, it creates inconsistencies and invites speculation. In particular, responses to media inquiries should be delegated to public relations or handled at the executive level.

Phase 3: Within 72 Hours

Preparing and Submitting the Initial Legal Report

Determine whether a preliminary report to the Personal Information Protection Commission is required (see the next section for details). If required, submit the preliminary report using the official form, covering what is known at the initial stage. Items listed as "unknown" or "under investigation" are acceptable at this point.

First Contact with Affected Parties

Determine whether notification to the individuals whose personal information was leaked is required, and if so, decide on the content, timing, and method of notification. The notification should clearly state: what happened, the current status of response efforts, and actions the individual should take (such as changing passwords).

This section explains the requirements and process for operator reporting and notification obligations under the amended Act on the Protection of Personal Information (fully enforced in 2022).

Cases That Trigger Reporting Obligations

Under the amended Act, reporting obligations arise when leakage, loss, or damage meeting any of the following conditions occurs (Article 26).

1. Involvement of sensitive personal information: race, creed, medical history, disability, criminal history, etc.
2. Risk of financial harm: credit card numbers, bank account information, etc.
3. Suspected malicious intent: unauthorized access, internal misconduct, etc.
4. More than 1,000 individuals affected: large-scale customer data leaks

Small-scale leaks that do not meet these criteria (such as a mistaken internal email sent to a specific individual) may not trigger statutory reporting obligations, but contractual notification duties may still apply independently.

The Two-Stage Process: Preliminary Report and Full Report

Preliminary Report (within approximately 3 to 5 days)

A preliminary report must be filed with the Personal Information Protection Commission "within approximately 3 to 5 days" of becoming aware of the incident. This report covers "what is known at the time of filing"—it is not required to be complete. The Personal Information Protection Commission's "Leak Report Form" is used for submission.

Full Report (within 30 days; 60 days for unauthorized access)

After the preliminary report, a full report compiling confirmed information must be submitted within 30 days in principle (60 days in cases involving unauthorized access). The full report must include the following.

• Date and time the breach occurred; date and time it was discovered
• Overview of the breach and its cause
• Categories and number of personal records leaked
• Whether secondary harm has occurred or may occur
• Status of individual notification
• Recurrence prevention measures

Timing and Content of Individual Notification

Notification to affected individuals should in principle be made "promptly," but where "notification to the individual is difficult" or "notification may harm the individual's interests," public disclosure (such as posting on a website) may serve as an alternative.

Minimum content to include in notification:

• Factual explanation of what occurred (concise and in plain language)
• Types and scope of personal information leaked
• Actions the individual should take to prevent secondary harm (changing passwords, being alert to suspicious contacts, etc.)
• How to contact you with questions

Notifications consisting solely of apologies with little concrete information are perceived as insincere and invite secondary complaints. Communicating facts concisely and honestly is always the best approach.

This section organizes the legal liabilities and practical roles of contractors and clients when a data breach occurs in the context of contract development or outsourcing.

The "Supervisory Duty Over Contractors" Under Japan's Act on the Protection of Personal Information

Japan's Act on the Protection of Personal Information imposes a supervisory duty on clients (the delegating party) who outsource the handling of personal data to external parties (Article 25). This means that even if a breach occurs due to a contractor's error, the client may be held liable for "failing to appropriately select and supervise the contractor."

Practical examples of fulfilling the client's supervisory duty:

• Confirming the contractor's information security management framework in advance (ISMS certification, Privacy Mark acquisition, etc.)
• Including information security provisions and breach notification obligations in the outsourcing contract
• Conducting periodic security audits or requiring status reports
• Designing the data flow to limit the personal data shared with the contractor to the minimum necessary

Scope of Contractor Liability and Contractual Obligations

When contractors handle personal information, they may qualify as "personal information handling operators" under the Act and bear direct obligations. They are also commonly subject to confidentiality obligations, information security compliance obligations, breach notification duties, and damage compensation obligations under their contracts.

Key points for contractors to keep in mind:

When the notification obligation is triggered: If a contract states "promptly" or "immediately," there is a high likelihood that the obligation to notify the client arises as soon as suspicion emerges—not just when certainty is established. Be aware of the risk that "let's report once we've confirmed it" becomes a contractual breach.

Management of subcontractors: If part of the contracted system development is further subcontracted to another vendor, the contractor generally bears responsibility to the client even if the breach originates with the subcontractor. Subcontractor selection, management, and contracting must also be handled carefully.

Negotiating the scope of damage compensation: Depending on the scale of a breach, compensation claims may far exceed the contracted amount. It is important to proactively negotiate and include a damage compensation cap clause limiting liability to the contracted amount or a defined ceiling.

Collaborative Response Between Parties After a Breach

Once a breach is confirmed, the optimal outcome for both parties is to respond cooperatively rather than adversarially.

Practical areas of collaboration:

• Contractor executes technical containment and root cause investigation, providing ongoing updates
• Client handles reporting to the Personal Information Protection Commission (the client typically serves as the primary point of contact)
• Joint drafting of individual notification text and coordination of delivery methods
• Establishing a unified contact point for public statements and media inquiries

The most common misstep in breach incidents is the contractor delaying notification to the client, followed by the client becoming furious about "why weren't we told sooner." This deepens the conflict and makes cooperative response impossible. Sending the first notification promptly and demonstrating a collaborative stance—"let's handle this together"—serves both trust preservation and damage minimization.

This section organizes the post-incident process of root cause analysis, technical improvements, and contract revisions, through to the completion of post-incident response.

Root Cause Analysis and Fundamental Countermeasures

After the incident has been contained, root cause analysis must not stop at "fixing the found vulnerability." Dig into the background of the surface-level event: "why did this happen?"

Representative root cause categories:

Technical factors: SQL injection, inadequate access control, hardcoded credentials, lack of encryption, insufficient log management. These often arise from technical debt or inadequate review during the development process.

Operational factors: Insufficient review of access rights (accounts of departed employees still active, etc.), inadequate password policies, delayed security updates, absence of regular vulnerability scans.

Contractual and structural factors: Information security requirements not specified in the contract, lack of incident response procedures, insufficient security literacy training for staff.

Prioritizing the Implementation of Recurrence Prevention Measures

Implementing all countermeasures simultaneously is not realistic. To prioritize, evaluate risk by multiplying "scale of harm if exploited" by "likelihood of actual occurrence," and address high-risk items first.

Items to address in the short term (within one month):

• Fixing the vulnerability that directly caused the current breach
• Reviewing access rights and applying the principle of least privilege
• Setting up monitoring and alerts for anomalous logins and large-scale data access

Items to address in the medium term (3–6 months):

• Conducting a security assessment (penetration testing, code review)
• Establishing and practicing an incident response procedure
• Incorporating a security review stage into the development workflow

Ongoing Communication with Customers and Stakeholders

A breach incident does not end with the notification. Ongoing communication about the status of response efforts, completion of recurrence prevention measures, and sincere handling of inquiries is necessary to rebuild trust.

For customer-facing support, establish a dedicated email address or phone number and clearly identify the staff member handling inquiries as proof of good faith. Do not end responses to inquiries with "we'll check with the relevant department and follow up"—actually follow through. Complaints about promised callbacks that never came often cause secondary harm equal to or greater than dissatisfaction with the breach itself.

Post-Incident Contract and Framework Review

Use the incident as an opportunity to revisit existing outsourcing contracts, non-disclosure agreements, and information security policies.

Points to review:

• Explicitly stating notification obligations in the event of a breach (timing, method, recipients)
• Revisiting the ceiling and scope of damage compensation provisions
• Codifying requirements for the contractor's security management framework
• Mandating periodic security reporting and auditing

Even with the best preventive measures in place, zero risk from data breaches is unachievable. What matters equally to "working to prevent it from happening" is establishing an advance agreement on "how to act when it does happen." This reduces risk for both contractors and clients.

---

References

• Personal Information Protection Commission, "Guidelines on the Act on the Protection of Personal Information (General Section)" (2022 Amendment Version). https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
• Personal Information Protection Commission, "Responses When Cases Such as Leakage of Personal Data Occur." https://www.ppc.go.jp/personalinfo/legal/leakAction/
• IPA (Information-technology Promotion Agency, Japan), "Information Security Management Guidelines for Small and Medium-sized Enterprises." https://www.ipa.go.jp/security/guide/sme/about.html