How SASE Governance Models Handle Policy Versioning and Change Approval
I spent the better part of last year helping a financial services firm with about 8,000 employees clean up the operational mess left by their SASE deployment. The platform had been running in production for eighteen months by the time I got there, and nobody had a definitive answer for what the current policy state actually was. Changes had been made directly in the admin console during incidents, never captured in a change ticket, and the vendor's "configuration history" feature showed timestamped diffs but had no approval workflow attached to it. During a routine audit, the compliance team found that several DLP policies had been silently modified three months earlier and there was no record of who authorized it.
What we ended up building was pretty close to what DevOps teams do with application infrastructure. Configurations got exported via API into a Git repository, a lightweight CI pipeline ran validation checks before any policy could be promoted, and a change ticket in their ITSM system became the required trigger for any production change.
The part that took the longest was getting the network access policies, the cloud app control policies, and the DLP policies into the same workflow, because they lived in different admin panels with different API maturity levels. Two of the three had complete APIs; one required a combination of API calls and manual steps that we documented and enforced through process rather than automation.
The audit findings closed out, and the team finally had a way to answer "what changed and who approved it" without digging through individual inboxes. Did anyone else end up having to build the versioning layer themselves rather than relying on what the vendor shipped?
edit: for those asking about rollback speed in production incidents, it depends entirely on whether your platform supports atomic policy swaps or applies changes incrementally