Identify Data Sources and Locations

The Deliverable Is an Inventory

Task 3 has a physical output. A data source inventory lists, for every data element in your requirements, where it lives, who owns it, how you get it, what it costs, what you are permitted to do with it, and how long access takes. It is the bridge between Task 1 (what you need) and the later task of actually gathering data, and it is the document that converts 'the data is around somewhere' into a plan a sponsor can fund.

Internal Systems: System of Record Versus Downstream Copy

Map the internal estate first, in categories:

• Operational databases — the transactional systems where data is authored: billing, CRM, ERP, electronic health records, ticketing.
• Data warehouses and marts — modeled, cleaned, business-defined; convenient, but the transformation may already have destroyed what you need.
• Data lakes and lakehouses — raw and high-volume, with variable documentation.
• SaaS platforms — marketing automation, HR, support tooling; reachable only through an API with rate limits and export restrictions.
• Event and application logs — clickstream, telemetry, audit trails; often the only record of what a user did rather than what the system concluded.

The distinction that matters most is system of record versus downstream copy. The system of record is where a value is authored and corrected. A warehouse table is a copy, shaped by transformation rules, refresh lags and filters someone chose years ago for a reporting purpose. Copies are usually easier to access and are often perfectly adequate — but you must know which you are using and ask what the transformation dropped. Corrections and deletions are the classic casualty: warehouses frequently keep only current state, so the record of what a value was at decision time, which point-in-time correctness demands, has already been overwritten.

External and Third-Party Data

Weather, credit, firmographics, geospatial, market prices, benchmark panels and industry datasets can supply signal your organization cannot generate. Four questions decide whether a feed is usable:

1. Cost — per record, per seat, per call, or annual license, and whether that cost recurs for the operational life of the model rather than only during the project.
2. Licensing and permitted use. This is the gate project managers skip. A license that permits internal analysis may forbid training a model, redistributing derived outputs, or embedding results in a commercial product. Get permitted use confirmed in writing by procurement and legal before the data enters the pipeline.
3. Refresh and continuity guarantees — what the agreement promises about refresh cadence, schema stability, historical restatement and notice of change.
4. Control. A model whose most important feature comes from a vendor feed inherits that vendor's pricing power, outage risk and right to discontinue. Ask now what happens to the model if the feed stops, and record the answer as a risk; it reappears in Domain V contingency planning.

Cloud and Distributed Repositories

Modern data is rarely in one place: object storage buckets, regional databases, subsidiary systems and partner platforms. Establish two things for each — where the data physically sits, and what may cross a border. Data residency rules, whether national law or contractual commitment, may prohibit copying data out of a region, which can force training to happen where the data lives rather than where the platform team would prefer. Egress charges and network paths turn a 'free' internal dataset into a real line item. Multi-entity organizations regularly discover that the same customer table exists in five regions with five schemas and five owners, and that consolidating it is a project in its own right.

Legacy Systems and Archives

The history-depth requirement set in Task 1 is what usually forces this excavation. Deep history lives in the least accessible places: decommissioned mainframe extracts, tape or cold-storage archives, a vendor system nobody has logged into since the migration, fixed-width flat files with no schema. Establish three things. Can anyone still read the format and restore it? Does documentation or living expertise survive — this is where the SMEs from Task 2 matter most? And has retention policy already deleted what you need, which is common and non-negotiable. Recovering three years of pre-migration history is a work package with a cost, a duration and an owner, not a footnote in a status report.

Ownership, Permissions and Lead Time

For every source, document the owner (accountable for the data), the steward (defines and maintains it), the approver (grants access), the classification (public, internal, confidential, regulated), the approved purpose, and the typical approval duration. That last field is what the exam cares about. Approval for a regulated source can take weeks — privacy review, security review, contract amendment, environment provisioning — and it sits on your critical path whether or not you tracked it. Surface access lead time as a schedule risk with a real date, and start the longest approvals on day one of Data Understanding. Detailed privacy clearance is a separate Domain III task; here you are establishing that a path exists and how long it takes.

Data Source Inventory Template

Keep the inventory alive through the phase. It becomes the input to data gathering, the evidence behind the data-sufficiency go/no-go, and the reference the operations team needs at handover.

The Trap: Existence Is Not Availability

The exam repeatedly punishes the assumption that because data exists somewhere, the project can use it. Between existence and use sit ownership, classification, consent and permitted purpose, technical readability, retention limits, residency rules, cost and an approval queue. Treat a source as unavailable until you have a named approver, a stated purpose and a realistic date. And when a source turns out to be genuinely unusable, that is a Data Understanding finding to escalate — feeding back into scope, the business case or the solution design — not a problem to route around by quietly substituting a convenient dataset nobody has assessed.