Where it runs: the building, your tenancy, or a vendor

Self-hosted, private cloud and enterprise SaaS are not points on a quality scale. They are three answers to one question: whose systems hold the data while the work is done. That question is what your constraints record from module 01 answers, and it is why the constraint conversation comes before the tool conversation.

Each class has an honest case. Self-hosted when the data may not leave; private cloud when it may leave the building but not your control; SaaS when the vendor’s written commitments are sufficient and the operational burden is what you are buying your way out of.

This site derives a transfer verdict from the architecture rather than asserting one: none, metadata only, some, or yes. It is computed from the edges of the diagram, so a recipe cannot claim that nothing leaves while drawing an arrow to a vendor.

The rung worth understanding is the one people argue about. Sending documents into your own cloud tenancy is not “none”. You still control the account, but the documents have left the building, and that is exactly the fact a data-processing question turns on. A deployment that answers this wrongly in a security questionnaire loses more time than one that answers it honestly.

Open a recipe’s architecture and look at the boundary box first, then at every arrow that crosses it. For each crossing ask what is on it, who receives it, and what contract governs the receipt. That is the whole method, and it is the same method a customer’s risk function will apply to your design.

Do it on someone else’s design before you do it on your own. Comparing two recipes that reach different verdicts is the fastest way to see what causes the difference.