Seven questions to ask any third-party tool on your Microsoft 365 tenant
SOLUTION GUIDE
Every Microsoft 365 vendor asks for some level of access to your tenant. The tools that will still be safe to run in three years are the ones whose vendors can answer specific questions about how they authenticate, what they hold, and what an attacker gets by breaching them. This is the seven-question checklist worth running any prospective third-party Microsoft 365 tool through before you approve admin consent, with guidance on what good answers look like, what to treat as a red flag, and how to verify each claim independently.
Question 1: Delegated or application permissions?
Why it matters. This is the most fundamental design choice a Microsoft 365 vendor makes. Delegated permissions mean every request happens as a specific signed-in user, subject to that user's existing SharePoint and OneDrive permissions. Application permissions mean the vendor's app authenticates as itself, holding tenant-wide credentials on the vendor's servers, and can access data across the tenant regardless of any specific user's session. Neither is inherently wrong, but they are for different jobs.
What a good answer looks like. The vendor can name their model clearly and explain why. For a user-facing productivity tool: "delegated only, here are the specific scopes." For a background service that legitimately needs tenant-wide access: "application permissions, here are the specific scopes and here is why they are needed."
Red flags. Cannot answer clearly. Cannot list the scopes. Uses application permissions for a user-facing tool without a clear operational reason. Requests broad-scope application permissions such as Files.ReadWrite.All or Sites.FullControl.All when a narrower scope would work.
How to verify. The admin-consent screen shown by Entra ID when the app is installed lists every permission scope the vendor is requesting, labelled delegated or application. This is not something you have to trust. It is shown at the moment of approval.
Question 2: What credentials does the vendor hold that authenticate to our tenant?
Why it matters. If the vendor holds a client secret, certificate or long-lived refresh token that authenticates to your tenant, then a breach of the vendor's systems is a breach of the door to your tenant. This is the SolarWinds pattern, the Okta pattern, and the recurring pattern in supply-chain compromises generally.
What a good answer looks like. "We hold no client secret or certificate that authenticates to your tenant. Access tokens for your users are held on user devices only, are short-lived, and are scoped to a single user." Or, for tools that legitimately need application permissions: "Yes, we hold a client secret for your tenant. Here is how we protect it: per-tenant secret rotation on a scheduled interval, hardware security module for storage, secret access is logged and reviewed."
Red flags. Vague answers. "It is all encrypted" without describing the credential architecture. Cannot describe how a compromise of their infrastructure would affect your tenant. Cannot describe their credential rotation policy.
How to verify. Ask for the credential rotation policy in writing. Ask for the relevant section of their most recent penetration test report or SOC 2 Type II access-controls review. Look for specifics, not reassurance.
Question 3: If the vendor is compromised, what is the blast radius inside our tenant?
Why it matters. Third-party supply-chain compromises are common. The relevant question is rarely "will our vendor ever be compromised" but "what happens to us when they are." A vendor who has thought this through can describe it in one paragraph; a vendor who has not will change the subject.
What a good answer looks like. A specific description of exactly what an attacker would gain by breaching the vendor. Ideally: "The attacker would have access to our own systems (metering data, configuration policies for your tenant). They would not have access to your Microsoft 365 environment or file contents, because we do not hold credentials that would authenticate to your tenant." Or, for an application-permissioned vendor: "The attacker would gain whatever access our application permissions grant. Here is our incident detection window, notification SLA, and containment procedure."
Red flags. "We have never been breached" (irrelevant to the question). "We have strong security" (does not answer). A shrug. Being unable to enumerate what would be exposed.
How to verify. Ask for an example incident-response plan or the results of a recent tabletop exercise. Ask for their breach notification SLA in the contract. Ask for a hypothetical walk-through: "if we discovered your systems were compromised on a Friday afternoon, what would we see happen over the following 72 hours?"
Question 4: What data does the vendor hold on their own systems, and for what purpose?
Why it matters. Even a vendor that never touches your file contents may hold significant data about your users, your configuration and your usage patterns. That data is subject to breach, to subpoena, and to your own regulatory obligations around processor management.
What a good answer looks like. A specific enumerated list: sign-in identifiers, configuration policies, aggregate usage metrics, support and telemetry logs. A stated purpose for each item. A stated retention period for each item.
Red flags. Cannot enumerate. Vague answers like "just the data needed to provide the service." Retention "as long as necessary" without a stated period. No answer to the deletion question when the contract ends.
How to verify. Read the vendor's Data Processing Agreement (DPA). It should contain a specific data inventory, retention schedule, and sub-processor list. If it does not, ask for one before signing.
Question 5: Are file contents ever stored, indexed or copied on the vendor's infrastructure?
Why it matters. Distinct from Question 4. Some Microsoft 365 vendors legitimately need to store file contents: backup tools, data-loss-prevention scanners, migration platforms, e-discovery services. Others do not: productivity tools, drive-mappers, front-end integrations, chat and collaboration overlays. If a vendor is storing your file contents on their infrastructure, that changes your regulatory posture significantly, particularly around data residency, breach notification, subject access requests, and deletion obligations.
What a good answer looks like. For tools that do not store: "We do not maintain a copy or index of your file contents. Files are streamed from Microsoft to user devices at request time." For tools that do: "Yes, we store [backup copies / indexed content / preview thumbnails] for [specific purpose]. Data resides in [named region]. Encryption at rest via [named method]. Retention [period]. Deletion process [documented]."
Red flags. Ambiguity. "We cache for performance" without saying for how long, where, and encrypted how. Storing content without a clear operational justification. Storing content in a region you cannot use.
How to verify. DPA again. Also the vendor's SOC 2 Type II report (if they have one) describes data flows in the security section. For UK / EU customers, the DPA should also explicitly state whether personal data is transferred outside the UK / EU and under what mechanism.
Question 6: Does the vendor hold a current independent security certification?
Why it matters. Certifications are not, in themselves, proof of good security. They are proof of an accountable framework. The vendor operates under a documented set of controls, subject to annual external audit, with named staff responsible for the results. That framework is what tends to be missing at the vendors who ship the worst incidents.
What a good answer looks like. A current certificate for at least one recognised standard: ISO/IEC 27001, SOC 2 Type II, ISO 27017 or ISO 27018 for cloud-specific controls, HIPAA / HITRUST for US healthcare, PCI DSS for card data. Named auditor. Current date. Willing to share the certificate (or the SOC 2 report under NDA).
Red flags. "We are working towards it." Expired certificate. Cannot produce it. Only self-attestation. "We follow ISO 27001" without being certified. Certification scope that excludes the product you are buying.
How to verify. Ask for the certificate. Check the auditor's website or the relevant accreditation body register. For SOC 2 reports, read the auditor's opinion and any exceptions section carefully.
Question 7: Where is data processed and stored?
Why it matters. Depending on your regulatory obligations (UK GDPR, EU GDPR, HIPAA, sector-specific data-sovereignty rules), where your data is processed matters legally and operationally. It is also relevant for latency, for your own supplier-management policies, and for international-transfer mechanisms if data leaves your jurisdiction.
What a good answer looks like. Specific regions named for each processing purpose. If EU data stays in EU regions, say so. If the vendor uses sub-processors (analytics, hosting, CDN, email), those are enumerated with regions and with the international transfer mechanism used.
Red flags. "Global" without specifics. Cannot name sub-processors. Uses sub-processors in jurisdictions with weak data-protection frameworks and cannot justify why. No documented sub-processor change notification policy.
How to verify. The DPA lists sub-processors and locations. Ask for the sub-processor change notification policy. If you have specific residency requirements, get them into the contract, not just the security review.
Beyond the seven: nice-to-haves
The seven are the load-bearing questions. Several other things are worth asking, especially in more mature vendor reviews.
- Single sign-on and SAML support. Does the vendor's own admin portal support your existing identity provider, so you are not managing another set of credentials?
- Conditional access compatibility. Can you apply your existing Entra ID Conditional Access policies to the vendor's application, or does the app bypass them?
- Offboarding and data deletion. How is your data deleted when the contract ends? How quickly? What evidence do you receive?
- Contract terms. DPA in place, breach notification SLA, liability caps, right-to-audit clauses, source-code escrow (rarely relevant), termination-for-convenience.
- Financial health. A vendor that fails commercially is a data-recovery and business-continuity problem. Public accounts, funding, ownership, revenue scale.
- Support and escalation model. Who do you call when something breaks. Response time SLAs. Named contacts vs a shared queue.
How to use this checklist
Send it to the vendor before the security review, not during. It gives them time to gather specific answers rather than improvise on a video call. Score answers on specificity, not on confidence. A vendor who can produce a scope list, a DPA, a current certificate and an incident-response plan is a fundamentally different risk profile from one who says "trust us", regardless of which company either of the two is.
Weight the questions to your actual situation. If you are a regulated financial services firm, Questions 6 and 7 (audit and residency) dominate. If you are a smaller business without strong regulatory pressure, Questions 1, 2 and 3 (the permissions and blast-radius questions) are what you actually need to get right. Question 5 (file contents storage) tends to be the surprise item that changes an evaluation late in the process, so raise it early.
Frequently asked questions
Do these questions apply only to Microsoft 365 tools?
The specifics (delegated vs application permissions, Entra ID consent screen) are Microsoft-specific, but the underlying principles apply to any SaaS vendor that will hold or access your organisation's data. Google Workspace, Salesforce and other platforms have equivalent permission models and equivalent consent flows.
What if a vendor cannot or will not answer some of the questions?
That is itself useful information. A vendor that cannot describe how their product authenticates to your tenant, what data they hold, or what happens if they are compromised is either less mature than the products you should be considering, or is choosing not to disclose. Neither is disqualifying by itself, but it should raise the bar for other assurance you get: a longer contract negotiation, more caveats in the DPA, higher liability caps.
Where does Cloud Drive Mapper's own answer to these questions live?
The full answer is in the Zero-access architecture guide and the Security & Trust section, both linked below. In short: Cloud Drive Mapper uses delegated permissions only, holds no vendor-side credentials that authenticate to customer tenants, does not store or index file contents, is ISO/IEC 27001 certified continuously since 2016, and processes data in named UK and EU regions.
What is the difference between ISO 27001 and SOC 2?
ISO 27001 is an international standard for Information Security Management Systems, common in the UK, EU and Asia. SOC 2 is a US audit framework covering security, availability, confidentiality, processing integrity and privacy. Different frameworks with substantial overlap. Neither is inherently stronger; both prove the vendor operates under a formal control framework subject to external audit.
Do we need all of these certifications, or just one?
For most organisations, one current recognised certification (either ISO 27001 or SOC 2 Type II) is sufficient assurance of a vendor's control framework. Sector-specific requirements may add specific obligations on top: HIPAA for US healthcare, PCI DSS for card data, FedRAMP for US federal, and others.
Related resources
Try Cloud Drive Mapper with your own security review
Run the seven questions past us. Your security team can review the admin-consent scopes at the moment they approve the app.