Securing a Power App That Was Never Meant to Hold Sensitive Data

If a Power App you built now holds sensitive data and more people can see it than intended, contain first. Record the current sharing and preserve access logs as evidence, then remove broad sharing on the app and revoke "anyone with the link" and organisation-wide links on the SharePoint list, Excel file or storage behind it. Then accept the real security model: sharing an app only controls who can run it, permissions on the data source control who can see the data, and filters inside the app hide rows without protecting them. The fix is moving the data to Dataverse with table, row and column security, or locking the existing source down correctly, verified as a real user.

This post is for the person who built a useful app in a hurry, often on a SharePoint list or a spreadsheet, and has just realised it now holds salaries, absence reasons, disciplinary notes or personal details. It is not legal advice. Whether and how the exposure must be reported is a question for your data protection officer or legal adviser, and they should be involved from the first hour.

What should you do in the first hour after finding the exposure?

Stop the exposure growing without destroying the record of what happened. Write down, with times, what you noticed, who reported it and what they could see, and take screenshots. Then work through containment in this order.

1. Record the current sharing before you remove it. Screenshot the app sharing panel in Power Apps, and the Manage access panel on the SharePoint list, library, site or OneDrive file behind it, including every sharing link and who it was created for.
2. Revoke "anyone with the link" sharing links on the data source first, because they work without signing in and can be forwarded outside the organisation. Then remove "people in your organization" links and direct shares to groups that are wider than intended, such as everyone except external users.
3. Narrow sharing on the app itself: remove it from Everyone and large security groups, keep only the people who genuinely need it, and review who is a co-owner.
4. Check for copies. Exports to Excel, flows that email or copy the data, and other apps or reports using the same list or file all need the same review.
5. Tell your IT or security team and your data protection officer now, not after the fix, so evidence is preserved properly and nobody is surprised later.
6. Verify containment by opening the list or file link in a private browser window while signed out, and signed in as a colleague who should no longer have access.

If you cannot work out quickly where the data is exposed, restrict the whole SharePoint site or file to its owners until you can. A few hours of disruption to the people using the app is a smaller problem than continued exposure.

What access logs exist and how do you preserve them?

Preserve before you investigate, because retention is limited and some records only exist if a setting was already switched on. What is available depends on your Microsoft 365 licensing and tenant configuration, so confirm the details with your administrator and current Microsoft documentation rather than assuming.

• Microsoft Purview audit: where auditing is enabled for the tenant, the audit log search can return SharePoint and OneDrive activity such as files and list items being accessed, sharing links being created or used, and sharing changes, as well as Power Apps activity such as app launches. A Purview or Microsoft 365 administrator can run the search and export the results.
• SharePoint site usage and sharing reports: site owners can see usage information and, where available, run a report of sharing links on the site. Save the output alongside the screenshots.
• Power Platform admin center analytics: reports on app usage, such as which users launched an app and when, can help identify who used it, subject to what your tenant has available.
• Dataverse auditing, if the data was already in Dataverse: it records creates, updates and deletes when auditing was enabled for the environment and table, but reads are not recorded by the standard audit history. Read activity logging for Dataverse depends on separate configuration.

Export what you find to a secure location with restricted access, record who ran each search and when, and do not delete sharing links or the app until the export is done. Be clear about the limits too: logs may show that someone opened a file or launched an app without showing exactly which rows they saw.

Why does sharing a Power App not protect the data behind it?

Because a canvas app is a front end, not a lock. Sharing the app gives someone permission to run it. The app then connects to the data source as that user, through connectors such as SharePoint, Excel Online or OneDrive, so the user needs their own permission on the list or file for the app to work. That same permission lets them open the list in SharePoint, open the file in Excel, or connect to it from another app, report or flow, entirely outside your app.

This is why three common approaches do not secure anything:

• Filtering a gallery so each person sees only their own rows. The filter decides what the screen shows, not what the user may read, and the full list is still available to them at its source.
• Hiding screens or buttons for certain users. Anyone with access to the data can reach it without that screen.
• Removing someone from the app while leaving their access to the list or file. They can no longer run the app, but they can still read the data.

There are two further traps. Data in an Excel file stored in OneDrive or SharePoint is only as private as the file's sharing, and a file shared with a link for convenience can end up far wider than the app. And some connections, such as a SQL Server connection using SQL authentication, are shared implicitly with everyone the app is shared with, so every app user effectively works with the maker's database credentials. Check the connections your app uses in the Power Apps maker portal.

How do you secure the data properly after containment?

Pick one of two routes, depending on whether different users should see different rows.

If everyone who uses the app should see all of the data, locking down the existing source can be enough. Move the list or file to a SharePoint site that only the right group can access, stop inheriting permissions from a wider site, grant access through one security group rather than to individuals, disable anonymous sharing for that site if your tenant allows it, and apply sensitivity labels where your organisation uses them. The app keeps working for the group and no longer works for anyone else.

If users should see only some rows, such as employees seeing their own records, managers seeing their team and HR seeing everyone, a SharePoint list or spreadsheet is the wrong home. Item-level permissions on a list are hard to maintain and easy to break, and the connector still gives each user direct access to whatever they are allowed to read. Move the data to Dataverse, where access is enforced by the platform on every route:

• Security roles decide which tables a user can read, create, update or delete, and at what depth: their own records, their team or business unit, or the whole organisation.
• Record ownership, teams and business units provide the row-level boundaries, so a gallery filter becomes a convenience rather than the control. Our guide to Dynamics 365 security with business units and teams explains how to design that model, and it applies equally to Dataverse behind a Power App.
• Column security profiles protect individual columns, such as salary or health information, even from users who can see the rest of the record.
• Auditing can be enabled on the tables and columns that matter so future changes are recorded.

Moving to Dataverse changes licensing for canvas apps, because Dataverse is a premium capability, so check current Microsoft licensing for your users before committing. Our guide to moving a legacy app to Power Apps and Dataverse in a regulated setting covers the migration itself. If the exposed app is an external portal built on Power Pages rather than an internal canvas app, the model is different, and our guide to fixing a Power Pages table permissions data leak covers it.

How do you verify the fix as a real user?

Never test as the maker or an administrator, because your own permissions make everything look correct. Create or borrow test accounts that match each real role and check every path to the data, not just the app.

1. Sign in as a user who should see nothing and confirm the app fails to load the data, the SharePoint list or file cannot be opened by direct link, and the site does not appear in their search results.
2. Sign in as a user who should see only their own rows and confirm the app shows only those, then try to reach other rows another way, such as a new canvas app or an Excel connection to the same source.
3. Sign in as a manager and as an HR user and confirm each sees exactly their scope.
4. Open every previously issued sharing link in a private window while signed out and confirm it no longer works.
5. Check that flows, exports and reports built on the data respect the new permissions, or are removed.
6. Write down each test, the account used, the result and the date, and keep it with the incident record.

What should you tell people, and who decides about disclosure?

Keep the facts and the decisions separate. Your job is to establish the facts accurately: what data was exposed, from when to when, to which group of people, whether anonymous links were used, and what the logs can and cannot show. Hand those facts to your data protection officer, legal adviser and HR leadership, and let them decide whether the exposure must be reported to a regulator or the people affected, and on what timescale. Those obligations vary by jurisdiction and by the kind of data involved, and they are outside what a technical partner should advise on. For the wider data protection controls in a Dynamics 365 or Dataverse estate, such as retention and subject access requests, see our guide to GDPR retention, erasure and DSARs in Dynamics 365.

How do you stop the next app from doing the same thing?

Treat this as a governance gap rather than one person's mistake, because citizen-built apps holding sensitive data are common wherever Power Apps is available without guardrails. Useful controls include data loss prevention policies that restrict which connectors can be combined, a separate environment with tighter rules for apps handling personal data, Managed Environments sharing limits that stop apps being shared with whole security groups or too many people, tenant settings that restrict anonymous sharing on SharePoint and OneDrive, and an inventory of apps and their data sources that someone actually reviews. Check current Microsoft documentation for the exact settings, because they change between releases.

If you want an independent view of how far the problem extends, our Dynamics 365 health check and technical audit covers security posture and Power Platform governance, including sharing, DLP coverage and app sprawl. If you need the app rebuilt properly on Dataverse, with a security model designed around who should see what, our Power Platform developers do that work, remotely from Yerevan, Armenia, directly or on a white-label basis for Microsoft partners. Where Microsoft licensing is the reason sensitive data ended up in a spreadsheet in the first place, a custom CRM or business application with its own access control is the alternative worth comparing.