A network DLP appliance at the company's internet edge reports no policy violations for the quarter, yet an audit finds that sensitive files were uploaded to an unsanctioned web service over HTTPS during that period. What is the most likely cause and remedy?
Select an answer to reveal the explanation.
Short Explanation
A DLP appliance staring at HTTPS traffic is like a mail inspector handed sealed envelopes; it can see the address but not the letter. You either open the envelope with TLS inspection or check the letter before it's sealed with endpoint DLP. More signatures won't help if it can't read the content at all.
Full Explanation
Network DLP works by inspecting content as it passes through a monitoring point. When traffic is encrypted with TLS, the appliance sees only connection metadata such as destination and volume, not the payload, so content rules cannot match and sensitive uploads pass without alerts. This is a well-known DLP limitation in cloud environments where nearly all traffic is HTTPS. The remedies are to terminate and inspect TLS at a controlled egress point, with appropriate privacy and legal review, or to move inspection to the endpoint, where agents see content before the browser encrypts it, often combined with CASB controls for sanctioned services. DLP policies are not limited to structured data; content inspection with patterns, fingerprints and keywords routinely covers documents and other unstructured files. A larger signature set cannot help when the payload is unreadable, because the problem is visibility, not pattern coverage. HTTPS uploads are not blocked by DLP by default; the audit finding is consistent with encrypted traffic passing uninspected, and there is no basis for assuming email was used. Exam caveat: TLS inspection introduces certificate trust and privacy considerations and is often exempted for sensitive categories. Operational check: send a seeded test file over HTTPS and confirm detection.