Threat-model a workflow before a security checklist

A security review becomes more useful when everyone can point to the same business process. Start with an important workflow, such as supplier onboarding or payment approval. Describe what success means, who can influence each step, and where information crosses between people or systems. Then choose controls that address the actual concerns.

Draw what the team is protecting

OWASP describes threat modeling around four questions: what the team works on, what can go wrong, what to do, and whether the result is adequate.[7] Use those questions to keep the review tied to decisions rather than a list of product names.

A data flow diagram shows components, data movement, and external interactions. OWASP identifies it as a common modeling technique.[7] The first version can be simple. Include users, storage, outside services, and trust boundaries, where one party must decide whether to trust another party’s input or authority.

Discuss failures in business terms

Invite operations staff to describe what an incorrect outcome looks like. Could the wrong person approve a supplier change? Could an attachment reach an unrelated reviewer? Could a retry create a duplicate action? These are questions to investigate, not assertions that the system contains those defects.

Recommend ranking concerns using plausible access, business impact, and existing controls. Record assumptions separately from verified behavior. A short model with explicit uncertainties is more useful than a detailed diagram that quietly assumes every external service behaves correctly.

Hypothetical example: supplier bank changes

In a hypothetical procurement workflow, a supplier submits changed payment details. A reviewer approves the change and an integration passes it to finance. The workshop identifies a trust boundary between the submitted request and the reviewer’s authority.

The proposed response separates submission from approval, verifies the approved change at handoff, and records a safe audit event. The team then asks how those controls behave during reassignment or an integration retry. This hypothetical model does not demonstrate that the eventual implementation enforces the proposed rules.

Convert the model into acceptance work

OWASP includes mitigations and review and validation in its process.[7] For each priority concern, decide whether to reduce, avoid, transfer, or explicitly accept the risk. Keep unresolved choices visible.

• Identify the asset and unacceptable outcome for each priority concern.
• Mark external inputs and changes in authority on the workflow.
• Assign each control and unresolved assumption to an owner.
• Write a test or review method for every selected response.
• Revisit the model after new integrations or approval paths appear.

Keep the scope small enough to finish

A workshop cannot prove the absence of threats. Too much scope can produce a document nobody maintains. Start with one high-value path and record what remains outside it. Use checklists afterward to find missed controls, rather than treating checklist completion as evidence that the business workflow received a meaningful review.