"There was a central billing system upstream on Amdocs servers, but this database also had billing details so they didn't have to reach back upstream to Amdocs if users asked to provision new services," Joker said.
What Joker discovered on the main production server
On her first day, a newly hired database administrator who asked to be called Joker was given sudo-level access and told to "take a look" at company databases. What she found was the main production server for the carrier's data services division and, inside it, a master customer table containing names, addresses, Social Security numbers, billing information — and full 16-digit credit card numbers stored in the clear.
The account states CVVs were missing from some entries but that many CVVs were present. The data was unencrypted and unobfuscated: sensitive identifiers sat in the same table as customer names and addresses, visible to anyone with sufficient database access.
Amdocs servers and the duplicate billing records
Joker reported that a central billing system existed upstream on Amdocs servers. Despite that architecture, developers had replicated billing details into the carrier's customer database so the local system would not have to query Amdocs when provisioning new services.
The duplication was described candidly: the local copy meant developers could provision without "reach[ing] back upstream to Amdocs." That convenience, according to Joker's recollection, is what left large swaths of personally identifiable and payment card information exposed in the clear on the carrier's own servers.
Permissions, tokenization expectations, and the zero‑trust shortfall
Joker expected tighter controls. She said she assumed access to that level of information would be tightly controlled and that sensitive fields would be handled using tokenization, with tokens linking back to an otherwise secure vault so credit card and Social Security numbers would not appear next to customer names and addresses.
Her account also highlights a classic access-control failure: a new hire received sudo-level permissions on day one, enabling immediate visibility into the master customer table. Joker summed up the contrast between expectation and reality: permissions should start from a zero-trust assumption and provide only what someone needs to do their job.
How management reacted and what was changed
After Joker informed management about the exposed data, the company deleted the offending payment information from the local database and required developers to "go upstream again for billing information," restoring the original intended use of the Amdocs billing system. That corrective action removed the locally stored sensitive data and forced a return to relying on the centralized billing source.
Joker later contrasted this episode with her subsequent employment at a major online retailer, saying security was "front and center" there even back in the George W. Bush era — an anecdote the account uses to underscore that secure handling of payment data was possible at the time.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: Joker's account underscores the consequences of overly broad privileges and local replication of upstream payment systems. The story specifically points to tokenization and least-privilege access controls as the techniques that were expected but absent.
- Procurement and systems architects: The presence of a central Amdocs billing system is central to the episode; duplicating billing detail into downstream databases for convenience created the exposure. Procurement leaders will note the operational trade-off between latency/convenience and central control.
- End users and customers: The exposed fields were concrete and personal — names, addresses, Social Security numbers, full credit-card numbers, and in many cases CVVs — the very data consumers rely on firms to protect.
This account is a practical reminder: technical convenience — a local copy of billing data to speed provisioning — can defeat architectural protections. Joker's first-day discovery ended with data deletion and a requirement to use upstream billing again, but it also leaves a clear question: how many systems keep the same hard-to-justify shortcuts, and how many new hires still arrive with excessive privileges? The specifics in Joker's story — Amdocs upstream billing, a master customer table with cleartext payment data, and an immediate fix after disclosure — are a small, sharp case study in why access controls and data tokenization matter.
