ISO/IEC 5181

• Abstract:

  This document provides guidelines, methodology and techniques for deriving securely information denoted to as provenance metadata about data assets from multiple sources, intermediaries or users.

• Status: Not Published
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 4 - Security controls and services
• Current Stage: 6000 - International Standard under publication
• Start Date: 25-Sep-2026
• Completion Date: 26-Sep-2026

Overview

ISO/IEC 5181 is an ISO standard focused on information security, cybersecurity, and privacy protection with a specific emphasis on data provenance. It provides guidelines, methodology, and techniques for securely deriving provenance metadata about data assets from multiple sources, intermediaries, or users.

This standard is especially relevant where organizations need to understand where data came from, how it changed, who handled it, and how trustworthy it is. In modern data-driven environments, data provenance supports trust, transparency, accountability, and privacy-aware data sharing across complex digital ecosystems.

For organizations working with dataspaces, industrial data, smart manufacturing, digital twins, and data governance, ISO/IEC 5181 offers a structured way to evaluate and document provenance in a way that supports secure use of data across its lifecycle.

Key Topics

• Data provenance methodology

  • Defines a practical approach for deriving provenance metadata
  • Supports secure handling of data across lifecycle stages

• Verification and validation

  • Helps assess whether provenance claims can be demonstrated or checked
  • Links provenance with trustworthiness and provability

• Value stream semantics

  • Describes how data and production value streams relate
  • Supports comparison between data behavior and operational processes

• Information model

  • Introduces a data provenance information model
  • Includes concepts such as:
    • data flow control model
    • complexity model
    • reference architecture model
    • security and privacy model

• Trust and privacy

  • Addresses how provenance metadata contributes to trust
  • Supports privacy-aware control of associated metadata

• Data governance and dataspaces

  • Relevant for environments where data is shared through governed platforms
  • Supports use cases involving data users, providers, and intermediaries

Applications

ISO/IEC 5181 has practical value in a wide range of data-intensive and security-sensitive contexts, including:

• Enterprise data governance
• Cybersecurity and compliance workflows
• Smart manufacturing and industrial systems
• Dataspace participation and data sharing
• Digital twin and industrial data ecosystems
• Privacy-preserving data exchange
• Traceability of data assets and metadata

Organizations can use the standard to improve confidence in data used for analytics, decision-making, automation, and cross-organization collaboration. It is particularly useful where data must be shared while still maintaining visibility into origin, handling, and trust status.

Related Standards

ISO/IEC 5181 aligns with several related standardization areas and references concepts from other ISO and IEC documents. Relevant neighboring standards and frameworks include:

• ISO/IEC 11179 series - metadata and data element registration
• ISO/IEC 25012 - data quality model
• ISO/IEC 20547-3 - big data reference architecture concepts
• ISO/IEC 23643 - security terminology and concepts
• ISO/IEC TS 5723 - trustworthiness-related terminology
• ISO/IEC 62890 - data ownership and usage permissions context
• ISO/IEC 20151-1 - dataspace-related development context

For organizations building secure, trustworthy, and privacy-conscious data ecosystems, ISO/IEC 5181 provides an important foundation for data provenance management and provenance metadata governance.

FINAL DRAFT
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 27
Information security, cybersecurity
Secretariat: DIN
and privacy protection — Data
Voting begins on:
provenance
2026-07-30
Voting terminates on:
2026-09-24
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/IEC FDIS 5181:2026(en) © ISO/IEC 2026

FINAL DRAFT
ISO/IEC FDIS 5181:2026(en)
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 27
Information security, cybersecurity
Secretariat: DIN
and privacy protection — Data
Voting begins on:
provenance
Voting terminates on:
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO/IEC 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/IEC FDIS 5181:2026(en) © ISO/IEC 2026

© ISO/IEC 2026 – All rights reserved
ii
ISO/IEC FDIS 5181:2026(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 5
5 Data provenance methodology . 6
5.1 General assumptions .6
5.2 Verification and validation principles .8
5.3 Value stream semantics . .8
5.3.1 Correspondence between LC value streams .8
5.3.2 Value stream behaviour .9
5.3.3 Representation of VS semantics .9
5.3.4 Continuity aspect of operating products and data .10
5.3.5 Formal language terms . .10
5.3.6 Processing of trust .11
5.3.7 Quality of data provenance .11
5.4 Value stream description language.11
5.4.1 Using variables .11
5.4.2 Data provenance proposition . 12
5.4.3 Catalogue of narrative of provenance artefacts . 12
5.4.4 Generating a narrative of provenance by example . 13
6 Data provenance information model . 14
6.1 General .14
6.2 Data flow control model .14
6.3 Data provenance complexity model . 15
6.4 Data provenance reference architecture model . 15
6.5 Data provenance security and privacy model .16
Annex A (informative) DP artefacts of narrative of provenance . 19
Annex B (informative) Operational ontology of DP .24
Annex C (informative) Dataspaces for data provenance .26
Annex D (informative) Data provenance constraints derived from regulations .28
Bibliography .29

© ISO/IEC 2026 – All rights reserved
iii
ISO/IEC FDIS 5181:2026(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
ISO/IEC FDIS 5181:2026(en)
Introduction
This document provides guidelines and methods on how to derive data provenance information from a
system of co-operating authenticated stakeholders. Data provenance is valid if, the data value stream
represented by sequences of < data, metadata > tuples, in any life cycle phase of compound industrial data
and production value streams, is always comparable to the value stream of production involving operational
technology. Hence, the < data, metadata > tuples value stream is twinning the production value stream such
that both data and production value streams are isomorphic to each other.
The use and processing of data performed by applications, systems, robots, individuals, agents or companies
[22]
usually is subject of permissions from data owners as applied in ISO/IEC 62890.
“Data owner” is a term that is applied to the rights of a data holder. Data holders have the rights to access,
use, or manipulate their data. The data owner role is understood as an individual or a group of stakeholders
who can have control over certain data attributes like data creation, accuracy or the names or identifiers of
sources, etc.
Data provenance information is useful to all who want to use available data in other applications or want
to decide to make data voluntarily available as a common good in a dataspace that can be subscribed by
various application stakeholders. Identifying and deriving information from the history of metadata events
provide details on the narratives of data provenance and data manipulations. The concept of narration is
used because it visually describes sequences of activities or the state changes of a system. Graphically, a
sequence of state changes or events is a graph trajectory.

© ISO/IEC 2026 – All rights reserved
v
FINAL DRAFT International Standard ISO/IEC FDIS 5181:2026(en)
Information security, cybersecurity and privacy protection —
Data provenance
1 Scope
This document provides guidelines, methodologies and techniques for securely deriving information about
data assets from multiple sources, intermediaries or users, which is denoted as provenance metadata.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
data
data asset
collection of data items that provide value to organizations playing roles like data provider, data intermediary
and data user
Note 1 to entry: Data are a product, hence data are an asset that can be disseminated, shared, distributed, consumed, or
copied by processes or humans involved in the workflow of an enterprise, factory, information and data infrastructure
or human-machine cooperating communities like smart cities, smart factories etc.
3.2
data altruism
voluntary sharing of data without compensation
Note 1 to entry: Voluntary sharing of data is based on consent of certain data subjects to process their personal data
and to get permission from data holders to use non-personal data.
[11]
Note 2 to entry: Data can be shared via a virtual data sharing platform, such as a dataspace.
Note 3 to entry: A certification framework can provide organizations with voluntary authorization by governments
compared to a framework with compulsory authorization.
[25]
Note 4 to entry: In this context, data altruism is interpreted according to Article 2(16) of the EU DGA.
3.3
artefact
constructive, descriptive or semantic element of views on a thing of interest (ToI) as represented by the
semiotic triangle with three views on the ToI
Note 1 to entry: The construction of things view obeys operational engineering constraints, the description view obeys
requirements represented by an ontological language, and the semantics view is given in a notation that supports
reasoning analysis of the past and predictive simulation-based analysis of future behaviour of a ToI.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Note 2 to entry: The ToI can be modelled by an urban digital twin (UDT) which feeds back information from the
performed analysis.
Note 3 to entry: The term artefact is preferred in formal systems because it means an intangible concept in contrast to
a physical object.
3.4
computation
graph computation
sequence of directed edges of a graph (trajectory) that is enabled by annotated rules conditioning the
execution of sequences of edges of the graph
Note 1 to entry: A data graph is an asset that is applied and manipulated along an executable life cycle value stream
(LC VS) trajectory.
Note 2 to entry: A process graph is defined by three things i.e. a set of vertices (i.e. process states), a vertice-disjunct
set of edges (i.e. transitions) and an incidence mapping that maps an edge either into an undirected pair of vertices (i.e.
action), or that maps an edge into a pair of directed vertices (i.e. event). For short, the latter is called directed edge and
the former undirected edge.
Note 3 to entry: Data or process assets both, are modelled by computable graphs, i.e. data graphs or process graphs.
3.5
dataspace
data governance framework and supporting services to build trustworthiness and enable data sharing
through an agreed set of policies, semantic models, protocols and processes
Note 1 to entry: More formally, a dataspace can be considered as a set of data assets annotated with metadata such
as data provenance information, which is organized as a publish-subscribe dataspace that manages many-sorted data
[5]
type items as < n-tuples > , whereby < n-tuples > are defined for n ≥ 2 elements of respective sorts.
Note 2 to entry: sort is a term from applied mathematics that represents a variable i.e. a set of terms of a considered
type.
1)
[SOURCE: ISO/IEC 20151-1:— , 3.1, modified — definition has been modified to align with the context of
this document; notes 1 and 2 to entry have been added.]
3.6
data graph
graphical representation of a data structure using graph artefacts such as vertices, edges and an incidence
mapping
Note 1 to entry: In the data provenance methodology of subclause 5.2, components of a data structure are graphically
represented by tree-like graphs i.e. data graphs.
Note 2 to entry: The graph semantic artefacts allow to represent either data structures or knowledge but also
behaviour of processes or stakeholders that communicate via the dataspace.
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an
incidence mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of
directed vertices.
3.7
process graph
graphical representation of a process using graph artefacts such as vertices, edges and an incidence mapping
Note 1 to entry: The elements of a process are graphically represented by a mesh-network-like graph.
Note 2 to entry: The graph semantic artefacts allow to represent behaviour of processes or stakeholders that
communicate via the dataspace, but also data structures or knowledge.
1) Under development. Stage at the time of publication: ISO/IEC FDIS 20151-1:2026.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an
incidence mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of
directed vertices.
3.8
data governance
process focused on managing the quality, consistency, usability, security, and availability of data
Note 1 to entry: This process is closely linked to the notions of data ownership and stewardship.
[26]
[SOURCE: ISO/TR 14872:2025, 3.3, modified — “information” has been replaced by “data”.]
3.9
data leakage
drain of data that makes the operation phenomenon, including the phenomenon’s data, untrustworthy
Note 1 to entry: The longer the life cycle value stream (LC VS) of operation, the higher the complexity of production.
Higher complexity creates a higher risk of data leakage or other non-authorized manipulations.
3.10
metadata
data that defines and describes other data
Note 1 to entry: to entry In the ISO/IEC 11179 and ISO/IEC 19763 series of standards, the objects being described are
instances of the subclasses of item, e.g. concepts, data elements, services.
[19],[20]
[SOURCE: ISO/IEC 11179-3:2023/Amd 1:2026, 3.2.30]
3.11
provenance metadata
metadata about the provenance of data
Note 1 to entry: Metadata comprises in practice various categories of information about the state of data that is
observable during the life cycle value stream (LC VS).
Note 2 to entry: Metadata derived during the LC VS of processing assets has the purpose to provide trust in the
incorporation of data subscribed from a dataspace.
Note 3 to entry: Metadata annotated to data that are generated and derived during the operation of a physical
machinery (e.g. energy distribution, automated production, self-driving cars) is called the narrative of provenance
(NoP) of the associated data of interest.
Note 4 to entry: By inspecting the NoP, the data of interest can be applied by stakeholders, processes, or individuals
in contexts different from the source contexts. Based on the NoP, interested parties can decide which of their data
subscribed from the dataspace, they want to use as a common good and which not.
3.12
data provenance
ownership and usage history of data of a system, consisting of information that is given by sets of metadata
describing origins, sources of data, parties involved in generating, manipulating, and managing any data
[10]
Note 1 to entry: A similar definition of data provenance is given in VDE SPEC 90009 v1.0 that defines data provenance
(DP) as the origin of the metadata values comprising person, organization, software agent, file or unknown. VDE
[10] [13] [10]
SPEC 90009 v1.0 is based on IEC 61360-1 that defines the attributes for the specification of meta-metadata.
[10]
Note 2 to entry: In this document and in contrast to the VDE SPEC 90009 v1.0 , metadata (values) of data provenance
information are interpreted semantically which means metadata (values) are derived during the life cycle value
streams in the same activity or phase of production from the data and from the production.
[20]
Note 3 to entry: A similar definition of data provenance is given in ISO/IEC 11179-33 that defines provenance as
information on place and time of origin, derivation or generation of a data set, proof of authenticity of the data set, or a
data set of past and present ownership of that data set.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
3.13
provability
verifiability
degree to which something can be reliably demonstrated or formally proven
Note 1 to entry: Defining the data provenance involves specifying provenance evaluation criteria and requirements
that can demonstrate the data provenance of a system in a provable way.
Note 2 to entry: Provability is an important element of the data provenance methodology.
3.14
quality of data
degree to which the characteristics of data satisfy stated and implied needs when used under specified
conditions
Note 1 to entry: Quality of data (QoD), e.g. of a blueprint of car production, is coupled with the quality of the operation
phenomenon of a technical production of a car.
Note 2 to entry: Data are an informational asset that digitally mirrors the behaviour of an operational asset. The
coupling is understood as the technical phenomena of a system’s machinery, e.g. car production, that is tightly coupled
with the mirroring asset of data capturing through sensors and data analysis provisioning to actuators on a high level
of quality of data.
[SOURCE: ISO/IEC 25012:2008, 4.3, modified — preferred term has been made “quality of data” (QoD); Notes
to entry have been added.]
3.15
security
resistance to intentional unauthorized acts designed to cause harm or damage to a digital data asset or to
personally identifiable information captured by a system
Note 1 to entry: Security is the freedom from misuse of data.
Note 2 to entry: In the context of data provenance, “system” includes data and their associated metadata.
[SOURCE: ISO/IEC 23643:2020, 3.16, modified — in the definition, “system” has been replaced by "digital
data asset or to personally identifiable information captured by a system”; Notes to entry have been added.]
3.16
privacy
right of individuals to control or influence information related to them that may be collected and stored and
by whom and to whom that information may be disclosed
Note 1 to entry: In the context of data provenance, privacy refers to control of the data and the associated metadata.
[SOURCE: ISO 7498-2:1989, 3.3.43, modified — Note to entry has been replaced.]
3.17
semantics
mapping between elements of a language and the real world
Note 1 to entry: The semantics of data manipulation can be described in computational terms such as processes,
variables and many-sorted data types.
Note 2 to entry: The semantics of production process based on state changes during life cycle value streaming can be
represented by graphs comprising events and states.
[28]
[SOURCE: ISO/IEC TR 24800-1:2012, 2.5, modified — Notes to entry have been added.]
3.18
semiotic triangle
model that relates linguistic symbols to semantic concepts and to the objects they represent
Note 1 to entry: Linguistic symbols can be terms or signs, possibly from an ontology.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Note 2 to entry: Semantic concepts can be represented by graph vertices and edges.
3.19
sort
data type
variable
formal notion from algebraic data type theory, which describes sub-data types that can be extended to
many-sorted (i.e. complex) data types comprising multiple sets of data
Note 1 to entry: Sorts are algebraic terms that represent sets of data in a dataspace.
Note 2 to entry: The terms data type and variable are synonymous terms for a sort i.e. a set of data items.
Note 3 to entry:
3.20
trust
recognize an asset (something, someone) as being trustworthy in a defined context of use that is of value to
the user
3.21
trustworthiness
ability to meet stakeholders’ expectations in a verifiable way
Note 1 to entry: Depending on the context or sector, and on the specific product or service, data, technology and
process used, different characteristics apply and need verification to ensure stakeholders’ expectations are met.
[SOURCE: ISO/IEC TS 5723:2022, 3.1.1, modified — Notes 2, 3 and 4 to entry have been deleted.]
3.22
validity
proof of a data provenance proposition in certain circumstances or system states that become valid or
invalid
Note 1 to entry: Semiotic mappings is achieved by defining pairs of semiotic artefacts from the three semiotic domains.
By this view, validity is a kind of “weak correctness proof” based on propositions about relationships between semantic
artefacts (declarative), ontological artefacts (descriptive) and physical artefacts (constructive, phenomenological).
4 Abbreviated terms
AAS asset administration shell
CDDL concise data definition language
DP data provenance
DPIM data provenance information model
DS data secrecy
DTw digital twin
HMI man-machine interface
GDPR general data protection regulation
IoT internet of things
MD metadata
MMI machine-machine interface
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
ML machine learning
NoP narrative of provenance
LC VS life cycle value stream
OT operational technology
PII personally identifiable information
QoD quality of data
PIR provenance, identities, rights
RAM reference architecture model
RM reference model
SF smart factory
SM smart manufacturing
ToI thing(s) of interest
TW trustworthy, trustworthiness
UDT urban digital twin
VS value stream
5 Data provenance methodology
5.1 General assumptions
Figure 1 illustrates a < data, metadata > VS, its production VS, and their dynamic interrelationships. In the
figure, the stakeholder types are represented by rectangles, the corresponding activities manipulating
variables are represented by circles, and the narratives of provenance (NoP) are represented by arrows.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Key
1,2 ., 8 reference numbers of DP activities
A, B, C stakeholder DP categories of provider, intermediary, user
NOTE 1 The letters A, B, and C indicate three stakeholder types.
NOTE 2 Ontological artefacts identified in B of the intermediaries are described in an operational manner.
NOTE 3 The numbers 1 to 8 indicate activities on the upper and lower life cycle value stream (LC VS).
Figure 1 — Life cycle value streams of parallel data and production asset processing
The concept of data provenance relies on the following two principles: (a) semantics that is expressed in
[7, 32]
terms of graph artefacts and (b) the physical phenomena that coincide with the derived narratives of
provenance (NoP).
The two principles (a) and (b) are operationalized into 8 activities:
a) Activity 1 and 2: descriptions of the data (key reference 1 of Figure 1) and metadata (key reference 2 of
Figure 1) elements and rules to fit into < data, metadata > pairs;
b) Activity 3: provisioning of required resources (artefacts) for the anticipated asset production processes;
c) Activity 4: cyclic information provisioning from the space of production to the digital data space of
information modelling;
d) Activity 5: observation of LC production VS events and patterns that are of interest to questions of trust;
e) Activity 6: inheritance of data models usually many-sorted data (i.e. multiple sets) and PIR information
from both < data, metadata > VS and production VS to improve quality of production;
f) Activity 7: based on available data manipulation tools, to perform analysis and simulations and if
necessary, provide adjustments to the production processes to synchronize with the data VS models;
g) Activity 8: verification or validation of the expectations of the data user involved in the considered use
case on the production asset (as applied in Annex B and Annex C).
The anticipated value streams (VS) of the production asset life cycle contain not only single data items (i.e.
constants) but also sorted variables that represent sets of data (i.e. data types).
The LC VS model of Figure 1 comprises three basic types of stakeholders.
h) The provider of many-sorted data, metadata and (production) resources is specified by the related
variables md of sort “metadata” and res of sort “resources” (key reference A in Figure 1)
i) The producer of a product asset is specified by variables comprising certificates cert and evidence ev of
sort “dataspace”, or product prod of sort “production space” (key reference B in Figure 1).

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
j) The product/data user stakeholder is specified by the variables uc of sort “trusted UC” and pr of sort
“trusted product” (key reference C in Figure 1).
The < data, metadata > model changes in the path above (Figure 1) correspond to the changes of the
production process in the path below (Figure 1). The < data, metadata > model trajectory at the end of a
considered LC VS represents the user’s expectations on the trusted product that are semantically comparable
i.e. verifiable with the measured qualities on the trusted product and therefore the corresponding data and
production value streams can be trustworthy.
5.2 Verification and validation principles
Figure 1 shows the basic validation and verification principles (as outlined in Annex B and Annex C) of
deriving trust when using data voluntarily made available that stem from different sources while respecting
their histories of changes and manipulations by inspecting metadata narratives of provenance (NoP) on the
data’s life cycle value stream (LC VS).
The two value streams of Figure 1 (i.e. the upper < data, metadata > and the lower production VS) are
intended to be validated or verified against each other. Then both assets, the < data, metadata > model
and the related product can be trusted (activity 8 in Figure 1). To demonstrate this, the expectations from
the < data, metadata > VS is shown to be fulfilled by the production processes that operate in parallel.
In Figure 1, the < data, metadata > model changes in the path above correspond with the changes of the
production process in the path below. The < data, metadata > model trajectory at the end of a considered LC
VS represents the user’s expectations on the trusted product that are semantically comparable i.e. verifiable
with the measured qualities on the trusted product and therefore the corresponding data and production
value streams can be trustworthy.
In the DP methodology represented in Figure 1, authenticity in industrial systems mean that the < data,
metadata > VS is always in relation to the production VS of a thing of interest (ToI) based on operational
[21] [33]
technology. Since, the < data, metadata > tuples VS is twinning the production VS, the corresponding
value streams are isomorphic to each other.
5.3 Value stream semantics
5.3.1 Correspondence between LC value streams
In industrial systems, basically, there are two corresponding value streams the < data, metadata > VS and
the production VS.
In Figure 1, the < data, metadata > VS is the upper stream, starting from the initial < data, metadata > sources
in activities 1 and 2, working through the intermediaries of performing activities 6 and 7 based on acquired
PIR < data, metadata > tuples of measured production qualities, and finally to the expected use cases verified
with the final product in activity 8.
The production VS is the lower stream, also starts from the initial < data, metadata > sources in activities
1 and 2, but is aligned with the production resources that are provided in activity 3. The production VS
then works through the intermediaries of performing activity 5 manufacturing qualities, properties and
capabilities of the resultant asset of a new product. The < data, metadata > tuples information is acquired by
the production VS in activities 4 and 5 and delivered to the upper VS to perform a production analysis or a
simulation for achieving an anticipated high quality of the product.
The production activities provide a proof that the stakeholders’ expectations documented by < data,
metadata > models are achieved on the resulting product asset. This capability is called provability of DP
assertions.
The cyclic process incorporating activities 1 to 7 is a semantic process of generating trust because it
generates various categories of tuple sets of the < provenance, identities, rights > (P, I, R) metadata that
document all activities necessary for the LC VS of production of a product (i.e. the physical asset).

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Metadata capturing occurs in all physical processes during the entire LC VS. It is an ongoing task for the
purpose of creating trust for the use or application of data-of-interest that are subscribed from a dataspace.
For example, in production processes, an asset is basically a product together with its data that result from
stakeholders involved in the same LC VS that is generating, operating, manipulating, decommissioning or
refurbishing the compound LC VS of < data, metadata > tuples and production.
When collecting metadata from observations of the production VS (Figure 1, activities 4, 5) and integrating
these derived metadata into NoPs (Figure 1, activities 6, 7) then these NoPs can be used to prove product
authenticity because of the applied isomorphy property.
5.3.2 Value stream behaviour
The three basic interoperating stakeholders (A, B, C) of Figure 1 reside in different infrastructures that
comprise human, digital and physical resources to set up activities of parallel data processing and production
processes. In the various LC VS stages, processes are required to interact in a trustworthy manner by means
of exchange and forwarding new or manipulated data models via specific dataspaces.
Data models can comprise various data types. A data type is many-sorted which means that there can be
[5]
multiple sorts with variables in one many-sorted (i.e. compound) data type. In the application of the asset
[6]
administration shell (AAS), a sort can be a sub-model or in formal terms, a sort can be represented by a
variable. This is also outlined for each stakeholder in Figure 1.
With respect to data provenance inspections to obtain trustworthiness for some data-of-interest, it is
important to note that generally data is an asset that mirrors model behaviour of production assets during
their production or operation as outlined in Figure 1, activities 1 to 7. The VS are described in terms of
sequences of compound < data, metadata > pairs that describe stories of trusted data manipulations
twinning semantically the sequences of production events.
However, when data are considered as assets, they can be made accessible by an own asset administration
[6]
shell (AAS) sheltering the data like a physical product. A data-product has value to its provider, creator,
or user when data are used in models such as a production process in all its phases of functional and quality
maturity. The value of a data product is related to its stakeholders’ credibility and market economics of data
users.
5.3.3 Representation of VS semantics
Figure 1 represents the LC VS of the incorporated assets i.e. the generation of an initial data including
metadata specifications during operation and the operational (technical) production asset yielding a
product of a certain quality.
The two value streams of Figure 1 operate in parallel and are referred to as a compound data-product
asset. The presentation of the whole LC in Figure 1 is represented by the three stakeholder categories (key
references A, B, C). In the lower stream (production LC VS), the stakeholders manage and manipulate the
production infrastructure and the resources required for the production, and, in the upper stream ( metadata > VS), the verification of the data model, the management of the dataspace and the data prepared
for use by authenticated third parties and the product user.
The provisioning of resources to a production LC VS, comprising data and metadata is required for
[8]
authentication. The producer can involve data and resources from multiple sources for the VS processes of
production.
The quality of the product to be produced is documented by generating metadata that can comprise trust
certificates, collections of evidence about the integrity, authenticity and confidentiality of the assets (i.e.
data, product or production), and stakeholder identities. This documentation can be used by the customer or
user as the metadata evidence required for proving trust and product authenticity. Based on the metadata
evidence, the customer can prove that the documented metadata NoP of any product apply the isomorphy
property, such that both value streams obey the rules of provability.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Figure 1 shows the isomorphic principle, which means that the collected < data, metadata > tuples are in
all LC VS stages in synchrony with the LC VS stages of the production. This is a formal way of applying
provability to LC VS processes.
NOTE 1 Tuples denominate a collection of heterogeneous items that are packaged due to certain constraints.
Stakeholder A (activities 1 to 3) starts the production with a trusted collection of initial data and resources
that semantically initialize the quality of production to be maintained during all activities of the LC VS.
Stakeholder B (activities 4 to 7) continue the production process showing that LC VS stages, data, and
metadata tuples can be updated and evaluated with respect to the operational production stages of a
product. Vice versa, the production activities can be validated against the data model based on LC VS < data,
metadata > tuples. Formally, data and metadata structures can be instantiated with type graphs that can be
manipulated based on a formal grammar.
Stakeholder C (activity 8) finishes the production by comparing the expectations modelled as use cases or
NoPs with the result of production. In case of isomorphy, the model and product comply.
NOTE 2 The capabilities of data and metadata handling are captured by the concept of a dataspace. Data and
metadata can be combined into tuples which are identifiable by valid proposition and can allow stakeholders to
publish and subscribe specified data and metadata tuples to and from the dataspace.
[8]
NOTE 3 A comparable metadata-based content provenance authentication methodology is specified in C2PA
[14] [24]
technical specifications which comprise a” Concise Data Definition Language (CDDL)” to express binary object
data structures and provide tools to human users, for automated compliance checking, data analysis and security.
NOTE 4 The C2PA manifest is a data structure comprising a so-called claim of a collection of assertions. The claim
is hashed by signature. The assertions contain certain information about data with some hashes to bind them to the
manifest.
5.3.4 Continuity aspect of operating products and data
Semantics with respect to data provenance includes LC VS behaviour of a process or system that is
represented by variables that change continuously or discretely over time. In other words, the process
variables range over sets of typed values, formally referred to as “sorts”.
NOTE A process represented by a continuous variable is modelled in terms of graph-theoretical approach
comprising vertices, edges and mappings among vertices. The mapping defines the creation of graph edges in terms
of ordered or unordered pairs of vertices. An ordered pair of vertices is semantically equivalent to an observed event.
An unordered pair is equivalent to a potential event not yet observed i.e. the declaration of an action. The metadata
annotated to the action describes that action by means of ontological artefacts.
The application of production resources require trust in data and resources to be applied or consumed.
Thus, trustworthiness influences the quality of data and production. In a dataspace, trustworthiness can be
derived from metadata annotated to data. Figure 2 illustrates the complexity dependency of quality of data
from the LC VS. The more a data tuple experiences manipulation during the LC VS, the less trust is placed on
the data tuple of interest.
5.3.5 Formal language terms
For the creation of PD metadata, a formal language approach is applied to determine and analyse the
information on data provenance derived from observed data manipulations in a certain LC value stream.
The information contained by the metadata of a thing of interest (ToI) is used by the LC VS stakeholders, to
make decisions on data or product usage.
The approach of data provenance distinguishes between the concepts of metadata comprising information
on data provenance, security, privacy and trust, and formal language terms used for making assertions
about data provenance propositions.
[8]
NOTE The application of propositions in logic depends upon the context of use. For example, in case of capturing
data provenance metadata, a proposition can describe the observation of an event that depends from the binding of all
free variables of the proposition in a certain context.

© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
5.3.6 Processing of trust
Descriptive artefacts of a domain ontology comprise the range of representations from single
data representations to complex knowledge representations, including learned or derived < data,
metadata > tuples based on trusted methods and tools of data provenance information handling and
manipulations.
An example of data provenance value adding based on metadata is shown in Figure 1 by the activities 4
to 7. This cyclic process is called a process of generating trust because it maintains sets of PIR metadata
that document all activities on data and on production of the involved trusted stakeholders, necessary to
produce a physical product asset.
The production documentation by means of NoPs but a
...

ISO/IEC draft FDIS 5181:2026(en)
ISO/IEC JTC 1/SC 27/WG 4
Date: CLEAN (V03.1) 2026-05-12
Secretariat: DIN
Date: 2026-07-15
Information security, cybersecurity and privacy protection — Data
provenance
FDIS stage
ISO/IEC FDIS 5181:2026(en)
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2023 2026 – All rights reserved
ii
ISO/IEC DISFDIS 5181:2026(en)
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 6
5 Data provenance methodology . 7
5.1 General assumptions . 7
5.2 Verification and validation principles . 9
5.3 Value stream semantics . 9
5.4 Value stream description language . 13
6 Data provenance information model. 16
6.1 General. 16
6.2 Data flow control model . 16
6.3 Data provenance complexity model. 17
6.4 Data provenance reference architecture model. 18
6.5 Data provenance security and privacy model . 20
Annex A (informative) DP artefacts of narrative of provenance . 23
Annex B (informative) Operational ontology of DP . 29
Annex C (informative) Dataspaces for data provenance . 32
Annex D (informative) Data provenance constraints derived from regulations . 34
Bibliography . 36

© ISO/IEC 2026 – All rights reserved
iii
ISO/IEC FDIS 5181:2026(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© ISO/IEC 2023 2026 – All rights reserved
iv
ISO/IEC DISFDIS 5181:2026(en)
Introduction
This document provides guidelines and methods on how to derive data provenance information from a system
of co-operating authenticated stakeholders. Data provenance is valid if, the data value stream represented by
sequences of < < data, metadata> > tuples, in any life cycle phase of compound industrial data and production
value streams, the data value stream is always comparable to the value stream of production involving
operational technology. Hence, the < < data, metadata> > tuples value stream is twinning the production value
stream such that both, data and production value streams are isomorphic to each other.
The use and processing of data performed by applications, systems, robots, individuals, agents or companies
[22]
usually is subject of permissions from data owners as applied in ISO/IEC 62890 [22].
“Data owner” is a term that is applied to the rights of a data holder. Data holders have the rights to access, use,
or manipulate their data. The data owner role is understood as an individual or a group of stakeholders who
can have control over certain data attributes like data creation, accuracy or the names or identifiers of sources,
etc.
Data provenance information is useful to all who want to use available data in other applications or want to
decide to make data voluntarily available as a common good in a dataspace that can be subscribed by various
application stakeholders. Identifying and deriving information from the history of metadata events provide
details on the narratives of data provenance and data manipulations. The concept of narration is used because
it visually describes sequences of activities or the state changes of a system. Graphically, a sequence of state
changes or events is a graph trajectory.
© ISO/IEC 2026 – All rights reserved
v
DRAFT International Standard ISO/IEC DIS 5181:2026(en)

Information security, cybersecurity and privacy protection — Data
provenance
1 Scope
This document provides guidelines, methodologies and techniques for securely deriving securely information
denoted to as provenance metadata about data assets from multiple sources, intermediaries or users. , which
is denoted as provenance metadata.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1 3.1
data
data asset
collectionscollection of data items that provide value to organizations playing roles like data provider, data
intermediary and data user
Note 1 to entry: Data isare a product, hence, data isare an asset that can be disseminated, shared, distributed, consumed,
or copied by processes or humans involved in the workflow of an enterprise, factory, information and data infrastructure
or human-machine cooperating communities like smart cities, smart factories etc.
[SOURCE: ISO/IEC 20547-3:2020 3.7 modified, Note 1,3 to entry removed]
3.2 3.2
data altruism
voluntary sharing of data without compensation
Note 1 to entry: Voluntary sharing of data is based on consent of certain data subjects to process their personal data and
to get permission from data holders to use non-personal data.
[11] [11]
Note 2 to entry: Data can be shared via a virtual data sharing platform, , such as a dataspace.
Note 3 to entry: A certification framework can provide organizations with voluntary authorization by governments
compared to a framework with compulsory authorization.
[25]
Note 4 to entry: In this context, data altruism is interpreted according to Article 2(16) of the EU DGA [25].
ISO/IEC FDIS 5181:2026(en)
3.3 3.3
artefact
constructive, descriptive or semantic element of views on a thing of interest (ToI) as represented by the
semiotic triangle with three views on the ToI
Note 1 to entry: The construction of things view obeys operational engineering constraints, the description view obeys
requirements represented by an ontological language, and the semantics view is given in a notation that supports
reasoning analysis of the past and predictive simulation-based analysis of future behaviour of a ToI.
Note 2 to entry: The ToI can be modelled by an urban digital twin (UDT) which feeds back information from the
performed analysis.
Note 3 to entry: The term artefact is preferred in formal systems because it means an intangible concept in contrast to a
physical object.
3.4 3.4
computation
graph computation
sequence of directed edges of a graph (trajectory) that is enabled by annotated rules conditioning the
execution of sequences of edges of the graph
Note 1 to entry: A data graph is an asset that is applied and manipulated along an executable life cycle value stream (LC
VS) trajectory.
Note 2 to entry: A process graph is defined by three things i.e. a set of vertices (i.e. process states), a vertice-disjunct set
of edges (i.e. transitions) and an incidence mapping that maps an edge either into an undirected pair of vertices (i.e.
action), or that maps an edge into a pair of directed vertices (i.e. event). For short, the latter is called directed edge and
the former undirected edge.
Note 3 to entry: Data or process assets both, are modelled by computable graphs, i.e. data graphs or process graphs.
3.5 3.5
dataspace
data governance framework and supporting services to build trustworthiness and enable data sharing
through an agreed set of policies, semantic models, protocols and processes
Note 1 to entry: More formally, a dataspace can be considered as a set of data assets annotated with metadata such as
data provenance information, which is organized as a publish-subscribe dataspace that manages many-sorted data type
[5] [5]
items as < < n-tuples>, > , whereby < < n-tuples> > are defined for n≥ ≥ 2 elements of respective sorts . .
Note 2 to entry: sort is a term from applied mathematics that represents a variable i.e. a set of terms of a considered data
type.
1 1)
[SOURCE: ISO/IEC 20151-1 ,:— , 3.1, modified — Note 1definition has been modified to align with the context
of this document; notes 1 and 2 to entry hashave been added.]
3.6 3.6
data graph
graphical representation of a data structure using graph artefacts such as vertices, edges and an incidence
mapping
Under development. Stage at the time of publication: ISO/IEC FDIS 20151-1:2026.
1)
Under development. Stage at the time of publication: ISO/IEC FDIS 20151-1:2026.

© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
Note 1 to entry: In the DPdata provenance methodology of subclause 5.2subclause 5.2components, components of a data
structure are graphically represented by tree-like graphs i.e. data graphs.
Note 2 to entry: The graph semantic artefacts allow to represent either data structures or knowledge but also behaviour
of processes or stakeholders that communicate via the dataspace.
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an incidence
mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of directed vertices.
3.7 3.7
process graph
graphical representation of a process using graph artefacts such as vertices, edges and an incidence mapping
Note 1 to entry: The elements of a process are graphically represented by a mesh-network-like graph.
Note 2 to entry: The graph semantic artefacts allow to represent behaviour of processes or stakeholders that
communicate via the dataspace, but also data structures or knowledge.
Note 3 to entry: A graph is defined by three elements i.e. a set of vertices, a vertices-disjunct set of edges and an incidence
mapping that maps an edge either into an undirected pair of vertices, or that maps an edge into a pair of directed vertices.
3.8 3.8
data governance
process focused on managing the quality, consistency, usability, security, and availability of data
Note 1 to entry: This process is closely linked to the notions of data ownership and stewardship.
[26] [26]
[SOURCE: ISO/TR 14872:2025 ,, 3.3, modified — “information” has been replaced by “data”]”.]
3.9 3.9
data leakage
drain of data that makes the operation phenomenon, including the phenomenon’s data, untrustworthy
Note 1 to entry: The longer the life cycle value stream (LC VS) of operation, the higher the complexity of production.
Higher complexity creates a higher risk of data leakage or other non-authorized manipulations.
3.10 3.10
metadata
data that defines and describes other data
Note 1 to entry: to entry In the ISO/IEC 11179 and ISO/IEC 19763 series of standards, the objects being described are
instances of the subclasses of item, e.g. concepts, data elements, services.
[19] [19],[20] 2 ],[[20]
[SOURCE: ISO/IEC 11179-3:2023/Amd 1:2026, Amd1 — , 3.2.30]
3.11 3.11
provenance metadata
metadata about the provenance of data
Note 1 to entry: Metadata comprises in practice various categories of information about the state of data that is
observable during the life cycle value stream (LC VS.).
Note 2 to entry: Metadata derived during the LC VSofVS of processing assets has the purpose to provide trust in the
incorporation of data subscribed from a dataspace.

Under development. Stage at the time of publication: ISO/IEC 11179-3:2023/Amd 1:2026.
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Note 3 to entry: Metadata annotated to data that are generated and derived during the operation of a physical machinery
(e.g. energy distribution, automated production, self-driving cars) is called the narrative of provenance (NoP) of the
associated data of interest.
Note 4 to entry: By inspecting the NoP, the data of interest can be applied by stakeholders, processes, or individuals in
contexts different from the source contexts. Based on the NoP, interested parties can decide which of their data
subscribed from the dataspace, they want to use as a common good and which not.
3.12 3.12
data provenance
ownership and usage history of data of a system
Note 1 to entry: Provenance, consisting of data is information that is given by sets of metadata describing
origins, sources of data, parties involved in generating, manipulating, and managing any data.
[10][10]
Note 2 1 to entry: A similar integratable DP definition of data provenance is given in VDE SPEC 90009 v1.0 that
defines data provenance (DP) as the origin of the metadata values comprising person, organization, software agent, file
[10][10] [13][13]
or unknown. VDE SPEC 90009 v1.0 is based on IEC 61360-1 that defines the attributes for the specification of
[10] [10]
meta-metadata. .
[10] [10]
Note 3 2 to entry: In this document and in contrast to the VDE SPEC 90009 v1.0 , , metadata (values) of data
provenance information are interpreted semantically which means metadata (values) are derived during the LClife cycle
value streams in the same activity or phase of production from the data and from the production.
[20] [20]
Note 4 3 to entry: A similar integratable DP definition of data provenance is given in ISO/IEC 11179-33 that defines
provenance as information on place and time of origin, derivation or generation of a data set, proof of authenticity of the
data set, or a data set of past and present ownership of that data set.
3.13 3.13
provability
verifiability
degree to which something can be reliably demonstrated or formally proven
Note 1 to entry: Defining the data provenance involves specifying provenance evaluation criteria and requirements that
can demonstrate the data provenance of data of a system in a provable way.
Note 2 to entry: Provability is an important element of the DPdata provenance methodology.
3.14 3.14
quality of data
degree to which the characteristics of data satisfy stated and implied needs when used under specified
conditions
Note 1 to entry: Quality of data (QoD), e.g. of a blueprint of car production, is coupled with the quality of the operation
phenomenon of a technical production of a car.
Note 2 to entry: Data isare an informational asset that digitally mirrors the behaviour of an operational asset. The
coupling is understood as the technical phenomena of a system’s machinery, e.g. car production, that is tightly coupled
with the mirroring asset of data capturing through sensors and data analysis provisioning to actuators on a high level of
quality of data.
[SOURCE: ISO/IEC 25012:2008, 4.3, modified — preferred term has been made “quality of data” (QoD) and);
Notes to entry have been added.]
3.15 3.15
security
resistance to intentional unauthorized acts designed to cause harm or damage to a digital data asset or to
personally identifiable information captured by a system
© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
Note 1 to entry: Security is the freedom from misuse of data.
Note 2 to entry: In the context of data provenance, “system” includes data and their associated metadata.
[SOURCE: ISO/IEC 23643:2020, 3.16, modified — in the definition, "“system"” has been replaced by "digital
data asset or to personally identifiable information captured by a system";”; Notes 1, 2 to entry have been
added.]
3.16 3.16
privacy
right of individuals to control or influence what information related to them canthat may be collected and
stored and by whom and to whom that information may be disclosed
Note 1 to entry: In the context of data provenance, privacy refers to control of the data and the associated metadata.
[SOURCE: ISO 7498--2:1989, 3.3.43, modified — Note to entry has been replaced.]
3.17 3.17
semantics
mapping between elements of a language and the real world
Note 1 to entry: The semantics of data manipulation can be described in computational terms such as processes,
variables, data sets (called sorts) and many-sorted data types comprising many sorts.
Note 2 to entry: The semantics of production process based on state changes during LClife cycle value streaming of
production processes can be represented by graphs comprising events and states.
[28] [28]
[SOURCE: ISO/IEC TR 24800-1:2012 ,, 2.5, modified — Notes to entry have been added.]
3.18 3.18
semiotic triangle
model that relates linguistic symbols to semantic concepts and to the objects they represent
Note 1 to entry: Linguistic symbols can be terms or signs, possibly from an ontology.
Note 2 to entry: Semantic concepts can be represented by graph vertices and edges.
3.19 3.19
sort
data type
variable
formal notion from algebraic data type theory. It, which describes sub-data types that can be extended to
many-sorted (i.e. complex) data types comprising multiple sets of data.
Note 1 to entry: Sorts are algebraic terms that represent sets of data in a dataspace.
3.20Note 2 to entry: The terms data type and variable are synonymous terms for a sort i.e. a set of data items.
Note 3 to entry:
3.20
trust
recognize an asset (something, someone) as being trustworthy in a defined context of use that is of value to
the user
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
3.21 3.21
trustworthiness
ability to meet stakeholders’ expectations in a verifiable way
Note 1 to entry: Depending on the context or sector, and on the specific product or service, data, technology and process
used, different characteristics apply and need verification to ensure stakeholders’ expectations are met.
[SOURCE: ISO/IEC TS 5723:2022, 3.1.1, modified — Notes to entry 2, 3 and 4 to entry have been deleted.]
3.22 3.22
validity
proof of a data provenance proposition in certain circumstances or system states that become valid or invalid
Note 1 to entry: Semiotic mappings is achieved by defining pairs of semiotic artefacts from the three semiotic domains.
By this view, validity is a kind of “weak correctness proof” based on propositions about relationships between semantic
artefacts (declarative), ontological artefacts (descriptive) and physical artefacts (constructive, phenomenological).
4 Abbreviated terms
AAS asset administration shell
CDDL concise data definition language
DP data provenance
DPIM data provenance information model
DS data secrecy
DTw digital twin
HMI man-machine interface
HMI
man-machine interfacegeneral data protection regulation
GDPR
IoT
internet of thingsmetadata
MD
MD metadata
MMI
machine-machine interfacemachine learning
ML
ML machine learning
NoP narrative of provenance
LC VS life cycle value stream
OT operational technology
PII personally identifiable information
QoD quality of data
PIR provenance, identities, rights
RAM reference architecture model
RM reference model
SF smart factory
© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
SM smart manufacturing
ToI thing(s) of interest
TW trustworthy, trustworthiness
UDT urban digital twin
VS value stream
5 Data provenance methodology
5.1 General assumptions
Figure 1Figure 1 illustrates a < < data, metadata> > VS, its production VS, and their dynamic
interrelationships. In the figure, the stakeholder types are represented by rectangles, the corresponding
activities manipulating variables are represented by circles, and the narratives of provenance (NoP) are
represented by arrows.
Key
1,2 ., 8 reference numbers of DP activities
A, B, C stakeholder DP categories of provider, intermediary, user
NOTE 1 The letters A, B, and C indicate three stakeholder types.
NOTE 2 Ontological artefacts identified in B of the intermediaries are described in an operational manner.
NOTE 3 The numbers 1 to 8 indicate activities on the upper and lower life cycle value stream (LC VS).
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Figure 1 — Life cycle value streams of parallel data and production asset processing

NOTE 1 the letters A, B, and C indicate three stakeholder types.
NOTE 2 ontological artefacts identified in B of the intermediaries are described in an operational manner.
NOTE 3 the numbers 1 to 8 indicate activities on the upper and lower life cycle value stream (LC VS).
The concept of data provenance relies on the following two principles: (a) semantics that is expressed in terms
[7][7, 32], [32]
of graph artefacts and (b) the physical phenomena that coincide with the derived narratives of
provenance (NoP).
The two principles (a) and (b) are operationalized into 8 activities:
a) Activity 1 and 2: Descriptionsdescriptions of the data (key reverencereference 1 of Figure 1)) and
metadata (key reverencereference 2 of Figure 1)) elements and rules to fit into < < data,
metadata> > pairs,;
b) Activity 3: Provisioningprovisioning of required resources (artefacts) for the anticipated asset production
processes,;
c) Activity 4: Cycliccyclic information provisioning from the space of production to the digital data space of
information modelling,;
d) Activity 5: Observationobservation of LC production VS events and patterns that are of interest to
questions of trust,;
e) Activity 6: Inheritanceinheritance of data models usually many-sorted data (i.e. multiple sets) and PIR
information from both < < data, metadata> > VS and production VS to improve quality of production,;
f) Activity 7: Basedbased on available data manipulation tools, to perform analysis and simulations and if
necessary, provide adjustments to the production processes to synchronize with the data VS models,;
g) Activity 8: Verificationverification or validation of the expectations of the data user involved intoin the
considered use case on the production asset (as applied in Annex B and Annex C. ).
The anticipated value streams (VS) of the production asset life cycle contain not only single data items (i.e.
constants) but also sorted variables that represent sets of data (i.e. data types).
The LC VS model of Figure 1Figure 1 is comprised of comprises three basic types of stakeholders.
h) theThe provider of many-sorted data, metadata and (production) resources is specified by the related
variables md of sort “metadata” and res of sort “resources” (labelkey reference A in Figure 1Figure 1))
i) theThe producer of a product asset is specified by variables comprising certificates cert and evidence ev
of sort “dataspace”, or product prod of sort “production space” (labelkey reference B in Figure 1Figure
1).).
j) The product/data user stakeholder is specified by the variables uc of sort “trusted UC” and pr of sort
“trusted product” (labelkey reference C in Figure 1Figure 1). ).
The < < data, metadata> > model changes in the path above (Figure 1(Figure 1)) correspond withto the
changes of the production process in the path below (Figure 1(Figure 1).). The < < data, metadata> > model
© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
trajectory at the end of a considered LC VS represents the user’s expectations on the trusted product that are
semantically comparable i.e. verifiable with the measured qualities on the trusted product and therefore the
corresponding data and production value streams can be trustworthy.
5.2 Verification and validation principles
Figure 1Figure 1 shows the basic validation and verification principles (as outlined in Annex B and Annex C)
of deriving trust when using data voluntarily made available that stem from different sources while respecting
their histories of changes and manipulations by inspecting metadata narratives of provenance (NoP) on the
data’s life cycle value stream (LC VS).
The two value streams of Figure 1Figure 1 (i.e. the upper < < data, metadata> > and the lower production VS)
are intended to be validated or verified against each other. Then both assets, the < < data, metadata> > model
and the related product can be trusted (activity 8 in Figure 1Figure 1).). To demonstrate this, the expectations
from the < < data, metadata> > VS areis shown to be fulfilled by the production processes that operate in
parallel.
In Figure 1Figure 1,, the < < data, metadata> > model changes in the path above correspond with the changes
of the production process in the path below. The < < data, metadata> > model trajectory at the end of a
considered LC VS represents the user’s expectations on the trusted product that are semantically comparable
i.e. verifiable with the measured qualities on the trusted product and therefore the corresponding data and
production value streams can be trustworthy.
In the DP methodology represented in Figure 1Figure 1,, authenticity in industrial systems mean that the
< < data, metadata> > VS is always in relation to the production VS of a thing of interest (ToI) based on
[21] [21] [33][33]
operational technology . Since, the < < data, metadata> > tuples VS is twinning the production VS,
the corresponding VSvalue streams are isomorphic to each other.
5.3 Value stream semantics
5.3.1 Correspondence between LC value streams
In industrial systems, basically, there are two corresponding value streams the < < data, metadata> > VS, and
the production VS.
In Figure 1Figure 1,, the < < data, metadata> > VS is the upper stream, starting from the initial < < data,
metadata> > sources in activities 1 and 2, working through the intermediaries of performing activities 6 and
7 based on acquired PIR < < data, metadata> > tuples of measured production qualities, and finally to the
expected use cases verified with the final product in activity 8.
The production VS is the lower stream, also starts from the initial < < data, metadata> > sources in activities
1 and 2, but is aligned with the production resources that are provided in activity 3. The production VS then
works through the intermediaries of performing activity 5 manufacturing qualities, properties and capabilities
of the resultant asset of a new product. The < < data, metadata> > tuples information is acquired by the
production VS in activities 4 and 5 and delivered to the upper VS to perform a production analysis or a
simulation for achieving an anticipated high quality of the product.
The production activities provide a proof that the stakeholders’ expectations documented by < < data,
metadata> > models are achieved on the resulting product asset. This capability is called provability of DP
assertions.
The cyclic process incorporating activities 1 to 7 is a semantic process of generating trust because it generates
various categories of tuple sets of the < < provenance, identities, rights> > (P, I, R) metadata that document
all activities necessary for the LC VS of production of a product (i.e. the physical asset).
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
Metadata capturing occurs in all physical processes during the entire LC VS. It is an ongoing task for the
purpose of creating trust for the use or application of data-of-interest that are subscribed from a dataspace.
For example, in production processes, an asset is basically a product together with its data that result from
stakeholders involved in the same LC VS that is generating, operating, manipulating, decommissioning or
refurbishing the compound LC VS of < < data, metadata> > tuples and production.
When collecting metadata from observations of the production VS (Figure 1(Figure 1,, activities 4, 5) and
integrating these derived metadata into NoPs (Figure 1(Figure 1,, activities 6, 7) then these NoPs can be used
to prove product authenticity because of the applied isomorphy property.
5.3.2 Value stream behaviour
The three basic interoperating stakeholders (A, B, C) of Figure 1Figure 1 reside in different infrastructures
that comprise human, digital and physical resources to set up activities of parallel data processing and
production processes. In the various LC VS stages, processes are required to interact in a trustworthy manner
by means of exchange and forwarding new or manipulated data models via specific dataspaces.
Data models can comprise various data types. A data type is many-sorted which means that there can be
[5] [5]
multiple sorts with variables in one many-sorted (i.e. compound) data type. In the application of the asset
[6] [6]
administration shell (AAS) ), a sort can be a sub-model or in formal terms, a sort can be represented by a
variable. This is also outlined for each stakeholder in Figure 1Figure 1.
With respect to data provenance inspections to obtain trustworthiness for some data-of-interest, it is
important to note that generally data is an asset that mirrors modelsmodel behaviour of production assets
during their production or operation as outlined in Figure 1Figure 1,, activities 1 to 7. The VS are described in
terms of sequences of compound < < data, metadata> > pairs that describe stories of trusted data
manipulations twinning semantically the sequences of production events.
However, when data are considered as assets, they can be made accessible by an own asset administration
[6] [6]
shell (AAS) ) sheltering the data like a physical product. A data-product has value to its provider, creator,
or user when data isare used in models such as a production process in all its phases of functional and quality
maturity. The value of a data product is related to its stakeholders’ credibility and market economics of data
users.
5.3.3 Representation of VS semantics
Figure 1Figure 1 represents the LC VS of the incorporated assets i.e. the generation of an initial data including
metadata specifications during operation and the operational (technical) production asset yielding a product
of a certain quality.
The two value streams of Figure 1Figure 1 operate in parallel and are referred to as a compound data-product
asset. The presentation of the whole LC in Figure 1Figure 1 is, represented by the three
stakeholdersstakeholder categories (key references A, B, C.). In the lower stream (production LC VS), the
stakeholders manage and manipulate the production infrastructure and the resources required for the
production, and, in the upper stream ( > VS), the verification of the data model, the
management of the dataspace and the data prepared for use by authenticated third parties and the product
user.
The provisioning of resources to a production LC VS, comprising data and metadata areis required for
[8] [8]
authentication . The producer can involve data and resources from multiple sources for the VS processes
of production.
The quality of the product to be produced is documented by generating metadata that can comprise trust
certificates, collections of evidence about the integrity, authenticity and confidentiality of the assets (i.e. data,
product or production), and stakeholder identities. This documentation can be used by the customer or user
© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
as the metadata evidence required for proving trust and product authenticity. Based on the metadata evidence,
the customer can prove that the documented metadata NoP of any product apply the isomorphy property,
such that both value streams obey the rules of provability.
Figure 1Figure 1 shows the isomorphic principle, which means that the collected < < data,
metadata> > tuples are in all LC VS stages in synchrony with the LC VS stages of the production. This is a
formal way of applying provability to LC VS processes.
NOTE 1 Tuples denominate a collection of heterogeneous items that are packaged due to certain constraints.
Stakeholder A (activities 1 to 3) starts the production with a trusted collection of initial data and resources
that semantically initialize the quality of production to be maintained during all activities of the LC VS.
Stakeholder B (activities 4 to 7) continue the production process showing that LC VS stages, data, and
metadata tuples can be updated and evaluated with respect to the operational production stages of a product.
Vice versa, the production activities can be validated against the data model based on LC VS < < data,
metadata> > tuples. Formally, data and metadata structures can be instantiated with type graphs that can be
manipulated based on a formal grammar.
Stakeholder C (activity 8) finishes the production by comparing the expectations modelled as use cases or
NoPs with the result of production. In case of isomorphy, the model and product comply.
NOTE 1 2 The capabilities of data and metadata handling are captured by the concept of a dataspace. Data and metadata
can be combined into tuples which are identifiable by valid proposition and maycan allow stakeholders to publish and
subscribe specified data and metadata tuples to and from the dataspace.
[8][8]
NOTE 2 3 A comparable metadata-based content provenance authentication methodology is e.g. specified in C2PA
[14][14] [24] [24]
technical specifications which comprise a” Concise Data Definition Language (CDDL)” )” to express binary
object data structures and provide tools to human users, for automated compliance checking, data analysis and security.
NOTE 3 4 The C2PA manifest is a data structure comprising a so-called claim of a collection of assertions. The claim is
hashed by signature. The assertions contain certain information about data with some hashes to bind them to the
manifest.
5.3.4 Continuity aspect of operating products and data
Semantics with respect to data provenance includes LC VS behaviour of a process or system that is represented
by variables that change continuously or discretely over time. In other words, the process variables range over
sets of typed values, formally referred to as “sorts”.
NOTE 1 A process represented by a continuous variable is modelled in terms of graph-theoretical approach
comprising vertices, edges and mappings among vertices. The mapping defines the creation of graph edges in terms of
ordered or unordered pairs of vertices. An ordered pair of vertices is semantically equivalent to an observed event. An
unordered pair is equivalent to a potential event not yet observed i.e. the declaration of an action. The metadata
annotated to the action describes that action by means of ontological artefacts.
The application of production resources require trust in data and resources to be applied or consumed. Thus,
trustworthiness influences the quality of data and production. In a dataspace, trustworthiness can be derived
from metadata annotated to data. Figure 2Figure 2 (6.3) illustrates the complexity dependency of quality of
data from the LC VS. The more a data tuple experiences manipulation during the LC VS, the less the trust is
placed on the data tuple of interest.

Tuples denominate a collection of heterogeneous items that are packaged due to certain constraints.
© ISO/IEC 2026 – All rights reserved
ISO/IEC FDIS 5181:2026(en)
5.3.5 Formal language terms
For the creation of PD metadata, a formal language approach is applied to determine and to analyse the
information on data provenance derived from observed data manipulations in a certain LC value stream. The
information contained by the metadata of a thing of interest (ToI) is used by the LC VS stakeholders, to make
decisions on data or product usage.
The approach of data provenance distinguishes between the concepts of metadata comprising information on
data provenance, security, privacy, and trust, and formal language terms used for making assertions about
data provenance propositions.
[8][8]
NOTE 1 Propositions The application of propositions in logic depend depends upon the context when
applying.of use. For example, in case of capturing data provenance metadata, a proposition describescan describe the
observation of an event. The event happens because that depends from the binding of all free variables of the proposition
are bound by thein a certain context.
5.3.6 Processing of trust
Descriptive artefacts of a domain ontology comprise the range of representations from single data
representations to complex knowledge representations, including learned or derived < < data,
metadata> > tuples based on trusted methods and tools of data provenance information handling and
manipulations.
An example of data provenance value adding based on metadata is shown in Figure 1Figure 1 by the activities
4 to 7. This cyclic process is called a process of generating trust because it maintains sets of PIR metadata that
document all activities on data and on production of the involved trusted stakeholders, necessary to produce
a physical product asset.
The production documentation by means of NoPs but also the identification of modelling artefacts can be of
value for similar production processes e.g. for use as a blueprint adopting the variables from an existing
environment to a new machinery and production environment. The modification of graph artefact is achieved
by applying a formal graph grammar. Hence, a trusted artefact can be used in different contexts and is thus of
value to stakeholders connected to a trustworthy dataspace.
Provenance metadata comprises of various categories of information about the state of data that is observable
during the life cycle value stream (LC VS).
The PIR metadata categories comprise:
— — data provenance (P) that is derived from the phenomena of physical operation incorporating data
along trajectories of usage;
— — digital identities (I) that control the stakeholders requesting access to the data or thing of interest;
— — digital rights (R) that control the access to the data or thing of interest (ToI).
The PIR metadata categories can be subdivided into macro- and microdata. Macrodata are the identifiers,
similar to IP address, that are external but directly indicate PII that is associated with a device or location.
Microdata are attributes and identifiers driven by the PII. Principal engagement with technology or its
function, this is by nature pseudonymous, or non-PII.
[4][4]
The metadata derived during the LC VS describing processing of assets can provide trust in the use of data
that is subscribed from a related dataspace.
© ISO/IEC 2023 2026 – All rights reserved
ISO/IEC DISFDIS 5181:2026(en)
By inspecting a NoP, the data of interest can be applied by stakeholders, processes, or individuals in contexts
different from the source contexts of data. Based on the NoP information, interested parties can decide which
of their data they want to be used as a common good and which they do not want to
...