Start with a small system map
Choose a specific workflow rather than attempting to model the entire organization at once. Sketch the users, services, data stores and external dependencies involved. Mark where information crosses between areas with different access rules or owners. The drawing does not need polished notation. Its purpose is to help the group agree on what exists and identify where their understanding differs before implementation makes those assumptions harder to change.
Ask concrete questions
Follow a request through the drawing. How is the caller identified? Where is permission checked? What happens if the same request is repeated or arrives with unexpected data? Who can change the configuration? Keep the discussion tied to the system in front of you. Useful questions often expose missing requirements, such as a need to separate administrative access from ordinary use or to avoid placing sensitive information in application logs.
Turn concerns into decisions
Record each meaningful concern with its potential impact, existing protections and next action. Some need a design change; others need a test or more information. Assign an owner and a review point. If a risk is accepted, document who made that decision and why. This avoids producing a long list that appears thorough but leaves the delivery team uncertain about what to do next.
Return when the architecture changes
A model describes a particular understanding of a system. Revisit it when adding a new integration, opening access to a different audience or changing where sensitive data is processed. Keep the diagram and decisions close to the engineering documentation. The goal is a repeatable conversation that improves design, supported by specialist review where the consequences or complexity justify it. A single workshop should not be treated as a security guarantee.
Working through a similar question?
Tell us about your context and the decisions in front of you.
Talk to LUNAR LABS