Most swg proofs of concept fail quietly. They start with a vendor SE kickoff, drift through a few scope changes, lose momentum when a key engineer goes on PTO, and conclude three months later with a deck that everyone has already stopped reading. The tool gets bought or not based on relationship and fatigue rather than evidence.
This post is a rebuttal to that pattern. A serious swg POC fits in two weeks, produces a pass or fail on every stated criterion, and ends with a decision the security and finance leads can both sign.
A well-run swg POC is a two-week engagement with written pass/fail criteria, a fixed test matrix, and a decision memo on the final day.
Why Most SWG POCs Fail
Three failure modes dominate. Name them before the POC so they do not happen to yours.
The Vendor Drives the Agenda
The vendor SE has run this motion fifty times. The customer team has run it once. Without a pre-written plan, the POC becomes a tour of the product’s best features rather than a test of the customer’s requirements. Good features, wrong questions.
Criteria Are Never Written Down
“See if it blocks shadow AI” is not a criterion. “Block upload to the top 20 consumer GenAI services, demonstrated by attempted paste from a test account, logged with user and destination in the console, within 10 seconds” is a criterion. The difference is whether the result is arguable.
Dealbreakers Surface Post-Signing
The agent is incompatible with the EDR. The Mac build lacks a DLP surface the team needs. The DPA does not cover the in-scope region. All findable in the first week. All found in month four, after contract.
Pre-POC: Writing Pass/Fail Criteria
Before the vendor touches production, write the criteria. Two hours of work here saves two months later.
Architecture Criteria
Is inspection on-device or through a POP? Measured p95 added latency on a residential connection? RAM footprint? Native binary for the installed CPU?
Deployment Criteria
MDM profile per platform. Install and enroll a test laptop in under 30 minutes without vendor assistance. Clean uninstall.
Policy Criteria
Block target categories. Enforce identity-aware policies against the SSO provider. Exceptions expire automatically. Policy exports are human-readable.
DLP and AI Criteria
Classify unstructured PII without custom regex. Block upload to consumer GenAI services with a single toggle. Events include user, destination, classification, and reason.
Coexistence Criteria
Run alongside the existing EDR and VPN for 72 hours without user-reported degradation, CPU spikes, or crashes.
Evidence Criteria
Every blocked event has a readable reason. Logs export to the SIEM in a documented schema. Change history is immutable and timestamped.
If a criterion cannot be tested in one command or one click, rewrite it until it can.
The Two-Week POC Plan
A day-by-day plan keeps the engagement tight. Deviations get noticed the day they happen, not three weeks later.
| Day | Activity | Owner |
|---|---|---|
| 1 | Kickoff, confirm criteria, provision tenant | Vendor + IT |
| 2 | Deploy to five pilot laptops via MDM | IT |
| 3 | Baseline policy built from template, SSO integrated | IT |
| 4 | Architecture and latency tests run, recorded | Security engineer |
| 5 | DLP and shadow AI tests run against criteria | Security engineer |
| 6 | Coexistence run starts, 72-hour soak | IT |
| 7-8 | Weekend soak, no intervention | None |
| 9 | Soak review, user feedback collected | IT |
| 10 | Cross-platform parity tests (Mac and Windows) | Security engineer |
| 11 | Evidence export tested, schema verified | Security + GRC |
| 12 | Red team attempt on tamper protection | Security engineer |
| 13 | Results compiled into matrix, criteria scored | Project lead |
| 14 | Decision memo written and circulated | Project lead |
Two weeks. No drift. If the vendor cannot meet this cadence, the product is not deployment-ready for your team even if it passes functional tests.
An on-device swg architecture shortens several of these steps because there is no POP to select, no network routing to plan, and no backhaul to provision. The POC collapses into product testing rather than infrastructure planning.
Red Flags and Green Flags
A few signals inside the POC predict the next three years of the relationship.
Red Flags
- The vendor needs professional services to build the baseline policy.
- DLP detection only works after a week of rule tuning.
- Mac and Windows agents behave noticeably differently.
- The console reasons are opaque codes rather than readable strings.
- The SE defers every hard question to “the product team.”
- Pricing is not committable before the decision memo.
Green Flags
- Baseline policy works on day one without a workshop.
- DLP classifies unstructured content correctly with zero configuration.
- Agents behave identically across platforms.
- Console events are self-explanatory to a new analyst.
- The SE answers technical questions in writing, with references to docs.
- Pricing is on the table before the decision is made.
A mature secure web gateway will produce mostly green flags inside the first five days. A product that is still maturing will show its red flags early, and the team can disengage before the quarter is gone.
Writing the Decision Memo
The POC ends on day 14 with a memo. One page, three sections: the result matrix with pass, fail, or partial per criterion; the business implication of each partial or fail; and the recommendation with a specific contract shape covering term, user count, and price ceiling.
Circulate the memo to security leadership, finance, and IT the same day. The point of a tight POC is to make the decision inevitable rather than contentious, and the memo is what makes it so.
Shipping the Decision
A POC that runs in two weeks, against written criteria, with a decision memo at the end, changes the vendor dynamic permanently. Teams that adopt this playbook cut evaluation cycles, negotiate better terms, and catch dealbreakers before they become renewal problems.
FAQ
What is a secure web gateway?
A secure web gateway inspects outbound web traffic from user devices and enforces policy on destinations, categories, and content. In a POC context, the relevant questions are where inspection happens, how policy is authored, and what evidence the product produces for each enforcement action.
How to enable secure web gateway for a POC?
Provision a tenant, integrate with the SSO provider, build a baseline policy from a vendor template, and deploy the agent to a small pilot group via MDM. A capable product completes this sequence in a single day. If initial setup stretches into a week, that is a signal about the product’s deployment maturity.
How does this compare to a Zscaler POC?
Zscaler POCs typically follow the cloud-proxy pattern and spend significant time on POP selection, network routing, and SSL bypass tuning. That adds weeks to the plan above. On-device architectures such as dope.security skip those steps because there is no POP and no backhaul. The core functional criteria, however, apply to any SWG POC regardless of architecture.
What should the SWG POC not include?
Cut anything that does not map to a pass/fail criterion. Vendor roadmap sessions, future-feature demos, and peer customer calls are useful for vendor selection context but do not belong inside a two-week POC. Keep the POC focused on what ships today.
