12 Data Security Controls: Nine You Have, Three You Don't

Most organizations have a data security controls list. They run through it during audits, point to it during board briefings and check off the same boxes they checked off three years ago. Then a breach happens anyway.

The problem isn't effort. It's that the frameworks most security teams rely on were written before the threat landscape changed. None of the top-ranking controls lists from the industry's biggest names include a single control for AI. Not one accounts for employees pasting customer records into ChatGPT, or for autonomous agents querying databases without a human initiating the action. Those aren't edge cases in 2026. They're daily occurrences in nearly every enterprise.

This post covers 12 data security controls: the foundational ones every program needs and three that most frameworks still don't list. Each section covers what the control actually needs to do, not just what it's called.

Start with What You Can See

1. Data discovery and classification

Every other control on this list depends on this one. You cannot enforce policy on data you haven't found. You cannot classify data you haven't inspected. And you cannot make access decisions that are proportionate to risk if you don't know which data carries the most of it.

Data discovery maps where sensitive data lives across cloud storage, SaaS applications, on-premises repositories and collaboration platforms. Classification assigns labels based on content, context and regulatory sensitivity, not just file type. That distinction matters. A log file and a payroll export are both text files. The risk profile is entirely different.

AI-powered classification is now the practical standard for organizations with data volumes that make manual review impossible. The key requirement is accuracy: high false-positive rates mean security teams spend their time chasing noise instead of real exposure. Classification labels also need to travel with the data and drive enforcement downstream. A classification that lives only in a spreadsheet isn't a security control.

Data security posture management (DSPM) is the technology layer that makes discovery and classification operational at enterprise scale, continuously scanning environments and surfacing exposure as it changes.

Know Who Can Reach What

2. Data access governance

Access control gets discussed in almost every security framework, but most implementations stop at a one-time configuration of identity and access management (IAM) policies. That's not the same as data access governance.

Governance is ongoing. Permissions drift. Employees change roles, contractors leave and their access lingers, and folders get shared in ways that made sense in the moment but create persistent exposure. Overshared directories and inherited permissions are among the most common conditions that make a breach significantly worse than it needed to be.

Effective data access governance combines access reviews, entitlement rightsizing and data classification context to make access decisions defensible. Knowing a user has read access to a folder is one thing. Knowing they have read access to a folder containing 40,000 regulated records they've never touched is what makes that access a risk worth addressing.

The practical goal is least privilege as an enforced reality, not a stated principle.

Stop Data Before It Leaves

3. Data loss prevention

Data loss prevention (DLP) is the enforcement layer that turns classification policy into action. It applies rules across the channels where data actually moves: endpoint, email, web and cloud applications. When sensitive data hits a policy threshold, DLP can block the transfer, coach the user, log the event or escalate for review.

The architecture decision that separates mature DLP programs from fragile ones is unified policy management. Siloed tools, one for endpoint, one for email, another for cloud, mean policies don't stay consistent across channels. An employee blocked from emailing a file can often upload it to a personal cloud drive if the enforcement isn't coordinated.

Classification depth also matters. Coverage of 1,700 or more classifiers isn't a marketing number. It's what determines whether the system recognizes proprietary source code, not just credit card numbers. High false-positive rates are a policy design problem, not an inherent limitation of DLP technology. A well-tuned program flags real incidents without generating enough noise to cause alert fatigue.

Forcepoint DLP delivers unified policy enforcement across every major data movement channel, with AI-powered classification built in to reduce false positives and keep incident queues focused on what matters.

Email Is Still the Biggest Exit Door

4. DLP for email

Outbound email is the most common channel for both accidental and intentional data loss. It deserves its own entry on this list because most organizations underinvest in email-specific enforcement even when they have a broader DLP program in place.

The risk profile is distinct. Email is conversational, fast and easy to misaddress. A single mistaken recipient can expose a regulated record to someone outside the organization. Intentional exfiltration via email is also common because it looks like normal business activity until someone examines the content.

Effective email DLP provides agentless enforcement on platforms like Microsoft 365 Exchange and Google Workspace, with pre-built policy templates covering major regulatory requirements and the ability to inspect attachments, not just message bodies. It needs to work on outbound traffic without requiring routing changes that create latency or operational friction.

Forcepoint DLP for Email extends the same classification engine and policy framework that governs endpoints to outbound email, with coverage across M365 Exchange, Google Workspace and other platforms, and no agent required on user devices.

Encryption Isn't Optional, It's a Floor

5. Encryption at rest and in transit

Encryption is foundational, but it's worth being precise about what it does and what it doesn't. Encryption at rest protects stored data from being readable if storage is accessed without authorization. Encryption in transit protects data moving between systems from interception or tampering. Both are necessary. Neither replaces classification or access control.

The organizational governance question matters as much as the technical implementation. Who manages encryption keys? Where are they stored relative to the data they protect? What happens when a key management system fails? These are the questions that expose whether encryption is a real control or a checkbox.

Strong algorithms and authenticated protocols are the baseline. The control lives in how consistently encryption is applied across environments, including development and test environments where real data sometimes ends up without the same protections applied to production.

The Perimeter Is Your Cloud

6. Cloud data security

Data doesn't live in one place. It moves into SaaS applications, gets stored in cloud environments and gets shared through collaboration platforms that were never designed with data security as a primary concern. The shared responsibility model that governs cloud security creates a gap most organizations underestimate: the cloud provider secures the infrastructure, but the organization is responsible for securing its own data within it.

Cloud data security requires visibility into what data exists in cloud environments and SaaS applications, control over how that data moves and policy enforcement that reaches into the cloud without requiring on-premises infrastructure to inspect cloud traffic.

A cloud access security broker (CASB) provides the visibility and control layer for SaaS environments. Combined with DSPM for posture management of data at rest, these tools address the blind spots that make cloud environments a common source of exposure in breach investigations.

Forcepoint Cloud App Security gives security teams full visibility into data across SaaS applications and enforces DLP policies in cloud environments without requiring changes to existing network architecture.

Behavior Tells You What Logs Cannot

7. Insider risk management and behavioral monitoring

Most data breaches involve someone who already has authorized access. That's why perimeter controls and access management, as important as they are, don't close the full risk picture. Insider risk programs address what happens after access is granted.

The distinction between insider threat and insider risk matters for program design. Threat implies intent. Risk includes the negligent employee who mishandles sensitive data without meaning to, the contractor whose access outlasted their engagement and the well-intentioned engineer who uploads source code to a personal device for convenience. Most incidents involve risk, not threat. Programs that treat every anomaly as a potential malicious actor generate friction without catching the cases that are actually costly.

Behavioral monitoring establishes baselines for how individuals interact with data and surfaces deviations worth investigating. Risk scoring helps prioritize which deviations require immediate response. The goal is earlier detection: according to IBM, malicious insider attacks take an average of 194 days to identify, a window that reflects how invisible these incidents are without behavioral analytics in place.

Risk-adaptive controls go one step further. Rather than applying the same enforcement policy to every user regardless of context, they tighten controls automatically when risk rises and relax them when it falls, scaling protections to the actual risk level without requiring manual intervention at each step.

Zero Trust Isn't a Product, It's a Posture

8. Zero trust access

Zero trust is frequently sold as a product category. It isn't. It's an architectural principle: no user or system receives implicit trust based on network location. Every access request is verified. Every session is evaluated against context: user identity, device posture, location, data sensitivity and behavioral signals.

Applied to data security, zero trust means access decisions are continuous, not one-time grants at login. A session that starts legitimately can be stepped down or terminated if conditions change. It means permissions are scoped to specific tasks, not to broad resource categories. And it means the assumption of breach is built into the architecture, so controls exist to limit what a compromised account can reach.

Zero trust is the governance philosophy that makes the controls above coherent. Discovery and classification define what data is sensitive. Access governance determines who can reach it. DLP enforces what they can do with it. Behavioral monitoring watches for signals that something has gone wrong. Zero trust is the framework that holds those pieces together.

Compliance Requires Evidence, Not Just Intent

9. Audit logging and compliance reporting

Regulators don't accept declared policy as evidence of control. They ask for logs, access records, incident histories and documentation of how controls were applied to specific data types in specific environments. Organizations that rely on manual documentation to satisfy these requirements spend significant time on compliance work that could be automated.

A defensible audit trail captures who accessed what data, when, from where and what they did with it. It logs policy violations alongside the context that makes them interpretable. It produces exports that map to the specific requirements of relevant frameworks, whether that's GDPR, HIPAA, PCI DSS or emerging AI regulations.

Automated compliance reporting reduces the lift while improving accuracy. Manual audit processes introduce gaps; automated logging captures events continuously. The result is an audit trail that exists as a byproduct of normal security operations, rather than as a separate documentation effort that begins when an audit is announced.

The Three Controls Every Framework Is Missing

Every control above appears in some form in the frameworks that major security vendors publish. The three below do not. They represent the gap between a data security program designed for 2020 and one that reflects how data actually moves in 2026.

10. Shadow AI governance

Employees are using AI tools that security teams haven't approved. In most organizations, the full inventory of those tools is unknown. According to Gartner, 69 percent of organizations suspect employees use prohibited generative AI tools. The data they're pasting into those tools, customer records, source code, credentials, financial data, doesn't stay within the session. Free and consumer-tier AI services have historically retained user inputs and routed them through subprocessors the organization never approved.

Traditional discovery methods don't surface shadow AI the way they surface unauthorized SaaS applications. AI tools route through the browser like ordinary web traffic. An employee using a personal ChatGPT account looks identical to an employee using an approved web application unless endpoint-level detection is specifically designed to identify it.

This control requires three things: a complete inventory of AI tools in use across the enterprise, risk-ranked by category and threat profile; enforcement that distinguishes between personal and corporate accounts on the same platform; and the ability to act on that inventory inline, without requiring network architecture changes or new proxy infrastructure.

Forcepoint AI Data Security identifies every unsanctioned AI tool in the environment, from personal AI accounts and browser extensions to MCP clients and vibe-coding tools, and categorizes each by risk using Forcepoint X-Labs' AI application database. Security teams can block shadow AI with granular allow, restrict or block decisions enforced inline, in real time.

11. DLP for sanctioned AI apps

Approving a tool is not the same as governing it. Employees paste sensitive data into ChatGPT Enterprise, Microsoft 365 Copilot, Claude for Enterprise, AWS Bedrock and other approved AI platforms every day. According to Gartner, 33 percent of employees admit to inputting sensitive information into unapproved AI tools, and that figure covers only what employees self-report. Standard DLP policies were never designed to inspect AI prompts, responses or file uploads. The interaction happens in a browser session. The data is submitted as natural language. Legacy DLP has no framework for treating that as a governed data transfer.

The architectural challenge is real. Most tools that attempt to inspect AI interactions require reclassification of existing data assets or the deployment of new infrastructure before enforcement can begin. For organizations with mature DLP programs, that's a significant rebuild. The better approach extends existing classification policies directly to the AI interaction layer without requiring organizations to start over.

This control needs to cover the full interaction: prompts in, responses out and file uploads, not just what leaves the endpoint. It needs to log every interaction with full identity attribution for compliance purposes. And it needs to scale with the AI adoption curve, which is moving faster than most security programs can respond to manually.

Forcepoint AI Data Security brings AI interactions into the existing DLP framework. Classification policies apply to prompts and uploads across approved AI platforms from day one, with no reclassification required. Security teams can prevent data leaks in AI apps using 2,000-plus out-of-the-box classifiers, with compliance-ready exports covering EU AI Act, NIST AI RMF and more than 80 regulatory regions.

12. Agentic AI behavioral controls

AI agents now operate in enterprise environments without a human initiating each action. They query databases, read email, modify records, call APIs and trigger downstream workflows autonomously. According to Rubrik Zero Labs, non-human identities now outnumber human users 82-to-1 in enterprise environments. Gartner projects that 40 percent of enterprise applications will feature task-specific AI agents by end of 2026, up from under 5 percent in 2025.

Standard DLP doesn't inspect agent calls. Standard IAM wasn't designed to right-size permissions for non-human actors that behave dynamically across tool chains. Most agents deployed in enterprises today inherit the permissions of the user who deployed them, which means an over-permissioned human creates an over-permissioned agent with the same blast radius but none of the accountability. A compromised or misdirected agent can exfiltrate data, modify records or trigger downstream workflows in seconds, before any alert surfaces.

This control requires identity attribution on every agent action, linked to both the agent and the user who triggered it. It requires runtime enforcement between agents and the applications they call, not monitoring after the fact. And it requires human-in-the-loop approval gates for high-sensitivity operations: writes, deletes and access to regulated data categories.

Forcepoint AI Agent Gateway sits between every agent and the applications it calls. No agent holds a standing credential. Every call is inspected before it executes. Sensitive writes and deletes require human approval. Every action is logged with full identity attribution, producing the audit trail regulators will ask for before most organizations know they need one. Learn more about Forcepoint's approach to agentic AI security.

Controls Work When They Work Together

The failure mode that makes breaches expensive isn't usually a missing control. It's controls that don't share context. Classification that doesn't inform DLP enforcement. DLP that doesn't feed behavioral analytics. Behavioral analytics that can't see what AI agents are doing. Each gap is a place where an incident can develop before any individual control surfaces it.

Effective data security programs treat these 12 controls as a connected system, where posture insights inform enforcement decisions, behavioral signals update risk scores in real time and compliance reporting is generated automatically rather than assembled manually when an audit begins. That's what it means for data security to be self-aware: it adapts to changing conditions rather than waiting for a human to notice something is wrong and respond.

Forcepoint Data Security Cloud delivers these controls from a unified platform, with shared classification intelligence, coordinated policy enforcement and continuous monitoring across the environments where data lives and moves today.

Frequently Asked Questions

What are data security controls?

Data security controls are the technical measures, policies and procedures an organization uses to protect sensitive data from unauthorized access, loss or misuse. They include technologies like data loss prevention and encryption as well as governance practices like access reviews and audit logging. Effective controls work across the full data lifecycle, from discovery and classification through enforcement, monitoring and incident response.

What is the difference between a data security control and a data security procedure?

A control is a technical or administrative mechanism that enforces a security outcome, such as blocking a file transfer or encrypting data at rest. A procedure is the documented process that governs how that control is configured, maintained and reviewed. Controls without procedures drift out of alignment with organizational risk. Procedures without controls are policy documents that don't enforce anything. Both are required for a defensible program.

What data security controls are required for GDPR compliance?

GDPR doesn't prescribe specific technologies, but it requires organizations to implement appropriate technical measures to protect personal data. In practice, this means encryption, access controls, audit logging, data minimization practices and breach detection capabilities. Data security posture management supports GDPR compliance by identifying where personal data is stored and whether controls are in place and correctly configured.

What controls protect data in AI applications?

Three controls address AI-specific data risk: shadow AI governance, which identifies and enforces policy on unsanctioned AI tools; DLP for sanctioned AI apps, which extends existing policies to approved AI platforms like ChatGPT Enterprise and Microsoft 365 Copilot; and agentic AI behavioral controls, which govern autonomous agents operating in enterprise environments. Most security frameworks don't yet list these as distinct controls, which is why AI-related incidents are both common and expensive to contain.

How many data security controls does my organization need?

The right number depends on the organization's data environment, regulatory obligations and risk tolerance. A useful starting point is ensuring coverage across five categories: visibility (discovery and classification), access (governance and least privilege), enforcement (DLP across channels), detection (behavioral monitoring and audit logging) and AI (shadow AI, sanctioned AI apps and agentic systems). Gaps in any category create conditions where controls in the others are less effective than they would otherwise be.