Discuss AppSec Prioritization in the Development Sprint

An application security backlog often holds more findings than a development team plans to address during one sprint. Your sales conversation should not begin with a promise of more alerts or a claim saying every issue deserves equal attention. Begin with the customer decision process. Learn how a finding reaches an engineer, who assigns ownership, and why a security concern loses priority beside release work.

Ask for one recent example instead of an opinion about the whole program. Say, “Think about a finding from the last completed sprint. What happened from first notice through a developer decision?” A buyer might describe a scanner result entering a shared queue, then waiting for an AppSec analyst to identify an application owner. Another buyer might describe an engineering manager reviewing findings only during a planning meeting. Each account reveals a different delay.

Keep your questions close to decisions. Ask whether developers receive application context, location details, evidence of exposure, ownership information, or remediation guidance from an authorized specialist. Ask which information creates trust and which information creates debate. Then ask who resolves disagreement when an AppSec priority conflicts with a release date. You seek a route from finding to action, not a complaint about any person or team.

Suppose a fictional online marketplace has one AppSec group and four product teams. Findings enter a shared queue every Monday. During the last fictional sprint, an analyst added eight findings. Five lacked a named product owner. Two had owner names, yet no release milestone. One reached a developer because an engineering manager recognized the affected service. The AppSec lead says developers ignore tickets. Treat this as a workflow question, never a verdict on developer effort.

Separate facts from interpretation. Facts include the shared queue, the missing owner field, and a finding selected by an engineering manager. “Developers ignore tickets” describes frustration, yet needs examination. Ask, “When a developer sees one of these tickets, which information is missing before work enters a sprint?” The engineering manager replies, “We need service ownership, planned release work, and whether the issue affects a public path.” Those answers give your review session a useful boundary.

Choose one representative finding with customer approval. Pick an item whose record shows a known handoff problem, such as an issue without a product owner or release context. Do not choose an unusually urgent example merely to create pressure. A representative item helps participants inspect ordinary work. In the fictional marketplace, select the finding with an identified service yet no assigned product owner. Mark practice details as fictional unless the customer supplies approved data.

Invite people involved in the decision. An AppSec lead explains how findings enter review. An engineering manager explains sprint planning and release priorities. A product owner or service owner explains application context. Set the question: “What would help this team decide whether this one finding belongs in a planned sprint, needs more research, or should wait under your existing process?” Customer participants retain every security and delivery decision.

Write a session note before invitations go out. Name the selected finding, the ownership gap, and the decision required on Friday. Send the note to each participant with a request for corrections. An early correction keeps your meeting focused on a record everyone recognizes instead of an issue selected from incomplete information.

Before the session, ask each participant for one source already used in daily work. The AppSec lead might bring a finding record. The engineering manager might bring a sprint planning view or written priority rule. A product owner might bring service ownership notes. Do not request broad system access. A narrow set of customer approved records supports a useful conversation without widening scope.

Walk through events in order. First, review how a finding arrives. Next, inspect whether service ownership appears. Then ask how a product team learns about release timing and user exposure. Finally, ask where a decision gets recorded. A gap becomes easier to name when everyone sees where movement stops. Avoid a feature tour before the group agrees on this sequence.

Use dialogue which respects people doing the work. In a fictional roleplay, the AppSec lead says, “We send reports every week, yet owners do not respond.” You reply, “For this example, what does a developer see first, and which detail would make an owner clear?” The engineering manager says, “The ticket names a component, yet nobody knows which product owns the component.” Ask next, “Where does your team maintain service ownership today?” This question opens a path without blame.

Actionable information means more than severity labels. A development team might need a clear owner, affected service, release context, remediation guidance from an authorized specialist, and a decision record. Exact inputs belong to the customer workflow. Do not state a tool ranks issues correctly or removes human judgment. Staffing, product context, and internal priorities shape each sprint decision.

Ask about exception routes too. A finding might need more investigation. A product owner might dispute service ownership. A release deadline might require an existing customer escalation route. Learn where such cases go and who responds. If a buyer says risk acceptance exists, ask who records the decision and which context they need. Do not suggest policy changes or security outcomes. Your purpose involves understanding current work before a limited evaluation.

At the end of a workflow review, write observed details and open questions separately. An observed detail in the fictional marketplace reads, “The selected finding named a service yet lacked a product owner.” An open question reads, “The engineering manager will identify the ownership source used during sprint planning.” This distinction stops an account executive from presenting an assumption as an outcome.

Agree on a test small enough for a sprint discussion. The fictional team chooses one finding on Tuesday. The engineering manager identifies the ownership source by Wednesday. The AppSec lead adds approved practice context before Thursday. On Friday, the product owner and engineering manager decide whether the finding enters the next sprint, needs more research, or follows an existing exception route. Record only statements participants confirm.

DealSpeak coaching should assess whether an account executive reached a real decision path, named participants, and set a bounded next step. Coaching should also listen for blame. “Developers ignore tickets” should lead to a question about missing context, not a speech about engineering discipline.

For the fictional marketplace, ask the engineering manager to bring the ownership source for the selected finding on Wednesday. Place a fifteen minute decision review on Friday, open the selected finding, and ask the product owner to name the next route for the record.