The 3-week secure web gateway pilot checklist for lean IT teams
.jpeg)
A secure web gateway pilot doesn't need a project manager, a steering committee, or a 40-page test plan. It needs about 20 users, three weeks, and a short list of things that have to be true before you sign.
This is the checklist lean IT teams use with us. Three people, 600 to 900 devices, an incumbent renewal on the calendar. Copy it as-is.
Before you start: write down the pass/fail criteria
Pilots fail when nobody agreed on what "pass" meant. Decide it before the agent is on a single machine. Five criteria cover almost everyone. Write them down, put them in the wrap-up invite, and grade each one at the end.
| # | Criterion | What "pass" looks like | Evidence to collect |
|---|---|---|---|
| 1 | Speed and reliability on and off network | Pilot users report faster than the incumbent; no captive-portal failures for travelers; Mac and Windows both | User feedback, side-by-side page loads |
| 2 | Deployment through existing MDM | Packaged and pushed by your own team, one-time sign-in, no per-device config | MDM push log, agent check-in in console |
| 3 | Policy, cloud app controls, DLP | URL filtering, enterprise-only AI access, and upload DLP all validated in a walkthrough | Policy tester results, audit log, DLP event |
| 4 | SIEM and security due diligence | Real-time events in your SIEM; every questionnaire item answered in writing; SOC 2 Type 2 under NDA | SIEM screenshot, dated written answers |
| 5 | Support responsiveness | Setup questions answered in minutes; zero Sev-1 or outage tickets during the pilot | Ticket list with response times |
Week 1: tenant, agent, first 20 users
Day 1: get the tenant. With dope.security you sign in with your corporate Google or Microsoft account and the tenant exists. Confirm with any vendor that this trial tenant becomes your production tenant. If you have to redeploy policies into a new tenant at signature, that's a week you'll lose later.
Day 1: connect identity. Sync a test group from Entra or Google Workspace. The person doing it needs admin rights on the identity side for the consent step, so line that up in advance rather than discovering it on the call.
Day 2: pick the pilot users on purpose. Not IT. Pick the 15 to 20 people with the worst experience on the current gateway: the developers with the longest bypass lists, the executive whose laptop fails on hotel Wi-Fi, the person who could never sign in. If the new agent wins them, you have your champions.
Day 2 to 3: push through MDM. Jamf, Kandji, or Intune. Push to the pilot group, not the whole directory. Confirm the agents check in and that the console is showing your own traffic within the hour.
Day 3: turn SSL inspection on. Don't pilot with it off. Add developer tools that pin their own certificates to an Application Bypass in a test policy. Watch the SSL error notifications in the console for anything you missed. (If your fleet is Mac-heavy, read why Mac fleets end up with inspection off before this step.)
Week 2: break things on purpose
This is the week most teams skip, and it's the week that matters most for the wrap-up. Run these tests and screenshot the results.
Disable a device from the console. Confirm the user loses web access without needing a password or any action on their end. Then re-enable it.
Try to uninstall the agent as a user. Confirm the anti-uninstall password holds, and that the attempt shows up in the audit log with a name and a timestamp.
Push a policy change. Block a category, time how long it takes to land on the pilot devices. On dope.security it's seconds over a websocket, not a polling window. Then reverse it and time that too.
Push a second identity group. Confirm it lands in the console with the right policy attached. Group-based policy is where most of your real-world admin work will live.
Test a pinned-cert application. Pick an integration tool or internal app that uses its own certificate, add it to the Application Bypass, confirm it works with inspection on for everything else.
Stream to your SIEM. Sumo Logic, Splunk, Sentinel, QRadar, Datadog, CrowdStrike, or S3. Confirm events arrive in real time, and note that console analytics may lag the SIEM feed by up to a day, so the SIEM is your source of truth for incident work.
Send the security questionnaire. Agent update control and canary groups, Sev-1 escalation path, fail open versus fail closed, encryption at rest and in transit, log retention, DR testing, SOC 2 report. Note the date you sent it and the date you got complete answers back. That gap is your first support data point. (We published our answers to the 11 questions security teams ask before replacing Zscaler so you can compare.)
Week 3: broaden, then wrap up
Widen the pilot. Add 20 to 30 more users from the business side. Pilot feedback from IT is useful; pilot feedback from sales, finance, and operations is what your VP wants to hear.
Count the tickets. Every support request you sent during the pilot, with response time. Setup questions are expected. Sev-1s and outages aren't. A median response time under 20 minutes with zero outage tickets is a pass. (We publish our standard targets: 24/7 email support staffed by product engineers, one-hour initial response for Severity 1, 99.9% availability SLA, and a live status page.)
Hold the wrap-up. Pilot users, security lead, budget owner, 45 minutes. Walk the five criteria. Pass or fail each one with the evidence from week 2. If everything passes, ask for the quote and the EULA on the call.
The questions you'll forget to ask
Every pilot we've run surfaces the same late questions. Ask them in week 1 instead:
Can our service desk disable a user without going through the security team? (Yes. The SOC Analyst role covers it; further roles are configured with you.)
Can we see more than seven days of analytics, and can we export a report for management? (The console analytics window is seven days; longer history and monthly reporting live in your SIEM, which is why the SIEM test in week 2 isn't optional.)
Can we block AI apps per policy, and does cloud app control cover file-sharing apps so we're not managing FQDNs by hand? (Cloud App Controls cover AI tools and personal accounts for Google and Microsoft; blocking personal Claude accounts shows how the tenant control works. Check the current coverage list at inflight.dope.security for the apps you care about.)
What happens if the cloud is unreachable? (The agent keeps enforcing cached policy on previously visited sites. New sites are allowed or blocked based on your Fail Close setting. Inspection runs on the device, so a cloud issue doesn't interrupt browsing.)
Three weeks, then decide
Greylock Partners went from first proposal to signed contract in 27 days. Outreach Health had 99% of devices secured within a week of signing. The pattern is consistent: when the pilot is scoped tightly and the pass/fail criteria are written down, the decision makes itself. And if the incumbent's renewal is what's driving the timeline, the 90-day Zscaler switch plan shows where the pilot fits.
Grab the tenant at dope.security and start week 1 today. Or book a 20-minute call and we'll run the pilot kickoff with you.


.jpeg)
.jpeg)
.jpeg)

