CPLT
Talk to me — I don't bite
All posts
architecture-reviewsecurityvendor-assessmentmethod

Named or Assumed: The First Question I Ask of Any Architecture Document

The weak point of most architecture dossiers is the sentence that says security is 'handled by the platform.' Here's the one distinction that separates auditable inheritance from a gap in disguise.

Stéphane Lepain··4 min read

I read a lot of architecture documents. Different vendors, different stacks, different templates — an ERP dossier one month, a cloud design the next, an AI vendor's security whitepaper after that. They don't fail in the same places. But they almost all fail in the same way.

Somewhere around the middle, there's a sentence like this:

"Authentication and access control are handled by the platform."

That sentence is doing an enormous amount of work, and nobody is checking whether it can lift the weight.

Two sentences that look identical

Compare these:

"Access control is inherited from Platform X, as described in document Y, section 4.2."

"The platform handles access control."

They read like the same claim at different levels of politeness. They are not the same claim. They are opposites.

The first one is inheritance. There's a name, a reference, a section number. You can go get document Y, read section 4.2, and check three things: that the control exists, that it does what this dossier thinks it does, and that it actually covers this system and not just the platform's own components. Someone can be wrong here — the reference might be stale, the control might not extend to this use case — and that's exactly what makes it reviewable. A claim you can falsify is a claim you can audit.

The second one is an assumption dressed as inheritance. There's no reference to follow, no control to verify, no document where the claim lives. Nobody owns it. The application team believes the platform team handles it; the platform team has never heard of this application. On paper, nothing is wrong — which is precisely the problem, because nothing is checkable either.

I've started calling the second kind a gap wearing inheritance's clothes. It has the shape of a control. It has the vocabulary of a control. What it doesn't have is anyone on the other end.

Where these gaps go to wait

Assumed controls don't blow up during review. That's what makes them dangerous — review is the one moment everyone is looking, and an assumption reads fine when you're skimming.

They surface later, and always in the same costume. An incident review, eighteen months on, and someone says the sentence I've heard in too many rooms:

"We thought that was covered."

Not "we decided to accept that risk." Not "we checked and were wrong." We thought. The gap was never anyone's decision — it was a handoff both sides believed the other had caught.

The question, and why it needs no product knowledge

So this is the first thing I ask of any architecture document, before I care what the system does or what it runs on:

For every security claim: is this named, or assumed? And what does it sit on?

That's it. You don't need to know the platform. You don't need to have administered the product. You're not evaluating whether the control is good — you're evaluating whether the control exists as a claim someone can be held to. A junior reviewer can apply this on day one, and it will embarrass documents written by twenty-year veterans.

In practice it turns into a short checklist:

  • Does the document name the platform, service, or team providing each inherited control?
  • Does it reference where that control is described — a document, not a vibe?
  • Does the referenced control actually cover this system, or just the provider's own perimeter?
  • Is there any claim resting on "handled by," "managed by," or "provided by" — with no noun behind it?

Anything that fails the last check goes on a list, and that list is usually the review.

The AI clause

I said this works on any architecture document. Right now there's one place it earns its keep more than anywhere else: AI vendor documentation.

"The model provider handles data security" is the 2026 version of "the platform handles authentication." It shows up in integration designs, procurement memos, DPIAs — carrying an entire compliance story on its back, mostly unexamined. Handles it where? Under which agreement — the consumer terms or the enterprise DPA? Does "no training on your data" cover the logs? The subprocessors? The retention window?

Named, or assumed?

If the document can answer with a reference, you have an architecture. If it answers with confidence, you have a hope.

And hope, in a dossier, is easy to spot once you know its uniform: it's the sentence with no name in it.

Named is a control. Assumed is a hope with formatting.