Customer data access transparency: 'who looked at my data' as the new standard

Where the customer’s expectations sit

A few years ago privacy meant the operator was not selling customer data to third parties. That was the baseline minimum, and customers did not require proof.

Today the line has moved. Privacy means the customer has visibility into how their data is used. In leading markets — Europe after GDPR, California after CCPA, similar frameworks elsewhere — the customer has an explicit right to know who, when and for what purpose accessed their data.

In Uzbekistan this line has not formally reached enforcement level yet, but the direction of regulatory development and the broader international trend suggest that in the foreseeable future (3-5 years) operators will have to provide customers with this visibility.

In parallel, customers are starting to ask. “Someone strangely knew about my recent trips — did the operator share that?” “I got a strange call from a partner — where did they get my data?” Without an answer, trust in the operator declines.

What transparency means in practice

Real data access transparency has several components.

A visible log in the customer’s app. A “data access” section where the customer sees who (which operator team, which partner) accessed their data, when, and for what purpose.

Categorisation by purpose. Not “accessed data”, but “the marketing team looked at your ARPU to qualify for an offer”, “the contact centre opened your account after a call”, “partner X received a SIM-status signal for anti-fraud verification”.

The ability to revoke specific access. If the customer sees a team or partner accessing and is uncomfortable, they can revoke access for that category.

An audit trail for compliance. Each access logged immutably. A year later it is possible to reconstruct who looked at what.

Plain-language explanation. Each log entry has to be understandable for a customer with no legal or technical background.

Without these components “transparency” stays a declaration in a privacy policy nobody reads.

Where this often gets stuck

Technically. Most operations systems (CRM, billing, contact centre, marketing automation) do not have unified access logging. Each system writes its own log in its own format. Building a unified view requires serious work.

Operationally. Every time an operations team accesses customer data, a log entry has to be written. Done badly, this slows operations.

The privacy paradox. Some access is part of legitimate operations. For example, marketing looks at ARPU to qualify customers for campaigns. If the log shows this in a poorly formulated way, the customer can be alarmed by legitimate access.

Partner exposure. Every signal sent to a partner is access. If all partner accesses are transparent to the customer, partners may not like the visibility.

Regulatory ambiguity. In some jurisdictions transparency at this level is not required. Building proactively is investment ahead of regulation.

Internal pushback. Teams may not want to be visible to the customer on access. “What if the customer asks why we looked at this?” — a change in operational discipline.

What changes in the operating model

Real transparency requires operational change, not only technology build.

Every access to customer data must carry a purpose code. Not “opened customer profile” but “opened FOR retention analysis”, “opened FOR a billing inquiry”, “opened FOR marketing campaign qualification”. Requires tooling and discipline.

Purpose codes have to align with the consent registry. If the customer has not consented to data use for a marketing campaign and a marketing query asks for access — the system must block, not merely log.

Regular audit reviews. Monthly or quarterly — review of who accesses which customers’ data most often, with anomaly pattern analysis.

Customer-facing communication. The customer sees the log in the app and also receives periodic summaries: “this month your data was accessed N times for the following purposes”. Builds a sense of control.

Without operational rigour the technological log becomes a data dump nobody uses.

A realistic path

Months 1-6. Foundation. Audit current access logging across systems. Identify gaps. Initial purpose code framework.

Months 7-12. Build the core. Unified access log data warehouse. Integration with major operations systems. Initial customer view as a pilot to a limited audience.

Months 13-18. Customer rollout. Customer-facing dashboard, periodic summaries, ability to revoke access. Initial education campaigns.

Months 19-24. Maturity. All operations systems integrated. Audit discipline established. Customer engagement with the transparency feature established.

By two years in the operator has a working transparency capability that positions it ahead of competitors and aligned with the assumed regulatory direction.

What often goes wrong

Building technology without operational discipline. The log exists, but purpose codes are not used consistently — the log becomes noise.

Customer-facing UX too complex. The customer opens the access log, sees hundreds of technical entries, understands nothing. Transparency without usability is a formality.

Partner transparency uncontrolled. Every signal to a partner is logged but uncategorised — the customer sees “partner X accessed” with no understanding of what or why. This creates panic, not transparency.

No customer education. Feature is live, but customer does not know it exists. Without communication transparency goes unused.

Internal teams bypassing logging to stay invisible. If teams find ways to circumvent the log, transparency is undermined.

When not to do it now

If operations systems are extreme legacy without modern logging capability, foundation build will take 2+ years. Better to wait until other modernisation is closer to completion.

If the regulator does not indicate a direction in this area, proactive investment may be premature.

If the operator’s brand is not positioned around trust, the investment does not align with positioning and the effect is limited.

If the customer base is on average not high-tech (large feature-phone share), the customer dashboard reach is low.

If competitors also do not, first-mover risk is high and the market does not require it.

Discussion points for the committee

What is the current access logging capability across operations systems? What is the gap?

What is the regulator’s direction? Indications that transparency may become required?

Is the organisation ready to enforce operational discipline on purpose codes for every access? A behavioural change.

Which 2-3 high-priority use cases for customer-facing transparency? Pilot from those.

What 18-24 month investment commitment is needed and is it there?

How SamaraliSoft can help

Customer Data Transparency Architecture — analysis of the current state of access logging, design of unified access log architecture, purpose code framework, customer-facing UX design, organisational design of operational discipline, and a phased rollout with a limited-audience pilot over 12-18 months.

Related reading

• /en/insights/telecom-consent-wallet/ — consent wallet
• /en/solutions/telecom-trust-platform-cornerstone/ — trust platform in detail
• /en/insights/telecom-youth-segments-payments/ — biometrics and UX
• /en/insights/telecom-number-reputation/ — number reputation

Sources

• Central Bank of Uzbekistan — biometric verification for digital banking
• The Paypers — digital banking verification UZ
• Ministry of Digital Technologies — telecom infrastructure
• Digital Government Portal — digital infrastructure UZ
• UzDaily — telecom market