How a Mid-Market Public Sector IT Team Rolled Out Its First Secure Web Gateway Across a Distributed Workforce

How a Mid-Market Public Sector IT Team Rolled Out Its First Secure Web Gateway Across a Distributed Workforce

If you’ve worked in public sector IT, you know the budget conversation comes before the architecture conversation. The brief always sounds the same: keep the laptops safe, keep the auditors happy, don’t spend like a Fortune 500. This public sector secure web gateway case study is what happened when a mid-market council in EMEA actually solved the problem instead of patching it for another year.

The customer is a public sector organization with a workforce split across council offices, partner sites, libraries, depots, and a steady tail of home-working staff. They picked dope.security to stand up their first real SWG on a greenfield deployment, brought in through a regional channel partner.

Quick read

  • Industry: Public Sector
  • Replaced: Greenfield (no prior SWG)
  • Deployed: dope.SWG

Where things stood

Before this project, the security stack was the usual public sector layering. Endpoint AV. A perimeter firewall doing some URL filtering for the on-prem users. A VPN that worked, mostly, for the people who remembered to turn it on. And a long list of policies in the staff handbook that nobody had operationalized.

The Principal Architect leading the project had a short list of issues to solve. Inspect what people were actually doing on the web, including over HTTPS. Stop relying on the VPN to be the policy enforcement layer. Get something defensible in front of the next internal audit. None of that was going to happen by buying another firewall.

The brief: real security on a council-sized budget

Public sector procurement does not love long product evaluations. The brief had to be small.

The architect wrote it down on a single page. SSL inspection that worked off the corporate network, because most of the workforce isn’t on it for most of the day. Category-based filtering that the IT team could actually maintain without specialist consultants. Deployment that fit the existing endpoint management tooling, not a new agent stack. Pricing that survived a council budget review.

That set the table for an on-device SWG conversation, not a cloud-proxy one.

Why on-device made it possible

dope.security’s fly-direct architecture moves the proxy onto the endpoint. Web filtering, SSL inspection, and policy enforcement happen on the device, with no cloud PoP to route through and no backhaul to a vendor data center.

For a distributed council workforce, that meant the SWG was active on every laptop, in every location, without depending on the VPN to be on. Field staff connecting from a partner site or a contractor’s office got the same policy as someone at headquarters. That was the part the architect cared about most.

The deployment used the IT team’s existing endpoint management tool. No second console. No bespoke agent stack. The SWG was running across the managed estate inside a couple of weeks, not the multi-month timeline the team had been quoted by larger vendors.

“We needed a SWG that worked the way our staff actually work, not the way a vendor’s reference architecture diagram works. dope.security met us where we were. The deployment took weeks, the policy was readable, and the cost survived the budget conversation.”

— Principal Architect, a mid-market public sector organization

The non-technical reason

Architecture and price got dope.security shortlisted. The global support team got it across the line, and that part is not a small detail in public sector.

Council IT teams run lean. The Principal Architect was not going to win a hire-three-people fight. The deal came down to whether the vendor’s support team would actually pick up the phone when something needed an answer. With dope.security, the customer was on a first-name basis with their support contacts inside the first month, and the questions that used to disappear into a ticket queue came back as same-day answers.

What changed

Inside the first quarter, the team had SSL inspection running on every managed laptop, regardless of where the device sat on the network. They had category-based policy the IT team could update without consultants. They had a clean answer when the auditor asked about HTTPS visibility. And the staff didn’t notice, which is the highest praise public sector users give a security project.

FAQ

Can a mid-market public sector IT team deploy a secure web gateway without a major integrator project? Yes. An on-device SWG removes most of the heavy infrastructure that drove the need for a long integrator engagement. Policy lives in a single console, deployment uses the existing endpoint management tool, and there is no PoP architecture to provision. A small in-house team plus a regional channel partner can run the program end to end.

Does dope.security work for distributed public sector workforces, including remote and field staff? The proxy runs on the endpoint, so the SWG follows the user. Council office, library, partner site, contractor office, home: the policy and SSL inspection behavior are the same in every one of them, with no dependency on the VPN being on.

How does dope.security fit a public sector budget compared to enterprise SSE platforms? Most enterprise SSE platforms quote multi-year, PoP-anchored deployments that don’t fit a typical public sector budget. dope.security ships as a single endpoint agent with one console for SWG, CASB, DLP, and Cloud Application Control, which keeps the procurement conversation small and the renewal conversation honest.

About dope.security

dope.security, the Distributed On-device Proxy Endpoint, is the preferred security vendor for security leaders across SMBs, midsize enterprises, Fortune 500 companies, and the world’s top VC and PE firms. Deployed in 83 countries, dope.security protects web, data, and AI traffic globally through its patented fly-direct architecture.

Customer Stories
Customer Stories
Case Studies
Case Studies
Secure Web Gateway
Secure Web Gateway
Remote Work Security
Remote Work Security
back to blog Home