In 2025, 72% of organizations couldn't see how users interacted with sensitive data across endpoints and cloud, while 53% of security teams lacked continuous visibility into where sensitive data lived. Many teams took days or weeks to locate it. Fortinet's 2025 Data Security Report exposes the uncomfortable truth behind modern enterprise data security: organizations often deploy controls before they can reliably identify the data, users, systems, and third parties those controls must govern.
That visibility gap becomes harder to manage when customer support content, SaaS applications, AI agents, vendor platforms, and unmanaged devices share information. Encryption and access controls still matter, but they can't protect a data flow nobody has mapped. A practical security program therefore starts with discovery, classification, and continuous observation, then applies controls where the risk appears.
Table of Contents
- Financial Impact of Enterprise Data Breaches
- Understanding the Data Lifecycle and Threat Models
- Core Technical Controls for Data Protection
- The Convergence of Third-Party and AI-Driven Risks
- Compliance Frameworks and Governance Implementation
- AI and LLM Security Considerations
- Implementation Roadmap and Vendor Evaluation
Financial Impact of Enterprise Data Breaches
Enterprise data security has a measurable financial baseline. IBM reported a global average data breach cost of USD 4.45 million in 2023, USD 4.88 million in 2024, and USD 4.44 million in 2025, with the global average reported at USD 4.44 million in 2026. IBM's Cost of a Data Breach research attributes the recent increase to higher detection, escalation, and lost-business costs. The figures fluctuate, but breach exposure remains in the multi-million-dollar range.
U.S. incidents carry a higher reported impact. IBM reported U.S. breach costs of USD 10.22 million in 2025 and USD 11.5 million in 2026, roughly double the global average. IBM's breach-cost reporting also found that organizations extensively using AI in prevention saved USD 2.2 million on average in 2024. AI can improve detection and prevention, but it does not replace sound architecture, accurate asset ownership, or controls that cover the full data path.
Visibility determines whether controls work
Encryption can protect a database while sensitive exports remain in a SaaS workspace. DLP can cover corporate applications while an approved integration sends support-ticket content to an AI service outside its inspection boundary. Endpoint policies can apply to managed laptops while data sits on a contractor's unmanaged device.
Visibility is therefore a control dependency, not a reporting convenience. Security teams need a current view of:
- Where sensitive data resides: Include databases, object storage, collaboration tools, ticketing platforms, knowledge bases, backups, and AI indexes.
- Who and what can access it: Map employees, service accounts, integrations, vendors, agents, and temporary credentials.
- How information moves: Follow uploads, API calls, exports, prompts, model responses, email forwarding, and synchronization jobs.
- Which copies still matter: Retention, archival, duplication, and deletion decisions should follow business and regulatory requirements.
Practical rule: If your team can't produce a current data-flow map for a high-risk workflow, it can't reliably prove that the workflow is protected.
Containment speed also affects the financial outcome. Faster identification can reduce escalation and lost-business impact, but teams cannot contain data they cannot locate. Maintain an inventory that reflects application changes, new vendors, AI workflows, and unmanaged endpoints, then test whether monitoring follows those changes.
Understanding the Data Lifecycle and Threat Models
Sensitive information doesn't become risky only when an attacker reaches a production database. Risk appears as data is created, copied, processed, shared, retained, and eventually deleted. A useful lifecycle review follows the information itself rather than the application boundary.
Creation and storage
Creation begins when a customer submits a support ticket, an employee writes a document, or a system generates an event. The first risks include excessive collection, accidental inclusion of personal information, and exposure during transfer from a browser, form, email channel, or integration.
Classify data as close to creation as possible. A support platform should distinguish public documentation from account details, authentication information, payment data, and internal escalation notes. Classification doesn't need to be perfect on the first pass, but it must produce useful handling decisions.
Storage introduces a different problem. Databases, file stores, search indexes, logs, caches, and backups may all contain copies of the same record. Apply encryption, access restrictions, retention rules, and monitoring to each location. Guidance on data-at-rest protection is useful when reviewing storage layers that sit outside the primary application database.
Usage and sharing
Data in use is exposed to applications, administrators, analysts, support agents, automation, and AI systems. An employee may need the existence of a ticket but not its private attachments. A retrieval system may need a product manual but not an internal incident report. Access should follow the task, not the broad role alone.
Sharing creates another boundary. APIs, webhooks, vendor connectors, exports, and collaboration links can move information beyond the original system. Review the destination, purpose, fields, authentication method, and logging behavior for every integration. An unsecured API can bypass otherwise strong storage controls.
The practical test is simple: trace one support question from submission to resolution. Record every system that receives the content, every transformation applied, and every person or service that can retrieve it.
Archival and deletion
Archived data often escapes active monitoring because teams treat it as inactive. Old tickets, snapshots, exports, and model-related records may still contain sensitive information and may remain accessible through administrative paths. Define who can retrieve archives, why they can retrieve them, and when the data should leave them.
Deletion must cover primary records and derived copies. That includes search indexes, caches, analytics stores, backups where applicable, and downstream vendor systems. A deletion workflow that removes only the visible user record creates a false sense of completion.
Core Technical Controls for Data Protection
Technical controls work best as layers. Encryption limits the value of stolen storage, identity controls limit who can retrieve records, DLP can interrupt risky movement, and monitoring gives investigators the evidence needed to respond. None of these controls solves the visibility problem alone.
Comparing the control layers
| Control Type | Primary Threats Addressed | Implementation Complexity | Common Gaps |
|---|---|---|---|
| Encryption | Stolen storage, intercepted traffic, unauthorized infrastructure access | Moderate to high | Poor key separation, unmanaged exports, unclear recovery procedures |
| RBAC and ABAC | Excessive privileges, unauthorized access, privilege abuse | Moderate | Static roles, stale entitlements, service-account overreach |
| Just-in-time access | Persistent administrator exposure, compromised privileged accounts | High | Weak approval workflows, incomplete session records |
| DLP | Accidental sharing, exfiltration, risky uploads and transfers | High | False positives, incomplete application coverage, weak classification |
| MFA and conditional access | Credential theft and account takeover | Moderate | Exceptions for legacy systems, weak recovery paths |
| Network segmentation | Lateral movement and broad service exposure | High | Flat cloud networks, trusted integrations, unmanaged exceptions |
| Continuous monitoring | Undetected misuse, anomalous access, poor incident evidence | High | Alert overload, missing context, siloed logs |
For encryption, protect data at rest and in transit, then make key ownership explicit. Cloud-native key management can simplify operations, while customer-managed keys may provide stronger control over access and revocation. Google Cloud's privacy product guidance describes DLP discovery and classification, de-identification through tokenization or automatic purging, data residency controls, and customer-managed keys as complementary ways to reduce exposure.
Access controls should combine role, resource, purpose, device posture, and request context. RBAC is easier to administer, but attribute-based policies handle changing conditions more precisely. Just-in-time elevation reduces standing privilege, though it requires reliable identity governance and usable approval processes. MFA is essential for privileged and remote access, but it won't compensate for an account that can reach far more data than its owner needs.
DLP should inspect content and context. A rule that blocks every export will frustrate support teams, while a rule that checks only keywords will miss structured records and encoded content. Start with high-risk workflows, tune exceptions with business owners, and send events to a monitoring system that preserves enough context for investigation.
Design principle: A control that generates alerts nobody can investigate becomes security theater.
Segmentation limits blast radius, but modern traffic often travels through approved SaaS and API paths rather than traditional network routes. Combine segmentation with identity-aware authorization, secrets management, endpoint posture checks, and immutable audit records. Teams that automate support or integration workflows should also track client n8n workflows so they can identify which automations touch sensitive data and which credentials they use.
For a deeper encryption architecture review, see enterprise data encryption. The implementation should document algorithms, key rotation, recovery, ownership, and exceptions rather than treating encryption as a checkbox.
The Convergence of Third-Party and AI-Driven Risks
Enterprise data becomes difficult to protect once it moves beyond systems security teams can see. Vendors, AI services, contractors, browser sessions, and unmanaged endpoints may all handle legitimate business data while remaining outside the organization's normal monitoring boundary. The practical problem is visibility: teams need to map where data travels, which identities and tools touch it, and what evidence remains when something goes wrong.
The 2025 DBIR executive summary reported third-party involvement in 30% of breaches, exploitation of vulnerabilities in 20% of breaches, and ransomware in 44% of breaches. It also found that 46% of compromised systems with corporate credentials were non-managed devices. These findings connect vendor access, software exposure, and endpoint blind spots. Protecting the network alone leaves important data paths ungoverned.
Treat vendors as active data paths
A vendor review should answer operational questions:
- Access scope: Which fields, files, and environments can the vendor retrieve?
- Operational access: Do support personnel, subcontractors, and automation accounts have access?
- Device controls: Can vendor users connect from unmanaged endpoints?
- Evidence: Are access events, exports, failures, and administrative actions available for review?
- Incident handling: Can the vendor identify affected records and preserve relevant evidence?
Contracts establish obligations, but they do not enforce least privilege. Use scoped credentials, short-lived access, field filtering, approval workflows, and monitoring that records enough context to investigate. The guidance on supply chain security for CTOs helps connect vendor dependencies with day-to-day security decisions.
Govern AI as a privileged integration
AI systems expand the visibility gap because prompts, retrieved context, tool inputs, and generated outputs may each contain sensitive data. Organizations need an inventory of approved AI services, connected repositories, plugins, agents, and endpoints. Without that inventory, policy enforcement covers only the tools security teams already know about.
Do not approve an AI service based only on its provider's reputation. Review retention behavior, training-use terms, regional processing, access controls, logging, deletion procedures, and connected tools. Minimize data before prompts leave controlled systems, then inspect responses before they reach customers or external workflows.
API authorization receives the same scrutiny. The API security best practices guide covers authentication, authorization, validation, rate controls, and monitoring for interfaces connecting enterprise systems. These controls help expose which applications and AI agents can reach sensitive data, rather than assuming approved integrations are automatically safe.
Compliance Frameworks and Governance Implementation
Compliance frameworks become useful when teams translate requirements into operating controls. GDPR, SOC 2, and ISO 27001 don't replace architecture, but they can create a shared language for ownership, evidence, risk treatment, and continuous improvement.
Turn requirements into control evidence
Start with a data register that identifies categories, owners, purposes, locations, processors, retention rules, and deletion paths. Then map each requirement to a technical or procedural control. The same access log may support SOC 2 evidence, ISO 27001 risk treatment, and GDPR accountability, provided it captures meaningful events and remains reviewable.
Useful mappings include:
- GDPR: Data minimization, lawful-purpose handling, data residency decisions, access requests, and demonstrable deletion workflows.
- SOC 2: Logical access controls, change management, monitoring, incident response, and evidence that controls operate consistently.
- ISO 27001: Risk assessment, documented policies, asset ownership, treatment plans, and continual review.
Google Cloud's privacy guidance identifies data residency controls and customer-managed keys as mechanisms that can support jurisdictional and governance requirements when implemented with appropriate operating procedures. The technology doesn't decide the legal basis or retention period. Those decisions belong to the organization's privacy, legal, security, and business owners.
Build auditability into daily operations
Continuous compliance is easier when evidence comes from normal workflows. Record access decisions, policy changes, data exports, administrative actions, vendor activity, incident steps, and deletion outcomes. Assign owners to review exceptions and expire them rather than letting temporary approvals become permanent access.
Avoid collecting logs that contain the sensitive content you're trying to protect. Store event metadata where possible, restrict log access, define retention, and test whether investigators can reconstruct an event without exposing unnecessary customer information.
Compliance should describe how the business protects data every day, not how it prepares for an audit once a year.
AI and LLM Security Considerations
Large language models introduce risks at every point where data enters, influences, or leaves the system. A customer support agent may retrieve website content, internal documents, tickets, and account context before generating a response. Each source needs an access decision, a classification decision, and an output decision.
Control ingestion before improving the model
Don't send raw enterprise content into a training, fine-tuning, or retrieval pipeline without understanding its sensitivity. Remove unnecessary personal information, secrets, internal case details, and regulated fields before ingestion. Tokenization or other de-identification can preserve useful structure while reducing exposure, but teams must verify that re-identification isn't trivial through surrounding context.
Retrieval permissions should mirror source permissions. If an employee can't open a document in the source system, the AI layer shouldn't surface its contents in a response. Indexes need tenant isolation, document-level authorization, deletion handling, and monitoring for bulk retrieval.
Protect prompts and outputs
Prompt injection can cause an AI system to follow instructions embedded in retrieved content or user input. Reduce the impact by separating instructions from untrusted content, restricting tools, validating parameters, and requiring authorization for consequential actions. Treat every tool call as a data movement event.
Output filtering should check for personal information, secrets, internal instructions, and customer records before a response reaches a user. Logging should capture the identity, source references, policy decision, tool activity, and outcome without storing unnecessary sensitive prompt content.
For a broader treatment of operational controls, Averta OS for AI security offers useful context on securing generative AI deployments. Vendor evaluation should cover model training use, retention, regional processing, subprocessors, incident notification, deletion, and support access.
AgentStack is one example of a support platform that combines website and document ingestion, multi-model orchestration, omnichannel delivery, role-based access control, exportable audit logs, and GDPR features such as data residency, deletion, and export. Any platform used for AI-enabled support should be evaluated against the same requirements, with special attention to tool permissions and the boundaries around customer content.
Make AI decisions reviewable
Define escalation paths for uncertain or high-impact responses. Give human agents access to the evidence behind a response, and allow them to correct or reject an automated action. Security teams should test prompt injection, unauthorized retrieval, cross-tenant leakage, sensitive output generation, and unsafe tool use before production rollout.
Implementation Roadmap and Vendor Evaluation
Begin with the workflows that combine sensitive data, external access, and business impact. Map the data, classify it, identify every recipient, and establish a baseline for access and movement before buying another control.
A practical sequence is:
- Discover: Inventory repositories, SaaS tools, AI systems, vendors, endpoints, indexes, and exports.
- Prioritize: Rank flows by sensitivity, exposure, business criticality, and recovery requirements.
- Control: Apply least privilege, encryption, DLP, conditional access, segmentation, and monitoring to the highest-risk paths.
- Prove: Test deletion, access reviews, incident containment, vendor offboarding, and audit evidence.
- Improve: Measure blind spots, exceptions, investigation time, and policy coverage, then repeat the review as workflows change.
Ask vendors where data is processed, how keys are managed, what they log, how subprocessors are governed, how deletion works, which controls apply to AI tools, and how they support incidents involving unmanaged devices. Favor integrations that expose data lineage and policy decisions rather than adding another isolated dashboard.
AgentStack helps teams build and operate AI-powered customer support agents across website, document, email, Slack, and voice workflows, with role-based access control, exportable audit logs, data residency, deletion, export, and encryption controls. Visit AgentStack to evaluate how its ingestion, orchestration, and support workflows fit your enterprise data security requirements.