Project Online Security and Compliance: Onplana Compared

Project Online security reviews often begin and end with a logo wall. "Runs in Microsoft 365" appears on PMO evaluation scorecards as if it settles the question. What it actually means is that Microsoft secures the infrastructure layer. That is true and worth something. It is not a complete picture of what controls your IT team can configure, what your compliance team can audit, and what your data team can govern at the platform level.

The distinction matters more than it used to. PMOs in regulated industries, defense supply chains, healthcare, and financial services are discovering that "inherits Microsoft's certifications" answers a different set of questions than "your IT team can configure SSO from any identity provider, pull a structured audit log by API, and decide where the data lives." Both questions matter. The second is rarely covered in vendor procurement comparisons.

TL;DR. Project Online runs on Microsoft's cloud and inherits Microsoft's compliance certifications, covering most enterprise security requirements for teams already fully in the Microsoft 365 ecosystem. Onplana provides the same infrastructure-layer security plus additional operational controls: native SSO for any identity provider, field-level audit logs accessible by API, customer-managed encryption keys, and self-hosted deployment on AWS, Azure, GCP, or private infrastructure. The gap matters for regulated industries, data-residency-constrained organizations, and teams moving off an Azure-only deployment model.

What Project Online Security Actually Covers

Microsoft 365's compliance posture is strong. The platform holds ISO 27001, ISO 27018, SOC 1 and SOC 2 Type II, FedRAMP Moderate, and dozens of other certifications. If your board or auditor asks "are you on a SOC 2 certified platform?", Project Online's answer is yes. That is not in question.

The operational question is different: what security controls can your team actually manage? Microsoft's certifications cover what Microsoft does to secure the infrastructure. They do not cover whether your IT team can configure SSO to your preferred identity provider without routing through Azure Active Directory. They do not determine whether your compliance team can export a structured log of who changed which task in which project at what timestamp. They do not govern whether your data team can enforce a customer-managed encryption key that Microsoft never sees.

Compliance-heavy PMOs discover these controls matter when they start comparing tools in detail. The infrastructure certification is table stakes. The operational control surface is the differentiator.

Identity Management and SSO: More Configuration Than It Looks

Project Online's identity model is built on Microsoft Entra ID (formerly Azure Active Directory). If your organization uses Entra ID as its primary identity provider, SSO integration is native and relatively seamless. Sign in once, access Project Online through the M365 app launcher, and user provisioning flows through the Microsoft 365 admin center.

The complexity arrives when your IdP is not Entra ID. Organizations running Okta, Ping Identity, Auth0, AWS IAM Identity Center, or any other enterprise IdP face a federation requirement: configure your IdP to federate with Entra ID, which then authenticates into Project Online. It is solvable, but it adds configuration work and a dependency. If the federation layer has a certificate expiry, a policy change, or a misconfiguration, access to Project Online breaks even when the primary IdP is healthy.

Onplana supports SAML 2.0 and OIDC natively, without requiring an intermediate Azure AD layer. An organization running Okta configures Onplana directly in Okta without a federation dependency. The same applies to Auth0, Ping Identity, Google Workspace as an IdP, or any other standards-compliant identity provider. SCIM 2.0 provisioning is available through the same direct connection, so user lifecycle events (create, update, deactivate) propagate from the IdP without additional connectors.

For organizations that have deliberately moved identity management outside the Microsoft stack, this difference is material. The federation workaround functions; the direct connection is simpler to operate and audit.

Audit Logs and Compliance Trail

Project Online audit logging flows through Microsoft 365's Unified Audit Log, accessible via Microsoft Purview. This covers a meaningful set of events: user sign-ins, SharePoint document access, administrative configuration changes, and some project-level events. For an auditor asking "did anyone access this system without authorization?" or "when was this configuration changed?", the Unified Audit Log provides relevant evidence.

The gap appears at the field-change level. If your audit requirement is "show me every change to any task in this project, what field was changed, from what value to what value, by which user, at which timestamp," the Unified Audit Log does not provide that granularity natively. The full reference for what Microsoft Purview's audit log captures across Microsoft 365 services is documented at Microsoft Learn's audit log activities page. Reviewing that documentation against your specific audit requirements is the most direct way to assess whether Project Online's logging meets your compliance scope.

Onplana's audit log tracks field-level changes across projects, tasks, resources, and custom fields. The log is accessible via API, which means compliance teams can export it directly into their SIEM, SOAR, or audit tooling without manual steps. The export format is structured JSON, designed for programmatic consumption rather than manual review. For PMOs in regulated industries where demonstrating field-level change control is a compliance requirement, the difference between "administrative-level audit" and "field-level audit" is often the deciding factor.

The diagram below maps the security control layers in each tool and how much configurability each layer exposes to the customer.

Deployment Model as a Security Control

Project Online runs on Microsoft Azure. Your data, your project structures, your custom fields, and your resource information live in Microsoft-managed infrastructure in the Azure region your Microsoft 365 tenant is homed to. That region is specified at tenant creation; changing it later is a significant migration. There is no option to run Project Online on AWS, GCP, or private infrastructure.

This is a security variable for two categories of organizations. The first is data-residency-constrained organizations: PMOs in the European Union subject to GDPR data-residency obligations, government entities with sovereign cloud requirements, and regulated industries where contract clauses restrict data to specific jurisdictions. Azure has regions in most major geographies, so residency within a country is usually achievable. Residency outside Microsoft's cloud entirely is not.

The second category is organizations that have made a deliberate architectural decision to move computing infrastructure away from Microsoft. This is not common but it exists: technology companies that have migrated to AWS as their cloud-of-record, defense contractors operating on private infrastructure for specific programs, financial services firms with multi-cloud policies that prevent vendor concentration. For these organizations, a PMO tool that requires Azure residency creates a compliance exception to their own architecture policy.

Onplana's deployment model is cloud-agnostic. The SaaS tier runs on Onplana-managed infrastructure. The self-hosted option deploys on AWS (VPC, RDS, ECS or EKS), Azure (App Service or AKS, Azure SQL, Key Vault), GCP (GKE, Cloud SQL), or any Kubernetes-compatible private infrastructure. The feature set is identical across deployment modes. Data does not move to Onplana-managed infrastructure in self-hosted deployments.

For a complete treatment of Onplana's security architecture and compliance certifications, the security and compliance overview covers encryption models, audit trail design, and the self-hosted architecture in detail.

Customer-Managed Encryption and Key Management

Project Online uses Microsoft-managed encryption keys for data at rest. Data stored in SharePoint and Azure databases backing Project Online is encrypted with keys that Microsoft manages, rotates, and controls. The "Microsoft manages this" framing means your organization never risks losing access to your own data by mishandling a key. It also means your organization cannot enforce a policy like "if our key is revoked, the data is permanently inaccessible to any party."

Customer-managed keys (CMK or BYOK) are a security control that regulated industries sometimes require. The logic: if a subpoena, regulatory seizure, or data breach compromises the platform provider, revocable CMK-encrypted data cannot be read by the platform or by an attacker with access to the platform's infrastructure. The control gives the data controller (your organization) the authority to make data inaccessible, not just the platform.

Microsoft 365 does offer a feature called Customer Key, which lets enterprise M365 customers supply encryption keys for Exchange, SharePoint, and Teams data. Project Online data stored in SharePoint may be covered by this, but it is part of Microsoft 365's premium compliance tier and applies to the SharePoint content layer, not to the Project Server data model directly.

Onplana's Enterprise tier supports customer-managed encryption keys through AWS KMS, Azure Key Vault, and GCP Cloud KMS. The key configuration is part of the Onplana Enterprise onboarding. Onplana does not retain plaintext key material; the key is held in your KMS and presented to Onplana for encryption and decryption operations.

Project Online Security vs Onplana: The Full Comparison

The table below compares both platforms on twelve security and compliance dimensions.

Security Dimension	Onplana	Project Online
SSO identity providers	SAML 2.0 and OIDC, any standards-compliant IdP	Microsoft Entra ID; other IdPs require federation
SCIM user provisioning	Native SCIM 2.0 endpoint	Via Azure AD connector (Microsoft-managed)
Audit log granularity	Field-level changes, API-accessible, JSON export	Administrative/event-level via Microsoft Purview
Customer-managed encryption keys	Yes (Enterprise tier, AWS KMS / Azure Key Vault / GCP KMS)	Microsoft Customer Key (M365 premium compliance add-on)
Deployment model	AWS, Azure, GCP, Docker, or SaaS	Microsoft Azure only
Data residency control	Full (self-hosted) or chosen SaaS region	Azure geographic regions at tenant level
IP allowlisting	Yes (app-layer and network-layer)	Via Entra ID Conditional Access policies
Air-gapped deployment	Yes (self-hosted, no egress required)	No
Role-based access control	Custom role definitions, granular permissions	PWA category-based security groups
SOC 2 Type II	Yes (Onplana standalone)	Inherited from Microsoft 365
Penetration testing	Annual third-party test; results available to Enterprise customers	Microsoft's responsibility (shared responsibility model)
GDPR data processing agreement	Available directly with Onplana	Microsoft DPA covers M365 services

Which Controls Matter for Your Organization?

The right answer depends on your threat model and compliance obligations.

For most organizations in the Microsoft 365 ecosystem, Project Online's inherited security posture covers the basics well. If your identity provider is Entra ID, your audit requirements are met by Microsoft Purview, and your compliance framework does not require customer-managed keys or out-of-Azure deployment, the security profile is adequate for the majority of enterprise PMO use cases.

The Onplana controls become material in specific scenarios. Healthcare and life-sciences PMOs under HIPAA or FDA 21 CFR Part 11 often require field-level audit trails as a validation artifact. Financial services organizations under SOX or DORA may require demonstrable proof of field-level change control for project records. Defense contractors and government agencies with FedRAMP High, IL4/IL5, or sovereign cloud requirements cannot use Azure SaaS without additional authorization. Organizations that have moved off Azure as their cloud infrastructure have a policy conflict with any Azure-only tooling.

If your organization is planning a migration from Project Online before the September 30, 2026 retirement deadline, the security evaluation belongs early in the vendor selection process, not as a late-stage compliance sign-off. Security teams reviewing the destination tool need time to evaluate architecture, request the penetration testing report, and configure SSO before the cutover. The features page details which security capabilities are available in each Onplana tier. Leaving security assessment to the final weeks of migration is one of the most consistent patterns in delayed cutovers.

Run the free Project Online Inventory Checklist Before your security team evaluates a destination tool, inventory what Project Online data you are protecting. The checklist maps every project, custom field, user role, and integration in about 10 minutes and generates a structured export plan. No signup required. → Open the checklist

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.