Summary — Data Security in Practice
What You Practised Today
The three modules demonstrate parts of a data security program: observe risk, configure and test controls, and investigate evidence. They do not build or validate a complete production deployment.
The central insight: Sensitive data can be exposed through different activities. Network inspection, endpoint controls, and browser controls provide complementary protection; deployment coverage, policy scope, and evidence still need validation.
The Dataparity Story — Complementary Exercises
| Module | What You Did | Allocation |
|---|---|---|
| Module 1 — Visibility | Reviewed SaaS usage, posture and OAuth access; explored endpoint sensitive data, user timelines, applications and connected-device inventory; assessed Copilot sharing exposure | 60 min: Labs 1–4, 20 / 15 / 15 / 10 min |
| Module 2 — Protection | Built detection logic and web/endpoint policies in Labs 5–7; tested preconfigured browser controls in Lab 8 | 90 min: Labs 5–8, 15 / 25 / 25 / 25 min |
| Module 3 — Investigation | Reviewed a pre-populated queue, incident evidence, existing notifications and state changes, available actions, and a workflow preview | 30 min: Lab 9, 20 min + knowledge check, 10 min |
Allow 15 minutes for the Module 2 prerequisites, including CloudShare access, Client Connector setup, and SSL/TLS inspection verification for the lab HTTPS traffic. Setup is included in the overall workshop estimate.
The company and personas connect the labs, not one continuous file journey. Dataparity_Q2_2025_Workforce_Financial_Summary.docx is reused in Labs 6 and 7. Lab 8 uses supplied customer text, a sensitive sample PDF from DLP Test, and a browser-viewed document. Labs 3, 4, and 9 explore independent pre-populated records; they do not trace the student's document through all three modules.
The Three Protection Layers You Tested
Kevin attempted to upload the workforce financial summary to ChatGPT or a listed alternative. With SSL inspection applicable to the lab HTTPS traffic, Inline Web DLP inspected the upload and blocked it using the DP Project Code engine. Alex reviewed the custom End User Notification and the event in Web Insights.
Two distinct local activities were blocked. Application File Access prevented Notepad++ from opening the document. Kevin then opened it in Word, copied the content, and attempted to paste into Notepad++; the Clipboard rule blocked that paste. Alex compared File Read and Paste Text events in Endpoint DLP Insights. These tests did not require a web upload.
Using Chrome with the authenticated Browser DLP extension, Kevin tested three preconfigured controls: masking sensitive values in a ChatGPT prompt, blocking the Name + SSN + CCN PDF download from DLP Test with a Download Blocked message, and displaying a viewer-identity watermark on a browser-viewed document. These are distinct outcomes: masking, download prevention, and a visual deterrent.
Detection Reuse — What the Labs Demonstrate
Lab 5 creates a custom dictionary and an engine named DP Project Code. The engine uses ALL, with each component matching more than zero times:
(Credit Cards > 0)
AND (ABA Bank Routing Number > 0)
AND (DP Project Code > 0)
|
+-- Lab 6: Inline Web DLP
+-- Lab 7: Endpoint DLP — Application File Access and Clipboard
Lab 8: Separate preconfigured Browser DLP policies
SSN is not a separate component of this engine. Lab 5 also selects SaaS Security and Outbound Email DLP as engine channels, but the workshop does not configure or test enforcement policies for those channels. It does not establish that this student-built engine powers Browser DLP or every data protection surface.
Investigation — Evidence, Not Assumed Continuity
For Module 3, return to the Enterprise Tenant using CloudShare → Credentials → SDC Credentials, not the Module 2 Student Admin login. Lab 9's example is an existing Inline incident: attachment, type post, at dlptest.com/https-post/, with rule CC SSN HIPAA Block. It is not a verified continuation of Kevin's student-tenant tests.
Priya reviewed the existing User Notifications table and attributed State Changes, explored the Actions menu without executing actions, and previewed Auto Notify User and Concurrently Escalate without configuring it. A notification record does not by itself prove which workflow produced it.
Key Takeaways
1. Visibility provides context. SaaS posture, sharing exposure, endpoint data, user activity, applications, and device inventory help identify questions to investigate before tuning enforcement. In Lab 3, User Risk Profile is calculated in ZIA, not from the displayed sensitive-file count. A device Allow record does not prove successful sensitive-data exfiltration, and a recorded device association does not mean it is connected now.
2. Protection outcomes differ. The exercises cover an upload block, a file-read block, a clipboard-paste block, browser masking, sensitive-download blocking, and watermarking. Validate the outcome and evidence for each activity rather than treating all controls as identical.
3. Shared detection still needs scoped policies. Labs 6 and 7 reuse Lab 5's engine, while their rules select different activities and applications. Lab 8 is a separate preconfigured experience. Other browsers, devices, destinations, and data types require their own coverage validation; three layers do not guarantee complete protection.
4. Investigation closes the learning loop. Read-only investigation shows how evidence, notification history, and workflow previews inform response decisions. You did not send notifications, escalate incidents, or configure automation in Module 3.
5. User guidance matters. The custom block message in Lab 6 and the existing notification history in Lab 9 illustrate how clear explanations and follow-up can support safer behaviour. They are separate exercises, not proof that one user's actions produced every record.
Learn More
Ready to go deeper? Explore Zscaler's data security platform:
Whitepapers, solution briefs, and architecture guides for data security use cases covered today — and beyond.
Share Your Feedback
We'd love to hear about your experience today. Takes less than 2 minutes.
Your feedback directly shapes the next iteration of this lab. 6 questions, 2 minutes.