August 27, 2026

Incident Readiness as Privacy by Design: The Leading Edge of the European Debate

About the author: Kohei Kurihara, Privacy Expert

[Disclaimer] This article reflects the author's personal views. The author is not a licensed attorney, and this article is not intended as legal advice.

Introduction

As many readers know, Article 25 of the GDPR (General Data Protection Regulation) defines "data protection by design and by default," explicitly requiring organizations to implement technical and other measures in line with the core principles of data protection.

Some articles describe the "by design and by default" concept in Article 25 as drawing on "Privacy by Design," a framework devised in 2009 by Dr. Ann Cavoukian, then Information and Privacy Commissioner of Ontario, Canada. When developing systems with incident response in mind, adopting the Privacy by Design mindset is extremely important.

The 7 foundational principles of Privacy by Design

Privacy by Design consists of seven principles. Even before a system is designed, you check whether development follows a design philosophy aligned with these principles. The seven principles are as follows.

Proactive not reactive; preventative not remedial
Rather than responding after a privacy breach occurs, take measures in advance to prevent privacy breaches from happening.
Privacy as the default setting
Adopt privacy protection as the standard rule and build it in so that data is protected automatically.
Privacy embedded into design
Rather than implementing privacy protection as an add-on, develop with it included as a design element.
Full functionality: positive-sum, not zero-sum
Rather than prioritizing either security or privacy, achieve both at the same time.
End-to-end security: full lifecycle protection
Design security and privacy protection into the entire lifecycle of the information.
Visibility and transparency: keep it open
Design for transparency and understandability so that users and providers can verify each other and build mutual trust.
Respect for user privacy: keep it user-centric
Put users at the center and protect individual interests to the fullest extent.

With these seven principles at its core, this becomes an even more important way of thinking when building trustworthy systems that protect user rights.

Privacy by Design, recommended by regulators across the G7, including Japan

About 17 years have passed since the seven principles of Privacy by Design were devised, and the digital society predicted back then is gradually becoming reality.

Until now, the conversation has centered on compliance and governance focused on meeting legal requirements, and regulators in each country have actively pushed for legal compliance. But as AI gradually becomes commonplace in business, service design and system design are growing in importance alongside compliance.

For services used by minors in particular, numerous statements have been issued calling for the protection of children's personal data. At the G7 Data Protection and Privacy Authorities Roundtable held in Ottawa, Canada, in June 2025, a statement on the handling of children's personal data was issued that "encourages organizations to act as responsible innovators by adopting Privacy by Design practices, regardless of whether they are legally required in a given jurisdiction."

Because children's personal data may be more prone to misuse than other information if leaked, it is recommended that system development follow the principles of Privacy by Design from the service design stage onward.

At the G7 Data Protection and Privacy Authorities Roundtable held in Paris, France, this June, in addition to the Privacy by Design approach encouraged in last year's statement, the authorities also addressed the need to build it into the design of age verification used to determine whether a user is a minor.

Another statement addressed the theme of "internet-connected home devices and protecting children's privacy." Privacy protection is becoming a key theme in product design not only for companies that provide digital services, but also for companies that manufacture hardware.

Designing incident response into the system from the start

So far, I've introduced global trends and developments in international rules.

While the need to address privacy protection from the design stage is easy to understand, many of you may be wondering, from a practical standpoint, why you should adopt the "by design" mindset at all.

One of the main reasons I believe organizations should embrace "by design" is the reporting obligations (incident reports) imposed on companies by regulations in each country.

In recent years, it has become common to see companies leak personal data, and not only through external attacks. When personal data is leaked, companies are expected not just to strengthen internal security and governance, but also to have a system in place to understand the scope of the leak and report on the situation quickly.

This means it is important to approach design from the perspective of the "information lifecycle" defined by Privacy by Design.

Article 33 of the GDPR requires "notification of a personal data breach to the supervisory authority": organizations must notify the competent supervisory authority of a breach, including leaks of personal data, within 72 hours. Within this short 72-hour window, each company is expected to identify the problem that occurred and assemble answers to all the required items before responding.

Looking at actual cases in Europe where organizations were penalized for violating Article 33 of the GDPR, the Enforcement Tracker, a list that compiles penalty cases, shows 101 cases (including those that also involved violations of articles other than Article 33) between the GDPR's entry into force in 2018 and April 30, 2026.

As this shows, when systems are not developed with incident response in mind from the design stage, there are cases where the response to reporting obligations is delayed and ends in fines.

Start by assessing the risks of the personal data your company handles

Many of you may be wondering how, concretely, to put Privacy by Design into practice at your own company. The seven principles of Privacy by Design are somewhat abstract, and there are many parts that practitioners find hard to apply.

So I recommend starting with a DPIA (Data Protection Impact Assessment), as required by Article 35 of the GDPR.

*In Japan, on June 30, 2021, the Personal Information Protection Commission published a document outlining key considerations for PIA (Privacy Impact Assessment), one of the methods for putting Privacy by Design into practice.

A DPIA is a process in which, when the personal data processed under the GDPR falls into a high-risk category, you assess potential risks in advance, compile the results into a report, and keep it on record.

In April of this year, the EDPB (European Data Protection Board), made up of regulators from across Europe, released a DPIA template that sets out the items to be assessed when conducting a DPIA.

The template includes items for assessing whether "data protection by design and by default," as defined in Article 25, has been implemented. Start by using this template to check whether measures that qualify as "by design" are in place.

Following the template, assess whether "by design" measures are in place against the items below.

(The following is an example of a risk assessment of the requirements defined in Article 25, conducted using the template.)

Assessment item	Feature that satisfies it	Justification (assessment)	Implementation status
Minimization of data processing	Remove personal identifiers via named entity recognition before calling an external LLM API	The functional requirements restrict everything except the necessary information	Planned
Minimization of data retention periods	Implement a feature that automatically deletes logs after 30 days	Designed so that, except for data essential to operations, data is not retained longer than necessary	Partially implemented
Implementation of privacy-by-default settings	Settings that allow the model to be retrained are off by default	Unless the default settings are changed, data is not processed for other purposes	Planned
User data control and pseudonymization	Automatically hash IDs so pseudonymization can be achieved across the entire system	Configured so that data cannot be linked across separately managed data servers	Implemented

Assessment item: An item defined in Article 25 of the GDPR

Feature that satisfies it: A feature implemented, or planned for future implementation, to satisfy the item defined in Article 25 of the GDPR

Justification: An explanation of why the implemented or planned feature was assessed as appropriate for satisfying the item

Implementation status: The implementation status of the feature

Referring to the example above, assess risks in advance and fill in the assessment items to determine whether the specifications meet the "by design" requirements set out in Article 25. Also record the current implementation status, and assess the level of potential risk.

For features not yet implemented but under consideration, also document the schedule and plan for implementing them. Filling in each item makes it clear what a particular service or product is missing, enabling the organization to properly assess its risks related to personal data.

Understand where your high-risk data lives

So far, I've shown how to use a risk assessment template to check whether "by design" requirements have been implemented. By organizing the requirements to implement in advance according to risk, you can minimize the impact of risks that may arise after a system goes live.

A page published by the European Commission calls this approach the "risk-based approach." It requires organizations to assess in advance what risks exist when processing personal data in their systems, and to understand the anticipated risks in a transparent way.

Even if an incident occurs and personal data is leaked due to system flaws or vulnerabilities, or misuse is suspected, having taken a risk-based approach lets you detect the risk quickly and report to the relevant regulators even within the limited 72-hour window.

To implement this kind of risk-based approach, what companies need to do is understand what kinds of data they handle and how much data they process.

One method for doing so is "data mapping," and I recommend starting with it. The "Data Mapping Toolkit" published by Japan's Personal Information Protection Commission in October 2022 offers a clear explanation of why data mapping matters and how to introduce it.

In this article, I've introduced the first steps companies should take from a Privacy by Design perspective. Especially for incident response to data leaks, rather than figuring out how to respond after a problem occurs, there is a growing need to anticipate incident risks and conduct risk assessments from the system design stage. I hope this serves as a useful reference as you consider practical measures.

References

About the author
Kohei Kurihara, Privacy Expert

While in university, he worked in a politician's office, and after graduating joined Rakuten. After two years in sales, he started his own company, helping overseas digital services expand into Japan and Japanese services expand abroad. Since 2017, he has served as the Japan representative of the Government Blockchain Association, a US nonprofit.

Later, while involved in founding startups, he spoke on blockchain at international conferences, including those hosted by UNESCO. In 2020, he founded the Privacy by Design Lab, a general incorporated association, where he works on building international forums centered on privacy advocacy. His areas of expertise are data protection (personal information protection), digital marketing, and blockchain. He runs "Privacy Talk," an interview media outlet featuring direct conversations with privacy leaders in Japan and around the world.

arrow_backBack to articles