Is Dynamics 365 in scope for CMMC?
The question has no product-level answer, because CMMC scope follows the data rather than the license. What it resolves to is narrower and more useful: what is inside the Dataverse environment your Dynamics 365 apps run on.
Every defense contractor running Dynamics 365 asks this eventually, usually a few weeks before an assessment. Most of what a search turns up is about which Microsoft cloud to buy. That question is real, but it is a different question, and it stops where the work starts.
None of what follows requires Pathix.
Scope follows the data, not the product
CMMC assessment scope is defined by where Federal Contract Information and Controlled Unclassified Information live and by what can reach them. It is not defined per product. There is no list of applications that are in scope and applications that are out, which is why “is Dynamics 365 in scope” has no yes or no answer on its own.
The determination is yours to make and your assessor’s to test. What follows is how the platform is put together, so that determination can rest on what your environment contains rather than on an assumption about what a business system typically holds.
A Dynamics 365 environment holding nothing but commercial pipeline data sits somewhere different from one where a contract record carries a program name, a part number and a delivery schedule. The license is identical. The scope question is not.
It is harder to answer than it looks. Business systems accumulate data nobody planned for them to hold, usually in a notes column or an attachment. And a system that holds nothing sensitive itself can still be in scope as a path to something that does, which on this platform means integrations, service accounts and Power Pages.
The tenancy question, and why it is not this page
The first thing most searches surface is GCC High. That question is real: Microsoft publishes which of its clouds carry which authorizations, what DFARS 252.204-7012 requires of a provider, and where the ITAR and data-residency lines fall. If you are choosing between commercial, GCC and GCC High, read Microsoft’s own compliance documentation and talk to a partner who does that work for a living.
Keep it separate from what follows. The two get conflated constantly, and the conflation is expensive in one specific direction.
| The tenancy question | The system question |
|---|---|
| Which Microsoft cloud is authorized to hold this data, and under what contract terms. | Given the environment you have, who can reach what inside it, and on what basis. |
| Answered once, at procurement, and revisited rarely. | Answered continuously, because it changes every time somebody edits a role or ships a plugin. |
| Microsoft and your partner answer it. Documentation and contracts are the evidence. | You answer it. Your environment's own configuration is the evidence. |
The expensive direction is assuming the first settles the second. Landing in an authorized cloud says nothing about whether an integration account in that tenant holds System Administrator, or whether a column somebody deliberately secured is being copied into one that is not. Those are configuration facts, and they are the ones an assessor tests.
Pathix is not a compliance product and this guide is not compliance advice. It cannot tell you what is in your scope, and no tool can: scope is an organizational determination and assessment outcomes rest with your assessor. What follows is a method for describing your environment accurately, which is an input to that determination rather than a substitute for it.
Which system are you actually being asked about
“Dynamics 365” names an application layer. The customer engagement apps, Sales, Customer Service, Field Service and Project Operations, store everything in Dataverse: the tables, the columns, the security roles, the plugins, the flows, the auditing configuration. When an assessor asks a system-level question about your Dynamics 365 deployment, the answer lives in Dataverse whether or not anybody says the word.
The exception matters. Finance and Supply Chain Management, the former AX line, keep their own store and reach Dataverse through dual-write. If your CUI lives in Finance, the Dataverse environment is at most half of your answer, and dual-write itself becomes a path worth looking at rather than an implementation detail.
- The customer engagement apps are one system with two names, so everything below applies to them directly.
- Power Apps and Power Automate on the same environment share that Dataverse, the same security model and frequently the same tables. They belong in the same conversation whether or not anyone bought a Dynamics license for them.
- Finance and Supply Chain Management sit on a separate store. Treat the Dataverse side and the Finance side as two systems joined by a documented integration.
- A Power Pages site on the environment is a public face on the same data. If one exists it belongs in the inventory even if nobody mentioned it, because it is the shortest path from the internet to a table.
Answering the system questions by hand
Assessors do not ask about products. They ask who holds privileged access, whether it is limited to what the role requires, whether changes to sensitive data are recorded, and whether access is removed when somebody leaves. All of that is answerable from configuration you already own.
Start with the principals, not the tables
Most people start by listing tables and looking for sensitive data. Start with who can reach it instead. The surprises are there, and there are fewer of them.
Export the environment’s roles and assignments through the Web API or a data export. Query systemuser for rows where applicationid is not null: those are the integration and service accounts, and they are the population worth reading first. Join through systemuserroles to role and read the role names.
In rough order of how often they turn up:
- An application user holding System Administrator or System Customizer. This is the fastest finding in the exercise and it settles a least-privilege question without argument.
- A role held by both a person and an application user. Group the assignment list by role rather than by user; any role whose holders include both kinds is one. It matters because every privilege added to it lands on both audiences at once, and because the access record can no longer tell a person from a process.
- A role that grants write on the security tables themselves. An account that can edit role definitions has no ceiling: whatever least privilege was configured describes where that account started, not how far it can reach.
Then repeat the exercise for disabled users. Disabling an account revokes sign-in and leaves role assignments, record shares and flow ownership exactly where they were. An offboarding checklist that reads as complete while the sharing table still names the person who left is a common finding, and an entirely visible one.
Then the protections you have already configured
Read the column security profiles in the admin center and list the secured columns. For each, check that at least one profile grants somebody read access. A column secured with no profile granting it is invisible to everyone including the people who need it, and that usually means somebody has quietly worked around it.
Check auditing separately, per column rather than per environment. Auditing enabled at the organization level does not mean a given column is audited, and a column you have classified as sensitive but excluded from auditing produces no record at all. That is the one thing you cannot reconstruct after the fact.
Then the paths in and out
Inventory the connection references, custom connectors, service endpoints and webhooks on the environment, and read the destination on each. You are looking for destinations on plain http rather than https, and for endpoints with no authentication configured. Both are visible in the registration.
If a Power Pages site exists, read its table permissions and the web roles attached to them, and find which role the site treats as its anonymous users role. A table permission granting read to that role, on a table holding anything you would not publish, is the finding. Read the site settings for the site’s Web API as well: it can serve a table that the site’s own pages never render.
On the enhanced Power Pages data model, the advertised role relationship on a table permission accepts a write and then reads back empty, permanently. Checking it the obvious way will tell you no role is attached when one is. Read the roles from the Portal Management app’s own Table Permission form instead.
Where the manual method runs out
Everything above is real work that produces real evidence, and for a small environment it is the right approach. What defeats it is worth knowing before you commit a week to it.
- Plugin assemblies are compiled. Nothing in any admin surface tells you which columns a plugin writes, whether it calls an external endpoint, or whether it swallows its own exceptions. You can decompile them, and that is a legitimate thing to do to code running in your own tenant, but it is a per-assembly exercise rather than an inventory.
- What a principal can reach is not a list of roles. It resolves through roles held directly and through teams, privilege scope, the business-unit hierarchy, the manager chain and column security profiles, all at once. Every one of those is readable on its own. Combining them correctly, for every principal, is the part that does not scale.
- The answer is true on the day you produce it. A privilege scope widened from Local to Global, a role added to a business unit’s default team, a new plugin step: none of them announce themselves, and what you documented in March is not what is true in June.
Where Pathix comes in
Pathix does that work from a read-only scan inside your own tenant. It reads compiled plugin IL, workflow definitions and flow JSON to resolve what each component writes and reads at the column level, resolves effective permissions through the whole chain rather than listing role names, and diffs each scan against the last so a change nobody announced shows up as a change.
For CMMC specifically, the findings it produces carry the practices they produce evidence for. Those mappings are indicative: Pathix detects a condition relevant to a control, and what that is worth in an assessment is your assessor’s call rather than ours. It is self-hosted in your own Azure subscription and metadata-only, which for an environment in assessment scope tends to be the first question asked about it rather than the last.
The practice-by-practice crosswalk, including what it deliberately does not claim, is on the CMMC readiness page. If your concern is the Power Pages site specifically, the Power Pages exposure page covers what a site’s configuration grants to visitors who never sign in, and is honest about the one layer a scan cannot read.