Enterprise Readiness Assessment¶

All checklists from BOLT, SCALE-OPS, DIALOGE, and SHIELD — consolidated into one reference for enterprise evaluators, auditors, and new CoE leads.

How to use this page

Work through each section and check off what is in place. Gaps identify where to focus next. This page is designed to be printed, exported, or used as an audit working document.

BOLT — Operating Model Readiness¶

Source: BOLT Foundation

Platform Foundation¶

[ ] Low-code platform identified (Power Platform or equivalent)
[ ] Platform accreditation obtained or in progress — enterprise security approval
[ ] Workspace strategy defined — default, business, and solution workspace tiers established
[ ] DLP policies configured — per workspace tier with appropriate connector restrictions

Security Pre-Approvals¶

[ ] Classification boundary defined for Tier 1 and Tier 2 pre-approval
[ ] Security / compliance function engaged on pre-approval model
[ ] Pre-approval scope documented — what is covered, what is not
[ ] Pre-approval renewal cycle defined (annual minimum)

Connector Library¶

[ ] Connector assessment process defined — criteria documented
[ ] Initial connector library assessed and published
[ ] Request process defined for new connector approvals
[ ] Library governance cycle established — quarterly review, annual full assessment

Governance Documentation¶

[ ] Terms of use drafted and published
[ ] Developer guidelines drafted and published
[ ] Tier criteria documented — objective criteria for each tier
[ ] Escalation process documented — how solutions move between tiers

Roles and Ownership¶

[ ] Six BOLT roles identified and named — specific individuals or teams assigned
[ ] RACI communicated to all relevant parties
[ ] Ownership documentation process defined — captured at solution go-live
[ ] Orphaned resource process defined — what happens when owners leave

Enablement¶

[ ] Citizen developer training path designed and published
[ ] Power user training path designed and published
[ ] Support routing defined — Tech Solution Team scope and Platform Team escalation
[ ] Community channel established (Teams or SharePoint for maker community)

SHIELD — Security Baseline¶

Source: SHIELD Overview

Every enterprise Power Platform deployment must have the following minimum baseline in place before production workloads go live.

Sight (Identity & Access)¶

[ ] Named owners assigned to every environment
[ ] MFA enforced for all admin accounts
[ ] No personal accounts used for service connections
[ ] Entra ID Access Reviews configured for privileged roles
[ ] Service principals inventoried and governed
[ ] Guest/external user access time-bound and reviewed

Harden (Data Security)¶

[ ] DLP policy applied to every environment including Default
[ ] Dataverse security roles designed — not default System Administrator for all
[ ] Data classification defined for all sensitive tables
[ ] Column-level security profiles configured for sensitive fields
[ ] Secrets stored in Azure Key Vault — not embedded in solutions
[ ] Data residency verified for regulated workloads

Inspect (Application Security)¶

[ ] Connector approval catalogue defined and published
[ ] Solution Checker configured as a deployment gate
[ ] Safe zone definition exists — makers know what requires review
[ ] Workload pattern library started — at least one approved pattern
[ ] Full security review process documented for Tier 3–4 solutions

Enforce (Compliance & Audit)¶

[ ] DLP policies documented with business rationale
[ ] Dataverse auditing enabled in all production environments
[ ] Audit retention period defined and configured
[ ] Compliance framework alignment documented (SOC2, ISO, GDPR as applicable)
[ ] Maker attestation process active via CoE Starter Kit

Lockdown (Infrastructure & Network)¶

[ ] Production workloads in dedicated environments — not Default Environment
[ ] Managed Environments enabled on all non-developer environments
[ ] Environment routing configured
[ ] Default Environment hardened (restrictive DLP, limited access)
[ ] VNet integration assessed for regulated workloads

Defend (Threat Detection & Response)¶

[ ] Service Health notifications subscribed
[ ] Flow failure monitoring in place for critical flows
[ ] Incident response contact defined — someone knows what to do
[ ] Power Platform activity logs flowing to centralised SIEM (Microsoft Sentinel recommended)
[ ] At least one incident response runbook documented

DIALOGE — Solution Readiness (Per Solution)¶

Source: Individual pillar pages in DIALOGE

Use this section to assess readiness of a specific solution before go-live.

D — Data¶

[ ] Decision made: Dataverse vs alternative data store — justified and documented
[ ] Standard tables identified and extended where applicable
[ ] Custom tables created only where no standard table applies
[ ] Relationships designed — type, cascade behaviour, and purpose documented
[ ] Security roles designed by job function — not one role for all
[ ] Least privilege applied — minimum access required for each role
[ ] Business units configured if organisational data isolation is needed
[ ] Row-level security scope defined for each role on each table
[ ] Column-level security profiles created for sensitive fields
[ ] Application users created for all integrations — no personal accounts
[ ] Auditing enabled on all sensitive, regulated, and business-critical tables
[ ] Audit log retention period defined
[ ] Data classification assigned to all tables
[ ] Storage baseline recorded; capacity alerts configured

I — Integration¶

[ ] All connected systems mapped — internal and external
[ ] Data flow direction defined — push, pull, or bidirectional
[ ] Standard connector used where available
[ ] Connection references used for all connectors — no hardcoded connections
[ ] Service accounts or application users used — no personal credentials
[ ] Custom connectors reviewed and approved through governance process
[ ] All connectors verified against DLP policy
[ ] Error handling implemented on all critical flow actions
[ ] Failure alerts configured — notification to solution owner
[ ] Flow run history monitoring configured

A — AI¶

[ ] AI capabilities selected based on use case fit
[ ] Human-in-the-loop defined for all consequential AI decisions
[ ] AI accountability model established
[ ] Data classification reviewed for all data processed by AI models
[ ] Copilot Studio agent knowledge sources reviewed for accuracy and confidentiality
[ ] AI Builder credit consumption monitored
[ ] AI data residency verified

L — Logic¶

[ ] Logic placement decided per business rule — data layer first
[ ] Business rules implemented for logic that applies across all interfaces
[ ] Calculated and rollup columns used where applicable — not duplicated in apps
[ ] Every piece of logic has a named owner
[ ] Logic is testable in isolation
[ ] All logic packaged in solutions — nothing built directly in production

O — Operations¶

[ ] Application Insights configured for production canvas apps and critical flows
[ ] Custom events defined for business-significant actions
[ ] Error handling produces meaningful error messages for users
[ ] Support model defined (L1–L4) with named contacts
[ ] Operational documentation (runbooks) created alongside the solution
[ ] Retirement criteria defined — when and how to decommission

G — Go-Live¶

[ ] Solution packaged — all components in a solution with correct publisher prefix
[ ] Environment variables used for all environment-specific values
[ ] Connection references used for all connectors
[ ] Solution Checker run — Critical and High findings resolved
[ ] SHIELD Inspect gate passed (mode appropriate to solution risk)
[ ] UAT completed and signed off by business team
[ ] Deployed as managed solution to production
[ ] Version documented; rollback plan defined
[ ] Release communication sent to affected users

E — Experience¶

[ ] Interface type chosen deliberately (canvas, model-driven, Power Pages, etc.)
[ ] Responsive design implemented for target form factors
[ ] Accessibility verified against WCAG 2.1 AA (where applicable)
[ ] WYSIWYIS principle applied — display values reflect stored values
[ ] Performance tested with representative data volumes
[ ] User acceptance testing completed

Maturity Quick-Reference¶

All four frameworks use a consistent three-level maturity model:

Level	General Character	When It's Sufficient
Basic	Minimum viable. Microsoft defaults. Limited governance.	Personal productivity, low-risk, non-regulated
Intermediate	Deliberate design. Defined ownership. Error handling. Monitoring.	Team/department solutions, moderate risk
Advanced	Full enterprise discipline. Automated enforcement. Audit-ready. Continuously monitored.	Mission-critical, regulated, large user populations

The Safe Zone principle: Not every solution needs every capability at Advanced maturity. Each DIALOGE pillar and SHIELD pillar defines a safe zone — the conditions under which a lower maturity level is acceptable. Assess against safe zone boundaries, not maximum maturity.

Part of powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026