Behavior Policies for Employee Monitoring & DLP: A Field-Tested Practical Guide
This guide is a field-tested catalog of behavior policy scenarios for HR / InfoSec / IT teams running User Activity Monitoring (UAM) and DLP platforms (Teramind, ActivTrak, native DLP modules, etc.). It's written to be product-agnostic — every example maps directly onto the "trigger → condition → action" logic that virtually every UAM/DLP tool uses.
1. Why Behavior Policy Logic Matters
Most companies, after deploying a UAM/DLP product, end up in one of two places: either no policies run at all (the tool just records data passively), or they enable 3-5 copy-pasted templates from the internet and forget about them. Neither works in practice:
- Without policies, the product becomes a "post-incident review" tool — a data leak is discovered after it already happened.
- Generic templates, uncalibrated to the company's real workflows, either cause alert fatigue (a flood of false positives) or completely miss critical scenarios.
The right approach is to think of policies in three layers:
- Block — Irreversible, clearly-violating actions (e.g., dumping a customer database and emailing it to a personal address).
- Warn / Alert + Log — Suspicious but potentially legitimate-in-context behaviors (e.g., large file transfers, off-hours access).
- Log only — Events with no immediate action needed but valuable for later analysis (e.g., creating a
.ziparchive).
Deciding which layer a policy belongs to upfront matters both for legal risk and employee experience. A "block everything" approach is usually disabled within two weeks due to the flood of IT complaints it generates.
Anatomy of a Behavior Policy
Regardless of platform, a behavior policy consists of:
| Component | Description | Example |
|---|---|---|
| Trigger | The monitored event type | File copy, URL visit, process start, email send |
| Condition | Filter that narrows the trigger | device = removable, recipient domain != company.com |
| Target | User/group the policy applies to | Whole company, Finance only, managers only |
| Action | What happens when triggered | Block, Warn, Alert (email/Slack), Log, Kill Process, Lock Screen |
| Exception | Prevents false positives | "Don't warn IT staff for PowerShell usage" |
Now let's expand this logic into categories with real-world scenarios.
2. Data Loss Prevention (DLP) Policies
This category answers "how does data leave the company?" Leak channels generally fall into four buckets: removable media, cloud storage, email, screen capture/recording.
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Email containing personal data | Email body/attachment matches a national ID, IBAN, or credit card regex + recipient domain is external | Block + Alert (InfoSec) | If the regex is too strict it'll match invoice numbers too — run it in "log only" mode for a week before going live and tune thresholds based on real hit rates. |
| Bulk copy to USB | device = removable + file copy count > N within 5 min |
Alert + on-screen warning | Targeting bulk copying instead of single-file copying is the practical way to separate legitimate use (e.g., copying a presentation) from exfiltration. |
| Upload to cloud storage | URL contains (drive.google.com, dropbox.com, wetransfer.com, mega.nz) + upload event |
Warn (first time) → Block (repeat) | Escalating action lets you distinguish "accidental one-off" from "systematic leak." |
| Screenshot in a sensitive window | Process = SnippingTool.exe, obs64.exe, bandicam.exe + active window = ERP/CRM |
Alert + flag the screen recording | Process-based detection alone isn't enough — without "which window was active," you'll also flag normal usage. |
| Encrypted archive creation | .zip/.rar/.7z creation + file size above threshold |
Log only | Shouldn't trigger an alert by itself, but is valuable as a reference point when reconstructing a data-leak timeline. |
| (New scenario) Sending a corporate file to a personal device via AirDrop/Nearby Share | Process = AirDrop/Nearby Share + file originates from a corporate share |
Alert | An increasingly common channel in hybrid work environments that most DLP tools miss entirely. |
| (New scenario) Sensitive tab open during screen sharing | Video conferencing app (Zoom/Teams) screen share active + browser tab tagged Finance/HR |
Warn (real-time notification to user: "sensitive content is being shared") | Leaks via meeting recordings usually go unnoticed; a real-time nudge is low-cost and high-impact. |
3. Insider Threat / Suspicious Behavior Policies
This category tries to catch "deviation from normal." A single event is usually insufficient — patterns matter.
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Off-hours access | Login outside working hours + accessed resource tagged "sensitive" | Alert (sensitive resources only) | Alerting on all off-hours logins becomes meaningless at companies with significant flexible-work populations. Narrowing the target is essential. |
| Excessive copy-paste | Clipboard copy event count > threshold / 5 min | Alert | This threshold needs to be set high for developers and data analysts, otherwise the team generates constant false positives. |
| Repeated access to the same sensitive file | Same user accesses the same file > N times in one day | Alert + daily summary report | Meaningful for files like payroll/salary sheets where "why is this being opened repeatedly" is a fair question. |
| Remote access without VPN | RDP/SSH session + VPN process not running | Block or Alert (policy-dependent) | The most common false-positive source in the field — some legitimate third-party access also looks like this; an exception list is essential. |
| (New scenario) Temporary tightened policy for users in their notice period | User profile is added to a "Notice Period" group → DLP policies for USB, cloud, external email automatically tighten to Block | Block + Alert HR | The pre/post-resignation window is statistically the highest-risk period for data exfiltration. Automating this via group membership — rather than relying on someone to remember — eliminates the "forgot to do it" risk. |
| (New scenario) Concurrent sessions from geographically distant locations | Two active sessions, GeoIP distance > X km, time gap < 1 hour | Alert + force re-auth | The classic "impossible travel" scenario; ideally cross-referenced with SSO/identity logs, but UAM data alone gives an early signal too. |
4. Productivity & Performance Policies
A sensitive area: the goal isn't to create a surveillance state, it's to make patterns visible. Most actions here should be reports, not blocks.
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Category-based app usage | App category = Entertainment/Social, during work hours, total time > threshold | Weekly summary report | Showing department-level trends instead of individually "catching" people drastically reduces friction with HR. |
| Idle time analysis | Idle time > 15 min, recurring daily pattern | Flag (sent to the employee themselves, not the manager — "you were inactive for X hours today") | Self-feedback is met with far less resistance than manager-facing reports and changes behavior faster. |
| (New scenario) Meeting load vs. "deep work" time | Calendar integration + app usage data: more than 60% of the day in meetings + frequent app-switching during the remaining time | Weekly "focus score" report | Reframes productivity analysis from "how much is the employee working" to "is the employee given room to focus" — a much more valuable framing for leadership. |
| (New scenario) Tool redundancy detection | Same topic discussed across multiple tools (e.g., the same conversation happening in Slack, Teams, and email) | Monthly "tool consolidation" report | Not a monitoring policy per se, but a strong example of using UAM data for cost optimization — useful when presenting to management. |
5. Compliance (KVKK/GDPR) Policies
For companies operating under Turkey's KVKK (or GDPR), this category is no longer "nice to have" — it's something auditors actively ask about.
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Personal data shared externally | File contains national ID/IBAN/phone regex + recipient is not @company.com |
Block + Alert (Data Protection Officer) | Provides concrete technical-measure evidence for data security obligations under KVKK Art. 12 — useful during audits. |
| Policy acknowledgment tracking | KVKK/InfoSec policy document not opened within N days of assignment | Automatic reminder | Simple, but automates the "awareness training evidence" that auditors frequently request. |
| (New scenario) Risk of data collection without a privacy notice | A new form/survey tool (Google Forms, Typeform, etc.) is opened and field names like "full name," "phone," "national ID" are detected in its content | Alert (to Legal/DPO, without blocking the user) | Employees creating well-intentioned but non-compliant "shadow forms" is a common, hard-to-spot risk. |
| (New scenario) Access to data past its retention period | Files in a folder tagged with a "destruction date" are still being opened/copied after that date | Alert + route into the automated deletion workflow | Operationalizes the "data minimization" principle that most companies otherwise only have on paper. |
6. AI Tool Policies (ChatGPT, Copilot, Midjourney, etc.)
The fastest-growing risk category since 2023 — and one that most companies still have zero policies for.
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Source code pasted into an AI chat tool | Active app = IDE (VS Code, JetBrains) + clipboard paste target = chat.openai.com / claude.ai / gemini.google.com | Alert (not Block — to avoid disrupting developer workflow) | Outright blocking usually pushes usage to "shadow AI" (personal devices, no VPN). Alert + awareness is more sustainable. |
| Corporate document uploaded to an AI tool | File upload event + destination domain in the AI tools list + file tagged "Confidential" | Block + Alert | If you don't have a DLP classification layer, this can start as a simple filename/extension-based rule. |
| (New scenario) Corporate API key pasted into a prompt | Text input/paste event + content matches regex (sk-, AKIA, ghp_, JWT format, etc.) + destination = browser/AI tool |
Block + Alert DevSec | Developers pasting an entire .env file while asking an AI to "fix this error" is one of the most common AI-related leak patterns observed in the field. |
| (New scenario) Installing an unapproved AI browser extension | Extension store install + extension permissions include "read all tabs" | Alert + IT approval workflow | AI browser extensions (summarizers, autofill, etc.) often send full page content to third-party servers; employees install them as "productivity tools" without realizing this. |
| Defining an approved AI "safe zone" | Company-hosted/licensed AI tool (e.g., Microsoft Copilot for Business, ChatGPT Enterprise) | Add to exception list (policy doesn't trigger) | The goal isn't to block AI usage — it's to keep data inside corporate boundaries. Making this distinction explicit dramatically reduces user pushback. |
7. Developer / IT Security Policies
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| SSH/private key exfiltration | Filename/extension .pem, .ppk, id_rsa + USB/cloud/email destination |
Block + Alert | One of the highest-impact, lowest-false-positive rules observed in the field — almost no legitimate scenario requires these files to leave the org. |
| Database dump operation | Process = mysqldump/pg_dump or filename dump.sql/backup.bak + followed by external transfer |
Alert + Log | "Taking a dump" alone isn't suspicious (backup routines exist) — the real signal is dump + external transfer combined. |
| Unauthorized PowerShell/CMD usage | Process = powershell.exe/cmd.exe + user group ≠ IT/Admin |
Alert | The most common "self-triggered alert" in the first weeks is IT forgetting to add their own accounts to the exception list. |
| (New scenario) Access to production environment variables | Opening/editing a .env file + path contains production/prod + user not in "DevOps" group |
Block + Alert | A cheap way to catch cases where the access matrix is correct on paper but leaky in practice (shared servers, shared accounts, etc.). |
| (New scenario) Deploy attempt outside CI/CD pipeline | git push or running a deploy script, branch = main/production + source machine is not a CI runner |
Alert DevOps | In teams with an "emergency manual deploy" culture, making these events visible (rather than fully blocking them) is invaluable for post-mortems. |
8. Disaster Recovery / Anomaly Detection Policies
| Policy | Trigger / Condition | Action | Field Note |
|---|---|---|---|
| Mass file deletion | File deletion count > threshold / 5 min | Alert + (if possible) make the directory read-only | Ransomware's earliest signs are usually not "file modification" but a burst of file renaming + deletion. |
| Tampering with backup folders | Path contains /backup + delete/modify event |
Block | A significant portion of ransomware attacks target backups first; should be paired with a "read-only / immutable snapshot" strategy for these folders. |
| (New scenario) Burst of files with encryption-like extension changes | Many files change extension in a short time (e.g., .docx → .locked/.encrypted) |
Alert (critical priority) + trigger network-isolation workflow for the device | Simpler than classic "entropy increase" detection but still provides early warning, giving the SOC team minutes to respond. |
9. Industry-Specific Scenarios
Call Centers / Customer Support
- Screen recording software opened during a customer call → Block
- Customer personal data copied into a non-approved app (Notepad, Excel) → Alert
- (New) A card number matching the PCI-DSS pattern typed in plaintext into chat/ticketing → Block + suggest auto-masking
Manufacturing / SCADA / OT
- Unauthorized user accessing a SCADA terminal → Block
- PLC configuration files modified → Alert OT Admin
- (New) Attempted software install via USB on a production-line PC expected to be air-gapped → Block + notify physical security
Healthcare
- Patient data file exported externally → Block
- DICOM/MRI files emailed → Block
- (New) Patient record accessed by staff outside the relevant doctor/department ("curiosity access") → Alert + monthly access audit report
10. Five Practical Lessons From Rolling This Out
-
Start in "log only" mode. Putting a new policy directly into Block/Warn mode floods IT with complaints in week one. Run silent logging for 1-2 weeks to see the real trigger rate, then calibrate thresholds accordingly.
-
Treat the exception list as an ongoing process, not a one-time setup. Groups like IT, managers, and external auditors change over time. A quarterly "exception list review" cadence prevents both security gaps and unnecessary alerts.
-
Match the action to the actual risk. A "block everything" approach pushes employees to find workarounds (taking photos with personal phones, using personal devices, etc.) — which kills visibility entirely. Reserve Block for clear-cut violations; use Warn/Alert for medium-risk scenarios.
-
Design policies with HR and Legal, not just IT. "Productivity" and "behavioral anomaly" policies in particular intersect directly with employee rights. Transparently communicating the existence of these policies to staff (typically via an Acceptable Use Policy document) is both a legal and ethical necessity.
-
Frame reporting around trends, not "gotchas." Instead of sending managers a list of "user X did Y," present department-level trends (e.g., "cloud upload attempts in Finance increased 40% this month") — this is met with far less resistance and tends to point at root causes (e.g., a missing workflow) rather than individuals.
Closing
Rather than copying this entire catalog and deploying it all at once, I'd recommend picking your top 3-5 highest-risk scenarios and walking each one through the "log only → alert → block" maturity curve. Behavior policies aren't a "set and forget" configuration screen — they're a living document that needs regular review as the company's workflows evolve.
This guide generalizes lessons learned from operating a Teramind-based UAM/DLP platform in a 1,500+ user enterprise environment. The scenarios described do not reflect any specific organization's actual configuration; they are provided for educational and reference purposes.