Skip to main content
Versa Networks

DLP Configuration Guide

  1. Last updated
  2. Save as PDF

Versa-logo-release-icon.pngFor supported software information, click here.

Versa Networks data loss prevention (DLP) provides comprehensive data protection across multiple communication channels including email, web, chat, SaaS applications, and cloud storage. With native SSL/TLS inspection, it applies DLP policies to encrypted traffic and supports a wide range of file types and metadata, including OCR for PDFs and images.

The Versa Networks unified policy engine ensures consistent management across its security and DLP services from a single interface. Integrated with CASB capabilities, it delivers deep visibility and control over sensitive data in both on-premises and cloud environments. The intuitive UI, built-in templates, best practices, and analytics make it easy to deploy and manage, while supporting compliance with standards like HIPAA, PCI and GDPR.

This article describes the essential steps to configure DLP, helping you quickly deploy and manage policies to protect sensitive data across your network and cloud applications.

DLP Configuration Overview

Versa’s DLP configuration follows a modular, layered approach, building complex protections from simple, reusable components. The process consists of defining and combining key building blocks in a nested structure:

Data Patterns

These are the most granular elements of the DLP system. A data pattern typically consists of a regular expression (regex) used to detect specific values such as keywords, patterns (e.g., credit card numbers), or sensitive terms. Administrators can define custom patterns or use Versa’s rich library of predefined ones.

Recommendations:

  • Keyword and Regex both are mandatory for predefined custom patterns, and a data pattern will only match if at least one of the defined keywords is present together with a value that matches the defined regex, within the defined range, as shown in the example below.
  • The Range Window (Bytes) parameter defines how many bytes around a detected keyword or regex match are inspected to validate context. A value of 100–200 bytes is generally recommended as it balances accuracy and performance; smaller windows (50–100 bytes) work well when patterns are close together, while larger windows (up to 500 bytes) may be needed if attributes are separated by more text. As a best practice, start with 100 bytes and adjust only if broader context is required.

undefined

Data Protection Profiles

At the next level, data protection profiles group multiple data patterns using logical expressions such as AND, OR, NOT, or proximity operators like NEAR. This allows for the creation of more nuanced conditions to match complex data leakage scenarios. Both custom and predefined patterns can be referenced in a profile.

Operator

What it does

Pseudo-syntax

Matches

Doesn’t match

AND

All referenced patterns must be present

PATTERN_A AND PATTERN_B

Text contains both an EMAIL and a CREDIT_CARD

Only EMAIL or only CREDIT_CARD

OR

Any one of the patterns is enough

PATTERN_A OR PATTERN_B

Either PAN or AADHAAR appears

Neither appears

NOT

Excludes matches that contain a pattern

PATTERN_A AND NOT PATTERN_B

CREDIT_CARD present but no CORP_EMAIL_DOMAIN

Both CREDIT_CARD and CORP_EMAIL_DOMAIN present

NEAR

Two patterns must occur within n words of each other (any order)

PATTERN_A NEAR/5 PATTERN_B

“card number is 4111… email me” (≤5 words apart)

“card number … [30 words] … email”

Recommendations:

  • Recommended to configure a Boolean expression with at least 2 or 3 patterns(userdef/predef) with any of the operators.
  • Max 10 data patterns can be added to data protection profiles.
  • Versa DLP has predefined data protection profiles, a built-in database of data expressions & rules which are used to classify the data. These expressions or rules are updated with SPack upgrades and it is designed to detect most occurrences of sensitive/regulatory data, but not all.

DLP Rules

DLP rules consume one or more Data Protection Profiles and define how and when inspection occurs. Each rule includes:

  • Inspection Method:
    • Content Analysis—Efficient scanning of data-in-motion using prefilters.
    • File DLP—Inspects based on file attributes (filaname, filesize range and/or hash value).
    • OCR—​​​​​​​Applies policy to text extracted from image-based files.
    • EDM—​​​​​​​Matches data against exact entries in a user-supplied dataset.
    • Document Fingerprinting—​​​​​​​Matches documents based on predefined sensitive forms.
  • File Types—​​​​​​​Specify which file types are subject to inspection.
  • Direction/Context—​​​​​​​Specify whether the rule applies to uploads, downloads, or both. Also clarify whether it applies to the header, body, and/or attachments.
  • Actions—​​​​​​​Determine what happens when a match is found, such as block, alert, or allow.

Recommendation: Do not select Header in DLP policy until it’s required.

DLP Profile

DLP Profiles aggregate multiple DLP rules into a single configuration object. These profiles are then applied within policies to enforce DLP across the desired traffic paths. This nested and reusable design allows organizations to scale DLP policies efficiently while maintaining clarity and control over policy logic.

Note: Do not add HTTP or HTTPS applications to the DLP profile by default. Include them only when there is a specific use case or need for DLP inspection of applications that are not already covered by native DLP support.

Before You Begin

Before you proceed with the steps outlined in this document, make sure to do the following:

  • The provider administrator must complete your tenant configuration. If you haven’t received this information, contact your Managed Service Provider or Account Manager for assistance.
  • Obtain the Enterprise Administrator (Tenant Admin) credentials for the Versa SASE portal, also called the Concerto User Interface.

Use Case 1: (PII) Aadhaar Card Numbers and Indian Mobile Numbers Policy

This use case demonstrates how Versa Networks’ Data Loss Prevention (DLP) can be configured for ACME-ONE, a global enterprise concerned about the leakage of personally
identifiable information (PII).

The HR and Compliance departments at ACME-ONE frequently process documents containing Indian Aadhaar card numbers and Indian mobile phone numbers, both of which are considered sensitive PII. To prevent the accidental or intentional exfiltration of this information, the organization wants to block outbound transfers (such as external emails with attachments using Gmail or Outlook) whenever:

  • The file or message contains either of the following:
    • Aadhaar-related keywords (e.g., Aadhaar, UIDAI) and matches Versa’s predefined Aadhaar number detection pattern.
    • The file or message contains Indian mobile number patterns.
  • More than 10 Aadhaar numbers or more than 10 Indian mobile numbers are found within the same file or transaction.

Using Versa’s integrated DLP engine, ACME-ONE defines a DLP policy named "PII Protection Policy" with the following conditions:

Policy Name

Conditions

Details

PII Protection Policy

Aadhaar-related keyword & Aadhaar number pattern AND >10 Aadhaar numbers in a single file/transaction OR Indian mobile number pattern AND >10 Indian mobile numbers in a single file/transaction

1) Detect Aadhaar details using keywords combined with Versa’s predefined Aadhaar pattern. 2) Detect Indian mobile numbers using Versa’s predefined mobile number pattern. 3) Trigger when more than 10 Aadhaar or Indian mobile numbers are detected in the same file/transaction. Actions include blocking, logging, or quarantining as per the DLP policy.

Prerequisites

  • SSE Gateway with VSPA, VSIA or both enabled.
  • Authentication via Active Directory (LDAP used in our scenario).
  • TLS Decryption enabled for the cloud applications defined for testing.

Configuration

The DLP configuration consists of the following steps, which are described in detail below:

  1. Create DLP objects:
    • Create a data protection profile (detection patterns, dictionaries, fingerprinting, etc.).
    • Create a DLP rule (conditions that trigger DLP checks).
    • Create and assign a DLP profile / policy (the policy that ties the data profile and rules to enforcement actions).
  2. Create TLS decryption rule for the cloud apps you will test (Gmail and Outlook).
  3. Create real-time protection rule that applies the DLP profile to the cloud apps defined in Step 2.
  4. Perform tests and validate the behaviors. Execute test cases, verify detection and enforcement, and record results.

Step 1: Create DLP Objects

Create a Data Pattern for Indian Mobile Numbers

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Patterns.
  2. Click + Add.

    undefined
  3. Define the values with a simple regex for Indian mobile numbers, making sure the keywords are included and related to the content, as shown below.

    undefined
  4. Click Save. 

Create a Data Protection Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Protection.
  2. Click + Add.

    undefined
  3. Complete the three configuration steps shown in the image below.

    undefined
  4. In step 1, Select DLP Data Pattern:
    1. Select Add Predefined Data Pattern and search for the one you need. In this example, enable INDIA_AADHAAR_INDIVIDUAL.
    2. Click Save.
    3. Click on User-Defined Data Pattern and enable Indian_Mobile_Numbers (created in the last step).
    4. Click Save.
  5. In step 2, Action:
    1. Click the + icon next to the data identifier INDIA_AADHAAR_INDIVIDUAL to add it to your Boolean expression.
    2. Insert the OR operator and click the + icon again to add Indian_Mobile_Numbers. 

      undefined
    3. Once the data identifier has been added, click Next to continue.
  6. In the Review & Submit step, assign a name to your Data Protection profile.

    undefined
  7. Click Save.

Create a DLP Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Rule.
  2. Click + Add.

    undefined
  3. The menu to select the type of DLP rule displays. For details on the different types of DLP rules, see DLP Rule Type Reference.
  4. Select Content Analysis, and then enter information for the following fields:
    • Severity Level—Select the severity assigned to the DLP event. Each level has a default value: Low = 1, Medium = 10, High = 20, Critical = 30. The default value here specifies the number of occurrences needed to trigger the rule. In the current case, we select Medium.
    • Severity Value—Define a custom number of occurrences required to trigger the rule. The counter starts from 0. For example, if you set the value to 10, the rule will trigger beginning from the 11th DLP event. In this case, set the value to 10. Note that in DLP, the Severity Level defines the default number of matches required to trigger a rule (Low=1, Medium=10, High=20, Critical=30). If a custom Severity Value is set, it overrides the default threshold (e.g., High=20 but Value=5 →triggers after 5 occurrences).
    • Predefined/User Defined—Select User Defined and then choose the Data Protection Profile you created earlier, named data-protection-profile-AADHAAR.
  5. Click Next. 

    undefined
  6. In the File Type step, select the file types you want to inspect (.txt, .doc, .docx, .csv, etc.).
  7. Click Next.

    undefined

    The image below shows file types supported for DLP.

    undefined
  8. In step 3, Configure Activity, Protocol & Context, enter information for the following fields:
    • Activity—Select the activity to which the DLP module will be applied. In our case, select Upload.
    • Web Protocol—Select HTTP.
    • Context—Defines which part of the packet or message will be inspected. For this example, select Attachments and Body.

      undefined
  9. In the Exclude step, specify the file name(s) that should be excluded from DLP inspection.

    undefined
     
  10. In the Action step, define the action to be executed when the rule is triggered (Allow, Alert, Block or Reject). In this use case, the action is set to Alert so that only a log is generated in teh platform without blocking the user or displaying any popup messages. This option is commonly used when tuning DLP rules. For more information on the different actions, see DLP Rule Actions Reference. 

    undefined
  11. In the Review & Submit step, verify that your rule matches the example shown in the image below.

    undefined
  12. Click Save. 

Create the DLP Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Profile.
  2. Click + Add.

    undefined
  3. Complete the six steps shown in the following image.

    undefined
  4. In the Select DLP Rules step:
    1. In the User Defined Rules section, search for the rule you created earlier and select it.
    2. Click Next. It should look like the example shown below.

      undefined
  5. In the Configure Rule Order step, you can select any rule and move it up or down to change the DLP processing order. The rule at the top is processed first, and the one at the bottom is processed last. In this case, this does not apply since only a single rule is selected.

    undefined
  6. In the Applications & Group step:
    1. In the Applications search field, search for each application to which the DLP profile will be applied. In our case, select Gmail and Outlook.
    2. Click Next, as shown in the image below.

      undefined

      Note: In cases where not all dependent applications are known, adding the generic applications HTTPS or HTTP to the DLP profile may help. However, this approach is not technically guaranteed to work and could impact unrelated traffic. Therefore, rules applied in real-time protection should remain as specific as possible.

      In some cases, you may also need to add dependent applications when dealing with SaaS apps. For example, Gmail relies on additional services such as gstatic.com to load resources like icons, scripts, or image previews (e.g., when sending or viewing image attachments). Without allowing these dependencies, the SaaS application may not function correctly.

  7. In the Reputation step, select the Enable Logging option to store website reputation events, as shown in the image below. Reputation refers to a local URL database used to categorize websites and assign reputation scores for web filtering. This local database allows quick lookups for the most common and popular websites. Additionally, Versa offers the option to enable Cloud Lookup to complement the local database. For this use case, Cloud Lookup is not required.

    undefined
  8. In the Action step, enter the following information:
    • Actions—Leave the default action set to Allow.
    • Enable Logging—Click on the toggle button to enable it.
    • Exit on First Rule Match—Leave the default action set to disabled. as shown in the image below.

      undefined

      Note: If multiple DLP rules are configured, this option should be disabled to ensure that all rules are applied to the same session.

  9. In the Review & Submit, assign a name, then review the configuration.
  10. Click Save.

Step 2: Create the TLS Decryption Rule for the Cloud Applications (Gmail and Outlook)

To ensure that payloads can be inspected and DLP policies applied, a TLS decryption rule must exist for the cloud applications being tested (e.g., Gmail and Outlook). For the detailed step-by-step configuration for creating this rule, see TLS Decryption Rule Configuration.

Step 3. Create the Real-Time Protection Rule

In this step, you create the real-time protection rule using the DLP profile on the cloud apps defined earlier.

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Internet Protection.
  2. Click + Add. 

    undefined
  3. Complete the workflow steps shown in the following image.

    undefined
  4. In the Applications & URLs step, select the applications to which you want to apply our DLP module (here, Gmail and Outlook). 
  5. In the Users & Groups step, select the test group and then click Next. In this case, it can be the (VIP) group coming from the LDAP-AD.
  6. In the Endpoint Posture step, you can apply Endpoint Information Profiles and Entity Risk Bands. In this case, leave the default settings to apply none and click Next.
  7. In the Geolocation step, you can filter by Source or Destination Geo Location. In this case, we leave the default setting to All and click Next.
  8. In the Network Layer 3-4 step, you can filter by services (Layer 4) such as HTTP, HTTPS, DNS, ICMP, etc. You can also filter by Source & Destination (Layer 3). In this case, leave the default values and click Next.
  9. In the Security Enforcement step:
    1. Click on the Security Profiles option.
    2. Select Data Loss Prevention. Toggle the switch to enable it, then choose the profile named dlp-profile-use-cases, which is the one created for this case.
    3. Click Next.
  10. In the Review & Validate step, verify the configuration (see image below).

    undefined
  11. Click Save, and select add this rule at the top of the rule list.
  12. Publish the changes applied in Concerto and proceed with the verifications.

Step 4. Perform Tests and Validate the Behavior

To perform tests, it is important to understand which key pair values will cause the selected Data Pattern (INDIA_AADHAAR_INDIVIDUAL) to match your data samples. This is part of your Predefined DLP Patterns.

  • DLP Pattern Name—INDIA_AADHAAR_INDIVIDUAL
  • Keywords—(aadhaar|aadhaar card)
  • Pattern Conditions:
    • Detects a 12–digit Aadhaar number that starts with digits 2–9.
    • Supports different formatting styles, such as continuous digits (123412341234) or with separators (e.g., 1234-5678-9123 or 1234 5678 9123).
    • Ensures the detected number is not part of a larger alphanumeric string.

The following sample data, based on the above and also the custom data pattern created in Step 1, can be used to create the .txt file (Test1.txt) and run the tests.


Aadhaar Numbers: 6472 4756 5971 6904 5289 0788 7885-6256-1067 8950-0527-1593
019114027248 7617-8729-4609 855106136654 111048062360 8558 4853 3876
462740952344 763753879522 679336449441 1255 3766 1539 2904-0323-2864 7932-7598-
9884 7285 2101 3902 618131683916 4168-9830-2972 0595-3528-6334 7088 6925 2334
Mobile Numbers: 8168718125 +91 6883553941 08511396286 08087536420 0-9344714963 91
9050767250 0-6642953071 9772829100 0-7555887505 9497707487 +919947360842
+919086832700 6361279769 +91 8772342864 07606012845 919099828766 8773658291
9555473795 91-9465257534 91-6948732713
 


Compose an email from Gmail or Outlook and attach Test1.txt, which should be allowed because the Alert action does not block but generates an alert log for the DLP event. When checking the logs in Concerto > Analytics > DLP Logs, you should see something similar to the images below.

undefined

Optional: You can also change the action from Alert to Block for this DLP rule. As a best practice, DLP rules are usually deployed in Alert mode first to fine-tune detections, and only then switched to Block mode once they are validated. When using Block, the logs will reflect the blocked action instead of an alert. In addition, the user session will be dropped, and the client will display a pop-up notification with the violation message, as shown below.

undefined

undefined

Use Case 2: Protecting Confidential HR Forms with Fingerprint DLP

This use case demonstrates how ACME-ONE leverages Fingerprint-based DLP in Versa Networks to protect sensitive HR documents that must not leave the corporate environment. The HR department at ACME-ONE manages a “Confidential Employee Disciplinary Form”, which contains predefined fields such as:

  • Employee Name
  • Employee ID
  • Date of Incident
  • Description of Violation
  • Manager Comments
  • HR Review Outcome

Although the specific details in each form may vary, the overall structure, layout, and field labels remain consistent.

To prevent the exfiltration of these documents through web-based uploads to cloud storage services such as SharePoint and Dropbox, Versa’s Fingerprint DLP engine is configured to detect document similarity against a registered template of the “Confidential Employee Disciplinary Form.”

Using Versa’s integrated DLP engine, ACME-ONE defines a DLP policy named " Confidential HR Form Protection" with the following conditions:

  • Policy Name HR Form Protection Policy
  • Conditions Document fingerprint match with a 50% similarity
  • Details:
    • Register the “Confidential Employee Disciplinary Form” as a fingerprinted document in Versa DLP.
    • Trigger the policy if outbound traffic contains a web upload attempt of a file with ≥ 50% similarity to the fingerprinted template via SharePoint or Dropbox.
    • Actions include Alerting, blocking and logging.

Prerequisites

Before you being, make sure do to the following:

  • SSE gateway with VSIA enabled.
  • Authentication via Active Directory (LDAP is used in this scenario).
  • TLS decryption enabled for the cloud applications defined for testing.

Configuration

The DLP configuration consists of the following steps, which are described in detail below:

  1. Create DLP objects:
    1. Create a DLP Sub-Folder and upload the confidential file.
    2. Create a DLP Rule (conditions that trigger DLP checks).
    3. Create and assign a DLP Profile / Policy (the policy that ties the data profile and rules to enforcement actions).
  2. Create TLS decryption rule for the cloud apps you will test (SharePoint and Dropbox).
  3. Create real-time protection rule that applies the DLP profile to the cloud apps defined in Step 2.
  4. Perform tests and validate the behaviour. Execute test cases, verify detection and enforcement, and record results.

Step 1: Create DLP Objects

For our rule type (Document Fingerprinting), create a folder where the confidential document will be stored. This document will be used to generate corresponding fingerprint hash. You must also define and upload the confidential file. Once this is completed, you can define the DLP rule by selecting the folder that already contains your file and then proceed with the standard configuration steps.

Create the Folder

  1. Navigate to Configure > Security Service Edge > Settings > Files and Folders.
  2. Click + Add.

    undefined
  3. The Add Folder window appears. Enter information for the following fields:
    • Where should folder be placed?—From the dropdown list, select DLP/Fingerprints.
    • Folder Name—Enter a descriptive name, for example, ACME-ONE-Fingerprinted-Files-HR.
  4. Once completed, the configuration window appears as follows:

    undefined

Upload File

  1. Navigate to Configure > Security Service Edge > Settings > Files and Folders.
  2. Click + Upload File.

    undefined
  3. The Upload File window displays.
  4. Enter information for the following fields:
    • Hash the File—Leave the default option checked. 
    • Where should the folder be placed—Select DLP/Fingerprints/ACME-ONE-Fingerprinted-Files-HR, which is the sub-folder already defined.
    • Upload File—Click and select the file from the corresponding location. 
  5. Once completed, the configuration window appears as follows:

    undefined
  6. Click Upload to complete the process.

Create a DLP Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Rule.
  2. Click + Add.

    undefined
  3. A menu to select the type of DLP rule displays. Select Document Fingerprinting. For details on the different types of DLP rules, see DLP Rule Type Reference.
  4. Enter information for the following fields:
    • Folder Name—Click on the dropdown list and select the folder related to your current tenant. In this case, it is ACME-ONE-Fingerprinted-Files-HR.
    • Similarity Threshold—Defines the minimum level of content overlap required between an uploaded user document and the reference (sample) document. For example, if the
      threshold is set to 60% and the computed similarity is 70%, the document will be considered a match. Conversely, if the threshold is set to 80%, the same document
      would not be considered a match. For this case, select 50%.
  5. Once completed, the configuration window appears as follows:

    undefined

    Note: 

    • Avoid False Matches on Blank Forms—If the computed similarity is 95% or higher, Versa assumes the uploaded document is effectively blank or unmodified, and the document will not be considered a match. Ensure user-filled forms include sufficient new content to lower the similarity below 95%, enabling meaningful evaluation.
    • Recommended Thresholds for Fully Completed Forms—For user-submitted, fully completed forms, set the similarity threshold between 30% and 60% to reliably detect and match against the original template.
    • Tailor the Threshold—Adjust the similarity threshold based on form type and expected variation. Use lower thresholds for structured, fully completed forms and higher thresholds for loosely-modified templates.
  6. Click Next.
  7. In the File Types step, select the file types you want to inspect (here, .docx and .pdf). Supported file types are .pdf, .doc, and .docx.

    undefined
  8. Click Next. 
  9. In the Activity, Protocol and Context step, enter information for the following fields:
    • Activity—Select the activity to which the DLP module will be applied (here, Upload.)
    • Web Protocol—Select HTTP
    • Context—Defines which part of the packet or message will be inspected (here, Attachments).

      undefined
  10. Click Next. 
  11. The Exclude step displays. Click Next (this use case does not require excluding any files).

    undefined
     
  12. In the Action step, configure the action to be executed when the rule is triggered (here, Block). For more information on the different actions, see DLP Rule Actions Reference.

    undefined
     
  13.  In the Review & Submit step, verify that your rule matches the example shown in the image below.

    undefined
  14. Click Save.

Create the DLP Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Profile.
  2. Click + Add.

    undefined
  3. Complete the six steps shown in the following image.

    undefined
  4.  In the Select DLP Rules step:
    1. In the User Defined Rules section, search for the rule you created earlier and select it.
    2. Click Next. It should look like the example below.

      undefined
  5. Click Next to skip the Configure Rule Order step (only a single rule has been selected).
  6. In the Applications & Group step:
    1.  In the Applications search field, search for each application to which the DLP profile will be applied. In this case, select the related apps for Sharepoint and
      Dropbox.
    2. Click Next, as shown in the image below.

      undefined
       

      Note: In cases where not all dependent applications are known, adding the generic applications HTTPS or HTTP to the DLP profile may help. However, this approach is not technically guaranteed to work and could impact unrelated traffic. Therefore, rules applied in real-time protection should remain as specific as possible.

       

      In some cases, you may also need to add dependent applications when dealing with SaaS apps. For example, Gmail relies on additional services such as gstatic.com to load resources like icons, scripts, or image previews (e.g., when sending or viewing image attachments). Without allowing these dependencies, the SaaS application may not function correctly.

  7. In the Reputation step, select the Enable Logging option to store website reputation events, as shown in the image below. Reputation refers to a local URL database used to categorize websites and assign reputation scores for web filtering. This local database allows quick lookups for the most common and popular websites. Additionally, Versa offers the option to enable Cloud Lookup to complement the local database. For this use case, Cloud Lookup is not required. 

    undefined
    1. Actions—Leave the default action set to Allow.
    2. Enable Logging—Click the toggle to enable logging.
    3. Exit on First Rule Match—Leave the default action set to disabled, as shown in the screenshot below. 

      undefined

      Note: If multiple DLP rules are configured, this option should be disabled to ensure that all rules are applied to the same session.

  8. In the Review & Submit step, review the configuration.
  9. Click Save.
    10.
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  

Step 2: Create the TLS Decryption Rule for the Cloud Applications (Sharepoint and Dropbox)

To ensure that payloads can be inspected and DLP policies applied, a TLS decryption rule must exist for the cloud applications being tested (e.g., Sharepoint and Dropbox). For detailed step-by-step configuration, see TLS Decryption Rule Configuration.

Step 3. Create the Real-Time Protection Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Internet Protection.
  2. Click + Add. 

    undefined
     
  3. Complete the seven steps shown in the following image.

    undefined
  4. In the Applications & URLs step, select the applications to which you want to apply the DLP module (here, Sharepoint and Dropbox). 
  5. In the Users & Groups step, select the test group and then click Next. In this case, it can be the (VIP) or (HR) group coming from the LDAP-AD.
  6. In the Endpoint Posture step, you can apply Endpoint Information Profiles and Entity Risk Bands. In this case, leave the default settings to apply none and click Next.
  7. In the Geolocation step, you can filter by Source or Destination Geolocation. In this case, leave the default setting to All and click Next.
  8. In the Network Layer 3-4 step, you can filter by services (Layer 4) such as HTTP, HTTPS, DNS, ICMP, etc. You can also filter by Source & Destination (Layer 3). In this case, leave the default values and click Next.
  9. In the Security Enforcement step:
    1. Click the Security Profiles option.
    2. Select Data Loss Prevention. Toggle the switch to enable it, then choose the profile named DLP-Profile-Fingerprint, which is the one created for this case. 
    3. Click Next.
  10. In the Review & Validate step, review the configuration (as shown below).

    undefined
  11. Click Save, and select to add this rule at the top of the rule list.
  12. Publish the changes applied in Concerto and proceed with the verifications.

Step 4. Perform Tests and Validate the Behavior

To perform the tests, upload the test file from SharePoint and Dropbox that corresponds to the confidential form once completed.

The original form, which is blank, is shown below.  The filename is Incident_Report_Form_Blank.docx.

undefined

 

The filled form, which is used in the test, is shown below.  The filename is Incident_Report_Form_Filled.docx.

undefined

Upload from SharePoint or Dropbox the file called Incident_Report_Form_Filled.docx, which should be blocked because the Block action was selected. 

  • The following image shows the SharePoint test.

    undefined
     
  • The following image shows the Dropbox test.

    undefined

 

For the sample filled form, see Sample Data for EDM Test.

When checking the logs in Concerto > Analytics > DLP Logs, you should see something similar to the images below.

undefined

Use Case 3: VIP Customer Data Protection with EDM-Based DLP

This use case demonstrates how ACME-ONE leverages EDM-based DLP in Versa Networks to prevent sensitive customer records from being leaked by employees in Finance or VIP Management. These employees regularly access the VIP Customers Database and frequently use cloud collaboration platforms and email services. The Finance and VIP Management departments at ACME-ONE manage a VIP Customers Database containing highly sensitive information, such as:

  • Customer Full Name
  • Customer ID / Account Number
  • Email Address
  • Phone Number
  • Contract Reference Number

Since these records represent ACME-ONE’s top customers, preventing their unauthorized disclosure is a business-critical requirement. Unlike fingerprinting entire forms, EDM provides field-level matching against the structured database, ensuring that even partial extracts (e.g., a CSV export) are detected. To reduce the risk of intentional or accidental exfiltration via platforms commonly used by Finance and VIP staff, Versa’s EDM DLP engine is configured to detect matches against the registered VIP customer database when data is transmitted through:

  • Cloud storage apps: SharePoint web, Dropbox web.
  • Email services: Outlook (Office 365), Gmail

Using Versa’s integrated DLP engine, ACME-ONE defines a DLP policy named “VIP Customer Data Protection” with the following conditions:

Policy Name

Conditions

Details

VIP Customer Data Protection

EDM match with ≥ 1 field hit from VIP database

1) Register the VIP customer database as an EDM source in Versa DLP. 2) Trigger the policy if outbound traffic contains data matching any field from the EDM source via SharePoint, Dropbox, Outlook, or Gmail. 3) Actions include Blocking, and Logging.

Prerequisites

Before you begin, make sure you have the following:

  • SSE gateway with VSIA enabled.
  • Authentication via Active Directory (LDAP in this scenario)
  • TLS decryption enabled for the cloud applications defined for testing.

Configuration 

The DLP configuration consists of the following steps, which are described in detail below:

  1. Create DLP objects:
    • Create a DLP Pattern for USA mobile numbers, Contract id and Customer id.
    • Create a DLP Rule (conditions that trigger DLP checks).
    • Create and assign a DLP Profile / Policy (the policy that ties the data profile and rules to enforcement actions).
  2. Create TLS decryption rule for the cloud apps you will test (SharePoint, Dropbox, Outlook and Gmail).
  3. Create real-time protection rule that applies the DLP profile to the cloud apps defined in Step 2.
  4. Perform tests and validate the behaviour. Execute test cases, verify detection and enforcement, and record results.

Step 1: Create DLP objects

For this use case (EDM – Exact Data Match), upload the database through Concerto and then select the columns that contain sensitive information, mapping each column to a data pattern (either predefined or customized). It is important to have already defined any custom data patterns to be used, before reaching this step. In this case, define a custom data pattern for USA mobile numbers, contract IDs, and customer IDs, and use a predefined one for emails. After that, define the DLP rule, where we must configure the Boolean expression that determines the match condition.

Creating a Data Pattern for USA Mobile Numbers

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Patterns.
  2. Click + Add.

    undefined
  3. Define the values with a simple regex for USA mobile numbers, making sure the keywords are included and related to the content, just as shown in the image below.

    undefined
  4. Click on Save.

Creating a Data Pattern for Contract ID

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Patterns.
  2. Click + Add.
  3. Define the values with a simple regex for Contract ID based on the Database (CTR_XXXX_XXXX), making sure the keywords are included and related to the content, just as shown in the image below.

    undefined
  4. Click on Save.

Creating a Data Pattern for Customer ID

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Patterns.
  2. Click + Add.
  3. Define the values with a simple regex for Customer ID based on the Database (CUST_XXXXXX), making sure the keywords are included and related to the content, just as shown in the image below.

    undefined
  4. Click on Save.

Create a DLP Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Rule.
  2. Click + Add.

    undefined
  3. A menu to select the type of DLP rule displays. Select Exact Data Match (EDM). For details on the different types of DLP rules, refer to DLP Rule Type Reference.
  4. Complete the configuration workflow steps:
  5. In the Exact Data Match step, enter information for the following fields:
    • Create Expression—Defines a boolean expression without relying on a database. This expression can use either predefined or customized data patterns.
    • Upload File—Allows you to upload a database file, and automatically displays the column headers so you can decide which ones to use and which data pattern
      to associate with each of them. For example, if the database has a column with email addresses, that column can be mapped to Versa’s predefined data pattern for emails.
    • Select File Name—Allows you to select a file that was previously uploaded to Versa under the File and Folders path. For this case, select this option. The following screen displays.

      undefined
    • Hash the File—Keep this option enabled, which is selected by default for security reasons. However, if in the future the Administrator wants to download the original database from Concerto, this option must be unchecked; otherwise, the downloaded file will only contain the hashed values.
  6. Drag and drop the database file or click to select it manually. In this case, we upload the file named vip_customers_db1.csv. Then, remove the columns that are not relevant, and map each remaining column to the corresponding DLP data pattern, as shown in the image below.

    undefined
  7. Click Save.
  8. In the Boolean Operation section, define the boolean expression that determines the match condition. For example, use a simple expression that applies an OR operator to all the headers, and shown below.

    undefined
  9. Click Next. 
  10. In the File Type step, select the files that you want to inspect (here, .csv and .txt.)

    undefined
  11. Click Next. 
  12. In the Configure Activity, Protocol & Context step, enter information for the following fields:
    • Activity—Select the activity to which the DLP module will be applied (here, Upload.)
    • Web Protocol—Select HTTP
    • Context—Defines which part of the packet or message will be inspected (here, Attachments).

      undefined
  13. In the Exclude step, you can specify the file name(s) that should be excluded from DLP inspection. Here, there is no need to exclude any files, so leave this field blank and click Next.
  14. In the Action step, define the action to be executed when the rule is triggered (Allow, Alert, Block or Reject). For this case, select Block. For information on different actions, see DLP Rule Actions Reference. 

    undefined
  15. In the Review & Submit step, verify that your rule matches the example shown in the image below.

    undefined
  16. Click Save.

Create the DLP Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Profile.
  2. Click + Add.

    undefined
  3. Complete the configuration workflow shown below.

    undefined
  4. In the Select DLP Rules step:
    1. In the User Defined Rules section, search for the rule you created earlier and select it.
    2. Click Next. It should look like the example shown below.

      undefined
  5. In the Configure Rule Order step, you can select any rule and move it up or down to change the DLP processing order. The rule at the top is processed first, and the one at the bottom is processed last. In this case, this does not apply since only a single rule is selected.
  6. In the Applications & Group step:
    1. In the Applications search field, search for each application to which the DLP profile will be applied. In this case, select Gmail, Outlook, SharePoint and Dropbox.
    2. Click Next, as shown in the image below.

      undefined

      Additionally, Versa offers the option to enable Cloud Lookup to complement the local database.

      Note: In cases where not all dependent applications are known, adding the generic applications HTTPS or HTTP to the DLP profile may help. However, this approach is not technically guaranteed to work and could impact unrelated traffic. Therefore, rules applied in real-time protection should remain as specific as possible.

      In some cases, you may also need to add dependent applications when dealing with SaaS apps. For example, Gmail relies on additional services such as gstatic.com to load resources like icons, scripts, or image previews (e.g., when sending or viewing image attachments). Without allowing these dependencies, the SaaS application may not function correctly.

  7. In the Reputation step, select the Enable Logging option to store website reputation events, as shown in the image below. Reputation refers to a local URL database used to categorize websites and assign reputation scores for web filtering. This local database allows quick lookups for the most common and popular websites. Additionally, Versa offers the option to enable Cloud Lookup to complement the local database. For this use case, Cloud Lookup is not required.

    undefined
  8. In the Action step, enter the following information:
    • Actions—Leave the default action set to Allow.
    • Enable Logging—Click on the toggle button to enable it.
    • Exit on First Rule Match—Leave the default action set to disabled. as shown in the image below.

      undefined

      Note: If multiple DLP rules are configured, this option should be disabled to ensure that all rules are applied to the same session.

  9. In the Review & Submit, assign a name, then review the configuration.
  10. Click Save.

Step 2: Create the TLS Decryption Rule for the Cloud Applications(Gmail, Outlook, SharePoint and Dropbox)

To ensure that payloads can be inspected and DLP policies applied, a TLS decryption rule must exist for the cloud applications being tested (e.g., Gmail, Outlook, Sharepoint and Dropbox). For detailed step-by-step configuration for creating this rule, see TLS Decryption Rule Configuration.

Step 3. Create the Real-Time Protection Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Internet Protection.
  2. Click + Add.

    undefined
  3. Complete the workflow steps shown in the following image.

    undefined
  4. In the Applications & URLs step, select the applications to which you want to apply the DLP module (here, Gmail, Outlook, SharePoint and Dropbox). 
  5. In the Users & Groups step, select the test group and then click Next. In this case, it can be the (VIP) or (HR) group coming from the LDAP-AD.
  6. In the Endpoint Posture step, you can apply Endpoint Information Profiles and Entity Risk Bands. In this case, leave the default settings to apply none and click Next.
  7. In the Geolocation step, you can filter by Source or Destination Geo Location. In this case, leave the default setting to All and click Next.
  8. In the Network Layer 3-4 step, you can filter by services (Layer 4) such as HTTP, HTTPS, DNS, ICMP, etc. You can also filter by Source & Destination (Layer 3). In this case, leave the default values and click Next.
  9. In the Security Enforcement step:
    1. Click on the Security Profiles option.
    2. Select Data Loss Prevention. Toggle the switch to enable it, then choose the profile named DLP-Profile-EDM, which is the one created for this case. 
    3. Click Next.
  10. In the Review & Validate step, verify the configuration (see image below).

    undefined
  11. Click Save, and select to add the rule at the top of the rule list. 
  12. Publish the changes applied in Concerto and proceed with the verifications.

Step 4. Perform Tests and Validate the Behavior Edit section

To perform tests, upload a test file from Gmail, Outlook, SharePoint, or Dropbox that contains partial information from the original database. This example uses the file vip_customers_db1.csv.

Note: The sample file must have headers that are identical to those loaded from the database and defined in the rule. 

The example below shows a portion of the data contained in the CSV file (vip_customers_db1.csv).

firstname,lastname,gender,mobile,customer,contract,email
Ava,Jackson,Male,3140474786,CUST_000001,CTR_1001_0001,ava.jackson@initech.com
Ava,Harris,Female,7359869480,CUST_000002,CTR_1001_0002,ava.harris@acmeenergy.com
Lucas,Lee,Female,9411336152,CUST_000003,CTR_1001_0003,lucas.lee@hooli.com
Olivia,Lee,Male,7110163088,CUST_000004,CTR_1001_0004,olivia.lee@wayneenterprises.com
Daniel,Johnson,Female,2647706560,CUST_000005,CTR_1001_0005,daniel.johnson@wayneenterprises.com
Emma,Taylor,Male,5041660904,CUST_000006,CTR_1001_0006,emma.taylor@umbrella-corp.com
Daniel,Martinez,Male,3286054734,CUST_000007,CTR_1001_0007,daniel.martinez@initech.com
Ethan,Harris,Male,4032561166,CUST_000008,CTR_1001_0008,ethan.harris@aurora-services.com
Daniel,Diaz,Male,4129341454,CUST_000009,CTR_1001_0009,daniel.diaz@globex.com
Emma,Allen,Female,4604552725,CUST_000010,CTR_1001_0010,emma.allen@cascadeinc.com

 

Upload the file created with the data from Gmail, Outlook, SharePoint or Dropbox. The file should be blocked because the Block action was configured. 

  • The following image shows the Dropbox Test:

    undefined
     
  • The following image shows the SharePoint Test:

    undefined

 

When checking the logs in Concerto > Analytics > DLP Logs, you should see something similar to the image below.

undefined
 

Use Case 4: Collaboration Chat Monitoring with DLP for Bad Words

This case demonstrates how ACME-ONE leverages DLP profiles in Versa Networks to detect and flag inappropriate or non-compliant language in collaboration tools, specifically Slack chats. The objective is to monitor communication channels for the use of prohibited terms, ensuring compliance with corporate policies and maintaining a professional environment.

The Collaboration and HR departments at ACME-ONE are responsible for monitoring employee chat activity for the following categories of concern:

  • Use of offensive, discriminatory, or profane language (bad words).
  • Custom-defined terms that reflect ACME-ONE’s internal compliance policies (e.g., code words, sensitive project names, or restricted topics).

Versa’s DLP engine allows combining predefined bad words dictionaries with custom keyword lists, ensuring that both general profanity and organization-specific terms are
detected in Slack chat messages. To reduce the risk of misconduct or policy violations in internal collaboration, Versa’s DLP engine is configured to inspect chat content from Slack (web and desktop app) and apply DLP actions when matches are detected. Using Versa’s integrated DLP engine, ACME-ONE defines a DLP policy named “Bad Words and Inappropriate Language Monitoring” with the following conditions:

  • Policy Name—Bad words and inappropriate language monitoring.
  • Conditions—Match on predefined bad words dictionary or custom keyword list.
    • Enable Versa’s predefined dictionary for profanity/offensive language. 
    • Create a custom keyword list with terms specific to ACME-ONE’s compliance rules (e.g., project code names, restricted slang).
    • Apply the policy to outbound and internal chat traffic within Slack.
    • Actions include Alerting, Logging, and optional Blocking.

Configuration

The DLP configuration consists of the following steps, which are described in detail below:

  1. Create DLP objects:
    • Create a DLP pattern for custom bad words.
    • Create a DLP rule (conditions that trigger DLP checks).
    • Create and assign a DLP profile / policy (the policy that ties the data profile and rules to enforcement actions).
  2. Create TLS decryption rule for the cloud apps you will test (Slack).
  3. Create real-time protection rule that applies the DLP profile to the cloud apps defined in Step 2.
  4. Perform tests and validate the behavior. Execute test cases, verify detection and enforcement, and record results.

Step 1: Create DLP Objects

For this use case (Content Analysis), we will use the predefined Bad Words data pattern and create an additional custom pattern if needed. These patterns will be referenced in
the DLP rule, where a Boolean expression (e.g., Predefined_BadWords OR Custom_BadWords) defines the match condition.

Creating a Data Pattern for Bad Words

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Patterns.
  2. Click + Add.

    undefined
  3. Define the values with a simple regex for Bad Words, making sure the keywords are included and related to the content, just as shown in the image below.

    undefined
  4. Click on Save.

Creating a Data Protection Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > Data Protection.
  2. Click + Add.

    undefined
  3. Complete the three configuration steps shown in the image below.

    undefined
  4. In step 1, Select DLP Data Pattern:
    1. Select Add Predefined Data Pattern and search for the one you need. In this example, enable GLOBAL_BAD_WORDS.
    2. Click Save.
    3. Click on User-Defined Data Pattern and enable ProhibittedWords (created in the last step).
    4. Click Save.
  5. In step 2, Action:
    1. Click the + icon next to the data identifier GLOBAL_BAD_WORDS to add it to your Boolean expression.
    2. Insert the OR operator and click the + icon again to add ProhibittedWords. 

      undefined
  6. Click Next.
  7. In the Review & Submit step, assign a name to your data protection profile.

    undefined
  8. Click Save.

Create a DLP Rule

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Rule.
  2. Click + Add.

    undefined
  3. The menu to select the type of DLP rule displays. For more information on the different types of DLP rules, see DLP Rule Type Reference.
  4. Select Content Analysis, and then enter information for the following fields:
    • Severity Level—Select the severity assigned to the DLP event. Each level has a default value: Low = 1, Medium = 10, High = 20, Critical = 30. The default value here specifies the number of occurrences needed to trigger the rule. For this case, select Medium.
    • Severity Value—Define a custom number of occurrences required to trigger the rule. The counter starts from 0. For example, if you set the value to 10, the rule will trigger beginning from the 11th DLP event. In this case, set the value to 10. Note that in DLP, the Severity Level defines the default number of matches required to trigger a rule (Low=1, Medium=10, High=20, Critical=30). If a custom Severity Value is set, it overrides the default threshold (e.g., High=20 but Value=5 →triggers after 5 occurrences).
    • Predefined/User Defined—Select User Defined and then choose the Data Protection Profile you created earlier, named data-protection-profile-AADHAAR.

      undefined
  5. Click Next. 
  6. In the File Type step, select the file types you want to inspect (.txt, .doc, .docx, .csv, etc.).

    undefined

    The image below shows the files types supported for DLP.

    undefined
     
  7. Click Next.
  8. In step 3, Configure Activity, Protocol & Context, enter information for the following fields:
    • Activity—Select the activity to which the DLP module will be applied. In this case, select Upload.
    • Web Protocol—Select HTTP.
    • Context—Defines which part of the packet or message will be inspected. For this example, select Attachments and Body.

      undefined
  9. In the Exclude step, specify the name(s) that should be excluded from DLP inspection.

    undefined
  10. In the Action step, define the action to be executed when the rule is triggered: Allow, Alert, Block, or Reject. Here, select Alert because you only want a log to be generated in the platform without blocking the user or displaying any popup messages. This option is commonly used when tuning DLP rules. For more information on the different actions, see DLP Rule Actions Reference. 

    undefined
  11. In the Review & Submit step, verify that your rule matches the example shown in the image below.

    undefined
  12. Click Save. 

Create the DLP Profile

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Profiles > DLP Profile.
  2. Click + Add.

    undefined
  3. Complete the six steps shown in the following image. 

    undefined
  4. In the Select DLP Rules step:
    1. In the User Defined Rules section, search for the rule you created earlier and select it.
    2. Click Next. It should look like the example shown below.

      undefined
  5. In the Configure Rule Order step, you can select any rule and move it up or down to change the DLP processing order. The rule at the top is processed first, and the one at the bottom is processed last. In this case, this does not apply since only a single rule is selected.
  6. In the Applications & Group step:
    1. In the Applications search field, search for each application to which the DLP profile will be applied. In our case, select Gmail and Outlook.
    2. Click Next, as shown in the image below.

      undefined

      Additionally, Versa offers the option to enable Cloud Lookup for cases where OCR type DLP is required.

      Note: In cases where not all dependent applications are known, adding the generic applications HTTPS or HTTP to the DLP profile may help. However, this approach is not technically guaranteed to work and could impact unrelated traffic. Therefore, rules applied in real-time protection should remain as specific as possible.

      In some cases, you may also need to add dependent applications when dealing with SaaS apps. For example, Gmail relies on additional services such as gstatic.com to load resources like icons, scripts, or image previews (e.g., when sending or viewing image attachments). Without allowing these dependencies, the SaaS application may not function correctly.

  7. In the Reputation step, select the Enable Logging option to store website reputation events, as shown in the image below. Reputation refers to a local URL database used to categorize websites and assign reputation scores for web filtering. This local database allows quick lookups for the most common and popular websites. Additionally, Versa offers the option to enable Cloud Lookup to complement the local database. For this use case, Cloud Lookup is not required.

    undefined
  8. In the Action step, enter the following information:
    • Actions—Leave the default action set to Allow.
    • Enable Logging—Click on the toggle button to enable it.
    • Exit on First Rule Match—Leave the default action set to disabled. as shown in the image below.

      undefined

      Note: If multiple DLP rules are configured, this option should be disabled to ensure that all rules are applied to the same session.

  9. In the Review & Submit, assign a name, then review the configuration.
  10. Click Save.

Step 2: Create the TLS Decryption Rule for the Cloud Applications (Slack)

To ensure that payloads can be inspected and DLP policies applied, a TLS decryption rule must exist for the cloud applications being tested (e.g., Slack). For detailed step-by-step configuration for creating this rule, see Decryption Rule Configuration.

Step 3. Create the Real-Time Protection Rule Using the DLP Profile 

  1. Navigate to Configure > Security Service Edge > Real-Time Protection > Internet Protection.
  2. Click + Add.

    undefined
  3. Complete the workflow steps shown in the following image.

    undefined
  4. In the Applications & URLs step, select the applications to which you want to apply our DLP module (here, Slack). 
  5. In the Users & Groups step, select the test group and then click Next. In this case, it can be the (VIP and HR) group coming from the LDAP-AD.
  6. In the Endpoint Posture step, you can apply Endpoint Information Profiles and Entity Risk Bands. In this case, leave the default settings to apply none and click Next.
  7. In the Geolocation step, you can filter by Source or Destination Geo Location. In this case, we leave the default setting (All) and click Next.
  8. In the Network Layer 3-4 step, you can filter by services (Layer 4) such as HTTP, HTTPS, DNS, ICMP, etc. You can also filter by Source & Destination (Layer 3). In this case, leave the default values and click Next.
  9. In the Security Enforcement step:
    1. Click on the Security Profiles option.
    2. Select Data Loss Prevention. Toggle the switch to enable it, then choose the profile named DLP-Profile-BADWORDS, which is the one created for this case. 
    3. Click Next.
  10. In the Review & Validate step, verify the configuration (see image below).

    undefined
  11. Click Save, and select add this rule at the top of the rule list.
  12. Publish the changes applied in Concerto and proceed with the verifications.

Step 4. Perform Tests and Validate the Behavior

To perform the tests, send bad words through Slack with the Versa SASE client enabled. 

Example of a Slack test using a global bad word sample:

undefined

 

Example of a Slack test using a custom bad word sample:

undefined

 

Example logs from Analytics:

undefined

DLP Rule Type Reference

Content Analysis

Use many prefilters before actual data is scanned and analyzed. It helps to apply DLP policies on data-in-motion effectively. Additionally, it can leverage either predefined or user-defined Data Protection Profiles, as shown in the image below.

undefined

File DLP

File-based DLP provides protection based on the configured file attributes, as shown in the image below. Administrators can define rules such as file name (using specific patterns or values), file size (by setting minimum and maximum thresholds with actions applied outside the allowed range), and SHA256 hashes (to explicitly allow or block specific files). When multiple attributes are configured, they are evaluated using AND conditions, meaning that all specified criteria must be met simultaneously for the rule to apply. Alternatively, a single attribute can be used on its own—for example, configuring only the file size range, or only the SHA256 hash—by leaving the other fields blank. This flexibility allows organizations to fine-tune protection by combining general attributes with precise identifiers, or by focusing on a single attribute when needed.

undefined

Optical Character Recognition (OCR)

OCR technology converts images into text and applies DLP policies on the extracted text data. It requires connectivity to the Versa OCR Cloud Instance, which should be reviewed with the support team. Similar to Content Analysis, it can leverage either predefined or user-defined Data Protection Profiles, as shown in the image below.

undefined

Exact Data Match

Versa's Data Loss Prevention (DLP) Exact Data Match (EDM) is an advanced security feature that detects and prevents data breaches by matching specific, sensitive data records against predefined datasets. Unlike traditional pattern-based detection, EDM allows organizations to upload structured data (such as customer records, financial information, or employee details) into a secure, hashed database. Versa DLP then scans network traffic for exact matches to these datasets, ensuring highly accurate data protection with minimal false positives.

A financial institution needs to prevent unauthorized transmission of customer account numbers and Social Security Numbers (SSNs). By using Versa's DLP EDM, they upload a securely hashed database of customer records. If an employee attempts to send an email or upload a file containing an exact match to this data, the system detects the violation and enforces security policies, such as blocking the transmission, alerting administrators, or requiring additional authorization. This ensures compliance with regulations (e.g., PCI DSS, GDPR, HIPAA) and protects sensitive business and customer information from leaks or theft.

Document Fingerprinting

It converts a standard form into a sensitive information type, which you can use to define transport rules and DLP policies.

 

DLP Rule Actions Reference

  • Allow—The content transfer is permitted without restriction. No enforcement action is taken.
  • Alert—The action is allowed, but an alert/notification is generated for visibility, monitoring, or further investigation.
  • Block—The content transfer is prevented. The user may receive a notification that the action was blocked depending on policy configuration.
  • Reject—The content transfer is actively denied, and the session is forcefully terminated. The browser typically shows a “connection reset” or similar error, and at the same time the endpoint client displays a popup notifying the user of the DLP violation.

TLS Decryption Rule Configuration

  1. Navigate to Configure > Security Service Edge > TLS Decryption > Policy Rules.
  2. Click + Add.

    undefined
  3. Complete the steps shown in the following image.

    undefined
  4. In the Decryption Enforcement step:
    1. Select the green checkmark (Decrypt traffic and inspect the server certificate).
    2. For the decryption profile, select Standard.
    3. Click Next.
  5. In the Applications & URLs step:
    1. Select the Applications tab.
    2. In the search field, add Gmail and Outlook.
    3. Click Next.
  6. In the Users & Groups step:
    1. Select your test group. In this case, it can be the VIP group coming from the LDAP-AD.
    2. Click Next. 
  7. In the Endpoint Posture step, leave the default values, and click Next.
  8. In the Network Layer 3-4 step, leave the default values, and click Next. Note that you can filter by services such as HTTP, HTTPS, DNS, and ICMP.
  9. In the Review & Validate step:
    1. Review the configuration. It should look like the image below.

      undefined
    2. Click Save, and select to add this rule ad the top of the rule list.

Sample Data for EDM Test

Confidential Employee Incident Report Form

This form is intended for the reporting of workplace incidents and policy violations. All submissions are confidential and will be reviewed by the HR Compliance Department. Please complete all required sections. Additional evidence or extended narratives should be attached as separate documents. Do not exceed the provided space in each section.

Section 1 - Employee Information

Employee Name: John Doe
Department: IT Security
Position: Senior Security Analyst
Date of Incident: 09 / 12 / 2025

Section 2 - Type of Violation

Please check one or more categories that best describe the violation (mandatory selection):
[X] Confidentiality Breach
[ ] Code of Conduct
[ ] Workplace Harassment
[ ] Safety Violation
[ ] Other (please specify) ___________________________

Section 3 - Description of Violation

Provide a concise summary of the violation in 3–4 sentences maximum. If additional details are needed, attach a supporting document.

Description: On September 12th, 2025, an employee was observed uploading a confidential HR policy document to a personal Dropbox account. The file contained sensitive disciplinary procedures. The incident was detected by the DLP monitoring system and reported for investigation.

Section 4 - Witnesses

List up to 2 witnesses with name and department. Additional names must be attached separately.

  1. Jane Smith – HR Department
  2. Michael Brown – IT Department

Section 5 - Co-Workers Involved

List any co-workers directly involved in the incident. Specify their role or relation to the case.

  1. Alice Johnson – Co-worker who shared the document link internally.
  2. N/A

Section 6 - Acknowledgement

By signing this form, the reporting employee confirms that the information provided is accurate to the best of their knowledge. The HR Compliance Department will review the case and take the appropriate action as outlined in company policy.

Supported Software Information

Releases 12.2.1 and later support all content described in this article.

  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Page type
    Topic
  2. Tags
    1. unvalidated