SHIELD — E: Enforce¶

Enforcement turns policy into practice — and generates the evidence that audits require.

TL;DR

Controls that exist but are not enforced create a false sense of security. Apply DLP policies consistently — every environment, reviewed against actual usage. Enable Dataverse auditing in all production environments. Generate compliance evidence as a byproduct of daily operations, not a periodic scramble. If you cannot respond to an audit finding within 24 hours, your enforcement is not mature enough.

Applies To

Audience: Compliance & Audit Officer · CISO · Platform Admin Character: Ongoing Frameworks: SHIELD · SCALE-OPS (Stewardship — governance processes)

What Enforce Means in SHIELD¶

Enforce is the pillar that closes the gap between security policy and security reality. Policies designed in Harden, access controls configured in Sight, and security reviews conducted in Inspect only provide security value if they are consistently applied — and if evidence of that application exists when it is needed.

In immature Power Platform environments, the gap between policy and practice is wide. DLP policies exist but have never been reviewed against actual connector usage. Security role assignments were made years ago and never revisited. Audit logs are enabled but retention is undefined. When an auditor asks "how do you know your controls are working?" the answer is silence.

In mature environments, audits do not disrupt operations. Evidence assembles itself as a byproduct of normal practice. Controls are consistently applied because automation enforces them. The audit conversation is a presentation of evidence, not a scramble to produce it.

Enforce is the discipline that creates the second scenario.

Why Enforce Decisions Matter¶

Security controls that exist but are not enforced create a false sense of security — and create liability when that false sense is tested. The consequences of unenforced controls are consistently more severe than the consequences of openly acknowledged gaps:

A DLP policy that exists but is never reviewed against actual usage provides no protection and prevents no incident
A compliance attestation process that makers bypass because it was never made mandatory provides no audit evidence
Security baselines that were defined but never applied to new environments mean that the environments created in the last two years have never been secured
Audit trails that were never enabled mean that when an incident occurs, there is no forensic evidence

Enforce converts security intent into security reality — through automation, through governance processes, and through the discipline of treating compliance evidence as a byproduct of daily operations rather than a periodic project.

The Core Questions Enforce Answers¶

Are our DLP policies consistently applied — not just defined?
Do we have documented rationale for every security policy decision?
Are makers attesting to compliance for their solutions?
Does evidence of our controls exist without manual collection?
Are we aligned to the compliance frameworks that apply to us?
Can we respond to an audit finding within 24 hours with documented evidence?
Are security baselines applied to every environment — including those created last week?

Policy Enforcement — Making Controls Stick¶

DLP Policy Consistency¶

DLP policies are only effective if they are applied consistently across all environments and if their application is monitored. The most common Enforce failure is DLP policies that exist in the tenant but have gaps — environments created without policy assignment, legacy environments with outdated policies, or policy exceptions that were granted informally and never expired.

DLP enforcement discipline: - Every environment must have at least one DLP policy applied — environments without DLP coverage are ungoverned by default - Tenant-level policies provide the floor — they apply to all environments and cannot be overridden by environment-level policies - Environment-level policies can be more restrictive than the tenant-level policy — they are additive, not competing - New environments must receive DLP policy assignment as part of the provisioning process — not as an afterthought - DLP policy coverage must be reviewed regularly — a quarterly review against the environment inventory confirms no gaps

DLP policy documentation: Every DLP policy must have a documented rationale — not just the policy configuration but the business reasoning behind each connector classification decision. When an auditor asks why a specific connector is blocked, or when a maker asks for an exception, the answer should be immediately available.

The documentation should capture: - Why each connector is in its assigned bucket - The approval authority for the policy - The date the policy was last reviewed - Any exceptions granted, with justification and expiry

Managed Environments as Enforcement Infrastructure¶

Managed Environments are the primary enforcement infrastructure for non-developer Power Platform environments. Enabling Managed Environments on an environment activates a suite of governance controls that would otherwise require manual oversight:

Solution Checker enforcement — blocks solution import if Critical or High severity findings exist
Sharing limits — restricts canvas app sharing to security groups rather than the entire organisation
Maker welcome content — communicates environment purpose and applicable policies to makers on first access
Usage insights — surfaces inactive apps, orphaned resources, and usage anomalies
IP firewall — restricts environment access to approved IP ranges

Managed Environments should be enabled on every non-developer environment as a baseline enforcement control. The investment is configuration; the return is consistent policy application without ongoing manual oversight.

Security Baselines¶

A security baseline is a defined minimum security configuration for each environment type — the set of controls that must be in place before an environment is used for its intended purpose.

Example security baseline for a Production environment: - Managed Environments enabled - DLP policy applied (specific named policy or tier) - Named owner recorded in Admin Center - System Administrator role assigned only to named individuals with documented justification - Dataverse auditing enabled - Solution Checker enforcement enabled - Environment routing configured (for Default Environment)

The security baseline converts security requirements into a checklist that every environment must satisfy. New environments are provisioned against the baseline; existing environments are reviewed against it periodically.

Baseline enforcement: Security baselines are most effective when their application is automated — provisioning workflows that configure new environments to baseline before they are handed to the owner. Manual baseline application introduces variation and gaps. The platform team should own baseline definition, automation, and periodic verification.

Compliance Framework Alignment¶

Power Platform deployments in regulated industries must demonstrate alignment to applicable compliance frameworks. Enforce is where that alignment is documented, evidenced, and maintained.

Common Frameworks and Their Power Platform Implications¶

SOC 2 (Service Organisation Control 2) SOC 2 audits evaluate controls related to security, availability, processing integrity, confidentiality, and privacy. For Power Platform: - Access controls (Sight) must be documented and reviewed - DLP policies and Dataverse security roles provide the confidentiality controls - Audit logging provides the evidence of control operation - Change management records (solution deployment history) provide processing integrity evidence

ISO 27001 ISO 27001 requires a comprehensive information security management system. For Power Platform: - Asset inventory — all environments, solutions, and data stores - Access management — role assignments, access reviews, authentication controls - Cryptography — encryption at rest and in transit - Supplier relationships — Microsoft as a cloud service provider - Incident management — the Defend pillar's incident response framework

GDPR GDPR requires documented data processing activities, lawful basis, and data subject rights processes. For Power Platform: - Record of processing activities — documenting what personal data Power Platform solutions process and why - Data Protection Impact Assessments (DPIAs) — for high-risk processing activities - Data subject rights — processes for access, erasure, and portability requests - Data breach notification — the Defend pillar's incident response must include breach notification procedures

HIPAA HIPAA requires technical, administrative, and physical safeguards for Protected Health Information (PHI). For Power Platform: - Access controls — Sight and Harden controls for environments containing PHI - Audit controls — Dataverse auditing and activity logging - Transmission security — encryption in transit for PHI - Business Associate Agreements — Microsoft's BAA for covered Power Platform services

The documentation requirement: Framework alignment must be documented — not assumed. For each applicable framework, maintain a controls mapping document that shows which SHIELD controls address which framework requirements, with evidence references. This mapping is the foundation of the audit response.

Audit Trail Generation as Operational Byproduct¶

The most mature Power Platform environments do not prepare for audits — they pass them. This is possible when audit evidence is a byproduct of normal operations rather than a project triggered by an audit notification.

What Constitutes Audit Evidence in Power Platform¶

Access governance evidence: - Entra ID Access Review reports — showing who reviewed access, when, and what actions were taken - PIM activation logs — showing when admin access was used, by whom, and for what purpose - Environment role assignment history — who has had what access to which environments

Change management evidence: - Solution deployment history via Power Platform Pipelines or Azure DevOps — every production deployment recorded with approver, timestamp, and solution version - Source control commit history — every solution change traceable to a developer, a commit, and a review - DLP policy change history — when policies were modified, by whom, and what changed

Operational compliance evidence: - Dataverse audit logs — record-level create, update, delete history for regulated tables - Flow run history — execution records for critical automated processes - Solution Checker results — stored as pipeline artefacts, showing security review outcomes - Maker compliance attestations — stored in Dataverse via the CoE Starter Kit

Configuration evidence: - Managed Environments configuration — showing that governance controls are enabled - DLP policy configuration — the policy itself, with its documented rationale - Security role definitions — showing what access each role provides - Environment inventory — every environment with its owner, purpose, and DLP coverage

The Audit Package¶

When an auditor requests evidence, the audit package should be assemblable within hours — not weeks. The audit package for a typical Power Platform compliance review includes:

Environment inventory with owners and DLP coverage
User access report — who has what roles in which environments
Access review records — last review date, reviewer, outcomes
DLP policies with documented rationale
Production deployment history — last 12 months
Maker compliance attestations for production solutions
Dataverse audit log sample — demonstrating audit capability
Incident log — any security events in the review period and their resolution

If any of these elements requires a significant effort to produce, it is a signal that the corresponding Enforce control is not operating as a byproduct of normal operations.

Maker Compliance Attestation¶

The CoE Starter Kit's compliance process requires makers to self-attest to the data handling, business justification, and support arrangements for their solutions. This attestation process serves two purposes: it makes makers explicitly aware of their governance responsibilities, and it generates compliance documentation for the organisation.

What makers attest to: - Business justification — why does this solution exist, what business problem does it solve? - Data classification — what data does this solution access or process? - Support arrangements — who supports this solution, how do users get help? - Maker acknowledgement — the maker confirms they understand the applicable DLP policies and governance requirements

The compliance process: The CoE Starter Kit includes a compliance process flow that identifies solutions requiring attestation — typically solutions above a defined usage threshold or in production environments — and sends attestation requests to solution owners. Solutions without valid attestation are flagged for follow-up.

The enforcement dimension: Attestation processes only provide value if they are enforced. A compliance process that sends requests and accepts non-response without follow-up generates no meaningful evidence. The platform team must: - Define which solutions require attestation (production solutions, solutions above a user count threshold, solutions handling Confidential or Regulated data) - Follow up on non-responses within a defined timeframe - Escalate to solution owners' managers if responses are not received - Maintain an exception register for solutions with overdue or outstanding attestations

Policy Exception Management¶

Security policies will generate exception requests. DLP policies block connectors that makers need. Security baselines restrict access that individuals believe they require. The exception process is not a failure of governance — it is a feature of governance that must itself be governed.

Exception process requirements: - Formal intake — exceptions submitted through a defined channel (Power Apps form, ServiceNow, or the CoE Starter Kit's request process) - Business justification — the requester documents why the exception is needed and what business purpose it serves - Risk assessment — the security function assesses the risk introduced by the exception - Time-limited approval — exceptions are granted for a defined period, not permanently. Standing exceptions should be rare and explicitly justified. - Review at expiry — exceptions are reviewed when they expire; continued need must be re-justified - Register maintained — all granted exceptions are logged with justification, approver, and expiry date

The exception register as audit evidence: The exception register is one of the most important compliance documents for a regulated organisation. It demonstrates that exceptions to security policy were granted deliberately, with documented justification and limited duration — rather than being ad-hoc workarounds that accumulated without oversight.

Maturity Levels¶

Level	Description
Basic	DLP policies applied to all environments. Some documentation of policy decisions. Dataverse auditing enabled in production. Basic attestation awareness.
Intermediate	DLP policies documented with rationale. Managed Environments enabled on all non-developer environments. Security baselines defined. Compliance framework mapping documented. Maker attestation process active via CoE Starter Kit. Exception register maintained.
Advanced	Full audit trail generation as operational byproduct. Automated baseline enforcement on environment provisioning. Compliance framework controls mapped and evidenced. Audit package assemblable within hours. Exception process fully governed with time-limited approvals. Quarterly Enforce review cycle active.

Safe Zone¶

Low-risk, non-regulated solutions with informal support and limited user base can operate at Basic maturity.

Any deployment that meets one or more of the following must reach Intermediate or Advanced maturity: - Subject to SOC 2, ISO 27001, GDPR, HIPAA, or any other compliance framework - Processes Confidential or Regulated data - Has external users or customer-facing components - Is mission-critical — compliance failures have material business impact - Has undergone or is expected to undergo an external audit

Common Mistakes¶

Policies defined but never enforced — DLP policies exist in documentation but have gaps in application. New environments created without policy assignment. The policy is theoretical; the protection is absent.
No documented rationale — policies applied without explanation. When an exception is requested, there is no baseline against which to evaluate it. When an auditor asks why a connector is blocked, nobody can answer.
Managed Environments not enabled — environments operating without the governance infrastructure that Managed Environments provides. Solution Checker bypass, ungoverned sharing, no usage insights.
Attestation process not enforced — compliance requests sent, non-responses accepted. The attestation register shows outstanding items for months without follow-up.
Security baselines defined but not applied — the baseline document exists; the environments created last month do not conform to it.
Exceptions accumulate — exceptions granted informally, without documentation, without expiry dates. The exception register grows without review. What was an acceptable temporary exception two years ago is now a standing gap.
Audit evidence assembled as a project — when an audit notification arrives, a multi-week effort begins to collect evidence. Evidence that should have been a byproduct of operations becomes an emergency project.
Compliance framework mapping incomplete — the organisation claims SOC 2 alignment but has never mapped SHIELD controls to SOC 2 requirements. The first audit conversation is also the first time the gaps become visible.

Readiness Checklist¶

DLP Policy Enforcement - [ ] DLP policy applied to every environment — no ungoverned environments - [ ] Tenant-level DLP policy in place for organisation-wide restrictions - [ ] All DLP policies documented with business rationale - [ ] DLP policy coverage reviewed quarterly — no gaps - [ ] DLP exception process defined — intake, assessment, approval, expiry, register

Managed Environments - [ ] Managed Environments enabled on all non-developer environments - [ ] Solution Checker enforcement configured - [ ] Sharing limits configured — canvas apps shared to security groups, not entire organisation - [ ] Maker welcome content configured for each environment - [ ] IP firewall configured for sensitive environments (where applicable)

Security Baselines - [ ] Security baseline defined for each environment type - [ ] Baseline application automated for new environment provisioning (where possible) - [ ] Existing environments verified against current baseline - [ ] Baseline review schedule defined — reviewed when compliance requirements change

Audit Trail - [ ] Dataverse auditing enabled in all production environments with defined retention period - [ ] Solution deployment history retained — pipeline artefacts, source control - [ ] Access review records retained — Entra ID Access Review reports - [ ] PIM activation logs retained (where PIM is in use) - [ ] DLP policy change history documented - [ ] Audit package components identified — assemblable within defined timeframe

Maker Attestation - [ ] CoE Starter Kit compliance process deployed and active - [ ] Solutions requiring attestation defined — criteria documented - [ ] Non-response follow-up process defined - [ ] Attestation records stored in Dataverse and retained

Compliance Framework - [ ] Applicable compliance frameworks identified - [ ] Controls mapping document created — SHIELD controls mapped to framework requirements - [ ] Evidence references identified for each control - [ ] Gap assessment completed — controls not yet implemented documented and remediated

Exception Management - [ ] Exception intake process defined and communicated to makers - [ ] All active exceptions documented in exception register - [ ] Exceptions time-limited — no permanent exceptions without explicit re-justification - [ ] Exception register reviewed quarterly — expired exceptions actioned

Part of the SHIELD Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026