Over the years, I have learned that customer trust is not built by compliance alone. It comes from how systems actually handle data every day. In practice, I think five areas matter most
Making customer intent consistent across systems
Treating privacy as a distributed-systems problem
Reducing unnecessary data
Designing for failure
Understanding how AI is expanding the trust boundary
I will go into each of these below and share why they matter in real systems with some of my experiences. For CISOs and other security leaders, these ideas can also help turn broad privacy and trust goals into concrete priorities for architecture, governance, data protection and operational risk.
I learned this while working on large-scale digital commerce and personalization systems. A customer action that looks simple on the surface can involve many systems behind the scenes. A preference may be stored in one place, used by several services, cached for performance and also influence analytics or machine-learning systems. That experience taught me that privacy is not just about having the right policy or control in one system. The real challenge is making sure the customer’s choice is respected everywhere that data is used.
The first area is customer intent. If a customer changes a privacy setting, opts out of personalization or asks for certain data to be deleted, that choice should not stop at the system where it was first recorded. In practice, the same data may already be used by other services, caches, event pipelines, analytics systems or machine-learning workflows. The challenge is making sure the customer’s latest choice is understood and respected across all of them, even when those systems do not update at the same time.
This is where privacy becomes a distributed-systems problem, and freshness of data becomes just as important as correctness. A preference may be updated correctly in the source system, but another service may still have an older value in a cache, an event may already be in transit or a batch process may be working from yesterday’s data. I learned from working on personalization and recommendation systems that stale information can be completely accurate and still lead to the wrong outcome because the customer’s intent has changed. Privacy works the same way, but with higher consequences. Each individual system may be functioning as designed, while the overall experience no longer reflects what the customer asked for. For security leaders, that means a privacy control should not be judged only by whether it exists, but also by how quickly and reliably the latest customer choice reaches every place where that data is used.
Regulation has pushed engineering in the right direction. Article 25 of the GDPR established the idea of data protection by design and by default, while the NIST Privacy Framework treats privacy as a risk-management problem that should be considered while systems are being built. I see both as important shifts because they move privacy closer to architecture and engineering decisions. But in practice, privacy programs can still gravitate toward proving that a control exists: Was consent captured? Who can access the data? Can we process deletion requests? Those questions matter, but they are still mostly about compliance. The harder question is whether the system continues to respect the customer’s intent after the data moves through multiple services, storage layers, pipelines and downstream consumers.While designing or reviewing a data flow, I find one question particularly useful, “If customer intent changes here, where can the old intent still survive?” It forces the discussion beyond whether a control exists and toward how the system actually behaves.
Trust breaks at system boundaries
A deletion request is a good example of where this gets complicated. To the customer, the action is simple: they ask for their data to be deleted. Behind the scenes, that information may exist in transactional storage, event streams, caches, analytical datasets, logs or derived data used by other systems. Some information may need to be deleted quickly, while other records may have legitimate security, fraud, financial or regulatory retention requirements. The goal is not necessarily to delete everything everywhere at the same moment. The important part is knowing where the data exists, why it is there, who owns it and what should happen after the customer makes the request. This is where a compliance requirement becomes an engineering and operational trust problem.
This is also why I see data minimization as more than a privacy requirement. Every additional copy of customer data creates another place that has to be secured and eventually cleaned up. Over time, data that was collected for one reasonable purpose can become a dependency for analytics, experimentation or machine-learning systems and in most cases for heavy commerce and personalization focused system the likelihood of this is very high. Leading to teams managing a growing number of systems to understand the privacy and retention rules. For security leaders, reducing unnecessary data can therefore reduce both privacy risk and operational complexity.
The Federal Trade Commission’s guidance for businesses makes a similar point: companies should collect only the information they need and keep it only as long as there is a legitimate business reason to do so. A useful question to translate it as an engineering question would be “Does this data earn the complexity that comes with keeping it?” If the answer is yes, then the system should have clear ownership, access controls, retention rules and a defined purpose. If the answer is unclear, that is usually a signal to challenge why the data is being collected or retained in the first place a good push to either remove or follow minimum retention policy an internal information security team follows.
Privacy controls should be designed for failure
Another lesson I learned from operating large-scale systems is that we should not design only for the happy path. In reliability engineering, we routinely ask what happens when a dependency times out, a message is delayed and/or a service becomes unavailable, similarly privacy controls should be reviewed. What happens if the system cannot determine the latest consent state? What happens if a deletion request succeeds in most systems but fails in one downstream service? What happens if an old event arrives after a customer has changed a preference? At scale, they become normal operating conditions, and security leaders need to know how the system is expected to behave when they occur.
The important part is to make that failure behavior intentional, like the safest choice may be to stop processing when the latest privacy state cannot be verified. We can see it as fraud prevention or security required on financial records where not every system needs the same rule. What matters is that the exception is understood and designed rather than discovered during an incident. For CISOs, this is where privacy moves from policy into operational risk where we should ask whether a control exists and know what the system will do when that control is unavailable or fails.
This also means privacy needs its own observability. We spend a lot of effort monitoring availability, latency and error rates, but I think privacy controls should have similar operational signals. How long does it take for a preference change to reach downstream systems? Where are deletion requests failing? Which systems are still depending on data that should have been retired? Without that visibility teams may know that a privacy control but still have very little confidence in how it is behaving in production. For CISOs, this is an important to understand privacy is not only be audited periodically, but also about measurable as part of day-to-day system health.
AI is widening the trust boundary
I have seen this trust boundary grow over time. During the 2015-2020, personalization and recommendation systems became increasingly sophisticated by bringing together more customer signals to improve relevance and experience. With LLMs and now agentic systems, that boundary is expanding much faster. A traditional application may read from a known database or call a defined API. An AI system can retrieve information from documents, customer records, previous interactions or other tools, combine that information and increasingly take actions based on it. That makes the trust boundary ridiculously wid. For CISOs, engineers, auditing and security team the question is no longer only “Who can access this data?” it is more about “What information can this system retrieve, combine and act on?”
The scale of this shift is already visible. Cisco’s 2026 Data and Privacy Benchmark Study found that 90% of surveyed organizations had expanded their privacy programs because of AI, while 93% planned to invest more in privacy and data governance over the next two years. I see this as a sign that AI governance cannot be separated from data governance. Before security leaders think about model controls, they need to understand what data the AI system can reach, how that access is authorized and whether the same privacy rules continue to apply when information is retrieved, combined or used to take an action. The risk is beyond too much data, it’s also that customers may not understand how their information is being used once AI is involved. A support interaction, a document or a past transaction may have been collected for one purpose, but an AI system can make that information useful in a completely different context and a place where trust can erode quickly. For me the practical question is whether the customer’s original expectation still holds when data is reused by an AI system. If the answer is unclear, the architecture and governance model need more work before the feature scales.
Turning trust into a CISO priority
I think the practical takeaway is to make customer trust part of the system review process rather than a check only during compliance reviews. When reviewing a new data flow, AI capability or customer-facing feature, I would ask a few basic questions: What customer data is being used? Why is it needed? How fresh does the customer’s preference need to be? Where can that data travel or be copied? Is the data classified and annotated so downstream systems know how it should be handled? What happens when a privacy control fails? And can we observe whether the system is actually behaving the way we intended? One practical approach that I have seen work well in large distributed systems is attaching the right security and privacy metadata to the data itself. For example, classification can help identify sensitive data, retention metadata can define how long it should remain and routing policies can determine where that information is allowed to move. This becomes especially useful when the same data flows through many services because the control does not depend entirely on every downstream team remembering the original intent.
These kinds of controls help turn a broad goal like “earn customer trust” into concrete engineering and information-security governance priorities. The harder work is making sure the system continues to respect customer intent as data moves, copied or is used in new ways. For security leaders the priority proving that the right controls exist while understanding how those controls behave in production and if the architecture can preserve customer intent through change, failure and increasingly complex AI-driven data flows, then compliance becomes part of a system customers can actually trust.
No Responses