Which Microsoft 365 Apps Can Access Your Advisory Firm’s Data?

A financial advisory firm can remove a former employee’s account and still have third-party applications authorized to access business data. CRM synchronization, meeting tools, document services and old software trials may have connections that deserve their own review.

Before buying another security product, ask your IT provider for a clear answer: which applications have access, what can each one do, and why does the firm still need it? For advisory firms in Frederick, Maryland, a documented Microsoft 365 application review is a useful project to include in an MSP proposal or recurring technology review.

1. Separate employee access from application access

Microsoft distinguishes between delegated permissions, where an application acts on behalf of a user, and application permissions, where software acts as its own identity without a signed-in user. Background services such as backup tools can legitimately need the latter. That distinction matters because a review limited to employee accounts misses a different form of access. See Microsoft’s permissions and consent overview.

Ask your provider to explain each permission in business language. “Reads calendars for scheduling” is more useful to an operations manager than an unexplained permission name. Also ask whether the access is limited to the intended people or resources, or reaches more broadly across the organization.

2. Request an inventory you can actually review

A useful deliverable should identify each relevant enterprise application and its business purpose. Request these fields:

• Application name and unique identifier, publisher and responsible vendor.
• Named business owner and the workflow it supports.
• Delegated and application permissions, including access to mail, files or directory information.
• Who authorized the connection, where the available records show that information.
• Available usage evidence, its source and the dates covered.
• Recommendation: retain, reduce permissions, investigate or retire.

Microsoft provides tools to review and revoke enterprise-application permissions. The firm should receive the findings in an understandable register, not just screenshots or a tenant-wide export with no interpretation.

Keep the scope clear. This inventory describes connections visible in the reviewed Microsoft environment. It is not proof that every SaaS subscription, browser extension, vendor-side integration or independently authenticated system has been discovered.

3. Treat “last used” as evidence, not a verdict

An application without recent activity is a candidate for investigation, not automatically safe to delete. Quarterly reporting, periodic exports and recovery tools may be quiet between scheduled uses. Conversely, a recent sign-in does not establish that an application is necessary or appropriately permissioned.

Ask which activity types the provider checked. Microsoft Entra sign-in logs distinguish interactive user sign-ins, non-interactive user sign-ins, service-principal sign-ins and managed-identity sign-ins. Looking only at employee logins can miss background activity.

The observation window matters too. Microsoft currently lists default Entra audit and sign-in retention of seven days for Free and 30 days for P1/P2. Longer history depends on the relevant logging and retention arrangements. An upgrade does not restore expired history. These logs are also separate from Microsoft 365’s Unified Audit Log. Check the firm’s actual configuration against Microsoft’s retention documentation.

A defensible finding says “no activity observed in these logs during this period,” then checks the business owner, vendor records and scheduled dependencies. It should not say “never used” when the evidence cannot support that conclusion.

4. Prioritize permissions and ownership, not just age

Start with connections that have powerful access and an unclear purpose. Examples worth investigating include an abandoned trial with broad file access, an application with no current owner, or a connector retained after its replacement went live. These are review scenarios, not claims about any particular vendor.

Have the provider explain whether the permission set fits the documented function. Ask what narrower supported configuration is available and what would stop working if permissions changed. Avoid assuming that a familiar brand, verified publisher or recent use is sufficient approval for every requested permission.

For suspected compromise, use the firm’s incident-response procedure rather than waiting for routine cleanup. Preserve relevant evidence and coordinate containment with the authorized security and compliance contacts.

5. Retire access through a controlled change

For ordinary cleanup, require approval from the business owner before changing a connection. Record its current configuration, dependencies, the proposed technical action, a test plan and a recovery plan. Removing a permission grant, disabling access and deleting an application object are different changes; the provider should select the appropriate one.

Test the affected workflow with authorized users. Confirm that essential synchronization, backup, reporting and client-service functions still work. Track failures and vendor follow-up rather than treating the absence of a help-desk complaint as sufficient evidence.

Removing a Microsoft permission does not, by itself, prove that a vendor deleted information previously received. Review the separate vendor account, data-return and retention arrangements where applicable. Preserve records required by the firm’s approved policies before retiring services.

6. Make the review a useful MSP deliverable

When comparing proposals, ask providers to show an anonymized example of the final register and explain:

• Which environments and application types are included?
• What history is available, and what will remain unknown?
• Who translates permissions into business risks and obtains owner decisions?
• Who performs approved changes and verifies the affected workflows?
• How are new integrations and permission changes reviewed afterward?

Agree on scope, access, any licensing costs and follow-up responsibilities before the work begins. The useful outcome is a smaller set of justified connections, clearly recorded exceptions and a repeatable approval process.

Keep regulatory conclusions separate

This is an operational security checklist, not a compliance certification. The SEC’s amended Regulation S-P applies to specified covered institutions, including SEC-registered investment advisers; that does not mean every financial advisory business has identical obligations. The SEC’s small entity compliance guide explains its scope. Have the firm’s compliance team and counsel determine applicable requirements and retention decisions. This article does not claim that a particular review interval or product is legally required.