Revoke App Access and Check What Data Remains

To withdraw a connected app’s access, find it in your account’s app list, review what it can reach, and revoke permissions that no longer serve a current need. Google Account and Microsoft work or school accounts have different controls, so check the connection type and who granted consent before acting. Removing access may interrupt a feature you still use.

Revocation stops further access under that permission; it does not establish what the developer retained earlier. Google’s account-data guidance explains that apps can receive permission to view and copy information, and that you may need to ask the developer to delete data already obtained after you revoke access. Keep the access decision and any deletion request as separate entries in your audit.

Build an audit entry for each connection

Review each Google Account you use and the apps presented in your Microsoft work or school account. An app’s familiar name does not show whether its access is still necessary. Open its details and compare the permission with the task that originally required it; if you cannot establish a current need, record that uncertainty.

A short worksheet makes the decision easier to revisit, particularly when someone else depends on the app:

App and account: Record the app name, the account it is connected to, and the type of connection shown.
Permission scope: Note which information or services the app can reach. Distinguish basic profile access from permission to view, copy, or change account data where those details are shown.
Last-known need: Name the task or feature that justified access, who still relies on it, and whether that need remains current.
Consent owner: For a Microsoft work or school app, record whether you granted the permission or an administrator granted it on your behalf.
Decision and follow-up: Record the action taken, any affected feature, and whether the developer may need a separate data-deletion request.

Give particular attention to broad permissions with no identifiable current use. If an app supports a shared workflow, establish who uses that workflow before withdrawing access. The worksheet is a way to make a documented decision, not a reason to treat every older connection as suspicious.

Remove the right Google Account connection

Google’s linked-app instructions direct you to the Linked apps page. For an app allowed to reach Google Account data, select “Access to your Google Account,” choose the app, and open “See details.” Review its access, then select “Remove access” and confirm if the permission is no longer needed. The page also lets you filter apps by the Google product or other account access involved.

Confirm that you are signed in to the Google Account you intend to audit, especially if you use more than one.
Open Linked apps and select “Access to your Google Account.” Choose an app and inspect “See details.”
Compare the access shown with the need recorded in your worksheet. If the need has ended, select “Remove access” and confirm.
Record the decision and check any feature that depended on the connection.

Other entries on the same page represent different relationships. Removing a “Sign in with Google” link stops automatic sign-in to that app but does not delete the data it holds. A “Linked account” entry can instead give Google access to an account at another service; deleting that link can disable features that rely on it. An app may appear under more than one connection type, so identify the specific relationship before removing it.

Check who granted Microsoft work or school consent

In the My Apps portal, Microsoft’s permission instructions say to hover over an app, open its menu, and select “Manage your application.” The upper part of the permissions window shows consent you granted personally; “Revoke Permissions” can withdraw it. A lower part, if present, shows permissions an administrator granted on your behalf, which you cannot revoke yourself.

For your own consent, compare the listed permissions with the app’s current job before selecting the revoke control. Access to a calendar or contacts may be central to a feature, and Microsoft warns that removing permission can break app functionality. Record what changed so a failed workflow has a clear explanation.

If the permission sits in the administrator-granted section, note the app, the permission, and why it no longer appears necessary. Send that information to your work or school administrator for review. The absence of a user-controlled revoke option is a consent boundary, not a completed removal.

Handle information the app already received

After access is removed, the remaining question is what the app obtained while permission was active. A permission screen shows what the app was allowed to reach; it does not provide an inventory of copies held by its developer. That distinction matters most for access that allowed copying, such as photos or contacts, but the details of retention depend on the app.

Look in the app’s account settings and privacy information for data controls. If those do not resolve the issue, contact the developer and identify the app account and the information you want addressed. Ask whether data obtained through the connection remains, whether it can be deleted, and what action is required. A request to remove copied data can be kept distinct from closing the app account if you still use it for another purpose.

For a work or school app involving organization data, include your administrator in that follow-up so the request reflects the organization’s access decision. Record the developer’s response alongside the revoked permission and any feature that stopped working. That leaves the audit with separate outcomes for account access, app functionality, and previously shared information.