Docomo's October 27, 2026, notice concerns 443,495 records associated with Docomo Hikari's plala (S Course), including specified former customers. It follows unauthorised access to a So-net database. This is a defined service group, rather than all Docomo customers.
For a worried reader, the first task is to identify the subscription behind the familiar company name. Which service did you actually use, and during which dates?
This guide explains how to read the official notices, separate account and email credentials, and organise a response without following an unfamiliar message into a fake login page. It uses public announcements and support information. It has not accessed customer accounts, obtained leaked data or established whether any particular reader is affected.
Begin with the exact service name
Find the service description in your own contract or account records. Preserve the full wording, including the course name. Similar-looking brands and subscription labels can refer to different products, and abbreviating them may erase the distinction that determines whether a notice applies.
Docomo's dated announcement is here: https://www.docomo.ne.jp/info/notice/page/261027_05_m.html. It distinguishes plala (S Course) from other named plala services. The information categories it lists include contact and identity details and service identifiers; it says passwords and payment-related information are not included in that specified plala disclosure.
Do not turn that last statement into a conclusion about every part of the wider So-net incident. The operator's separate announcement divides the findings into categories. The meaningful comparison is between your service and the corresponding category, rather than between two isolated headlines that happen to use different totals.
For a household with several subscriptions, make a private list of the service, account holder and period of use. This is an organisational tool, not a request to send identity information to this publication. Avoid copying full identifiers into a shared family chat when a service name and an unresolved question are enough to coordinate the next step.
Keep the incident dates separate
Docomo's announcement places the unauthorised access on October 19 and says it received the provider's report on October 26 before publishing its notice on October 27. Those dates describe different stages. An incident date, a confirmation date and an announcement date should not be treated as interchangeable.
The distinction is useful when comparing a news report with an account message. An older event can become newly public, and a later notice can add detail without meaning that a second attack has occurred. Read the wording of each update before deciding what has changed.
If you save a notice, record its date and the date you checked it. Keep any revised version distinguishable from the earlier one. A private note saying “read the October 27 announcement on October 28” is clearer than a screenshot labelled only “today,” especially if another household member examines it later.
This also helps when asking support a question. You can identify the specific announcement and service instead of describing an undated story about a company name. The support team still has to assess the account, but the question begins with the right context.
Why the wider So-net announcement has several categories
So-net's announcement separates member information, certain email-service credentials, plala (S Course) information and smaller additional categories. Its member and plala entries should not be read as a single statement that every listed type of information was exposed for every customer. The original announcement is at https://www.so-net.ne.jp/info/2026/20261027_0001.html.
The operator says it reset passwords for the affected email-service category on October 27 and asks the relevant users to set them again through My Page. That is a specific instruction for the affected category, not proof that every password connected with every product was disclosed.
When a notice contains a list, ask three questions about each item: whose information is covered, which fields are involved and what action the operator requests. The answers may differ between items. Read the boundaries before combining them into a personal action plan.
For example, a fictional household might have a mobile subscription, an internet-access contract and an additional mailbox. Those are three service questions, even if one person pays for all of them. One affected mailbox does not automatically establish that a mobile password or every financial account has been compromised.
An account password and an email password can be different
So-net's incident FAQ identifies four affected email-service groups: Mail Service (G), A-Box, So-net VAIO Mail and PostPet Mail Account Service. It separately gives examples of passwords for which disclosure had not been confirmed, including the My Page login password and the free basic mailbox password.
Consult the current FAQ rather than choosing a reset procedure solely from a broad news headline: https://www.so-net.ne.jp/support/faq/qa202610_01/. The service name, the credential's purpose and the operator's instructions need to match.
Think of a password as belonging to a particular door. Changing the password for one door does not necessarily change another. A member account may manage a subscription while a mail client uses a separate email password to collect messages. Confusing those roles can leave the intended task unfinished or create an unnecessary access problem elsewhere.
Before making a change, write down which credential you are changing and through which official service. Do not write down the secret itself in the same planning note. If the official process asks you to prove ownership, complete that process through the provider's route rather than asking an unknown helper to bypass it.
A careful sequence for an affected email-service user
First, confirm that your mailbox belongs to the category described in the FAQ. Then open the provider's official support route independently. Follow the current procedure for that service, paying attention to whether the instructions concern My Page, an email password or another setting.
After the change, check the way you normally use email. So-net's FAQ says that people using a mail application may need to replace its stored email password, while Webmail users should verify that the new password works. Use the provider's instructions for the specific application rather than changing unrelated settings at random.
If access fails, preserve the error wording and the step at which it occurred. A failure to connect is not, by itself, evidence of a new attack. It may mean that the application still has the old credential, that a change has not yet taken effect or that another issue needs support. The official guidance should determine the next check.
Do not repeatedly change several different passwords without tracking which change belongs to which service. A concise record of completed steps makes a support conversation much easier. Record the action and time, never the new password or a one-time security code in a public or shared document.
Guard against a convincing follow-up message
Japan's National Police Agency explains phishing as impersonation through messages or sites designed to obtain information such as login details. Its prevention guidance is available at https://www.npa.go.jp/bureau/cyber/countermeasures/phishing.html. A genuine incident can give a fraudulent message a plausible story without making the message authentic.
A message that knows your name or mentions the right provider may feel reassuring. Those details do not establish that the sender controls an official support channel. Open the known official site or app yourself and check the relevant notice there, rather than entering credentials through an unexpected message's link.
The operator's incident notice also warns about suspicious contact. Preserve the distinction between reading a public announcement and responding to someone who claims they can fix the problem. A caller asking for a security code is a separate event that needs verification; the existence of the breach does not authorise that request.
If you have already entered information on a suspicious site, use the affected service's official recovery route promptly and seek the appropriate support. If money or financial access is involved, contact the relevant financial provider through its known channel. This article cannot verify a transaction or guarantee recovery, but an accurate record of what you entered can help the responsible service assess the problem.
Review password reuse without assuming every account was breached
The Information-technology Promotion Agency recommends long, difficult-to-guess passwords that are not reused across services, together with multi-factor authentication where provided. Its account-security guidance is at https://www.ipa.go.jp/security/anshin/measures/account_security.html.
That advice supports a general review of account habits. If the same password was used for a service whose credential was exposed and for another important account, the reuse creates a connection worth addressing through the other service's official settings. It does not mean this article has evidence that the second service itself suffered a breach.
Keep the review manageable. Identify the credential concerned, the other services where it was reused and the current official method for securing each account. Work through the list carefully. Avoid making broad changes to business or shared accounts without the appropriate account owner's authority and recovery arrangements.
If a service offers additional authentication, understand its setup and recovery process before relying on it. A stronger sign-in method helps protect access, while losing every recovery method creates a different problem. Keep recovery material privately and use the service's documented process; never send it to a person who offers to activate protection on your behalf.
Prepare a support question that can be answered
A useful support enquiry identifies the service and the uncertainty. For example, a fictional former customer might ask whether their cancellation date places them within the period specified in the notice. Another might ask which official procedure applies to an additional mailbox whose application no longer connects.
Those are different questions. The first concerns inclusion in a category; the second concerns completing a service-specific action. Combining them into a broad request to “check everything” can obscure the practical next step. Keep the facts of your account separate from speculation about how the attack occurred.
Use contact details reached from the current official announcement or support page. Do not rely on a telephone number supplied in an unsolicited message. This guide deliberately points to the maintained source rather than promising that a support number, opening time or procedure will remain unchanged indefinitely.
When preparing records for support, retain originals and send only what the official process requests. Do not upload identification to a random breach-checking site. There is no need to search for stolen records to prove that you read the notice, and doing so can expose your information to another untrusted party.
Preserve evidence without spreading personal data
Keep the public notice separately from private account material. The public notice can be shared as a link; an account statement may contain information that should remain private. If someone helps translate a message, consider whether the relevant passage can be discussed without exposing unrelated identifiers.
For an unexplained account event, note the time, the service and what you observed. Preserve any relevant message or provider reference. Do not transform an observation such as an unfamiliar email into an accusation against a named person. The provider or appropriate authority must assess what the evidence establishes.
Our Alliance Medinet guide offers a separate example of matching a notice's scope to a response: https://monetizearticle.com/article/alliance-medinet-data-breach-how-to-read-your-notice-and-respond-safely-051da1. Its event and service context differ from this case. The transferable habit is to identify the exact affected category before deciding which action follows.
Conclusion
The Docomo Hikari notice concerns a defined plala (S Course) group within a wider So-net incident. Start with your exact service, read the matching information category and follow the official instructions for the relevant credential. Preserve the dates and scope when comparing later updates.
A measured response can be active without being indiscriminate: verify the route, complete the requested task, review any genuine password reuse and record unresolved questions. Avoid treating a broad company name, a leaked contact detail or an urgent message as a complete account assessment.
Sources and research note
Researched October 28, 2026. Primary sources are the October 27 Docomo and So-net announcements, So-net's incident FAQ, IPA account-security guidance and National Police Agency phishing guidance. Statements about information categories retain their service-specific scope; no individual exposure, account compromise, compensation or future misuse is established here. No leaked records or private accounts were accessed. Examples are fictional. Google Trends Japan, Past 24 hours, All categories and All trends, sorted by search volume, showed “ドコモ 情報 漏洩” first at 100K+, Active, when retrieved at 11:00 UTC. The original conceptual AI image is an explanatory home-internet scene, not an incident screenshot, leaked record or official notice.