Blyde Financial Services, a fictional South African financial-services group, now has a working platform landing zone. Its four application landing zones are live, and its infrastructure arrives through a few internal patterns built on pinned, verified modules rather than hand-built resources. Then four teams arrive with the same request. Fraud operations wants a model trained on card transactions and case outcomes. Document processing wants to search scanned applications and claims. Customer service wants call summaries joined to complaint history. The employee knowledge team wants policies and procedures in a form an assistant can use.
The data team's first answer is the obvious one: create a large storage account, call it the data lake and give everyone access. Within a quarter there are three copies of the customer table, nobody can say which one the fraud model used, and a folder of scanned identity documents is readable by a team that only needed policy manuals.
The storage was never the problem. A data lake is a place to put data. What Blyde needed was a data landing zone: the governed foundation that decides who owns data, how it is classified, who may read it, how long it is kept and what other teams can safely build on. This part explains what that foundation contains and why analytics and AI should not start without it.
What a data lake gives you, and what it does not
A data lake, in the plain sense, is cheap, scalable storage plus the compute to process what is in it. That is useful. It is also all it is. A lake on its own does not tell you:
- who is accountable for a dataset being correct;
- which fields hold personal or special personal information;
- where a number came from and what transformed it on the way;
- who may read it, and for what purpose;
- when it must be deleted;
- what a consumer can rely on staying the same next month.
Each of those is a decision, and in an unmanaged lake each one is made silently by whoever writes the next pipeline. That is the same failure part 1 described for an empty subscription, one level up. The platform landing zone settles identity, networks, policy, logging and recovery once, so that workload teams inherit them. The data landing zone does the same for data governance.
The data landing zone, defined
In this series a data landing zone is the part of the estate where data workloads run under shared governance services: a catalogue, classification, lineage, access policy, quality checks and retention, with domain teams publishing data products through it. It sits on the platform landing zone and reuses its identity, network, policy and logging. It does not replace them.
The vendors describe the same shape in their own terms, and their terms keep moving, so it is worth being precise about dates.
- Microsoft. The Cloud Adoption Framework's earlier cloud-scale analytics guidance named a data management landing zone for central governance and data landing zones for domain data, each in its own subscription, deployed after an Azure landing zone. Checked on 7 November 2026, the old data landing zone page now resolves to Microsoft's newer unified data platform guidance (updated October 2026). That guidance is built around Microsoft Fabric and Microsoft Purview, and it is organised around data ownership, governance and security baselines, and operational standards for data products.
- AWS. AWS Prescriptive Guidance on data mesh describes a central governance account with producer and consumer accounts. It sets out three ways to build it: Amazon DataZone, the open-source data.all framework, or a custom build on AWS Lake Formation (checked on 7 November 2026).
- Google Cloud. The Knowledge Catalog data mesh quickstart (the product was formerly Dataplex Universal Catalog) maps domains to lakes and teams to zones, and attaches existing storage to zones as assets (checked on 7 November 2026).
The products differ. The pattern does not: a central governance plane, domain-owned data spaces, and a cloud landing zone underneath. That is why this series uses the vendor-neutral term.
Seven things the data landing zone must settle
Each item below is a design decision with an owner, not a tool to buy.
- Ownership. Every dataset that others depend on has a named business owner and a technical steward. At Blyde, card-transaction events belong to the head of fraud operations, not to the data team that runs the pipeline. AI projects expose weak data ownership explains why this is the first thing AI breaks.
- Classification. Fields are labelled when data is published, not when someone asks. Identity numbers, account numbers, health information and biometric data in scanned documents are tagged at ingestion, and the tags travel with copies.
- Quality. Tests run on every load and results are published with the data. A consumer should see that yesterday's load failed before a dashboard or a model uses it. Data quality and observability are operational disciplines covers the practice.
- Lineage. Every published dataset can be traced to its source systems and transformations. For a financial-services group this is also an audit requirement: a fraud model's training set must be reproducible.
- Access. Access is granted by policy, based on classification and purpose, through the platform's identity service. It is not granted by sharing a storage key. Purpose matters as much as role: the knowledge assistant's service identity can read policy manuals but not claims files.
- Retention. Retention rules are attached to data products and enforced by deletion jobs that someone monitors. Retention is a deletion pipeline, not a schedule makes the case.
- Data products. Datasets that others rely on are published as products with a contract, not left as tables that happen to be readable.
If one of these has no owner, the data landing zone has a gap. A catalogue that lists datasets without owners, classifications and contracts is an inventory, not governance.
Producers and consumers both have obligations
The most useful change Blyde made was to write down what producers and consumers each owe, and to record it in the catalogue rather than in a meeting.
The producer, fraud operations in this example, publishes a schema and versions it, classifies every field, runs quality tests on each load and fixes breaks within an agreed time. The consumer uses the product only for its stated purpose, honours access and classification, pins the version it depends on and reports breaks to the owner. The contract between them holds the owner, schema, classification, quality tests and service level, lineage, retention rule and access policy.
A data product is more than a governed table explains what turns a table into a product. The data landing zone's job is to make that cheap: templates for publishing, a catalogue that rejects products without owners or classifications, and quality and lineage tooling that every domain inherits. Without that platform, every domain invents its own version of "governed", and none of them match.
Two trade-offs are worth naming. Contracts slow the first release of a dataset, because someone has to decide what it promises. And a central data team can become a bottleneck if it reviews every product by hand. The fix for the second is the same as for the platform landing zone: the centre sets rules and automates checks, and domains publish on their own.
Classification and POPIA belong in the foundation
Blyde processes personal information about customers, employees and the people who appear in claims and fraud cases. The Protection of Personal Information Act applies to all of it, and some of it, such as health information and biometric data in identity documents, is special personal information, which the Act allows to be processed only under specific authorisations.
The design point is simple. If classification lives only in a spreadsheet, every copy of the data loses it. If classification is a property of the data product, enforced by access policy and carried through lineage, then the knowledge assistant, the fraud model and next year's analytics project all inherit the same rules without having to rediscover them. Which data can AI touch? A traffic-light guide is a practical starting scheme.
Financial institutions also have sector obligations. The Prudential Authority and the FSCA's Joint Standard 2 of 2024 on cybersecurity and cyber resilience took effect on 1 June 2025, the commencement date set by the authorities' Joint Notice 1 of 2024 (checked on 7 November 2026). A data landing zone that knows where sensitive data sits and who can reach it makes those obligations easier to evidence. This is general information, not legal advice. Each institution should confirm which instruments apply to it.
Trusted data is the prerequisite for AI
The next part covers the AI landing zone. It depends on this one in three specific ways.
- Grounding reads products, not storage. A retrieval index built over the raw lake inherits every duplicate and every mislabelled folder. An index built over published data products inherits their owners, classifications and freshness. Data lineage for AI answers shows why lineage must reach as far as the answer.
- Permissions must survive the trip. If a document is restricted in the source, it must stay restricted in the index and in the answer. That only works if access policy is part of the data product and not something each AI team rebuilds.
- Evaluation needs reproducible data. You cannot compare this month's fraud model with last month's if you cannot say which version of the training data each one used.
This is the order the series argues for. Govern the environment first, then govern the data, before you try to govern intelligence built on top of it.
A short test
| Question | Weak answer | Data landing zone answer |
|---|---|---|
| Who owns the customer table? | "The data team" | A named business owner and steward, recorded in the catalogue |
| Which fields are personal information? | "We would have to check" | Classified at publication; the label travels with every copy |
| Did last night's load pass? | Someone notices a broken report | Quality results published with the data; consumers see the failure first |
| Where did this model's training data come from? | A notebook on a laptop | Lineage from source system to versioned data product |
| Who can read scanned identity documents? | Anyone with the storage key | Only identities whose purpose and role permit it, by policy |
| When is it deleted? | "We keep everything" | A retention rule on the product, enforced by a monitored deletion job |
| What happens when the schema changes? | Consumers find out when they break | A versioned release under the contract, announced to known consumers |
If most of your answers sit in the middle column, you have a data lake. That is a reasonable place to start, but it is not yet a foundation.
Key points
- A data lake is storage and compute. A data landing zone adds ownership, classification, quality, lineage, access, retention and data products as shared services.
- It sits on the platform landing zone and reuses its identity, network, policy and logging. It does not create a second estate.
- Vendor terms differ and change. Microsoft's guidance has moved from cloud-scale analytics landing zones to a unified data platform, and AWS and Google describe data mesh with central governance. The pattern is the same in all three.
- Write down what producers and consumers each owe, and enforce it in the catalogue.
- Classification must be a property of the data, so that every downstream AI and analytics workload inherits it.
- The AI landing zone should read published data products, never the raw lake.
This is part 6 of Cloud Foundations, Explained End to End. Previous: Azure Verified Modules: turning architecture standards into deployable building blocks. Next: What is an AI landing zone?
How CloudNala can help
CloudNala reviews data platforms for organisations that are about to put analytics or AI on top of them. We map which datasets others depend on, who owns them, how they are classified and who can reach them. We then design the data landing zone around the gaps: the catalogue rules, the data product contract, classification and access policy, retention enforcement and the lineage your auditors and AI teams will both need. You get a foundation the next AI workload can inherit rather than rebuild.
Background reading: Microsoft, Unified data platform adoption; AWS Prescriptive Guidance, AWS offerings for a data mesh; Google Cloud, Build a data mesh with Knowledge Catalog.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Landing Zone Review or write to us at consult@cloudnala.co.za