A DLP (Data Loss Prevention) detects and block a potential data leak due to a specific context (for instance, a company). In order for us to design a related service within policies we must be aware of: The kind of application acting as a vector (ie. Dropbox, MS-Teams, e-mail etc). The typical profile to match a sensitive info template (ie. Brazil´s CPF, credit card, zip code etc). The file´s attributes (in case the info is stored into one, in transit). The data leak source (either a device or a branch network). In this project, the DLP we rely on is part of a SASE (Secure Access Service Edge) solution deployed inline with the client(s). Then the Internet traffic from the brach is monitored as shown at the topology: For the first case a credit card picture upload was tested against Dropbox web app. PS. that credit card is useless by the moment I´m publishing this project, for obvious reason. It was necessary to configure the rule to include OCR (Optical Character Recognition) analysis once we´re using a JPEG file. By the way, it is imperative to validade a sample of data/files while we create the rules in order to avoid false positives and false negatives. Then we have the following DLP rule. And the file used for the test… When we try to upload the file throughout Dropbox, a blocking message pops up right away and an event is generated on the SASE management console. Just before that, another event had been generated which is due to the traffic decription from a TLS inspection rule. That is necessary because prior to uploading the file, the application was identified. For the second test, a list of random Brazil´s CPFs in plain text was uploaded to PasteBin web app. There is already a built-in rule for that but not as comprehensive as the one customized from REGEX (Regular Expression). A profile called “CPF ajustado” was configured so: ^\d{3}\.\d{3}\.\d{3}\-\d{2}$ Sensitive info was sent as following: And blocking came out right away: That generated an event on the management console: