Skip to main content

Enterprise Data Management Requirements Catalogue

1. Purpose​

The Enterprise Data Management Requirements Catalogue is the detailed, authoritative requirement set supporting the Enterprise Data Management Principles & Mandatory Requirements.

It translates the Level 1 principles into specific, traceable, assessable requirements.

The catalogue is intended for use by:

  • programme management;
  • Enterprise Architects;
  • Domain Architects;
  • Solution Architects;
  • Data Architects;
  • Data Owners;
  • Data Stewards;
  • Engineering teams;
  • governance forums;
  • Enterprise Data Architecture / Data Management functions.

Each requirement is structured to support applicability assessment, design traceability, evidence review, Data Control assessment, and exception governance.

Where architecture semantics are relevant, the catalogue uses GEDRM 0.1 as the semantic reference model and GEDRA 0.1 as the generic enterprise data reference architecture. Local or profile-specific architecture terminology should be mapped explicitly to those generic semantics.

2. Normative Language​

  • MUST — mandatory requirement. Non-compliance requires an explicitly approved exception.
  • MUST NOT — prohibited practice unless an approved exception exists.
  • SHOULD — expected practice unless a justified alternative is documented.
  • MAY — optional where appropriate.

3. Requirement Model​

AttributePurpose
Requirement IDStable identifier
Requirement DomainRequirement family
Requirement StatementNormative requirement
Normative LevelMUST / SHOULD / MAY
ApplicabilityConditions under which it applies
RationaleWhy the requirement exists
Evidence ExpectedHow compliance is demonstrated
Control RequiredYes / No / Existing / New / Changed
Control ReferenceIdentifier of related Data Control where applicable
Accountable Delivery RoleWho implements or provides evidence
EA AssessmentAccepted / Concern / Exception Required
Exception ReferenceWhere applicable

4. Requirement Domains​

Diagram

  • DMR-01 Data Ownership and Accountability
  • DMR-02 Data Classification and Criticality
  • DMR-03 Authoritative Sources and Data Copies
  • DMR-04 Data Modelling and Semantics
  • DMR-05 Data Contracts and Schema Management
  • DMR-06 Data Quality
  • DMR-07 Metadata and Data Lineage
  • DMR-08 Data Lifecycle, Retention and Deletion
  • DMR-09 Data Residency, Sovereignty and Cross-Border Movement
  • DMR-10 Data Consumers and Consumption
  • DMR-11 Data Asset and Data Product Assessment
  • DMR-12 Data Product Management
  • DMR-13 Data Change and Evolution
  • DMR-14 Data Security, Access and Entitlements
  • DMR-15 Data Observability and Operational Management
  • DMR-16 Data Integration and Interoperability
  • DMR-17 Regulatory and Evidential Data Requirements
  • DMR-18 Data Architecture Alignment
  • DMR-19 AI and Advanced Analytics Consumption
  • DMR-20 Data Controls and Assurance
  • DMR-21 Architecture Evidence, Exceptions and Governance

DMR-01 — Data Ownership and Accountability

Objective​

Ensure that all material data created or affected by an initiative has clear business, technical, and governance accountability.

DMR-01.01 — Business Data Ownership​

Every material business dataset or data domain affected by the initiative MUST have an identified accountable Business Data Owner.

DMR-01.02 — Technical Ownership​

Every material technical implementation that stores, processes, or distributes data MUST have an identified technical owner.

DMR-01.03 — Data Stewardship​

Where enterprise Data Governance policy requires Data Stewardship, the relevant steward MUST be identified.

DMR-01.04 — Product Ownership​

Where data is managed as a Data Product, an accountable Data Product Owner MUST be identified.

DMR-01.05 — Ownership Persistence​

Ownership MUST remain valid after programme closure.

A programme team itself MUST NOT be treated as the enduring owner of production data unless the programme becomes an established operational capability.

DMR-01.06 — Producer and Consumer Accountability​

Material data producers and consumers MUST be identifiable.

DMR-02 — Data Classification and Criticality

Objective​

Ensure that data is appropriately classified and that controls reflect its nature, sensitivity, and business importance.

DMR-02.01 — Enterprise Classification​

Material data MUST be classified using applicable enterprise classification standards.

DMR-02.02 — Sensitive Data Identification​

The initiative MUST identify data subject to enhanced protection, including where applicable:

  • personal data;
  • customer information;
  • transaction information;
  • confidential business information;
  • regulatory information;
  • commercially sensitive information;
  • legal records;
  • restricted data.

DMR-02.03 — Critical Data Elements​

The initiative MUST identify whether it creates or changes Critical Data Elements or equivalent governed data concepts.

DMR-02.04 — Control Alignment​

Security, retention, access, distribution, resilience, monitoring, and Data Controls MUST be proportionate to the classification and criticality of the data.

DMR-02.05 — Derived Data​

Derived data MUST NOT automatically be assumed to have a lower classification than its source.

DMR-03 — Authoritative Sources and Data Copies

Objective​

Protect governed authority over data and avoid unnecessary proliferation of non-owning copies.

DMR-03.01 — Authoritative Source Identification​

For material data, the Authoritative Source MUST be identified for the relevant governed scope. Where material to the architecture, the System of Record maintaining authoritative operational state and the Source of Authority establishing or designating sourcing authority MUST also be identifiable. These roles may coincide but MUST NOT be assumed equivalent.

DMR-03.02 — New Authoritative Sources​

An initiative proposing a new Authoritative Source MUST obtain appropriate architectural and governance approval, including explicit authority designation by the applicable Source of Authority or equivalent governance basis.

DMR-03.03 — Duplicate Authority​

An initiative MUST NOT create an ungoverned competing Authoritative Source for an existing governed data scope.

DMR-03.04 — Persistent Copies​

A persistent non-authoritative copy MUST have documented justification.

Acceptable justification may include:

  • regulatory requirements;
  • jurisdictional requirements;
  • resilience;
  • operational performance;
  • consumer isolation;
  • analytical requirements;
  • contractual obligations.

DMR-03.05 — Copy Traceability​

A non-authoritative copy MUST retain traceability to its authoritative source.

DMR-03.06 — Synchronisation​

Where a copy is expected to remain aligned with its source, the synchronisation mechanism and acceptable lag MUST be defined.

DMR-03.07 — Copy Lifecycle​

Copies MUST have defined retention, ownership, refresh, and retirement arrangements.

DMR-03.08 — Non-Owning Copy Principle​

Persistent non-owning copies SHOULD be minimised in accordance with Enterprise Data Strategy.

DMR-04 — Data Modelling and Semantics

Objective​

Maintain consistent business meaning across the enterprise.

DMR-04.01 — Semantic Reuse​

Existing enterprise or domain business concepts MUST be reused where appropriate.

DMR-04.02 — Programme-Specific Semantics​

Programmes MUST NOT introduce alternative definitions for existing enterprise concepts without explicit governance.

DMR-04.03 — New Concepts​

New material business concepts MUST be defined and governed.

DMR-04.04 — Source-to-Target Mapping​

Material semantic transformations MUST be documented.

DMR-04.05 — Semantic Preservation​

Source distinctions that have material business meaning MUST NOT be lost solely for implementation convenience.

DMR-04.06 — Common Models​

Where canonical, standard, ontology, or domain models exist, initiatives SHOULD align with them.

DMR-04.07 — Enterprise Ontology Alignment​

Material business concepts SHOULD align to the applicable Enterprise Ontology or Domain Ontology where such models exist.

DMR-04.08 — External Standards​

Where external standards are used, mappings between external and internal semantics MUST be explicit and traceable.

DMR-05 — Data Contracts and Schema Management

Objective​

Ensure predictable, governed, and evolvable exchange of data.

DMR-05.01 — Governed Data Interfaces​

Material data interfaces MUST have an explicit contract.

DMR-05.02 — Contract Content​

A data contract SHOULD define, where relevant:

  • schema;
  • semantic meaning;
  • mandatory fields;
  • optional fields;
  • permissible values;
  • ownership;
  • Data Quality expectations;
  • availability;
  • latency;
  • version;
  • compatibility expectations.

DMR-05.03 — Schema Versioning​

Schemas exposed to consumers MUST support controlled version evolution.

DMR-05.04 — Breaking Changes​

Breaking changes MUST be identified and governed.

DMR-05.05 — Consumer Impact​

Material contract changes MUST assess downstream consumer impact.

DMR-05.06 — Deprecation​

Deprecated contracts or schemas MUST have an explicitly governed retirement process.

DMR-05.07 — Technical Versus Product Contracts​

A technical interface contract MUST NOT automatically be treated as equivalent to a Data Product Product Promise. A Data Contract and Product Promise may be related, but they remain distinct governed constructs.

DMR-06 — Data Quality

Objective​

Ensure that data is fit for its intended business use.

DMR-06.01 — Quality Requirements​

Material datasets MUST have Data Quality expectations appropriate to their intended use.

DMR-06.02 — Quality Dimensions​

Applicable dimensions SHOULD include:

  • accuracy;
  • completeness;
  • validity;
  • timeliness;
  • consistency;
  • uniqueness.

DMR-06.03 — Consumer Context​

Data Quality requirements MUST consider the needs of material consumers.

DMR-06.04 — Quality Rules​

Material Data Quality rules MUST have explicit measurement logic.

DMR-06.05 — Quality Thresholds​

Where practical, acceptable quality thresholds MUST be defined.

DMR-06.06 — Quality Ownership​

Responsibility for Data Quality monitoring and remediation MUST be identified.

DMR-06.07 — Quality Failure​

Material Data Quality failures MUST have defined escalation and remediation arrangements.

DMR-06.08 — Regulatory Quality​

Data used for regulatory purposes MUST satisfy applicable regulatory accuracy, completeness, and evidential requirements.

DMR-06.09 — Data Quality Control Assurance​

Material Data Quality obligations MUST be supported by appropriate Data Controls in accordance with DMR-20. A Data Quality Rule evaluates a quality condition; the Data Control provides the governed assurance mechanism. Where the phrase Data Quality control is used operationally, it is an architectural/control pattern rather than a new GEDRM core concept.

DMR-07 — Metadata and Data Lineage

Objective​

Ensure that material data can be understood, discovered, traced, and governed.

DMR-07.01 — Business Metadata​

Material datasets MUST have sufficient business metadata to explain their purpose and meaning.

DMR-07.02 — Technical Metadata​

Relevant schema, platform, interface, and technical metadata MUST be captured.

DMR-07.03 — Ownership Metadata​

Ownership information MUST be discoverable.

DMR-07.04 — End-to-End Lineage​

Material data flows MUST provide lineage from authoritative source to material consumption point.

DMR-07.05 — Transformation Lineage​

Material transformations MUST be represented in lineage.

DMR-07.06 — Regulatory Lineage​

Regulatory and other critical data MUST provide sufficient lineage to support auditability and reconstruction.

DMR-07.07 — Product Lineage​

Data Products MUST identify their upstream dependencies and downstream material consumption relationships.

DMR-07.08 — Metadata Registration​

Governed Data Assets and Data Products MUST be registered in the appropriate enterprise catalogue or registry where such capability exists.

DMR-07.09 — Metadata and Lineage Controls​

Where required by risk, regulation, or product promise, material metadata and lineage obligations MUST have controls capable of identifying material gaps or failures.

DMR-08 — Data Lifecycle, Retention and Deletion

Objective​

Ensure that persistence is intentional and aligned with business, legal, regulatory, and operational obligations.

DMR-08.01 — Purpose of Persistence​

Every material persistent store MUST have a defined purpose.

DMR-08.02 — Retention Period​

Retention requirements MUST be defined.

DMR-08.03 — Legal and Regulatory Alignment​

Retention MUST comply with applicable legal, regulatory, records-management, and contractual obligations.

DMR-08.04 — Deletion​

Where deletion is required, deletion behaviour MUST be defined.

DMR-08.05 — Downstream Propagation​

Where relevant, the initiative MUST determine whether source deletion, correction, or restriction must propagate downstream.

DMR-08.06 — Archival​

Archival requirements MUST be distinguished from operational storage requirements.

DMR-08.07 — Temporary Data​

Temporary, cached, staging, and intermediate data MUST have defined lifecycle controls.

DMR-08.08 — Indefinite Persistence​

Data MUST NOT be retained indefinitely solely because no deletion mechanism was designed.

DMR-08.09 — Lifecycle Controls​

Material retention and deletion obligations MUST be supported by controls that provide evidence of expected lifecycle behaviour where required.

DMR-09 — Data Residency, Sovereignty and Cross-Border Movement

Objective​

Ensure that jurisdictional requirements apply to the complete data lifecycle and not merely primary storage.

DMR-09.01 — Residency Identification​

Applicable data residency requirements MUST be identified.

DMR-09.02 — Storage Location​

The jurisdiction in which material data is stored MUST be known.

DMR-09.03 — Processing Location​

The jurisdiction in which restricted data is processed MUST be understood.

DMR-09.04 — Cross-Border Transfer​

Material cross-border data movement MUST be explicitly identified.

DMR-09.05 — Replication​

Replication and backup locations MUST be included in residency assessment.

DMR-09.06 — Disaster Recovery​

Disaster recovery arrangements MUST satisfy applicable jurisdictional restrictions.

DMR-09.07 — Operational Access​

Support, administrative, and engineering access from another jurisdiction MUST be considered where residency or sovereignty rules apply.

DMR-09.08 — Metadata and Logs​

Metadata, logs, telemetry, derived data, and backups MUST be included in residency assessment where they contain restricted information.

DMR-09.09 — Residency Controls​

Material residency and cross-border restrictions MUST have controls capable of preventing or detecting unauthorised storage, replication, processing, or access where required.

DMR-10 — Data Consumers and Consumption

Objective​

Ensure that data is designed and governed with explicit understanding of who consumes it and for what purpose.

DMR-10.01 — Consumer Identification​

Material Data Consumers MUST be identified. Where data passes through intermediary recipients, the Data Recipient and the ultimate Data Consumer MUST be distinguished where those roles differ.

DMR-10.02 — Consumer Classification​

Consumers SHOULD be classified where relevant as:

  • operational;
  • regulatory;
  • risk;
  • finance;
  • analytics;
  • reporting;
  • Data Science;
  • AI/ML;
  • external customer;
  • external institution;
  • regulator;
  • downstream Data Product.

DMR-10.03 — Purpose of Consumption​

The intended purpose of material consumption MUST be understood.

DMR-10.04 — Consumption Expectations​

Availability, latency, Data Quality, retention, and support expectations MUST reflect material consumer needs.

DMR-10.05 — Uncontrolled Direct Consumption​

Where governed products or interfaces exist, uncontrolled direct access to underlying implementation stores SHOULD be avoided.

DMR-10.06 — Consumer Dependency​

Material downstream dependencies MUST be identifiable.

DMR-11 — Data Asset and Data Product Assessment

Objective​

Determine whether newly created or materially changed data should remain a Data Asset or be managed as a Data Product.

DMR-11.01 — Asset Identification​

Material reusable data created by an initiative MUST be assessed as a governed Data Asset.

DMR-11.02 — Productization Assessment​

Reusable Data Assets MUST be assessed to determine whether they should be managed as Data Products.

DMR-11.03 — Productization Factors​

The assessment SHOULD consider:

  • consumer population;
  • cross-domain reuse;
  • regulatory significance;
  • expected longevity;
  • discoverability requirements;
  • service expectations;
  • Data Quality commitments;
  • semantic stability;
  • support obligations;
  • repeatable consumption;
  • lifecycle management;
  • ownership;
  • cost and value.

DMR-11.04 — Intentional Productization​

A Data Asset MUST NOT be classified as a Data Product solely because it is technically consumable.

DMR-11.05 — Ownership Decision​

The accountable owner MUST make or endorse the decision to accept the product obligations associated with productization.

DMR-12 — Data Product Management

Objective​

Ensure that data intentionally productized as a Data Product satisfies applicable enterprise productization requirements, GEDRA Data Product semantics, and, where adopted, HDIP profile-specific product management requirements.

DMR-12.01 — Product Identity​

A Data Product MUST have a stable identity.

DMR-12.02 — Product Ownership​

A Data Product MUST have an accountable owner.

DMR-12.03 — Product Promise​

A Data Product MUST define an explicit consumer-facing Product Promise.

DMR-12.04 — Output Ports​

Data Product consumption interfaces MUST be governed as explicit output ports or equivalent product interfaces.

DMR-12.05 — Input Dependencies​

Material source dependencies MUST be identified.

DMR-12.06 — Product Versioning​

Material changes to the Product Promise MUST be version-managed.

DMR-12.07 — Discoverability​

Data Products MUST be discoverable through the appropriate enterprise catalogue, registry, ProductVerse, marketplace, or equivalent capability.

DMR-12.08 — Observability​

A Data Product MUST expose sufficient observability signals to determine whether it is meeting its Product Promise. Those signals SHOULD support health assessment and product-evolution decisions where material.

DMR-12.09 — Lifecycle​

Creation, activation, evolution, deprecation, and retirement MUST be governed.

DMR-12.10 — Economic Accountability​

Material Data Products SHOULD provide sufficient cost and value transparency to support economic accountability.

DMR-12.11 — Product Promise Controls​

Appropriate Data Controls MUST support material Product Promise commitments where governed assurance is required.

DMR-13 — Data Change and Evolution

Objective​

Ensure that initiatives design for future data evolution rather than only the initial implementation state.

DMR-13.01 — Upstream Change​

The impact of upstream schema or semantic change MUST be considered.

DMR-13.02 — Consumer-Driven Change​

The architecture MUST support controlled evolution in response to legitimate downstream requirements.

DMR-13.03 — New Dependencies​

Introduction of new enrichment or source dependencies MUST be governed.

DMR-13.04 — Backward Compatibility​

Where consumers require continuity, backward compatibility SHOULD be provided.

DMR-13.05 — Version Management​

Material changes to externally consumed data MUST be versioned where necessary.

DMR-13.06 — Migration​

Breaking changes MUST define consumer migration arrangements.

DMR-13.07 — Change Traceability​

Material semantic, schema, or product changes MUST be traceable to their rationale and approval.

DMR-13.08 — Control Impact Assessment​

Material data changes MUST assess whether existing Data Controls are affected, invalidated, or require revalidation.

DMR-14 — Data Security, Access and Entitlements

Objective​

Ensure that access to data is appropriate, controlled, and aligned with Data Management requirements.

DMR-14.01 — Least Privilege​

Access MUST follow least-privilege principles.

DMR-14.02 — Purpose-Based Access​

Where applicable, access MUST be consistent with legitimate business purpose.

DMR-14.03 — Privileged Access​

Privileged access to restricted data MUST be controlled and auditable.

DMR-14.04 — Access Lifecycle​

Provisioning, review, and removal of access MUST be governed.

DMR-14.05 — Shared Credentials​

Shared or uncontrolled credentials MUST NOT be used for material data access unless explicitly authorised.

DMR-14.06 — Security Versus Data Governance​

Technical authorization or access permission MUST NOT by itself be treated as sufficient evidence of legitimate data usage or governed Entitlement. Authentication, authorization, and entitlement semantics MUST remain distinguishable where material.

DMR-14.07 — Entitlement Controls​

Material access and entitlement obligations MUST have appropriate preventive and/or detective controls.

DMR-15 — Data Observability and Operational Management

Objective​

Ensure that material data assets, products, flows, and supporting capabilities expose sufficient operational signals and that those signals can be interpreted to assess health, obligations, cost, value, feedback, and evolution where relevant.

DMR-15.01 — Operational Health​

Material data flows, Data Assets, Data Products, and supporting capabilities MUST expose appropriate operational observability signals.

DMR-15.02 — Freshness​

Where timeliness matters, data freshness MUST be observable.

DMR-15.03 — Volume​

Unexpected material changes in data volume SHOULD be detectable.

DMR-15.04 — Schema Failure​

Schema incompatibility or contract failure MUST be detectable.

DMR-15.05 — Quality Failure​

Material Data Quality failures MUST be observable.

DMR-15.06 — Product Promise Monitoring​

Where data is productized, Plane-4-style Observability Capability MUST expose sufficient signals to assess whether the Product Promise is being met. Where health, value, lifecycle, or evolution decisions depend on those signals, they SHOULD be interpreted through Plane-6-style Observability & Health Assessment.

DMR-15.07 — Observability Is Not Sufficient by Itself​

Where an observation is intended to support a control obligation, the threshold or rule, Control Owner, trigger/frequency, response, evidence, and remediation behaviour MUST be explicitly defined. A metric, dashboard, log, or observability signal is NOT by itself a Data Control or Control Evidence.

DMR-16 — Data Integration and Interoperability

Objective​

Promote sustainable data exchange between domains and platforms.

DMR-16.01 — Approved Integration Patterns​

Material data integration SHOULD use approved enterprise integration patterns.

DMR-16.02 — Loose Coupling​

Cross-domain data exchange SHOULD minimise unnecessary implementation coupling.

DMR-16.03 — Semantic Interoperability​

Interoperability MUST consider meaning as well as technical connectivity.

DMR-16.04 — Reusable Interfaces​

Where multiple consumers require substantially the same data, reusable governed interfaces SHOULD be preferred over bespoke point-to-point extracts.

DMR-16.05 — Strategic Platforms​

Where HDIP or other approved strategic Data & AI capabilities aligned to the enterprise target architecture satisfy the requirement, initiatives SHOULD prefer them over unnecessary programme-specific equivalents.

DMR-17 — Regulatory and Evidential Data Requirements

Objective​

Ensure that regulatory and evidential data is reproducible, explainable, and auditable.

DMR-17.01 — Regulatory Use Identification​

The initiative MUST identify whether affected data supports a regulatory obligation.

DMR-17.02 — Reproducibility​

Material regulatory outputs MUST be reproducible to the level required by applicable regulation.

DMR-17.03 — Evidential Trace​

Source data, transformations, assumptions, and outputs MUST provide sufficient traceability.

DMR-17.04 — Historical Reconstruction​

Where required, historical states MUST be reconstructable.

DMR-17.05 — Regulatory Change​

Regulatory changes that alter data requirements MUST be reflected through controlled semantic, contract, and product evolution.

DMR-17.06 — Regulatory Control Evidence​

Where regulatory obligations are supported by Data Controls, sufficient control evidence MUST be retained to support assurance and audit.

DMR-18 — Data Architecture Alignment

Objective​

Ensure that programme architecture contributes to, rather than fragments, the enterprise target data architecture.

DMR-18.01 — Enterprise Data Strategy Alignment​

Material data architecture decisions MUST be assessed against Enterprise Data Strategy.

DMR-18.02 — Target Architecture Alignment​

Material initiatives MUST assess alignment with the enterprise target data architecture, GEDRA where adopted as the generic reference architecture, and HDIP where adopted as a GEDRA-aligned strategic Data & AI specialization.

DMR-18.03 — Strategic Capability Reuse​

Existing strategic capabilities SHOULD be reused where they satisfy the requirement.

DMR-18.04 — Duplication of Strategic Capabilities​

Programmes SHOULD NOT independently create capabilities equivalent to strategic enterprise data capabilities without justification.

DMR-18.05 — Cross-Domain Impact​

Material cross-domain impacts MUST be identified.

DMR-18.06 — Local Optimisation​

Programme-level optimisation MUST NOT knowingly introduce material enterprise-level data fragmentation without explicit architectural acceptance.

DMR-18.07 — Target State Contribution​

Material initiatives SHOULD demonstrate whether they:

  • advance the target state;
  • remain neutral to it; or
  • create temporary or strategic divergence.

DMR-19 — AI and Advanced Analytics Consumption

Objective​

Ensure that data used by AI and advanced analytics remains governed throughout its use.

DMR-19.01 — AI Consumption Identification​

The initiative MUST identify where its data is intended for AI, ML, or advanced analytics consumption.

DMR-19.02 — Provenance​

Training, evaluation, grounding, and inference data MUST retain appropriate provenance.

DMR-19.03 — Data Rights​

The organisation MUST have appropriate rights and lawful basis for intended AI use.

DMR-19.04 — Quality Suitability​

Data Quality MUST be assessed against the intended AI use rather than assumed from operational suitability.

DMR-19.05 — AIPS Interaction​

Where the initiative creates or materially changes an AI Product, applicable enterprise AI governance and relevant AIPS requirements MUST be assessed where adopted.

DMR-19.06 — Product Dependencies​

AI Products SHOULD consume governed Data Products where this provides appropriate reliability, semantics, provenance, and lifecycle guarantees.

DMR-20 — Data Controls and Assurance

Objective​

Ensure that material Data Management obligations are supported by explicit, owned, measurable, and evidential controls.

DMR-20.01 — Control Identification​

The initiative MUST identify Data Controls required to satisfy applicable Data Management, regulatory, policy, architecture, and product obligations.

DMR-20.02 — Control Objective​

Each material Data Control MUST have a defined control objective describing the risk or obligation it addresses.

DMR-20.03 — Control Ownership​

Each material Data Control MUST have an accountable control owner.

Ownership MUST remain valid after programme closure.

DMR-20.04 — Control Type​

Material controls SHOULD identify their nature where relevant, such as:

  • preventive;
  • detective;
  • corrective;
  • automated;
  • manual;
  • semi-automated.

DMR-20.05 — Control Operation​

The initiative MUST define how and when each material control operates.

This may include:

  • event-driven;
  • continuous;
  • per transaction;
  • daily;
  • periodic;
  • pre-publication;
  • pre-consumption.

DMR-20.06 — Control Thresholds​

Where a control evaluates measurable conditions, thresholds and tolerances MUST be defined.

DMR-20.07 — Control Evidence​

Material controls MUST generate or retain sufficient Control Evidence to demonstrate operation and outcome. The evidence MUST identify the Data Control it substantiates and, where Control Execution is explicitly modeled, the relevant execution.

DMR-20.08 — Control Failure​

Control failures MUST have defined:

  • detection;
  • notification;
  • escalation;
  • remediation;
  • exception handling.

DMR-20.09 — Automated Controls​

Where reliable automation is reasonably achievable, material controls SHOULD be automated to reduce unnecessary dependence on manual operation. Automation does NOT by itself establish control effectiveness; manual, automated, and semi-automated controls remain subject to design, execution, evidence, ownership, and response expectations.

DMR-20.10 — Control Independence​

Where risk or regulation requires independent assurance, control design MUST support the appropriate separation between:

  • data production;
  • control execution;
  • assurance or review.

DMR-20.11 — Control Traceability​

A material control MUST be traceable to the requirement/reference, Data Policy, risk, contractual obligation, architecture decision, or Product Promise it supports.

DMR-20.12 — Data Product Controls​

Where a Data Product is created or materially changed, appropriate controls MUST support material Product Promise commitments where governed assurance is required.

Examples include:

  • freshness;
  • completeness;
  • schema compatibility;
  • availability;
  • lineage completeness;
  • permitted distribution.

DMR-20.13 — Regulatory Controls​

Where data supports regulatory obligations, controls MUST provide sufficient evidence and reproducibility to satisfy applicable regulatory assurance requirements.

DMR-20.14 — Control Lifecycle​

Controls MUST be reviewed when material changes occur to:

  • source data;
  • semantics;
  • consumers;
  • Product Promises;
  • regulatory requirements;
  • architecture;
  • residency;
  • classification.

DMR-20.15 — Control Retirement​

A control MUST NOT be retired merely because the programme implementing it has closed.

Control retirement must be tied to retirement or replacement of the underlying obligation.

DMR-21 — Architecture Evidence, Exceptions and Governance

Objective​

Ensure that compliance can be demonstrated rather than merely asserted.

DMR-21.01 — Evidence​

The programme MUST provide sufficient evidence to demonstrate satisfaction of applicable Data Management requirements. Requirement/architecture evidence is NOT automatically Control Evidence; where Control Evidence is claimed, it MUST satisfy the control-evidence semantics defined in DMR-20 and GEDRA Governance & Assurance.

DMR-21.02 — Evidence Proportionality​

Evidence requirements SHOULD be proportionate to materiality and risk.

DMR-21.03 — Exceptions​

Where a mandatory requirement cannot be satisfied, an explicit exception MUST be documented.

DMR-21.04 — Exception Content​

An exception MUST include:

  • requirement being breached;
  • reason;
  • impact;
  • risk;
  • compensating controls;
  • owner;
  • duration;
  • remediation plan where applicable.

DMR-21.05 — Time-Bounded Exceptions​

Temporary exceptions MUST have an expiry or review point.

DMR-21.06 — Architecture Evidence​

Material architecture decisions MUST be recorded through the appropriate architecture governance process.

DMR-21.07 — Closure​

Programme closure MUST NOT leave unresolved ownership, governance, lifecycle, control, or architectural obligations without an identified BAU owner.

5. Applicability Assessment​

Before detailed assessment, every material initiative should complete a lightweight applicability questionnaire.

Suggested questions include:

  1. Does the initiative introduce or modify a material data source?
  2. Does it create a new persistent data store?
  3. Does it create a new copy of existing data?
  4. Does it change an authoritative source?
  5. Does it introduce new schemas or material semantic changes?
  6. Does it expose data to new consumers?
  7. Does it introduce a new API, stream, event, file, or other data interface?
  8. Does it introduce or materially change a Data Asset?
  9. Could the resulting Data Asset warrant productization?
  10. Does it affect regulatory data?
  11. Does it move data across jurisdictions?
  12. Does it affect retention or deletion?
  13. Does it introduce or change Critical Data Elements?
  14. Does it affect Data Quality expectations?
  15. Does it affect lineage or metadata?
  16. Does it create dependencies on new upstream data?
  17. Does it affect downstream consumers?
  18. Does it introduce AI or ML consumption?
  19. Does it duplicate an existing strategic enterprise data capability?
  20. Does it create any divergence from Enterprise Data Strategy, target architecture, GEDRA, or HDIP profile requirements where applicable?
  21. Does it introduce or materially change a Data Management control?
  22. Does it create or change data supporting a key business, regulatory, or risk control?
  23. Are existing controls dependent on data being changed by the initiative?
  24. Does the initiative change the source, lineage, timing, semantics, or quality of data used by an existing control?
  25. Does a new or changed Data Product promise require measurable controls?

Responses determine which DMR domains and individual requirements become applicable.

6. Evidence Model​

For every applicable mandatory requirement, the programme must provide sufficient evidence.

Evidence may include:

  • architecture diagrams;
  • data architecture views;
  • design documents;
  • semantic models;
  • ontology mappings;
  • data contracts;
  • schema definitions;
  • catalogue registrations;
  • lineage records;
  • Data Quality rules;
  • Data Control definitions;
  • control execution evidence;
  • retention schedules;
  • residency assessments;
  • access and entitlement models;
  • operational dashboards;
  • product specifications;
  • governance decisions;
  • approved exceptions.

Compliance is demonstrated through evidence, not assertion alone.

7. Assessment Model​

The Enterprise Data Architecture / Data Management function may assess a requirement using statuses such as:

  • Satisfied;
  • Satisfied with Observation;
  • Partially Satisfied;
  • Concern;
  • Exception Required;
  • Not Applicable.

The assessment should focus on the Data Management outcome and architectural risk, not on prescribing unnecessary implementation detail.

8. Exception Model​

Where a mandatory requirement cannot be satisfied, the exception must state:

  • requirement ID;
  • reason;
  • business justification;
  • architectural impact;
  • risk;
  • compensating controls;
  • accountable owner;
  • expiry or review date;
  • target remediation where relevant.

An exception does not remove the underlying requirement.

It records an explicitly accepted divergence from it.

9. Traceability​

Every material initiative should maintain requirement traceability using at least the following structure:

Requirement IDApplicabilitySolution ResponseControl RequiredControl IDControl ObjectiveControl OwnerEvidenceStatusEA Assessment

Control Required may be recorded as:

  • Yes;
  • No;
  • Existing Control;
  • New Control;
  • Control Change Required.

10. Requirement, Metric, Observability and Control Distinction​

A requirement is not itself a control.

A metric is not necessarily a control.

A dashboard is not necessarily a control.

A material Data Control should normally have:

  • a Control Objective;
  • Trigger or Frequency;
  • Defined Expected State;
  • Threshold or Rule;
  • Control Owner;
  • Evidence;
  • Failure / Exception Response.

For example:

Observability

Data completeness = 98.7%

Control

Data completeness MUST remain at or above the agreed threshold. A breach generates a control failure, owner notification, evidence record, and remediation workflow.

11. Architectural Boundary​

The catalogue specifies required enterprise Data Management outcomes.

It does not normally prescribe detailed implementation choices unless an enterprise standard already mandates them.

For example:

Material data flows MUST provide end-to-end lineage.

is a Data Management requirement.

Whereas:

Configure vendor product X using scanner Y every ten minutes.

is normally a solution-design decision.

This boundary preserves programme and Domain Architect accountability while ensuring enterprise Data Management requirements are not treated as optional guidance.

12. Relationship to GEDRM, GEDRA, BPS, UPOS, ProductVerse, HDIP and AIPS​

The detailed catalogue is compatible with the broader semantic, architecture, productization, and Data & AI concepts represented by:

  • GEDRM — generic enterprise data semantic reference model;
  • GEDRA — generic enterprise data reference architecture;
  • BPS — universal product grammar;
  • UPOS — universal productization architecture;
  • ProductVerse — interconnected product relationship model;
  • HDIP — GEDRA-aligned reusable strategic Data & AI architecture specialization;
  • AIPS — AI Product-specific productization and governance requirements.

The catalogue can be adopted independently. GEDRM/GEDRA provide semantic and architectural reference points where adopted; HDIP and AIPS provide stricter profile/product specializations where applicable. None of these replaces the normative Data Management requirements in this catalogue.

13. Governing Principle​

The purpose of the catalogue is not to impose a centralised implementation model. It is to ensure that local programme delivery does not create unmanaged enterprise data risk, semantic fragmentation, unowned data, uncontrolled duplication, ineffective controls, or strategic architecture divergence.