Lead an Identity and Access Management Discovery Call

An identity and access management discovery call loses focus when every concern enters one broad category. A buyer might mention delayed onboarding, old accounts, privileged access review, late approvals, or scattered records. Each issue involves different people, source records, and decisions. Start with one event from recent work. You leave with a usable description instead of a long list of labels.

Ask the identity leader to choose a recent onboarding, role change, departure, temporary assignment, privileged request, or evidence search. Choose the event with the clearest friction. Recent work gives both people something concrete: who started the request, systems involved, approvers, wait points, and records created along the way. A general complaint rarely supplies enough detail for a useful next meeting.

Open with one simple question: “Which recent access event created the most work or uncertainty for your team?” Pause. An identity leader might answer with a control name, a project label, or a statement about inconsistent ownership. Use their language, then ask for the situation behind those words. “Please walk me through the last example. Who noticed the issue first, and what happened next?” This moves a conversation from labels toward observable work.

Consider a fictional practice situation. Harbor Field Services, a fictional company, hired Sam as a regional operations manager on August 5. Sam needed email, a scheduling application, reporting access, and a shared project folder. Human resources created Sam’s employee record Monday morning. Sam’s manager sent access requests later Monday. One application owner approved Tuesday. Another owner saw a request Thursday. Sam received all requested access Friday afternoon.

Do not jump from Sam’s delay to a product discussion. Map the current route in the buyer’s own terms. Ask who begins each request, where approval occurs, which person performs access changes, and how Sam learns completion. Then ask what begins work after a role change. One application owner might wait for a manager email while another checks a weekly spreadsheet. Those differences matter more than a broad statement about manual work.

Write each step into a shared note during the conversation. Say, “Human resources creates the employee record Monday. The manager requests access. Application owners approve separately. An operations administrator grants access. Sam receives an email after completion.” Invite correction. This readback often reveals an omitted handoff. Perhaps nobody verifies access after a grant. Perhaps a manager contacts support when approval sits too long. Ask for the actual route rather than treating an exception as an error.

Ask for the decision behind every handoff. “What information tells the manager which applications Sam needs?” “What does an application owner check before approval?” “Who decides whether Sam’s role fits access already granted?” Answers might point to a job title, manager judgment, a local document, or details held outside the employee record. Do not label email weak on sight. Ask what outcome the identity leader wants from a different operating approach.

Use specific language for risk. “Access risk” might refer to a former worker with folder access, late access for a new worker, broad access granted to prevent delay, or approval evidence no one finds later. Ask which outcome worries the buyer most in the selected event. Follow with questions about frequency, exception detection, and response after someone notices. Do not estimate impact or score risk unless the buyer brings a method and supporting information.

User experience also needs an event, not an opinion. Sam’s first week provides a useful frame. Ask when Sam received instructions, what work waited for access, whom Sam contacted, and whether a person owned follow up. An identity leader might say Sam used a colleague’s workstation during the wait. Record this as a reported workaround in this fictional situation, not a claim about every employee. Ask where workers go when a request stalls.

Bring an application owner into later discovery where practical. An identity leader explains the broader route, yet an application owner often knows why an exception occurs. In the fictional Harbor Field Services situation, the reporting owner says regional managers need access based on contract area. Human resources does not store contract area in Sam’s employee record. Operations sends this detail through a shared spreadsheet. The team now has one clear information gap to examine.

Ask which person owns each decision without assigning ownership yourself. Ask who defines role access, who approves exceptions, who responds when a manager disagrees, and who maintains application records. Separate participation from decision ownership. An operations manager might submit a request. An application owner might decide access. An identity administrator might perform a change. A security leader might review evidence. The selected event makes each contribution visible.

Evidence deserves a separate route. Do not assume an approval record proves a grant, or a grant record proves correct approval. Ask where each record should appear after the event closes. Ask who retrieves records during internal review and what slows retrieval. In this fictional example, a reviewer needs the request, manager approval, application owner approval, and completion record. The identity leader says each record lives in a different place. This is a focused subject for later evaluation.

Test the stated route with an exception. Ask about the last urgent request, late owner response, changed manager decision, or worker transfer. “What happened when Sam’s regional assignment changed two weeks after the start date?” produces more detail than “How do you handle exceptions?” The buyer might describe a correction, a new approval, or a support message. Follow each action in sequence. Avoid calling deviation a failure before learning why people chose the route.

Keep the meeting narrow. You do not need every application, every policy, or every future initiative in one session. Near the close, repeat the selected event, people involved, systems, missing information source, and next buyer decision. Ask whether your notes match their description. If a solutions consultant needs a technical answer, write one precise question and agree who will answer.

Practice with a fictional role play. A colleague plays an identity leader and says, “Our controls vary across teams.” You respond, “Which recent access event shows this most clearly?” The colleague chooses an offboarding event. Ask for the person’s last day, systems involved, request source, owner actions, completion record, and one exception. An observer stops the practice whenever you begin product discussion before learning the event.

Run a second practice round where the identity leader uses control terms without an example. Say, “I want to understand how those terms affect work. Please take me through the last request where evidence took time to collect.” Write supplied facts and label unknown points. Before setting another meeting, ask the leader to confirm the sequence. For your next call, create fields for trigger, request source, approval, access change, completion notice, and evidence location. Fill each field with the buyer’s words, leave unknown fields blank, then ask which owner should discuss the missing contract area detail from Sam’s fictional onboarding situation.