What Sakura Internet's Breach Disclosure Teaches Us | Designing for the Day Your Cloud Provider Is Compromised

Hello, this is Ryuta Hamamoto from TIMEWELL. On 19 August 2026, Sakura Internet published a second notice about unauthorized access to its systems¹, alongside a timely disclosure to the exchange. The first notice on 17 August had been about part of its rental server environment. The second one widened the picture to the sales management system that holds contract and billing records, with as many as 1,360,563 member accounts potentially in scope¹.

This article is not an autopsy of the company's mistakes. If anything, detecting an anomaly on 9 August, publishing within eight days, and then revising the scope upward in a follow-up while the investigation was still running is the kind of incident handling I would like to see more often in Japan. Publishing a number that makes your own quarter look worse is not an easy call for a listed company. So the question here is not what Sakura Internet got wrong. It is what every company renting infrastructure can take away from what has been disclosed.

One boundary before we start. The intrusion path, the attacker, and any exploited vulnerability have not been disclosed. I am not going to fill that gap with guesses.

Separating the two incidents on a timeline

Let me lay out the facts as published, and flag clearly where something has not been published.

It starts on 9 August 2026. Sakura Internet detected an anomaly in a server environment it manages and opened an investigation. That investigation found that a third party had reached some Sakura Rental Server customer environments by way of the company's own management environment². As of the first notice on 17 August, unauthorized logins had been confirmed on 583 accounts³⁴. Malware had been placed on some servers, and the attacker had been in a position to access customer information and information covered by the secrecy of communications, specifically data stored in customer server areas and user identifiers². No impact was confirmed on Sakura Cloud, Sakura VPS, Sakura Dedicated Server PHY, or Koukaryoku PHY².

Then the second notice on 19 August changed the shape of the story. Possible unauthorized access to the sales management system holding contract and billing records was confirmed, and the total number of member records potentially in scope was given as 1,360,563¹. According to press coverage, the fields involved include member ID, company name, department, address, name, phone number, email address, date of birth, gender, fax number, contracted services, contract period, and billed amounts⁵. For some customers, access to hashed password data may have occurred. The company does not store credit card data, and no exfiltration of data has been confirmed so far¹.

The detail I would not skip past is the kink in the timeline. Access to the sales management system happened before 9 August, the day the rental server intrusion was detected, and whether the two are connected is still under investigation¹. The first hole you find is not necessarily the first hole that opened. Anyone who has run an incident response will recognise how much work sits behind that sentence. Close out the event you detected, declare victory, and you may leave an older door standing open.

The company says it has revoked credentials, removed malware, tightened monitoring, engaged external forensic specialists, notified affected customers individually, and reported to and shared information with the relevant authorities²¹. Its exchange filing the same day noted that the effect on consolidated results for the fiscal year ending March 2027 is still being assessed. Separating what is confirmed from what is not, and saying so, is the right order of operations.

If you want to check where your own organisation stands on incident readiness with something more concrete than a gut feeling, our AI literacy assessment is one place to start the inventory.

Why it happens: the management plane is the structural weak point

What follows is general. It is not a claim about how this particular intrusion worked, because that has not been published.

A cloud or shared hosting platform has two layers: the surface customers see, and the surface only the provider touches. Call them the data plane and the management plane. The management plane is where the powerful privileges live, the ones that create and stop servers, reissue passwords, and pull backups. It does not take much imagination to see why an attacker prefers it. Compromising customer servers one at a time is slow work compared with reaching the layer that already holds all of them. The economics that make consolidation cheap are the same economics that make a breach expensive.

And when a customer environment is reached through the provider's management plane, whatever hardening the customer did gets bypassed. Longer passwords do not help. A current WordPress does not help. That is not customer negligence, it is the shape of the shared responsibility model. What happens on the far side of the responsibility boundary cannot be stopped from this side. Most companies can recite that. Very few have designed around it.

This is not a rare scenario either. In IPA's Ten Major Security Threats 2026, "attacks targeting supply chains and outsourcing partners" ranked second for the fourth year running, behind ransomware in first for the fourth year running⁶. Attacking a hardened organisation head-on is slower than entering through a provider or a subcontractor it already trusts. For attackers this is settled doctrine. It is our side of the table that still designs as if providers do not get breached.

There is a second problem: asymmetric detection. An intrusion on the provider's platform is nearly invisible to you. Your access logs will not show suspicious activity on a management plane you cannot see. Which is why I think the customer's preparation has to shift from preventing the event to standing back up after it. I made a similar argument in why personal data leaks from GitHub. Same question, different platform: assume the place you put your data is compromised, and ask how far you can walk on your own legs.

Your legal duty does not transfer with your data

This is the part most teams get wrong. The provider published a notice, so surely the customer can just wait. The law does not work that way.

Under Japan's Act on the Protection of Personal Information, a leak of personal data that risks harming individual rights and interests triggers a report to the Personal Information Protection Commission and notification to the affected individuals. Reporting comes in two stages. The preliminary report is due promptly, in practice roughly within three to five days. The final report is due within 30 days, extended to 60 days where the leak may have been carried out for an improper purpose⁷. A leak caused by unauthorized access can be reportable regardless of the number of records.

So what about a company that kept its customer list on a rented server? It turns on whether the relationship counts as entrusting the handling of personal data. Where it does, the processor is released from its own reporting and individual-notification duties once it promptly notifies the entrusting party⁸. Read that the other way around: the reporting duty stays with the entrusting party, meaning you. The provider's public notice and your filing with the Commission are two separate acts.

Where the contract instead states that the provider does not handle the stored personal data, and access is properly controlled, the arrangement falls under what practitioners call the cloud exception, and counts as neither provision nor entrustment. Even then, you remain responsible for managing that handling appropriately as part of your own security control obligations⁹. The Commission issued an advisory in March 2024 on what applies when a cloud provider does qualify as a personal information handling business operator⁹. "Not entrustment" is not "not our problem".

One more thread. The first notice used the phrase "information falling under the secrecy of communications"². Telecommunications carriers must report leaks of the secrecy of communications to the Minister for Internal Affairs and Communications, with a first report promptly after discovery and a detailed report within 30 days of becoming aware of the case¹⁰. If your company has filed as a telecommunications business, and plenty of companies running mail or messaging features have, that obligation can be yours too. Worth checking your filing status once, in calm weather.

The single point of this section: renting is not delegating. The obligations that attach to you as the data controller do not move when the data does.

Rebuilding on the assumption that the provider gets breached

So what do you actually do? Not defence, but the design that lets you stand back up after being caught in someone else's incident. Here is how I would prioritise it.

Priority	What to do	How to check
High	Separate your authentication	Is the provider console password reused anywhere else? Is MFA on for every administrator? Are ex-employees and former vendors still holding accounts?
High	Separate your backups	Do backups live only under the same provider and the same account? Is there at least one generation with a different provider or offline?
High	Inventory what you have deposited	List which services hold personal data, credentials, or confidential material, so you can judge reporting obligations before an incident, not during one
Medium	Separate your keys	Are encryption keys for critical data held solely by the provider? Does the service support customer-managed keys?
Medium	Preserve logs externally	Do audit-relevant logs exist only on the provider's side? What is the retention period, and can you pull them yourself during an incident?
Medium	Review contract clauses	Does the contract set a notification deadline, a scope for disclosing cause information, audit rights, and rules on subcontracting?
Low	Keep an exit path	Can you export data in a portable format? Have you actually done it once in the last year?
Low	Write down your vendor criteria	Do your criteria go beyond "has a certificate" to registration scope, governing law, and jurisdiction?

Think of these eight as the outsourcing and incident-readiness items from METI and IPA's Cybersecurity Management Guidelines Ver 3.0, translated into cloud terms¹¹. A few notes on using the table.

The top three are things you can start this week, and they are the ones that bite in this specific case. Separating authentication gets treated as housekeeping, but with possible access to hashed password data now disclosed¹, any company reusing that password elsewhere should change it today. Hashing means an attacker needs time. Time is not the same thing as safety.

The middle three are design work and will need buy-in. External log preservation is the one I see missed most often. Whether you can determine the scope of a compromise drives both your regulatory filing and what you can tell your own customers. Yet in most companies the logs that would answer those questions exist only on the provider's side. While the provider investigates, you have nothing to say. In my experience it is that silence, rather than the incident itself, that costs you your customers' trust.

Reviewing contract clauses is work that can only be done in peacetime. Contracts without an incident notification deadline are common. Without one, you find out when your vendor decides you find out. Given that you may owe a preliminary report within three to five days⁷, a contract that lets notice arrive two weeks later quietly puts your own compliance at risk. Almost no security training covers this, which is part of why our WARP SECURITY programme spends more time on contracts and design in peacetime than on attack techniques.

If you need high assurance, prefer ISMAP-registered services, but read the scope

This is the part I most want to land.

When you are choosing a provider for a system that handles sensitive information, I would push hard for services registered under ISMAP, formally the Information system Security Management and Assessment Program. ISMAP evaluates cloud services against the security requirements the Japanese government demands and lists the ones that pass. It is jointly governed by NISC, the Digital Agency, the Ministry of Internal Affairs and Communications, and METI, with IPA providing operational support¹². A January 2020 Cybersecurity Strategic Headquarters decision made procurement from the registered list the default for government agencies¹².

I see three reasons a private company should borrow this as a selection standard.

First, the renewal cadence. Registration on the ISMAP cloud service list runs for one year and four months from the day after the end of the audit period it was based on¹². In practice, you re-audit internally and externally every year or you fall off the list. Compared with certifications that can be earned once and quietly aged, that matters.

Second, incident reporting is built into the programme. Registered providers pledge that if a security incident capable of seriously affecting users occurs during the registration period, they will report it to the ISMAP operating committee without delay¹². Whether the world hears about a problem does not rest solely on the provider's own judgement.

Third, the programme has already written down the questions worth asking. Applicants must supply information on capital relationships and officers, on the risk that laws other than Japanese law apply to the information handled, on the governing law and jurisdiction set in the contract, and on the status of third-party testing such as penetration tests and vulnerability assessments¹². Those four make an excellent vendor questionnaire whether or not the vendor is on the list. Import the criteria even when you cannot import the registration.

Now the two caveats, and they are not optional.

The first is that ISMAP registration is not a guarantee of safety. That is not my opinion. The programme overview states that its audit work provides "neither a report of a conclusion nor assurance", and that it "differs in nature from an assurance engagement"¹². Nobody is stamping the service as safe. What is confirmed is that defined procedures were carried out against controls the provider itself declared. Miss that distinction and the list turns into a comfort blanket.

The second is that registration is per service, with an explicit scope. This case makes it concrete. For Sakura Internet, the registered service is Sakura Cloud, and the company's own manual sets out the registered scope down to the zones, the first and second zones of the Tokyo region and of the Ishikari region, plus the covered functions¹³. Rental server is not inside that scope. To be clear, that is not a criticism of the company. A shared hosting product and an IaaS built for government procurement serve different purposes at different prices, so of course the registered scope differs.

The problem is on the reader's side. "That vendor has ISMAP registration, so we are fine" is a claim about a company where only a claim about a service means anything. Within one vendor, some services are in scope and others are not, and within one service, some regions are in scope and others are not. Check the configuration you will actually deploy against the ISMAP cloud service list and the vendor's published scope.

For SaaS used in lower-risk work there is also ISMAP-LIU, which trims the external audit requirements¹⁴. I covered how the two frameworks differ in an introduction to ISMAP, and for how this sits alongside ISO/IEC 27001 there is an introduction to ISMS.

Closing: from designing against incidents to designing through them

The published facts once more. Unauthorized access to part of the rental server environment, unauthorized logins on 583 accounts, and malware on some servers². Possible unauthorized access to the sales management system, with up to 1,360,563 member records potentially in scope¹. No exfiltration confirmed so far, and no credit card data stored¹. The intrusion path and the attacker have not been disclosed, and every structural argument in this article is a general one.

What I take from this is that the centre of gravity has moved from designing against incidents to designing through them. Choose vendors carefully, and use ISMAP as the yardstick when the stakes justify it. Just remember it is a screen, not a guarantee. However carefully you choose, the odds that your provider is compromised never reach zero, and on that day the duty to explain things to your customers stays with you. Where backups sit, where logs are preserved, who holds the keys, when the contract says you get told. Four unglamorous items, and the only ones whose value is decided on the day it happens.

Start with two of them. Check your backups and your log retention this week. If you want to talk through vendor selection criteria, or a security programme that reaches the executive layer rather than stopping at the engineers, get in touch and we can work through your situation together.

References

Facts in this article rest on Sakura Internet's official notices and on primary material from ISMAP and the relevant ministries. Press coverage is cited only as supporting confirmation.

Footnotes

1. Notice Regarding Unauthorized Access to Our Systems (Second Notice) — Sakura Internet Inc. — 19 August 2026 (Japanese) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

2. Unauthorized Access to Part of Our Rental Server Service Environment — Sakura Internet Inc. — 17 August 2026 (Japanese) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. Unauthorized access to Sakura Rental Server, 583 accounts confirmed (press, supporting reference) — INTERNET Watch — 17 August 2026 (Japanese) ↩

4. Unauthorized access to Sakura Rental Server, risk of personal data exposure (press, supporting reference) — ITmedia NEWS — 17 August 2026 (Japanese) ↩

5. Sakura Internet: up to 1.36 million accounts potentially affected (press, supporting reference) — ASCII.jp — 19 August 2026 (Japanese) ↩

6. Ten Major Security Threats 2026 — Information-technology Promotion Agency, Japan (IPA) ↩

7. Mandatory Reporting of Data Breaches and Notification to Data Subjects — Personal Information Protection Commission ↩ ↩²

8. What to do when personal data leaks at a processor — Personal Information Protection Commission ↩

9. Advisory on Points to Note When a Cloud Service Provider Qualifies as a Personal Information Handling Business Operator — Personal Information Protection Commission — 25 March 2024 ↩ ↩²

10. Reporting of Leaks of the Secrecy of Communications in Telecommunications Business — Ministry of Internal Affairs and Communications ↩

11. Cybersecurity Management Guidelines and Support Tools — Ministry of Economy, Trade and Industry ↩

12. Overview of the Information system Security Management and Assessment Program (ISMAP) — NISC, Digital Agency, MIC, METI — November 2023 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

13. ISMAP (Information system Security Management and Assessment Program) — Sakura Cloud Manual (Japanese) ↩

14. About ISMAP-LIU — NISC, Digital Agency, MIC, METI — 1 April 2025 ↩