What running inside your own Microsoft tenant actually means

Your tenant is your firm's own instance of Microsoft's cloud: the identities, mailboxes, files, permissions and policies that belong to your organisation. If your firm uses Microsoft 365, you already have one. Everything inside it is governed by your administrator settings, your access rules and your retention policies, not by any supplier's.

When software runs inside the tenant, it means the application, its database and its documents live in that same environment, under accounts your firm controls. There is no second copy of your deal data anywhere else.

Most software sold to advisory firms works differently. Your data is transferred to the vendor's own infrastructure and sits in the vendor's database, usually alongside data from their other customers. Access is governed by the vendor's internal policies, and your protection is contractual: a data processing agreement describes what they promise to do and not do.

Contracts matter, but they are promises about behaviour, not constraints of architecture. Structurally, the vendor's engineers can query the data, and depending on the terms it may also feed the vendor's analytics or model training. That is not an accusation of bad faith. It is simply what the architecture permits, and confidentiality assessments should start from what is possible rather than what is promised.

The in-tenant arrangement removes whole categories of exposure rather than mitigating them. Your deal data never leaves your environment, so there is no vendor-side copy to breach, subpoena or misplace. It is never pooled with other firms' data. It is never available to train anyone's models. And when your firm revokes access, access is actually revoked, because the systems sit behind your own identity controls rather than a vendor's login page.

Access control stops being a separate chore. Because the deal system sits behind the same identity as email and files, your existing joiner and leaver process covers it automatically: the moment an account is disabled, that person is out of everything, including the deal infrastructure.

Client questions get easier to answer. When a client or their lawyers ask where their confidential information is held, the answer is your firm's own environment, governed by your firm's controls, rather than a list of subprocessors in three jurisdictions. Audit trails and retention behave the same way: activity lands in your logs, and your retention policies apply without special arrangements.

Running in your own tenant shifts some responsibility to you. Your tenant hygiene matters more: multi-factor authentication, sensible admin roles and a tidy permission structure are your side of the bargain. Whoever maintains the software needs an agreed, auditable access route into the environment to ship updates. And when something needs attention, the conversation is with your team and your engineers rather than a vendor's status page.

These are real obligations, but they are the same obligations a firm already carries for its email and documents. Nothing new has to be trusted; the deal infrastructure simply joins the estate the firm already controls.

Five questions expose the architecture quickly. Where exactly is our data stored, and under whose account? Can your staff read it, even in principle? Is any of it used for analytics, benchmarking or model training? What happens to it when we terminate? And who controls access revocation, us or you?

Vendors with a defensible architecture tend to answer these quickly and specifically. Vague answers are also information.