How to Set Up Inline DLP Policy for Web, Email & SaaS in Cato

Setting up inline DLP in Cato takes three objects in a fixed order: pick your data types under Security > Data Types & Profiles, group them into a Content Profile, then write Data Control rules under Security > App & Data Inline that apply that profile to applications and activities. Start every rule in Monitor, read a fortnight of events, then switch to Block. TLS Inspection must already be enabled, because inline DLP inspects the decrypted payload — and you need the DLP license on top of CASB.

That is the whole mechanism. The rest of this guide is the detail that decides whether it works in production or generates two hundred false positives and gets switched off.

What does inline DLP in Cato actually cover?

Cato has two DLP enforcement points, and confusing them is the most common planning mistake.

Both use the same data types and content profiles, which is the useful part: build your definitions once and apply them in either policy.

Where email fits. Inline DLP covers web destinations, so webmail — Gmail, Outlook on the web, anything accessed over HTTPS — is inspected as ordinary web traffic, and the content profile's supported file categories include email and message formats, so .eml, .msg and .pst attachments are scanned. What inline DLP does not do is sit in your mail flow like an SMTP gateway, and it does not inspect mailboxes at rest. If your requirement is "scan everything leaving our tenant by email," that is the API connector for Microsoft 365 or Google Workspace, not an inline rule. Worth settling before you promise anyone email coverage.

What do you need before you start?

• CASB license for the Application Control policy, plus the DLP license to enable Data Control rules inside it

• TLS Inspection enabled on the traffic you intend to inspect — see enabling TLS inspection in Cato

• QUIC and GQUIC blocked in the Internet Firewall, since QUIC cannot be TLS inspected

• A firewall rule with event tracking that matches the traffic you expect DLP to inspect

• Admin rights over Security policies and Data Types & Profiles

• An honest answer to "what data would actually hurt us if it left" — this is the part no console can do for you

Caution: Do not build this policy on a Friday and leave it in Block. Every step below assumes Monitor first. A DLP policy that blocks legitimate work in week one gets disabled in week two and never comes back.

Why does inline DLP need TLS inspection to work at all?

Cato's DLP content scans are inline and proxy-based, operating on HTTP inspection of the decrypted payload. If the session is encrypted and not inspected, there is no payload to scan — the rule simply never matches, and it looks identical to a misconfigured rule.

Two practical consequences follow. QUIC and GQUIC cannot be TLS inspected at all, so a browser negotiating QUIC to a cloud app escapes DLP silently. And the application must be identified, which requires the client reaching the service by hostname rather than direct IP, with DNS traffic visible to Cato.

Before you debug a single rule, check the TLS Inspection field on the event in Monitoring > Events. A value of 1 means decrypted. A value of 0 explains most DLP failures on its own.

Step 1 — Choose your data types

Go to Security > Data Types & Profiles and open the Data Types tab. The Data Catalog ships with predefined types across these categories:

• Personally Identifiable Information (PII)

• Financial data

• Payment Card Industry Data Security Standard (PCI DSS), covering card data

• Health care, plus HIPAA types relevant only to the USA

• UK National Health Service

• Document classification

• Item identifiers such as postal codes and license keys

The catalog also contains country-specific data types, so check what is available for India before you assume you need custom types for local identifiers.

Each type shows a Threshold — the minimum number of occurrences needed to activate it. Thresholds are your primary defence against false positives. One card number in an email is a refund. Three hundred in a spreadsheet is a breach.

When predefined types are not enough

Custom data types cover what only you can describe — project codenames, internal document markers, client lists, your own ticket ID format. Cato supports:

If your organisation already runs Microsoft Purview labels, start there. Matching an existing label is more reliable than re-describing the same content as keywords, and it keeps classification in one place rather than two.

Step 2 — Build the content profile

1. Stay in Security > Data Types & Profiles and open the DLP Profiles tab.

2. Select Content Profile and click New.

3. Name it for the response you intend, not the data — PII - block and PII - monitor are more useful six months later than PII profile 2.

4. Add your data types.

5. Enable OCR Scan Enabled if screenshots are a realistic leak path. The engine extracts text from images and from images embedded in files, then matches it against the profile.

6. Click Apply, then Save.

Four scanning limits worth knowing before you rely on this:

• Files up to 50 MB are scanned inline. Larger files show a "Bypass By Size" verdict.

• Audio, video and binary files are not supported.

• Embedded documents and images are scanned up to 5 per file. If a file contains more, only the five largest are scanned — so a 40-tab workbook or a deck with twenty embedded images is only partly inspected.

• PNG and JPEG scanning is supported only for the Upload action. Downloads of those formats are not scanned.

Keep profiles separate by intended action. A profile you will block on should be narrow and high-confidence. A profile for monitoring can be broad, because nothing breaks when it fires.

Step 3 — Write the Data Control rules

Data Control rules live in the Application Control policy at Security > App & Data Inline. On older tenants the path reads Security > Application Control, with profiles under Security > DLP Profiles.

Build your baseline in this order, most specific first:

1. Sanctioned apps, monitor only. Your approved Microsoft 365 or Google Workspace tenant with a broad profile in Monitor. This is your visibility layer and it should stay permanently.

2. High-confidence block rules. Card data, access keys and tokens, and anything your regulator treats as non-negotiable, blocked to unsanctioned destinations.

3. Category rules for unsanctioned destinations. Personal file sharing, unsanctioned AI tools, webmail that is not yours.

4. A catch-all monitor rule at the bottom. It tells you what the rules above did not cover.

For each rule, the fields that matter:

• Application — a specific app, a category, or Sanctioned Apps

• Activities — upload, download, file share. Leave it empty and the rule matches every activity, which is too blunt for a Block rule

• Content Profile — the profile from Step 2

• Source — start with a pilot group, never Any

• Action — Monitor now, Block later

• Tracking — enable events, and add notifications for the rules you want to hear about immediately

If your account was created after 25 March 2025, check the default recommended CASB/DLP policy first. It already contains monitoring rules for PII, financial data, access keys and legal data going to generative AI tools. Build on those rather than duplicating them.

Add File Control rules for what content scanning cannot judge

File Control rules, in the same policy, match on file attributes rather than content. Use them when the file type itself is the risk — a database dump, a PST export, a design file — regardless of what is inside.

Fields include Content Type across hundreds of file types, Content Size with a Greater than or At most operator, Activities for upstream or downstream direction, Access Methods for user-agent conditions, Source, Time, and a severity value used in events. Attributes combine with AND or OR.

One constraint to design around: rules configured with Content Size support only the Monitor action. You cannot block on size alone. File Control also requires TLS Inspection to identify files.

Step 4 — Run in Monitor and tune

1. Go to Monitoring > Events and apply the Apps Security preset filter. It shows the DLP profiles triggered, the matched data types and the file attributes.

2. Work through violations individually for the first week. Each one is either a real leak, a legitimate workflow nobody told you about, or a false positive. All three are useful.

3. Raise thresholds on noisy types. Narrow regex that matches more than you meant. Split broad profiles.

4. Only then promote rules to Block.

Give this a fortnight, not a week. One week captures the routine and misses the month-end close, payroll run and board pack — which is precisely when finance and HR move large volumes of sensitive data under time pressure, and precisely the behaviour your policy needs to have seen before it starts blocking.

Step 5 — Decide fail-open or fail-closed, deliberately

By default the Data Control policy fails open: traffic is allowed when a scan cannot complete. Fail-closed blocks traffic that DLP could not finish scanning.

Read this next sentence twice, because it is the single most consequential setting in the policy. Fail-closed applies to all traffic flows, not only traffic matching a Data Control rule, and it applies to all DLP scans for the whole account.

So fail-closed is not a per-rule hardening step — it changes the failure behaviour of your entire estate. It is the right choice for organisations where an unscanned file leaving is genuinely worse than a blocked one, and the wrong choice almost everywhere else. Make it a documented decision with a named owner, not a checkbox someone ticked while tidying up.

How do you verify the policy works?

Test both directions with a seeded file. Build a document that crosses the threshold for one of your data types, attempt the upload from a device in scope, and confirm the block. Then upload a clean file and confirm it passes. A policy tested only on the block case is not tested.

Confirm the event detail. In Monitoring > Events with the Apps Security preset, the violation should name the profile, the matched data types and the file attributes — and show TLS Inspection as 1.

Test the formats that behave differently. Upload a PNG containing sensitive text to confirm OCR. Try a file with more than five embedded documents to see the five-largest limit in practice. Try something over 50 MB and watch for the Bypass By Size verdict. These are the gaps someone will find eventually; better that it is you.

Test from a remote user, not just the office. Inline DLP covers remote users on the Cato Client, but only if their traffic is actually tunnelled.

What commonly goes wrong?

• TLS Inspection shows 0. Nothing else matters until this reads 1.

• QUIC is not blocked. The traffic bypasses inspection entirely and produces no events.

• The app is not identified. Needs hostname access with DNS visible, not a direct IP.

• CSV and TXT files evade type detection. They lack magic headers — which is exactly the format people export customer data into. Test these specifically.

• Split-tunnelled traffic is never scanned. Check your split tunnel policy before concluding a rule is broken.

• Certificate-pinned desktop clients sit outside inspection — see fixing Cato TLS inspection application failures.

• Nobody owns the event review. This is how most DLP programmes actually fail. The rules work; the queue goes unread.

• Blocking with no sanctioned alternative. If people have no approved way to share a large file, they will find an unmonitored one.

A baseline policy is a week of configuration and a quarter of tuning. The configuration is the easy half — what takes effort is agreeing what counts as sensitive, keeping profiles current as the business changes, and having someone read the violation queue every week. Where that capacity does not exist in-house, it is normally folded into a managed CASB and data protection engagement, which is also how most teams keep the policy useful after the project team moves on.

FAQs

1) Do I need both the CASB and DLP licenses for inline DLP?

Yes. The Application Control policy comes with the CASB license, but enabling Data Control rules inside it also requires the DLP license. With CASB alone you can allow or block applications and their activities — stop all uploads to unsanctioned apps, for example — but you cannot make the decision based on what is inside the file. If you are building a baseline from scratch, start by confirming the entitlement, because the policy design differs completely depending on the answer.

2) Does inline DLP scan email?

Webmail, yes — Gmail and Outlook on the web are web destinations over HTTPS, so they are inspected like any other web traffic, and email file formats such as .eml, .msg and .pst are supported as scanned attachments. SMTP mail flow and mailboxes at rest, no. For tenant-wide email coverage including unmanaged devices you need the Data Protection API connector for Microsoft 365 or Google Workspace, which is a separate policy at Security > App & Data API Protection and does not require TLS Inspection.

3) Should I set fail-closed?

Only with a documented decision behind it. Fail-closed applies to every traffic flow in the account, not only traffic matching a Data Control rule, so it changes how your whole estate behaves when a scan cannot complete. Regulated environments where an unscanned file leaving is worse than a blocked one are the genuine use case. Everywhere else, fail-open plus a well-tuned policy is the better trade. If you are building toward PCI DSS or DPDP Act evidence, the audit question is usually whether you can show enforcement and review — which is a compliance automation problem as much as a DLP one.

4) Why does my DLP rule not trigger even though the file clearly contains sensitive data?

Work through it in this order: TLS Inspection field reads 1; QUIC and GQUIC blocked; file under 50 MB and of a supported type; application identified by hostname with DNS visible; and only then whether the content profile and threshold actually match the file. Also check the format-specific limits — PNG and JPEG scan only on upload, and only the five largest embedded items in a file are inspected. In practice the first two causes account for most cases.

5) Where should a first-time DLP policy start?

One broad Monitor rule on your sanctioned SaaS tenant, plus block rules for card data and access keys to unsanctioned destinations. That gives you visibility immediately and prevents the two leaks nobody will defend, without breaking anything. Then widen from evidence. The most common failure is the opposite approach — a comprehensive policy in Block on day one, which produces an outage and a disabled policy by day three.