Information Asset Stakeholders and Their Roles

An information asset needs more than a storage location

An information asset is information that has value to the organization and therefore needs to be managed deliberately. It can be a business record, database table, dashboard, contract repository, customer dataset, report, spreadsheet, or document collection.

Consider an employee expense claim. It may begin as a form submitted by an employee, move through an approval workflow, become a payment entry in a finance system, and later support an audit. The same business information is involved in several systems and stages—but the organization still needs answers to basic accountability questions:

• Who creates the claim data?
• Who decides what “valid expense claim” means?
• Who maintains the data’s definitions and quality?
• Who operates the application and protects it from loss or unauthorized access?
• Who is allowed to use the information, and for what purpose?

A useful rule is:

A stakeholder is a person, team, or organizational function with an interest in an asset. A role describes that stakeholder’s responsibility.

A single person may hold multiple roles in a small organization. For example, a finance manager may be both the business owner and a hands-on steward for expense data. In a larger organization, those responsibilities are usually distributed among several people and teams.

It is also important not to confuse a system with a stakeholder. An expense application may automatically produce a payment record, but a person or team must still be accountable for the asset, its use, and its controls.

A federated model: central standards, local expertise

In a large enterprise, a central team cannot personally understand every customer field, clinical code, product category, financial rule, or operational measure. Conversely, if every department invents its own definitions and access practices, the organization loses consistency and control.

A common solution is federated data governance:

• a central governance function establishes shared standards, policies, and oversight;
• business domains retain responsibility for the meaning, quality, and appropriate use of their own information;
• technical teams provide platforms and controls;
• consumers discover and use trusted information within approved boundaries.

Microsoft Purview is designed to support this kind of arrangement.

The practical implication is that governance should not become a distant compliance exercise. It should be connected to the people who understand and work with the asset every day.

The six stakeholder perspectives

The following table gives a practical baseline. Job titles vary across organizations, but the responsibilities should be recognizable.

These categories overlap in real work, but they should not be blurred. In particular, ownership is accountability, not a technical task list.

Producer: creates or captures the asset

A producer is the person, process, or system that creates, receives, captures, or supplies information.

Examples include:

• a customer submitting an order;
• a sales employee entering an opportunity;
• a sensor sending a measurement;
• an application generating an invoice;
• a supplier sending a contract or invoice file;
• an integration pipeline copying a file from one system to another.

The producer is not automatically the owner. An employee may enter an expense claim, but that employee does not decide the organization’s retention rules, accounting definitions, or access policy for all expense claims.

A producer can also introduce quality problems. For example, a form may allow a user to submit a claim without a receipt, or an integration may load an invalid currency code. Identifying the producer helps an organization decide where quality controls should be placed.

Owner: accountable for business value and decisions

The data owner is the business role accountable for an information asset or information domain. Ownership normally belongs close to the business function that has authority to define the asset’s purpose and accept the consequences of poor quality or inappropriate use.

A data owner typically decides or approves:

• the business purpose of the asset;
• its authoritative source;
• quality expectations and priority;
• classification and sensitivity expectations;
• who should be eligible to request access;
• appropriate uses and prohibited uses;
• resolution of major quality, ownership, or access disputes.

For example, a senior Finance Operations leader may own the expense-claim domain. An IT application manager may own the expense application as a technical product, but that does not necessarily make them the business owner of expense information.

A useful test is:

If a dispute arises over what a field means, whether it is fit for a reporting purpose, or whether a new team should receive access, who has the authority to make the business decision?

That person or role is a strong candidate for data ownership.

Steward: makes the asset understandable and usable

A data steward is usually closer to day-to-day information management. The steward translates governance expectations into practical work within a business domain.

Typical stewardship activities include:

• documenting definitions, business rules, and allowed values;
• maintaining glossary terms and asset descriptions;
• monitoring data quality and raising issues;
• helping users locate trustworthy information;
• linking related assets and documenting lineage;
• coordinating with owners, technical teams, and consumers;
• supporting access requests with business context.

For the expense-claim asset, a Finance data steward might document that:

• Claim date is the date the employee incurred the expense, not the reimbursement date.
• Approved amount is the amount authorized after policy checks.
• Claim status can only use approved workflow values.
• Missing receipt references are allowed only for an approved exception category.

The steward does not necessarily have final authority to accept a major risk or redefine a corporate policy. That remains the owner’s decision. The steward makes the asset’s meaning, quality, and usage visible enough for people to work consistently.

Custodian and technical managers: operate and safeguard the platform

A data custodian is responsible for the technical care of information. Depending on the organization, the role may be held by a database administrator, cloud platform team, application operations team, storage administrator, or managed service provider.

Custodial work often includes:

• provisioning and configuring storage or database services;
• implementing approved access controls;
• maintaining backups, recovery procedures, and system availability;
• monitoring technical security events;
• applying encryption and key-management settings;
• patching and operating the infrastructure;
• preserving logs and evidence of technical activity.

The custodian implements controls; the business owner specifies the business requirements those controls must satisfy. For instance:

• the owner decides that only Finance and authorized auditors should access expense claims;
• the custodian configures groups, permissions, logging, encryption, and backups;
• the security team may define the minimum technical standard;
• the steward may help confirm which fields are sensitive and who needs access.

Some organizations use “data steward” and “data custodian” loosely or interchangeably. For practical architecture work, it is safer to distinguish them:

• Stewardship emphasizes business meaning, quality, metadata, and coordination.
• Custody emphasizes technical operation and implementation of controls.

The following short video introduces owner accountability and the protective responsibilities often assigned to a custodian or steward.

Protection is a shared responsibility

“Who protects this asset?” rarely has a one-person answer. Protection is normally a coordinated set of responsibilities.

This is why an owner should not simply say, “IT handles security.” IT operates many controls, but the owner and steward provide the business context: what the data means, which use is appropriate, and how harmful a disclosure or error would be.

Consumer: uses information for a legitimate purpose

A data consumer is anyone who finds, requests, reads, analyzes, reports on, or otherwise uses an asset.

Consumers may be:

• business users;
• analysts and data scientists;
• managers;
• auditors;
• customer-service staff;
• automated applications;
• approved external partners.

Consumers are not passive recipients. They have responsibilities too:

• use the asset only for the approved purpose;
• follow conditions of use;
• protect exports and derived files;
• avoid assuming an asset is trustworthy without checking its description, quality, and provenance;
• report suspected errors, misuse, or access problems.

A consumer may create a new derived asset. For example, a finance analyst may use expense-claim data to create a departmental spending report. That report becomes a new information asset with its own producer, owner, steward, controls, and consumers.

Following one asset through its stakeholder network

Return to the expense-claim record from the previous lesson. Here is a stakeholder map for an organization that uses a cloud expense-management application.

Notice that the asset has one clear business owner, but many contributors. This avoids two common failures:

1. Everyone owns it. In practice, no one makes decisions or resolves problems.
2. IT owns it. Technical teams may operate the system well but cannot reliably decide business definitions, permitted uses, or quality priorities without business authority.

How Microsoft Purview supports these roles

Microsoft Purview does not replace governance roles. It gives those roles a shared place to document assets, definitions, classifications, lineage, quality information, policies, and access-request context.

The diagram highlights an important architectural idea: information can exist across many platforms—such as Azure SQL, Power BI, Microsoft 365, SQL Server, and SaaS applications—while governance metadata can be brought together for discovery and management.

However, a catalog is not the same thing as the underlying data platform. Microsoft’s Purview documentation specifically notes that Data Map and Unified Catalog contain metadata, not the underlying data, and their roles do not themselves grant access to the underlying data. In practice:

• a consumer may discover an asset in the catalog;
• the catalog can show its owner, glossary definitions, quality information, lineage, and access conditions;
• the consumer submits a request with a stated business purpose;
• an approved workflow and the underlying data platform determine whether access is granted.

This distinction is useful for architecture: governance visibility, access approval, and data access are connected but not identical capabilities.

The Unified Catalog demonstration below shows these responsibilities from both the consumer and governance perspectives.

Microsoft Purview uses specific platform role names such as Data Steward, Data Product Owner, Governance Domain Owner, and Data Source Administrator. These are permissions and operational roles within the platform. They should reflect an organization’s real accountability model, not substitute for it.

For example, assigning someone “Data Steward” permissions in a tool does not automatically make them the person who understands the business meaning of every field. Role assignment must follow actual responsibility.

A repeatable method for identifying stakeholders

When you encounter an unfamiliar asset, do not begin by asking, “Which team has the file?” Start with the business context.

1. Name and bound the asset

Describe the asset clearly enough to distinguish it from related assets.

• Too vague: “customer data”
• Better: “Customer master record used by Sales and Customer Support”
• Better still: “Approved customer master record, including customer ID, legal name, contact preferences, account status, and service tier”

The narrower description makes ownership and use easier to identify.

2. Identify the producing event and source

Ask:

• What business event creates or receives this information?
• Which person, process, application, or external party supplies it?
• Which source is authoritative?

For customer master data, the CRM application may be the primary source. For financial invoices, a supplier may be an external producer while Accounts Payable captures and validates the information internally.

3. Find the business owner

Ask who can make decisions about the asset’s business purpose, acceptable quality, and use. Choose the business function with genuine authority, not merely the team that hosts the system.

For example:

• Sales or Customer Operations may own customer master data.
• Finance may own general-ledger information.
• Human Resources may own employee records.
• Procurement may own supplier data.

4. Identify the steward and day-to-day managers

Ask who knows the definitions, common data issues, approved values, and business workflows. This often identifies a steward.

Then identify technical managers separately:

• Who operates the application?
• Who runs the database or storage service?
• Who maintains data pipelines?
• Who performs backup and recovery?

5. Identify protection responsibilities

Ask what must be protected and who performs each protection activity:

• Who classifies sensitive information?
• Who approves or reviews access?
• Who configures permissions?
• Who applies retention?
• Who handles legal holds?
• Who investigates suspected misuse?

This step prevents the vague and risky statement, “Security owns it.”

6. Identify consumers and permitted purposes

List consumers by use case, not only by department. “Finance” is broad; “Accounts Payable staff approving reimbursements” is more useful.

For each consumer group, document:

• purpose of use;
• minimum information needed;
• sensitivity constraints;
• access duration;
• whether they can modify, export, or only view the information.

7. Record the result in an asset profile

A simple stakeholder profile can become the basis for a catalog entry, governance document, or architecture decision.

This is not a full RACI matrix—that comes later in the course—but it gives you enough clarity to understand who should be involved when an information issue arises.

Common role-assignment mistakes

Assigning ownership to the technical host

A cloud team may run the database flawlessly, but it may not know whether “active customer” includes prospects, suspended accounts, or former customers. Technical custody is essential; it is not the same as business ownership.

Naming a department instead of a decision-maker

“Finance owns it” is a useful start but incomplete. A governance model needs a named role or accountable position, such as “Finance Operations Manager,” plus a backup or escalation route.

Treating the steward as the person accountable for every decision

A steward may investigate a quality problem, document its impact, and coordinate remediation. The owner should normally decide whether a risk is acceptable, a definition changes, or investment is justified.

Forgetting consumers

An asset can be technically secure and well documented but still fail if legitimate users cannot find it, understand it, or request appropriate access. Consumer needs should shape metadata, discovery, quality communication, and access workflows.

Assuming a catalog permission grants underlying data access

Catalog visibility can help a user discover and assess an asset. Actual data access is usually enforced by the source system, database, storage service, or application. Keep discovery permissions and data permissions conceptually separate.

Key takeaways

An information asset is governed by people and roles, not by technology alone.

• Producers create, capture, or supply information.
• A business owner is accountable for the asset’s purpose, quality expectations, classification, and appropriate use.
• A steward manages business metadata, definitions, quality coordination, and discoverability.
• A custodian and technical teams operate systems and implement approved controls.
• Protection is shared among owners, custodians, security, privacy, Legal, and records-management functions.
• Consumers use information for approved purposes and must follow its conditions of use.
• A Central Data Office can establish common governance standards while business domains retain responsibility for the information they understand.
• Microsoft Purview supports discovery and governance through metadata; it does not by itself replace data-platform access controls or organizational accountability.

Next, you will turn a business problem into measurable information requirements. The stakeholder map you created here will be essential: requirements are stronger when they specify who needs information, for what decision or process, at what quality level, and under which constraints.