What happened at IDC Frontier?

At around 3:40 a.m. on 7 October 2026, virtual servers stopped in four zones of IDC Frontier's IDCF Cloud East Japan Region 1. The company, a SoftBank subsidiary, confirmed a ransomware attack the same day and said 495 companies and local governments were affected. On 8 October it said customer data in those four zones was expected to be difficult to retrieve or restore, and that restoration would depend on backups customers held themselves. As of 9 October the intrusion route and whether any data was taken were still under investigation.

Isn't data in the cloud backed up by the provider?

Not in the way most people assume. Providers protect the durability and availability of their own platform. Protecting your data against deletion, corruption, and ransomware, including a ransomware attack on the provider itself, is normally your responsibility under the shared responsibility model. At IDC Frontier, customers whose only backups sat on the same platform as production were in a very different position from those who kept a copy somewhere else.

What is fourth-party risk?

Fourth-party risk is the risk that comes from your suppliers' suppliers: the hosting providers, identity services, email platforms, and subcontractors that a supplier relies on to deliver its service to you. You have no contract with them and often don't know who they are, but their failure reaches you anyway. Several of the organisations disrupted by the IDC Frontier attack, including JR East, were not IDC Frontier customers. They were customers of a company that was.

Does a supplier's ISO 27001 certificate mean we don't need to assess them?

No. An accredited ISO 27001 certificate is valuable independent evidence that a supplier runs a functioning information security management system, and it's reasonable to rely on it. It doesn't tell you whether the certification scope covers the service you actually buy, what data of yours they hold, how their backups are separated from production, who their subprocessors are, or how you would recover if the service disappeared. Certification demonstrates assurance. It doesn't replace understanding your own exposure.

How often should we review our suppliers?

It depends on the risk the supplier creates. Critical suppliers usually justify a review at least once a year, lower-risk suppliers every two or three years or only at renewal. A calendar alone isn't enough, though. A supplier should also be reassessed when something material changes: a security incident, a lapsed certification, a change of ownership, a move to a new hosting provider, a major subprocessor change, wider access privileges, or new categories of information being processed.

Your supplier gets hacked. What happens to your business?

At about 3:40 a.m. on Wednesday 7 October 2026, virtual servers started stopping in part of IDCF Cloud, the public cloud run by IDC Frontier, a SoftBank subsidiary in Japan. By that evening the company had confirmed the cause as a ransomware attack and put the number of affected customers at 495 companies and local governments. The next day came the sentence no cloud customer wants to read. In its third notice , IDC Frontier said customer data stored in the four affected zones was expected to be difficult to retrieve or restore, that in its current assessment data could only be restored from backups customers held themselves, and that customers should prepare a separate environment and rebuild there.

The effects spread well past those 495 contracts. Nissui’s logistics subsidiary stopped inbound and outbound shipping at 17 cold-chain sites used by about 1,200 companies. JR East disclosed that up to about two million email addresses from its online booking and membership services may have been exposed, not because it was an IDC Frontier customer, but because an email delivery provider it used was. As of 9 October, IDC Frontier was still investigating how the attackers got in and whether any data left the environment.

This is a developing incident and the details will change. The question it raises won’t. If one of your critical suppliers disappeared tomorrow, what would happen to your business and your data?

Key takeaways

A single ransomware attack on one cloud provider left 495 customers without their systems, and the provider’s own guidance was to rebuild elsewhere from backups the customers held themselves. Those without an independent copy had nothing to rebuild from.
Supplier risk is much wider than a data breach. Availability, integrity, permanent data loss, privileged access, lock-in, and the supplier’s ability to tell you what happened afterwards all matter as much as confidentiality.
You can’t assess a supplier properly until you know what information they hold, how you’ve classified it, and what they can access. Start with the information, not the questionnaire.
Your supplier register tells you who you buy from. It doesn’t necessarily tell you who your business depends on. Several organisations hit by this incident had no contract with IDC Frontier at all.
Assurance should be proportionate to risk: tier suppliers, review the critical ones more often, and reassess any supplier when something material changes rather than waiting for the calendar.
ISO 27001 certification is useful independent evidence. It isn’t a substitute for understanding what a supplier’s failure would mean for you.

Same incident, very different outcomes

What makes the IDC Frontier case instructive is how differently its customers came out of the same event, based on decisions they had made long before 7 October.

Six Apart, which runs the hosted version of the Movable Type publishing platform, had off-site backups taken at 1:00 a.m. that morning, less than three hours before the outage began. It moved all 31 of its servers to a different cloud provider and had them running by 9 p.m. the following day. Soliton Systems, by contrast, told customers that the backup server for its SecureDesktop service was managed on the same platform as production and was unavailable too, leaving it to rebuild the service on a different platform with no restoration time to offer. Somewhere in between, an inventory management service called Rakuraku Zaiko came back on 9 October on another cloud, restored from a backup dated 30 August: recovered, but with more than five weeks of data to account for.

None of these companies chose to be attacked, and none of them could have prevented it. What they controlled was where their backups lived, how recent they were, and whether they could stand the service up somewhere else. You can outsource a service, but you can’t outsource the consequences when that service fails.

Start with the information

Most supplier assessments begin with the supplier: a questionnaire, a certificate, a contract review. The more useful starting point is your own side of the relationship. For every significant supplier, you should be able to answer a short set of questions without going looking:

What information do they hold on our behalf?
Have we classified it? Is it personal, confidential, commercially sensitive, or business-critical?
Where is it stored, and who else can access it?
How long is it retained, and what happens to it when the contract ends?
What systems or privileges of ours can they reach?

This is ordinary asset management and information classification applied outside your own walls, and it’s the step most often skipped. A supplier holding last year’s marketing brochures and a supplier holding your payroll file can look identical in a procurement system. You can’t properly assess supplier risk until you understand the value of what you’ve entrusted to them.

Supplier risk is wider than a data breach

When people say “supplier risk” they usually mean a supplier leaking their data. That’s one risk of several, and for many organisations it isn’t the one that would hurt most.

Confidentiality. Information you entrusted to the supplier is exposed or stolen.
Integrity. Information is altered or corrupted, and you can no longer rely on it.
Availability. Ransomware, an outage, or a business failure takes a service you depend on offline.
Permanent data loss. Production and backups are affected together, which is exactly what IDC Frontier’s customers were told to plan for.
Privileged access. A managed service provider, developer, or support contractor with privileged access becomes the attacker’s route into your environment.
Software supply chain. Legitimate software, updates, or dependencies arrive already compromised.
Fourth parties. Your supplier depends on other suppliers you may never have heard of, which is fourth-party risk .
Concentration. Several of your important services turn out to rest on the same cloud, identity, or technology provider, known as concentration risk .
Privacy and regulation. Personal data is processed in ways that breach the law or your contract, and as controller you remain answerable for it.
Exit and lock-in. You can’t readily get your information back or move to an alternative.
Forensics. After an incident, the supplier can’t produce enough evidence to establish what happened to your data.

A supplier that scores well on confidentiality can still be your largest availability risk. Looking at each supplier across the whole list, rather than only asking “could they leak our data”, is what turns a questionnaire exercise into a risk assessment.

Not every supplier deserves the same scrutiny

Applying the same due diligence to the office plant service and the payroll provider wastes effort on one and under-examines the other. Suppliers should be categorised by the risk they create: the sensitivity of the information they hold, whether they have privileged or system access, how critical and how replaceable the service is, whether they process personal data, how heavily they rely on subcontractors, and what a failure would cost the business.

A simple four-tier model is enough for most organisations:

Tier	Typical suppliers	Typical review
1. Critical	Cloud hosting, managed IT, identity, payroll, core SaaS	At least annually, in depth
2. High	Important SaaS, outsourced developers, HR platforms, data processors	Annually
3. Medium	Limited data or system access	Every two to three years
4. Low	No meaningful access to systems or sensitive information	At onboarding and renewal

The intervals are illustrative. The principle isn’t: supplier assurance should be proportionate to the risk the supplier creates.

Reviews shouldn’t be purely calendar-driven either. A supplier assessed in January can be a different proposition by June. Reassess when something material changes:

a security incident or ransomware attack
a lapsed or withdrawn certification
a change of ownership
a major service change, or a move to a new cloud or hosting provider
a significant subprocessor change
increased access privileges
a significant outage
new categories of information being processed

Scheduled review plus event-driven review. Every organisation that depends on IDC Frontier, directly or otherwise, now has a reason to reassess that had nothing to do with its review calendar.

Your contract stops at the supplier. Your risk doesn’t

A typical SaaS product doesn’t run on its vendor’s own infrastructure. It sits on a cloud host, authenticates through an identity provider, serves content through a CDN, is built on a development platform, sends email through a delivery service, handles tickets in a support platform, and is assembled from open source components. Each of those is a company your organisation depends on and has no contract with.

The IDC Frontier incident shows what that looks like in practice. JR East and its card subsidiary View Card were affected through an external email delivery service. Takashimaya suspended its marketing emails because its delivery contractor used IDCF Cloud. Library users in Sakai lost access to a music service because the company operating it was hosted there. Sapporo’s city website lost its automatic translation. None of these organisations would have found IDC Frontier in their own supplier register.

For critical services, you should know who the important subcontractors are, where the service is actually hosted, and whether the security requirements in your contract are flowed down the chain. Where personal data is involved, GDPR Article 28 already requires your authorisation for sub-processors and the same data protection obligations at each level, which gives you a legitimate reason to ask. Third-party risk management that stops at the first contractual layer leaves most of the chain unexamined.

Concentration is the other half of this. If your CRM, your finance system, and your customer support tool all run on the same underlying cloud region, you have one dependency, not three. We wrote about this after the AWS Middle East strikes in March, and the lesson carries over unchanged: map where your critical services really live before an incident does it for you.

“It’s in the cloud, so it’s backed up”

This assumption has cost more organisations their data than any single piece of malware. Under the shared responsibility model , a provider keeps its platform running; protecting your data against deletion, corruption, and ransomware is generally your job. IDC Frontier’s guidance made the point explicitly, and it went further: customers in zones and regions that weren’t affected at all were also asked to take their own backups.

For any supplier holding information you couldn’t afford to lose, find out whether backups are:

independent of production, on separate infrastructure with separate credentials
protected against ransomware, for example through immutability or offline copies
tested by actually restoring from them
held in another account, platform, or location
available to you if the supplier itself fails

The question that cuts through all of it: if the supplier lost its entire environment tonight, could we recreate our critical information somewhere else? A snapshot on the same platform isn’t an answer to that, for reasons we covered in restore point or backup . And the age of the copy matters as much as its existence. Your RPO is whatever the date on your most recent independent backup says it is.

After the breach: what can your supplier actually tell you?

When a supplier is compromised, your own obligations start running immediately. You may need to notify a regulator, tell customers, and decide whether to revoke credentials or rebuild systems. Every one of those decisions depends on facts only the supplier can establish:

when the access began, and when it was removed
which accounts or identities were involved
what information was accessed, altered, or exported
whether the attacker established persistence
what evidence can be shared with affected customers

Three days into the IDC Frontier incident, the intrusion route and the question of data exfiltration were both still open, and downstream organisations such as JR East could only say that exposure couldn’t be ruled out. That’s not a criticism of an investigation in its first week. It’s an illustration of how long your own customers and regulators may be waiting on someone else’s logs. We looked at this gap in detail in our piece on logging and forensic readiness . The security of your organisation increasingly depends on the investigative capability of organisations you don’t control, so the time to ask what they can produce, and how quickly the contract obliges them to tell you, is before you need it.

Where ISO 27001 fits

ISO 27001 :2022 treats suppliers as a lifecycle rather than a one-off check, across five Annex A controls:

A.5.19, Information security in supplier relationships. Identify and manage the information security risks that come with using suppliers.
A.5.20, Addressing information security within supplier agreements. Put the relevant security obligations into the contract.
A.5.21, Managing information security in the ICT supply chain. Recognise that your supplier depends on a wider technology supply chain, and address it.
A.5.22, Monitoring, review and change management of supplier services. Keep checking throughout the relationship, and manage changes.
A.5.23, Information security for use of cloud services. Cover acquisition, use, management, and exit from cloud services.

Read together, they describe a simple sequence: identify, classify, assess, contract, monitor, reassess, exit. Classification decides how much assurance you need. Assessment decides whether the supplier is acceptable. The contract sets expectations, monitoring checks the supplier remains acceptable, reassessment responds when the risk changes, and exit planning makes sure you can get your information back and move.

There’s a second ISO 27001 story here. Large organisations increasingly ask their suppliers for certification or equivalent assurance, and those suppliers, now carrying the obligation, ask the same of their own hosting providers, developers, and subcontractors. NIS2 and DORA add regulatory weight for the sectors they cover. Security assurance is being pushed progressively deeper into the supply chain, which is healthy, and which is also why so many smaller companies first meet ISO 27001 through a customer’s security questionnaire .

A certificate is valuable evidence that an independent auditor has examined a supplier’s ISMS . It still leaves questions only you can ask:

Does the certification scope actually cover the service we use?
What data of ours do they hold, and where?
How are backups protected and separated from production?
Which subprocessors are involved?
How quickly must incidents be reported to us?
What forensic evidence would be available?
How would we recover if the service disappeared?

Certification can demonstrate assurance, but it doesn’t replace understanding your actual exposure.

Practical questions to ask now

Take your five or ten most critical suppliers and answer these for each:

What information do they hold, and how have we classified it?
What systems or privileges can they access?
How critical is their service, and what would happen if it disappeared for a week?
Which subcontractors and hosting providers do they depend on?
Could we recover our information independently of them?
What independent security assurance do we have, and does it cover the service we actually use?
When did we last reassess them, and has anything material changed since?

If those questions can’t be answered readily, the relationship probably isn’t understood well enough for the level of dependence you have on it.

Closing

Nothing here suggests supplier risk can be eliminated. Every organisation in this story was doing something sensible: using a domestic cloud provider backed by a major telecoms group, or buying a service from someone who did. The difference between a bad two days and an open-ended rebuild came down to things decided quietly, months earlier: where the backups were, how old they were, and whether anyone had asked what would happen if the platform itself was the casualty.

Supplier security isn’t about proving your suppliers will never be breached. It’s about understanding what their failure would mean for your organisation, reducing the likelihood and impact of that failure, and making sure the business can continue when a trusted supplier suddenly can’t. That takes demonstrable assurance throughout the supply chain, not simply trust at the first contractual layer.

If you’d like help building a proportionate supplier assurance process, or responding to the assurance requests your own customers are sending you, get in touch . Our ISO 27001 and Risk & Governance services cover the supplier side, and Customer Assurance covers the view from the other end of the questionnaire.