The Questions a Risk Committee Should Ask of Anything That Touches Intune

Direct answer: Before any platform connects to your Microsoft tenant, ask six questions: how people sign in, what it can do in your tenant and who granted that access, where your data is held and whether it’s kept separate, where your application packages live, what it checks before it deploys anything, and exactly how you remove it. Clear answers let a security review move quickly. Vague ones stall the project and leave the estate as exposed as it was.

Why Security Reviews Stall Good Projects

Any platform that connects to your Microsoft tenant should face a short set of questions from the risk committee. In regulated sectors, it will.

The problem is timing. Those questions usually arrive late, after the IT team has seen a product and wants to move. When the answers are vague, the project sits in review for weeks, and in the meantime nothing improves. The unpatched applications stay unpatched. The estate stays exactly as exposed as it was.

The better route is to ask, and answer, the questions up front. Here are the six we’d put to any tool that touches Intune, with what a good answer looks like.

1. How Do People Sign In?

Ask whether the platform has its own usernames and passwords, or uses your identity provider.

A good answer: single sign-on through Microsoft Entra ID, with no separate passwords, so your own MFA and Conditional Access policies apply to every sign-in. A separate login is one more credential to manage and one more place your policies don’t reach.

2. What Can It Do in Our Tenant?

Ask how the platform reaches your tenant, which permissions it holds, and who grants them.

A good answer: it connects through an enterprise application your own administrator consents to, with the permissions listed up front. Those permissions then sit in Entra ID like any other enterprise application, where you can review them and revoke them yourself.

3. Where Is Our Data Held, and Is It Kept Separate?

Ask where customer data is hosted, whether yours shares a database with other customers, and what security standards the supplier operates under.

A good answer: a named hosting region, a separate database per customer, and recognised certifications the supplier holds.

4. Where Do Our Application Packages Live?

This one is often missed. When a platform builds and holds your application packages, it holds part of your estate. If you ever change direction, getting them back can be harder than anyone expected.

A good answer: the packaged applications, and everything that goes with them, are stored in your own storage, in your own subscription, under your own access policies.

5. What Does It Check Before It Deploys Anything?

A platform that packages and deploys software is a powerful route into every device you manage. Ask what it checks before an installer becomes a package, and how changes reach production.

A good answer: every installer is verified against its expected hash and scanned for malware before it’s packaged, and anything that fails is deleted rather than deployed. New versions go to named testers first, then to production in phases that can be rolled back.

6. What Happens When We Want It Gone?

Ask exactly how you’d leave: what happens to your data, and how access is removed.

A good answer: a defined, two-part exit that you control. Removing your tenant from the platform deletes the data it holds; removing its enterprise application from Entra ID removes its access. Neither step should depend on the supplier.

How ALICE Answers Them

These are the answers for ALICE.

Sign-in: Microsoft Entra ID single sign-on is the only way in. There are no ALICE passwords, and your own MFA and Conditional Access policies apply to every sign-in.
Permissions: ALICE reaches your Intune through an enterprise application your administrator consents to, using application permissions. The access is granted by you, and you can revoke it at any time.
Data: each customer’s data sits in its own separate database, hosted in Azure UK South. Camwood, which runs ALICE, is ISO 27001 certified, and separately holds Cyber Essentials certification for the whole organisation, ALICE included.
Packages: your packaged applications, Intune files, documentation and test evidence are stored in your own Azure storage account, in your own subscription. ALICE is connected to it through a Microsoft Entra role assignment, the default and recommended setup.
Before deployment: every installer, whether it comes from the catalogue, your own private repository or a manual upload, is hash-verified and scanned for malware before it’s packaged. A mismatch or detection deletes the installer and fails the package. New versions then go to named testers and through phased rollout in your own Intune, and any phase can be rolled back.
Your in-house applications: you keep their installers in a private repository, an Azure storage container you own. ALICE watches it for new versions, checks each one, and builds a new package that inherits the previous configuration.
Leaving: removing the tenant from ALICE deletes the data it holds. Deleting its enterprise application from Entra ID removes access. Two separate steps, both yours.

More on where your packages live: Your Packages, Your Storage.

A Question List to Take Into Your Next Review

Copy these into your supplier questionnaire:

How do users sign in, and do our MFA and Conditional Access policies apply?
How does the platform reach our tenant, which permissions does it hold, and can we review and revoke them ourselves?
Where is our data hosted, is it kept in its own database, and which security certifications apply?
Where are our application packages stored, and who controls access to them?
What checks run before an installer is packaged or deployed, and can a deployment be rolled back?
What exactly happens to our data and access when we leave?

Control first. Capability second. Both answered before you buy.

Frequently Asked Questions

Which questions should a risk committee ask before connecting a tool to Intune?

How people sign in, what the tool can do in your tenant, where your data is held and whether it's separate, where your packages live, what it checks before deploying, and how you remove it.

How do you check what a connected tool is allowed to do in your tenant?

Where are ALICE's application packages stored?

How do you remove ALICE completely?

Bring Your Security Team's Questions

Start a 14-day trial in your own tenant, or book a demo and bring your security team with their questions. We’d rather answer them up front.

ALICE is Camwood‘s platform for Autonomous Application Lifecycle Management: discover, rationalise, package, deploy and patch through your own Intune, with every decision kept on one record.