Security Reviews with Regulated Customers
Treat security as a stakeholder: find the real requirement, show the data flow, and get to yes.
Security Reviews with Regulated Customers
In regulated customers (finance, health, government) the security review decides whether a project ships. Reviewers are not trying to stop AI; they are trying to answer a fixed set of questions with evidence:
Your job is to make those answers easy to give: a clear data-flow diagram, a control for each risk, and honest notes on what is not yet decided.
Why it matters
Projects that meet security late get blocked late, after the budget is spent and the sponsor has promised a launch date. Projects that bring security in during discovery usually find an acceptable design: a region-pinned endpoint, zero data retention, a private deployment, or an open-weight model running on the customer's infrastructure.
AI adds a few questions security teams have not always had to ask before: whether prompts and outputs are retained by a provider, whether retrieved documents respect the user's permissions, whether text inside a document can steer the system (prompt injection), and whether an agent's actions are attributable. Arriving with answers to these builds trust quickly.
How to do it
Meet security in week one, before the architecture is fixed.
Ask what they need to be true, not what they will block. "No data leaves Australia" is a requirement you can design for; "no AI" rarely is the real requirement.
Draw a one-page data-flow diagram with every boundary, processor and store, including the model provider, logging and backups.
Build a control matrix: for each risk, the control, the evidence and the owner (template below).
Agree a decision path for open items, with dates.
Keep the record with the project, and update it whenever the design changes.
A control matrix security can sign
| Risk | Control | Evidence | Owner |
|---|---|---|---|
| Customer data processed outside Australia | Model endpoint pinned to an Australian region; no cross-region fallback | Provider contract clause; endpoint config in repo | Platform lead |
| Prompts or outputs retained or used for training | Zero-retention agreement; training opt-out confirmed | Signed data processing addendum | Procurement |
| Users see documents they are not entitled to | Permissions filtered in the retrieval query, not after | Test suite: 40 cross-permission queries, 0 leaks | Engineering lead |
| Instructions hidden in documents steer the system | Untrusted content separated from instructions; high-risk actions need approval | Red-team test results | Engineering lead |
| Actions cannot be attributed | Every request and tool call logged with user and service identity | Sample log export to the customer SIEM | Platform lead |
| Access cannot be removed quickly | Service identity revocable in one step; documented runbook | Revocation tested on 2026-10-20 | Customer IT |Worked example: "no customer data may go to an external model"
A bank's CISO states the rule in the first meeting. Asking what must be true reveals three underlying requirements: data stays in Australia, nothing is retained by a third party, and the bank can audit every request.
Two designs meet them:
The team presents both with their trade-offs. Security approves the first for the pilot and the second as the fallback, and the project keeps its timeline.
In a real engagement
Bring a one-page data-flow diagram to the first meeting. It answers most questions before they are asked and shows you take the review seriously.
Never route around security through the sponsor. A project approved over security's objection is one incident away from being shut down.
Be precise about what you do not know yet. "Retention terms are being confirmed with the provider; decision by 25 October" is trusted. "It is fine" is not.
Test the controls, not just the design: run permission-leak tests and prompt-injection tests, and give security the results.
Challenge
Security says no customer data may be sent to any external model. Describe two architectures that could still deliver the use case and what each costs in quality or time.
Checklist
Production checklist
0 of 9 checked
Knowledge check
A CISO says the project cannot send data outside the region. What is the best first step?
Complete
You have finished “Security Reviews with Regulated Customers”. Continue to the next chapter or practise in the FDE simulator.
Mark this chapter as complete
Track your progress and unlock the next chapter.