UpGuard identified a publicly accessible AWS S3 repository operated by NICE Systems, a Verizon third-party vendor, that exposed customer call-centre logs containing names, addresses, phone numbers, account details and some unmasked Verizon account PINs.
The incident is a clear example of third-party cloud risk becoming enterprise risk: Verizon customer data was exposed through vendor-controlled infrastructure, not Verizon-owned systems. The source report shows a basic but high-impact control failure - sensitive data stored in an internet-accessible S3 bucket that was fully downloadable by URL, with inconsistent masking of sensitive fields and a delayed remediation window between notification and closure. The broader lesson is architectural as much as procedural: public cloud storage mechanisms designed for openly accessible content should not be used for private customer data, especially where known discovery methods and commodity scanning make exposed buckets easy to find. For cloud security and governance teams, this maps directly to failures in storage configuration, vendor oversight, sensitive data handling and detection coverage for public exposure of regulated or high-risk customer authentication data.
| What Happened | Cause | Action |
|---|---|---|
| Sensitive Verizon customer data was stored in a publicly accessible AWS S3 repository | UpGuard reports the NICE Systems bucket was “fully downloadable and configured to allow public access,” allowing access by entering the S3 URL. Internet-facing S3 functionality is intended for public content, not private customer data. | Validate that no buckets containing customer, call-centre, identity or authentication data allow anonymous access, public ACLs, public bucket policies or public website-style exposure. SkySiege flags any public data hosted via S3 public services as a misconfiguration due to better options being available for distributing even public data. |
| The storage architecture made discovery easy, not just access easy | The repository was reachable through a known AWS S3 addressing pattern and named “verizon-sftp,” making it easily identifiable and quick to enumerate. Exposed S3 endpoints are routinely scanned using known tooling and naming enumeration. | Validate whether cloud storage naming, DNS exposure and service endpoint usage create low-effort discovery paths for attackers. SkySiege checks for S3 bucket naming conventions and ensures that any buckets configured for public access, lacking encryption or possessing no policies at all are flagged up. |
| Authentication-related data was exposed, creating account takeover risk | Source report confirms some records included unmasked Verizon account PINs alongside phone numbers and other customer information. Those PINs were used to verify callers, making impersonation and SIM-swap style abuse plausible. | Validate whether authentication secrets, PINs, call-centre verification data or support-channel identity attributes are stored in logs and whether masking is consistently enforced. SkySiege checks for data classification across all resources ensuring that data is able to be identified and correctly managed. |
| Data protection controls were inconsistently applied | UpGuard observed many records with masked sensitive fields, but also records where no masking existed, including thousands of unmasked PINs in one text file. This indicates broken or inconsistent data handling controls rather than a one-off file anomaly. | Validate data classification, masking, tokenization and log-sanitization controls across all ingestion and export paths. |
| Vendor data segregation appears weak | The same repository also contained internal data from Orange S.A., another NICE Systems partner. Even if that data appeared less sensitive, the co-location of multiple customers’ data in one exposed repository indicates poor tenant separation and governance. | Validate logical and physical segregation between customer datasets in vendor-managed environments. SkySiege checks for appropriate environment classification to determine data controls and clear grouping for cloud resources. |
| Remediation and escalation took too long for an internet-exposed dataset | UpGuard says Verizon was notified on June 13 and the exposure was closed on June 22. For publicly downloadable customer data, that delay extended the period in which unauthorised access could occur. | Validate incident routing, vendor notification SLAs and emergency response authority for third-party cloud exposures. SkySiege makes misconfigurations like these visible immediately avoiding the need for external notification. |
| Third-party access to sensitive customer data outpaced oversight | NICE Systems was a trusted Verizon partner supporting call-centre and back-office operations, yet the exposed data sat in vendor-controlled AWS infrastructure. The source report explicitly frames this as third-party vendor risk becoming direct business risk. | Validate which vendors store or process customer PII, support-channel data and verification secrets in their own cloud accounts. SkySiege works well for controlling and assessing third party providers and can be done the same day. |
This incident was not just a storage misconfiguration; it was a failure in cloud architecture, vendor governance and detection coverage. Sensitive customer support data was placed in a cloud repository that UpGuard could access anonymously over the internet using a public-access storage pattern that is inherently easy to scan and enumerate. That turns a private data handling requirement into an exposure model optimised for discovery.
The business impact extends beyond privacy loss. Unmasked Verizon account PINs materially increased the likelihood of customer impersonation, call-centre fraud, account changes and SIM-swap style attacks. Because mobile numbers often underpin SMS-based authentication, the operational consequence can expand from telecom account abuse into downstream compromise of consumer accounts protected by text or voice verification as well as two factor authentication.
There are also clear visibility and governance gaps. Verizon’s customer risk depended on NICE Systems’ AWS controls, but the source report gives no indication that those controls prevented public exposure or enforced consistent masking. The inclusion of Orange data in the same repository indicates weak customer segregation and raises broader concerns around data handling discipline inside vendor-managed environments.
From an enterprise risk standpoint, this creates financial exposure through incident response, customer notification, fraud losses, contractual disputes and potential regulatory scrutiny tied to handling of personal data and authentication information. Reputationally, customers do not distinguish between enterprise and vendor custody; if a trusted partner exposes data, the brand owner absorbs the damage. For cloud security teams, the lasting lesson is clear: public storage exposure, especially in third-party environments, must be continuously detected, governed and treated as a direct business-critical control failure.
