Your SASE Renewal Should Prove Who Owns Every Policy Change

A SASE platform can consolidate networking and security without consolidating accountability.

That becomes obvious at renewal. The provider says it manages the service. Network owns SD-WAN. Security owns inspection rules. Identity owns access groups. The application team approves exceptions. The vendor operates the console. Procurement sees one renewal proposal and assumes it is one service.

Then a policy change breaks access, an urgent exception sits in a queue, or an incident crosses three teams. Everyone touched the service. Nobody clearly owned the decision.

Before you renew a SASE platform or managed SASE service, prove who can request, approve, implement, test, reverse, and document each type of policy change. If the answer is still “shared,” the operating model is not ready for another term.

Start with the service you have, not the service you bought

Pull the current order form, master agreement, statement of work, service description, support terms, responsibility matrix, policy standards, and change records. Compare those documents with the live environment.

You are looking for three different layers:

The technology the platform can provide
The work the provider agreed to perform
The work your internal teams still perform to keep the service useful

Those layers are often different.

A platform may support centralized policy while separate teams still control identity groups, endpoint posture, network routing, data rules, and application approvals. A managed provider may administer the console but require customer approval for every meaningful change. A service may include routine changes while treating policy design, troubleshooting, or integration work as a project.

None of that automatically makes the service bad. It does make the monthly fee an incomplete picture of cost and accountability.

If you are still deciding between operating models, the managed SASE versus DIY SASE framework covers the broader build-or-buy question. At renewal, the narrower question is whether the operating split you chose is working and provable.

Build a policy ownership map

Do not begin with the vendor’s product modules. Begin with the decisions your business needs the service to make.

List the policy families that matter in your environment. They may include:

User and administrator access
Device posture requirements
Private application access
Web and DNS filtering
Data inspection and loss-prevention rules
Firewall and segmentation policy
SD-WAN routing and application priorities
Branch, remote-user, and third-party access
Decryption and inspection exceptions
Emergency blocks and incident containment

For each policy family, name the people or teams responsible for six actions:

Policy action	Accountable owner	Provider role	Approval required	Evidence retained	Target time
Request	Name or role	Intake or advise	Business justification	Ticket or change record	Defined by priority
Approve	Name or role	Recommend or validate	Risk and application approval	Approval record	Defined by priority
Implement	Name or role	Configure or observe	Approved change	Configuration record	Defined by priority
Test	Name or role	Supply logs or test support	Technical and business test	Test result	Before close
Reverse	Name or role	Execute or assist	Emergency authority	Rollback record	Defined by impact
Review	Name or role	Report or recommend	Service owner review	Exception and aging report	Monthly or quarterly

Do not put “IT” or “vendor” in every box. Use a role with enough authority to make the decision.

The same team does not need to own all six actions. In many environments, that would be a bad control. The point is to remove the gap between administration and accountability.

Test the seams between network, security, and identity

SASE renewals get messy because the policy is rarely controlled by one system.

An employee may have the correct identity group but fail a device-posture rule. A branch route may be healthy while a security policy blocks the application. A third party may receive application access through ZTNA while the application owner assumes network security approved the business relationship. A data rule may depend on labels controlled by another team.

CISA’s Zero Trust Maturity Model Version 2.0 treats identity, devices, networks, applications and workloads, and data as separate pillars with governance, visibility and analytics, and automation and orchestration cutting across them. It describes more mature environments as coordinating policy across pillars instead of enforcing policy in silos.

That is useful renewal guidance even though the CISA model was written for federal agencies and is not a commercial SASE contract standard. Your renewal review should test whether policies and evidence move across the systems and teams involved in an access decision.

Pick three real access paths:

A normal employee reaching a sensitive application
A remote administrator performing a privileged task
A third party reaching one approved resource

Trace each path through identity, device, network, security inspection, application authorization, logging, and support. Ask which team changes each control, which system supplies the decision signal, and where the provider’s responsibility stops.

If one team cannot explain the complete path, the renewal needs operating-model work, not another feature presentation.

Put exception ownership under pressure

Normal policy is easy. Exceptions show whether the service is actually controlled.

Pull a sample of recent allowlist requests, decryption bypasses, temporary access grants, blocked-application overrides, routing changes, and emergency security rules. For each one, check:

Who requested it and why
Who approved the risk
Which systems changed
Whether the change had an expiration date
Who tested the business result
Whether rollback instructions existed
Which logs or configuration evidence were retained
Whether anyone reviewed the exception after the immediate need passed

An exception without an owner becomes permanent because nobody feels authorized to remove it. An exception without an expiration date is a quiet policy change. An exception without testing can fix one user’s problem and create a wider security or performance issue.

Ask the provider for an exception inventory and aging report if the service includes that work. If the provider cannot produce it, decide whether the contract should require it or whether your team must own the record.

Separate change administration from change authority

A provider with console access is not necessarily authorized to make every change. An internal approver is not necessarily capable of judging every technical effect.

Write down the authority limits before renewal.

Which changes may the provider make without prior approval? Which require network, security, identity, application, privacy, or business approval? Who can authorize an emergency block? Who can reverse a change when the primary approver is unavailable? Which changes must wait for a maintenance window?

NIST SP 800-207 describes zero trust as an enterprise approach to making granular, least-privilege access decisions and continuously evaluating relevant security posture. That does not tell a commercial buyer how to divide work with a SASE provider. It does make one point hard to avoid: access policy is an ongoing decision system, not a configuration project you finish once.

Your contract and operating procedures should reflect that reality. A promise to “manage SASE” is weak if the agreement does not define change classes, authority, evidence, response targets, and escalation.

Measure the service buyers usually forget to price

SASE renewal pricing often focuses on users, sites, bandwidth, modules, and support tier. Add the retained labor.

Count the time your team spends on:

Translating business requests into policy changes
Chasing approvals across teams
Supplying identity, device, or application context
Testing changes the provider implemented
Troubleshooting between the SASE platform and another system
Reviewing logs, reports, and aged exceptions
Coordinating vendors when ownership is disputed
Correcting undocumented or poorly tested changes

Do not hide that time because it sits across several budgets. It is part of the service cost.

A cheaper managed service can become expensive when internal IT acts as its project manager, policy architect, test team, and escalation desk. A more expensive service can still be poor value if the provider controls the tools but supplies weak evidence and slow changes.

Compare the full operating model with the proposal, not only this year’s rate with next year’s rate.

Require evidence before you choose a renewal path

A quarterly service review deck is not enough. Ask for operating evidence from the current term:

Policy and configuration change history
Request, approval, implementation, and closure timestamps
Emergency change and rollback records
Open and expired exception reports
Escalation records and response times
Service-impacting policy incidents
Administrative role and access exports
Current integrations and failed-connector alerts
Runbooks for routine and urgent changes
Configuration export and transition support terms

Use that evidence to choose one of five paths:

Renew: Ownership, authority, service performance, and evidence support another term.

Renew with corrections: The platform and provider still fit, but the agreement needs named deliverables, owners, response targets, reports, or remediation dates.

Change the operating split: Keep the technology but move policy design, administration, testing, or monitoring between the provider and internal teams.

Run a competitive review: The provider cannot close material gaps, or you need to compare a different managed, co-managed, or internal model.

Do not renew yet: The evidence is too weak to support a decision, and the notice window still gives you time to investigate.

Do not leave corrections in meeting notes. Put material operating changes into the agreement, service description, responsibility matrix, or another controlled document referenced by the contract.

Run one policy change before you sign

Finish the renewal review with a live test.

Choose a routine but meaningful change, such as adding a new application group, changing an access rule for a branch, or creating a time-limited third-party exception. Use the real request channel, approvers, provider team, test process, rollback plan, and evidence.

Watch what happens.

Does the request reach the right queue? Can the approver see the risk and business reason? Does the provider understand every system affected? Can the team test both access and security behavior? Does the final record show who approved, what changed, when it changed, and when the exception expires?

One completed change tells you more about the service than another renewal demo.

You do not need one team to own every part of SASE. You need every policy decision to have an accountable owner and every handoff to produce evidence.

If your SASE agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, current responsibility matrix, renewal proposal, change records, and exception reports. Catch Advisors will help you find unowned work, weak evidence, and contract gaps before you commit to another term.