Security is the
critical path.

Engineers tend to file security under “things to clean up before launch.” In an FDE deployment, that framing loses deals. At most enterprises the security and compliance function holds a genuine veto: no matter how much the users love your solution, if security says no, it doesn’t ship. And security teams say no reflexively to anything they don’t understand or weren’t consulted on.

So the move is to treat security as a stakeholder from discovery onward, not a gate at the end. Ask early: “What does it take to get a new tool approved here?” Loop the right person in before you’ve committed to an architecture. A security requirement discovered in week one is a design input; the same requirement discovered in week six is a rebuild — or a dead deal.

The practical takeaway is a hierarchy of avoidance: the easiest compliance problem is the one you design out of existence. Don’t store card data. Don’t move health data off-network. Don’t collect personal data you don’t need. Every category of sensitive data you can avoid touching is an entire class of requirements you skip. The quick-reference keeps these straight in the moment.

Underneath every framework sit the same few data disciplines. Get these right and you’re most of the way to any of them.

The phrase to remember is less data, less risk. Every sensitive field you don’t store is a field that can’t leak, can’t be subpoenaed, and can’t sink a review. Data minimization is the cheapest security control there is.

Secrets are where good intentions meet a leaked GitHub repo. In a customer deployment the rules tighten, and the reviewer will ask about every one of them.

There’s a strategic angle here: least privilege is a speed tactic. A tightly scoped access request is easy for security to reason about and approve; a broad one demands a deep review. Asking for exactly what you need — and no more — is often how you deploy this quarter instead of next.

Eventually you’ll sit across from (or send a questionnaire to) the security team. Walk in with the answers and it’s a conversation; walk in empty and it’s an interrogation that stalls for weeks.

Two principles make reviews go fast. A smaller ask gets a faster yes — minimize scope and footprint so there’s less to scrutinize. And involve them early — a team that helped shape the design defends it; a team ambushed at the end blocks it. Security is a relationship, not a checkpoint.

Because so many deployments now put an LLM to work on the customer’s data, three AI-specific risks land squarely on the FDE.

These deserve their own study — the AI security handbook goes deep — but the FDE-level instinct is simple: assume any content the model reads could be adversarial, and assume anything you send to a model could leave. Design around both, and you’ll answer the AI security questions before the customer knows to ask them.

Two properties combine badly in every AI deployment. A model treats retrieved content as information, and content retrieved from a customer’s systems is written by people — including, sometimes, people outside the company. A claim document, a support ticket, a supplier email and a PDF filename are all untrusted text that will end up in a context window next to your instructions.

The instinct is to filter for suspicious phrases. It is a reasonable defence-in-depth layer and a weak primary control, because paraphrase defeats it and because leading with it tells a reviewer that the architectural boundary is not there. The framing that holds is: assume the injection succeeds, and make the consequence small.

The second assertion is the one most often got wrong in a way that looks fine. Filtering retrieved chunks against the user’s permissions after retrieval leaves the model having read documents that user cannot see, and the answer it generates is derived from them. The boundary has to be at retrieval or it is not a boundary.