Prove Netskope is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The laptop never steered. The page never aggregated. Policy blocked the upload. A DLP profile fired and nobody quoted its name. The HTTP transaction used an SSL bypass the Page Event never showed. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the exchange — steer first, then name the decision. Here you learn the five tools you actually open, in order, when someone asks you to prove Netskope is working.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you ship a bad change at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open the policy editor until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the tenant. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the Client is steering and names the SaaS activity. Side B proves the page and the alert object. Side C proves the one HTTP transaction when the summaries disagree. On a messy Sev-2, do them in this order until a field lights up.

Side A — Client Status, then Application Events

1. Prove the device is steering

   Path: Settings → Security Cloud Platform → Netskope Client → Devices. Search the username. Read Client Status, Internet Security Status, Private Apps Access Status, Last Event, Last Event Actor, Last Event Time. Official Client Status table: Enabled means at least one service is on; Disabled means all services are off. Source: Devices.

2. Open View Details before you invent a bypass

   Hostname → View Details. Quote Steering Configuration and Client Configuration. Event History names Tunnel Up, Tunnel Down, User Disabled, Admin Disabled, Tunnel down due to GRE / IPSec (status Backed Off), Detected Dead Peer, Ping timeout. A tray icon photo is not this page.

3. If the Client is Enabled, open Application Events — not the policy editor

   Path: Skope IT → Events & Alerts → Application Events. Filter Username + Application + date range. Query Mode example from Help: app eq 'Google Drive' and user eq 'priya@lab.example'. Add Activity = Upload if the ticket is a file.

4. Read the two columns that close a policy ticket

   Customize Columns → Alert group: Action, Policy Name, DLP Profile Name, DLP Rule Name, Incident ID, Type. Default table already shows Time, Username, Application, Activity, Object, Site. Source: Application Events.

Side B — Page Events, then Alerts

1. Open Page Events when the complaint is a website, not an activity

   Path: Skope IT → Events & Alerts → Page Events (Help also writes Skope IT → Events → Page Events). Default columns: Time, Username, Application, Site, Total Bytes. Customize for Bytes Uploaded / Downloaded, Access Method, URL, Category.

2. Treat empty or Bypass Traffic as steering evidence

   Official FAQ: when traffic is steered and then bypassed (steering exception or SSL Do Not Decrypt), the proxy can emit a Page Event with Bypass Traffic = yes, suppressed at one event per domain per minute, without total bytes. First access of a Steering Configuration category exception shows Bypass Reason : Steering Exception. Second access is Client-side — no Page Event.

3. Do not hunt Action on a normal Page Event

   Official FAQ: “no action is logged unless it is Isolation (a page-based action). For all other Page Events, the action field will remain empty.” Isolate is also a valid Action filter on Application Events and Alerts when RBI is deployed. Path to filter: Page Events → Action → Isolate → Apply.

4. If SOC said “we have a hit,” switch to Alerts

   Path: Skope IT → Events & Alerts → Alerts. Default: Time, Name (the policy that triggered), Type (policy, DLP, malware, anomaly), Action (alert, block, detection), Activity, Username, Application, Site, Object, Account Name. Rule columns add Policy Name, DLP Profile Name, DLP Rule Name. Alerts generate only when a policy or watchlist matches — a regular event otherwise.

Page path:     Skope IT → Events & Alerts → Page Events
Quote:         Site + Total Bytes + Bypass Traffic + Bypass Reason
Empty page:    first-access Steering Exception, or Client never steered
Action:        empty unless Isolation (RBI)

Alerts path:   Skope IT → Events & Alerts → Alerts
Quote:         Name + Type + Action + Object
Query sample:  alert_type eq DLP and user eq 'priya@lab.example'
Caveat:        RTP “Alert” on Browse activity does not generate an Alert event

Side C — Transaction Events / Advanced Analytics

1. Open Transaction Events when summaries disagree

   Path: Homepage → Skope IT → Transaction Events. Official: a comprehensive log of HTTP transactions; Page / App events are rolled up to avoid noisy web traffic. TxN is the row. Not available in FedRAMP, PBMM, and RUH1 tenants. Batched — may appear up to five minutes late. Do not declare “empty” at T+30 seconds.

2. Filter the RTP action, not the vibe

   Filters include Action (Real-time Protection Policy), Name (Real-time Protection Policy), Action, Action Reason, SSL Bypass, SSL Bypass Reason, Action (SSL Policy), Name (SSL Policy), Status Code, Remote Status Code, POP, SNI, URL, Access Method (Client), Transaction ID. Source: Skope IT Transaction Events.

3. Open the plus icon — Client / Netskope / Remote Server

   Details are grouped as Client (who initiated), Netskope (what the cloud enforced), Remote Server (destination). Copy the RTP Action + Name. If SSL is the ticket, copy SSL Bypass / SSL Policy Action, not a new web Allow.

4. Use Advanced Analytics when you need the same family at longer retention

   Advanced Analytics Transaction Events is the analytics surface for the same HTTP events — granular bytes, SSL-error visibility, IOC search on longer packages. Pause / resume ingestion lives under Advanced Analytics → Data Retention. It is not a second policy engine.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

Journey · one amber hop is the ticket

NEVD-01 — Prove the Client (Devices)

01:42 · P2. Priya on a hotel network that also has a guest GRE to NewEdge. Client tray looks green-ish on a phone photo. L1 already drafted a Real-time Protection Allow.

First tool: Settings → Security Cloud Platform → Netskope Client → Devices, search priya@lab.example.

If Backed Off / Disabled: Last Event = Tunnel down due to GRE (or IPSec, Secure Forwarder). Official status is Backed Off — the Client auto-disabled because another steering method is on the path. Quote that event. Next check is whether she should be Client-steered or site-steered — not Application Events policy.

If Enabled + Tunnel Up: you are allowed to open Skope IT for her user and the failing app. Client Status = Enabled is not Action = Allow.

NEVD-02 — Prove the SaaS activity (Application Events)

02:05 · P2. OneDrive in the browser opens. q3-payroll.xlsx upload fails after last night’s DLP ship. Someone wants “another Allow for onedrive.live.com.”

First tool: Skope IT → Events & Alerts → Application Events. Query app eq 'Microsoft Office 365 OneDrive for Business' and user eq 'priya@lab.example', last hour, Activity = Upload.

Proof field: Login row can be Allow; Upload row Action = Block and Policy Name = RTP-DLP-Finance-Upload, with DLP Profile Name and Incident ID on the Alert columns. That name is the ticket. Change that one rule — or the exception process — Apply Changes, then re-read the same two columns.

NEVD-03 — Prove the page (Page Events)

02:20 · P2. Salesforce “the site is down.” Application Events for Salesforce is empty. L1 wants Force-disable SSL for the OU.

First tool: Skope IT → Events & Alerts → Page Events. Filter Username + Site + last 30 minutes.

Proof field: either a Page Event for salesforce.com with Total Bytes, or Bypass Traffic = yes and Bypass Reason : Steering Exception, or nothing. Nothing after an Enabled Client still usually means the first-access exception already moved to Client-side bypass — or the flow never hit NewEdge. Official: Page Events are not a bandwidth tool; some URLs miss the heuristic.

NEVD-04 — Prove the object (Alerts)

02:40 · P2. SOC Slack: “DLP hit on payroll.” Finance wants DLP disabled for the night.

First tool: Skope IT → Events & Alerts → Alerts. Query alert_type eq DLP and the user. Read Name, Type, Action, Object.

Proof field: Type = DLP, Action = block, Object = q3-payroll.xlsx, Name = the policy. That is a control success until an exception owner says otherwise. A DLP block is not an outage — the factory already taught that sentence; this desk makes you paste the alert.

NEVD-05 — Prove the HTTP row (Transaction Events)

03:00 · P3. Salesforce UI loads. The Lightning API returns 403. Page Event exists. Application Event for Login is Allow. Someone typed Sev-1 in the channel.

First tool: Skope IT → Transaction Events. Filter User + SNI api.salesforce.com. Wait the batch window if the table is empty.

Proof field: Action (Real-time Protection Policy) = allow, SSL Bypass = yes, Status Code = 403, POP named. The page Allow did not inspect the API. That is an SSL Policy / pin / Do Not Decrypt conversation — not a new Cloud App Allow and not a tenant outage.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Netskope Docs — Devices (Settings → Security Cloud Platform → Netskope Client → Devices; Client Status, Internet Security Status, Last Event, Backed Off, Steering Configuration on View Details)
• Netskope Docs — Steering Configuration (Settings → Security Cloud Platform → Steering Configuration)
• Netskope Docs — Creating a Steering Configuration (Client auto-disables when it detects IPSec, GRE, or Explicit Proxy)
• Netskope Docs — Using Netskope Client (tray Configuration status / last config update)
• Netskope Docs — Application Events (Skope IT → Events & Alerts → Application Events; Alert columns: Policy Name, Action, DLP Profile Name)
• Netskope Docs — About Page Events (Skope IT → Events → Page Events; Time, Username, Application, Site, Total Bytes)
• Netskope Docs — Page Events FAQs (heuristic; Bypass Traffic; action empty unless Isolation; independent of Application Events)
• Netskope Docs — Alerts (Skope IT → Events & Alerts → Alerts; Name, Type, Action; Browse/Alert caveat)
• Netskope Docs — Skope IT Queries Library (action, alert_type, access_method, app)
• Netskope Docs — Isolation Events in Skope IT (action = isolate on Page Events, Application Events, Alerts)
• Netskope Docs — Skope IT Transaction Events (Homepage → Skope IT → Transaction Events; Action / Name of RTP Policy; 5-minute batch; FedRAMP / PBMM / RUH1)
• Netskope Docs — Advanced Analytics Transaction Events (granular HTTP family; SSL-error visibility)
• Netskope Docs — Transaction Events Fields Reference (RTP Action: allow, block, bypass, alert, useralert; policy name)

Related: Blog 1 · Netskope session factory · Architecture & steering · DLP deep-dive · Private Access (NPA) · Netskope practice dashboard