Set SASE priorities through application discovery

A SASE workshop starts with application behavior, not a promised design. Remote access complaints often arrive as broad requests for speed, simplicity, or stronger control. A solutions engineer brings order by asking which applications matter, who uses them, where access begins, and what people need to finish a normal task. Those answers help a security architect choose a small proof scope. A diagram belongs later, after owners agree on questions worth testing.

Prepare with a small application sample. Ask security and operations for applications employees use in ordinary work, applications contractors use, and applications with unusual access paths. Ask for one owner per application. An owner might sit in finance, engineering, operations, or another internal group. A network contact offers useful context, yet might not know an approval flow or a business deadline. An application owner supplies details about what a normal session requires.

Send a focused request before the workshop. Ask each owner for the user group, a normal task, current access method, identity steps they see, and a contact who knows support history. Ask for an example from a regular workday rather than a catalog description. “Expense approval portal used by payroll staff during month close” starts a useful conversation. “Finance system” forces the room to guess what work takes place or when urgency appears.

Build a visible worksheet. Use fields for application, user group, normal work sequence, access method, consequence of unavailable access, owner, open question, proof criterion, and review time. Keep one application per row. A notes area helps when participants supply extra context, but the main fields should remain short enough to read together. A worksheet is a working record, not a technical specification. Its value comes from showing where an answer has an owner and where an assumption needs attention.

Begin with the normal work path. Ask a participant to describe a real sequence without describing a preferred technical design. “A payroll analyst signs in from home, completes identity verification, opens the approval portal, submits a request, and receives confirmation” gives the group something observable. Ask where access begins, whether a browser or installed client appears, which identity step occurs, and what happens after sign in. Then ask how a contractor's path differs. Each answer reveals a policy question without pretending a solution already exists.

Treat priority as an operating decision. A popular application does not automatically deserve early proof work. Ask, “What happens during the next workday when this task stops?” Then ask who feels the impact and who decides acceptable behavior. An application used by fewer people might still belong in scope when a missed session delays a scheduled approval. Record the stated consequence beside the application. A priority word without a reason invites arguments during later design review.

Consider a fictional discovery workshop. Clara, a security architect, asks, “Will SASE solve every remote access concern?” Ben, the solutions engineer, says, “Application behavior and identity controls shape the scope. Let us choose a proof set and define observed results.” Clara names a legacy expense approval system, a browser collaboration service, and contractor access to an internal project portal. Ben adds three rows and asks who owns each application.

The finance owner explains an older sign in flow and extra approval work near month close. The network lead says office users begin through one path and home users begin through another. Ben writes each fact without guessing at architecture. He asks, “During a proof, which actions show acceptable access for a payroll analyst?” The owner answers, “A test analyst signs in, reaches the approval page, submits a sample request, and receives normal confirmation.” Ben records those actions as a proof criterion and asks who will observe the result.

The contractor row deserves separate treatment. Clara says some contractors work from unmanaged devices and changing locations. Ben asks who approves access, which resources belong in scope, and who confirms access removal after the work period. The identity lead explains current approval steps. The group does not treat contractor access as a smaller employee scenario. Their criterion says a named test contractor receives approved access only to the agreed project portal. After the test period, the application owner confirms whether removal occurred as expected.

Unknown behavior belongs in the worksheet. Suppose an owner says an installed client has unusual authentication behavior. Record “Authentication behavior needs confirmation,” rather than labeling the application incompatible. Ask the owner for a test path and an expected result. Ask the security lead which policy question needs review. Give both tasks a date. The room stays productive when unknowns turn into visible work instead of hidden assumptions inside a design drawing.

Choose a proof set with contrast. One application might use a browser, another might use an installed client, and another might involve contractor approval. Do not select rows only because attendees know them well. Select rows whose owners will take part and whose expected results are specific enough to observe. A row without an available owner usually produces delay or an unclear decision. If an owner has no time during the proposed window, choose a different application or move the proof date before claiming scope is ready.

Write proof criteria as observed sequences. “User experience is good” does not tell an observer what to look for. “Test analyst completes identity verification, reaches the named page, submits a sample request, and records an unexpected prompt” gives an observer a sequence. Name who watches the test and who decides whether a criterion is met. The security architect owns policy choices. The application owner owns statements about application behavior. The solutions engineer organizes questions and records agreed test work.

When a disagreement appears, keep both viewpoints in the record. An operations manager might rank the browser service first because many people rely on the service. A finance owner might rank the expense portal first because month close work has a fixed date. Write each stated consequence. Ask each owner for a short scenario behind their ranking. Then ask the security architect to choose scope based on stated policy and available evidence. Artificial agreement hides a decision from the people who need support later.

Finish the workshop by reading every populated row. Confirm application names, owners, user groups, normal sequences, proof actions, and open questions. Ask which unanswered question blocks a start. Schedule the next review around a concrete artifact, such as an owner supplied test sequence or identity flow description. Do not announce a broad rollout schedule from a partial inventory. The next design decision should follow observed proof results and policy choices recorded by security.

For practice, build a fictional worksheet with an expense portal, browser collaboration service, and contractor project portal. Give the expense portal a payroll analyst who must submit a sample request before Thursday 16:00. Give the contractor portal an owner who approves access for one test period. Ask a colleague to play Clara and raise a vague complaint about remote work. Turn the complaint into two written questions. Enter a test sequence for the affected row, then place the owner's review date beside the proof criterion before closing the worksheet.