Iris Plaza: establish the scope of a cloud incident
An estimate of stored data does not settle a breach’s impact. Iris Plaza shows why customer groups, fields and services need separate evidence before containment and restart decisions.
Ler em portuguêsBy Pentesty
Confirmed access does not establish the full impact
In its first notice, dated October 29, Iris Plaza confirmed unauthorized access and suspension of its online store. The company operates the Iris Ohyama group’s official shopping site. That record supports treating the occurrence as a confirmed incident while keeping the data investigation separate.
The November 5 notice described a suspicious file found on October 28 in the external cloud service. The stored data corresponded to approximately 7.7 million people: 5.8 million in member and former-member data and 1.9 million in non-member data. Viewing or acquisition was possible; actual leaked-record and affected-person counts remained under investigation.
Separate the groups before counting people
For a business with a similar operation, propose a scope matrix with four groups: active customers, closed accounts, guest purchasers and campaign participants. For each row, record the source system, fields present, period covered and available evidence. The classification should reflect the observed inventory without assuming everyone appears in the same datasets.
Keep row counts and distinct-person counts in separate columns. Document the authorized reconciliation rule across datasets, possible duplicates and limitations. A sample can establish that a particular field is present, but does not justify extrapolating the volume of an extraction. This prevents an operational estimate from being presented as a forensic result.
Request evidence for each field and copy
The November notice said fields varied with registration details. Some, including passwords, were described as encrypted; former members’ passwords were excluded. Payment card information was not stored in that cloud service. Those boundaries do not establish protection across the rest of the environment.
In an authorized assessment, connect each field to the copies actually used: application, exports, support and recovery, where they exist. For protected data, request documentation of the mechanism and responsibility for key access without collecting secrets. The word encrypted, by itself, does not demonstrate that the protection withstood the incident.
Reviewing closed accounts also requires understanding the applicable purpose and retention period. This case does not establish a broken deletion promise. To assess that question under another contract, use the approach to supplier deletion evidence, preserving the differences between the incidents.
Connect permissions, logs and responsibility
Before attributing the cause to the cloud, identify the contracted service, identities used and agreed responsibilities. Request authorized records that connect identity, resource, operation and time. Distinguish an existing permission from observed use and a demonstrated data transfer. Mark what the collection did not reach as unknown rather than filling the gap with an assumed cause.
Agree on an exercise with the provider using synthetic identifiers and test accounts. Check a permitted query and an attempt that should be denied within the approved scope. Connect the results to records produced by participating components. If the provider cannot make a step available, keep that dependency visible in acceptance rather than declaring complete coverage.
Define the evidence needed to resume service
Reopening a service requires its own criteria. Propose an evidence checklist for isolating the path under investigation, reviewing access and validating essential functions. In an authorized environment, use fictional data to check registration, lookup and ordering workflows. The responsible team should record the result, the exercise’s limitations and who decides whether to proceed.
Give each related service an explicit decision, even when infrastructure is shared. A precautionary shutdown does not establish compromise, and one functioning store does not automatically validate another. If the inventory and records disagree, stop drawing a conclusion about that dataset and assign the open issue to the designated owner.
Communicate the state of the evidence
Corporate communications should separate confirmed facts, possible impact and open questions, with a date and an owner for the next review. A number can change without invalidating the earlier record when its origin and scope remain clear. This discipline complements the analysis of allegations and supplier responses. Do not turn an incomplete finding into certainty of either disclosure or protection.
Frequently asked questions
Are the 7.7 million confirmed victims?
No. The notice describes the estimated size of stored data; actual leaked-record and affected-person counts remained under investigation.
Does the notice specify how passwords were protected?
It describes encryption without identifying the mechanism. Do not infer a particular algorithm, hashing or resistance to unauthorized access.
Does a precautionary shutdown establish that a service was breached?
No. Record the reason for interruption, evidence of compromise and agreed criteria for resuming service separately.
Does an assessment replace incident investigation?
No. An authorized test covers the observed scope and period. Investigating earlier access requires its own records and procedures.
Sources and references
Original Pentesty analysis, published November 8, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.