Power Platform Security

This is a question every organization using cloud services, business applications, and automation should ask. In Poland, an amendment to the National Cybersecurity System Act implementing the requirements of NIS2 has been in force since April 3, 2026. The EU Artificial Intelligence Act (AI Act) has also applied broadly since August 2, 2026, with certain obligations subject to exceptions and transitional periods. Although these regulations address different areas, they share a common direction: greater organizational responsibility for how technology, data access, and risk are managed.

Microsoft Power Platform provides a broad set of security mechanisms, but their availability alone does not mean that every application or automation is secure. The actual level of protection also depends on solution architecture, the permissions model, access policies, the way connectors are used, and governance across the entire environment.

In this article, we explain what Microsoft is responsible for, what remains the responsibility of the organization using Power Platform, and which mechanisms help protect data across Power Apps, Power Automate, Dataverse, and other components of the Microsoft ecosystem.

The foundation is the Shared Responsibility Model. The division of responsibilities between Microsoft and the customer depends on the service model, but some responsibilities remain with the organization regardless of whether it uses SaaS, PaaS, or other cloud services.

Microsoft is responsible, among other things, for physical data centers, the physical network, hosts, and provider-managed platform components. The organization remains responsible for its own data, user accounts and identities, service configuration, access management, and endpoint protection.

In practice, this means Microsoft can provide tools for managing roles, data policies, authentication, and auditing, but the organization must decide how those controls are configured and enforced.

A secure provider infrastructure does not automatically make an application secure if users are granted overly broad permissions, business data is connected to inappropriate services, environments are not governed by appropriate policies, or administrators do not control how connectors are used.

Similarly, working with an implementation partner does not transfer all security responsibility to the provider. A technology partner may be responsible for designing the architecture correctly, configuring the solution, and implementing the agreed security controls. The organization still remains responsible for its data, users, processes, and internal security policies.

That is why security should be designed into the solution from the beginning of the implementation, rather than added only after the application has been deployed.

One of the foundations of Microsoft’s security approach is Zero Trust. It is not a single feature or product, but a security model built around three principles: explicitly verifying every access request, granting the minimum required permissions, and assuming that a security breach may already exist within the environment.

In practice, this means that access decisions should not be based solely on whether a user knows their password or is connected to the corporate network. Factors such as identity, device, location, sign-in risk, and access context may also be taken into account.

This approach is supported by technologies such as Microsoft Entra ID, MFA (Multi-Factor Authentication), and Conditional Access. These tools allow organizations to require additional verification or restrict access depending on sign-in conditions.

In Power Platform projects, a common question is whether application data should be stored in SharePoint or Microsoft Dataverse. Both solutions can be used securely, but they provide different levels of control and are designed for different scenarios.

Within the Microsoft ecosystem, this is supported by mechanisms such as security groups in Microsoft Entra ID, Security Roles in Dataverse, administrative roles, and Conditional Access policies. Each of these mechanisms operates at a different level, so simply placing a user in the appropriate group does not replace a properly designed permissions model for applications and data.

This is particularly important for employee, customer, and contractor data, as well as other information protected under the General Data Protection Regulation (GDPR). Security should not be based on the assumption that an employee will intentionally avoid doing anything inappropriate. Risks also include account compromise, phishing, misconfiguration, and accidental data sharing.

Even a properly designed environment requires ongoing oversight after deployment. Over time, new applications, flows, connectors, and users are introduced, while a configuration that was appropriate at the time of implementation may no longer reflect the organization’s current needs.

That is why auditing and periodic access reviews are an important part of governance. Dataverse allows organizations to audit data changes and record selected user activities. Power Platform administrators also have access to mechanisms that help them analyze environments and how the platform is being used.

Microsoft provides a central source of information about the security, privacy, compliance, and transparency of its services – Microsoft Trust Center.
It includes materials covering services such as Azure, Microsoft 365, Dynamics 365, and Power Platform.

This resource is particularly useful for administrators, architects, security teams, and legal and compliance departments that need to verify information about data protection practices, certifications, or the compliance status of specific services.

The organization remains responsible for decisions such as information classification, permission assignment, environment segmentation, connector usage, user account management, application lifecycle management, and responding to changes and incidents.

That is why security architecture should be designed alongside the application architecture. If roles, data policies, governance, and data storage are considered only after the solution has already been deployed, bringing the environment under control will be significantly more difficult.