Skip to main content

DPCH09 — Compliant by Design

“Policy-as-Code and Entitlement Controls Enforced”

What DPCH09 is really asserting​

DPCH09 is not asserting that:

“The product is compliant” or “someone reviewed it.”

It is asserting that:

Compliance, access, and regulatory constraints are encoded as federated, executable policies (policy-as-code) that are visible during design, bound to the data product at publish-time, and enforced automatically at runtime.

Compliance is compiled into the product, not bolted on after the fact.

The Essence (Data Mesh + HDIP Interpretation)​

A Data Product satisfies DPCH09 if and only if:

  1. Governance is federated across layers: Global → Divisional → Domain → Product
  2. Applicable policies are discoverable and visible to the DPRO at design time
  3. Policies are bound to the product through its lifecycle (test, deploy, publish)
  4. Policies are enforced computationally at runtime (not manual controls)

This is the Data Mesh “computational governance” pillar in action.

Federated Policy Layers (What must exist)​

DPCH09 assumes a layered model:

  • Global policies (enterprise-wide): e.g., data classification rules, baseline retention, audit requirements
  • Divisional policies (CB/IB/PB): e.g., local regulatory rules, divisional risk controls
  • Domain policies (Payments, Risk): e.g., business-specific constraints, sharing rules
  • Product policies (optional): e.g., a product-specific usage restriction or additional control introduced by the DPRO

Critically: the DPRO can introduce product-specific policies, but only within permitted bounds (i.e., cannot override higher-level constraints).

Positive Criteria — When DPCH09 is met​

DPCH09 is met when all of the following are true:

1. Policies are visible during design (self-service governance)​

In the product management self-service portal, the DPRO can see:

  • which global/divisional/domain policies apply
  • why they apply (e.g., classification, jurisdiction, consumer type)
  • what choices are available (e.g., access posture options)

Visibility prevents “surprise compliance” later.

2. Policies are bound to the product during lifecycle​

During test/deploy/publish:

  • policies are linked to the data product descriptor/bundle

  • the product carries explicit references to:

    • applicable policy sets
    • entitlements model
    • classification/residency/retention attributes

This ensures compliance is not “out-of-band”.

3. Policies are executed at runtime (computational enforcement)​

Enforcement happens automatically through platform capabilities such as:

  • authorization checks (RBAC/ABAC/ReBAC/PBAC as applicable)
  • row/column filtering
  • purpose-based access gating
  • residency routing
  • audit logging and control execution

No reliance on “people remembering”.

4. Product-specific policies can be declared safely​

The DPRO may add product-specific policies like:

  • “only allowed for risk-approved consumers”
  • “mask these attributes for external sharing”
  • “retain only 90 days for this product”

These are added declaratively and enforced by the same policy engine.

Negative Criteria — When DPCH09 is not met​

DPCH09 is not met if any of the following are true:

❌ Policies exist but are not visible to the DPRO​

Examples:

  • governance rules live in documents
  • policies are applied later by governance teams
  • DPRO discovers constraints only after build

This is governance as surprise, not design.

❌ Policies are manual or procedural​

Examples:

  • ticket-based approvals for each access request
  • manual reviews substituting for policy enforcement
  • email-based sign-offs

Manual compliance does not scale and violates computational governance.

❌ Enforcement is optional or inconsistent​

Examples:

  • some ports enforce policies, others bypass them
  • policies exist but are not automatically executed
  • enforcement depends on engineers implementing it per pipeline

Compliance must be systemic, not bespoke.

Edge Cases (Important Guidance for Agents)​

Case 1: “Access control exists, but only RBAC at app level”​

⚠️ Partial

Rationale:

  • some enforcement exists
  • but not product-level, federated, or policy-as-code
  • missing residency/retention/purpose controls

Case 2: “Policies applied after deployment by central governance”​

❌ Not met

Rationale:

  • violates compliant-by-design
  • creates bottlenecks and delays
  • breaks self-service principle

Case 3: “Federated policies + design-time visibility + runtime enforcement”​

✅ Met

Rationale:

  • this is exactly the Data Mesh governance pillar realized

Evidence Signals an Agent Should Look For​

Authoritative evidence:

  • Policy registry bindings for the product (global/divisional/domain/product)
  • Entitlement model declaration linked to product
  • Runtime enforcement evidence (audit logs, access decisions)

Supporting evidence:

  • Portal screens showing applicable policies at design time
  • Policy conformance reports (pass/fail + reasons)
  • DPP trust section referencing compliance posture (optional linkage with DPCH06)

Red flags:

  • policies in PDFs
  • compliance “checklists” without enforcement
  • access granted via manual groups/tickets only

How an AI Agent Should Decide​

Decision rule (simplified):

If applicable policies are not visible at design time and not enforced computationally at runtime through federated policy-as-code, DPCH09 is not met.

Canonical Statement​

DPCH09 is satisfied only when federated computational governance (global → divisional → domain → product) is visible to the DPRO during design, bound to the product through deployment and publishing, and executed automatically at runtime via policy-as-code and entitlement enforcement.