Safeguard
Incident Analysis•

One FAQ Vendor, Five Clients: The Scala i-ask Breach

An overnight login to the admin site of Scala Communications' i-ask FAQ system exposed inquiry data from up to five client companies, including Daiwa, Citizen and Sompo Japan.

Safeguard Security Team
6 min read

On 6 October 2026, Scala Communications disclosed that a third party had logged in to the admin site of i-ask, its hosted FAQ and inquiry system, and planted an unauthorized program on a server it manages. Customer inquiry data belonging to up to five client companies on that server may have been taken. Daiwa Securities, Citizen Watch and Sompo Japan Insurance have each confirmed they were affected.

None of those three companies had their own systems breached. Their customers' data sat with a contractor that ran the contact form on their websites.

What's affected

From Scala Communications' notice and the client disclosures:

  • Vendor and product: Scala Communications, a subsidiary of Scala Inc., and its i-ask FAQ system, which lets companies publish questions and answers and take customer inquiries on their sites.
  • Window: About 20:30 on 2 October to about 08:00 on 3 October 2026, Japan time. Citizen and Sompo give the times as 20:33 and 08:01.
  • Detection: A database monitoring alert on the morning of 3 October. Scala blocked the access around 08:00 and told affected clients the same day.
  • Volume: Up to 713,126 inquiry records across up to five client companies. Scala stresses this counts inquiries, not people, and includes repeat inquiries from the same person.
  • Data: Names, email addresses and inquiry content, with fields varying by client.

What each named client has said:

  • Daiwa Securities (5 October): About 110,000 customers' information may have leaked, about 220,000 records in total once inquiries without personal identifiers are included. Items include name, email address and account number. Daiwa says the data cannot be used to access securities accounts or trade.
  • Citizen Watch (6 October): About 100,000 people across the Citizen, Bulova and Frederique Constant inquiry forms. Data includes names, addresses, phone numbers and email addresses. Citizen warns that if a customer typed bank account or card details into the inquiry text, those may also have leaked.
  • Sompo Japan (7 October): About 60,000 inquiry records from its SMILING ROAD business dashcam service, mostly from employees of corporate customers. Items include names, contact details, employer details, driver IDs, driving alert information, device serial numbers and inquiry text. Sompo says bank account, card and My Number card data are not included.

Scala has not said how the attacker obtained a working admin login. Its notice lists the fixes it made: changing the password of the account used, blocking the attacker's IP address, quarantining the program, changing admin passwords across all environments, and reconfiguring systems so uploaded files cannot run as programs. Planned work includes multi-factor authentication for admins and separation between environments.

How to check if you're exposed

The useful question is not "do we use i-ask" but "who else runs a web form, chat widget or help center on our behalf, and what lands in it."

  1. List every third-party form on your public sites. Crawl your own domains and pull out form actions and script sources that point off-site:
# Rough pass: find form posts and scripts served from other domains
curl -s https://www.example.com/contact | grep -oE '(action|src)="https?://[^"]+"' | sort -u

Repeat for support, careers, investor relations and product microsites. Marketing teams often add these without a security review.

  1. Ask each vendor three things. Is our data in a database shared with other customers? Is the admin console protected by MFA? How long do you keep submitted inquiries?
  2. Look at what customers actually type. Export a sample of recent inquiries from each tool. If you find card numbers, account numbers or ID documents in free text, that data is now in a system that was never designed to hold it.

What to do now

  1. Set a retention limit on inquiry data. Citizen said it was already moving to a new system and planned to delete all personal data from the old one after mid-October. Ask whether your vendor can purge closed inquiries after a fixed period, and turn it on.
  2. Require MFA on every vendor admin console that can see your customers' data. Scala is adding it after the fact. Put it in your contract and check it during onboarding.
  3. Ask about tenant separation. Here, five clients' databases were reachable from the same server. If your vendor cannot describe how one customer's data is isolated from another's, record that as a risk.
  4. Add a warning to forms. A short line telling users not to include card or bank details reduces what a breach like this can expose.
  5. Prepare customer messaging. All three named clients warned customers about follow-up phishing using their names and inquiry details. Have that template ready before you need it.

Why it matters

Contact forms and FAQ widgets feel low risk because they are not core systems. But they collect names, addresses and whatever customers decide to share, often for years, in a vendor's shared infrastructure.

When the vendor is breached, the clients carry the disclosure. Daiwa, Citizen and Sompo each issued their own notices. Citizen and Sompo set up dedicated customer contact channels, and Citizen said it and Scala reported the incident to Japan's Personal Information Protection Commission. Sompo said it would review how it manages contractors. That review is cheaper before an incident than after.

Try it yourself

Take one public web form your company runs through a vendor. Find out how long submissions are kept, whether the admin login requires MFA, and whether your data shares a database with other customers. Record the answers in your vendor register with an owner and a review date.

Click through it at your own pace, or open it full screen.

Quick check

Were Daiwa, Citizen or Sompo's own systems breached?

All three say no unauthorized access to their own systems has been confirmed. The data was on Scala Communications' servers.

Does the 713,126 figure mean 713,126 people?

No. Scala says it counts inquiries, so one person who asked several questions appears several times. It was still matching names to find the real number of people.

How did the attacker get the admin login?

Scala has not said. Its notice confirms an unauthorized login to the admin site and placement of a program on the server, with a forensic investigation ongoing.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.