EDM Council CDMC (Cloud Data Management Capabilities): EDM Council CDMC – Tutorial (about 60 minutes)

The Cloud Data Management Capabilities framework, usually shortened to CDMC, is the EDM Council's best-practice framework for managing and protecting data, above all sensitive data, in cloud, multi-cloud and hybrid-cloud environments. Chief data officers, security and privacy teams, cloud platform engineers, data stewards and auditors use it to agree what "well-controlled data in the cloud" means and to prove it with evidence. It is built around 14 key controls designed to be automated rather than checked by hand. After this tutorial you will be able to explain how CDMC is organised, describe what each key control asks for, plan a practical implementation and understand how readiness and certification assessments work.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current release is CDMC version 1.1, published by the EDM Council in September 2021 under a free licence for internal use by any organisation, member or not. The 14 key controls were first published in July 2021, and certification work refers to the CDMC Key Controls Framework Test Specifications version 1.1.1. The framework is maintained by the EDM Council's CDMC working group; the council's website now also uses the name "EDM Association" in its text. No newer version of the framework had been announced on the official CDMC page when this tutorial was checked, so version 1.1 is what you will meet in practice. In July 2026 the association said it is extending the CDMC assessment and certification programme to cover analytics and AI; no new framework version number had been published by the verification date. The full framework document is available from the council after registration, so this tutorial describes its publicly known structure in its own words rather than reproducing the text. Verified 2026-10-29 against the EDM Council CDMC pages, the September 2021 launch press release and Google Cloud's published CDMC reference architecture.

Who it is for: data governance leads and data stewards, cloud and data platform engineers, information security and privacy professionals, risk and compliance staff, internal auditors, architects and consultants who need a common, testable set of expectations for data held in the cloud. It is especially relevant in regulated sectors such as banking, insurance and capital markets, where the framework was born, but nothing in it is limited to finance.

Prerequisites: none. A general idea of what a cloud data platform is (storage, a data warehouse or data lake, identity and access management) helps. Every CDMC term is explained the first time it appears.

By the end of this tutorial:

You will be able to explain why CDMC was created and what problem it solves for organisations moving sensitive data to the cloud.
You will be able to name the six components of CDMC and describe the 14 key controls in your own words.
You will be able to define core vocabulary such as authoritative data source, provisioning point, entitlement, consumption purpose and lineage.
You will be able to outline an automation-first implementation, including the roles, metadata and evidence it needs.
You will be able to describe the difference between a readiness assessment and a certification assessment, and who may perform each.
You will be able to apply the controls to a realistic migration and spot the most common mistakes.
You will be able to position CDMC next to DCAM, ISO/IEC 27001, the CSA Cloud Controls Matrix and privacy regulations.

Lesson 1 – Origins, purpose and scope

The problem CDMC was built to solve

Around 2019 and 2020, many large financial institutions were moving from cautious cloud experiments to serious migrations of production data. Customer records, trading data, risk data and employee information started to leave tightly controlled data centres for cloud data warehouses, object stores and analytics services. Moving data is easy; moving the controls around it is not. In an on-premises world, many controls were implicit: a database sat behind a firewall, a small team knew who owned it, and access was handled by tickets. In the cloud, a developer can create a new storage bucket or table in seconds, copy data to another region with one command and share it with a partner through a managed service. Without deliberate design, governance falls behind the speed of the platform.

Regulators and boards asked familiar questions in this new setting. Where is our sensitive data? Who owns it? Who can see it, and why? Has it left the country? How long do we keep it? Can we prove all of this to an auditor? Each cloud provider offered tools to answer parts of these questions, but every bank was writing its own checklist, and every provider was answering a slightly different questionnaire from every customer. That duplication was slow and expensive for everyone.

How the framework was developed

The EDM Council, a cross-industry trade association for data management and analytics best known for its DCAM capability model, set up a CDMC working group in July 2020. According to the council, more than 300 professionals from over 100 organisations took part over roughly 18 months. Participants included the major cloud service providers (Amazon Web Services, Google Cloud, IBM and Microsoft), many financial institutions, consultancies and technology firms. The working group was co-chaired by Morgan Stanley and the London Stock Exchange Group (LSEG), and Capco provided project management.

The 14 key controls were published first, in July 2021, because they answered the most urgent need: a short list of concrete, testable expectations for sensitive data. The full framework, version 1.1, followed in September 2021. At launch the council described it as six components, 14 capabilities and 37 sub-capabilities, with the 14 key controls at its heart.

Purpose

CDMC has three closely related purposes:

A shared definition of good practice. It gives data owners, security teams and cloud providers one vocabulary and one set of expectations for managing data in the cloud.
Automation by design. Its controls are written so that a platform can enforce and monitor them continuously, using metadata, policies and alerts, instead of relying on periodic manual reviews.
Assurance. It supports scored readiness assessments and formal certification, so organisations and cloud solutions can show evidence that controls are in place.

Scope

CDMC applies to data held or processed in public cloud, private cloud, multi-cloud and hybrid arrangements. Its key controls focus on sensitive data: personal information, client confidential information, material non-public information (MNPI) and any other category an organisation decides needs special protection. It is industry-neutral even though financial services shaped its first version; healthcare, telecoms and public sector bodies face the same questions about sensitive data in the cloud.

It is also important to know what CDMC is not. It is not a law or regulation, and nobody is legally required to adopt it. It is not a full information security standard: it does not cover every topic in an information security management system, such as physical security or human resources security. It is not a product: no single tool "is" CDMC, although several vendors and cloud providers have built features and reference architectures that support it. And it is not a replacement for enterprise data management: the council positions CDMC as the cloud-specific companion to its broader DCAM model.

Lesson 2 – Key concepts and vocabulary

CDMC sits where data management, security and privacy meet, so its vocabulary draws on all three. Learn these terms before you look at the controls; most confusion in CDMC projects comes from teams using the same word differently.

Data asset – any identifiable collection of data that is managed as a unit, such as a table, a file set, a dataset, a stream or an API. Controls are applied and evidenced at the asset level.
Sensitive data – data that would cause harm to people or the organisation if exposed, altered or misused. Typical classes are personal information, client confidential data and material non-public information. Each organisation defines its own list and the rules for each class.
Data catalogue – a searchable inventory of data assets and their metadata (technical details such as schema and location, and business details such as owner, meaning and classification). CDMC expects the catalogue to be populated automatically.
Metadata – data about data. In CDMC, metadata is the main control mechanism: tags such as owner, sensitivity, approved location or retention period drive automated decisions.
Classification – assigning each asset, and often each column or field, to a sensitivity category according to a defined scheme, preferably by automated scanning with human review.
Data owner – the accountable business person or role who decides how a data asset may be used and who answers for its quality and protection. A data steward does the day-to-day work of maintaining definitions, quality and metadata on the owner's behalf.
Authoritative data source – the recognised, trusted origin for a particular kind of data, the one other systems should take it from instead of making their own copies.
Provisioning point – an approved place or interface through which consumers obtain data from an authoritative source, for example a curated dataset, a governed view or a data product published to the organisation.
Entitlement – a recorded permission that lets a person, group or system access a data asset. Managing entitlements means granting, reviewing, enforcing and revoking these permissions, and logging their use.
Data consumption purpose – the documented business reason for which a consumer is allowed to use data. CDMC links access to sensitive data with agreed purposes, which is the basis for ethical and lawful use.
Data sovereignty – the principle that data is subject to the laws of the country or region where it is stored or processed. Cross-border movement is any transfer or access that crosses those boundaries.
Data protection impact assessment (DPIA) – a structured assessment of privacy risk before processing personal data, often required by privacy laws when risk is high. Some organisations call it a privacy impact assessment (PIA).
Retention schedule – the rules that say how long each kind of data is kept and what happens at the end: archiving, deletion (purging) or review.
Data quality – how fit data is for its intended use, measured along dimensions such as completeness, accuracy, timeliness and consistency.
Data lineage – the record of where data came from and every movement and transformation it went through to reach its current form. Provenance is the origin part of that story.
Shared responsibility model – the split of duties between the cloud provider (securing the underlying infrastructure and services) and the customer (configuring them and governing its own data). CDMC controls are mostly customer responsibilities, supported by provider features.
Readiness assessment and certification assessment – the two kinds of CDMC assessment. The first is a scored analysis that can be self-run; the second is a formal audit by an authorised partner. Lesson 5 explains both.

A useful way to remember the vocabulary is to ask four questions about any data asset: what is it (catalogue, classification), whose is it (owner, authoritative source), who may use it and why (entitlements, consumption purpose, sovereignty), and what happens to it over time (protection, quality, retention, lineage, cost). The six components of CDMC follow almost exactly this order.

Lesson 3 – Structure of the framework

Four layers

CDMC is organised in layers that go from broad themes down to testable checks. At the top are six components, the major themes of cloud data management. Each component contains capabilities (14 in total), which describe what an organisation must be able to do. Capabilities break down into sub-capabilities (37 in total), which are the detailed practices an assessor looks for. Alongside this hierarchy sit the 14 key controls: a condensed set of the most important, automatable expectations for sensitive data, grouped under the same six components. For each key control, the council's documentation describes objectives, the questions an assessor asks, the artefacts that count as evidence and the criteria used for scoring.

Figure 1 – How CDMC is layered, from six components down to the evidence an assessment examines.

Why two views, capabilities and key controls? The capabilities describe a complete, mature cloud data management practice, including business cases, design principles and operating routines. The key controls pick out the points where weakness causes the most harm to sensitive data and where automation is both possible and essential. Many organisations start with the key controls, then grow into the full capability model.

The six components and their key controls

The table below lists the six components and the key controls grouped under each one, with a plain-language paraphrase. The names follow the publicly used short titles; the official wording, objectives and test steps are in the council's documents.

Component	Key controls	What it is about, in plain words
1. Governance and accountability	1 Data control compliance · 2 Ownership field · 3 Authoritative data sources and provisioning points · 4 Data sovereignty and cross-border movement	Somebody is accountable for every sensitive asset, trusted sources are known, location rules are respected, and compliance with all controls is measured continuously.
2. Cataloguing and classification	5 Cataloguing · 6 Classification	Every asset is discovered and described automatically, and its sensitivity is known.
3. Accessibility and usage	7 Entitlements and access for sensitive data · 8 Data consumption purpose	Only the right people get access, for an agreed reason, and their use is tracked.
4. Protection and privacy	9 Security controls · 10 Data protection impact assessments	Sensitive data is encrypted or de-identified as required, with evidence, and privacy risk is assessed when the situation requires it.
5. Data lifecycle	11 Data retention, archiving and purging · 12 Data quality measurement	Data is kept only as long as needed, then archived or deleted, and its quality is measured.
6. Data and technical architecture	13 Cost metrics · 14 Data lineage	The cost of each asset is visible, and the origin and movement of data are recorded.

The 14 key controls in your own words

Here is what each control expects, paraphrased. Notice how often the words "automated", "metadata" and "evidence" come up; that is the signature of CDMC.

Data control compliance. Compliance with the controls is monitored for every sensitive asset through metrics, and gaps trigger automatic notifications. In effect this is the control that watches all the other controls.
Ownership field. The catalogue records an owner for each sensitive asset. Where the owner is missing, a defined workflow assigns one; nobody simply hopes it gets filled in.
Authoritative data sources and provisioning points. A register shows which sources are authoritative for sensitive data and through which approved points consumers obtain it, so copies of copies can be recognised and reduced.
Data sovereignty and cross-border movement. Where sensitive data is stored, processed and accessed is recorded, and movement across borders is controlled and audited according to policy.
Cataloguing. Assets are added to the catalogue automatically when they are created or ingested, consistently across all environments. The matching capability also expects catalogues to be interoperable, so that metadata can be exchanged between them.
Classification. Sensitivity classification is applied automatically, for example by scanning content for personal identifiers, and recorded in the catalogue.
Entitlements and access for sensitive data. By default only the creator and the owner can reach sensitive data; any further access is granted deliberately, recorded and tracked.
Data consumption purpose. Every data sharing agreement that involves sensitive data states the approved consumption purpose. Implementations typically link that purpose to entitlements so that actual use can be compared with it.
Security controls. Appropriate protections such as encryption and masking or de-identification are enabled according to the classification, and evidence that they are active is recorded in the catalogue.
Data protection impact assessments. For personal data, the platform starts an impact assessment by itself, based on which country's or region's privacy rules apply, instead of depending on someone remembering to request one.
Data retention, archiving and purging. Each asset carries its retention rules, and archiving or deletion happens according to that schedule rather than by memory.
Data quality measurement. Quality measurement is switched on for sensitive data, and the resulting metrics are shared with owners and consumers when they are available.
Cost metrics. Cost information for data assets, such as the cost of storing, using and moving it, is captured and made available, typically through the catalogue, so owners can make informed decisions.
Data lineage. Lineage information, meaning the origin of data and its path through systems, is available for all sensitive data, so that impact and trust can be judged.

The capability view

The 14 capabilities cover the same ground at a broader level. Under governance and accountability, the framework expects business cases for cloud data management, established ownership for both migrated and cloud-born data, governed sourcing and consumption, and managed sovereignty. Under cataloguing and classification, it expects catalogues that are implemented, used and interoperable, and classification schemes that are defined and applied. Accessibility and usage covers entitlement management and ethical use of data. Protection and privacy covers security with evidence and an operating privacy framework. Data lifecycle covers lifecycle planning and quality management. Data and technical architecture covers technical design principles (including cost awareness) and provenance and lineage. The 37 sub-capabilities then spell out the detailed practices behind each of these.

Notice two things about this structure. First, it starts with governance: the controls only work if accountability and policy exist. Second, it ends with architecture: CDMC expects data management to be designed into the platform, not bolted on afterwards.

Lesson 4 – How CDMC works in practice

The automation-first idea

The most important practical idea in CDMC is that controls should be enforced and monitored by the platform itself. In a traditional approach, a governance team sends spreadsheets to data owners each quarter, asks them to confirm their datasets and access lists, and files the answers. That approach cannot keep up with a cloud environment where hundreds of tables appear each week. CDMC instead expects a feedback loop: new data is discovered automatically, described with metadata, checked against policy, and any gap is routed to a person or fixed by automation, with the result recorded as evidence.

Figure 2 – The automated control loop CDMC expects: discover, describe, check, protect or fix, and record evidence.

Metadata is the glue. If a table carries tags such as "sensitivity: personal data", "owner: retail lending", "approved location: EU" and "retention: seven years", then the platform can decide automatically who may query it, whether a copy to another region is allowed, which encryption and masking policies apply and when the data must be archived or deleted. Most cloud providers offer the building blocks: a catalogue service, a scanner that detects personal data, tag-based access policies, location restrictions, key management, audit logs and lineage capture. CDMC tells you which of these must be connected and what evidence they should produce.

Roles

CDMC is a cross-functional framework. A typical implementation involves:

Executive sponsors – usually the chief data officer together with the chief information security officer, sometimes with the chief privacy officer. They approve the policy and the scope.
Data owners – business leaders accountable for specific data domains, such as customer data or trading data. They approve access, purposes and retention.
Data stewards – maintain metadata, definitions and quality rules, and work through the exceptions the platform raises.
Cloud and data platform engineers – build the automation: catalogue integration, classification scans, policy-as-code, tagging services, dashboards.
Security and privacy teams – define protection requirements per sensitivity class, own key management and run privacy impact assessments.
Data consumers – analysts, data scientists and applications that request access and declare their purpose.
Risk, compliance and internal audit – define how compliance is measured and test the evidence.

Implementation steps

There is no single mandated method, but successful programmes tend to follow a similar sequence:

Set scope and policy. Decide which cloud platforms, environments and data domains are in scope, and write or update the data policy so that each CDMC expectation has an owner and a rule. Define the sensitivity classes and what each one requires.
Baseline with a readiness assessment. Score the current state against the framework to find the biggest gaps. Lesson 5 covers how.
Build the metadata foundation. Connect the catalogue to every data store, define a standard tag template (owner, sensitivity, authoritative flag, approved location, retention, cost and so on), and fill tags from reference tables wherever possible.
Automate classification and protection. Run content scans, map findings to sensitivity classes, and attach access and masking policies to those classes rather than to individual users.
Govern access and purpose. Introduce request workflows that capture purpose, record sharing agreements, and default sensitive data to owner-only access.
Manage location and lifecycle. Restrict where sensitive data can be stored, alert on cross-border movement, and drive retention actions from tags.
Measure and report. Publish compliance metrics per control, per domain and per platform, and alert owners when something drifts.
Collect evidence and improve. Keep logs, reports and configuration snapshots that show each control working over time; re-assess periodically.

Artefacts you will typically produce

Assessors look for evidence, not intentions. Common artefacts include the data policy and standards, the classification scheme, the catalogue tag template, the register of authoritative sources and provisioning points, data sharing agreements with purposes, the retention schedule, privacy impact assessment records, compliance dashboards and their history, access logs, encryption and key management configurations, data quality reports and lineage graphs.

Shared responsibility in a CDMC context

Cloud providers secure the infrastructure and supply the tools, but the customer decides what is sensitive, who owns it and who may use it. A provider's reference architecture can make the controls much easier to implement, but it does not transfer accountability. A practical rule: the provider can give you a classification scanner; only you can decide that a column containing account numbers is "client confidential" and must be masked for analysts.

Lesson 5 – Assessment, certification and compliance

Two kinds of assessment

The EDM Council offers a two-stage assurance path for CDMC:

Readiness assessment. A scorable analysis of existing cloud data management capabilities against the framework. An organisation can run it itself, or engage a CDMC Authorized Partner (a firm the council has approved to deliver CDMC assessments) to run it. Its purpose is to find gaps and plan remediation; it does not lead to a certificate on its own.
Certification assessment. A formal audit, which the council compares to the style of a SOC 2 report or an ISO/IEC 27001 certification audit. It must be performed by a CDMC Authorized Partner. Successful certification earns a CDMC certification digital badge, which is valid for 12 months, so certification has to be renewed to stay current.

Each control comes with scoring criteria, and every score has to be backed by evidence an assessor can inspect. A statement such as "we always classify new tables" earns little credit unless the assessor can see the scanning configuration, the resulting tags and the reports that show coverage over time.

Figure 3 – A typical assurance journey from self-assessment to certification and annual renewal.

Who can be certified

Two kinds of party pursue CDMC certification:

Organisations that use the cloud, such as banks and insurers, certifying their own cloud data management for a defined scope.
Cloud service providers and solution vendors, certifying that a product or reference architecture supports the controls. According to the council, they can certify against specific key controls or all 14. For example, in June 2023 Google Cloud announced that a reference architecture built on BigQuery and its data catalogue had been accredited as a CDMC Certified Cloud Solution, with the assessment facilitated by KPMG; the published design implements all 14 key controls with tags, scanners, policy engines and a reporting service. Other vendors and providers have published their own certifications.

Understand what a solution certification means. It shows that the solution can support the controls when deployed and configured as described. It does not make a customer compliant: the customer still has to deploy it, define its policies and owners, and produce its own evidence.

Individual training

Separately from organisational certification, the EDM Council offers CDMC training courses with a professional certification for individuals. Course names, formats and fees change, so check the council's site rather than relying on any list you see elsewhere.

Compliance and regulation

CDMC is voluntary. No regulator requires CDMC certification by name. Its value for compliance is indirect but real: the controls produce exactly the kind of evidence that supervisors, privacy authorities and auditors ask for under data protection laws, outsourcing and cloud guidance, operational resilience rules and risk-data expectations. A CDMC programme can therefore become the engine that feeds many compliance reports. Be careful in conversations: say "aligned with CDMC" or "CDMC certified for scope X by partner Y" rather than "CDMC compliant", which has no defined meaning.

Lesson 6 – Worked example: Harbour Mutual moves customer analytics to the cloud

Harbour Mutual is a fictional mid-sized insurer with operations in two European countries and a claims-processing team in Asia. It plans to move its customer analytics warehouse, which holds policyholder details, claims history and health information for some products, to a cloud data warehouse. The board wants the migration done within a year and asks for independent assurance that sensitive data will be at least as well controlled as before. The chief data officer and CISO choose CDMC as the yardstick.

Step 1 – Scope, policy and baseline

The sponsors define scope: one cloud provider, the production analytics environment, and three data domains (customer, policy, claims). They update the data policy with three sensitivity classes: "public", "internal" and "restricted", where restricted covers personal data, health data and anything that could reveal pricing strategy. A two-week self-run readiness assessment shows strong security basics (encryption is on everywhere by default) but weak ownership, no register of authoritative sources, manual retention and no lineage.

Step 2 – Catalogue and ownership

The platform team connects the cloud catalogue so every dataset and table in the warehouse is registered automatically when created. They define a tag template with fields for owner, steward, sensitivity class, authoritative flag, approved location, retention period, end-of-life action and monthly cost. Owners are filled from a reference table that maps each dataset prefix to a business domain. A nightly report lists any restricted table without an owner and opens a ticket for the domain's data steward. In the first week the report finds 140 tables with no owner, mostly analyst scratch copies; most are deleted, the rest assigned.

Step 3 – Classification and protection

A content scanner checks new and changed tables for personal identifiers such as names, policy numbers, dates of birth and health terms. Findings are mapped to the "restricted" class and written into the column-level tags. Access policies are attached to the class, not to people: restricted columns are masked for everyone except roles that the owner approves. Encryption keys for restricted data are customer-managed, and the key configuration is exported weekly as evidence.

Step 4 – Access, purpose and sovereignty

New tables containing restricted data are reachable only by their creator and owner. Analysts request access through a workflow that records the business purpose, for example "fraud analytics for motor claims", and the owner approves a sharing agreement with an end date. Queries carry a purpose label, and audit logs let stewards compare actual use with the agreed purpose. The organisation policy restricts storage of restricted data to EU regions. When the claims team in Asia needs to work on claims data, a privacy impact assessment is triggered automatically by the combination of "restricted" data and a non-EU access location; the outcome is a masked, aggregated provisioning view instead of raw records.

Step 5 – Authoritative sources, lineage and quality

The data office registers the policy administration system and the claims system as the authoritative sources, and two curated warehouse datasets as their provisioning points. Ingestion pipelines record lineage from source to report, so when a regulator questions a claims ratio, the team can show exactly which source tables fed it. Quality rules check completeness and validity of key fields on restricted data every day; scores below agreed thresholds alert the steward and appear on the owner's dashboard.

Step 6 – Lifecycle and cost

The retention tag drives a scheduled job: claims data is archived to cheaper storage after the active period and purged when the legal retention period ends, with a deletion log kept as evidence. Billing exports and query statistics are joined to the catalogue so each dataset shows its monthly storage and compute cost. Owners discover that three large historical copies cost more than the rest of the domain together and agree to retire them, which also reduces risk.

Step 7 – Monitoring and assurance

A compliance dashboard shows, for each of the 14 controls, the percentage of restricted assets that pass, with trends over time. After six months of stable results, Harbour Mutual engages a CDMC Authorized Partner for a readiness review, fixes two remaining gaps (lineage for a legacy feed and evidence of purge execution), and then passes the certification audit for the defined scope. The digital badge is added to the board's assurance report with a reminder to renew within twelve months.

Concern	Before	After CDMC
Ownership	Known informally for the main tables only	Tag on every restricted asset; missing owners routed automatically
Classification	Spreadsheet maintained once a year	Automatic scan on every new or changed table
Access	Granted per person by ticket, rarely reviewed	Default owner-only, purpose-based requests, usage tracked
Location	Assumed, not checked	Enforced by policy; cross-border access triggers an impact assessment
Retention	Manual clean-ups when storage filled up	Tag-driven archive and purge with deletion logs
Evidence	Collected by hand before each audit	Continuous metrics and stored history

The lessons from the example are the lessons of CDMC: start from policy and ownership, make metadata do the work, design defaults that are safe, and collect evidence as a by-product of normal operation.

Lesson 7 – Relationship to other standards and frameworks

CDMC rarely stands alone. Most organisations that adopt it already have an information security management system, a privacy programme and some kind of data management model. Knowing how they fit together avoids duplicate work.

Figure 4 – CDMC takes direction from broader data, security and privacy frameworks and turns it into automated cloud controls and evidence.

Framework	Owner	Focus	How it relates to CDMC
DCAM (Data Management Capability Assessment Model)	EDM Council	Enterprise-wide data management capability; the current DCAM v3 has eight core components, 34 capabilities and 101 sub-capabilities	The sibling model. DCAM covers the whole data management function in any environment; CDMC adds cloud-specific, automatable controls. Many firms assess both.
ISO/IEC 27001 with ISO/IEC 27017 and 27018	ISO and IEC	A certifiable information security management system, plus cloud security and cloud PII protection guidance	Broader security scope (people, physical, supplier, incidents). CDMC goes deeper on data ownership, cataloguing, purpose, quality, lineage and cost. Controls such as encryption and access overlap.
CSA Cloud Controls Matrix (CCM)	Cloud Security Alliance	Cloud security control objectives for providers and customers, with the STAR assurance programme	Security-centred and mapped to many standards; CDMC is data-centred and asks for data management metadata that CCM does not focus on.
NIST Cybersecurity Framework 2.0 and NIST Privacy Framework	NIST	Outcome-based frameworks for managing cybersecurity and privacy risk	Useful high-level structures for risk programmes; CDMC controls can serve as concrete implementations of their data-related outcomes.
GDPR and similar privacy laws	Legislators and regulators	Legal duties for personal data, including impact assessments for high-risk processing	Legal obligations; CDMC controls 4, 8, 10 and 11 help meet them by tracking location, purpose, impact assessments and retention.
BCBS 239	Basel Committee on Banking Supervision	Principles for risk data aggregation and risk reporting in banks	Regulatory expectations on data quality, lineage and governance; CDMC controls on ownership, authoritative sources, quality and lineage provide supporting evidence in the cloud.

Two practical tips follow. First, build one control library and map each internal control to every framework that needs it, so a single piece of evidence (for example, the encryption key configuration report) satisfies ISO/IEC 27001, CCM and CDMC at the same time. Second, use DCAM or another enterprise model to make sure the organisation-wide basics (data strategy, funding, data culture) exist; CDMC controls rest on those foundations and struggle without them.

Common pitfalls and best practices

Pitfalls

Treating CDMC as a security checklist only. Teams focus on encryption and access and ignore ownership, purpose, quality, lineage and cost. Assessors will find the gaps, and the business benefits are lost.
Manual controls dressed up as automation. A quarterly spreadsheet of owners does not meet the spirit of controls designed for continuous enforcement. It also falls out of date within days in a busy cloud environment.
Assuming the provider's certification covers you. A certified reference architecture shows capability, not your own compliance. Your policies, owners, configurations and evidence are still your responsibility.
Classifying without acting. Tagging data as sensitive is pointless if access, masking and location policies are not driven by those tags.
Scope that is too large on day one. Trying to cover every platform and domain at once delays results and exhausts sponsors. Start with the riskiest domain on the main platform.
Ignoring the data already migrated. Controls are often designed for new data while years of copied tables stay uncatalogued and unowned.
No evidence history. Showing that a control works today is not enough; assessors need evidence that it has operated over a period.

Best practices

Start from policy and accountability. Agree sensitivity classes, owners and rules before buying or building tools; automation needs something to enforce.
Design a standard metadata template. One tag template used across all platforms makes policies portable and reports comparable.
Make safe behaviour the default. Owner-only access for new sensitive data, approved regions only, and encryption on by default reduce reliance on people remembering.
Route exceptions to people with clear deadlines. Automation should detect gaps; stewards and owners should resolve them through tracked workflows.
Use reference architectures from your provider. Published designs and code from cloud providers shorten the build, as long as you adapt them to your own policies.
Measure per control and show trends. A dashboard with the percentage of sensitive assets passing each control gives sponsors a clear picture and gives assessors evidence.
Map once, comply many times. Align CDMC with your ISO/IEC 27001, CCM and privacy controls so evidence is shared.
Plan for renewal. Certification lasts 12 months; keep monitoring running so renewal is a routine check, not a new project.

Summary and key takeaways

CDMC is the EDM Council's framework for managing and protecting data, especially sensitive data, in cloud, multi-cloud and hybrid environments; version 1.1 dates from September 2021 and is free for internal use.
It was built by an industry working group of more than 100 firms, including the major cloud providers and large financial institutions.
Its structure is six components, 14 capabilities and 37 sub-capabilities, with 14 key controls grouped under the same six components.
The components run from governance and accountability through cataloguing and classification, accessibility and usage, protection and privacy, and data lifecycle, to data and technical architecture.
The key controls are designed for automation: metadata tags, policy engines, scanners, workflows and dashboards replace periodic manual checks.
Readiness assessments can be self-run or partner-led; certification assessments require a CDMC Authorized Partner and lead to a digital badge valid for 12 months.
Cloud providers and vendors can certify solutions against some or all key controls, but customers remain accountable for their own policies and evidence.
CDMC complements DCAM, ISO/IEC 27001, the CSA Cloud Controls Matrix and privacy laws; map controls once and reuse evidence.

Reflection questions

Think of one sensitive dataset in your organisation's cloud environment. Which of the 14 key controls would it pass today, and what evidence could you show for each?
Your organisation uses two cloud providers. How would you design a metadata template and catalogue approach so that the same CDMC policies apply on both?
Which roles in your organisation would act as data owners and data stewards under CDMC, and what would change in their daily work?
A business team wants to share customer data with an analytics partner in another country. Walk through the CDMC controls that would come into play and the decisions each one requires.
If your cloud provider offers a CDMC-certified reference architecture, what work would remain for your organisation before it could pass its own certification assessment?