Data Security: How Controls, Compliance and Governed Access Work Together

How much sensitive data is your security program actually protecting?

It sounds like a straightforward question. In practice, enterprise data moves across applications, cloud environments, partner workflows and AI systems, often leaving behind copies that no longer sit under the same controls as the source.

That makes coverage as important as the controls themselves. In a 2026 Cybersecurity Insiders survey of 1,064 enterprise security practitioners, only 7% said they could track sensitive data moving between applications in real time, while 19% said reconstructing its path could take weeks. Another 8% said they rarely have enough data to reconstruct the path at all.

Coverage gaps show up in several places. Sensitive data may sit in stores a security team no longer knows about, move into systems where the original controls no longer apply, or be accessed by users, applications and AI workloads under different identities and permissions. As the data estate expands, security depends on understanding which data is sensitive, where it resides and whether the intended controls still cover it.

Data security is the practice of protecting information throughout its lifecycle — from creation and storage through use, movement, sharing and deletion — against unauthorized access, disclosure, alteration, loss and theft. The goal is confidentiality, integrity and availability, supported through physical, technical and administrative controls.

The challenge is that the data objects being protected rarely stay put. A production table containing customer data might feed an analytics model, a development workflow, a partner integration and an AI application. Exports and pipeline outputs may create additional copies along the way, sometimes in environments owned by different teams.

Each of those copies needs its own protection. If an analyst exports query results to cloud storage, for example, the row access policy on the source table doesn’t govern the file sitting in that bucket. The bucket now needs appropriate permissions, monitoring, retention and — depending on the data — its own classification and protection controls.

That distinction is central to modern data security. Policies enforced against governed data can cover multiple ways of accessing that data while it remains inside the enforcement boundary. Once a separate copy exists elsewhere, the organization has another asset to secure.

Watch how Snowflake helps teams identify and govern sensitive data while maintaining centralized oversight:

Data security, data privacy and data governance overlap heavily in practice, which is why they’re often discussed together. But they answer different questions, and the distinction matters when teams are deciding who will own a policy, which controls apply and what evidence will show that the policy was followed.

For example, the same customer table might raise three different questions depending on who’s looking at it. A security engineer wants to know who can query it. A privacy professional wants to know whether the organization should retain the personal data it contains, and whether a particular use is permitted. A governance team needs to know who owns those decisions, which policies apply and where the evidence lives.

Data security protects data against unauthorized access, disclosure, alteration and loss.

Data privacy governs the appropriate collection, processing, retention and sharing of personal data, including the legal or organizational basis for those activities.

Data governance establishes ownership, policies, definitions, processes and accountability across the data estate.

Data classification connects all three. If a column containing personal identifiers has never been classified as personally identifiable information (PII), security teams won’t know that data needs stronger controls, and privacy teams may not know that the data falls within a particular obligation.

Data residency and sovereignty requirements may affect where records are stored or processed, which jurisdictions apply and who’s allowed to access them. Those decisions span governance, privacy and security.

Security teams often describe threats by attacker technique: phishing that steals credentials, credential abuse that broadens access, lateral movement that reaches additional systems or ransomware that encrypts or exfiltrates data. But the goal of understanding the techniques is to prevent specific outcomes — unauthorized access to sensitive records, modification of protected data, exfiltration or loss of availability.

Organizing risk around those outcomes makes it easier to connect each one to the controls designed to reduce it.

Unauthorized access

A stolen credential, compromised service account and excessive privilege can give someone access to data they weren’t meant to have. The scope of exposure depends heavily on the permissions attached to the identity.

For example, an application might need only a small number of tables to perform its current function, but its service account still holds access to many more from earlier projects or configurations. If that credential is compromised, the attacker inherits the broader permission set rather than the narrower access the application actually uses.

Least privilege, access reviews, multifactor authentication and more granular row- or column-level controls all reduce the amount of data exposed when an identity is compromised.

Accidental exposure

Not every exposure begins with an attacker defeating a control. Sensitive data may be placed in a storage location with overly broad permissions, shared with a larger audience than intended or moved into an environment with weaker controls than the source.

Misconfiguration is especially risky when data is copied between systems. A production table may be tightly governed, while an export of the same records sits in a development or collaboration environment with a different permission model.

Continuous discovery, configuration review and posture management help identify those gaps before they turn into incidents.

Data exfiltration

Data exfiltration occurs when sensitive information is copied or transferred outside its approved environment without authorization. The movement itself can happen through a compromised account, an over-permissioned integration, malware or an insider with legitimate access.

Once data leaves the governed environment, the organization has lost direct control over where that copy goes next. Exfiltration therefore affects both incident response and regulatory analysis, especially when personal, financial or other regulated data is involved.

Monitoring, data loss prevention systems and access history help teams detect unusual movement and reconstruct what data left, which identity was involved and when it happened.

Learn more about financial data security >

Insider misuse

Insider risk is different from credential theft because the user may be fully authorized to access the system. The problem is that the data is being accessed, used or shared outside the purpose the access was granted for.

A privileged user might browse sensitive records unrelated to their role, export data for personal use or share information with someone who shouldn’t receive it. In these cases, the account is valid and the authentication event is legitimate, but the data is being accessed or handled inappropriately.

Access governance, logging, periodic entitlement reviews and monitoring for unusual behavior all help reduce that risk.

Protecting sensitive data usually means combining several controls, each aimed at a different part of the problem. Access controls decide who or what gets in, masking and row- or column-level policies limit what authorized users can see, encryption protects data at rest and in transit, and logs record what happened afterward.

Learn more about data security protocols >

Control who and what has access

Every query begins with an identity. For a person, that might be an employee account authenticated through the organization’s identity provider. For an application, it might be a service account or another workload identity.

Identity and access management establishes who or what is making the request. Role-based access control (RBAC) associates that identity with permissions, while least privilege keeps those permissions limited to what the role actually needs. Multifactor authentication (MFA) adds an additional check at authentication time, helping reduce the risk that a stolen password alone is enough to reach a sensitive account.

The challenge is that permissions tend to accumulate over time. For example, someone changes teams but retains an old role-based access. Or an integration gains temporary access during a migration and keeps it after the migration is complete. Over-permissioning is still common in many organizations. In Palo Alto Networks’ 2025 survey of more than 2,800 cloud security professionals, 53% cited lenient identity and access management practices as a top challenge, which the report identifies as a leading vector for data exfiltration.

Periodic access reviews are meant to catch permission drift. More granular controls can then limit which rows or columns an authorized user or workload is allowed to see.

Learn more about row-level security >

Protect sensitive values

Access is only one dimension of protection. Data also needs safeguards while it’s stored, transmitted and presented to authorized users.

Encryption protects data at rest and in transit. Key management determines who controls the cryptographic keys, how they’re stored and when they’re rotated. Customer-managed keys give organizations additional control over parts of that key hierarchy when their security model requires it.

Data masking, tokenization and anonymization solve different problems.

A dynamic masking policy might show the final four digits of an account number to one role while exposing the complete value to another. Tokenization replaces the original value with a token, and an authorized process uses a controlled mapping or token service when it needs the underlying data. Anonymization seeks to reduce the ability to associate information with an identifiable person, typically for use cases where the original identity is no longer required.

Enforce policy where data is queried

The same sensitive data is often accessed through more than one interface — a business intelligence (BI) tool, notebook, application or AI workflow. If each of those tools applies its own version of the security rule, teams have to keep the logic consistent everywhere.

Suppose a BI dashboard hides Social Security numbers before displaying a customer table. Users of that dashboard see masked values. A notebook querying the underlying table directly never passes through the BI rule, so the dashboard configuration provides no protection there. If the masking policy is applied to the governed column itself, however, it can be evaluated at query runtime whenever that column is queried — whether the request comes through a notebook, dashboard or another supported query interface.

Enforcing policy against the governed data object gives different consumers a common control point — the rule or policy is evaluated when the query reaches the data, rather than depending on each consuming application to reproduce the same restriction.

This is why enforcement location and copy reduction belong in the same security conversation. Centralized policy reduces duplicated control logic, and fewer exports reduce the number of places where that logic no longer applies.

Monitor what actually happens

A control configuration tells you what should happen. Logs show what actually happened. Access history and audit records let teams inspect which identities queried sensitive data, what objects they accessed and when the activity occurred. Those records support incident investigation, access reviews and compliance evidence.

They also reveal gaps in policy design. For example, if a privileged role queries a sensitive table every day even though the underlying workflow no longer requires it, the access model needs another look.

Usability also must be considered. When legitimate users repeatedly encounter controls that block normal work, they often request broader roles, create exports or move data into less-governed tools. Precise controls only work when the approved path lets people complete the job they’re authorized to do without undue burden.

Cloud data security works within a shared responsibility model: the provider secures the portions of the service it operates, while customers remain responsible for areas such as their identities, permissions, data access and configuration. The exact boundary varies by cloud service and service model.

Consider a broadly permissioned role. The cloud provider can protect the underlying infrastructure and service, yet the cloud customer may have assigned that role much broader access than intended. If the credential is compromised, the underlying platform cannot infer that the grants were broader than the business intended.

Network configuration works the same way. Private connectivity, network policies and endpoint restrictions shape how workloads reach the service, while identity and data policies determine what they’re allowed to do once connected.

In a multicloud environment, consistency is a practical operating issue. One data set might be governed through one identity model while an equivalent copy elsewhere uses different roles, network rules and audit tooling. As teams maintain those configurations independently, small differences accumulate.

The question security teams need to ask is: If sensitive data exists in several cloud environments, does each location enforce equivalent access, masking, network and monitoring requirements?

Most data practitioners work above the physical and infrastructure layers, yet the controls beneath the database set the security floor. A well-designed row access policy does little against a compromised host with direct access to unprotected storage.

Infrastructure security covers the systems that make data services reachable and reliable: physical data center controls, network segmentation, endpoint hardening, vulnerability remediation and patching among them.

In self-managed environments, internal teams own much of that work directly. With managed services, more responsibility shifts to the provider, which changes what customers need to evaluate during procurement and ongoing risk review. Customers need current evidence about how vulnerabilities are identified, remediated and tracked, along with documentation describing the security controls operating beneath the managed service.

AI changes the data-security picture because sensitive information is no longer only queried and returned. It can also be retrieved as model context, passed between tools, transformed into new outputs and written into downstream systems, all within the same workflow. As Snowflake Chief Security and Trust Officer Mayank Upadhyay puts it, “The biggest mistake organizations can make is thinking AI security is only about securing the model.”

Protecting workflows from AI security risks requires following the data as well as the identity behind each request. Teams need to know what information the AI system receives, which controls apply when it queries or calls a tool, where outputs are written and whether any step creates a new copy outside the original governance boundary.

Identify whose permissions apply

AI agents and retrieval systems still rely on identity and access mechanisms, but a single workflow can involve multiple requests — for example, querying data under delegated user permissions, calling another service with a service identity and writing a result to a separate system. Security teams need to understand which identity and permissions apply at each step.

Teams must be able to answer:

• Which identity governs the data query?
• Which permissions are evaluated?
• What happens when the agent calls another tool?
• Does that tool operate under the user’s authorization, the agent’s service identity or a different credential entirely?

The answers to those questions determine what the agent can reach. For example, an agent answering a question about customer churn might query governed sales data under the user’s permissions, then call another service using a service account. Those two actions are subject to different authorization rules, even though they happen within the same run.

Keep controls in force across tool calls

Agent workflows often span several systems. A query retrieves data from one source, a tool call sends information to another service and a downstream step may write a result into a separate store. Each transition is a security decision point.

A tool shouldn’t inherit broader permissions simply because an agent invoked it. Teams need to understand which credential is used for each call and whether authorization is reevaluated when the workflow crosses into another system.

This is especially important when agents can take actions rather than only return text. The ability to query a table and the ability to update a record, send a message or trigger another application should be governed separately.

Control what data the AI system receives

AI systems should receive only the data the current request is authorized to use. Those restrictions need to be enforced at a trusted control point that every relevant access path passes through — whether that’s the governed data layer, an authorized gateway or another policy enforcement point.

The same principle applies to context supplied to the model. Retrieval systems and agent workflows should pull from sources the requesting identity is allowed to use, with sensitive fields filtered or masked according to policy. That doesn't always happen automatically: many retrieval services, including search indexes built for AI applications, run under a service identity rather than the end user's. In those cases, teams need to limit what gets indexed and apply per-user filtering in the application itself.

When data is written into another system, however, the destination’s controls take over. A governed query doesn’t automatically govern a new copy created downstream.

Protect against AI-specific attack paths

AI introduces attack techniques that target identity and access risks. Prompt injection attempts to manipulate an AI system’s instructions or tool use, potentially causing it to reveal data or perform actions outside the intended workflow. Model poisoning targets the data or processes used to train, fine-tune or otherwise adapt a model. Other attacks focus on extracting sensitive information from models, retrieval systems or the applications around them.

Frameworks from organizations such as OWASP and MITRE can help teams map these threats and design defense-in-depth controls across the application, model, data and tool layers.

Watch for shadow AI and uncontrolled copies

Some of the most immediate AI data-security risk comes from data leaving governed systems altogether. Shadow AI describes a familiar data-security issue: once sensitive data moves into an unmanaged tool or store, the organization has to discover and secure that copy separately. For example, an employee who uploads a customer file to an unapproved AI service has created a new copy outside established access controls, monitoring and retention policies.

The categories of data security solutions tend to overlap, but most are built around a particular part of the problem: controlling access, protecting sensitive values, finding exposed data or detecting how data is being used.

Identity and access management

Identity and access management (IAM) systems govern who or what can authenticate and which resources those identities are allowed to use. Related technologies include privileged access management, RBAC and entitlement-management tools that help teams reduce excessive permissions and review access over time.

Data discovery, classification and DSPM

Security teams can’t protect sensitive data they can’t see. Discovery and classification tools locate sensitive data and assign categories such as PII or financial data. Data security posture management (DSPM) tools extend visibility by continuously discovering data stores, identifying and classifying sensitive information and exposing conditions such as excessive permissions, misconfiguration and shadow data.

Data protection and privacy controls

These solutions reduce what authorized users and applications can see or expose. Depending on the platform, that can include dynamic data masking, tokenization, de-identification, row- and column-level policies and privacy-enhancing technologies such as clean rooms.

Encryption and key management

Encryption protects data while it’s stored or transmitted, while key-management systems control the cryptographic keys used to encrypt and decrypt it. Some organizations also use hardware security modules or customer-managed key models when they need additional control over key custody.

Data loss prevention and activity monitoring

Data loss prevention (DLP) tools look for sensitive information moving through channels such as endpoints, email, cloud applications and file transfers. Database and data activity monitoring tools focus more directly on how sensitive data is queried, changed or exported, giving security teams evidence they can use for investigation and policy enforcement.

Protecting sensitive data is only part of the job when regulations or industry standards apply. Organizations also need to demonstrate who had access, which controls were enforced and how incidents were handled when protected data was involved.

That’s where data security and compliance meet.

Frameworks and regulations such as GDPR, PCI DSS, CCPA, SOX and ISO 27001 differ substantially in scope and requirements. Depending on the obligation, organizations may need to demonstrate controls around access, protection of sensitive information, logging, retention, incident response or breach notification. In healthcare, for example, protected health information (PHI) carries specific privacy and security obligations under HIPAA.

Operational records make those requirements easier to substantiate. Access logs show who queried protected data. Policy records show which masking or access rules applied. Incident timelines document when suspicious activity was detected, what investigators found and when containment occurred. A team trying to determine who could access a table during the previous quarter shouldn’t have to assemble the answer from old tickets, screenshots and employee recollections.

Breach notification is another example. Different regulations impose different definitions, thresholds and reporting timelines, so incident-response teams need enough evidence to determine what data was involved, whether unauthorized access or disclosure occurred, and which obligations apply.

Compliance depends partly on control design and partly on recordkeeping. The security system needs to enforce the rule and leave enough evidence to show that it did.

Snowflake brings security controls into the governed data layer, so teams can apply policy closer to the data rather than recreating the same logic in every consuming tool.

Keep policy close to governed data

With Horizon Catalog, teams can use classification, tags and governance metadata alongside controls such as dynamic data masking, row access policies, projection policies and aggregation policies. Access History provides a record of how governed data is queried, which can help with investigation, review and audit documentation.

Reduce unnecessary copies

Secure Data Sharing lets consumers access shared data without receiving a conventional copy that they must ingest and manage separately. Snowflake Data Clean Rooms extend that model to governed collaboration across organizations, reducing the need to exchange raw copies of sensitive data.

Strengthen encryption and key control

Snowflake encrypts data at rest and in transit and supports customer-managed key options, including Tri-Secret Secure (available with Business Critical Edition), for organizations that need additional control over key management.

Monitor posture and access

Trust Center is designed to surface security findings and remediation guidance for Snowflake environments, helping teams identify configuration and posture issues alongside access activity.

Govern data used by AI

Horizon Catalog helps apply governance to data and business context used by AI workloads, including agents. Horizon Context builds on that foundation with governed business definitions through semantic views (additional capabilities are currently in public and private preview). For retrieval-based applications, which run with the service owner’s permissions, teams should scope indexed content and apply application-level filters for per-user access.

These capabilities provide enforcement points, visibility and governance mechanisms, while security and data teams still determine which data is sensitive, who should have access and which policies should apply. (Feature availability varies by Snowflake edition; see Snowflake editions for details.)

Design for change

Data use will keep changing. New applications, partners and AI systems will continue to appear, and sensitive data will continue to move with them.

A security model that depends on recreating controls for every new consumer will keep accumulating gaps. Designing for governed access, fewer unnecessary copies and visible enforcement gives teams a better chance of keeping security consistent as the data estate evolves.