CBDA organizational-level strategy is Domain 6 of the IIBA Certification in Business Data Analytics: 9% of 75 questions, so about 7 questions [1]. Section 2.6 of the Guide to Business Data Analytics has three tasks: organizational strategy, talent strategy and data strategy [2]. The first five domains describe one analytics initiative. Domain 6 looks one level up: what the organization needs so that many initiatives succeed.
CBDA organizational-level strategy at a glance
Domain 6 is the smallest domain by weight and the widest by scope. The facts:
| Item | Value |
|---|---|
| Domain | Guide Organizational-Level Strategy for Business Data Analytics (Domain 6) |
| Weight | 9% of the exam [1] |
| Exam format | 75 multiple-choice, scenario-based questions in 2 hours [1] |
| Guide section | 2.6: tasks 2.6.1 to 2.6.3, techniques (2.6.4), underlying competencies (2.6.5) and a case study (2.6.6) [2] |
| Expected depth | 17 IIBA competencies: 16 at "General Awareness", 1 at "Practical Knowledge: Follows Rules" [3] |
| Exam fee | $324 (was $405), first year of IIBA membership included; sale runs October 29 to December 31, 2026 [4] |
Last verified: November 2026 (exam facts, competencies and fees on iiba.org).
One small thing confused me at first. IIBA uses three names for the same domain. The CBDA page says "Guide Organization-level Strategy for Business Analytics" [1], the competency page says "Guide Company-level Strategy for Business Analytics" [3], and the guide says "Guide Organizational-Level Strategy for Business Data Analytics" [2]. If you see any of them in a practice set, it is Domain 6.
Competencies do not follow the tasks
The guide has three tasks [2]. The competency list has six groups and 17 items [3]. I think the mapping is the most useful study shortcut for this domain:
| Competency group [3] | Items | Example item [3] | Closest place in the guide |
|---|---|---|---|
| 6.1 Recommend Action | 1 | Transforming analysis results back into policies and procedures | 2.5.3 Manage Change, where analysts oversee this transformation (Guide, 2.5.3) |
| 6.2 Evaluation | 4 | Assessing organizational readiness, including data and automation readiness | 2.6.1 and the case assessment (2.6.6) |
| 6.3 Master Data Management | 4 | Contributing to the maintenance of a glossary (the only Practical Knowledge item) | 2.6.3 data governance; Data Dictionary in Domain 6 (Guide, 3.4) |
| 6.4 Perform Data Curation | 2 | Scanning and cataloging the data assets in a company | 2.6.3 metadata management and the inventory of existing environments |
| 6.5 Metadata Management | 2 | Identifying and applying data privacy rules | 2.6.3 data security and metadata management |
| 6.6 Performance Improvement | 4 | Ensuring that sampling methods are shared across teams | 2.6.2 Establishing Best Practices |
Two details stand out. First, items 6.6.3 (sampling methods shared across teams) and 6.6.4 (analytics requirements for re-use) repeat the guide's best-practice examples almost word for word [2, 3]. Second, the only item where you are expected to apply rules is glossary maintenance [3]. So I assume Domain 6 questions test recognition: which model, which role, which part of a data strategy. Not execution.
The three tasks of Domain 6
The domain "builds on the first five domains" and explores how organizations can "embed analytics initiatives into the organizational architecture and overall decision-making framework" [2]. A side note in the guide puts it shortly: the success of analytics engagements depends on the organization's disposition to analytics [2].
2.6.1 Organizational Strategy
Organizational strategy decides where analytics teams sit and how they relate to business units. The guide notes that many organizations start with proofs of concept or pilots that have a limited impact on their strategic posture [2]. The guide offers models that help move from an "analytics-aware" to an "analytics-driven" organization [2]:
| Model | What it is [2] | Strength the guide names [2] |
|---|---|---|
| Centralized | One analytics team supports other business units; a Centre of Excellence is an example | Upskilling talent, a cohesive team |
| Decentralized | Analytics teams embedded in business units | Closer to the unit's practices; specialized solutions |
| Hybrid | A mix, for example hub and spoke with geographic hubs | Not named separately |
| By function | Teams organized under business intelligence units, IT, the CIO's office and so on | Not named |
How the teams are organized depends on, but is not limited to, seven factors: enterprise data ownership, governance, requirements around outsourcing analytics, competition, industry outlook, supplier and vendor relationships, and the involvement of senior leadership [2].
What else the guide states:
- analytics teams are most effective when they are cross-functional;
- executive leadership support "is a necessity" for analytics engagements to succeed;
- a clear, direct information channel between leadership and analytics teams ensures a shared understanding;
- some organizations that succeeded put analytics directly under a Chief Analytics Officer [2].
The analyst's part is strategic. Systems thinking, conceptual thinking and collaboration with cross-functional stakeholders, including executives, help define the model. The guide names business model canvas, balanced scorecard, benchmarking and market analysis, value chain analysis, SWOT and CATWOE for this work [2].
A sample box in the guide adds a timeline that I find easy to miss. Many organizations start decentralized, with analytics embedded in business units. With maturity in data governance, the model may change, and large enterprises move to a hybrid or centralized shape with standardized practice [2].
Key output: the guide does not name a formal output. In the case study, the result is a recommendation on the model and how it should change over time [2].
2.6.2 Talent Strategy
Talent strategy is how an organization attracts, retains and grows analytics people. Competitive compensation is "one of the main driving factors" [2]. Six other factors help with recruiting and retention: engaging initiatives, working directly with key decision-makers, learning the business, solving complex problems, access to relevant tools, and a culture of trust and appreciation [2].
Beyond recruitment, the guide names three pillars [2].
1. Team structure. A partnership between people with business experience (stakeholders, SMEs, business analysis professionals) and people with technical skills (data engineers, analysts, scientists) [2]. A large organization may have any or all of these roles:
| Role | What it does in the guide [2] |
|---|---|
| Subject matter expert (SME) | Specific knowledge of the business sector or domain |
| Data/solution architect | Designs and develops data systems to capture and store data; generally does not program them (the data engineer does) |
| Data engineer | Develops and maintains data systems |
| Data scientist | Creates and evaluates analytics models |
| Data analyst | Interprets and analyzes data; may work under the direction of the data scientist |
| Experience designer | Builds experience prototypes and visual enhancements for stakeholders |
| Data journalist | Turns results into data stories |
| Business analysis professional | Establishes the scope and uses results to support decisions and their implementation |
Roles overlap and can be merged by size, industry, budget, project plan and capabilities. A business analysis professional with enough analytics and business knowledge can play SME, data analyst and data journalist, and support data architecture, engineering and experience design [2]. The organization-level focus is to set the guidelines for "the right team structure for the right initiative" [2].
2. Learning and development. Capabilities change very fast, so organizations keep upgrading skills in analytics platforms, big data and cloud. The guide's examples are Microsoft's Azure Machine Learning visual modelling and Google's TensorFlow [2]. Strong business and mathematical foundations are "essential competencies", and communication matters too: if stakeholders do not understand the results, "the entire engagement could be at risk" [2]. The three focus areas are business knowledge, technology and analytics platforms, and data communication and translation [2].
3. Best practices. They come from experience, lessons learned, industry trends and knowledge of other industries. The idea is a standard set of tools and techniques that fits the organization. Examples: policies to share sampling methods across teams, keeping subsets of analytics requirements for re-use, and a procedure for securing approval for data access [2].
Exam angle: the role table. Questions like "who turns results into stories" or "who designs but does not program data systems" come straight from it.
2.6.3 Data Strategy
Data strategy plans how data is acquired, stored and used across initiatives, not for one of them. The guide is blunt: "Unplanned analytics initiatives with a weak data strategy can only provide limited business value" [2]. Consolidating data for a single initiative may be enough only for ad hoc results [2].
Organizations with large-scale analytics consider enterprise data architecture, storage, data privacy and governance policies across the data life cycle. As more sources sit outside the analytics team's control, policies on integrity, consistency and relevancy are set. Data gateways from IoT devices, sensors, business applications and processes feed cloud storage [2]. When volume, velocity or the number of initiatives grows, tracking data and data requests gets complex. Without a single source of truth, "a just in time approach, or a self-service strategy" can serve data needs [2].
The four planning considerations, with the guide's definitions [2]:
| Consideration | Definition in the guide |
|---|---|
| Data governance | Rules and policies that manage data assets to ensure high-quality data |
| Data architecture | Models and standards that govern how data is collected, stored and integrated |
| Data security | Activities that protect data from a privacy and confidentiality perspective |
| Metadata management | Administration of information maintained about the data assets |
Technical professionals take inventory of existing environments. All considerations align with a strategic goal and a future state, and business analysis professionals bring this strategic perspective and work with IT and the business on an end-to-end strategy [2].
Exam angle: the four definitions are short and easy to swap. Governance is about rules for quality; architecture is about models and standards; security is about privacy and confidentiality.
Techniques and competencies for Domain 6
The 2.6.4 table lists eleven techniques, all from the BABOK Guide v3, and says the list is not comprehensive [2]:
| Technique (BABOK v3) | Use in Domain 6 [2] |
|---|---|
| Balanced Scorecard (10.3) | Align the data strategy to business objectives and outcomes |
| Benchmarking and Market Analysis (10.4) | Identify problems and opportunities to align the strategy; used with Five Forces, STEEP, CATWOE |
| Five Forces (within 10.4) | Analyze market forces, for example new entrants that rely heavily on analytics |
| Business Capability Analysis (10.6) | Catalogue capabilities and where analytics enhances or restricts them |
| Business Model Canvas (10.8) | See how value is created and where analytics gives an advantage |
| Collaborative Games (10.10) | Help stakeholders build a joint understanding of the strategy |
| Metrics and KPIs (10.28) | How analytics influences enterprise KPIs, and KPIs for the strategy itself |
| Organizational Modelling (10.32) | Find gaps in current organizational models |
| Risk Analysis and Management (10.38) | Mitigate uncertainty, for example an alternate course when engagements fail |
| SWOT Analysis (10.46) | Internal and external context; how analytics mitigates challenges |
| Value Chain Analysis (within 10.6) | Where analytics enhances the value of offerings |
No chapter 3 technique is in this table. Chapter 3 adds a short Domain 6 note to several techniques. Five say they have no significant role, but a small supporting use: Concept Modelling describes the analytics function, Data Dictionary is kept relevant as new terms appear, Decision Modelling and Analysis helps find optimal organization-level practices, Interface Analysis supports robust data models, and stakeholder analysis helps navigate organizational needs for data (Guide, 3.3, 3.4, 3.8, 3.13, 3.16). Data Flow Diagrams are "not specifically used" here, but describe data flows across processes the analytics team uses (Guide, 3.5). One technique has an active use: Survey and Questionnaire helps find the unique considerations of each functional unit during a large rollout of a data strategy (Guide, 3.17).
So Domain 6 is where your BABOK knowledge pays off. Several of these techniques have their own articles here: Business Capability Analysis, Balanced Scorecard and Metrics and KPIs.
Domain 6 is also the only domain in chapter 2 with its own "underlying competencies" section (2.6.5); the other domains have none [2]. It lists four groups, each with a BABOK chapter 9 reference: analytical thinking and problem solving (9.1), business knowledge (9.3), communication skills (9.4) and interaction skills (9.5), for example facilitating between stakeholders and resolving conflicts [2].
How it works in practice: the Retire Inc. case
The 2.6.6 case shows that the answer is rarely a clean "centralize" or "decentralize" [2]. Mai Tan is one of several product owners at Retire Inc., a young company in Singapore. Her team built RetireSafe, a product that shows citizens how prepared they are for retirement. After about twelve months it is the company's largest product investment, the release cycle went from annual to quarterly, and the team doubled [2]. Then other departments ask for its data: to build a prospect repository, cross-sell and design new products [2].
The organization-level questions appear: who decides access, how much to share, what to restrict, how to secure it, which policies are needed, who enforces them and how to avoid inconsistent data silos [2]. Mai compares two options, a centralized analytics team and expertise spread through the company. She uses benchmarking, business capability analysis, organizational modelling and SWOT, and finds that all existing data expertise sits in her product team [2]. The data includes sensitive personal information such as age, income and net worth [2].
| Step in the case [2] | Domain 6 element |
|---|---|
| Other departments want RetireSafe data | Organizational strategy is now needed (2.6.1) |
| Benchmarking shows the role of data architecture and governance | Data strategy considerations (2.6.3) |
| Organizational modelling reveals missing skills | Talent strategy (2.6.2) |
| Sensitive data, regulation | Data security (2.6.3) |
| Pros and cons of two options | Evaluation; not enough on its own |
The recommendation is a sequence. Set data standards and light-weight governance inside the RetireSafe team now, add data experts on short-term contracts, and later move to a centralized function built partly from that team [2]. The reasons were funding, the time to hire, and the risk of decentralizing with low data maturity: silos and "proliferation of unsecured sensitive data" [2].
The guide's takeaways are worth memorizing: it often takes one successful project to "open the floodgates" for data requests, recommendations do not have to be "either-or", and "context is everything" [2]. Maturity, workload, budget and politics drive the decision [2].
A worked example: choosing a model for an online retailer
This example is mine and invented. The seven factors are the guide's [2]. A mid-size online retailer has three analysts in marketing, two in finance and two data engineers in IT. Marketing and finance report different revenue numbers. The CFO sponsors analytics.
| Factor from 2.6.1 [2] | Finding in the example | Leaning |
|---|---|---|
| Enterprise data ownership | No owner per data domain | Central rules needed |
| Governance | None; two revenue definitions | Central rules needed |
| Outsourcing requirements | None | Neutral |
| Competition | Rivals use personalized recommendations | Keep analysts close to marketing |
| Industry outlook | Fast change in channels | Keep analysts close to the business |
| Supplier and vendor relationships | One marketing platform vendor holds key data | Central data agreement |
| Senior leadership involvement | CFO sponsor, direct channel possible | Hub can report to leadership |
The result leans hybrid: a small hub that owns governance, the glossary and metric definitions, and analysts who stay in marketing and finance as spokes. Then the other two tasks follow:
- Talent (2.6.2): a business analyst who also acts as data journalist for leadership updates, instead of a new hire; a shared practice for sampling and re-usable requirements.
- Data (2.6.3): one revenue definition in the glossary, an inventory of sources and their owners, and privacy rules for customer data.
I like this example for one reason: the deciding factor is not the analysts. It is the missing data ownership.
What practitioners and data say about analytics models
The data says most organizations struggle with exactly what Domain 6 covers. A 2018 McKinsey paper, based on a survey of about 1,000 organizations, notes that organizations that start centralized often later "move into a hybrid model of hubs and spokes" [5]. In a 2025 survey of 125 large organizations, the share with a chief data or analytics officer rose from 12% in 2012 to 84.3%, but only 47.6% call the role very successful [6]. Gartner predicts that by 2027, 80% of data and analytics governance initiatives will fail [7].
Practitioners describe the same moves the guide describes:
- Central first, then hybrid. Airbnb's first data scientist describes a central team that was siloed and treated as a resource, and a move to a "hybrid centralized/embedded structure" that still keeps one data science team [8].
- Embedded, then back, then embedded again. A director of data at a research platform ran an embedded team for three years. The first attempt struggled with junior analysts, so they re-centralized for about six months, trained, and embedded again [9].
- The hidden cost of decentralization. A data newsletter author estimates that "upwards 30% of time" of data teams goes to investigating data issues, often caused by upstream changes in other teams [10].
- Knowledge leaves with people. An analytics engineering writer notes that "embedded teams lead to knowledge fragmentation", while central teams lose touch with priorities [11].
- Stand-alone teams fade. A former LinkedIn team lead warns that stand-alone data science teams "risk marginalization" [12].
- Training reduces requests. Airbnb's internal data university reported a fifty percent drop in ad hoc requests from teams that took the training [13].
- Governance is people work. A governance leader at a retailer held about 50 one-to-one conversations before setting priorities [14].
- Leaders who do not back data. A chief data officer in banking says CDOs are set up to fail when executives "mostly trust themselves and their instincts" [15].
From a CBDA angle, candidates describe "scenario-based questions" [16] and warn that "many questions had two confusing answers" [17]. I found no candidate report about Domain 6 specifically. With about 7 questions, that is not surprising.
Experts disagree on where analytics should live
Practitioners agree that the model must fit the context, but not on the default.
1. Hybrid, with a strong hub. Large-company practitioners and consultants describe a hub and spoke model as the mature state [5, 8]. The guide's sample box points the same way for large enterprises [2].
2. Push ownership to the domains. The data mesh author argues that central data platforms created "an architecture and organization structure that does not scale" and proposes domain ownership [18].
3. Centralize governance, not people. The 2018 McKinsey paper says "Data governance, however, should be centralized, even if data ownership is not." [5]
4. Value first, governance second. A Gartner analyst says a governance program "that does not enable prioritized business outcomes fails" [7].
5. The org chart matters less than culture. One analytics engineering writer argues that embedded versus centralized is the wrong level of abstraction, and that shared systems, norms and language build data culture [11]. A data writer goes further and frames the choice for analytics teams as "Disband or rebrand" [19].
My view is close to the guide: start from the factors and the maturity, not from a favourite model. For the exam, the guide's words win. Context is everything, and the answer may be a sequence, not a choice [2].
What the exam looks for in Domain 6
Domain 6 questions reward the answer that fits the organization's maturity. Typical scenarios:
| Scenario | Tempting answer | Guide reading |
|---|---|---|
| One team holds all data expertise; budget is tight; data maturity is low | Centralize now with new hires | Start with standards in the existing team, centralize later [2] |
| Low maturity, sensitive data, a proposal to let every department build its own analytics | Decentralize for speed | Risk of silos and unsecured sensitive data [2] |
| Analytics work stalls without visible support | Hire more data scientists | Executive leadership support is a necessity; direct channel [2] |
| A small team needs data stories but has no budget for a new role | Hire a data journalist | Merge roles; a business analyst can act as data journalist [2] |
| Analysts leave despite good pay | Raise salaries again | Other factors: decision-makers, learning the business, tools, culture [2] |
| Teams use different sampling methods | Let each team decide | Best practice: share sampling methods across teams [2, 3] |
| Many data requests and no single source of truth | Build a warehouse first | Just in time or self-service strategy [2] |
| Which technique aligns data strategy to business objectives? | SWOT | Balanced Scorecard [2] |
How to prepare for the Domain 6 questions
- Learn the three tasks and the competency groups side by side (table above). Know that only glossary maintenance is Practical Knowledge [3].
- Memorize the four organizational models and the seven factors from 2.6.1 [2].
- Learn the eight roles of 2.6.2. In the guide, the data journalist appears only in this task, so it is easy to forget.
- Learn the four data strategy definitions of 2.6.3 [2].
- Re-read the Retire Inc. case and its takeaways [2].
- Revisit Domain 5, because both domains end in policies and procedures: see Use Results to Influence Business Decision Making. Then practice with the CBDA analytics strategy quiz and full mocks in the CBDA exam simulator.
At 9%, this domain deserves less time than Domains 1, 4 and 5 at 20% each [1]. My take: one or two focused sessions are enough if your BABOK techniques are solid.
Check yourself: CBDA practice questions
1. A young company has one product team with all its data expertise. Other departments request its data. Budget is limited and data maturity is low. What should the analyst recommend? A) Build a centralized analytics function now with new hires. B) Let each department build its own analytics team. C) Set standards and light governance in the existing team, then move to a central function later. D) Stop sharing data until a warehouse exists.
Answer: C. This is the Retire Inc. recommendation [2]. A fails on budget and time to hire; B risks silos and unsecured sensitive data.
2. Which role in the guide's team structure turns results into data stories for different levels of stakeholders? A) Experience designer. B) Data journalist. C) Data analyst. D) Subject matter expert.
Answer: B. The experience designer builds prototypes and visual enhancements; the data journalist turns results into stories [2].
3. "The models and standards that govern how data is collected, stored, and integrated" describes which data strategy consideration? A) Data governance. B) Data architecture. C) Data security. D) Metadata management.
Answer: B. Governance is the rules and policies for high-quality data [2].
Key takeaways
- Domain 6 is 9% of the CBDA exam: three tasks in the guide, 17 competencies on iiba.org [1, 2, 3].
- Organizational strategy chooses centralized, decentralized, hybrid or functional models by seven factors [2].
- Talent strategy covers retention, team roles, learning and best practices [2].
- Data strategy rests on governance, architecture, security and metadata management [2].
- Context is everything, and the recommendation can be a sequence [2].
FAQ
What is CBDA Domain 6?
Domain 6 of the IIBA CBDA exam is Guide Organizational-Level Strategy for Business Data Analytics. It weighs 9%, about 7 of 75 questions. It covers how an organization structures analytics teams, builds talent and plans its data, beyond a single initiative.
What are the tasks in the CBDA organizational-level strategy domain?
The guide lists three tasks: Organizational Strategy, Talent Strategy and Data Strategy. Section 2.6 also includes a technique table, a list of underlying competencies and the Retire Inc. case study.
Is a centralized or decentralized analytics team the right answer on the exam?
Neither by default. The guide describes centralized, decentralized and hybrid models and says the choice depends on factors such as data ownership, governance and leadership involvement. Its case study recommends a sequence: standards first, a central function later.
Which techniques matter most for Domain 6?
The guide lists eleven BABOK techniques, including Balanced Scorecard, Benchmarking and Market Analysis, Business Capability Analysis, Business Model Canvas, Organizational Modelling and SWOT. The 2.6.4 table lists no chapter 3 technique, and several chapter 3 techniques state that they have no significant role in this domain.
How much time should I spend on Domain 6?
Less than Domains 1, 4 and 5. One or two focused sessions on the models, roles, data strategy definitions and the Retire Inc. case are usually enough, if your BABOK techniques are solid.
Sources
- IIBA: Certification in Business Data Analytics (CBDA)
- IIBA: Guide to Business Data Analytics, 2.6 Guide Organizational-Level Strategy for Business Data Analytics
- IIBA: CBDA competencies
- IIBA: Certification fees
- McKinsey: Building an effective analytics organization (2018)
- DataIQ: 2025 AI and data leadership executive benchmark
- Gartner: 80% of D&A governance initiatives will fail by 2027 (2024)
- Airbnb Tech Blog: At Airbnb, data science belongs everywhere (2015)
- ResearchGate: Learnings from managing an embedded data team (2020)
- Inside Data: Data team structure, embedded or centralised (2022)
- Analytics Engineering Roundup: Data teams, embedded or centralized (2022)
- O'Reilly: Where should you put your data scientists? (2016)
- Airbnb Tech Blog: How Airbnb is boosting data literacy with Data U (2018)
- Context and Chaos: 4 practical lessons from data governance leaders (2024)
- GDS Group: Why chief data officers don't last long in the job (2023)
- Techcanvass: CBDA certification journey of Aniket (2024)
- Techcanvass: My certification journey, IIBA CBDA (2024)
- martinfowler.com: How to move beyond a monolithic data lake to a distributed data mesh (2019)
- Benn Stancil: Disband the analytics team (2024)