Security Column

Getting Breached Is Not the Disaster, Not Coming Back Is: Resilience and Reporting Speed After Taiwan's September Incidents

Updated: 2026.09.19 07:01
被打進來不可怕,回不來才可怕:從九月台灣三起資安事件,看企業該補的復原力與通報速度

September has been an uneasy month for cybersecurity among Taiwanese companies.

On 8 September, Business Weekly Group announced that its websites and online services had been hit by a malicious attack, taking down Business Weekly Store, its wealth-management site, and its health portal. The group later said recovery was more complex than expected and that it had brought in outside security specialists. Site content only came back gradually in mid-September, more than a week later. Print publication and distribution were unaffected.

Late on 15 September, EVA Air and Evergreen Aviation Technologies each filed material cybersecurity disclosures with Taiwan's Market Observation Post System. EVA Air said unidentified actors had intruded into its internal information environment through a malicious IP address and obtained employee names and business contact details. On discovery it followed company procedure, applied protective measures, notified the competent authority, and informed all staff. Evergreen Aviation Technologies reported that some internal systems had been attacked, isolated the affected equipment on detecting the anomaly, engaged an external forensics team, and assessed that business operations were not affected.

Put these side by side and the point is not whose perimeter was higher. For any organization of scale, being breached is a matter of probability. What separates outcomes is the few hours and the few days that follow.

## Your recovery time is not the number in the document

Most companies' security documentation states an RTO and an RPO, the target recovery time and the tolerable data loss. The problem is that those numbers were usually filled in at procurement, not derived from a drill.

On the day you actually go dark, recovery speed comes down to some very concrete things. Whether you hold an asset inventory that is still being updated and can say which systems run where and depend on what. Whether network segments are genuinely isolated, or one compromised machine opens a path across everything. Whether backups are offline and restorable while production is encrypted. Who has the authority to pull the plug, and who speaks to the outside world.

None of that is bought as a product. It is the result of architecture and rehearsal. The most telling line in the Business Weekly case is the official phrase "recovery was more complex than expected." That sentence appears in nearly every incident that stretches past a week, and it usually reflects not a technical failure but the fact that nobody ever assumed the scenario where an entire system has to be regrown from nothing.

## After 11 September, reporting speed became a legal duty

Something else happened this month that never reached Taiwan's headlines.

The vulnerability and incident reporting obligations of the EU Cyber Resilience Act took effect on 11 September 2026. From that date, any manufacturer selling products with digital elements on the EU market must issue an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, followed by a full notification within 72 hours. The final report on a vulnerability is due within 14 days after a corrective measure becomes available, and the final report on an incident within one month of the 72-hour notification.

Reporting runs through a single platform built by ENISA, the EU Agency for Cybersecurity, which went live the same day. The obligation covers products already placed on the EU market, not only newly launched models. Open-source software stewards come into scope on 11 December 2027.

Penalties sit in Article 64. Breaches of manufacturer obligations and of the reporting duties carry fines of up to 15 million euros or 2.5% of total worldwide annual turnover, whichever is higher. Most other CRA obligations only apply from December 2027, which makes reporting the first phase to arrive.

For Taiwanese manufacturers, contract producers, and module suppliers selling into Europe, the implication is direct. Your customers are on the EU market and must report within 24 hours, so they will turn around and ask you for answers in even less time.

## Whether you can file within 24 hours is decided long beforehand

Twenty-four hours sounds tight, but the real test is not reaction speed. It is whether your records were in order before anything happened.

When an incident hits, the reporting form asks a handful of things. Which product and which version is affected. Which component is at fault, and whether it is your own code or a third-party package. Which customers and which batches are affected so far. Whether mitigation exists and when a fix will ship.

Not one of those can be researched in the moment. They depend on a software bill of materials maintained as a matter of routine, on version-to-shipment records, on a customer notification path, and on a named contact with both the knowledge and the authority to speak. This is precisely what the product security incident response teams now being set up across Taiwanese industry are meant to handle.

One distinction matters here. ISO 27001 demonstrates that we manage our own house well, covering the organization's internal information security management system. What the CRA and a PSIRT demand is that we can act when something we shipped goes wrong, covering the whole product lifecycle. Neither substitutes for the other. A company already certified to ISO 27001 has the groundwork in asset inventory, access control, and incident management, so extending it to the product level is far quicker than starting from zero. But the extension still has to be done.

## Four questions for business owners

If you want to know where your company stands, these four questions will tell you. None requires budget. They only require someone to answer honestly.

  • If your main systems were destroyed today, how many days to restore from backup to a usable state? Is that figure rehearsed or estimated?
  • Are your backups offline? If an attacker holds domain administrator rights, can they reach that copy?
  • Who has the authority to disconnect and halt operations during an incident? Can that person be reached at three in the morning?
  • When a customer asks which vulnerable component went into their batch, how long before you can answer?

The first two measure resilience, the last two measure reporting capability. Any question you cannot answer marks the best place to invest next quarter, and what you invest in is usually process and architecture rather than a product.

## Resilience is designed, not purchased

The Evergreen case is worth studying not because they were never breached, but because within hours they completed four things: containment, engaging external forensics, notifying the regulator, and disclosing publicly. That pace cannot be improvised mid-incident. It comes from division of responsibility and delegated authority that already existed.

This is what we keep coming back to as a systems integration and digital transformation partner. Security is not a layer bolted on after a system goes live. It is a condition built in from the moment of architecture: how segments are divided, where backups live, how permissions are split, how long logs are retained, and who notifies whom when something breaks. We deliver systems in line with governance standards such as ISO 27001 because what matters is not only that they run smoothly on ordinary days, but that on the worst day you can still explain yourself and still come back.

The cost of a security incident was never the moment of intrusion. It is how long it takes you to return to normal operations.