Netskope Next Gen SWG — Real-Time Protection Policies

① How Real-time Protection reads the rulebook

Open your Netskope tenant and go to Policies → Real-time Protection. What you see is a numbered list of rules. Every web, SaaS and AI request that the Netskope Client steers and decrypts is run against this list from the top down, and Netskope stops at the first rule that matches. That rule’s action is applied and — with one narrow exception — no rule below it is even looked at for that activity.

This single behaviour, first-match-wins, explains most of the “why isn’t my policy working?” tickets an L1 engineer ever raises. If a broad Allow rule sits near the top and your specific Block sits below it, the Allow matches first and your Block is dead weight. The one exception: a non-terminal DLP action set to Alert can let processing continue, but treat the default mental model as “first match, full stop”.

Now the trap that catches everyone: what about traffic that matches no rule at all? Netskope’s documented default is to allow it. So an empty or sloppy list does not “fail closed” — it lets things through. That is exactly why explicit Block rules, allowlists and a sensible bottom-of-list catch-all matter.

Four terms you will use every day in RTP

Tap each card — these are the load-bearing words for the whole policy screen.

② Build one rule: Source → Destination → Profile & Action

Every RTP rule is the same sentence read left to right: WHO is doing WHAT on WHICH destination, and what is the verdict. Click New Policy → Web Access and you build it in three sections, each edited via the pencil icon by its heading.

Source — who the rule applies to

The Source section is the “who”. Pick by User, User Group, or Organizational Unit (OU); you can also match Unknown (all unauthenticated users), a Source network location (Trusted/Untrusted), an Access Method, an OS Family, or device classification. A rule for a small VIP group is simply a Source set to that group.

Destination — what they are reaching

The Destination for a Web Access rule is a Category — a web category chosen from the dropdown (Gambling, Streaming Media, Newly Registered Domains, and so on). For app-aware rules you instead pick a Cloud App, App Instance, or App Suite — and selecting a cloud app activates the “Activities and Constraints” section.

Profile & Action — the activity and the verdict

This is the action side. Activity-based control lets you match the verb: Browse, Upload, Download, Post, Share, Edit, Create, Delete, Form Post (the list depends on the app). A handy gotcha: Alert events are not generated for the Browse activity, so don’t expect “Alert on Browse” to fill Skope IT. You can narrow further with a Constraint Profile, attach a DLP Profile and a Threat Protection profile, then pick the Action and a Notification template (the block / coaching page).

③ Order is the policy — and SSL decides what RTP sees

Here is the lesson that separates a guesser from an engineer: in a first-match-wins list, placement is policy. Netskope’s own best practice is blunt — place rules for individuals or small groups near the top, place exceptions at the top of block policies, and put broad access-control toward the bottom. A specific rule below a broad one is a rule that never runs.

Netskope’s own best-practice doc gives a documented top-to-bottom shape: Threat Protection → Utility policies → Remote Browser Isolation (RBI) → CASB activity rules → Web category rules → Netskope Private Access (NPA). You don’t have to memorise it, but notice the pattern — sharp, high-risk and exception rules first; the broad acceptable-use web-category catch-all near the bottom. And always test new rules with a small test-user group first before they hit everyone.

SSL Decryption — the gate before RTP

SSL Decryption is a separate policy set at Policies → SSL Decryption → Add Policy, and it runs before RTP. Its action is Decrypt or Do Not Decrypt. The docs are explicit: “Decrypt: traffic will move to deep analysis via the Real-time Protection policies.” If a flow hits Do Not Decrypt (or is a certificate-pinned app that auto-bypasses), RTP still sees it but with limited context — your DLP and threat profiles can’t read an encrypted payload.

One more SSL gotcha for your first day: new SSL Decryption policies are created Disabled — you must enable them. And path-based matching doesn’t work on undecrypted traffic, because the URL path lives inside the encrypted payload.

④ Block, coach, and debug the dead rule

When a rule matches, the Action dropdown decides the user’s experience. Web Access primarily exposes Alert (log only / monitor) and Block, with the broader action set including Allow, User Alert, Bypass and Quarantine. The two you’ll explain in interviews are Block vs User Alert.

Block is a locked door: the request is denied and the user sees the Notification template you attached (your block page). User Alert is a polite doorman: it shows a coaching page that warns “this site is risky” and lets the user click Continue if they truly need it — and it logs who proceeded. Block is enforcement; User Alert is awareness with an audit trail.

A modern twist worth knowing for interviews: Netskope’s April 2025 AI-security update extended this same RTP engine to police GenAI apps. Inline policies can control specific AI actions — upload, download, copy and print — beyond a blunt allow-or-block, and real-time DLP can inspect both the prompt a user types and the AI-generated response. The “block uploads to a personal app” pattern you just learned is exactly how teams now stop staff pasting source code into ChatGPT.

For certification, map this lesson to the Netskope tracks: NSK100 (NCCSA) at the foundational tier and NSK200 (NCCSI), whose blueprint explicitly tests “User Activity and Threat Protection” and “SWG Functionalities” — URL filtering, SSL inspection, and category/threat/user-context policy building. The classic interview question: “Explain Netskope policy evaluation order and what happens on a no-match.” You can now answer it cold.