Asia breach roundup, 3 to 13 November 2026: Nitori, Sogo Hong Kong, Mirae Asset, CSC Telecom and Taiwan's AI-assisted wave

Short answer. In the ten days to 13 November 2026, a Japanese furniture chain, a Hong Kong department store, a Korean brokerage and more than ten Taiwanese businesses all disclosed unauthorised access to customer or employee data. A Latvian SMS provider that carries traffic for Baltic banks was reported to have left a real-time database of more than 125 million text messages open to the internet. None of these involved stolen payment card numbers, as far as the companies have said. Almost all of them involved the data that fraudsters need most: names, phone numbers, email addresses, purchase history and, in the Latvian case, the one-time codes that are meant to stop account takeover.

The pattern matters more than any single headline. Attackers sat inside networks for weeks. They went for loyalty and CRM systems because that is where the contact data lives. They hit login and verification services directly. And the second factor many banks still rely on, the SMS code, turned out to be readable by anyone who found one misconfigured database. Each section below covers one incident in depth. The second half pulls out the lessons, the legal clocks in each jurisdiction, and what you can fix this week.

At a glance

Nitori: up to 37.62 million records and a three-week head start

What Nitori confirmed

Nitori Holdings is Japan's largest furniture and home goods retailer. BleepingComputer counts 879 stores in Japan and 219 more across China, South Korea, Taiwan, Thailand, Singapore and Hong Kong, with annual revenue of about US$5.8 billion.

On 9 November the company posted a notice on its Nitori Net site apologising for possible leakage of personal information after unauthorised access to its systems (Impress Watch). The sequence it described is short:

1. On 6 November, Nitori confirmed unauthorised access by a third party to a system it manages and cut the access off.
2. Log analysis with outside specialists then found signs of access by a third party from mid to late October.
3. Up to 37.62 million personal information records may have been leaked.

That figure is a ceiling on records, not a count of people. As teiss notes, Nitori had not yet worked out how many customers are behind those records, and the number may move as log analysis and data matching continue. One person with a membership, three online orders and a corporate account could appear several times.

What data is in scope

Nitori split the possible exposure into three groups (BleepingComputer, Impress Watch):

• Individual members and purchasers. Membership number, name and its phonetic reading, email address, postal address, phone number, date of birth and gender.
• Corporate members. Membership number, company and department name, representative's name, company address and phone, and the contact person's name, email and phone.
• Orders. Order information for purchases through Nitori Net and Nitori's official shops on e-commerce marketplaces.

Which fields apply varies by customer. Nitori says account passwords and credit card information were not exposed.

What is still open

On 11 November a spokesperson said the company was still investigating the cause, including whether ransomware was involved, with outside cybersecurity experts (BleepingComputer). Nitori has not said which system was entered or how. It says it has fixed vulnerable points and strengthened threat monitoring. As of 11 November, no group had publicly claimed the attack (teiss).

Nitori informed Japan's Personal Information Protection Commission (PPC) and the police, and will contact affected customers by email or post. It warned that the data could fuel phishing emails, scam calls and messages pretending to come from Nitori, delivery firms or online marketplaces, and said it will never ask for a password, card number or PIN by email or phone.

Why Nitori matters beyond Japan

Two to three weeks between first access and detection is long enough to stage and move tens of millions of rows unnoticed. And the data is a phishing kit: name, address, phone, birth date and order history let a scammer reference a real sofa delivered to a real address. Nitori is also not alone. teiss links it to other autumn breaches in Japan, including a cloud service breach at Iris Ohyama that may have exposed data on up to 7.7 million shoppers.

Sogo Hong Kong: when the loyalty programme is the target

What the regulator and Sogo said

Hong Kong's Office of the Privacy Commissioner for Personal Data (PCPD) said it received a data breach notification from Sogo on 12 November. According to the PCPD's preliminary information, abnormal data-reading records in Sogo's membership system were first found on 5 November. The PCPD estimates that about 820,000 members may be affected and has started an investigation (The Standard, Dimsum Daily).

Sogo's own statement, posted on social media the same day, said it found in November that its membership system had been accessed without authorisation. Its preliminary list of affected fields is some members' membership numbers, names, contact phone numbers, email addresses and membership points. It said it is treating the matter seriously, has launched a full investigation, notified the relevant authorities and strengthened monitoring, abnormal-activity detection and risk assessment (The Standard, TVB News).

Note who said what. The 820,000 figure is the PCPD's estimate. Sogo itself did not give a number in the statements we read.

Why points balances matter

A points balance looks harmless. It is not. Fraudsters use it in two ways.

The first is pretexting. "Your 12,480 Sogo points expire on Friday, log in here to redeem them" is a convincing lure when the number is real. The second is direct theft. Loyalty points are a soft target because many programmes let members redeem with a phone number and a one-time code, and loyalty accounts rarely get the same fraud monitoring as bank accounts. Sogo's advice to members, to be wary of unknown links and anyone asking for personal, account or verification details by phone, text or email, reflects exactly that risk.

Chow Sang Sang, the same week

The same day, jeweller Chow Sang Sang reported a separate incident. It said unauthorised access to parts of its system was first identified on a Wednesday, that it stopped the access, hired cybersecurity experts and informed the PCPD and police (The Standard). TVB quoted the company saying the unauthorised access affected "both the membership system and official e-commerce channels" (TVB News). Data that may be involved includes customer names, phone numbers, email addresses, some order details and the last four digits of card numbers, plus employee names, job titles, work emails and contact numbers. There is no public link between the two Hong Kong incidents, and we do not suggest one.

Mirae Asset Securities: a login service, a groupware system and a group under fire

What happened

Mirae Asset Securities is one of Korea's largest brokerages. On 7 November it disclosed external attacks on two consecutive days (Kyunghyang Shinmun, SBS):

• 4 November. The mobile web phone verification login service, the smartphone-based customer authentication step.
• 5 November. The internal groupware system, called mi-global.

The company said it spotted "signs of abnormal access from external IPs", blocked the relevant paths and activated its emergency response.

What leaked

• Customers. Account numbers for about 3,800 customers. The company says account holder names were not leaked.
• Employees. Personal information of 35,255 people, including retirees and outsourced workers: names, employee ID numbers, email addresses, mobile phone numbers and encrypted passwords.
• Not included. Resident registration numbers, passport numbers, driver's licence numbers and foreigner registration numbers.

The company said there was no malware infection or service disruption, that no financial damage had been confirmed, and that the incident involved data viewed from outside without authorisation. Co-CEOs Kim Mi-seop and Heo Sun-ho apologised in a notice on the company website (Kyunghyang Shinmun).

The group pattern

The story gets more serious when you look at the rest of the group. DigitalToday lists four Mirae Asset affiliates hit in under two weeks:

1. Mirae Asset Life Insurance. A customer personal data leak on 26 October.
2. Mirae Asset Global Investments. External intrusion attempts identified on 28 October.
3. Energy Infrastructure Asset Management. External intrusion attempts identified on 2 November.
4. Mirae Asset Securities. The attacks of 4 and 5 November.

The Financial Supervisory Service (FSS) sent an inspection team to Mirae Asset Securities on the morning of 9 November to check the scale and circumstances of the leak. Inspections are also under way at Mirae Asset Life Insurance and Mirae Asset Global Investments, and the FSS is examining whether the incidents share intrusion routes, attack methods or internal control weaknesses. No one has publicly attributed the attacks, and the shared-root-cause question is open.

The sector backdrop

Korea's financial sector has had a hard autumn. SBS reports that, as of 3 November, 40 security incidents had been reported by 37 financial companies, with about 473,000 information leak cases, and that authorities announced a comprehensive inspection of security systems at about 580 financial companies. An Ajou University professor quoted by SBS argued that inspections alone have often ended without lasting change, and called for continuous monitoring and re-verification.

Why a phone verification login service is a target

Phone verification sits exactly where identity is proved. Querying it can reveal which phone numbers map to customers. Account numbers alone do not move money, but paired with a phone number they make a strong pretext for a scam call. The staff data is the bigger worry: names, employee IDs, work emails and mobiles feed targeted phishing, and encrypted passwords invite offline cracking if the scheme is weak. Mirae has not said how they were protected.

CSC Telecom: the SMS pipe that banks share

Why a Latvian provider is in an Asia roundup

CSC Telecom is not in Asia. We include it because the lesson cuts across every region in this post. Banks, brokerages, retailers and loyalty programmes in Japan, Hong Kong, Korea and Taiwan all send one-time passcodes by SMS, and almost all of them do it through a third-party messaging provider. The CSC Telecom case shows what that dependency looks like when the provider's own storage is exposed.

What the researchers reported

Cybernews, a research outlet, reported finding a publicly accessible database run by CSC Telecom's Latvian branch. Here is what secondary outlets relaying that research describe:

• Technology. An unsecured ClickHouse database, a system built for analysing large volumes of data (ERR News).
• Volume and span. More than 125 million SMS messages sent between October 2022 and September 2026, with more than 3 million sent in September 2026 alone (ERR News, LRT).
• Real time. The database was updated as messages were sent, so a viewer could in principle read authentication codes as they were delivered (Identity Week).
• Content. Full message text with sender names and recipient numbers, including authentication codes, temporary passwords and password reset links, bank notifications, medical test results, bookings and delivery addresses, plus metadata such as timestamps, price and network route (ERR News, Pasquale Pillitteri).
• Senders. Swedbank and SEB in Latvia, insurers including ERGO, Compensa and Artea, airBaltic, the 112 emergency number, and businesses across Latvia, Lithuania and Estonia (ERR News, LRT).
• Timeline. Researchers found the database on 28 September 2026, the company was notified on 29 September, and the database was closed on 27 October (LRT, Pasquale Pillitteri). Public reporting followed on 11 November.

What the companies said

• CSC Telecom. Latvian public broadcaster LSM reported the provider's position that the issue had been rectified (LSM English), and the provider is reported to have said customer data was not leaked or copied. That is the provider's own assessment; no investigation result has been published. CSC Telecom's Estonian sales director said the Estonian SMS service runs on separate servers and a separate database, and that the vulnerability in the Latvian platform did not give access to the Estonian platform or its customer data (ERR News). Artea relayed CSC's description of "a security incident linked to a vulnerability in access configuration" (Pasquale Pillitteri).
• Swedbank. A spokesperson said the bank has suspended its use of CSC Telecom's services and requested information to assess the breach, and warned customers about messages asking for personal information or authentication codes (ERR News).
• SEB. SEB in Latvia said it used CSC only for limited marketing messages about pension funds, that sensitive data travels through other channels, and that its systems and client funds are not at risk. SEB in Estonia said no Estonian customer data had leaked (ERR News).
• Authorities. CERT.LV asked CSC Telecom to investigate whether its infrastructure was the source of a breach and passed information to law enforcement (ERR News). LSM reported that the State Police and the Data State Inspectorate have begun checks (LSM).

No source we read confirms that any code was actually intercepted or misused. The risk is what the exposure made possible, not a proven fraud loss.

What "real time" means for a one-time code

A one-time code is safe only if nobody else can see it before it expires. A database that records each message as it is sent removes that assumption. For an attacker who already holds a victim's password from an older breach, a code paired with a phone number and sender name is the missing second factor. Four years of history add another problem: enough bank alerts, bookings and deliveries to profile a person. The Cybernews operator's spokesperson, quoted by LRT, said the case raises GDPR questions about retention, and readable message bodies kept for about four years sit uneasily with the storage limitation principle.

Taiwan: an AI-assisted wave against more than ten firms

What officials said

At a Ministry of Digital Affairs (MODA) news conference on 11 November, Julius Huang, who heads incident notification and response at the Administration for Cyber Security, said preliminary investigations linked nearly half of recent attacks on more than ten Taiwanese businesses and online platforms to AI. He described AI as helping hackers "automatically find doors and try keys", exploiting weak passwords and unpatched software faster and more cheaply (Focus Taiwan).

Other points from the same briefing:

• The attacks affected over 1 million personal records, including names, phone numbers, email addresses and order details. No credit card or payment data breach was confirmed in the cases reviewed.
• Some attacks involved ARTEX, which officials described as a Chinese-developed automated tool for testing website and system weaknesses.
• Dennis Kung, president of the National Institute of Cyber Security, said the wave began around mid-September, with the first cases reported in South Korea, and was still ongoing. Some traffic appeared to come from Hong Kong, though Minister Lin Yi-jing cautioned that IP addresses do not establish where attackers really are.
• The minister declined to name affected businesses, citing financial and reputational harm.

Two companies had disclosed incidents on their own: e-commerce service provider 91APP, where up to 4.8 million consumers could be affected, and online travel agency ezTravel, with more than 690,000 affected members. MODA did not confirm whether either is in its tally (Focus Taiwan). The Taipei Times also lists Bank SinoPac among recent private-sector targets the ministry is assisting.

Reconciling the numbers

Two figures circulate, and they measure different things. MODA's "over 1 million records" covers the more than ten business cases it reviewed. The "about 8 million" figure comes from Chou Chih-ho, deputy director-general of the Administration for Cyber Security, speaking after a Cabinet meeting about personal data records affected by attacks over the past few weeks more broadly (Taipei Times). It is not a count for the ten-plus firms alone, and we do not present it that way.

Why "half AI-linked" is the important number

AI-assisted attacks here do not mean anything exotic. They mean the boring work of an intrusion, finding exposed services, testing default and reused passwords, fingerprinting software versions and matching them to known flaws, is now cheap and fast enough to run against every target at once. The defensive consequence is simple. The window between a flaw becoming known and someone trying it on your system shrinks toward zero, and the weak password nobody has rotated gets tested on day one. Patch speed and configuration hygiene matter more than they did a year ago, not less.

MODA also set expectations for digital economy businesses: report personal data breaches to the ministry within 72 hours of becoming aware, notify affected customers and contain the breach within 72 hours, and submit improvement plans within one month. The minister warned that scammers may use leaked order details to impersonate retailers and push consumers toward fake LINE customer service accounts claiming a recurring payment must be cancelled (Focus Taiwan).

Timeline across all five

Lesson 1: dwell time is the number that decides the size of the breach

Every incident here has a gap between first access and detection, and that gap is what turned an intrusion into a headline. Nitori's ran about two to three weeks. CSC Telecom's database was found by outside researchers and stayed reachable for about a month after the provider was told. Four Mirae affiliates were hit across ten days. Sogo has not said when the abnormal reads began.

Bulk theft is noisy if you look in the right place: query volumes, export jobs, outbound transfer and new admin sessions that look nothing like normal retail traffic. Many organisations log these events, but nobody watches them.

What to measure:

• Time to detect for unusual reads on customer databases, not just for malware on endpoints.
• Coverage of database audit logging on the CRM, loyalty and order systems, the ones attackers actually want.
• Egress baselines for the servers that hold customer data. A furniture retailer's member database has no reason to send gigabytes to an unfamiliar host at 3 a.m.
• Vendor detection commitments. If a provider holds your data, ask how quickly it would know about abnormal access, and get that answer in writing.

Lesson 2: loyalty and CRM data is a fraud kit, not "low sensitivity" data

Many data classification schemes rank card numbers and national IDs as high risk and treat contact details and purchase history as medium or low. The incidents here show why that ranking is out of date.

Look at what was taken. Nitori: names, addresses, phones, dates of birth, order history. Sogo: membership numbers, names, phones, emails, points balances. Chow Sang Sang: contact details, order details, last four card digits. Taiwan: names, phones, emails and order details. None of these is a payment credential. All of them make social engineering work.

The fraud chain is predictable. A message mentions a real order, or in Taiwan's case a fake LINE customer service account claims a recurring payment must be cancelled. The victim is walked through "verifying" their identity, which means reading out a one-time code or approving a payment. The attacker uses it for a transfer, a points redemption or a card enrolment.

The control implications are concrete. Treat loyalty and CRM stores as high-value systems with the same access reviews, logging and egress controls as payment systems. Minimise fields: if the loyalty system does not need date of birth, do not store it there. Separate the points ledger from the contact database so one query cannot return both. And plan the customer communication before you need it, because the first scam wave usually follows public disclosure within days.

Lesson 3: SMS one-time passcodes are a weak factor and a vendor dependency

The CSC Telecom case is the clearest example, but SMS codes run through the Mirae and Sogo stories too, because the scams that follow those breaches aim to talk customers out of their codes.

NIST's digital identity guidance is direct about this. In SP 800-63B, use of the public switched telephone network for out-of-band verification (SMS or voice) is "restricted": verifiers must offer alternative authenticator types, should consider risk indicators such as device swap, SIM change and number porting before sending a code, and must treat changing the registered phone number as binding a new authenticator. The same document states that OTP authentication is not phishing-resistant, because a code typed by hand is not bound to the site it was meant for.

Three separate weaknesses meet in an SMS code:

• Interception in transit or at rest. The CSC case shows a code can be read in the provider's own database. SIM swap and number porting attacks reach the same result at the carrier.
• Phishing. A real-time phishing page or a convincing phone call can collect the code from the user. The leaked contact data from Nitori, Sogo and Taiwan makes those calls more convincing.
• Vendor concentration. Many organisations use one or two aggregators for all transactional SMS. A single misconfiguration at that vendor exposes every bank, insurer and airline that uses it at once.

What to do about it depends on who you are. If you run a bank, brokerage or loyalty programme: offer and default to phishing-resistant options such as passkeys or app-based approval with number matching, keep SMS as a fallback with risk checks, and stop sending password reset links by SMS where you can. If you buy SMS services: put the provider through the same third-party review as any processor of personal data, including how long message bodies are kept, whether codes are stored at all, and who can query the store.

Lesson 4: five regimes, five different clocks

The five incidents fall under five legal regimes, and the differences are large. This is a summary, not legal advice; check the primary text and your own counsel for any filing decision.

Japan

Under Japan's Act on the Protection of Personal Information, a report to the PPC is required when a breach involves special care-required data, likely property harm, malicious action such as ransomware, or more than 1,000 people. A preliminary report is due immediately, ideally within three to five days, and a final report within 30 days, or 60 days depending on the type, with prompt notice to individuals (DLA Piper). Nitori's case meets at least two of those triggers.

Hong Kong

Hong Kong's Personal Data (Privacy) Ordinance requires data users to take practicable steps to protect personal data, but it does not require breach notification. The PCPD's June 2023 guidance recommends notifying the PCPD and affected people as soon as practicable (PCPD press statement). A mandatory notification mechanism has been proposed since 2020, and a February 2025 Legislative Council paper again listed it among planned amendments (LegCo paper), but we found no enacted change.

Korea

Korea's enforcement decree requires notice to affected people within 72 hours, and a report to the PIPC or KISA within 72 hours where 1,000 or more people, sensitive or unique identifiers, or illegal external access are involved (Enforcement Decree Article 40). Revised rules effective 11 September 2026 raised the maximum fine to 10 percent of total revenue for intentional or grossly negligent leaks affecting 10 million or more people, extended the 72-hour notice duty to cases with a high risk of exposure even before a leak is confirmed, and brought ransomware damage within the reporting rules (Korea JoongAng Daily).

Taiwan

Taiwan's Personal Data Protection Act already requires organisations to notify data subjects after investigation when their data is stolen or leaked. Amendments passed on 17 October 2025 add a duty for private-sector organisations to report qualifying breaches to a new Personal Data Protection Commission, with the threshold and timeline to be set by PDPC regulation, plus record-keeping and fines for failure to report (Baker McKenzie via Global Compliance News). MODA's 72-hour expectation for digital economy businesses applies now. Firms not covered by the Cyber Security Management Act report to their industry regulator, which passes the report on (Taipei Times).

EU

Under GDPR Article 33, a controller notifies the supervisory authority within 72 hours of becoming aware of a breach unless it is unlikely to result in risk, and a processor must notify the controller "without undue delay". The banks, insurers and airlines whose messages sat in CSC Telecom's database are controllers, and each needs to hear quickly from its processor what was exposed. Swedbank's request for information is that duty in practice.

The common thread in the law

Every clock starts at awareness, so slow detection does not buy time. And a large share of customer data processing happens at vendors, so your notice clock may depend on how fast they tell you.

What customers of these companies should do

If you are a Nitori, Sogo, Chow Sang Sang, Mirae Asset or affected Taiwanese platform customer, or you receive bank SMS in the Baltics:

1. Expect targeted scams. Messages that mention a real order, a real points balance or a real account are now more likely, not less. Treat any unsolicited contact asking for a code, a password or a payment as fraud until proven otherwise.
2. Never read out or forward a one-time code. No retailer, bank or delivery firm needs you to tell them a code they sent you.
3. Contact the company through its own app or website, not through a link or number in a message.
4. Move important accounts off SMS codes where the service offers passkeys or app-based approval.
5. Watch loyalty balances, not just bank statements. Points theft is easy to miss.
6. Ask your mobile operator about a port-out or SIM-change lock if it offers one.

What security teams should do

This week

• Search your vendor list for SMS and messaging providers. Find out whether message bodies are stored, for how long, and who can query them, and whether one-time codes reach any log or analytics store.
• Review access paths to CRM, loyalty and order databases. List every account and service that can run bulk reads, and remove what is not needed.
• Check internet exposure of data stores. ClickHouse, Elasticsearch, MongoDB, Redis and similar services should never answer on public addresses without authentication.
• Rehearse customer comms. Have a draft notice and a scam warning ready in each language you serve.

This quarter

• Measure detection time for data access. Run a tabletop where an attacker with valid credentials reads the customer table slowly for three weeks.
• Make phishing-resistant authentication the default for customers and staff, with SMS as a risk-checked fallback.
• Patch faster at the edge. The Taiwan briefing describes automated tools that find doors and try keys. Assume known flaws in internet-facing software will be tried within days.
• Tier vendors by the data they hold. A messaging provider that sees every authentication code belongs in your highest tier, alongside payment processors.
• Map your notification clocks. Build one runbook listing every regulator, threshold, deadline and owner across the markets you serve.
• Group-wide learning. If one subsidiary is hit, assume the others are being tested. Share indicators and intrusion routes across the group within hours, not after the regulator asks.

Fix it without waiting for upstream

You do not need the companies above, or your own vendors, to finish their investigations before you act. These are steps a team can take today with tools it already has.

1. Strip codes from logs and analytics. Search your own systems for places where outbound SMS content is logged. Mask or drop the code before it is written. Do the same for password reset tokens and magic links.
2. Shorten code lifetime and bind codes to context. Make one-time codes expire quickly, allow few attempts, and bind each code to the session or transaction it was issued for, so a stolen code cannot be replayed elsewhere.
3. Add risk checks before sending SMS. Before sending a code, check for recent SIM change, number porting or a new device where your provider or carrier exposes that signal, and fall back to a stronger factor if risk is high.
4. Put a retention limit on your messaging provider by contract and by configuration. Many providers let you set message body retention. Set it to the minimum you need for delivery troubleshooting.
5. Lock down data stores by default. Require authentication on every database listener, bind admin interfaces to private networks, and add a policy check to your infrastructure code that blocks public exposure of database ports.
6. Separate loyalty contact data from the points ledger so that one compromised query or service account cannot return both identity and value.
7. Set bulk-read alarms. Add a simple threshold alert on row counts returned or bytes exported from customer tables per hour, per account. It will be noisy at first. Tune it rather than turn it off.
8. Rotate and review service credentials on any system that can read customer data, including groupware and integration accounts like the ones targeted at Mirae.
9. Warn your customers first. If your brand is likely to be impersonated after a peer's breach, publish a short "we will never ask for your code" notice now.

None of these depends on a vendor patch or a regulator's finding. Most take hours, not weeks.

How Safeguard helps with this class of problem

Everything above comes from company statements, regulators and published reporting. Our part is helping teams manage the vendor, software and compliance risk these incidents expose. These are the generally available capabilities that map to the steps above.

Third-Party Risk Manager (TPRM). TPRM keeps a vendor directory with contracts, SLAs and risk tiers, and gives vendors a self-service portal. You can tier your messaging, CRM and loyalty vendors by the data they hold, send questionnaires about retention and access controls, request SBOMs and other evidence one at a time or in bulk, and track each request until it is validated. Each vendor gets a risk score across vulnerability, compliance, component and operational risk, and continuous monitoring sends alerts on new critical vulnerabilities and risk changes to email, Slack, Teams or a webhook so they reach an owner.

Compliance automation. The compliance suite brings frameworks, controls, evidence, monitoring, questionnaires, risks and vendors into one place, with continuous evidence collection across major clouds and identity providers. Teams use it to map controls and gather evidence for SOC 2, ISO/IEC 27001 and GDPR, including the vendor oversight, logging and incident response controls that matter after an incident like these. Safeguard itself is SOC 2 Type I and Type II audited, so we answer the same vendor questions we suggest you ask.

Asset discovery. Asset discovery inventories repositories, images, packages, SBOMs, vendors and workloads, and applies guardrails and enforcement to what it finds. That gives you a starting list of the systems and providers that touch customer data, built from what is actually connected rather than from memory.

Policies and gates. You can write organisation-wide policies, including from plain-English prompts, and enforce them as gates at build, CI and release, with actions to block, warn, notify or require approval. Examples that fit this post: block a release that adds a known-exploited component to an internet-facing service, or require approval for infrastructure changes that open a database port.

SCA and SBOM monitoring. Software composition analysis and SBOM generation in SPDX and CycloneDX, enriched with EPSS and known-exploited data, show which of your services and vendor products carry a component that is under active attack. When automated tools are probing for unpatched software within days, knowing where a vulnerable library sits is what lets you patch first.

You can see the platform at https://safeguard.sh.

FAQ

How many people were affected by the Nitori breach?

Nitori has not said. It reported that up to 37.62 million personal information records may have been leaked, and that figure counts records, not people. One customer can appear in several records as a member, a purchaser and a corporate contact. The company said the number may change as its investigation continues (teiss).

Did anyone actually steal SMS codes from CSC Telecom's database?

No source we read confirms that. Researchers reported that the database was open and updated in real time, so codes could have been read as they were sent. CSC Telecom says the vulnerability is fixed, and Latvian police and the Data State Inspectorate have begun checks.

Why does an SMS leak in Latvia matter to banks in Asia?

Because the architecture is the same everywhere. Banks, brokerages and loyalty programmes across Japan, Hong Kong, Korea and Taiwan send one-time codes through third-party SMS providers. If one of those providers stores message bodies in an exposed database, every sender's codes are exposed at once.

Is SMS two-factor authentication still safe to use?

It is better than a password alone, but it is a weak second factor. NIST classifies SMS and voice verification as "restricted" and states that OTP authentication is not phishing-resistant. Use passkeys or app-based approval where available, and keep SMS as a fallback with risk checks.

What did Mirae Asset Securities lose?

About 3,800 customer account numbers, without account holder names, and records for 35,255 current and former employees and outsourced staff, including names, employee IDs, emails, mobile numbers and encrypted passwords. The company said resident registration numbers and similar identifiers were not included and no financial damage has been confirmed.

Is Mirae Asset's breach linked to the other Mirae affiliates?

That is what the Financial Supervisory Service is examining. Four group affiliates reported leaks or intrusion attempts between 26 October and 5 November. No common cause has been announced.

Does Hong Kong require companies to report data breaches?

Not under current law. Notification to the PCPD is voluntary, guided by the PCPD's 2023 guidance, which recommends notifying as soon as practicable. A mandatory scheme has been proposed but, as far as we found, not enacted.

Sources

Nitori

• BleepingComputer, Nitori says hackers stole up to 37.6M customer records: https://www.bleepingcomputer.com/news/security/japanese-furniture-giant-nitori-says-hackers-stole-376m-customer-records/
• teiss, Nitori discloses breach exposing up to 37.62 million records: https://www.teiss.co.uk/news/japanese-furniture-retailer-nitori-discloses-breach-exposing-up-to-3762-million-records-18442
• Impress Watch (Japanese), 9 Nov 2026: https://www.watch.impress.co.jp/docs/news/2154952.html
• Nitori Net notice, 9 Nov 2026: https://www.nitori-net.jp/ec/notices/info261109/

Sogo Hong Kong and Chow Sang Sang

• The Standard: https://www.thestandard.com.hk/news/article/348370/SOGO-and-Chow-Sang-Sang-report-data-breaches-affecting-up-to-820000-members
• Dimsum Daily: https://www.dimsumdaily.hk/sogo-hong-kong-says-820000-members-hit-by-data-leak/
• TVB News: https://news.tvb.com/en/1206042-SOGOChowSangSangsawdataleaks
• South China Morning Post: https://www.scmp.com/news/hong-kong/law-and-crime/article/3374260/hong-kong-sogo-data-breach-puts-personal-information-820000-members-risk

Mirae Asset Securities

• Kyunghyang Shinmun: https://www.khan.co.kr/en/article/202611070942017/
• SBS News: https://news.sbs.co.kr/english/article.do?news_id=N1008835638
• DigitalToday: https://www.digitaltoday.co.kr/en/view/123052/fss-launches-on-site-inspection-at-mirae-asset-securities-probes-links-to-series-of-group-hacks

CSC Telecom

• ERR News: https://news.err.ee/1610193241/potential-csc-telecom-leak-exposes-125-million-text-messages-across-baltics
• LRT: https://www.lrt.lt/en/news-in-english/19/3111428/over-125m-leaked-text-messages-expose-data-of-lithuanian-companies-and-customers
• Identity Week: https://identityweek.net/massive-csctelecom-breach-exposes-125-million-sms-records-across-the-baltics/
• Pasquale Pillitteri: https://pasqualepillitteri.it/en/news/32664/csc-telecom-leak-125-million-sms-swedbank-seb
• LSM English: https://eng.lsm.lv/article/society/society/13.11.2026-possible-data-leak-issue-rectified-says-service-provider.a671760/
• LSM (Latvian): https://www.lsm.lv/raksts/zinas/latvija/12.11.2026-noverstas-nepilnibas-csc-telecom-iszinu-datubazei-policija-un-datu-valsts-inspekcija-sakusi-parbaudi.a671716/
• Cybernews original report: https://cybernews.com/security/csc-telecom-leaks-swedbank-seb-sms-messages/

Taiwan

• Focus Taiwan, 11 Nov 2026: https://focustaiwan.tw/sci-tech/202611110020
• Taipei Times, 13 Nov 2026: https://www.taipeitimes.com/News/taiwan/archives/2026/11/13/2003867667

Law and standards

• Japan APPI (English translation): https://www.japaneselawtranslation.go.jp/en/laws/view/4241/en
• DLA Piper on APPI breach reporting: https://www.dlapiper.com/insights/publications/2022/03/updates-for-the-amendment-of-japans-act-on-the-protection-of-personal-information
• PCPD Guidance on Data Breach Handling and Data Breach Notifications (June 2023): https://www.pcpd.org.hk/english/resources_centre/publications/files/guidance_note_dbn_e.pdf
• PCPD press statement, 30 Jun 2023: https://www.pcpd.org.hk/english/news_events/media_statements/press_20230630.html
• LegCo paper CB(2)247/2025(04): https://www.legco.gov.hk/yr2025/english/panels/ca/papers/ca20250217cb2-247-4-e.pdf
• Korea PIPA Enforcement Decree Article 40: https://prighter.com/resources/laws/korean-pipa/enforcement-decree/articles/article-40
• Korea JoongAng Daily on the 10 percent fine cap: https://koreajoongangdaily.com/business/korea-raises-data-breach-fines-to-10-of-revenue/12869899
• Baker McKenzie via Global Compliance News on Taiwan PDPA amendments: https://www.globalcompliancenews.com/2025/11/12/https-insightplus-bakermckenzie-com-bm-investigations-compliance-ethics-taiwan-amendment-to-personal-data-protection-act_10292025/
• GDPR Article 33: https://gdpr-info.eu/art-33-gdpr/
• NIST SP 800-63B: https://pages.nist.gov/800-63-4/sp800-63b.html