Why Data Product Access Still Takes Weeks, and How Governed Provisioning Fixes It

What is data product access provisioning?

Data product access provisioning is the step that turns an approved request into a working permission in the platform where the data lives, such as a warehouse role, a lakehouse grant or a BI workspace membership. It is the last mile of a data product. Everything before it, the definition, the contract and the listing in a data marketplace, tells a consumer what they could have. Provisioning is what lets them actually query it.

A governed access flow has three parts.

• The request. Who is asking, for which product or which of its ports, for what purpose and for how long.
• The decision. A policy check based on the data's classification, followed by approval from the product owner or the domain where the policy requires one.
• The grant. The permission created in the source platform, scoped to what was approved, recorded, and removed when its validity period ends.

Data access management is the broader discipline of deciding who may read, change and share data. Provisioning is where those decisions are executed, one request at a time, and it is where most organizations still lose the most time.

Why does data product access still take weeks?

Access takes weeks because the request crosses several systems and several people, and none of them owns the whole path. In a survey of 801 data experts at US companies, commissioned by Sigma Computing and run by Atomik Research in 2020, 55% put the average turnaround for a data request at one to four weeks. Data products were supposed to shorten that by packaging data into something a consumer can find and trust. They helped with finding. In many organizations, getting access still works the way it did before.

The delay comes from five places.

• Two systems with a ticket between them. The catalog or marketplace describes the product, and an identity tool or a platform administrator creates the permission. The service ticket is the only interface between the two, and it rarely carries the product's owner, contract or classification with it.
• Requests at the wrong level. Consumers often request individual tables, although a real analysis almost always needs several. Each table becomes its own approval, and the consumer finds out about a missing one only after the first grant lands.
• Approvers without context. The person who receives the request often cannot judge it, so it gets forwarded to the data team, then to the owner, then back with a question about scope.
• Manual execution. Once approved, someone writes the grant by hand in each platform the product touches, in between other work.
• No end date. When every grant is effectively permanent, every approval is a high-stakes decision, and careful approvers slow down accordingly.

The expectation on the business side has also changed. When an analyst could spend weeks preparing data before it was useful, a few weeks of waiting for access disappeared in the overall timeline. With AI assistants and agents that can answer a question minutes after they reach the data, the wait for access becomes most of the elapsed time.

How governed data product access works

Governed data product access runs the request, the decision and the grant as one chain, with the product's metadata attached at every step. A typical flow has six steps.

1. Discover. The consumer finds the product in a marketplace by subject, domain or platform, without needing to know which team owns it.
2. Evaluate. Before requesting, the consumer checks the owner, the data contract and its schema, the service levels, the quality checks, the license and whether the product is in production or being retired.
3. Request. The consumer states the use case, the scope (the whole product or specific ports, masked or unmasked personal data, a subset of rows) and the duration.
4. Decide. A policy evaluates the request against the data's classification. Depending on the policy, the access is granted immediately or routed to the approvers it names, such as the product owner or the owning domain.
5. Provision. The approved scope is granted in the platform where the data lives, with sensitive columns masked where the policy requires it, and the grant is recorded together with its reason.
6. Expire. When the validity period ends, the access is removed. Continuing to use the data is a new request and a new decision.

Two details separate a governed flow from a request form bolted onto a catalog. The approver sees the request with the product's owner, contract and classification attached, so the decision can be made where the request lands. And the grant is executed by the same chain that made the decision, so approval and enforcement stay connected.

Ticket-based access vs governed provisioning

The two models differ in where context and accountability live, and the difference in speed follows from that.

Ticket-based access still has a place. Organizations with a mature IT service management process sometimes need provisioning to stay inside it, and a governed marketplace can hand the request over as a ticket. What it should not do is leave the consumer to translate a data product into a ticket by hand.

Why time-bound access matters

Time-bound access gives every grant an end date set at the moment it is approved, and removes the permission automatically when that date arrives. It matters because the default alternative, access that stays until someone revokes it, accumulates. Permissions granted years ago to people who needed them once are a familiar finding in access reviews, and they often exist because removing them was always someone's job and never anyone's priority.

Security frameworks have asked for this for a long time. NIST SP 800-53 includes controls for least privilege, allowing only the access needed for assigned tasks (AC-6), for reviewing assigned privileges periodically and removing those no longer needed (AC-6(7)), and for automatically removing or disabling temporary and emergency accounts after a defined period (AC-2(2)). An end date on a data grant applies the same logic to data access. Least privilege then covers how long access lasts, as well as what it covers.

There is a less obvious benefit as well. Ninety days is an easier decision than forever. When the worst case of a mistaken approval is a bounded period rather than a permanent grant, an approver has less reason to hold a request back.

How long should data product access last?

Match the duration to the use case rather than picking one number for everything. A one-off analysis needs weeks or a quarter. A recurring report or a production pipeline needs longer, ideally aligned with the review cycle of the product's contract, so renewal becomes a deliberate check that the dependency is still wanted. An AI agent working on a defined task should get the shortest period that covers it. Whatever the duration, the approver should be able to shorten what was requested, and the consumer should be able to extend access as a new request rather than as a silent default.

Best practices for data product access requests

These practices apply whatever tooling you use. Each one removes a reason for a request to stall.

• Request the product, not the table. A data product carries its owner, contract and terms. A raw table carries none of them, so the approver has less to go on and the consumer has no agreed schema to rely on.
• Read the contract before you request. The schema, refresh time and quality checks tell you whether the product answers your question. If the product refreshes at 6am and your report runs at 3am, raise it with the owner before you request access.
• Ask for the narrowest scope that covers the use case. Specific ports, a subset of rows and masked personal data give the approver less to weigh, and narrow requests are usually approved fastest.
• Mask personal data by default. Make masked access the starting point and unmasking of personal data an explicit, justified choice.
• Check existing access first. Duplicate requests waste approver time. A good request flow tells the consumer what they already hold and offers an extension instead.
• Put an end date on every grant. Open-ended access should be the exception that needs a reason.
• Give AI agents the same path as people. An agent is a data consumer and needs its own identity, purpose, scope and end date. A shared service account with standing rights hides what each agent can reach.
• Name an owner on every product. A product nobody owns has nobody to approve its access, which is why ownership belongs before publication.

How Dawiso handles data product access

The Dawiso Data Product Platform, currently in public preview, runs the chain described above in one platform. A team defines a data product in the Data Product Wizard, publishes it to the Data Market, and a consumer's request goes through the Access Gate, which handles the approval and provisioning of data access.

Definition happens in seven steps. The Data Product Wizard walks the producing team through Basics, Business Context, Ownership, Data Assets, Ports, Contracts and Review. Publishing requires a named owner, so every product in the market has someone who can answer for it.

Discovery and evaluation happen in the Data Market. Only products in the production workflow state are listed. Each listing shows the product's purpose, output ports, data contract and terms where one is defined, and pricing and license, so a consumer can judge fit before asking for anything.

Requests go through the cart and checkout. With the Access Gate as the checkout target, which is the default, the consumer states the reason, the use case and the duration once for everything in the cart. Each product then gets its own card with the request scope.

• Ports. All offered ports are selected by default, so the whole product is requested unless the consumer narrows it.
• Personal data. Masked access is the default. Unmasking basic or sensitive personal data is an explicit choice, and for sensitive data the consumer picks which protected categories to unmask.
• Row scope. Where the policy requires it, the card asks the consumer to limit the request to a subset of rows, such as the requester's own business unit.
• Existing access. If the consumer already holds access to some of the selected ports, the card says so and can block a duplicate request or offer to extend the current access.
• Outcome preview. Before submitting, the card shows what the Access Gate would grant, for example immediate access, access after approval or a blocked request, together with the approvers and the validity period.

The Access Gate applies its approval policy and provisions the access. The policy can approve a shorter duration than the consumer asked for. Where a validity period is set, the access is removed automatically when it ends. Submitted requests and granted access are tracked under My Access. For a closer look at how the Access Gate works alongside Unity Catalog, see what Dawiso adds to Databricks Unity Catalog.

Organizations that want provisioning to stay inside their existing service management process can set Jira Service Management or ServiceNow as the checkout target instead. Dawiso then raises one request or record per product, and fulfillment follows the organization's own process.

Underneath, the data product model is built on open standards, the Open Data Product Specification, the Bitol Open Data Contract Standard and Open Data Mesh ports, and products can be exported back to ODPS and ODCS. The launch announcement covers the wizard and the standards in more detail.

Sources

• Sigma Computing, survey of 801 data experts and 800 line-of-business employees at US companies, conducted by Atomik Research, March 2020: sigmacomputing.com
• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, controls AC-2(2), AC-6 and AC-6(7)
• NIST Computer Security Resource Center, Glossary, least privilege
• Open Data Product Specification (ODPS), opendataproducts.org
• Bitol, Open Data Contract Standard (ODCS)
• Open Data Mesh, opendatamesh.org
• Dawiso Help, Data Market
• Dawiso Help, Data market checkout targets
• Dawiso Help, Data Product Wizard
• Dawiso Help, Data Product Standard