100% found this document useful (1 vote)

124 views514 pages

Data Governance Final v2

The document contains a list of control names and specifications related to data management. There are over 150 individual controls listed across various categories including organizational structure, data management programs, change management, metadata standards, data catalogues, data modeling, data architecture, data quality, data security and privacy, data systems, and data integration. Each control has a unique code and title.

Uploaded by

binhadisuperstore

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLSX, PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

124 views514 pages

Data Governance Final v2

Uploaded by

binhadisuperstore

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLSX, PDF, TXT or read online on Scribd

You are on page 1/ 514

Control Name Control Spec

Org.
DG.1.1
Structure

Org.
DG.1.2
Structure

Org.
DG.1.3
Structure

Org.
DG.1.4
Structure

Org.
DG.1.5
Structure

Org.
DG.1.6
Structure

Org.
DG.1.7
Structure

Org.
DG.2.1
Structure
Org.
DG.2.2
Structure

Org.
DG.2.3
Structure

Org.
DG.2.4
Structure

Org.
DG.2.5
Structure

Org.
DG.2.6
Structure

Org.
DG.2.7
Structure

Org.
DG.2.8
Structure

Org.
DG.2.9
Structure

Org.
DG.2.10
Structure

Org.
DG.2.11
Structure
Org.
DG.2.12
Structure

Org.
DG.2.13
Structure

Org.
DG.2.14
Structure

Org.
DG.2.15
Structure

Org.
DG.2.16
Structure

Data Management Policy DG.2.17

Data Management Programme DG.3.1

Data Management Programme DG.3.2

Data Management Programme DG.3.3

Data Management Programme DG.3.4

Data Management Programme DG.3.5

Data Management Programme DG.3.6

Data Management Programme DG.3.7

Change Management DG.4.1

Change Management DG.4.2

Change Management DG.4.3

Change Management DG.4.4

Change Management DG.4.5

Change Management DG.4.6

Organisational Awareness DG.5.1

Organisational Awareness DG.5.2

Organisational Awareness DG.5.3

Organisational Awareness DG.5.4

Organisational Awareness DG.5.5

Organisational Awareness DG.5.6

Organisational Awareness DG.5.7

Capability Audit DG.6.1

Capability Audit DG.6.2

Capability Audit DG.6.3

Capability Audit DG.6.4

Capability Audit DG.6.5

Capability Audit DG.6.6

Capability Audit DG.6.7

Capability Audit DG.6.8

Capability Audit DG.6.9

Capability Audit DG.6.10

Performance Management DG.7.1

Performance Management DG.7.2

Performance Management DG.7.3

Performance Management DG.7.4

Performance Management DG.7.5

Performance Management DG.7.6

Metadata Standards
MD.1.1
Conformation
Metadata Standards
MD.1.2
Conformation

Metadata Standards
MD.1.3
Conformation
Metadata Standards
MD.1.4
Conformation

MetaData Management
MD.2.1
Programme
MetaData Management
MD.2.2
Programme

MetaData Management
MD.2.3
Programme
MetaData Management
MD.2.4
Programme

MetaData Management
MD.2.5
Programme
MetaData Management
MD.2.6
Programme

MetaData Management
MD.2.7
Programme
Metadata Architecture MD.3.1

Metadata Architecture MD.3.2

Metadata Monitoring MD.4.1

Metadata Monitoring MD.4.2

Metadata Monitoring MD.4.3

Metadata Monitoring MD.4.4

Data Catalogue Requirements DC.1.1

Data Catalogue Requirements DC.1.2

Data Catalogue Requirements DC.1.3

Data Catalogue Requirements DC.1.4

Data Catalogue Principles DC.2.1

Data Catalogue Principles DC.2.2

Data Catalogue Population DC.3.1

Data Catalogue Population DC.3.2

Data Catalogue Population DC.3.3

Data Catalogue Population DC.3.4

Data Catalogue Population DC.3.5

Data Catalogue Population DC.3.6

Data Catalogue Population DC.3.7

Data Catalogue Population DC.3.8

Data Catalogue Population DC.3.9

Data Catalogue Usage DC.4.1

Data Catalogue Usage DC.4.2

Data Catalogue Usage DC.4.3

Data Catalogue Usage DC.4.4

Data Catalogue Usage DC.4.5

Data Catalogue Usage DC.4.6

Data Catalogue Usage DC.4.7

Implement Tools and Methods DM.1.1

Implement Tools and Methods DM.1.2

Implement Tools and Methods DM.1.3

Implement Tools and Methods DM.1.4

Unstructured Data DM.10.1

Unstructured Data DM.10.2

Unstructured Data DM.10.3

Unstructured Data DM.10.4

Unstructured Data DM.10.5

Unstructured Data DM.10.6

Modelling Artefacts DM.2.1

Modelling Artefacts DM.2.10

Modelling Artefacts DM.2.11

Modelling Artefacts DM.2.12

Modelling Artefacts DM.2.2

Modelling Artefacts DM.2.3

Modelling Artefacts DM.2.4

Modelling Artefacts DM.2.5

Modelling Artefacts DM.2.6

Modelling Artefacts DM.2.7

Modelling Artefacts DM.2.8

Modelling Artefacts DM.2.9

Business Glossary and Data
DM.3.1
Dictionary

Business Glossary and Data

DM.3.2
Dictionary

Data Model Metadata DM.4.1

Data Model Metadata DM.4.2

Data Model Metadata DM.4.3

Data Model Metadata DM.4.4

Enterprise Data Model DM.5.1

Enterprise Data Model DM.5.2

Enterprise Data Model DM.5.3

Enterprise Data Model DM.5.4

Conceptual Data Models DM.6.1

Conceptual Data Models DM.6.2

Conceptual Data Models DM.6.3

Conceptual Data Models DM.6.4

Master Profiles DM.7.1

Master Profiles DM.7.2

Master Profiles DM.7.3

Master Profiles DM.7.4

Logical Data Model DM.8.1

Logical Data Model DM.8.2

Logical Data Model DM.8.3

Logical Data Model DM.8.4

Physical Data Model DM.9.1

Physical Data Model DM.9.2

Physical Data Model DM.9.3

Physical Data Model DM.9.4

Arch Methodology DA.1.1

Arch Methodology DA.1.2

Arch Methodology DA.1.3

Arch Methodology DA.1.4

Arch Methodology DA.1.5

Baseline Data Arch DA.2.1

Baseline Data Arch DA.2.2

Baseline Data Arch DA.2.3

Baseline Data Arch DA2.4

Target DA DA.3.1

Target DA DA.3.2

Target DA DA.3.3
Target DA DA.3.4

DA Roadmap DA.4.1

DA Roadmap DA.4.2

DA Roadmap DA.4.3

DA Roadmap DA.4.4

Data Quality Plan DQ.1.1

Data Quality Plan DQ.1.2

Data Quality Plan DQ.1.3

Data Quality Plan DQ.1.4

Data Quality Plan DQ.1.5

Data Quality Plan DQ.1.6

Data Quality Plan DQ.1.7

Data Quality Plan DQ.1.8

Data Quality Audit DQ.2.1

Data Quality Audit DQ.2.2

Data Quality Audit DQ.2.3

Data Quality Audit DQ.2.4

Data Quality Audit DQ.2.5

Data Quality Uplift DQ.3.1

Data Quality Uplift DQ.3.2

Data Quality Uplift DQ.3.3

Information Security
DSP.1.1
Standards

Information Security
DSP.1.2
Standards

Information Security
DSP.1.3
Standards

Information Security
DSP.1.4
Standards

Information Security
DSP.1.5
Standards

Information Security
DSP.1.6
Standards
Data Privacy Policy DSP.2.1

Data Privacy Policy DSP.2.2

Data Privacy Policy DSP.2.3

Data Privacy Policy DSP.2.4

Data Privacy Policy DSP.2.5

Data Privacy Policy DSP.2.6

Data Privacy Policy DSP.2.7

Privacy By Design DSP.3.1

Privacy By Design DSP.3.2

Privacy By Design DSP.3.3

Privacy By Design DSP.3.4

Privacy Management DSP.4.1

Privacy Management DSP.4.2

Privacy Management DSP.4.3

Privacy Management DSP.4.4

Data System Protection DSP.5.1

Data System Protection DSP.5.2

Baseline DS Arch DS1.1

Baseline DS Arch DS1.2

Baseline DS Arch DS1.3

Baseline DS Arch DS1.4

Baseline DS Arch DS1.5

Baseline DS Arch DS1.6

Baseline DS Arch DS1.7

Baseline DS Arch DS1.8

Target DS arch DS.2.1

Target DS arch DS.2.2

Target DS arch DS.2.3

Target DS arch DS.2.4

Target DS arch DS.2.5

Target DS arch DS.2.6

Target DS arch DS.2.7

Target DS arch DS.2.8

DS Roadmap DS.3.1

DS Roadmap DS.3.2

DS Roadmap implementation DS.4.1

DS Roadmap implementation DS.4.2

DS Roadmap implementation DS.4.3

DS Roadmap implementation DS.4.4

DS Roadmap implementation DS.4.5

Data Backup and Recovery DS.5.1

Data Backup and Recovery DS.5.2

Data Backup and Recovery DS.5.3

Data Backup and Recovery DS.5.4

Data Backup and Recovery DS.5.5

Disaster Recovery and Business

Continuity DS.6.1

Disaster Recovery and Business DS.6.2

Continuity
Disaster Recovery and Business DS.6.3
Continuity

Data Lifecycle DS.7.1

Data Lifecycle DS.7.2

Data Lifecycle DS.7.3

Data Lifecycle DS.7.4

Data Lifecycle DS.7.5

Strategic Integration Platform DIO 1.1

Strategic Integration Platform DIO 1.2

Strategic Integration Platform DIO 1.3

Strategic Integration Platform DIO 1.4

Strategic Integration Platform DIO 1.5

Strategic Integration Platform DIO 1.6

Integration Architecture DIO 2.1

Integration Architecture DIO 2.2

Integration Architecture DIO 2.3

Integration Architecture DIO 2.4

Integration Architecture DIO 2.5

Integration Patterns DIO 3.1

Integration Patterns DIO 3.2

Integration Patterns DIO 3.3

Service Level Agreements DIO 4.1

Service Level Agreements DIO 4.2

Service Level Agreements DIO 4.3

Open Data Identification OD.1.1

Open Data Identification OD.1.2

Open Data Identification OD.1.3

Open Data Identification OD.1.4

Open Data Publishing Plan OD.2.1

Open Data Publishing Plan OD.2.2

Open Data Publishing Plan OD.2.3

Open Data Publishing Plan OD.2.4

Open Data Publishing OD.3.1

Open Data Publishing OD.3.2

Open Data Publishing OD.3.3

Open Data Publishing OD.3.4

Open Data Awareness OD.4.1

Open Data Awareness OD.4.2

Reference Data Management RM.1.1

Plan

Reference Data Management RM.1.2

Plan

Identify Reference Data RM.2.1

Identify Reference Data RM.2.2

Identify Reference Data RM.2.3

Identify Reference Data RM.2.4

Identify Reference Data RM.2.5

Identify Reference Data RM.2.6

Reference Data Change RM.3.1

Management
Reference Data Change RM.3.2
Management

Reference Data Change RM.3.3

Management

Reference Data Change RM.3.4

Management

Reference Data Platform RM.4.1

Reference Data Platform RM.4.2

Reference Data Platform RM.4.3

Master Data Management Plan RM.5.1

Master Data Management Plan RM.5.2

Identify Master Data RM.6.1

Identify Master Data RM.6.2

Identify Master Data RM.6.3

Identify Master Data RM.6.4

Operate Master Data RM.7.1

Operate Master Data RM.7.2

Operate Master Data RM.7.3

Operate Master Data RM.7.4

Operate Master Data RM.7.5

Operate Master Data RM.7.6

Operate Master Data RM.7.7

Data Marts DWBA.4.3

Data Marts DWBA.4.4

Operational Data Stores DWBA.5.1

Operational Data Stores DWBA.5.2

Operational Data Stores DWBA.5.3

Business Intelligence DWBA.6.1

Business Intelligence DWBA.6.2

Business Intelligence DWBA.6.3

Business Intelligence DWBA.6.4

Business Intelligence DWBA.6.5

Business Intelligence DWBA.6.6

Analytics and Big Data DWBA.7.1

Analytics and Big Data DWBA.7.2

Analytics and Big Data DWBA.7.3

Organisational Structure DG.1.1

Organisational Structure DG.1.2

Organisational Structure DG.1.3

Organisational Structure DG.1.4

Organisational Structure DG.1.5

Organisational Structure DG.1.6

Organisational Structure DG.1.7

Data Management Policy DG.2.1

Data Management Policy DG.2.2

Data Management Policy DG.2.3

Data Management Policy DG.2.4

Data Management Policy DG.2.5

Data Management Policy DG.2.6

Data Management Policy DG.2.7

Data Management Policy DG.2.8

Data Management Policy DG.2.9

Data Management Policy DG.2.10

Data Management Policy DG.2.11

Data Management Policy DG.2.12

Data Management Policy DG.2.13

Data Management Policy DG.2.14

Data Management Policy DG.2.15

Data Management Policy DG.2.16

Data Management Policy DG.2.17

Data Management Programme DG.3.1

Data Management Programme DG.3.2

Data Management Programme DG.3.3

Data Management Programme DG.3.4

Data Management Programme DG.3.5

Data Management Programme DG.3.6

Data Management Programme DG.3.7

Change Management DG.4.1

Change Management DG.4.2

Change Management DG.4.3

Change Management DG.4.4

Change Management DG.4.5

Change Management DG.4.6

Organisational Awareness DG.5.1

Organisational Awareness DG.5.2

Organisational Awareness DG.5.3

Organisational Awareness DG.5.4

Organisational Awareness DG.5.5

Organisational Awareness DG.5.6

Organisational Awareness DG.5.7

Capability Audit DG.6.1

Capability Audit DG.6.2

Capability Audit DG.6.3

Capability Audit DG.6.4

Capability Audit DG.6.5

Capability Audit DG.6.6

Capability Audit DG.6.7

Capability Audit DG.6.8

Capability Audit DG.6.9

Capability Audit DG.6.10

Performance Management DG.7.1

Performance Management DG.7.2

Performance Management DG.7.3

Performance Management DG.7.4

Performance Management DG.7.5

Performance Management DG.7.6

Metadata Standards
MD.1.1
Conformation
Metadata Standards
MD.1.2
Conformation

Metadata Standards
MD.1.3
Conformation
Metadata Standards
MD.1.4
Conformation

MetaData Management
MD.2.1
Programme
MetaData Management
MD.2.2
Programme

MetaData Management
MD.2.3
Programme
MetaData Management
MD.2.4
Programme

MetaData Management
MD.2.5
Programme
MetaData Management
MD.2.6
Programme

MetaData Management
MD.2.7
Programme
Metadata Architecture MD.3.1

Metadata Architecture MD.3.2

Metadata Monitoring MD.4.1

Metadata Monitoring MD.4.2

Metadata Monitoring MD.4.3

Metadata Monitoring MD.4.4

Data Catalogue Requirements DC.1.1

Data Catalogue Requirements DC.1.2

Data Catalogue Requirements DC.1.3

Data Catalogue Requirements DC.1.4

Data Catalogue Principles DC.2.1

Data Catalogue Principles DC.2.2

Data Catalogue Population DC.3.1

Data Catalogue Population DC.3.2

Data Catalogue Population DC.3.3

Data Catalogue Population DC.3.4

Data Catalogue Population DC.3.5

Data Catalogue Population DC.3.6

Data Catalogue Population DC.3.7

Data Catalogue Population DC.3.8

Data Catalogue Population DC.3.9

Data Catalogue Usage DC.4.1

Data Catalogue Usage DC.4.2

Data Catalogue Usage DC.4.3

Data Catalogue Usage DC.4.4

Data Catalogue Usage DC.4.5

Data Catalogue Usage DC.4.6

Data Catalogue Usage DC.4.7

Implement Tools and Methods DM.1.1

Implement Tools and Methods DM.1.2

Implement Tools and Methods DM.1.3

Implement Tools and Methods DM.1.4

Unstructured Data DM.10.1

Unstructured Data DM.10.2

Unstructured Data DM.10.3

Unstructured Data DM.10.4

Unstructured Data DM.10.5

Unstructured Data DM.10.6

Modelling Artefacts DM.2.1

Modelling Artefacts DM.2.10

Modelling Artefacts DM.2.11

Modelling Artefacts DM.2.12

Modelling Artefacts DM.2.2

Modelling Artefacts DM.2.3

Modelling Artefacts DM.2.4

Modelling Artefacts DM.2.5

Modelling Artefacts DM.2.6

Modelling Artefacts DM.2.7

Modelling Artefacts DM.2.8

Modelling Artefacts DM.2.9

Business Glossary and Data
DM.3.1
Dictionary

Business Glossary and Data

DM.3.2
Dictionary

Data Model Metadata DM.4.1

Data Model Metadata DM.4.2

Data Model Metadata DM.4.3

Data Model Metadata DM.4.4

Enterprise Data Model DM.5.1

Enterprise Data Model DM.5.2

Enterprise Data Model DM.5.3

Enterprise Data Model DM.5.4

Conceptual Data Models DM.6.1

Conceptual Data Models DM.6.2

Conceptual Data Models DM.6.3

Conceptual Data Models DM.6.4

Master Profiles DM.7.1

Master Profiles DM.7.2

Master Profiles DM.7.3

Master Profiles DM.7.4

Logical Data Model DM.8.1

Logical Data Model DM.8.2

Logical Data Model DM.8.3

Logical Data Model DM.8.4

Physical Data Model DM.9.1

Physical Data Model DM.9.2

Physical Data Model DM.9.3

Physical Data Model DM.9.4

Arch Methodology DA.1.1

Arch Methodology DA.1.2

Arch Methodology DA.1.3

Arch Methodology DA.1.4

Arch Methodology DA.1.5

Baseline Data Arch DA.2.1

Baseline Data Arch DA.2.2

Baseline Data Arch DA.2.3

Baseline Data Arch DA2.4

Target DA DA.3.1

Target DA DA.3.2

Target DA DA.3.3
Target DA DA.3.4

DA Roadmap DA.4.1

DA Roadmap DA.4.2

DA Roadmap DA.4.3

DA Roadmap DA.4.4

Data Quality Plan DQ.1.1

Data Quality Plan DQ.1.2

Data Quality Plan DQ.1.3

Data Quality Plan DQ.1.4

Data Quality Plan DQ.1.5

Data Quality Plan DQ.1.6

Data Quality Plan DQ.1.7

Data Quality Plan DQ.1.8

Data Quality Audit DQ.2.1

Data Quality Audit DQ.2.2

Data Quality Audit DQ.2.3

Data Quality Audit DQ.2.4

Data Quality Audit DQ.2.5

Data Quality Uplift DQ.3.1

Data Quality Uplift DQ.3.2

Data Quality Uplift DQ.3.3

Information Security
DSP.1.1
Standards

Information Security
DSP.1.2
Standards

Information Security
DSP.1.3
Standards

Information Security
DSP.1.4
Standards
Information Security
DSP.1.5
Standards
Information Security
DSP.1.6
Standards
Data Privacy Policy DSP.2.1

Data Privacy Policy DSP.2.2

Data Privacy Policy DSP.2.3

Data Privacy Policy DSP.2.4

Data Privacy Policy DSP.2.5

Data Privacy Policy DSP.2.6

Data Privacy Policy DSP.2.7

Privacy By Design DSP.3.1

Privacy By Design DSP.3.2

Privacy By Design DSP.3.3

Privacy By Design DSP.3.4

Privacy Management DSP.4.1

Privacy Management DSP.4.2

Privacy Management DSP.4.3
Privacy Management DSP.4.4

Data System Protection DSP.5.1

Data System Protection DSP.5.2

Baseline DS Arch DS1.1

Baseline DS Arch DS1.2

Baseline DS Arch DS1.3

Baseline DS Arch DS1.4

Baseline DS Arch DS1.5

Baseline DS Arch DS1.6

Baseline DS Arch DS1.7

Baseline DS Arch DS1.8

Target DS arch DS.2.1

Target DS arch DS.2.2

Target DS arch DS.2.3

Target DS arch DS.2.4

Target DS arch DS.2.5

Target DS arch DS.2.6

Target DS arch DS.2.7

Target DS arch DS.2.8

DS Roadmap DS.3.1

DS Roadmap DS.3.2

DS Roadmap implementation DS.4.1

DS Roadmap implementation DS.4.2

DS Roadmap implementation DS.4.3

DS Roadmap implementation DS.4.4

DS Roadmap implementation DS.4.5

Data Backup and Recovery DS.5.1

Data Backup and Recovery DS.5.2

Data Backup and Recovery DS.5.3

Data Backup and Recovery DS.5.4

Data Backup and Recovery DS.5.5

Disaster Recovery and

DS.6.1
Business Continuity

Disaster Recovery and

DS.6.2
Business Continuity

Disaster Recovery and

DS.6.3
Business Continuity

Data Lifecycle DS.7.1

Data Lifecycle DS.7.2

Data Lifecycle DS.7.3

Data Lifecycle DS.7.4

Data Lifecycle DS.7.5

Strategic Integration Platform DIO 1.1

Strategic Integration Platform DIO 1.2

Strategic Integration Platform DIO 1.3

Strategic Integration Platform DIO 1.4

Strategic Integration Platform DIO 1.5

Strategic Integration Platform DIO 1.6

Integration Architecture DIO 2.1

Integration Architecture DIO 2.2

Integration Architecture DIO 2.3

Integration Architecture DIO 2.4

Integration Architecture DIO 2.5

Integration Patterns DIO 3.1

Integration Patterns DIO 3.2

Integration Patterns DIO 3.3

Service Level Agreements DIO 4.1

Service Level Agreements DIO 4.2

Service Level Agreements DIO 4.3

Open Data Identification OD.1.1

Open Data Identification OD.1.2

Open Data Identification OD.1.3

Open Data Identification OD.1.4

Open Data Publishing Plan OD.2.1

Open Data Publishing Plan OD.2.2

Open Data Publishing Plan OD.2.3

Open Data Publishing Plan OD.2.4

Open Data Publishing OD.3.1

Open Data Publishing OD.3.2

Open Data Publishing OD.3.3

Open Data Publishing OD.3.4

Open Data Awareness OD.4.1

Open Data Awareness OD.4.2

Reference Data Management

RM.1.1
Plan

Reference Data Management

RM.1.2
Plan

Identify Reference Data RM.2.1

Identify Reference Data RM.2.2

Identify Reference Data RM.2.3

Identify Reference Data RM.2.4

Identify Reference Data RM.2.5

RM.5.1
Plan

Master Data Management

RM.5.2
Plan

Identify Master Data RM.6.1

Identify Master Data RM.6.2

Identify Master Data RM.6.3

Identify Master Data RM.6.4

Operate Master Data RM.7.1

Operate Master Data RM.7.2

Operate Master Data RM.7.3

Operate Master Data RM.7.4

Operate Master Data RM.7.5

Operate Master Data RM.7.6

Operate Master Data RM.7.7

Operate Master Data RM.7.8

Operate Master Data RM.7.9

Master Data Change

RM.8.1
Management

Master Data Change

RM.8.2
Management

Master Data Change

RM.8.3
Management
Master Data Change
RM.8.4
Management

Master Data Platform RM.9.1

Master Data Platform RM.9.2

Data Marts DWBA.4.3

Data Marts DWBA.4.4

Operational Data Stores DWBA.5.1

Operational Data Stores DWBA.5.2

Operational Data Stores DWBA.5.3

Business Intelligence DWBA.6.1

Business Intelligence DWBA.6.2

Business Intelligence DWBA.6.3

Business Intelligence DWBA.6.4

Business Intelligence DWBA.6.5

Business Intelligence DWBA.6.6

Analytics and Big Data DWBA.7.1

Analytics and Big Data DWBA.7.2

Analytics and Big Data DWBA.7.3
Definition

The Entity shall establish an organizational structure to support the Data Management Programme.

The Entity shall convene the Data Governance Board to manage delegated authority and responsibility within the Entity. The Board
will be the final arbiter within the Entity for all matters relating to data management.

The Entity shall appoint a Data Manager.

The Data Manager shall have delegated authority from the Data Governance Board.

The Entity shall identify and appoint Data Architects to support the Data Manager.

The Entity shall identify and appoint Data Stewards to support the Data Manager in both the business and technical areas of the
organisation.

The Entity shall identify and appoint Data Owners (who are responsible for a particular dataset) to support the Data Stewards. Data
Owners will be drawn from both the business and technical areas of the organisation.

The Entity shall regularly undertake monitoring and compliance checking to ensure that information systems and data related
processes are implemented in accordance with established policy, standards and best practices.

The Entity’s Data Management Policy shall address the scope of its data management systems, roles, responsibilities, management
commitment, coordination among organisational functions, and compliance obligations.
The policy shall contain a definition of data management; its overall objectives and scope, and the importance of data management as
a pillar of upholding high standards of data quality.

The policy shall contain a definition of data management; its overall objectives and scope, and the importance of data management as
a pillar of upholding high standards of data quality.

The policy shall be applicable to all business functions of the organisation and should be supplemented by supporting instructions and
guidance where appropriate for specific areas of activity.

The Entity shall establish its Data Management Policy (through implementing this control), describing how data will be managed
across the Entity.

In support of the Data Management Policy, the Entity shall establish policies for public consumption where there are external
stakeholders.

The policy shall cover the end-to-end data management lifecycle.

The policy should clearly express management's commitment to data management principles and highlight its alignment with
government strategy.

The policy should emphasize management expectations for data handling and the importance of maintaining high data quality
throughout the organization.

The Entity must include governance metrics and process checkpoints in their policy to measure ongoing data management
effectiveness in their systems and processes.

The policy should outline a system for users to report data issues and include an escalation plan for their resolution.
The policy must detail the change management process, specifically how it relates to the Data Management Program and its
initiatives.

The policy will undergo at least annual reviews, overseen by the Data Management Board to maintain its relevance and effectiveness.
More frequent reviews may be needed in response to major business or regulatory changes.

The Entity shall ensure that all policy developments are aligned with all relevant legislation.

The Entity shall collect and maintain evidence of compliance with their policies, and with the Control Specifications within these
standards.

The policy must be quantifiable and tied to the Control Standards in this document, with the Entity able to show how each control
supports a specific policy requirement.

The Entity must collect written confirmations from all personnel and stakeholders, including internal and external parties and
contractors, demonstrating their understanding and commitment to adhere to the Policy, with these signed records kept on file for
future reference.

The Entity is required to establish and maintain specific, measurable, and scheduled goals as part of its Data Management
Programme. These goals should align with the Entity's business strategy, risk management, compliance with data management
policies and legal requirements, and the promotion of a data-aware organizational culture.

The Plan shall be made available to ADSIC (ADDA) for review.

The Plan should outline data management initiatives, align with the Entity's strategic plan, undergo annual reviews, include key
performance indicators, and indicate budget requirements for planned initiatives.

The Entity must specify robust version control for all Data Management Programme documents in the plan.

The Entity's Data Management Programme must be approved by the accountable executive responsible for the associated
operational risks.

To support its Data Management Programme, the Entity will develop subsidiary plans for specific capabilities, like Data Governance,
Organizational Awareness and Training, Disaster Recovery, Document and Content Management, Data Architecture Management,
Inter-Entity Data Integration, and Reference and Master Data Management. These plans can either stand alone or be included as
appendices in the Entity's Data Management Programme Plan.

The Entity must follow the Government Data Management Model's principles and structure (Owned, Described, Quality, Access,
Implemented) in its Data Management Programme. These principles should be incorporated into subsidiary plans and integrated into
the business processes implemented throughout the Data Management Programme rollout

The Entity’s Data Governance Board should approve all changes to the Data Management Programme (e.g. Plan or Policy)

The Entity shall integrate its existing change management processes into each of the data management domains, or create a new
change management process if none already exists.

The Entity should establish a baseline for its Data Management Programme Plan, with proposed changes to the plan being analysed
for impact

Changes to the Data Management Programme Plan should be coordinated with the organisation-wide Change Management
capabilities of the Entity to ensure on-going alignment between Data Management and other organisation initiatives

When these Standards necessitate changes to existing business processes, the Entity should conduct an impact assessment to identify
stakeholders and processes affected, ensuring coordinated communication of the change.
The Entity shall develop and maintain its change management processes for the Data Management Programme as a whole, and
domain-level processes developed within the Data Management Programme

The Entity shall develop and execute organisation-wide awareness programmes for the required data domains

The Entity shall perform an audit of its capabilities and/or current state for each data domain
The Entity shall perform an audit of its capabilities and/or current state for each data domain

The Entity shall perform an audit of its capabilities and/or current state for each data domain

The Entity shall perform an audit of its capabilities and/or current state for each data domain
The Entity shall perform an audit of its capabilities and/or current state for each data domain

The Entity shall perform an audit of its capabilities and/or current state for each data domain

The Entity shall perform an audit of its capabilities and/or current state for each data domain
The Entity shall develop, report against and analyse key performance indicators relating to its Data Management Programme

The Entity shall develop, report against and analyse key performance indicators relating to its Data Management Programme

The Entity shall develop, report against and analyse key performance indicators relating to its Data Management Programme
Data Management performance data shall be verified by a competent and independent party that is not directly connected with the
work that is the subject of measurement

Data management performance reporting will evaluate technology and business process compliance, data
architecture maintenance, data model completeness, system-level data models, master profiles, data quality
milestones, master/reference data management achievements, and information/document lifecycles.

Performance data will influence continuing changes, which the Data Governance Board will assess for cost,
benefit, and status.

The Entity will follow Abu Dhabi Government Metadata Standards, including eGIF, SCAD, and geographical
metadata.
The Entity must follow Abu Dhabi Government Metadata Standards for eGIF, SCAD, and GIS.

The Entity must follow ISO/IEC:11179 Part 4 for precise data definitions in its business glossary, data dictionary,
and other data management domains.
The Entity must adopt ISO/IEC:11179 Part 5 for naming and identification principles to provide meaningful
names and IDs (e.g., Emirates ID) for persons or certain data contexts.

The Entity is going to launch a metadata programme that includes metadata assessment, stakeholder interviews,
requirement collecting, metadata architecture development, data stewardship, and a metadata management
implementation strategy.
To customise metadata for its operations, the Entity will employ Abu Dhabi government and international
standards including eGIF, SCAD, Geospatial, and ADMS. Abu Dhabi Government eGIF Metadata Standard-
compliant metadata items, improvements, and encoding methods will be included.

The Entity will employ information manually and automatically. According to the program's timeline, automated
scanning and proprietary techniques will ensure metadata correctness. To ensure metadata quality, Data Stewards
will manage recorded information and add business and technical metadata (Ref: MD.4.4).
The Data Governance Board will settle metadata definition and quality disputes not resolved by Data Stewards,
particularly where information spans departments.

Through the Data Catalogue, the Entity must make all metadata, data dictionary, business vocabulary, and
modelling and architectural deliverables available to users.
Based on user role, the Data Catalogue will index, search, and retrieve metadata.

Metadata values will indicate the capture version for Elements, Refinements, and Encoding Schemes, which the
Entity will version manage.
The Enterprise Data Architecture will include the Entity's metadata architecture, which must be documented per
DA Standards.

The Entity shall evaluate metadata architecture choices for central standard compliance and present arguments to
the Data Governance Board. A single repository, decentralised components with a single access point, or hybrid
components with central metadata management are possible.
Based on Data Quality standards, the Entity will construct metadata name and definition quality measurements,
maybe utilising subjective business experience, user surveys, and other techniques to assess metadata collection,
discovery, and utilisation.

The Entity will monitor and report on metadata quality based on established measurements. .
The Entity will assess metadata coverage across its business functions, including metadata definition, capture, and
usage coverage, with a focus on cross-business function metadata.

The Entity will align its Data Catalog with mandatory standards to enable interoperability. Mandatory standards include
Abu Dhabi Government eGIF Schema Generation, DCAT (Data Catalog Vocabulary), and XSD (XML Schema
Definition) for dataset structure description.

The Entity should align its Data Catalog with recommended standards like ADMS for asset description and RDF for
semantic relationships. In cases where alignment is not possible due to vendor limitations, the Entity must document
and justify the non-alignment to the Data Governance Board.

The Entity is required to create a Data Catalog with key features, including a metadata repository, a publishing portal
for controlled access, a workflow management tool, a business glossary, a data dictionary, a data model repository,
and version control.
The Entity will align its data catalog requirements with emerging government-wide standards.

The Entity shall develop its Data Catalog according to principles like usability, common usage, representation,
accuracy, sufficiency, economy, consistency, and integration. Alignment will be demonstrated through the Governance
Checkpoint Process, with conflicts resolved through practical solutions approved by the Data Governance Board.

The Data Catalog will serve as a central access point for all users, both internal and external, seeking information
about the Entity's data assets, even though these assets are stored in various systems. It will offer a unified resource
for finding and understanding any data asset.

The Entity will select datasets for the Data Catalog, including transactional, reference, master data, statistical, and
geospatial datasets. Factors like user numbers, reusability, and data complexity will be considered.

The Entity should create semantic data models for captured data, defining data relationships with a machine-readable
vocabulary.

The Entity shall define metadata for data capture, following metadata standards and emphasizing reusability. This
includes elements like Elements, Refinements, Encoding Schemes, standard names, and definitions. Compliance with
Abu Dhabi Government eGIF and other relevant domain standards' metadata requirements will be part of the Data
Catalog Population Roadmap.

The Entity will document the approach for capturing and populating metadata in the Data Catalog, with details for each
dataset in the Data Catalog Population Roadmap. Metadata will cover ownership, security classification, data quality,
validity periods, and version information.

The Entity will maintain metadata in the Data Catalog using the Governance Checkpoint Process. Additionally, the
Data Catalog Population Roadmap will define minimum metadata refresh periods for each dataset captured.

The Entity will categorize data assets within a hierarchy as follows: Metadata, Reference Data, Master Data,
Transactional Data, and Audit and Log Data. Data classes higher in the hierarchy are more critical, as lower-class
data relies on them. Higher-level data is relatively stable and has a longer lifespan, whereas lower-level data is more
dynamic and has a shorter useful life. The volume of data decreases as you move up the hierarchy, with the lower
classes having more data that is subject to frequent changes.
The Entity will create and publish a data sharing licensing model accessible via the data catalog.

The Entity will run an awareness program to promote Data Catalog information to stakeholders, emphasizing data
reuse benefits and available datasets.

Data reuse considerations will be integrated into the System Development Lifecycle (SDLC) of information systems,
with monitoring through the Governance Checkpoint Process for Data Governance Board approval.

The Entity will encourage innovative data use submissions from various functions, evaluated by the Data Governance
Board for merit and promoted by the Data Manager resulting from Data Catalog usage.

The Entity will allow dataset consumers to register their data usage in the Data Catalog, ensuring they are informed of
dataset changes. Consumers can be individuals, application system representatives, or business function
representatives.

Registered consumers of datasets will be classified as Formal or Informal. Formal consumers have service level
agreements with data producers, while Informal consumers rely on published licenses and policies.

The Entity will monitor and report on Data Catalog effectiveness using metrics such as dataset coverage, registered
consumers, and metadata completeness. An annual report on data coverage effectiveness will be presented to the
Data Governance Board.

The Entity will ensure that Data Governance Board reviews data models in the software development lifecycle as part
of the Governance Checkpoint Process. Data models are crucial deliverables for systems built, purchased, or
commissioned to support business and technology needs.

The Entity will implement data modeling tools with specific capabilities, including UML2.x-compliant models, support
for UML model interchange using the XMI Interchange Format, modeling of structured and unstructured datasets,
Common Warehouse Metamodel (CWM) support for data warehouse systems, metadata association for reusability,
and model versioning with traceability. Existing toolsets will be certified to meet these requirements, or the Entity will
initiate an effort to fill any gaps.
The Entity will provide training and education programs for developing data models to enhance awareness and value
for both business and technical users, tailored to their engagement levels with information systems.

The Entity will develop data models at conceptual, logical, and physical levels, involving input from various
stakeholders. The journey to document the as-is data model typically includes creating conceptual data models,
logical data models, and physical data models to represent the high-level ideas, system-independent views, and
system-specific implementations of data structures, respectively. Enterprise modeling will emphasize steps 1 and 2,
while information system modeling will focus on steps 2 and 3.

The Entity shall model unstructured data that is associated with structured data based on business terms and logical
concepts. This modeling can involve capturing concepts expressed in documents linked to records, such as medical
or education reports.

Semi-structured or unstructured data, including free text, images, audio, and video, must be modeled to document the
mandatory requirements, metadata describing concepts within unstructured data, and associated structured identifying
data. For instance, modeling may entail specifying requirements for citizen ID photos, including image characteristics
and associated structured data like Emirates ID and date.

The Entity will employ conversion techniques to transform semi-structured and unstructured data into structured
formats, allowing for the formal documentation and modeling of such data.
When converting unstructured data into structured forms, the Entity will align its processes with the Unstructured
Information Management Architecture (UIMA), enabling analysis of unstructured artifacts and the development and
modeling of artifact metadata. Governance of unstructured content lifecycles will be established through suitable
workflows (refer to DCM.2).

The Entity shall create Data Flow Diagrams and Entity Relationship Diagrams for unstructured data. Data Flow
Diagrams will illustrate the flow of unstructured information, along with associated metadata and identifying data,
between systems. Entity Relationship Diagrams will depict relationships between unstructured information concepts
and structured identifying data, as well as relationships between different unstructured information concepts.

The Entity will develop data models at the Conceptual, Logical, and Physical levels with interconnections to enable the
mapping of physical information systems to logical models and higher conceptual understanding. These data modeling
artifacts will be integral to the Entity's mandatory system design and architecture documentation.

Data modeling artifacts, including Entity Relationship Diagrams and Data Flow Diagrams, will be produced uniformly
for both structured and unstructured data.
The Entity will make data models available for reference and re-use within the organization. Data Architects will
evaluate pre-existing data models, align or re-use them for new information systems where feasible. Any exceptions to
this practice will require justification in the system design, with approval from the Data Governance Board.

UML diagrams will serve as the primary modeling notation throughout the software development lifecycle. Any
deviations from this standard will be documented and submitted for authorization by the Data Governance Board. The
primary use of UML diagrams will involve structural diagrams, including Class Diagrams, Entity Relationship
Diagrams, Component Diagrams, and Deployment Diagrams.

To enhance communication of data model concepts with business stakeholders, the Entity will employ tools better
suited for this purpose, such as text-based documents, presentation slides, and spreadsheets. The Data Governance
Board will contribute to the development of guidance to ensure effective communication with departments and
stakeholders.

Entity-Relationship diagrams and Class Diagrams will be used to document data object structure and relationships
across conceptual, logical, and physical levels.

Data Flow Diagrams will be employed to model data movement within and between systems, with a particular focus
on data forming part of the Entity's master profiles. This includes identifying and capturing points of data capture,
actions that transform or aggregate data, data export points (automatic or manual), and service endpoints emitting
master and common profiles.
In the case of very large models that can be challenging to read (e.g., models with over 200 tables or descriptive
artifacts), they should be subdivided into smaller, subject area-based models and aggregated into higher-level models
to maintain clarity. The primary purpose of data models is to aid understanding.

Data models will provide clear differentiation between aspects that are currently implemented and those that are not
yet implemented.

Data modeling artifacts shall form an integral part of the Entity's mandatory system design and architecture
documentation.

When designing new conceptual data models, the Entity shall ensure that data objects are represented by nouns, and
data relationships are represented by verbs.

For new logical data models, the Entity shall adhere to rules that include using appropriate data types for attributes
within tables, taking into account performance, storage, and data requirements. For instance, the Entity should
consider more suitable data types before using String or other variable character data types.
When designing new physical data models, the Entity shall follow specific rules, including using numeric primary keys
and employing numeric primary keys in reference data tables. Reference data tables will have, at a minimum, a
numeric primary key and a code value represented as a string. Physical data types with length or precision specifiers
should have appropriate lengths or precisions specified and not rely on default values.

The data model should indicate master/slave/federation rules when the Entity identifies data duplication across the
organization or when datasets owned by another Entity are used by an information system. These rules determine
how the datasets are managed, identifying which datasets are master, slave, or federated across systems.

Business terms for data objects, attributes, relationships, and values with contextual business meaning shall be
captured and defined. Business definitions will ensure consistency in the use and meaning of data objects and
relationships across the Entity. Business definitions will be stored in the business glossary section of the Entity's Data
Catalogue.
Technical definitions for terms within the business glossary will be produced to aid data integration and development
projects that span multiple systems. These technical definitions will consider logical and physical models and may
include technical validations like state diagrams, flow charts, and regular expressions. Technical definitions will be
maintained within the data dictionary of the Data Catalogue.

Minimum data model metadata that the Entity shall maintain includes Model Identifier, Responsibility Assignment,
Published Status, and Change History. Additional metadata will be determined based on the Entity's requirements and
evaluated by the Data Governance Board.

The Entity shall maintain traceability links for different views of the same subject area using annotations that indicate
other existing views. Lower-level identifiers will be used as part of the Reference Number element of the model
identifier to pre-assign numbers to different subject areas. Other metadata for data models will be decided based on
the Entity's requirements, evaluated by the Data Governance Board, and issued to staff.

Data models shall be stored in a version-controlled repository, and the Entity recommends using version control
repositories built into data modeling tooling, external version control repositories or document management systems
that support versioning, or file system structure as an interim solution.
The Entity will develop an enterprise-wide data model that represents an organization-wide view of all data central to
the Entity's core business functions. The enterprise data model is a key aspect of the baseline and target enterprise
data architectures.

The Data Governance Board will maintain oversight and approval of enterprise data models and socialize the
enterprise data model through working groups to facilitate sharing with other Entities.

When developing new data models for system implementations, the Entity shall ensure alignment with the Entity's
Enterprise Data Model. Conceptual, logical, and physical data models will demonstrate alignment with master profiles
and common profiles in the government Data Catalogue.

The Entity will align its Enterprise Data Model with government-wide data models as they emerge.

The Entity shall develop conceptual data models to support the architecture, development, and operational processes
for its data. Conceptual data models will be required as part of the system development lifecycle and provided to the
Data Governance Board through the Governance Checkpoint Process.

Techniques to develop conceptual data models include interviewing stakeholders, identifying candidate data profiles,
and combining candidate data profiles into master data profiles, transactional data profiles, and reference data
profiles. Conceptual data modeling shall be performed at a system or enterprise level, depending on the data view
needed.

Conceptual data models shall be used for documentation to support development of logical data models, change
requests, impact assessments, and gap analyses between baseline and target state requirements.
The Entity shall identify and model all master profiles and relationships between them. Master profiles represent core
data for the Entity's line of business. For example, a 'Citizen' profile may include family relationships, contact details,
and name change history.

Master profiles shall be documented at conceptual and logical levels and form part of the Entity's enterprise data
model. Each system containing master profile data shall have its data modeled at conceptual, logical, and physical
levels.

Entity master profiles shall be made available to ADSIC upon request to facilitate government-wide common profile
development, and the Entity shall align local profiles with government-wide common profiles when appropriate.

Share master profiles for government-wide alignment.

Develop logical data models with relationship rules and denormalization process.

Ensure technology-independent logical data models, considering alternative data repositories.

Use logical data types and business rules for flexible data representation.

Logical data models support development, change requests, and impact assessments. They are shared with the Data
Governance Board.

Develop physical data models based on logical data models for detailed technical specifications.

Physical data models enable technical implementation and operational functions, e.g., SQL queries.

Map logical to physical design, specifying configuration details as needed.

Reverse engineer data models from existing systems to support data architecture baselining, linking them to logical
models for analysis and inclusion.

Data architecture in TOGAF includes component models, data profiles, lifecycle models, security, quality, and change
processes.

Data architecture deliverables cover various domains, including metadata, data quality, security, and management
systems.

Architectural elements are classified as emerging, current, strategic, or retirement.

Specialized data architecture standards from Abu Dhabi Government centers of excellence are used.

Baseline data architectures are developed for information systems under the Entity's control, including maintenance
and updates.

Development of baseline data architecture considers business and technical requirements, data architecture themes,
and constraints.

System-level baseline data architecture is used for system changes and reviews, guided by the Data Governance
Board.
Baseline data architectures are continuously maintained and versioned.

The Entity produces a target enterprise data architecture, informed by the baseline architecture but not dependent on
it.

Baseline data architectures provide a foundation for developing and validating target data architectures.

The Entity produces target data architectures as information systems go through change cycles, required in the
Governance Checkpoint Process.
Target data architectures, at system or enterprise levels, address gaps, encourage data integration, remove
duplication, align with standards, and promote reuse.

The target data architecture influences technology and data requirements for system changes alongside business and
quality requirements.

The Entity identifies gaps between baseline and target enterprise data architectures, covering business, technical, and
capability aspects.
Gap analysis results in a roadmap to move from baseline to target enterprise data architecture, periodically reviewed
by the Data Governance Board.

The roadmap includes timelines, budgets, and priorities for component and system changes, remaining flexible to
address business priorities.

The Entity follows the roadmap during system development and maintenance, ensuring alignment with the enterprise
target data architecture. Annual reports assess the roadmap's effectiveness by identifying gaps between the starting
and ending baseline enterprise data architectures.

The Entity establishes data quality definitions covering various data types, which are stored in the business glossary
and data dictionary.

Data quality definitions are linked to business processes to evaluate the impact of data quality on operations, ensuring
accuracy in processes like citizen contact.
Data quality definitions encompass key aspects such as validity, timeliness, integrity, accuracy, and reliability,
determining acceptable criteria and assessing business benefits.

Metadata is aligned with data quality definitions to populate the Data Catalogue, including quantitative and qualitative
measures.

The Entity creates a data quality checklist tailored to its datasets to facilitate data audits in line with established data
quality definitions.

Data Quality Management Plan: The Entity will create a plan for auditing, monitoring, and maintaining data quality. This
plan covers the quality of master profiles, dataset quality, and addressing issues reported by users. It involves defining
roles, using data profiling and cleansing tools, and producing data quality metadata and requirements. The Data
Governance Board will oversee this plan, including one-off and incremental audits.

Data Quality Requirements: The Entity ensures that all new information systems and changes include specific data
quality requirements. These requirements, documented using data quality metadata definitions, serve as the basis for
internal data quality SLAs and external contractual agreements.

Incorporating Data Quality Audits: The Entity integrates data quality audits into the Data Governance Checkpoint
Process. This includes audits during system changes, plans for improving data quality, and documenting
requirements. The Data Governance Board defines when and where these audits are required, considering factors like
system integrity, accuracy, and reliability at various checkpoints in the data lifecycle.

Master Profile Audits: The Entity will audit its master profiles, as per Data Modeling standards, every three months
across all data sources. If data quality misaligns across sources or with defined standards, discrepancies will be
identified and root causes determined. Corrective action, if necessary, will be decided by the Data Governance Board.
Audit Intervals for Non-Common Profiles: The Entity will establish suitable audit intervals for data types not covered by
common profiles defined in DM2. The Data Governance Board will decide on corrective actions once the cause of
discrepancies is understood.

Third Party Data Quality Checks: The Entity will perform spot checks on third-party data to ensure compliance with
data supplier service level agreements. If no agreements exist, the Entity will develop its own data quality
requirements and share them with the data supplier.

Data Profiling Tools: The Entity will systematically use data profiling tools with various analysis capabilities, including
structured data column analysis, data structure-independent integrity analysis, pattern identification, reporting, and
change detection.

Metadata Storage: Data quality measures obtained during audits will be stored as metadata in the Data Catalogue.

Data Cleansing Initiative: The Entity will identify gaps between data quality definitions and measured data quality. It will
execute a data cleansing initiative to improve data quality, led by the Data Governance Board. Strategies may be
system-specific, data-type specific, or prioritized by business benefit, utilizing various tools and expertise.

Target Data Architectures: The Entity will ensure that target data architectures focus on improving data quality across
information systems and services. Master profiles will be a priority, extending to other data types as defined by the
Data Governance Board.

Data Cleansing Process: The end-to-end data cleansing process is outlined as follows:
The Entity must follow the latest approved Information Security Standards in Abu Dhabi Government, prioritizing them
over Data Management Standards in case of conflicts. The Data Governance Board is responsible for recording and
resolving conflicts.

The Entity's data architecture, information systems, and components should align with the approved Information
Security Standards in Abu Dhabi Government. The Data Governance Board will confirm this alignment through the
Governance Checkpoint Process.

When releasing data as Open Data, the Entity must demonstrate compliance with both the approved Information
Security Standards and Data Management Standards. The Data Governance Board will approve the data's
publication.

The Entity must classify systems to identify those at risk of privacy breaches according to the Entity's privacy policy
(see DSP.2).

The Entity must ensure compliance with Payment Card Industry (PCI) Security Standards for information systems
handling credit card data through the Governance Checkpoint Process.

The Entity must ensure that cloud suppliers adhere to ISO/IEC 27017 Cloud Security Standards and ISO/IEC 27018
Handling of Personally Identifiable Information Standards ratified by the International Standards Organisation.
The Entity must create a privacy policy in line with government privacy laws, incorporating guidance from these
Standards, particularly regarding its line of business data. The policy should include relevant information and guidance.

The privacy policy should include a public privacy statement, clearly outlining stakeholders' privacy rights and the
Entity's privacy obligations. It should remain aligned with cross-government policies.

In consultation with legal experts, individuals from whom data is collected should have the rights to view, correct
inaccuracies, and request the removal of their data when no longer relevant.

The Entity should clarify the purpose and use of personal data at the point of collection and offer stakeholders a
mechanism to opt out of non-core activities.

The Entity must create and maintain privacy metadata for its master profiles, clearly identifying attributes containing
private data. This metadata should be stored in the Data Catalogue.

The Entity's Open Data policy should align with the Data Privacy policy, ensuring no data that breaches individual
privacy is made public. Special attention should be given to preventing the 'mosaic effect,' which combines data from
multiple sources to identify individuals.

Develop an awareness program for the data privacy policy, disseminating it to all users of private data to remind them of
their responsibilities regarding data privacy.
The Entity must adhere to the principles of 'Privacy by Design,' which include being proactive, making privacy the default
setting, embedding privacy into designs, accommodating all legitimate interests, ensuring end-to-end security, providing
visibility and transparency, and respecting user privacy. This approach helps the Entity detect privacy issues early and
reduce privacy risks and costs.

The Entity should develop training and awareness materials on the principles and objectives of 'Privacy by Design' for
technical and business users responsible for designing information systems and processes.

The Entity needs to identify and address any deficiencies in its existing data sources regarding compliance with the
principles of 'Privacy by Design.' The requirements from the gap analysis should inform the Entity's target data
architecture at the enterprise level and within specific information systems as needed.

Data governance checkpoints should be used to confirm alignment with the principles of 'Privacy by Design' when:

The Entity must establish a privacy management workflow for identifying, logging, investigating, and resolving data
privacy-related issues in line with its privacy policy. This workflow should encompass issues reported by both internal
users and external stakeholders, involving steps for evidence collection, post-incident analysis, reporting, and
corrective actions. It is used to monitor policy implementation effectiveness, and the Entity should report privacy-
related metrics to cross-government working groups.

The Entity should provide individuals with a route to update or correct their private data, and these updates should be
part of a data quality audit.

The Entity, following its privacy policy, must respond promptly to requests for data disclosure from individuals, with
response times established by the Data Governance Board. Requests should be monitored to ensure timely action.
The Entity shall evaluate requests for data removal in accordance with its privacy policy, balancing business needs
with individual privacy. Requests should be handled internally, with an appeal process available to individuals if
needed, potentially involving cross-Entity collaboration. The Data Manager makes the final decision.

The Entity should take steps to prevent data loss and privacy breaches, considering appropriate architectural
components to enhance information system protection. These components may include data-loss prevention tools,
database activity monitoring, and data discovery tools. The Data Governance Board assesses data loss risks for each
system and incorporates technical components into the target data architectures as needed.

Data security and privacy requirements must be observed in production information systems within test, development,
and training environments. When using a subset of production data, data masking technologies should be applied to
protect sensitive information. Data masking techniques involve transforming, obfuscating, or randomizing data.
Consideration should be given to preserving the characteristics of real "Live" data in test or training environments.
Data quality audits are necessary when considering data masking.

The Entity must engage an infrastructure audit team knowledgeable about platform utilization metrics
and the prevalent hardware and software configurations across the Entity.
The Entity shall perform a comprehensive audit of physical inventory, encompassing Data Centers and
other sites. The audit should record various fields for each system, including location,
service/application name, server details, hardware, software, and more.

The Entity is required to conduct a logical audit of network inventory to reconcile with the physical
inventory. Tools like Spiceworks, SolarWinds, HP Open Computers and Software Inventory Next
Generation, or a Configuration Management Database (CMDB) instance should be used for this
purpose. Any discrepancies between the two audits should be reconciled through a remediation plan.

ADCMA maintains its IT storage landscape and conducts regular audits.

ADCMA has completed the physical inventory audit and provided evidence.

ADCMA is transitioning from Solarwinds to OP Manager Managed Engine for its operations.

Classify information systems as Legacy, Virtualize-able, or Cloud-able for migration suitability.

Create a migration list based on portability, criticality, and precedence factors.

Engage an infrastructure Architecture team to determine the target architecture for Data Centres.

Ensure the target architecture includes flexible infrastructure capabilities like IaaS and PaaS models.

Choose an appropriate cloud deployment model: Private, Community, Public, or Hybrid, while avoiding public cloud for
Abu Dhabi Government Data.

Determine Data Centre Tier: Decide on a Data Centre Tier based on availability and infrastructure criteria.

Compliance with Tiers: Ensure that Data Centre Standards align with the selected Tier and Cloud Deployment Model.
Consider All Options: Explore various data center strategies, including government solutions.

Cost-Benefit Analysis: Evaluate the financial aspects of data center and cloud investments.

Data Centre Transformation: Plan a transition program considering capacity, budget, and sharing resources.

Transformation Program Review: Seek ADSIC approval for the Data Centre Transformation Program.

Execute Transformation Plan: Implement the approved Data Centre Transformation Plan.

Establish a Cloud Centre of Excellence: Create a team with various cloud management roles.

Continuous Monitoring: Keep track of capacity and resource utilization.

Regular Capacity Audits: Conduct quarterly capacity audits and updates.

Keep Data Centre Plan Updated: Maintain an up-to-date development plan with periodic reviews.

Backup Plan Implementation: Implement an approved backup plan.

Define RPO and RTO: Specify Recovery Point and Time Objectives for backup plans.

Regular Backup Tests: Periodically test backup and restoration processes.

Offsite Backup: Store backup copies securely offsite with monitoring and fire protection.

Cost/Benefit Analysis: Analyze backup processes, favoring cloud-based solutions.

BCDR Plan Implementation: Implement a Business Continuity and Disaster Recovery plan.

BCDR Strategy: Define a strategy for protecting, stabilizing, and recovering critical activities.

BCDR Plan Contents: Include roles, activation process, mitigation actions, communication, recovery, media, and
stand-down plans.
Regular BCDR Drills: Plan and execute annual BCDR drills and quarterly paper scenario exercises.

The Entity should establish a policy and standards for managing all recorded information across its lifecycle, ensuring
high quality, security, and availability.

All data within the Entity should be authentic, reliable, complete, unaltered, and usable, with clear chain of custody and
metadata.

The Entity should identify data owners, establish creation and disposal requirements, determine sharing requirements,
and train staff in data management.

The Entity must maintain an inventory of data in a Data Catalogue, provide an annual report to the Data Governance
Board, and address areas of non-compliance.

Data held by the Entity should follow the Information Lifecycle process, including creation, retention, maintenance,
use, retirement, and disposal, with a focus on security and efficiency.

The Entity shall implement a Strategic Integration Platform to facilitate data transfer, transformation, access auditing,
performance monitoring, security controls, and transaction management. It should be part of the target enterprise data
architecture.
The Entity's strategic integration platform should align with the metadata requirements of the Abu Dhabi Government
Interoperability Framework.

The Entity shall develop and publish a policy for usage of its strategic integration platform, covering internal, trusted
third-party, and external data sharing.

Consideration should be given to migrating existing data feeds into and out of information systems through the
Strategic Integration Platform. The Data Governance Board should assess the business value and reusability of each
data feed.

External integration with data from other Entities should be made through the ADSIC Enterprise Service Bus (ESB).
The Entity should not engage in peer-to-peer data transfers. Datasets available through the ESB should be published
in the Entity's Data Catalogue.
Data exchange through the Strategic Integration Platform should be secure and audited, complying with information
exchange requirements of the approved Information Security Standards.

The Entity should consider appropriate data exchange methods when integrating data between applications and
systems, including file-based, message-based, and database-to-database exchanges.

The Entity should plan to migrate peer-to-peer application data sharing to the Strategic Integration Platform in its target
data architecture, enabling data reusability. Justification is required for cases where migration is not possible due to
proprietary software.

The integration platform should have the capability to broker interactions across different integration patterns, such as
file-based and message-based data exchanges.

Data architectural consideration should be given to the data formats allowed by each data service integrated, with
XML and JSON formats preferred for data transfer between Entities. Industry or proprietary formats are allowed with
justification and should be documented in the Data Catalogue.

Data Transfer Protocols: Choose suitable protocols for connecting systems to the Integration Platform, such as FTP,
HTTP, SOAP, and more. Document these in your Data Catalog.
Prefer One-Way Integration: Favor one-way data sharing methods like Publish/Subscribe, Request/Response, or
Broadcast.

Justify Two-Way Integration: Provide reasons for using complex two-way data sharing and address concerns like
transaction management and data concurrency.

Data Integration Design: Plan for detecting data delivery failures, ensuring repeatable and idempotent data retries,
maintaining statelessness, and ensuring high availability. The Data Governance Board will review these design
considerations.

Service Level Agreements (SLAs): Define agreements covering data quality, volume, service availability, data structure,
change control, exception handling, and SLA monitoring frequency.

Internal SLAs: Create agreements for data sharing within your organization and resolve disputes through the Data
Governance Board.

Binding SLAs for External Entities: Establish binding service-level agreements with other government entities via the
ADSIC ESB. In case of non-compliance, follow the exception escalation process and engage cooperatively to
investigate issues with the service level agreement.

10
Open Data Review: The Entity must systematically evaluate data sources and prioritize making them open unless
there are security, privacy, or data quality concerns. The Data Governance Board reviews and sets criteria for closing
data sources.

Record Keeping: The Entity should maintain systematic records of data sources, clearly indicating their open or
closed status, and provide plain language definitions in the Data Catalogue.

Open Data Access: All data deemed open in the Open Data Review should be available through the Open Data
Portal in machine-readable and human-readable forms.
Data Authenticity: Data should be made available as close to the source as possible, with minimal manipulation.
Privacy and security concerns should be addressed with minimal data changes.

Open Data Plan: Develop a plan for releasing open data, including data review, quality checks, and any required
privacy or security adjustments.
Prioritizing Open Data: Prioritize data release by addressing security, privacy, business needs, and data quality.

Systematic Planning: The Open Data Plan should systematically address all datasets identified in the Open Data
Review.

Plan Monitoring: Regularly monitor progress against the Open Data Plan and review it quarterly.

Publication on Data Portal: Publish open data on the Abu Dhabi Government Open Data Portal.

Data Quality Maintenance: Continuously review open data to ensure it meets quality standards and address security
and privacy concerns.
Dealing with Issues: If open data fails quality or faces security/privacy concerns, suspend its publication, conduct a
new review, and address the issues before relisting.

Usage Tracking: Capture usage trends and statistics on data access and report to the Government Data Governance
Committee.

Annual Awareness Campaign: Conduct annual campaigns to inform stakeholders about open data, its quality, and
any security/privacy measures. Inform and educate internal and external stakeholders and the public.
Transparency in Withholding Data: If a dataset isn't published, use the awareness campaign to explain the reasons,
provide a publication timeline, or clarify if the dataset will remain unpublished.

Plan and publish a schedule for identifying reference data in information systems, including resource
allocation and reviews.

Establish a team responsible for managing reference data, including discovery, alignment, and change
management.

Identify and document reference data used in information systems, specifying values and definitions.

Ensure reference data values are codified, unique, and not case-sensitive, with associated
descriptions.
Align reference data with relevant standards, creating a "master reference data" dataset.

Regularly review the master reference data to accommodate new systems or changes.

Align reference data used in systems with the master reference data or provide mapping schemas.

Describe reference data values in both Arabic and English.

Develop processes for actively managing reference data values, including requests and evaluations.
Define the Reference Data Change process, including requests, evaluations, and updates.

Capture and record requests, consultations, and decisions related to reference data changes.

Implement processes to audit reference data population across information systems.

Implement reference data export features for monitoring alignment with the master reference data.

Establish a Reference Data Management platform with various features.

Implement processes to detect and identify new or unrecognized reference data values for audit.

Plan and publish a schedule for identifying master data in information systems, with resource allocation
and reviews.

Establish a team responsible for managing master data, including discovery, alignment, and cleansing.

Identify and define master data profiles, including semantic definitions and lifecycle details.

Ensure master data records have unique, non-case-sensitive codification.

Publish KPIs and metrics to measure duplicate master data records in information systems.

Implement controls to limit the use of non-primary master data records when duplicates exist.

Match and link equivalent master data records within information systems to identify duplicates.

Assess master data profiles for tangible benefits in merging duplicated records.

Execute master data initiatives to cleanse and deduplicate records when compelling benefits are
identified.
Match and link equivalent master data records across all Entity-owned systems and government-wide
systems.

Develop and publish KPIs and metrics to measure the numbers of master data records across
systems.

Identify master data records without equivalent links for data stewardship activities.

Implement safeguards to monitor reference data values in master data records.

Conduct regular reviews to accommodate new systems or assess changes.

Ensure master data values can be described in multiple languages.

Develop and execute processes to actively manage master data records, prioritizing issues based on
importance and urgency.

Define the Master Data Change process, including identifying the primary information system,
maintaining master data records, and handling external data sources and publications.

Ensure that the process execution is documented and recorded for changes, consultations, and
decisions.

Implement processes to audit the population of master data across all information systems, including
measuring latency and data value alignment.
Implement master data export features for monitoring alignment with the primary master data dataset.

Implement a Master Data Management platform with various features, including workflow
management, multiple versions, import and export support, and data security measures.

Implement system processes to detect and identify new or unrecognized master data values for audit
and process review.

12
Establish quality standards for document and content management, including language style guides,
naming conventions, review processes, and version management.
Define requirements for document and content management, covering document standards, metadata,
retrieval procedures, retention policies, and more.
Ensure documents are authentic, reliable, complete, unaltered, and usable, with proper metadata.

Implement document systems and processes, including file plans, repositories, training, and
performance measurement.
During decommissioning of document systems, no new documents can be created, but existing
documents must remain accessible or be converted to a new system.

Determine retention policies based on business need, regulations, accountability, risks, privacy, and
stakeholder interests.

Establish a document classification scheme for consistent naming, security, access control, and
retention policies.

Ensure correct retirement and disposal techniques are employed, with options like physical destruction
or archiving.
Clearly document and regularly review the document lifecycle and associated processes.

Monitor and ensure compliance with document management processes, retention policies, and user
satisfaction.

Establish and maintain a training and awareness program for document and content management.

Choose a software solution that enables various aspects of document and records management,
including classification, metadata, versioning, retention policies, access control, audit trails, and ease
of use.

Consider international standards when selecting a software platform for document management.

Business Vision for Initiatives: Data warehouse and analytics initiatives should be driven by a clear
business vision. The Data Governance Board plays a key role in overseeing these initiatives.
Service Level Agreements (SLAs): SLAs should be developed to regulate data usage within the data
warehouse. They should include parameters such as data availability, data load latency, data retention,
and data quality.

Monitoring and Reporting: The entity should monitor the effectiveness of data warehouse initiatives
and report findings to the Data Governance Board. This should include technical alignment with the
architectural roadmap, implementation experiences, lessons learned, and business successes.

SLAs with External Data Suppliers: SLAs should be agreed upon with external data suppliers to
ensure confidence in externally sourced data. This includes defining ownership, issue resolution
workflows, data refresh cycles, and data quality requirements.

Data Staging Environment: A data staging environment should be used to collect, cleanse, match,
and merge source system data before adding it to the data warehouse. This can be a separate store or
part of an ETL tool.
Integration with Other Data Management Domains: Data warehouse initiatives should consider
other data management domains, including metadata, data catalog, data modeling, data architecture,
data quality, data security, data storage, data integration, and more.

Enriching Data with External Sources: The entity should explore sourcing and using external data to
enrich its own data for better business intelligence.

Use of COTS or Open Source Tools: Commercial Off The Shelf (COTS) or Open Source tools should
be preferred over internally developed tools, with justification required for internal development.

Usability and Complexity in Architectural Designs: Data warehouse designs should favor usability
but also consider implementation complexity. An incremental, business-focused approach is
recommended.

Data Warehouse Table Types: Different table types (staging, dimension, fact) should be used when
modeling the data warehouse, and data modeling should enhance understanding by stakeholders.
Use of Surrogate Keys: Dimension tables should have synthetic or surrogate primary keys to support
performance optimization.

Data Warehouse Schema Design: Simplest schema types like star schemas are preferred, and
deviations from star schemas should be justified.

Conforming Dimensions: Dimensions should be conformed for reuse across multiple fact tables to
support a gradual development of multiple data marts.

Sources for Data Calculations: Sources for data calculations should be present and maintained in
the data warehouse, with audited workflows for management.

Performance Metrics: Performance metrics should be developed to control data quality, volume, and
timeliness within the data warehouse.

Federated Data Warehouse: Data marts should be consolidated into a federated data warehouse with
common tooling and technology across all data marts.

Consolidation of Data Marts: The entity should include the timeline for consolidating data marts into a
federated data warehouse on the data architecture roadmap.
Reuse of Dimensions: Dimensions should be normalized and reused across data marts for efficient
data processing.

Maturity and Competency: The entity should identify effective data marts to develop maturity and
competency across various data marts.

Operational Data Store (ODS): An ODS should act as a data source for the enterprise data
warehouse.

Separation Between ODS and Data Warehouse: A clear separation between data for an ODS and
data in a data warehouse should be maintained.

Use of ODS for Current Data: The ODS should integrate, analyze, and report on current data when it
meets business requirements.

Use of Realistic Data: Realistic data should be used during the design and development of business
intelligence solutions, and reference to the data dictionary and business glossary is recommended.

Classification of Business Intelligence Initiatives: Business intelligence initiatives should be

classified as tactical, strategic, or operational and appropriately located in the data architecture
roadmap.
Integration with Enterprise Reporting: Business intelligence reporting should integrate with or
become the enterprise reporting solution, which is distinct from application reporting.

Avoidance of Non-Authoritative VGI: Non-authoritative Volunteered Geographical Information (VGI)

should be avoided in compliance with government directives.

Production of KPIs and Dashboards: Business intelligence tools should be used to produce KPIs,
dashboards, and scorecards that reflect the entity's business objectives.

Publication of Statistical Data: The entity should publish statistical data in line with the Statistics
Centre Abu Dhabi (SCAD) requirements and establish SLAs for data provided by SCAD.

Data Analysis Capabilities: The entity should develop data analysis capabilities suitable for its data
types and evaluate training opportunities.

Big Data Analysis: The entity should explore the use of 'Big Data' analysis techniques for high-
volume, high-velocity, or high-variety data.
Event Stream-Based Analytical Processing: Event stream-based analytical processing should be
implemented for high-velocity data analysis, and justifications for its implementation should be
evaluated.

The Entity shall establish an organizational structure to support the Data Management Program.

The organization shall be positioned in the Entity with sufficient authority such that it is empowered to
do its job effectively.

The organization will take responsibility and accountability for Data Management.

The organization will be based on the Roles and Responsibilities described in this control. An
illustrative example of an appropriate RACI matrix is provided in the appendix.

The Entity shall convene the Data Governance Board to manage delegated authority and responsibility
within the Entity.

The Board will be the final arbiter within the Entity for all matters relating to data management.

This Board should have representatives from each area affected by data management initiatives, with
the Data Manager responsible for the execution of the Board's actions through the program
management function of the Entity.

The Data Governance Board shall meet regularly (weekly, initially) to provide independent oversight
and support for the Data Management initiatives being undertaken by the Entity.
The Entity shall appoint a Data Manager.

The Data Manager shall have delegated authority from the Data Governance Board.

The Data Manager shall oversee the implementation of change.

The Data Manager shall ensure compliance with governance, policy, and standards.

The Data Manager shall ensure the coordinated training and awareness programs are executed within
the Entity.

The Data Manager shall share best practices with other Entities.

The Entity shall identify and appoint Data Architects to support the Data Manager.

The Data Architects shall work with the Data Manager and the Data Governance Board to ensure the
implementation of the Data Management Standards in all designs across the Entity.

The Data Architects shall establish a clearly defined target state for all data sources.

The Data Architects shall establish a clearly defined roadmap to achieve the target state for all data
sources.

The Data Architects shall be responsible for developing and maintaining a formal description of the
data and data structures within the Entity, including data designs and design artifacts, dataset
metadata definitions, and data flows throughout the Entity.

The Entity shall identify and appoint Data Stewards to support the Data Manager in both the business
and technical areas of the organization.
The Data Stewards will take responsibility for the lifecycle of the data as it passes through information
systems and ownership boundaries.

The Data Stewards will take responsibility for the quality of the data under their stewardship and
cleanse the data as necessary.

The Entity shall identify and appoint Data Owners (who are responsible for a particular dataset) to
support the Data Stewards.

Data Owners will be drawn from both the business and technical areas of the organization.

The Data Owners will take responsibility for a particular dataset throughout the lifecycle across
systems.

The Data Owners will ensure the quality standards for their dataset are met.

The Data Owners will liaise between the business and technical stakeholders to ensure that their
dataset is maintained to the highest standards possible.

The Entity shall regularly undertake monitoring and compliance checking to ensure that information
systems and data-related processes are implemented in accordance with established policy,
standards, and best practices.

Such reviews should include coverage of the performance of the domain processes and user
satisfaction.
The Entity’s Data Management Policy shall address the scope of its data management systems, roles,
responsibilities, management commitment, coordination among organizational functions, and
compliance obligations.

The policy document shall be approved by the Entity's Data Management Board, Data Manager, and
the Entity's executive management.

The policy shall be published and communicated to all employees and relevant stakeholders.

The policy shall contain a definition of data management, its overall objectives and scope, and the
importance of data management as a pillar of upholding high standards of data quality.

The policy shall be applicable to all business functions of the organization and should be
supplemented by supporting instructions and guidance where appropriate for specific areas of activity.

The Entity shall establish its Data Management Policy, describing how data will be managed across
the Entity.

The Data Management Policy shall be supported by the production of an internal Document Retention
Policy, describing the Entity’s policy for retaining, archiving, and destroying documents (See Document
and Content controls).
In support of the Data Management Policy, the Entity shall establish policies for public consumption
where there are external stakeholders.

The Entity shall make publicly available policies including the Privacy Policy and Open Data Policy.

The policy shall cover the end-to-end data management lifecycle.

The policy shall include a clear statement of management intent, showing support for the principles of
data management and reinforcing its importance in alignment with government strategy.

The policy shall underline management expectations of teams and individuals when handling data and
highlight the importance of maintaining high levels of data quality at all points within the organization’s
operations.

The policy shall include governance metrics and process checkpoints within their policy, describing
how they will measure the effectiveness of data management throughout the Entity’s information
systems and processes on a continuous basis.

Measures and metrics should be maintained continuously and tracked to reveal trends, available for
audit purposes at all times.

The policy shall describe the mechanism allowing business and technical users to raise data-related
issues, including a clear escalation plan to ensure such issues are appropriately handled and resolved.

The policy shall describe the change management process and how it applies to the Data
Management Program and its initiatives.

The policy shall be regularly reviewed and updated (annually at a minimum).

The Data Management Board shall ensure the policy's continued relevance, adequacy, and
effectiveness, with more frequent reviews if significant changes occur.

The Entity shall ensure that all policy developments are aligned with all relevant legislation.

The Entity shall collect and maintain evidence of compliance with their policies and with the Control
Specifications within these standards.

The policy shall be quantifiable and traceable back to the Control Standards of this document; the
Entity should be able to demonstrate how each control will contribute to achieving a given policy
requirement.

Ensure that audit findings are thoroughly analyzed to confirm potential risks associated with
unaddressed issues.

Make certain that audit results are classified and protected at a level equivalent to the highest data
source's security classification being audited.

Efficiently coordinate Data Management audit activities with other audits within the organization to
achieve effective performance and compliance reporting while minimizing disruptions.

The organization must keep its Data Management Program Plan and Policy updated in response to
audit findings in each data domain.

Data management performance reporting should be based on specific, measurable, achievable,

realistic, and timetabled goals outlined by the Data Governance Board and the Abu Dhabi Data
Management Programme. These goals must align with the Entity's business needs and legal
obligations.

Develop outcome-based performance metrics to evaluate the effectiveness and efficiency of the Data
Management Program. The Data Governance Board should oversee the definition of these metrics,
their alignment with the Program Plan, and data performance reporting to stakeholders.
The Data Governance Board's role includes setting performance metrics, analyzing data from various
domains, and reporting Data Management Program performance to relevant stakeholders at specified
intervals and in agreed formats.

Ensure that the organization's Data Management performance metrics align with the Abu Dhabi
Government Data Management Programme's indicators, enabling timely and accurate status reporting
to relevant stakeholders.

Data Management performance reporting should encompass several aspects, including compliant
technology and business processes, data architecture maintenance, completeness of data models,
data quality, and information lifecycle management.

Implement mechanisms for continuous improvement based on performance data analysis, and closely
monitor the cost, benefit, and status of proposed and implemented improvements.

The organization must adhere to applicable Abu Dhabi Government Metadata Standards, such as
eGIF, SCAD standards, and geospatial metadata standards.
Ensure that metadata management tools comply with ISO/IEC:11179 Metadata Registry Standards.

Comply with ISO/IEC:11179 Part 4 'Formulation of Data Definitions' for defining data, which presents
steps for developing unambiguous data definitions.
Follow the principles documented in ISO/IEC:11179 Part 5 'Naming and identification principles' for
developing meaningful names and identifiers.

Execute a metadata initiative to gather, store, and use metadata effectively, covering assessment of
existing metadata sources, requirements gathering, metadata architecture, data stewardship, and a
rollout plan.
Utilize Abu Dhabi government and international standards when developing metadata, including eGIF,
SCAD, Geospatial, and ADMS standards, ensuring that they align with the Entity's operational context.

Manage metadata using a combination of automated scanning and manual techniques, ensuring data
accuracy per a defined schedule.
In cases of metadata conflicts that cannot be resolved by Data Stewards, the Data Governance Board
is responsible for arbitration.

Ensure that all metadata is accessible through the Data Catalogue, serving as the user access point
for metadata, data dictionary, business glossary, and modeling and architectural deliverables.
The Data Catalogue should support indexing, search, and retrieval of metadata relevant to the user's
role.

Document metadata architecture according to Data Architecture standards, making it a component of

the Enterprise Data Architecture.
Evaluate and choose the most appropriate metadata architecture in alignment with central standards,
considering centralized, decentralized, or hybrid approaches.

Define measures for the quality of metadata names and definitions, including subjective business
experience and user surveys to assess metadata effectiveness.
Monitor and report on metadata quality, ensuring that metadata values identify the version they were
captured against.

Monitor metadata coverage across the organization's business functions, assessing metadata
definition, capture, and usage across departments.
Monitor the effectiveness of metadata stewardship through workflow monitoring, issue tracking,
training, and awareness programs.

Align the Data Catalogue with mandatory standards like Abu Dhabi Government eGIF Schema
Generation, DCAT, and XSD to facilitate interoperability.

Also, consider aligning the Data Catalogue with recommended standards such as ADMS and RDF,
providing justifications for non-alignment to the Data Governance Board where necessary.

Develop a Data Catalogue with key features, including a metadata repository, publishing portal,
workflow management tool, business glossary, data dictionary, data model repository, and version
control.
Align Data Catalogue requirements with government-wide data catalogue requirements as they evolve.

Design the Data Catalogue with usability in mind, using a standard vocabulary that represents real-
world concepts accurately.

Serve the Data Catalogue as a central access point for all data assets, even though the actual data
may reside in various systems.

Identify datasets suitable for inclusion in the Data Catalogue, including transactional data, reference
datasets, master data profiles, statistical data, and geospatial data.

Discover datasets using a combination of human interactions and technical tools for scanning data
sources.

Prioritize datasets for inclusion in the Data Catalogue based on past demand, business-level metadata
typically taking precedence.

Develop and store data models for captured datasets at both the business and technical levels.

Consider developing semantic data models that describe data relationships using a defined
vocabulary.

Define appropriate metadata for data capture, including ownership, security classification, data quality,
and version information.

Capture and populate metadata for each dataset, ensuring comprehensive information is included.

Regularly maintain metadata in the Data Catalogue through a defined process.

Classify data assets according to a hierarchy that includes metadata, reference data, master data,
transactional data, and audit and log data, considering data importance, volume, lifecycle, and
complexity.

Establish a licensing model for data sharing and make it accessible through the Data Catalogue.

Create and execute an awareness program to promote data availability to business and technical
stakeholders, emphasizing data reusability.

Ensure that the System Development Lifecycle (SDLC) includes considerations for reusing datasets
from the Data Catalogue.

Encourage submissions for innovative data usage from various functions, evaluating their merit
through the Data Governance Board.

Allow consumers of datasets to register their usage, providing them with information about dataset
changes and updates.

Classify registered consumers as Formal or Informal, depending on the presence of service level
agreements.

Monitor and report Data Catalogue effectiveness using metrics like dataset coverage, registered
consumers, and completeness of metadata.

Review data models in the software development lifecycle as part of the Governance Checkpoint
Process.
Data models are critical for system development and should align with business and technology
requirements.

Implement data modeling tools with UML2.x compliance, XMI interchange support, metadata
association, versioning, and traceability.

Provide training for data modeling, tailored to user roles (e.g., business vs. DB admins).

Develop data models (conceptual, logical, physical) to document Entity's data structure.

Model unstructured data linked to structured data through business terms and concepts.
Model semi-structured/unstructured data with mandatory requirements and metadata.

Convert unstructured data into structured formats for formal modeling.

Align unstructured data conversion with Unstructured Information Management Architecture (UIMA).

Govern unstructured content lifecycle with appropriate workflows.

Create Data Flow Diagrams and Entity Relationship Diagrams for unstructured data.
Develop Data Models at the Conceptual, Logical, and Physical levels with references.

Include data modeling in mandatory system design and architecture documentation.

Produce data models for structured and unstructured data.

Publish data models for reference and re-use; justify deviations to Data Governance Board.

Use UML diagrams as primary modeling notation; seek exceptions' approval.

Use models best suited for communication with stakeholders.

Utilize Entity-Relationship and Class Diagrams for data structure documentation.

Employ Data Flow Diagrams for data movement modeling.

Divide large models into smaller, subject area-based models for clarity.
Clearly indicate current and unimplemented aspects in data models.

Apply naming conventions for data objects and relationships in data modeling.

Indicate master/slave/federation rules for duplicate datasets and shared data.

Define business terms for data objects, attributes, relationships, and values.

Produce technical definitions for terms in the business glossary.

Maintain metadata including model identifiers, responsibility assignment, and status.

Capture traceability links and lower-level identifiers for data models.

Evaluate and maintain appropriate metadata for data models.

Store data models in a version-controlled repository.

Develop an enterprise-wide data model aligned with Entity's core functions.

Ensure Data Governance Board oversight and socialization of enterprise data models.

Align system data models with the Enterprise Data Model.

Align the Enterprise Data Model with government-wide data models.

Develop conceptual data models for architecture and development processes.

Use techniques like stakeholder interviews to create conceptual data models.

Perform conceptual data modeling at a system or enterprise level.

Use conceptual data models for documentation, change requests, and analysis.

Identify and model all master profiles and their relationships.

Document master profiles in the Data Catalogue.

Develop logical data models for data attributes and relationship rules.
Ensure alignment with Enterprise Data Model.

Describe referential integrity and normalization in logical data models.

Document de-normalization justifications when necessary.

Ensure logical data models are independent of technical implementation details.

Use logical data models for documentation, change requests, and analysis.
Develop physical data models based on logical models.

Use physical data models for technical implementation and operational functions.

Provide mappings between logical and physical data models.

Reverse engineer data models from existing systems and link to logical models.

Data Architect (5)

Develop data architecture within an Enterprise Architecture Framework (TOGAF).

Create components, data profiles, data security, and quality compliance designs.

Produce Data Architecture deliverables for all Data Management Programme domains.

Classify architectural elements into Emerging, Current, Strategic, or Retirement categories.

Use specialized data architecture standards.

Develop baseline data architectures for information systems.

Consider business and technical requirements for data architecture.

Use baseline data architecture for system validation.

Continuously maintain and version baseline data architectures.

Produce a target enterprise data architecture.

Create target data architectures for evolving systems.

Target data architectures should align with various criteria.

Influence technology requirements based on target data architectures.

Identify gaps between baseline and target data architectures.

Develop a roadmap for aligning data architectures.

Follow the roadmap for system and component changes.

Annually report on roadmap implementation effectiveness.

6
Provide data quality definitions in various categories.

Map data quality definitions to business processes.

Define measures for data quality (validity, timeliness, integrity, accuracy, reliability).

Populate Data Catalogue with data quality metadata.

Develop a data quality audit plan.

Establish roles and tools for data quality initiatives.

Include data quality requirements in business requirements.

Integrate data quality audits into Governance Checkpoint Process.

Audit master profiles and align data quality.

Define audit intervals for non-standard data types.

Perform spot checks on third-party data quality.

Use data profiling tools for systematic data audits with structured data column analysis, integrity
analysis, pattern recognition, and reporting.

Store data quality measures in the Data Catalogue.

Identify gaps between data quality definitions and measured quality, and execute data cleansing
initiatives.

Ensure target data architectures improve data quality with monitoring and cleansing components.

Detail an end-to-end data cleansing process.

Apply Information Security Standards, resolving conflicts through the Data Governance Board.

Certify alignment with Information Security Standards for various information systems and
components.

Demonstrate compliance when releasing Open Data.

Identify information systems at risk of privacy breaches.

Ensure PCI Security Standards compliance for credit card data.

Ensure cloud suppliers meet ISO/IEC 27017 and ISO/IEC 27018 standards.

Develop a privacy policy in alignment with government privacy legislation.

Include a public privacy statement.

Consider individuals' rights related to their data.

Clarify data usage and provide opt-out mechanisms for stakeholders.

Produce and maintain privacy metadata for master profiles.

Ensure Open Data policy aligns with Data Privacy policy to avoid privacy breaches.

Develop an awareness program for data privacy.

Adopt 'Privacy by Design' principles.

Provide training and awareness materials for 'Privacy by Design.'

Identify shortcomings and use gap analysis in target data architecture.

Validate 'Privacy by Design' principles in data governance checkpoints.

Develop a privacy management workflow for issue resolution.

Provide individuals with a route to maintain/correct private data.
Respond to data disclosure requests within established time targets.

Evaluate Data Removal Requests: The Entity will thoroughly review and consider data removal
requests concerning an individual's information, striking a balance between business needs and
privacy. The process will include an appeals mechanism and involve cross-Entity collaboration, if
necessary, with the Data Manager having the final say.

Strengthen Data Protection Measures: To safeguard against data loss and privacy breaches, the
Entity will deploy a range of security components. These include data-loss prevention tools, database
activity monitoring, and data discovery tools. Systems will be evaluated based on business value and
data sensitivity to assess the risk of data loss.

Secure Data in Testing Environments: Data security and privacy standards will extend to test,
development, and training environments. When utilizing subsets of production data, data masking
techniques will be employed to ensure data integrity while aligning with quality standards.
Engage Infrastructure Audit Team: An infrastructure audit team, well-versed in platform utilization
metrics and hardware configurations, will be brought in to comprehensively audit the Entity's
infrastructure.

Audit Physical Inventory: A comprehensive audit will be conducted for all systems within Data
Centers and other sites. The audit will involve recording specific details such as hardware models,
power requirements, and current statuses.

Conduct Logical Network Audit: The Entity will perform a logical audit of the network inventory to
ensure it aligns with the physical audit. Any discrepancies identified will be resolved through
remediation plans.

Audit Infrastructure Utilization: Infrastructure utilization audits will be carried out on all information
systems and servers to assess actual loads during usage scenarios, both at peak and baseline levels.

Determine Infrastructure Capacity: Based on the audits, the Entity will determine the current
infrastructure's capacity and utilization trends, providing insights into consolidation ratios and future
capacity requirements.

Categorize Systems by Criticality: Information systems will be categorized based on criticality levels,
allowing for classification as Core Infrastructure, Critical, High, Medium, or Low. This classification will
align with the Entity's business priorities.

Classify Systems for Portability: The categorization of systems into Legacy, Virtualize-able, or
Cloud-able will aid in assessing their suitability for migration to target architectures.

Create Migration List: A migration list will be developed, considering portability and criticality, to
identify systems earmarked for migration.

Engage Infrastructure Architecture Team: A specialized infrastructure architecture team will be

involved in determining the suitable target architecture for the Entity's data centers.

Adopt a Flexible Target Architecture: The target architecture will reflect the latest flexible
infrastructure capabilities, such as Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS),
ensuring alignment with the Entity's requirements.
Choose a Cloud Deployment Model: A suitable cloud deployment model—Private Cloud, Community
Cloud, Public Cloud, or Hybrid Cloud—will be selected based on alignment with the Entity's
requirements and the Abu Dhabi Government's data center capabilities.

Refer to TIA942 Standards: The Entity will adhere to TIA942 standards for its infrastructure, including
access, power, cooling, and networking, ensuring compliance.

Set Data Center Standards: Establishment of data center standards, aligning with the determined Tier
level and chosen Cloud deployment model, is crucial to meet specific criteria.

Explore All Options: The Entity will thoroughly explore various data center strategies before making
final commitments, considering emerging solutions in the Abu Dhabi Government's data center
landscape.

Consider Cost-Sharing and Resilience: To optimize costs and enhance resilience, the Entity will
explore opportunities to share data center capacity and resources with other government entities.

Plan a Data Center Transformation Program: The Entity will plan a structured Data Center
Transformation program to transition from the current state to the target architecture within the
timeframe of the Abu Dhabi Government Data Management Programme.

Submit the Program for Review: The Data Center Transformation program will be submitted to
ADSIC for review and approval, ensuring alignment with government policies and standards.

Execute the Data Center Transformation Plan: Upon approval by ADSIC, the Entity will execute the
approved Data Center Transformation Plan, ensuring compliance with the planned changes.

Establish a 'Cloud' Center of Excellence Team: A dedicated 'Cloud' Center of Excellence team will
be formed to manage various aspects of the cloud infrastructure and administration.

Continuously Monitor Capacity and Utilization: Regular monitoring of capacity and utilization will
ensure optimal performance and allow the Entity to address any potential issues proactively.

Regularly Audit Capacity and Utilization: Periodic audits will follow the methodology outlined in DS1
to ensure the efficient functioning of the infrastructure.
Keep a Data Center Development Plan Up-to-Date: Maintaining an up-to-date development plan will
ensure that the data center's growth aligns with evolving requirements, reviewed annually and
refreshed every three years.

Implement a Backup Plan: A comprehensive backup plan, compliant with approved Information
Security Standards, will be implemented to ensure data integrity and availability in the event of loss or
system failure.

Define Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO): Specific RPO and
RTO for each system covered by the backup plan will be determined and approved by the Data
Governance Board to align with business needs.

Conduct Regular Backup Availability Tests: Regular tests of the availability and effectiveness of the
backup and recovery procedures will be conducted, validating RPO and RTO objectives, backup
schedules, and restoration processes.

Prefer Remote Disk Backup for Offsite Storage: Remote disk backup will be favored for offsite
storage, ensuring secure and environmentally protected backup copies.

Conduct Cost/Benefit Analysis for Backup Processes: A thorough evaluation of the costs and
benefits of different backup processes will be undertaken, emphasizing modern solutions for backup
efficiency.

Implement a Business Continuity and Disaster Recovery (BCDR) Plan: A comprehensive BCDR
plan will be developed and implemented in compliance with approved Information Security Standards,
ensuring effective response to potential disasters.

Determine Appropriate BCDR Strategy: The Entity will assess and determine the most suitable
Business Continuity and Disaster Recovery (BCDR) strategy, taking into account critical activities,
incident mitigation, and vendor evaluations.

BDR Drills and Scenario Exercises: The Entity will plan and execute regular BCDR drills and paper
scenario exercises, ensuring that teams are well-prepared for various disaster scenarios.

Comprehensive BCDR Plan Contents: The Entity's BCDR plan will encompass defined roles and
responsibilities, incident response processes, actions for mitigating consequences, communication
plans, and clear recovery priorities.
Effective Information Lifecycle Management: The Entity will establish a policy and standards for
managing recorded information throughout its lifecycle, ensuring that data is authentic, reliable,
complete, unaltered, and usable.

Data Management Ownership: Data ownership and responsibilities will be clearly assigned, including
data class creation, disposal requirements, information-sharing, and security protocols.

Data Inventory Maintenance: The Entity will maintain an up-to-date Data Catalogue to facilitate
reporting on the status of the Data Inventory, departmental compliance with Data Management
Standards, and areas of risk and recommendations.

Information Lifecycle Stages: Data will be managed throughout the Information Lifecycle stages,
including creation, retention, maintenance, use, retirement, and disposal, ensuring data quality,
accuracy, and security.

Tight Governance and Monitoring: Stringent governance and monitoring will be maintained, with
data classification, retention, and disposal adhering to policies and procedures to prevent unauthorized
changes and ensure data security.
Strategic Integration Platform: The Entity will implement a Strategic Integration Platform as part of its
target enterprise data architecture, enabling data transfer, transformation, access auditing,
performance monitoring, security controls, and transaction management for efficient data integration.

Strategic Integration Platform and eGIF Metadata Alignment The Entity ensures that its
strategic integration platform aligns with the metadata requirements of the Abu Dhabi
Government Interoperability Framework (eGIF).

Policy for Usage of Strategic Integration Platform The Entity develops and publishes a
policy for using its strategic integration platform, covering internal, trusted third-party, and
external data sharing, encouraging cross-functional data sharing and considering service
level agreements.

Migration of Data Feeds Consideration is given to migrating existing data feeds into the
Strategic Integration Platform, evaluating business value and reusability.

External Integration Through ADSIC ESB Data integration with other Entities occurs
through the ADSIC Enterprise Service Bus (ESB) to avoid peer-to-peer data transfers.

Secure and Audited Data Exchange Data is exchanged securely and in compliance with
information exchange requirements outlined in Abu Dhabi Government's Information
Security Standards.

Data Exchange Methods The Entity considers appropriate data exchange methods,
including file-based, message-based, and database-to-database exchange methods.

Migration of Peer-to-Peer Data Sharing The Entity plans to migrate peer-to-peer application
data sharing to the Strategic Integration Platform for data reusability.
Integration Patterns Capability The integration platform allows different integration patterns,
including file-based and message-based exchanges.

Data Format Consideration Data architectural considerations are given to data formats
used in data services, with a preference for XML and JSON.

Data Transfer Protocols Data architectural considerations are given to data transfer
protocols, including FTP, HTTP, SOAP, ODBC, and JDBC.

One-Way Integration Patterns The Entity favors one-way integration patterns, including
publish/subscribe, request/response, and broadcast.

Two-Way or Interactive Integration Patterns Two-way data integration patterns are

considered and require justification through the Governance Checkpoint Process.

Data Integration Designs Consideration is given to data integration designs for detecting
delivery failure, repeatable retries, statelessness, and high availability.

10
Service Level Agreements Service level agreements (SLAs) are established, covering data
quality, data volume, availability, data variety, change control, exception escalation, and
SLA monitoring frequency.

Internal Service Level Agreements Internal SLAs are produced for data sharing within the
Entity, with dispute resolution through the Data Governance Board.

Binding Service-Level Agreements Binding SLAs are produced for data sharing between
Abu Dhabi Government Entities through the ADSIC ESB, with escalation procedures in
case of non-compliance.
Open Data Review The Entity systematically reviews all data sources, considering 'Open
By Default,' and criteria for closing sources are defined.

Open Data Records Systematic records are maintained, indicating the open or closed
status of data sources in the Entity's Data Catalogue.
Open Data Publication Open data is made available through the Open Data Portal in
machine-readable and, where practicable, human-readable forms.

Data Manipulation and Privacy Data is made available in its closest-to-source form, with
minimal manipulation, aggregation, redaction, or anonymization, taking into account privacy
and security concerns.

Open Data Plan An Open Data Plan is developed based on the Open Data Review,
ensuring data quality, addressing security and privacy, business priorities, and demand.

Open Data Plan Prioritization The Open Data Plan prioritizes data release based on various
criteria, including security, business priorities, demand, and data quality.

Systematic Dataset Address The Open Data Plan systematically addresses all datasets
identified in the Open Data Review.
Open Data Plan Monitoring Progress against the Open Data Plan is monitored and
reviewed quarterly.

Open Data Publication The Entity publishes its Open Data on the Abu Dhabi Government
Open Data Portal.

Continuous Data Quality and Privacy Review Open Data is regularly reviewed for
continuous data quality and privacy compliance.
Handling Open Data Failures In case of data quality or security concerns, the Entity
suspends Open Data publication, reviews the dataset, and executes a mitigation plan.

Data Usage Monitoring Usage trends and statistics regarding data access are captured and
reported to the Government Data Governance Committee.

Awareness Campaign Annual awareness campaigns are conducted to inform potential

users and stakeholders about the Entity's Open Data, its quality, and context.

Non-Published Datasets Explanation In cases of datasets not published, the Entity uses the
awareness campaign to explain the reasons, potential future publication, or the dataset's
non-publication status.
Reference Data Management Plan The Entity plans activities to identify reference data
used in its information systems, covering resources, scoping, and regular reviews.

Reference Data Management Team A dedicated team is established for reference data
management, including discovery, alignment, change management, and coordination.

Definition of Reference Data Reference data used in information systems is identified and
defined, including values and semantic definitions.

Codification of Reference Data All reference data values are codified as unique, non-case-
sensitive, contiguous values with associated descriptions and metadata.

Alignment with Standards Reference data values are aligned with government and local
standards, forming the 'master reference data' dataset.
Regular Reviews Regular reviews of the 'master reference data' dataset are conducted to
incorporate new information systems and changes.

Alignment or Mapping Reference data used in information systems is aligned with the
'master reference data' dataset or mapped, accounting for bi-directional transformations.

Multilingual Reference Data Reference data values are described in Arabic and English.

Active Management Processes are developed to actively manage reference data values,
allowing requests, evaluations, and applications.

Reference Data Change Process The Reference Data Change process is defined,
Process Execution and Evidence The Entity shall ensure that processes are executed in a manner
that allows for the capture and recording of requests, consultations, and decisions.

Reference Data Auditing The Entity shall establish processes to audit the population of reference
data across all its information systems to ensure data integrity.

Reference Data Export for Alignment The Entity shall implement features to export reference data
from information systems for comparison with the 'master reference data' dataset, facilitating alignment
monitoring and analysis.

Reference Data Management Platform The Entity shall implement a comprehensive Reference Data
Management platform with features such as workflow management, support for multiple versions of
reference data, API integration, and more, to effectively manage reference data.

Detection of Unrecognized Reference Data The Entity shall create system processes to detect and
identify the use of new or unrecognised reference data values, triggering audit and process reviews.
Master Data Management Plan The Entity shall plan and publish a schedule for identifying and
managing master data across its information systems, encompassing resource allocation, data
discovery, ongoing stewardship, and more.

Master Data Governance Team The Entity shall establish a dedicated team responsible for managing
all master data, including ownership, accountability, and consultation for significant dataset changes.

Master Data Definition and Lifecycle The Entity shall define master data elements, their semantic
definitions, and their lifecycles in both business and technical contexts.

Unique Codification of Master Data The Entity shall ensure that all master data records are uniquely
identified and codified with contiguous non-whitespace values, and such code values shall be non-
case-sensitive.

Metrics for Duplicate Master Data Records The Entity shall develop and publish key performance
indicators and metrics for measuring the number of duplicated master data records within each
information system.
Controls for Non-Primary Master Data Records The Entity shall implement systematic controls to
limit the use of non-primary master data records within information systems where feasible.

Matching and Linking of Master Data Records The Entity shall match and link equivalent master
data records within each information system to identify duplicate records.

Benefit Analysis for Data Merging For master data profiles that could benefit from merging
duplicated records, the Entity shall conduct a benefit analysis, considering data that references these
records and ensuring data references are updated accordingly.

Master Data Cleansing Initiative When a compelling benefit case or government-wide mandate
exists, the Entity shall schedule and execute a master data initiative to cleanse master data and
associated data to eliminate duplicate entries.

Cross-System Data Matching and Linking The Entity shall match and link equivalent master data
records across all information systems, including those operated by third parties, with special attention
to primary systems.
Metrics for Master Data Records The Entity shall develop and publish metrics to measure the
number of master data records and their equivalents across different information systems.

Unlinked Master Data Focus The Entity should be capable of identifying master data records that
have not been linked to any equivalent records, focusing on data stewardship and conducting regular
reviews.

Safeguarding Reference Data Values The Entity shall implement appropriate system safeguards to
monitor the use of reference data values to ensure their compliance with approved reference data.

Regular System Reviews Regular reviews, as outlined in the Master Data Initiatives plan, shall be
conducted to address new information systems and assess changes not identified through operational
processes.

Multi-Lingual Master Data The Entity shall ensure that all master data values can be described in
more than one language to accommodate linguistic diversity.
Active Master Data Management The Entity shall establish processes for actively managing master
data records, prioritizing issues based on importance and urgency.

Master Data Change Process The Entity shall define the process for maintaining master data
records, including identification of primary systems, maintenance processes, and incorporation of
external data.

Process Execution and Evidence The Entity shall ensure that process execution is well-documented,
including the capture and recording of changes, consultations, and decisions.

Master Data Auditing The Entity shall implement processes to audit the population of master data
across its information systems and develop metrics to measure data updates and alignment.
Master Data Export for Alignment The Entity shall create features for exporting master data from
information systems to compare with the 'primary master data' dataset, enabling alignment monitoring
and initial analysis.

Master Data Management Platform The Entity shall implement a comprehensive Master Data
Management platform with various features, including workflow management, support for multiple
versions of master data, API integration, and more.

Detection of Unrecognized Master Data The Entity shall establish processes to detect and identify
new or unrecognised master data values, ensuring they align with the change management process.

Quality Standards for Documents and Content The Entity shall define quality standards for
managing documents and content, encompassing language style guides, naming conventions, review
processes, and version management.

Document Management Requirements The Entity shall define requirements for managing
documents and content, covering document standards, metadata, retrieval procedures, and legal
considerations.

Document Integrity and Reliability The Entity shall ensure documents are authentic, reliable,
complete, unaltered, and usable, with proper records of changes and access.

Document System Implementation When implementing document systems, the Entity shall establish
file plans, repositories, training, data transfer, standards, retention timelines, and strategic integration.

Decommissioning Document Systems When decommissioning document systems, the Entity shall
discontinue new document creation, ensure accessibility for existing documents, and consider
migration to new systems.
Retention Policy Determination The Entity shall determine appropriate retention policies for
document types based on business needs, regulatory requirements, privacy concerns, and risk
assessments.

Document Classification Scheme The Entity shall establish a document classification scheme for
consistent naming, efficient retrieval, security provisions, access control, and retention policies.

Document Retirement and Disposal The Entity shall employ proper techniques for retiring and
disposing of documents, considering physical destruction, offline retention, archive handover, or
transfer of responsibility.

Document Lifecycle Management The Entity shall document and regularly review the lifecycle and
processes associated with documents and content.

Monitoring and Compliance The Entity shall conduct regular monitoring and compliance checks to
ensure that document systems and processes adhere to established policies and standards.

Training and Awareness The Entity shall maintain an ongoing training and awareness program for
document and content management, covering training requirements, policies, legal frameworks, and
system usage.
Document Management Solution Criteria The solution chosen by the Entity should meet criteria
enabling effective document management, including classification, metadata management, versioning,
search, access control, and auditing.

International Standards for Software Selection When selecting a software platform for document
management, the Entity may refer to related international standards for guidance.

usiness Vision-Driven Initiatives The Entity ensures data warehouse and business intelligence
initiatives align with a clear business vision. The Data Governance Board plays a crucial role in
overseeing these initiatives.

Service Level Agreements (SLAs) for Data Warehouse The Entity develops SLAs based on
business needs, defining SLAs for data availability, load latency, retention, and data quality.
Effective Data Warehouse Monitoring The Entity monitors and reports on initiative effectiveness,
sharing findings with the Data Governance Board for knowledge sharing across government entities.

SLAs with External Data Suppliers The Entity agrees on SLAs with external data suppliers to gain
confidence in externally supplied data, covering aspects like ownership, issue resolution, data refresh
cycles, and quality standards.

Data Staging Environment The Entity employs data staging for source data cleansing and merging,
utilizing various data-staging options.

Data Warehouse Initiative Considerations The Entity ensures alignment with various data
management domains, covering metadata, data catalog, modeling, architecture, quality, security,
storage, integration, master, reference, and open data.

Enrichment with External Data The Entity explores the use of external data sources to enhance
business intelligence.
Preference for COTS and Open Source The Entity prioritizes Commercial Off The Shelf (COTS) and
Open Source tools over internally developed ones, providing justification when necessary.

Usability-Oriented Architectural Designs The Entity favors data warehouse architectural designs
that prioritize usability while considering implementation complexity. An incremental, business-focused
approach is recommended.

Data Warehouse Table Types The Entity explains the different types of data warehouse tables,
including data staging, dimension, and fact tables.

Synthetic Primary Keys for Dimension Tables The Entity uses synthetic or surrogate primary keys
for dimension tables to optimize performance.

Schema Design Preference The Entity prefers star schemas for simplicity but justifies deviations
when necessary.

Conformed Dimensions for Reuse The Entity promotes conformed dimensions for reuse and
explains the concept and benefits.

Sources for Data Calculations The Entity ensures sources for data calculations are present and
managed within the data warehouse.
Performance Metrics for Data Quality The Entity develops performance metrics to control data
quality, volume, and timeliness.

Federated Data Warehouse The Entity normalizes data warehouse technology and explains the
concept of a federated data warehouse.

Consolidating Data Marts The Entity includes the consolidation of data marts in the data architecture
roadmap.

Dimension Normalization and Reuse The Entity normalizes and reuses dimensions for data
processing and reporting.

Maturity Development for Data Marts The Entity identifies effective data marts for organizational
maturity and competency.

Operational Data Store as Data Source The Entity uses the operational data store (ODS) as a data
source for the enterprise data warehouse.

Separation of ODS and Data Warehouse The Entity explains the distinction between ODS and data
warehouse data, highlighting their purposes and usage.
ODS Functionality and Integration The Entity utilizes ODS functionality for integrating, analyzing,
and reporting on current data.

Realistic Data for Business Intelligence The Entity emphasizes using realistic data for clarity, with
reference to the data dictionary and business glossary.

Classify Business Intelligence Initiatives The Entity classifies BI initiatives according to types,
explaining tactical, strategic, and operational BI.

Integration with Enterprise Reporting The Entity integrates BI reporting with enterprise reporting and
discusses the differentiation between enterprise reporting and application reporting.

Non-Authoritative VGI Compliance The Entity complies with government directives on non-
authoritative Volunteered Geographical Information (VGI).

KPIs, Dashboards, and Scorecards The Entity develops and uses BI tooling for key performance
indicators, dashboards, and scorecards.
Statistical Data Publication The Entity publishes statistical data in line with Statistics Centre Abu
Dhabi (SCAD) requirements, establishing SLAs for SCAD-provided statistical data.
Comments Compliance Status

No identified structure or model supports the Data

Management program in this assessment. Not implemented

No Data Governance board currently exists with Not implemented

delegated authority and defined responsibilities.

The Data Manager role is undefined and not in Not implemented

operation as of this assessment.

The Data Architects' role is undefined and not in Not implemented

operation in this assessment.

The Data Stewards' role is not defined or

operationalized in this assessment Not implemented

As of this assessment, no 'Datasets' are identified

across the organization, and therefore, roles as Data Not implemented
Owners are neither defined nor operationalized.

As of this assessment, no organizational structure,

R&R, or operating model supports the Data
Management program, and there is a lack of Not implemented
defined DG standards, best practices, and policies.

In this assessment, ADCMA has already

implemented the "Privacy Policy" on its website.
However, there is no overarching Data
Management policy, organizational structure, or
operating model established to support the Data Not implemented
Management program. Furthermore, the Data
Management Policy remains undefined, and there is
no documentation for the systems' span-of-control.
Not implemented
As of this assessment, there is no established
organizational structure, R&R, or operating model
to govern the data management policy.

As of this assessment, there's no established

structure, R&R, or operating model to oversee the Not implemented
data management policy.

In this assessment, there is no established

organizational structure, R&R, or operating model Not implemented
to oversee the data management policy.

In this assessment, there is no established

organizational structure, roles and responsibilities
(R&R), or operating model to govern the data Not implemented
management policy.

As of this assessment, ADCMA has implemented the

"Privacy Policy," available on its website. ADCMA
complies with Open Data policy requirements when Not implemented
accessing Open Data but currently does not share
any data.

As of this assessment, there is no defined end-to-

end data management lifecycle. Not implemented

As of this assessment, there is no statement of

intent from ADCMA management regarding Data Not implemented
Management.

As of this assessment, there's no defined end-to-

end data management lifecycle, and the team lacks Not implemented
awareness about maintaining high data quality.

As of this assessment, no governance metrics or

process checkpoints are defined to measure the Not implemented
effectiveness of data management controls.

In this assessment, there is an ongoing ITSM

initiative, but there is no defined procedure for Not implemented
business and technical users to report data-related
issues.
There is no defined change management process
for the data management program in this Not implemented
assessment.

In this assessment, there is no established

organizational structure, R&R, or operating model
to support the Data Management program. Not implemented
Additionally, there is no DG board in place with the
authority to review Data Management policies.

In this assessment, no organizational structure,

roles and responsibilities (R&R), or operating model
exists to support the Data Management program. Not implemented
Additionally, there is no DG board with the
authority to review policies and ensure alignment
with legislation.

In this assessment, the process for gathering and

maintaining evidence for the DM Statement of Not implemented
Compliance is not established.

In this assessment, there is no implementation of

data management policy traceability to control Not implemented
standards.

ADCMA follows a standard NDA process when

engaging with stakeholders, ensuring stakeholders Not implemented
adhere to relevant policies in writing.

The Entity will set and uphold specific, measurable,

and scheduled goals in support of its Data
Management Program, focusing on business
strategy, risk management, compliance with data Not implemented
management policies and standards, and fostering
an organizational culture that is mindful of data
management responsibilities.

As of this assessment, there is no established data

management program plan. Not implemented
In this assessment, no data management program Not implemented
plan is defined.

In this assessment, there are no version control

specifications for data management program Not implemented
artifacts.

The Data Assessment program, starting in Q4 2023,

will serve as the baseline for the Data Management Not implemented
Program.

In this assessment, ADCMA has established a Data

Management capability plan for Disaster Recovery Not implemented
and Document & Content Management.

In this assessment, the ADG's data management

model principles (Owned, Described, Quality, Not implemented
Access, Implemented) have not been put into
practice.

In this assessment, there is no Data Governance

board with delegated authority and defined Not implemented
responsibilities.

The existing CM process defines 3 tiers of approvals Not implemented

(Std, Critical and Emergency).

In this assessment, there is no established change

management process baseline for the Data Not implemented
Management Program.

In this assessment, there is no established change

management process baseline for the Data Not implemented
Management Program.

In this assessment, there is no established change

management process baseline for the Data Not implemented
Management Program.
In this assessment, there is no established change
management process baseline for the Data Not implemented
Management Program.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not defined or operationalized.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not defined or operationalized.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not defined or operationalized.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not established or in operation.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not established or in operation.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not established or in operation.

In this assessment, the training and organizational

awareness components of the Data Management Not implemented
program are not established or in operation.

In this assessment, no Data Management Audit

framework is in place to ensure compliance with the
Data Management Policy and Standards as defined
by the ADG-DMS and recommended policies. Not implemented
Furthermore, there is no established alignment of
the Data Management Audit Framework with the
Internal Affairs sector.
In this assessment, there is no Data Management
Audit framework to ensure compliance with the
Data Management Policy and Standards defined by
the ADG-DMS and recommended policies. Not implemented
Furthermore, there is no established alignment of
the Data Management Audit Framework with the
Internal Affairs sector.

In this assessment, there is no Data Management

Audit framework in place to ensure compliance with
the Data Management Policy and Standards defined
by the ADG-DMS and ADG recommended policies. Not implemented
Additionally, there is no established alignment of
the Data Management Audit Framework with the
Internal Affairs sector.

In this assessment, there is no Data Management

Audit framework in place to ensure compliance with
the Data Management Policy and Standards as
defined by the ADG-DMS and ADG recommended Not implemented
policies. Additionally, there is no established
alignment of the Data Management Audit
Framework with the Internal Affairs sector.

In this assessment, there is no Data Management

Audit framework in place to ensure compliance with
the Data Management Policy and Standards as
defined by the ADG-DMS and recommended Not implemented
policies. Additionally, there is no established
alignment of the Data Management Audit
Framework with the Internal Affairs sector.
In this assessment, there is no Data Management
Audit framework in place to ensure compliance with
the Data Management Policy and Standards as
defined by the ADG-DMS and recommended Not implemented
policies. Additionally, there is no established
alignment of the Data Management Audit
Framework with the Internal Affairs sector.

In this assessment, there is no Data Management

Audit framework in place to ensure compliance with
the Data Management Policy and Standards as
defined by the ADG-DMS and recommended Not implemented
policies. Additionally, there is no established
alignment of the Data Management Audit
Framework with the Internal Affairs sector.
In this assessment, Data Management performance
metrics have been partially implemented for
Enterprise Service management and Data Security,
but they do not cover all data domains as defined in
the Data Management standards. Additionally, the
Performance Management module is partially Not implemented
implemented in the ERP system to measure the
performance of each employee. Employee
objectives are linked with their Key Performance
Indicators (KPIs), and these KPIs are aligned with
departmental KPIs.

In this assessment, Data Management performance

metrics have been partially implemented for
Enterprise Service management and Data Security,
but they do not cover all data domains as defined in
the Data Management standards. Additionally, the
Performance Management module is partially Not implemented
implemented in the ERP system to measure the
performance of each employee. Employee
objectives are linked with their Key Performance
Indicators (KPIs), and these KPIs are aligned with
departmental KPIs.
As of this assessment, Data Management
performance metrices are partially implemented
for Enterprise Service management and Data Not implemented
Security but does not cover all data domains
defined in the Data Management standards

As of this assessment, Data Management

performance metrices are partially implemented
for Enterprise Service management and Data Not implemented
Security but does not cover all data domains
defined in the Data Management standards

As of this assessment, Data Management

performance metrices are partially implemented
for Enterprise Service management and Data Not implemented
Security but does not cover all data domains
defined in the Data Management standards

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata Not implemented

management tool is not available.
In the current landscape, the metadata Not implemented
management tool is not available.

In the current landscape, the metadata

management tool is not available. Not implemented
In the current landscape, the metadata
management tool is not available. Not implemented

In the current landscape, the metadata

management tool is not available. Not implemented

In the current landscape, there is no data catalogue Not implemented

implementation.

In the current landscape, there is no data catalogue Not implemented

implementation.
In the current landscape, there is no data catalogue Not implemented
implementation.