Practice: Security reviews, governance and compliance in regulated industries
Generated by Claude through GigAI 0.1.11.10 on 2026-10-12.
Main tool: OWASP ASVS · OWASP ASVS gives a regulated customer's reviewer a list of verifiable application security requirements, and the OWASP threat modeling process is the laptop-only way to decide which of those requirements your AI deployment must meet and to prove it. · Alternatives: NIST SP 800-53 is a broad control catalog for whole organisations and federal systems rather than a testable application checklist; OWASP Threat Dragon is a diagramming tool that draws and stores the threat model but does not supply requirements; Open Policy Agent enforces access rules as code at run time instead of documenting them; Presidio detects and masks PII in text but covers only that one control; Vault and cloud key management services hold keys and secrets and are evidence for a control, not the framework itself.
Every step links into the tool's own documentation; links were checked on 2026-10-12 · version 1
Setup (one time)
1. Read the introduction to the OWASP threat modeling process and note the four steps it follows.
The whole path follows these four steps, and the ASVS requirements you pick later only make sense once threats are identified this way.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: You can name the four steps from memory and say what each one produces.
2. Create a local version-controlled folder for the review pack and choose one sample AI deployment to model, such as a retrieval assistant that answers questions over customer records containing PII and card data.
Scoping one concrete system keeps every later artifact specific. A folder under version control lets the model be reviewed and repeated like code.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: The folder exists with a one-paragraph scope note that names the system, its users and what is out of scope.
3. Install any free diagramming tool on your laptop and read the data flow diagram symbols the process uses.
Every later step refers to the processes, data stores, flows and trust boundaries on this diagram, so you need the notation before you draw.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: You can draw and label a process, a data store, a data flow and a trust boundary in your tool.
Steps
1. Write the threat model information header for your sample deployment: application name, version, description, document owner, participants and reviewer.
This is the first artifact a customer reviewer reads. It fixes exactly which version of the system the review covers.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: A header file in your folder has every field from the sample filled in for your deployment.
2. Create the external dependencies table, listing the model endpoint, the vector index, the identity provider, the key manager and the logging store.
In an AI deployment most of the risk sits in components you do not own. Reviewers ask about each of them by name.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Each dependency has an ID and a description stating what your system assumes about it.
3. Write the entry points table, covering the chat interface, the document ingestion job, the retrieval query path, tool calls and the admin console.
Entry points are where an attacker reaches the system. For an AI system they include prompts and ingested documents, not only web endpoints.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Every way data or instructions can enter the system has an ID, a description and the trust levels allowed to use it.
4. Create the assets table, listing raw PII and payment data, then the derived data: embeddings, index entries, prompt and response logs, caches and evaluation sets.
Derived data carries the same regulated content as its source and is the part teams forget. It must be a named asset before it can be governed.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Each derived data item appears as its own asset with an ID and a note saying which source data it was built from.
5. Write the trust levels table, then record for each derived data asset which trust level may read it, how long it is kept and how it is deleted when the source record is removed.
Governance of retention, deletion and access is only reviewable when each rule is tied to a named asset and a named trust level.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Every derived data asset has an access rule, a retention period and a deletion path written next to it, with no blank cells.
6. Create the data flow diagram for the deployment, drawing trust boundaries around the customer network, your application, the model endpoint and the index.
The diagram shows where regulated data crosses a boundary inside a prompt or an index write. Those crossings are where controls are needed.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Every entry point, asset and external dependency from your tables appears on the diagram, and each flow carrying PII or card data is labelled.
7. Run a STRIDE pass over every element and boundary crossing on the diagram, adding AI cases such as prompt injection through ingested documents and leakage of another user's records through retrieval.
Walking the six categories element by element is what makes a threat model complete rather than a list of the threats you happened to think of.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: A threat list exists where each threat has an ID, a STRIDE category, and the diagram element and asset it affects.
8. Compare the threats with the qualitative risk model and rank them, scoring likelihood and impact for each.
A reviewer wants to see that the highest risks got controls first. The ranking also tells you which ASVS requirements are mandatory for this deployment.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Every threat has a risk rating and the list is sorted with the top five clearly marked.
9. Write a countermeasure for each ranked threat using the STRIDE mitigation techniques, then map each one to the matching OWASP ASVS requirement and the matching NIST SP 800-53 control family in two extra columns.
Regulated customers ask in the language of their control framework. A mapping from threat to control to requirement lets them tick off their checklist quickly.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: No ranked threat is without a countermeasure, and each countermeasure names one ASVS requirement and one NIST SP 800-53 family.
10. Write the data protection countermeasures for each flow labelled as PII or card data: encryption in transit and at rest with a named key owner, and masking or tokenising of values before they reach a prompt, a log or the index.
Information disclosure threats against regulated data are closed by encryption and masking. The reviewer needs to see which control sits on which flow.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: Each labelled flow on the diagram has an encryption control and a masking decision recorded, with each threat marked mitigated, partially mitigated or not mitigated.
11. Reproduce the assessment from scratch after changing one thing in the design, such as adding a new tool call, and configure a checklist in the repository that must be completed on every design change.
A threat model that is not rerun on change goes stale. A repeatable assessment step is what turns it into a standing control rather than a one-off document.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: The repository history shows a second pass with updated tables and diagram, and a checklist file lists the checks to repeat on each change.
12. Package the review pack as you would hand it to a customer security team: scope, diagram, asset and trust tables, ranked threats, the control mapping and the open risks, then use it to direct a code review of the highest-risk entry points.
This is the production-like end state. A complete pack that already links threats to code and controls is what makes a customer security review go quickly.
Explained in: Threat Modeling Process (Historical) | OWASP Foundation (community.owasp.org), checked 2026-10-12
Done when: A single document in the folder lets a colleague acting as reviewer trace any top threat to its control, its ASVS requirement and the code area to inspect, without asking you a question.
Back to Security reviews, governance and compliance in regulated industries