Learning Path

Module Overview

Meet the Team

Lab Tenants

Before enforcing policies, Alex explores Dataparity's SaaS usage, corporate and personal instances, endpoint data and activity, and Microsoft 365 sharing exposure. Lab 3 connects sensitive-file findings with a user's timeline, endpoint applications, and connected-device inventory. These are pre-populated observations, not incidents generated by the student's later tests.

Module Objectives​

Labs in This Module​

Lab 1 — Visibility into Shadow IT and SaaS Usage

Log Into the Enterprise Tenant​

1. Open your assigned CloudShare environment and select Credentials in the left menu.
2. Scroll to SDC Credentials. Locate the Admin User login URL, Admin Username, and Password.
3. Open sdc.zslogin.net in your browser and sign in to the Solution Demo Centre using those SDC Admin credentials.

Use the SDC Credentials section, not the Zscaler Tenant / Student Admin credentials above it.

Use Experience Center Nav 1.0​

After logging in to your assigned Zscaler Lab tenant / Solutions Demo Center tenant, you should be presented with the Experience Center Nav 1.0 user interface.

Skip the pop-up to try the new navigation.

Task 1: Discover Shadow IT using the SaaS Security Report​

Analytics → Experience Center

Locate the Switch to Existing Reports toggle in the lower-left corner and ensure it is enabled.

Analytics → SaaS Security Report

Observe the following metrics in the Overview section, then review Top Application Categories and Applications by Risk Index:

Locate an application marked as Unsanctioned — for example, Dropbox — and click the application name to view detailed risk information.

Review the application risk details:

• Application Status — Sanctioned or unsanctioned
• Risk Index — Relative risk level
• Activities Supported — Upload, Download, Share, Edit, Delete

Task 2: Discover Application Instances​

Analytics → Instance Discovery Report

Select the desired time range (for example, Last Quarter) and choose an application such as Gmail to review detected instances.

Review the list of detected domains associated with the selected application. Click a domain such as gmail.com to investigate usage details. Then click the Analyze More button to drill deeper into the domain activity.

Observe the list of users interacting with the selected domain and review their activity:

• Upload Bytes
• Download Bytes
• Number of Transactions
• Last Accessed

Task 3: Automatic Content Classification Using ML-Based Detection​

Analytics → Data Discovery Report

Ensure Switch to Existing Reports is enabled. Review the dashboard showing detected sensitive files and ML categories.

Review the dashboard widgets — Top 10 Users, Timeline for Files in Top ML Categories, Top 10 Applications — and click Analyze More to investigate further.

Select a Content Type such as Immigration and a Subcategory such as Asylum and Refugee. Review the associated Application and User.

Lab Summary​

In this lab you established foundational visibility into SaaS usage and sensitive data activity:

These capabilities provide the visibility required before implementing data protection and enforcement controls in subsequent labs.

Explore available filters, tabs, and drill-downs beyond the examples. Dashboard values and application lists may vary.

Task 1 — SaaS Security Posture Management (SSPM)​

Step 1 — Navigate to the SSPM Portal​

1. In the Experience Center, enable Switch to Existing Reports and open Analytics → SaaS Security Report.
2. Select Posture Management.
3. Click Posture Management ↗ to launch the SSPM portal at apptotal.zscaler.com.

Step 2 — Review the SSPM Dashboard​

Review:

• Enabled Controls — active controls and severity breakdown.
• Status Summary — Fail, Pass, Partial, Pending, and Disabled.
• Controls by Platform — compare findings across SaaS platforms.
• Failed Controls Remediation Matrix — compare severity and remediation effort.

Select a control and explore Remediation, Compliance, Assets, Audit log, and Notes. Identify what failed, which assets are affected, and the recommended remediation.

Step 3 — Prioritize Failed Controls​

Review the Failed Controls Remediation Matrix. Start with High Severity / Low Effort findings, then compare other cells to understand the trade-off between risk and remediation effort.

Step 4 — Review Compliance Mapping​

Select Compliance in the left navigation.

• Frameworks: expand a framework to review its controls and pass/fail results.
• Platforms: compare compliance findings across SaaS platforms.
• Review the mapping table's Framework, Control ID, Security Check count, Status, and Tenant.

Consider which failed control would be most useful to address first, based on severity, effort, and compliance relevance.

Task 2 — Third-Party Application Governance​

Step 5 — Review the App Dashboard​

Select App Dashboard in the SSPM portal.

Review Active Apps, Risky Apps, Affected Users, and Deactivated Apps. Then explore:

• Apps by Classification — Sanctioned, Unsanctioned, Reviewing, and Unclassified.
• Apps by Finding Type — Potentially Harmful, Dormant, and Overprivileged.
• Top Apps by Risk Score and Highlights — identify apps worth investigating.

Step 6 — Review Active Apps and App Detail​

Select Apps → Active Apps (App Status: Enabled). Compare each app's Publisher, Platform, Users, Risk Score, and Access Type.

Open an app, such as Keeper® Password, and review:

Compare the permissions granted with the app's business purpose. OAuth integrations can access SaaS data directly, making this an important view alongside inline traffic inspection.

Key Takeaways​

• SSPM: identify SaaS misconfigurations and affected assets.
• Remediation and compliance: prioritize findings using severity, effort, and framework mappings.
• App Governance: review third-party permissions, activity, and risk.

What comes next: Lab 3 moves to endpoint data, user activity, applications, and connected-device inventory.

1. Open the Endpoint Data Scan Dashboard​

Step 1 — Launch Zscaler Internet Access​

Log in to the Solution Demo Centre portal at sdc.zslogin.net/portal, then select Zscaler Internet Access.

Step 2 — Navigate to Endpoint Data Scan​

In the ZIA console, open Dashboard and select Endpoint Data Scan under Reports.

Step 3 — Review the Dashboard Layout​

Locate the summary tiles, Top Users with Sensitive Data, and Sensitive File Range Distribution.

2. Review the Endpoint Data Posture​

Step 4 — Review the Summary Tiles​

Review the three summary tiles at the top of the dashboard. Numbers may vary on your dashboard. Values shown below are screenshot examples, not expected results.

Compare the proportion of users with sensitive data and the proportion of scanned files classified as sensitive.

3. Review Users and Endpoints​

Review Top Users with Sensitive Data in the dashboard overview.

User Risk Profile is calculated in ZIA, not from the sensitive-file count shown here. Review it alongside the endpoint data findings.

Explore the Department, User Group, and Sensitive Data selectors to compare results.

4. Review Data Classifications​

Step 5 — Explore the Classification Widgets​

Scroll down to the classification widgets.

Use View All where available. Compare classifications, departments, and file types; a file can match more than one classification.

5. Review the Sensitive File Range Distribution​

Review Sensitive File Range Distribution in the dashboard overview. The example groups users into:

• More than 100 files
• 25 – 100 files
• Less than 25 files

Check whether sensitive data is concentrated among a few users or spread across the user population.

6. Investigate a User's Endpoint Data​

Step 6 — Open User Investigation​

Select User Investigation using the people icon in the left navigation. Use the User filter to locate 2305990-sales@thezerotrustlab.com and open the user. You can also sort by Incidents to explore other users.

Step 7 — Review the User Overview​

Confirm the selected user is 2305990-sales@thezerotrustlab.com, then review Overview.

Step 8 — Inspect Data at Rest​

Open Data at Rest to review scan results and individual files.

Review Total Files Scanned, Last Scan Time, Files with Sensitive Data, Top Sensitive Data, and Sensitive Data by File Type.

In Top Sensitive Files Discovered, locate Customer Credit Cards.xlsx if present, or choose another file. Review its File Size, DLP Engines, AI & ML Categories, and Path. Explore View All and additional classification matches where available.

Step 9 — Review the User Timeline​

Open Timeline and select an incident. The screenshot uses PCI High Print Block from August 27, 2026 at 20:11; if it is not available, select another incident and review the same fields. Incident numbers and types may vary.

Compare other events and use the available Timeline filters. A Block action records a prevented attempt; an Allow device event does not establish that a sensitive-file transfer succeeded.

7. Explore Endpoint Applications and Connected Devices​

Step 10 — Explore Application Investigation​

Select Application Investigation in the left navigation and open Overview.

Open the Inventory tab and explore available application details. Compare categories and versions rather than stopping at the screenshot example.

Step 11 — Explore Connected-Device Inventory​

Select Inventory in the left navigation, then Removable Storage.

Review Usage Distribution by Department, Usage Distribution by Action, and these device fields:

• Device-Friendly Name, Serial Number, VID, and PID
• Endpoint Name and User
• Action

Use the User filter to explore devices associated with 2305990-sales@thezerotrustlab.com. The screenshot includes a TOSHIBA TransMemory USB Device associated with Demo1-Prevent.

Open linked device names and explore Portable Device, Printer, CD/DVD, and Floppy Disk where available. Inventory shows recorded device associations, not necessarily devices connected right now.

8. Summarise the Complete Endpoint Picture​

Questions that you can find answers to:

• How many users and files contain sensitive data?
• Which classifications, departments, and file types appear most often?
• What data and devices are associated with the investigation user?
• What application, channel, destination, rule, and action appear in an incident?
• Which endpoint applications or versions warrant further investigation?
• Which connected-device records can you associate with an endpoint and user?
• What else did you discover through filters, tabs, or drill-downs?

1. Review the Microsoft Copilot Readiness Dashboard​

Analytics → SaaS Workflows → Microsoft Copilot Readiness Assessment

Review the summary tiles at the top of the page. Focus on:

• Total No. of Sensitive Assets
• Sensitive Assets Exposed Org-Wide
• Sensitive Assets Exposed with Specific Users

Review the Assets Exposure section. Observe the exposure categories:

• Assets Exposed Org-Wide
• Assets Exposed Using External Link
• Sensitive Assets Exposed with > 1000 Users

2. Review All Exposed Sensitive Assets​

In the Assets Exposure section, click View All.

Review the list of exposed sensitive assets. Focus on:

Select one or more assets and review the available remediation options. Example action: Apply MPIP label.

Navigate back to the dashboard by clicking Microsoft Copilot Readiness Assessment in the breadcrumb.

3. Investigate Top Risk Assets​

In the Top Risk Assets widget, click the data type with the highest count (for example, Credit Card).

Review the assets associated with that sensitive data category. Identify:

• Where the files are stored (OneDrive or SharePoint)
• Who owns the files
• How the files are shared
• Whether they are exposed Org-Wide, via External Link, or to a limited set of users

4. Review Top Owners of Exposed Sensitive Data​

Review the Top Owners widget. Focus on the Org-Wide tab first. Observe which users are associated with the most exposed sensitive assets and consider whether the sharing pattern looks intentional, excessive, or risky.

5. Validate Copilot Readiness Risk​

Return to the dashboard and summarize the findings:

Discuss why this matters before enabling Microsoft Copilot:

• Copilot can index and retrieve content based on the user's existing access
• Broad sharing increases the chance of unintended data exposure
• Sensitive content should be reviewed and remediated before AI rollout

Lab Environment Overview​

Your lab environment consists of two components:

Part 1 — Access Your Lab Environment​

Step 1 — Locate Your Lab Tenant Credentials​

1. Open your assigned CloudShare environment and select Credentials in the left menu.
2. Under Zscaler Tenant, locate the Zscaler Admin Console link, Student Admin Username, and One Time Password.
3. Use these Student Admin credentials for Module 2, not the SDC Credentials listed below them.

Step 2 — Access the Lab VM​

In CloudShare, open the Windows VM tab, shown as Windows 11 x64 in the screenshot. Use VM List to locate the VM if needed.

Verify the VM is ready:

• Zscaler Client Connector icon visible in the system tray
• File Dataparity_Q2_2025_Workforce_Financial_Summary.docx is on the Desktop

Step 3 — Log Into the Lab Tenant (Module 2)​

From your laptop browser, open the Zscaler Admin Console link — console.zscaler.com — and sign in with the Student Admin Username and One Time Password from CloudShare.

If prompted to change the password on first login, set a new password and use it for subsequent admin-console and Client Connector logins.

Part 2 — Configure Zscaler Client Connector (Lab Tenant)​

These steps configure the Client Connector forwarding profile and app policy on the lab VM. This is required for Labs 6, 7, and 8 to enforce DLP policies on endpoint traffic.

Step 4 — Log Into the Admin Console​

If you are not already logged in from Part 1, go to https://console.zscaler.com from your laptop browser and log in with your Student Admin credentials.

Step 5 — Verify SSL Inspection​

1. In the Lab Tenant admin console, search for ssl.
2. Select SSL/TLS Inspection Policy under Policies, as shown below.
3. Confirm that SSL inspection is enabled for the lab traffic. The screenshot shows an Enable SSL rule with Criteria: Any and Action: Inspect. Check that the applicable rule uses Inspect, taking rule order and existing exemptions into account.

Step 6 — Navigate to Forwarding Profiles​

Click the search bar at the top of the admin console and type forwarding profile (1). Select Forwarding Profile for Platforms from the results (2):

Step 7 — Add Forwarding Profile​

Click Add Forwarding Profile and configure:

• Profile Name: HandsOnLab_FW_Profile

Step 8 — Configure Windows Driver and ZIA Tunnel Settings​

In the WINDOWS DRIVER SELECTION section, then the FORWARDING PROFILE ACTION FOR ZIA section:

• Tunnel Driver Type: Packet Filter-Based (1)
• On-Trusted Network: Tunnel (2)
• Tunnel version selection: Z-Tunnel 2.0 (3)

Step 9 — Configure VPN, Off-Trusted Network, and ZPA​

Still in the ZIA section, tick the checkboxes:

• VPN-Trusted Network: Check Same as "On-Trusted Network" (1)
• Off-Trusted Network: Check Same as "On-Trusted Network" (2)

Then, in the FORWARDING PROFILE ACTION FOR ZPA section (3):

• On-Trusted Network: Tunnel
• VPN-Trusted Network: Same as "On-Trusted Network"
• Off-Trusted Network: Same as "On-Trusted Network"

Click Save (4).

Step 10 — Navigate to Windows Platform Settings​

Click the search bar and type windows (1). Select Windows (previously part of 'App Profiles') from the results (2):

Step 11 — Add Windows App Policy​

Click + Add Windows Policy and configure:

• Name: HandsOnLab_App_Profile (1)
• Rule Order: 1 (2)
• Status: Enabled (3)
• Forwarding Profile: HandsOnLab_FW_Profile (4)
• Install Zscaler SSL Certificate: On (5)
• Notification Template: Legacy Notification Settings (6)
• User Groups: All Selected (7)

Leave all other settings at their defaults. Don't click Add (8) yet — first complete Step 12 in the same dialog.

Step 12 — Enable Data Protection / Endpoint DLP​

Scroll down in the same Add Windows Policy dialog:

• In the AI & DATA SECURITY section — Install Endpoint ZDP: On (1)
• Expand NOTIFICATION AND LOGGING (2):
  • Use Zscaler Notification Framework: On (3)
  • Bring Notification to Focus: On (4)

Then click Add to save the policy.

Part 3 — Setup VM and Login to Zscaler Client Connector (ZCC)​

Step 1 — Login to the VM​

Return to the Windows VM tab in your assigned CloudShare environment. If a Windows sign-in is required, use the VM credentials supplied for your environment.

Step 2 — Open and Login to Zscaler Client Connector​

Locate the ZCC icon in the system tray (bottom right of the taskbar) ①, right-click it, and select Open Zscaler ②. The Zscaler Client Connector window opens ③.

Use your Lab Tenant Student Admin username from Part 1, Step 3 and its current password to log in. If you changed the one-time password, use your updated password here.

Tip — Copy/Paste: If direct paste does not work, use the clipboard controls available in your VM console, or enter the credentials manually.

Step 3 — Verify All Modules Are Active​

Once logged in, the ZCC dashboard opens. Confirm the following:

• Authentication Status: Authenticated (green)
• Service Status: ON
• All modules (Private Access, Internet Security, Digital Experience, Data Protection) are visible and active

Step 4 — Verify Traffic Is Being Steered to Zscaler​

Open a browser inside the VM and navigate to https://ip.zscaler.com. The page should confirm your traffic is passing through the Zscaler Zero Trust Exchange and display your Zscaler proxy details.

Quick Reference — All Credentials​

Module 2 Overview

Alex moves from visibility to protection: build detection logic in Lab 5, configure and test Inline Web and Endpoint DLP in Labs 6–7, then test preconfigured Browser DLP controls in Lab 8 as Kevin. The DP Project Code engine combines Credit Cards AND ABA Bank Routing Number AND the custom DP Project Code dictionary; Labs 6 and 7 reuse it. Lab 8 uses separate preconfigured policies for masking, sensitive-download blocking, and watermarking.

Module Objectives​

Labs in This Module​

Step 1: Navigate to DLP Dictionaries and Review Predefined Dictionaries​

Policies → Data Protection → Common Resources → Dictionaries & Engines

Review the list of predefined dictionaries. Locate and observe the following two dictionaries used in this lab:

• Credit Cards
• ABA Bank Routing Number

These predefined dictionaries require no changes — you will add them directly to the DLP engine in Step 3.

Step 2: Create a Custom DLP Dictionary​

Click Add DLP Dictionary and configure with the following settings.

Add the following detection patterns:

Set the action to Count Unique.

Then add the following contextual phrases:

• Confidential
• Internal Only
• Salary
• Payroll
• Project Codes
• Internal

Set the phrases' action to Count All, then click Save to save the custom dictionary.

Step 3: Create a Detection Logic using a DLP Engine​

Switch to the DLP Engines tab, then click + Add DLP Engine.

Under Channels, select the following (leave DSPM unchecked):

• Endpoint DLP
• Inline Web
• SaaS Security
• Outbound Email DLP

Then add the following detection components, each with condition > 0:

• Credit Cards
• ABA Bank Routing Number
• DP Project Code

Review the expression preview. It should display:

((Credit Cards > 0) AND (ABA Bank Routing Number > 0) AND (DP Project Code > 0))

All three dictionaries must match: Credit Cards AND ABA Bank Routing Number AND the custom DP Project Code dictionary. Click Save to save the engine.

Step 4: Understand How Detection Logic Supports Enforcement​

This detection logic will be reused in the following labs:

Lab 8 separately tests preconfigured browser policies for copy-paste controls; it does not reuse this engine.

Scenario Overview​

This lab demonstrates the complete Inline Web DLP workflow end-to-end:

Use the supplied payroll report to test the Lab 5 engine. DP Project Code requires all three dictionaries to match: Credit Cards AND ABA Bank Routing Number AND the custom DP Project Code dictionary, each with a count greater than zero. Payroll data or SSNs alone do not satisfy this engine.

Task 1 — Admin Experience: Configure Inline DLP Protection​

Step 1 — Navigate to End User Notification (EUN)​

Alex creates a custom End User Notification to explain why uploads containing sensitive corporate data are blocked. Clear user coaching reduces helpdesk escalations and reinforces security awareness.

Navigate to:

Step 2 — Add a Custom EUN​

Navigate to the Client Connector tab and click Add Custom Message. Select channel Inline Web.

Step 3 — Add the Custom Message Text​

Enter the message that will be displayed to end users when a policy violation occurs. The message should identify the policy, explain the reason for the block, and provide a contact path.

Step 4 — Navigate to Inline DLP Policy Creation​

Navigate to the Inline DLP policy creation page:

Step 5 — Configure Basic Policy Information​

The policy window is large and split across multiple sections. The first section covers the foundational policy settings:

• Policy Name: Block Sensitive Corporate Data Uploads
• Rule Order: Set appropriately for your policy stack
• User Scope: All users (or scoped to the Dataparity employee group)
• Destination / Application Scope: Any destination for this lab (this includes sanctioned and unsanctioned destinations)

Step 6 — Configure Policy Criteria​

In the Criteria section, select the Unified DLP Engine created in Lab 5 — DP Project Code.

This is the key connection point: the detection logic built in Lab 5 is now referenced by an enforcement policy. Lab 7 reuses this engine for Endpoint DLP; Lab 8 uses separate, preconfigured browser policies.

Step 7 — Configure Policy Action​

In the Action section:

• Set Action = Block
• Select the End User Notification created in Steps 1–3

This completes the Detection → Enforcement → User Coaching → Logging chain.

Task 2 — User Experience: Prevent Data Exfiltration​

Step 8 — Attempt the Upload​

Kevin opens a browser on the lab VM and navigates to https://chatgpt.com — a GenAI platform — to get an AI-powered analysis of the sensitive data.

He selects Dataparity_Q2_2025_Workforce_Financial_Summary.docx from the desktop and initiates an upload.

Expected result when the upload is inspected and matches the policy:

1. The lab VM's upload traffic is steered through Zscaler with SSL inspection
2. Inline DLP inspects the file content
3. The DP Project Code engine matches all three dictionary conditions
4. The policy blocks the upload; verify the notification and corresponding Web Insights event

Step 9 — Kevin Receives the Block Notification​

Instead of a successful upload confirmation, Kevin sees the custom End User Notification Alex configured in Task 1.

Task 3 — Admin Experience: Review Web Insight Log​

Step 10 — Navigate to Web Insight Logs​

Navigate to the Web Insight log viewer:

Step 11 — Apply DLP Engine Filter​

Apply a filter to isolate DLP-triggered events:

Filter: DLP Engine = DP Project Code

Step 12 — Review Violation Metadata​

Locate your upload attempt using its time, signed-in lab identity, and chosen destination. Kevin is the scenario persona; your event should show the actual test identity. Expand the matching event to review the violation record:

The values below are examples, not a required literal match to the screenshot. Verify your actual identity, VM/IP, chosen destination, rule, engine, file, and action. Display labels and screenshot values can vary.

Prerequisite — Verify Notepad++ on the Lab VM​

Notepad++ is pre-installed on the CloudShare VM, as described in Pre-Requisites for Module 2. Confirm it is available before Task 1. If it is missing, ask your facilitator to check the VM setup.

Complete Lab 5 first: both rules in this lab use the DP Project Code engine.

Task 1 — Block Application File Access to Sensitive Documents​

Step 1 — Navigate to Endpoint DLP Policy​

Navigate to the Endpoint DLP policy page:

Review the policy list. You will create the Application File Access rule below. If your assigned tenant already contains the same lab rule, review and update it rather than creating a duplicate.

Step 2 — Navigate to Endpoint DLP Resources​

Before creating the AFA rule, review how applications are defined. Navigate to:

Step 3 — Review the Notepad++ Application Definition​

In DLP Resources, click the Applications tab and search for notepad. Click the eye icon to view the Notepad++ (Windows) definition.

Application definitions use Original File Name + File Name + Digital Signature to uniquely identify an application. The digital signature check ensures the policy applies to the genuine Notepad++ binary — a renamed or unsigned copy would not match.

Step 4 — Create the Application File Access Rule​

Navigate back to Endpoint DLP Policy and click + Add DLP Rule:

Callout 1 — Rule Name: Block Sensitive Data with AFA Callout 2 — Channel: Application File Access Callout 3 — Content Matching: Select DLP Engines Callout 4 — DLP Engines: DP Project Code — same engine from Lab 5 Callout 5 — Action: Block Callout 6 — Click Save

Step 5 — Push the Updated Policy to the Endpoint​

After saving the rule, the policy must be pushed to the endpoint agent. On the lab VM:

1. Right-click the Zscaler icon in the system tray
2. Click Open Zscaler
3. Navigate to Data Protection
4. Click Update DLP Policy

Callout 1 — ZCC Connectivity: Service Status ON Callout 2 — Right-click ZCC tray icon → Open Zscaler Callout 3 — Click Data Protection Callout 4 — Click Update DLP Policy

Step 6 — Kevin Attempts to Open the File in Notepad++​

Kevin right-clicks Dataparity_Q2_2025_Workforce_Financial_Summary.docx on the desktop and selects Edit with Notepad++.

The moment Notepad++ attempts to read the file, Application File Access intercepts at the OS layer — before any data reaches the application.

Step 7 — Endpoint DLP Blocks the File Read​

Kevin sees two simultaneous events:

Zscaler block notification:

Blocked An application opened one or more files that contain potentially sensitive data. This activity was blocked by your organization.

• File Name: Dataparity_Q2_2025_Workforce_Financial_Summary.docx
• Destination: notepad++.exe

Notepad++ error dialog:

ERROR — Can not open file C:\Users\Zscaler\Desktop\Dataparity_Q2_2025_Workforce_Financial_Summary.docx

Notepad++ never displayed a single byte. The OS-level block happened before the application received any data.

Step 8 — Navigate to Endpoint DLP Insights​

Callout 1 — Click Logs in the top nav Callout 2 — Select Insights Callout 3 — Click Endpoint DLP Insights

Step 9 — Review the AFA Violation Log​

Locate the Application File Access event for your test. Screenshot counts and engine labels may differ; verify your event against the rule you configured:

Activity Type: File Read is the key differentiator from the Clipboard channel. This tells Alex exactly what Kevin attempted — a direct file read by an unauthorized application — not a network upload or clipboard operation.

Task 2 — Block Clipboard Exfiltration to Local Applications​

Step 1 — Navigate to Endpoint DLP Policy​

As Alex, open the Endpoint DLP policy page:

The screenshot shows an existing Clipboard rule. Rule names and order may differ in your tenant.

Step 2 — Configure the Clipboard DLP Rule​

Click + Add DLP Rule and configure Block Cut_n_Paste Sensitive Data below. If that lab rule already exists, edit it instead.

Click Save.

Step 3 — Push Updated Policy to Endpoint​

After saving the Clipboard rule, push the policy to the endpoint:

Right-click ZCC tray icon → Open Zscaler → Data Protection → Update DLP Policy

Step 4 — Kevin Opens the Document in Word and Selects Sensitive Content​

Kevin opens Dataparity_Q2_2025_Workforce_Financial_Summary.docx in Microsoft Word — which is allowed, as Word is a sanctioned application. He selects the entire document so that the Credit Cards, ABA Bank Routing Number, and DP Project Code signals required by the engine are included.

Kevin presses Ctrl+C to copy. He then opens Notepad++ and attempts Ctrl+V to paste.

Step 5 — Endpoint DLP Blocks the Paste​

Instead of pasting, Kevin sees a Zscaler block notification:

Blocked The copied content contains potentially sensitive data. This activity was blocked by your organization.

• Destination: notepad++.exe

Notepad++ remains empty — not a single character was pasted.

Step 6 — Navigate to Endpoint DLP Insights​

Step 7 — Review the Clipboard Violation Log​

Apply filter: Channel = Clipboard → Run Query

Compare Activity Type: Paste Text (Task 2) vs Activity Type: File Read (Task 1). Two distinct OS-level events, two different channels, one unified Endpoint DLP Insights log — giving Alex a precise audit trail of exactly what Kevin attempted at each layer.

Lab Summary​

In this lab:

1. Alex reviewed the Notepad++ application definition in DLP Resources
2. Alex created an Application File Access rule using the DP Project Code engine
3. Alex pushed the updated policy to the endpoint via ZCC → Update DLP Policy
4. Kevin right-clicked Dataparity_Q2_2025_Workforce_Financial_Summary.docx → Edit with Notepad++ → blocked at OS file read layer
5. Alex confirmed Activity Type: File Read in Endpoint DLP Insights
6. Kevin opened the file in Word (allowed), copied sensitive content, attempted to paste into Notepad++ → blocked at OS clipboard layer
7. Alex confirmed Activity Type: Paste Text in Endpoint DLP Insights — two distinct channels, one unified log

Key Takeaway: Endpoint DLP closes the OS-layer gaps that proxy and browser DLP cannot cover. Application File Access and Clipboard are two complementary channels that together prevent both direct file extraction and content copy/paste exfiltration — entirely off-network.

Prerequisite — Log In to the Chrome Extension​

On the same CloudShare VM, authenticate the Chrome extension with the SDC Admin credentials listed in Pre-Requisites for Module 2. This extension login is separate from the Student Admin login used by ZCC. Lab 8 uses preconfigured Browser DLP policies; it does not require the DP Project Code engine you created in the Lab Tenant.

Prereq Step 1 — Open the Extension Sign-In Website​

Open Google Chrome on the lab VM and go to enterprise.onsqrx.com.

Prereq Step 2 — Enter the Tenant Identifier​

Enter dlpdemo as the tenant identifier and click Continue.

Prereq Step 3 — Enter the Lab User ID​

Enter the Admin Username from CloudShare → Credentials → SDC Credentials.

Prereq Step 4 — Select Okta SSO​

Click Okta SDC SSO to proceed to identity provider authentication.

Prereq Step 5 — Complete IDP Authentication​

Complete the identity-provider login with the same SDC Admin Username and its assigned password.

After signing in with your SDC Admin credentials, you will see the "All set!" confirmation screen. This signs you in to the installed Browser DLP extension. Do not click "Sign in as Admin" — it is not required for this lab. Close this tab and return to the lab guide.

Task 1 — Mask Sensitive Values Before GenAI Submission​

Steps​

Kevin opens ChatGPT in Chrome and pastes the following sample customer record. Use this supplied example rather than real customer data:

Customer name: Daniel Reeves
Email: daniel.reeves@acme-corp.com
Phone: +1 415-238-7712
SSN: 531-72-8943
Issue: Customer reported duplicate billing for invoice INV-4482 and
wants confirmation once the refund is processed.

As soon as Kevin pastes the content, the Browser-Based DLP extension detects the sensitive values — SSN, email, phone number — and masks them inline before the prompt is submitted. Kevin is notified that sensitive content has been redacted.

Task 2 — Block Sensitive File Downloads​

Step 1 — Select the Sample and Download Format​

1. In Chrome on the lab VM, open https://dlptest.com/sample-data/.
2. Under PII / PCI Test Datasets, select Name + SSN + CCN (callout 1). This dataset contains fabricated names, Social Security numbers, and credit card numbers.
3. In the dialog, click Download PDF (callout 2).

Step 2 — Verify the Download Is Blocked​

Confirm that the Download Blocked notification appears (callout 3) with the message:

File Download has been blocked based on policy

The screenshot also shows dlptest-name-ssn-ccn.pdf marked Removed in Chrome's downloads list. The expected outcome is that the PDF is not available as a successful download.

Select I UNDERSTAND to dismiss the notification. If the file downloads successfully or only a generic browser error appears, confirm the Browser DLP extension is authenticated and ask your facilitator to check the demo policy.

Task 3 — Dynamic Watermark with Viewer Identity​

Steps​

Kevin opens the following sensitive Dataparity document in Chrome — this document has been tagged for dynamic watermarking by the Browser-Based DLP policy:

As soon as the document renders in the browser, the extension overlays a dynamic watermark containing Kevin's identity — user name, email, and timestamp — across the document view.

Module 3 Overview

After Alex's policy work and Kevin's tests, Priya explores a separate, pre-populated incident queue in Zscaler Workflow Automation (ZWA). Review incident evidence, existing user notifications and state changes, available actions, and a workflow template preview. The Lab 9 example is an Inline incident for an attachment/post at dlptest.com under CC SSN HIPAA Block — not the student's Lab 6 or 7 document or DP Project Code policy. Allow 20 minutes for Lab 9 and 10 minutes for the knowledge check.

Module Objectives​

Lab in This Module​

Background​

Return to the Enterprise Tenant using CloudShare → Credentials → SDC Credentials, as described in Lab 1. Keep the Experience Center Nav 1.0 interface for the navigation shown here.

As Priya, investigate a pre-populated inline DLP incident in Workflow Automation (WFA). Review its file metadata, policy, notifications, and state-change history to understand how incidents are handled.

Incident counts, dates, and available records may differ from the screenshots. If the example record is unavailable, select another Inline incident and review the same fields.

Task 1 — Navigate to Workflow Automation and Open the Incidents Queue​

Workflow Automation is accessed from the main Zscaler console navigation bar. Follow the steps below to reach the Incidents list.

Steps​

Step 1 — Open Administration → Workflow Automation

From the top navigation bar, click Administration. In the drop-down, locate the Workflow Automation section on the far right and click it to switch context.

Callout 1 — Click Administration in the top nav. Callout 2 — Select Workflow Automation from the sub-menu. Callout 3 — Under Incident Management, click Incidents.

Step 2 — Review the Incidents Landing Page

You are now on the Incidents list. It brings together incident records from the sources integrated with this tenant.

Observe the following on this page:

The Priority and Severity quick filters at the top right let you surface Critical and High incidents instantly without opening the advanced filter panel.

Task 2 — Filter by Source DLP Type​

Use the Filters panel to isolate the available incident sources relevant to your investigation.

Steps​

Step 1 — Open the Filters Panel

Click the filter icon (funnel) at the top right of the Incidents toolbar.

Callout 1 — Click the filter funnel icon. Callout 2 — Select Source DLP Type from the filter category list. Callout 3 — Check Endpoint and Inline under Include to see violations from those two channels side by side.

Available Source DLP Types:

• Email — incidents from ZIA Email DLP
• Endpoint — incidents from Zscaler Client Connector endpoint DLP agent
• Inline — incidents from ZIA inline proxy (web traffic)
• SaaS Security — incidents supplied by integrated SaaS data-protection sources

Task 3 — Drill Into an Incident: Full Triage Walk-Through​

Now open one of the inline incidents to see the complete forensic picture Zscaler captures.

Steps​

Step 1 — Open the Incident Details Page (Overview)

Click on Transaction ID 53-1282-7639608590483288010 — the top-of-queue Critical incident — to open its full detail view.

Read each section of the Overview panel:

Scroll to the Violation Details section:

The example's Current State Details panel shows Validating with User. Review User Notifications and State Changes below to establish what actions were recorded; the status alone does not identify whether they were manual or automated.

Step 2 — Review the Policy and Content Sections

Scroll down to the Policy and Content panels.

Policy section:

Content section:

Application section:

The File MD5 hash is a pivotal forensic artefact. Priya can use this to verify whether the same file has appeared in multiple incidents, pivot into threat intelligence, or correlate with endpoint DLP logs.

Step 3 — Review Violation Content, User Notifications, and State Changes

Scroll further down to the Violation Content, User Notifications, and State Changes sections.

Violation Content:

• Generate Presigned Link — produces a time-limited URL to retrieve the actual violating file content (subject to tenant permissions).
• View Trigger Data — shows the raw data that fired the DLP engine, including matched content snippets and engine confidence scores.

User Notifications table:

State Changes audit trail (most recent first):

Use State Changes to review the recorded actions, timestamps, actors, and comments. The example attributes notification and status changes to an administrator; identifying a specific automated workflow would require additional evidence.

Task 4 — Explore Available Actions​

Return to the top of the Incident Details page and open Actions. Review the available options without executing them; this exercise explores existing records in the read-only Enterprise Tenant.

Task 5 — Explore Workflow Templates​

Priya has reviewed an incident and its recorded history. Next, preview an existing workflow template to understand how notification and escalation can be automated; no workflow configuration is required in this lab.

Steps​

Step 1 — Navigate to Workflow Templates

In the left rail of Workflow Automation, expand Workflows and click Workflow Templates.

Review the available templates. Examples shown include:

Review the Counts column and available mapping details. A count alone does not establish that a workflow ran for the incident you inspected; check its mapping criteria and execution evidence.

Step 2 — Preview the Auto Notify User and Concurrently Escalate Template

Click the eye icon next to Auto Notify User and Concurrently Escalate to open the workflow preview.

Read the visual workflow diagram:

The right panel shows the configurable settings:

• Escalate to Manager — Notification Channel + Language
• Escalate to Approver — Approver Name + Notification Channel + Language

This single template replaces what would otherwise be a multi-step manual process: notify, look up manager, escalate, confirm. It executes in seconds, automatically, for every incident that matches the workflow mapping criteria.

Lab Summary​

In this lab, Priya explored a pre-populated incident and response workflow:

1. Navigated to the Incidents queue via Administration → Workflow Automation
2. Reviewed queue counts and statuses for the selected reporting window
3. Filtered by Source DLP Type to compare Inline and Endpoint records
4. Inspected an incident's user, file metadata, application, and policy details
5. Reviewed recorded User Notifications and State Changes
6. Explored available response actions without executing them
7. Previewed an existing notification-and-escalation workflow template

Key Takeaway: Workflow Automation is not a passive log viewer. It is an active SOC workspace where detection, investigation, user notification, and automated response all converge — replacing the multi-tool, multi-console workflow most security teams operate today. The State Changes audit trail and Workflow Templates together deliver both compliance evidence and operational efficiency.

Module 1 — Visibility​

Q1. In Labs 1–4, Alex observed Dataparity's environment without enforcing any blocking policies. Why is it important to start with visibility before enforcement — and what risk does skipping this step create?

Q2. In Lab 3, how did Endpoint Data Scan, User Investigation's Data at Rest and Timeline views, Application Investigation, and connected-device Inventory contribute different parts of the endpoint picture? Use one example of a classification, incident, application, and device association. Why is the ZIA-calculated User Risk Profile not simply the sensitive-file count, and why does a device Allow record not prove that sensitive data was successfully exfiltrated?

Q3. Instance Discovery in Lab 1 distinguishes between corporate and personal instances of the same application (e.g., corporate Google Drive vs. personal Google Drive). Why does this matter for a DLP policy — and what would happen if you blocked the application rather than the personal instance?

Module 2 — Protection​

Q4. Lab 5's DP Project Code engine combines Credit Cards AND ABA Bank Routing Number AND the custom DP Project Code dictionary, each with a condition greater than zero. Labs 6 and 7 reuse this engine; Lab 8 uses separate preconfigured browser policies. What benefit does detection reuse provide, and why do channel-specific policies and tests still matter?

Q5. Compare the six protection activities in Module 2. Complete the table with the control and outcome you observed; do not treat masking or watermarking as a block.

Q6. Lab 6 reviews Web Insights, and Lab 7 reviews Endpoint DLP Insights. Lab 9 explores an independent pre-populated Workflow Automation queue with Inline and Endpoint filters. How does a combined incident view support triage, and what evidence would you need before linking a queue record to one of your own Lab Tenant tests?

Q7. Lab 8 tests Chrome with an authenticated Browser DLP extension. What deployment and policy checks would you make before claiming equivalent coverage in another browser? Which activities from Labs 6 and 7 could other layers address, and why should you not assume they reproduce browser masking or watermarking?

Q8. Lab 7's Clipboard rule was scoped to Notepad++ (Windows) as the destination application. A colleague suggests changing the destination to Any to maximize protection. What is the trade-off of setting destination to Any — and under what circumstances would you keep it scoped to a specific application?

Module 3 — Investigation​

Q9. In Lab 9, the User Notifications table records an email to the originating user, and State Changes attributes Notify User and Change Status entries to a named admin. What do the channel, status, timestamp, and Changed By fields actually establish? What additional evidence would be needed to attribute the notification to a particular workflow, rather than inferring it from the incident status or the template you previewed?

Q10. Priya filtered the pre-populated queue by Source DLP Type = Inline + Endpoint. What would adding SaaS Security let her explore if matching records exist? Why would reviewing dashboards in the read-only Module 1 labs not itself generate those SaaS incidents?

Cross-Lab Synthesis​

Q11. Dataparity and the three personas connect the workshop, but the labs do not trace one file across all three modules.

• How do Alex's visibility and policy work, Kevin's protection tests, and Priya's read-only investigation complement each other?
• Which document is actually reused in Labs 6 and 7, and how do Lab 8's customer text, sample PDF download, and watermarked document differ?
• Why should the independent records in Labs 3, 4, and 9 not be treated as the same file or the student's incident? Consider Lab 9's attachment/post, dlptest.com, and CC SSN HIPAA Block fields.

Q12. A customer asks: "If I deploy Inline Web DLP, Endpoint DLP, and Browser DLP, am I fully protected?" Based on Labs 6–8, what would you say? Consider SSL inspection, agent and extension deployment, rule scope, untested channels, and the difference between a preventive block and a deterrent watermark.

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 Dataparity Story — Complementary Exercises​

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​

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:

Share Your Feedback​

We'd love to hear about your experience today. Takes less than 2 minutes.