Giving External Auditors Read-Only Access to Dynamics 365 Data

Which routes can give external auditors read-only access, and how do they compare?

Four routes cover almost every audit request. The usual mistakes are assuming guest access costs nothing because the auditors only read, and building a custom API under deadline pressure that nobody maintains after the audit. Compare the routes on the four things that matter when the audit is time boxed and the auditors belong to another organisation.

None of the routes below is free. Each one moves the cost somewhere: user licences, portal capacity, reporting licences or capacity, or the storage, labelling and identity governance features that make an export safe. Licensing terms change, so confirm the implication for your scenario against the current Microsoft licensing guide and with your licensing partner before you commit to a route.

How do guest users with scoped read-only security roles work, and what licence do they need?

Invite each auditor as a Microsoft Entra B2B guest, so they sign in with their own organisation's account and you never manage their passwords. Put the guests in a Microsoft Entra security group, link that group to a Dataverse group team, and assign a purpose-built read-only security role to the team. When a guest first signs in, a user record is created in Dataverse.

Being a guest does not remove the licensing requirement. A guest who opens a model-driven or Dynamics 365 app needs a licence that covers that app, and which tenant that licence may come from is set out in current Microsoft documentation. The Team Members licence is tempting for read-only access, but its use rights are limited to specific scenarios and apps in the Dynamics 365 licensing guide, so check the current guide before assuming it covers an audit team. The guide also describes rights for external users, but they depend on how the access happens, so get a written answer from your licensing partner for your exact scenario.

• Build the role from nothing rather than copying an existing one: Read only, on the tables in scope only, with no Create, Write, Delete, Append, Assign or Share privileges.
• Remove Export to Excel and bulk privileges from the role, but remember that anyone with read access and API access can still retrieve what they can read. How export privileges fit the wider model is covered in our guide to the Dynamics 365 security model.
• Secure sensitive columns such as personal or bank details with column security, and do not add the auditor team to the profile unless the audit needs those values.
• Give the guests a dedicated app module with only the tables and views they need, so the experience matches the role.
• Know the limit: Dataverse security decides which rows a user can read by ownership, business unit, team and sharing, not by date. There is no built-in way to say "only records from the audited financial year", which is often the reason an export pack wins.

When is a controlled export pack the better answer?

When the audit is about a defined period, when there are many auditors, or when the auditors mainly need to sample and test rather than browse. An export pack answers the scope question precisely, because the query defines exactly which rows and columns leave, and it avoids licensing each auditor for Dynamics 365. The trade off is that it is a snapshot, and once data leaves Dataverse the controls move to the file and the location.

For small and medium extracts, FetchXML or Web API queries run by an internal user or a Power Automate flow produce Excel or CSV files. For large or repeated extracts, Azure Synapse Link for Dataverse or Microsoft Fabric link can land tables in storage for a governed query. Both carry their own Azure or Fabric consumption, and very large one-off volumes follow the patterns in the Dataverse bulk import strategy in reverse: batch, page and reconcile.

• Define the extract in writing with the auditors: tables, columns, filter (for example the audited period and business unit) and the as-at date and time.
• Produce a manifest: file names, row counts per file, control totals such as sums of amounts, and a hash of each file, so both sides can prove the pack is complete and unaltered.
• Deliver into a dedicated SharePoint site or library shared with the guest group only, or an Azure Blob container accessed through short-lived shared access signatures issued under a stored access policy so they can be revoked early.
• Apply a Microsoft Purview sensitivity label with encryption to the files, so access is checked when a file is opened, even after it has been downloaded. Label features depend on your Microsoft 365 licensing.
• Set an expiry on sharing links and guest access, and agree how long the auditors may retain their working copies under their own obligations.

Can a read-only Power Pages site serve a large group of auditors?

Yes, and it is the route that scales best to a large and changing auditor group that needs live data, but it has the highest setup effort and the least forgiving failure mode. Authenticated site users consume Power Pages capacity, which is paid, so check the current Power Pages licensing model for how authenticated users are counted before sizing it.

The safest design does not expose the live tables at all. Populate a dedicated audit extract table with exactly the in-scope rows, and grant an Auditor web role Read only on that table, with no Create, Write, Delete, Append or Append To. Keep lists and forms read-only, and leave the Web API off for that table unless it is needed. Filters on a list are presentation, not security: the table permission is what decides which rows the site will return. Sign auditors in through Microsoft Entra ID so their own organisation's account is used.

Table permission mistakes expose every row to every signed-in auditor. Before go live, test as a real auditor account, not as an administrator, using the method in our guide to Power Pages table permissions and data leaks. What a Power Pages build covers is on our Power Platform consulting page.

Should auditors get a Power BI report instead of the underlying data?

Often, when the audit questions are analytical: totals by period, exceptions, approvals outside policy, or changes by user. A report can answer those without exposing every column of every row, and row-level security can restrict what each auditor sees.

Licensing applies here too. Guests viewing shared content need a Power BI licence, unless the content is in a capacity that allows viewers without a per-user licence, and that capacity is itself paid. Check the current Power BI and Microsoft Fabric licensing documentation for your tenant.

• Share a Power BI app or specific reports with the guest group rather than adding guests to the workspace, and do not grant Build permission on the semantic model.
• Apply row-level security for the audited business units or entities, and test it with the view as role option before sharing.
• Review the tenant export settings for guests, including export to Excel, CSV and Analyze in Excel, and restrict them if the audit does not need raw data.
• Apply sensitivity labels to the report and semantic model, so any permitted export inherits protection.
• If the auditors need a published dataset rather than a report, treat it like an export pack: defined scope, manifest and expiry.

How do you restrict auditors to exactly the records in scope?

Scope is the part auditors test first and admins get wrong most, because the tools that decide row access in Dataverse were designed for staff, not for a time-boxed third party. Decide scope in writing with the auditors before choosing a mechanism, then pick the mechanism that can express it. If you are not sure the current security model is clean enough to build on, an independent Dynamics 365 health check and technical audit reviews security posture and licensing alongside the rest of the environment.

How do you prevent auditors sharing the data onward?

You cannot make onward sharing impossible once a person can read data, but you can make it hard, traceable and contractually covered. Agree the handling terms in the engagement letter or a data handling annex first: permitted use, where working copies may be stored, retention and deletion. Then back the terms with controls.

• Encrypting sensitivity labels on export files and Power BI content, so a forwarded file does not open for someone outside the permitted group.
• Guest-only sharing on the SharePoint site with anonymous links disabled, and sharing restricted so guests cannot reshare.
• No Build permission and restricted export in Power BI; no Web API and no export in Power Pages lists.
• Data loss prevention policies in Microsoft Purview where your licensing includes them, to flag labelled content leaving through email or cloud uploads.
• Watermarking or a clear classification header in exported files, so their origin and handling rule are obvious.

How do you log who accessed what during the audit?

Decide what you will need to prove before access starts, because logging switched on afterwards does not recover the past. Standard Dataverse auditing records changes, not reads. Read activity can be captured through Microsoft Purview activity logging where your licensing and configuration support it. What each source records, and how to export audit history for long-term retention, is covered in our guide to Dynamics 365 audit trails for compliance.

How do you revoke auditor access cleanly when the audit ends?

Set the end date before the start date. Access that relies on someone remembering to remove it is still there at the next audit. Put every grant on a register with an owner and an expiry, and make the end of the audit a checklist rather than a clean-up project.

• Grant guest access through Microsoft Entra entitlement management access packages with an expiry, or run an access review on the guest group at the end date. Check which Microsoft Entra ID Governance licensing these features need.
• Remove the guests from the group, which removes their access through the Dataverse group team, then disable or delete the guest accounts. The Dataverse user records remain disabled, with their history intact.
• Remove any access team membership and direct shares created for sampled records.
• Expire SharePoint sharing links, remove the site access and delete the export pack after the agreed retention; revoke the stored access policy behind any Blob shared access signatures.
• Remove the Auditor web role and deactivate auditor contacts in Power Pages, or turn the audit site off.
• Remove Power BI app or report access and delete any audit-only workspace.
• Confirm from the logs that no access occurred after the end date, and keep the register, the manifest and the revocation evidence with the audit file.

Should auditor access requirements influence your CRM platform choice?

Rarely on their own, but repeated audits of the same data are a signal worth reading. If you face the same auditor request every year, a permanent read-only audit extract and a standard revocation checklist on Dynamics 365 and Power Platform are usually the right investment, and the licensing cost of the route you choose becomes a known line rather than a surprise.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where the licensing model itself is the obstacle, for example a large and changing population of external reviewers who need live access, a custom-built CRM on React, Node.js, PostgreSQL or .NET lets you design external access and its logging without per-user licences, with the cost moving to hosting, build and support instead. For many external systems rather than people, the governed pattern is in our guide to an API gateway for external consumers.

How does Solzet help give external auditors access to Dynamics 365 data?

We start from the audit request: what the auditors need to test, for which period and entities, how many people, and by when. From that we recommend the route and its licensing implication in writing, then build it: the read-only role and group team, the reconciled export pack with its manifest and secured location, the audit extract site in Power Pages or the Power BI app, together with logging and a revocation checklist that runs on a date. The work is contained and finishes when access is removed and evidenced.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. If the audit has exposed wider doubts about the environment, our health check and technical audit is the place to start, and Power Pages and Power Automate builds sit with our Power Platform consulting service.