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 source documents are stored in a tenant, the firm controls that storage and its account permissions. A connected service may still process material elsewhere. Check the complete data flow before concluding that there are no external copies or processing steps.

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 distinction matters most at the moments nobody plans for: an acquisition of the vendor, a change of terms, a breach on their side, or a subpoena served on them rather than on you.

An in-tenant arrangement can give the firm direct control over storage and identity permissions. That does not automatically mean information never leaves the environment: integrations and model processing may involve external services. Review the data flow, support access and provider terms as well as the deployment location.

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.

For an in-tenant deployment, explain which information is stored under the firm's controls and which external services process it. Client questions still require a documented account of subprocessors, support access, audit logging and retention. Hosting location alone does not answer those questions.

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.

For a deployment within the firm's own environment, agree the accounts, permissions and maintenance access with its IT team. Verdalyze can work with that arrangement where appropriate. It is one deployment option: other engagements use managed infrastructure, with client information handled securely and privately under agreed terms.

Day to day the firm's data then behaves like the rest of its estate: it sits behind the same identities as email and files, follows the same joiner and leaver process, writes to the same audit logs and inherits the same retention policies. Nothing new has to be trusted, because nothing new has been introduced between the firm and its data.

Model calls must be assessed separately from where documents are stored. A workflow may send the material needed for a task to a model provider, even if the source files remain in a client-controlled tenant. Agree the processing terms, access and retention for that call. The output returns as a draft for human review, with source references so it can be checked.

Because the workflow runs behind the firm's existing access controls, an agent can never show a person a document that person could not open themselves. That single property answers most of the questions a client's lawyers ask about AI, and it is a consequence of where the system runs rather than of any policy written afterwards.

For most small firms the tenant is administered by an external IT provider, and their sign-off is straightforward because nothing leaves the environment they already manage. The items they will want to confirm:

• Which accounts and permissions the deal system uses to read and write the firm's data.
• The scoped access route Verdalyze uses to maintain the system, and how it is audited.
• That multi-factor authentication and sensible admin roles are in place, since these are the firm's side of the bargain.
• Where the tenant's data is located, so the same answer applies to the deal system.
• How access is revoked when a person or a vendor leaves.

Each of those is a question the provider already answers for the firm's email and files. The deal infrastructure simply joins the list.

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.