SHIELD¶
SHIELD: The six pillars of enterprise security for Power Platform
TL;DR
Six pillars cover the full enterprise security surface: Sight (identity & access), Harden (data security), Inspect (application security gate), Enforce (compliance & audit), Lockdown (infrastructure & network), Defend (threat detection & response). Five operate continuously; Inspect fires at defined lifecycle points. Start with the security baseline — then mature toward Advanced.
SHIELD is the security model for Power Platform — defining how organisations protect their solutions, data, and platform from risk, threat, and non-compliance.
What SHIELD Is¶
Security in enterprise Power Platform is not a single control or a single team's responsibility. It spans identity, data, applications, infrastructure, compliance, and threat response — each requiring deliberate design, consistent enforcement, and continuous operation.
SHIELD organises these concerns into six pillars — each covering a distinct security domain, each with a clear owner within the security organisation, and each mapped directly to the Power Platform controls and Microsoft tooling that implements it.
SHIELD is built on industry-standard security thinking — grounded in established security domains that any security professional will recognise regardless of their platform background. It then specialises to Power Platform, showing precisely how each domain maps to the platform's governance surface: Entra ID, DLP policies, Managed Environments, Dataverse auditing, Microsoft Sentinel, and more.
It is enterprise-first by design. Power Platform connects to everything — CRM, ERP, HR systems, financial data, customer records. The security model must be commensurate with that connectivity. SHIELD is written for organisations that take that responsibility seriously.
Why SHIELD Exists¶
Power Platform's accessibility is its greatest strength and its greatest security challenge. Hundreds of connectors. AI capabilities. Low-code development that puts powerful tooling in the hands of every licensed user. An ecosystem that spans from personal productivity to mission-critical regulated workloads.
Without a security model, that accessibility becomes exposure. DLP policies that were never designed. Connectors accessing sensitive systems without review. Flows running under personal accounts that expire when people leave. Audit evidence that does not exist when regulators ask for it.
SHIELD exists because enterprise Power Platform deployments need a security framework that is as deliberate as the governance model that runs the platform — not bolted on after an incident, but designed in from the start.
Who SHIELD Is For¶
SHIELD is written for the entire security organisation — not just the CISO, but every role that contributes to enterprise security posture:
| Role | Primary SHIELD Pillars |
|---|---|
| CISO | All pillars — strategic oversight and accountability |
| Security Architect | Sight, Harden, Lockdown |
| Application Security Engineer | Inspect, Enforce |
| Security Operations / SOC | Defend, Inspect |
| Compliance & Audit Officer | Enforce, Sight |
| Data Protection Officer | Harden, Enforce |
| Platform Admin (security responsibilities) | Sight, Lockdown, Enforce |
SHIELD and the Other Frameworks¶
SHIELD is one of four complementary frameworks on powerplatform.wiki:
| Framework | Core Question | Primary Audience |
|---|---|---|
| SHIELD | How do we protect the solution and platform? | CISO · Security Org |
| SCALE-OPS | How do we govern and operate the platform at scale? | Admin · CoE Lead · Platform Lead |
| DIALOGE | What are the building blocks of a solution? | Solution Maker · Solution Engineer |
| BOLT | How do business and IT build together? | Business Leadership · CIO · CTO · CFO |
The boundary between SHIELD and SCALE-OPS is the most important to understand clearly:
| Concern | Framework |
|---|---|
| Security posture, controls, monitoring, incident response | SHIELD |
| Platform operations, governance, lifecycle, enablement | SCALE-OPS |
| Business continuity and disaster recovery | SCALE-OPS (Operations pillar) |
| DLP policy security rationale and design | SHIELD (Harden + Enforce) |
| DLP policy deployment and environment management | SCALE-OPS (Containment) |
| Ongoing security health checks and posture assessments | SHIELD (Defend) |
| Platform operational health and capacity monitoring | SCALE-OPS (Operations + Performance) |
SHIELD asks: Are we secure? SCALE-OPS asks: Are we operating well?
The Six Pillars¶
| Letter | Pillar | Security Domain | Character |
|---|---|---|---|
| S | Sight | Identity & Access Management | Ongoing |
| H | Harden | Data Security & Privacy | Ongoing |
| I | Inspect | Application Security | Risk-based gate |
| E | Enforce | Compliance, Audit & Governance | Ongoing |
| L | Lockdown | Infrastructure & Network Security | Ongoing |
| D | Defend | Threat Detection, Response & Security Operations | Ongoing |
Five pillars are ongoing — they operate continuously as the platform runs. One pillar is a risk-based gate — Inspect fires at defined points in the solution lifecycle, not continuously.
The Core Questions SHIELD Answers¶
Every pillar addresses one of these questions:
- What are we protecting? — Sight
- How do we reduce exposure? — Harden
- Is what we built safe? — Inspect
- Are our controls consistently applied and evidenced? — Enforce
- Are our infrastructure boundaries holding? — Lockdown
- Are threats being detected and acted on? — Defend
S — Sight¶
You cannot secure what you cannot see.
Security Domain: Identity & Access Management Character: Ongoing
Sight is the foundation of the SHIELD framework — establishing complete visibility of who exists in the tenant, what they can access, and whether that access is appropriate. Without Sight, every other pillar operates blind.
Sight covers user and service account inventory, access mapping across environments and resources, permission reviews and least-privilege validation, authentication controls including MFA and conditional access, service principal and delegated admin governance, and external user management.
Key topics: User inventory, access mapping, least-privilege, MFA enforcement, conditional access, service principals, application users, Entra ID Access Reviews, Privileged Identity Management (PIM), guest and external user governance, orphaned account detection
H — Harden¶
Hardening is proactive — it reduces the attack surface before threats materialise.
Security Domain: Data Security & Privacy Character: Ongoing
Harden covers the controls that protect data at rest, in transit, and in use — ensuring that sensitive and regulated data is classified, protected, and governed before it is ever accessed by a threat actor. Hardening is a continuous posture, not a one-time configuration.
Harden covers data classification, DLP policy design and tiering, encryption at rest and in transit, row-level and column-level security, data residency configuration, privacy compliance, and secrets management.
Key topics: Data classification, DLP policy design and tiering, Dataverse security roles, row-level security, column-level security, encryption, data residency, Microsoft Purview, Azure Key Vault, GDPR and privacy compliance, sensitive data governance
I — Inspect¶
Not every solution needs a full review. Every solution must be assessed.
Security Domain: Application Security Character: Risk-based gate
Inspect is SHIELD's most distinctive pillar — a risk-based security review model that applies to solutions before they reach production. Unlike the other five pillars which operate continuously, Inspect fires at defined points in the solution lifecycle: before Go-Live, before significant changes reach production, and annually for approved workload patterns.
Inspect operates in three modes: Safe Zone auto-pass for solutions within pre-approved boundaries, Workload Pattern approval for classes of solutions reviewed once and approved for reuse, and Full Security Review for new patterns, regulated data, and high-risk workloads.
Key topics: Safe Zone — auto-pass criteria, Workload Pattern approval — review once, approve many, Full Security Review — triggers and process, connector security review, Solution Checker as a security gate, secure coding and design review, data handling review, authentication review, dependency mapping, annual pattern re-evaluation
E — Enforce¶
Enforcement turns policy into practice — and generates the evidence that audits require.
Security Domain: Compliance, Audit & Governance Character: Ongoing
Enforce ensures that security controls, policies, and compliance requirements are consistently applied across the platform — and that the evidence of that enforcement exists without requiring manual collection. In mature Power Platform environments, audits do not disrupt operations because evidence assembles itself as a byproduct of normal practice.
Enforce covers policy enforcement, compliance framework alignment, audit trail generation, maker compliance attestation, security baseline management, policy exception governance, and audit readiness.
Key topics: DLP policy enforcement with documented rationale, compliance frameworks (SOC2, ISO 27001, GDPR, HIPAA), audit trail generation as operational byproduct, maker attestation via CoE Starter Kit, security baselines per environment type, policy exception management, audit readiness — evidence on demand, Microsoft Purview, Dataverse audit logging
L — Lockdown¶
Lockdown is both a standing architecture principle and an emergency capability.
Security Domain: Infrastructure & Network Security Character: Ongoing
Lockdown defines the structural controls that contain risk through isolation, boundary enforcement, and network security — and the emergency capabilities that enable rapid containment when threats are detected. The best Lockdown controls are invisible to users and operators until they are needed urgently.
Lockdown covers environment isolation and purpose-driven environment strategy, tenant boundary controls, network isolation including Private VNet integration, Default Environment hardening, emergency access controls, cross-tenant connector governance, and data sovereignty.
Key topics: Environment isolation strategy, Managed Environments as the primary containment layer, tenant-level DLP policies, Private VNet integration for regulated workloads, Default Environment hardening, environment routing, IP firewall, emergency environment suspension and access revocation, cross-tenant connector controls, customer-managed keys, data sovereignty configuration
D — Defend¶
Defend is where security operations lives — the ongoing heartbeat of the security function.
Security Domain: Threat Detection, Response & Security Operations Character: Ongoing
Defend covers the full security operations lifecycle — continuous monitoring for threats and anomalies, structured incident response, forensic investigation, and the continuous improvement cycle that feeds post-incident learnings back into the platform's security posture. Defend also encompasses ongoing security operations: health checks, vulnerability scanning, and posture assessments.
Key topics: Continuous threat monitoring, Microsoft Sentinel integration, anomaly detection, Power Platform activity monitoring, incident severity levels (P1/P2/P3), incident response runbooks, escalation paths, forensic investigation using audit logs, root cause analysis, post-incident review discipline, security posture assessments, vulnerability scanning, continuous improvement cycle, Microsoft Defender for Cloud Apps
SHIELD Maturity Model¶
Each pillar has its own maturity levels. Across the framework, maturity follows a consistent pattern:
| Level | What it means |
|---|---|
| Basic | Minimum controls in place. Microsoft defaults applied. Suitable for low-risk, non-regulated workloads. |
| Intermediate | Deliberate security design. DLP policies tiered. Access reviews conducted. Incident response documented. Audit logging enabled. Suitable for enterprise solutions with moderate risk profiles. |
| Advanced | Full security posture. All six pillars operating at enterprise-grade. Automated enforcement, continuous monitoring, audit-ready evidence, regular posture assessments, post-incident improvement cycle active. Required for regulated industries, mission-critical workloads, and organisations with formal security compliance obligations. |
The SHIELD Security Baseline¶
Before any enterprise Power Platform deployment goes live, the following minimum baseline must be in place across all six pillars:
Sight: Named owners assigned to every environment. MFA enforced for all admin accounts. No personal accounts used for service connections.
Harden: DLP policy applied to every environment including Default. Dataverse security roles designed — not default System Administrator for all users. Data classification defined for all sensitive tables.
Inspect: Connector approval catalogue defined. Solution Checker configured as a deployment gate. At minimum, a safe zone definition exists — makers know what requires review.
Enforce: DLP policies documented with business rationale. Dataverse auditing enabled in all production environments. Audit retention period defined.
Lockdown: Production workloads in dedicated environments — not the Default Environment. Managed Environments enabled on all non-developer environments. Environment routing configured.
Defend: Service Health notifications subscribed. Flow failure monitoring in place for critical flows. An incident response contact defined — someone knows what to do when a security event occurs.
This baseline is the minimum. It is not the target. The target is Advanced maturity across all six pillars for regulated and mission-critical workloads.
How to Use SHIELD¶
If you are a CISO or security leader: Start with the framework overview here, then review the Enforce pillar for compliance posture and the Defend pillar for security operations. Use the maturity model to assess current state and set targets.
If you are a security architect: Read Sight, Harden, and Lockdown in full — these are the design-time security pillars where architectural decisions are made. Then review Inspect to understand the solution security review process.
If you are an application security engineer: Read Inspect in full — it defines the security review process you will operate. Then review Enforce for the compliance evidence your reviews must generate.
If you are a SOC analyst or security operations team: Read Defend in full — it defines your monitoring, detection, response, and continuous improvement responsibilities. Review Inspect for the application security context that informs what you are monitoring.
If you are a compliance or audit officer: Read Enforce in full — it defines the audit evidence, compliance framework alignment, and attestation processes. Review Sight for the access governance evidence that compliance frameworks typically require.
Reference Files¶
| File | Contents |
|---|---|
| shield-S-sight.md | Sight pillar — Identity & Access Management deep-dive |
| shield-H-harden.md | Harden pillar — Data Security & Privacy deep-dive |
| shield-I-inspect.md | Inspect pillar — Application Security risk-based gate deep-dive |
| shield-E-enforce.md | Enforce pillar — Compliance, Audit & Governance deep-dive |
| shield-L-lockdown.md | Lockdown pillar — Infrastructure & Network Security deep-dive |
| shield-D-defend.md | Defend pillar — Threat Detection, Response & Security Operations deep-dive |
Part of the powerplatform.wiki framework library Last updated: March 2026 Last reviewed: March 2026 Status: Complete — all six pillars documented