ISO/IEC 5259 Series: ISO/IEC 5259 Series – Tutorial (about 60 minutes)

The ISO/IEC 5259 series is the international family of standards on data quality for analytics and machine learning (ML). Its five parts give a shared vocabulary, a model for measuring data quality, requirements for managing it, a process framework for day-to-day work such as labelling, and a governance framework for boards and senior managers. It is used by data scientists, data engineers, ML engineers, quality and compliance teams, and the managers who are accountable for AI outcomes. After this tutorial you will be able to explain what each part covers, define and measure data quality for a real ML use case, organise the work across the data life cycle, and position the series next to ISO/IEC 25012, ISO/IEC 42001 and the EU AI Act.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the series has five published parts, all first editions developed by ISO and the International Electrotechnical Commission (IEC) through joint technical committee ISO/IEC JTC 1, subcommittee SC 42 (Artificial intelligence). Part 1 (Overview, terminology, and examples) and Part 3 (Data quality management requirements and guidelines) were published in July 2024, Part 4 (Data quality process framework) also in July 2024, Part 2 (Data quality measures) in November 2024, and Part 5 (Data quality governance framework) in February 2025, so its reference is ISO/IEC 5259-5:2025. All five are at stage 60.60 (International Standard published); no amendment or second edition is listed, and ISO also sells them as a five-part package. The common title of every part is Artificial intelligence — Data quality for analytics and machine learning (ML). Parts 1 and 3 also mention a planned sixth document, the technical report ISO/IEC TR 5259-6 on visualising data quality; check the ISO catalogue for its current status before relying on it. Verified 2026-10-29 against the ISO committee catalogue entries for each part (including ISO/IEC 5259-5:2025, published 2025-02-12) and the ISO package listing. There is no formal certification scheme dedicated to the series (see Lesson 5).

Who it is for: data scientists and ML engineers who want a disciplined way to say whether their data is good enough; data engineers who build pipelines feeding models and dashboards; data stewards, data owners and data governance leads; quality, risk and compliance professionals who now have AI in scope; and managers who must sign off an AI system. No previous knowledge of ISO standards is required.

Prerequisites: none. A rough idea of what a dataset is (rows and columns, or a folder of images or documents) and what it means to train a model on examples is helpful. Both are explained where they are needed.

Learning objectives. After this tutorial:

You will be able to explain why analytics and ML need their own approach to data quality and what problem the ISO/IEC 5259 series solves.
You will be able to use the core vocabulary: data quality, characteristic, measure, requirement, data life cycle, provenance, labelling, data quality plan and data quality claim.
You will be able to describe the role of each of the five parts and how they fit together.
You will be able to turn a business need into data quality requirements, choose characteristics and measures, set thresholds and report the results.
You will be able to organise data quality work across the data life cycle, including labelling by internal teams or suppliers.
You will be able to explain what conformity, assessment and assurance can and cannot mean for this series.
You will be able to relate the series to ISO/IEC 25012, ISO 8000, ISO/IEC 8183, ISO/IEC 42001 and the data rules of the EU AI Act.

Lesson 1 – Origins, purpose and scope

Why data quality decides what a model can do

A traditional program behaves according to rules a developer wrote. A machine learning model behaves according to patterns it found in example data. That single difference moves data from a supporting role to the centre of the stage. If the examples are wrong, out of date, unevenly spread across the cases the model will meet, or labelled inconsistently, the model learns those flaws faithfully. No amount of clever tuning repairs a training set that never contained the situations the model must handle.

Analytics has the same dependency in a gentler form. A dashboard that counts customers twice, or a forecast built on a month of missing sales, produces confident numbers that lead to poor decisions. In both cases the cost of bad data usually appears late: after a model goes live, after a regulator asks for evidence, or after customers are treated unfairly.

Why the older data quality standards were not enough

Data quality was not a new topic for standards bodies. ISO/IEC 25012, published in 2008 as part of the SQuaRE family (Systems and software Quality Requirements and Evaluation), defines a general model of fifteen data quality characteristics for structured data held in computer systems. ISO/IEC 25024 describes how to measure them. The ISO 8000 series covers data quality in areas such as master data and data exchange. These documents remain useful, and the 5259 series builds on them.

They were written, however, with business records and databases in mind. ML raises questions they did not address directly. Does the training set represent the people, places and conditions where the model will be used? Are the classes balanced, or does one outcome dominate? Are the labels attached to images or text consistent between annotators? Is the data used for testing genuinely separate from the data used for training? Does the data still look like the world it describes six months after launch? Data also arrives in more forms: images, audio, free text, sensor streams and synthetic data, not only tidy tables.

Who wrote it and what it covers

The series was developed by ISO/IEC JTC 1/SC 42, the committee responsible for AI standards, which also produced ISO/IEC 22989 (AI concepts and terminology), ISO/IEC 23894 (AI risk management guidance) and ISO/IEC 42001 (AI management systems). Its purpose is to give organisations of any size, type or sector a common way to define, measure, manage and govern the quality of data used for analytics and ML, across the whole data life cycle. It applies to structured data such as tables and to unstructured data such as text, images and audio, and to data that an organisation collects itself, buys, receives from partners or generates.

It is useful to be clear about what the series does not do. It does not prescribe algorithms, model architectures or tools. It does not tell you what accuracy a model must reach, because model performance is a separate question from data quality, although the two are linked. It does not replace privacy or security standards; it touches topics such as compliance and identifiability only as qualities of the data. And it does not hand you a fixed set of thresholds: what counts as good enough depends on the purpose the data serves, which is why requirements always come first.

The central idea: fitness for a specified purpose

The single most important idea in the series is that data quality is not an absolute property. The same dataset can be excellent for one use and unacceptable for another. A table of customer addresses that is 95 percent complete may be fine for a regional sales chart and quite unfit for training a delivery-time model that must work in every postcode. The series therefore treats data quality as the degree to which data meets the requirements of an organisation in a defined context. Every part follows from that idea: you state requirements for a context, you measure against them, you manage the gap, and leadership makes sure the whole arrangement keeps working.

Lesson 2 – Key concepts and vocabulary

The series uses many terms from ISO/IEC 22989, ISO/IEC 25012 and data governance practice. The definitions below are explained in plain words; they are not the official text.

Data quality – how far data meets the stated requirements for a specific context of use. It is always relative to a purpose.
Data quality characteristic – one category of quality, such as accuracy, completeness or representativeness, that groups related attributes of data.
Data quality measure – a defined way to put a value on a characteristic, usually through a measurement function such as a ratio of records that pass a check to records checked.
Data quality requirement – a statement of what a dataset must achieve for its intended use, often written as a measure plus a target or threshold.
Data quality model – the structured set of characteristics, and the measures attached to them, that an organisation uses to specify and evaluate data quality. Part 2 provides one.
Data life cycle – the stages data passes through from the first idea of using it, through planning, acquisition, preparation, use in models or analysis and maintenance, to its retirement or deletion.
Data provenance – a record of where and when data originated, how it was derived or transformed, and who has owned or controlled it. Provenance supports traceability and trust.
Metadata – data that describes other data, for example field definitions, units, collection dates, licences and labelling instructions.
Data originator – the person or organisation that first produced the data, which may hold rights over it. It is often a different organisation from the one that holds or uses the data, and the people described by the data can have rights of their own.
Data creator – a role inside an organisation that generates, collects and curates data from its sources; Part 5 uses it when assigning accountabilities.
Labelling (annotation) – adding the target information a supervised model learns from, such as a class name, a bounding box drawn around an object, a segmentation outline or key points on an object.
Training, validation and test data – the data a model learns from, the data used to tune it during development, and held-back data used to estimate how it will perform on cases it has not seen.
Representativeness – how well a dataset reflects the population and conditions where the model or analysis will be applied.
Balance – how evenly the dataset is spread across classes or groups that matter, for example the share of fraudulent versus legitimate transactions.
Data quality management – the coordinated activities by which an organisation directs and controls data quality, from culture, competence and resources down to the checks made at each stage of the data life cycle.
Data quality plan – a document that sets out the practices, processes, responsibilities and resources needed to reach the data quality objectives for a dataset or project.
Data quality claim – a declaration of how far a dataset meets a given data quality requirement; to be credible it needs measurement evidence behind it.
Supplier agreement – a written agreement between a customer and a data or labelling supplier that states who performs which data activities, which evidence will be reviewed and which work products are exchanged.
Data governance – the system by which the current and future use of data is directed and overseen, so that it supports the organisation's purpose and obligations.
Data owner and data steward – the party accountable for a dataset and its use, and the role that makes sure everyday data work follows agreed policies and practices.
Drift – a change over time in incoming data, or in the relationship between inputs and outcomes, that makes data collected earlier less representative of today.

Two distinctions help when reading the parts. First, a characteristic is what you care about, while a measure is how you put a number on it; one characteristic can have several measures. Second, management is about planning and running data quality work, while governance is about setting direction, assigning accountability and overseeing that management is effective. The series keeps these levels in separate parts.

Lesson 3 – Structure of the series

The five parts are designed to be read together. Part 1 is the entry point. Part 2 gives you the yardstick. Parts 3, 4 and 5 address management, processes and governance, which can be remembered as what must be in place, how the work is done day to day, and why and by whom it is directed.

Figure 1 – Part 1 lays the foundation, Part 2 supplies the measures, and governance (Part 5) directs management (Part 3), which is carried out through processes (Part 4).

Part	Title (short)	Main content	Main readers
5259-1:2024	Overview, terminology, and examples	Concepts, terms, a concept framework (management, governance, provenance), a data life cycle model and illustrative examples	Everyone starting with the series
5259-2:2024	Data quality measures	A data quality model, measures for each characteristic and guidance on reporting results	Data scientists, data engineers, testers, auditors
5259-3:2024	Data quality management requirements and guidelines	Organisation-wide and life-cycle-stage requirements, supporting processes, supply chains, tools and project-level data quality planning	Data quality and AI programme managers, quality and compliance teams
5259-4:2024	Data quality process framework	Processes for different kinds of ML and for analytics, with particular attention to labelling and evaluation	ML teams, labelling teams and labelling service providers
5259-5:2025	Data quality governance framework	Principles, strategy, policy, accountabilities and risk for data quality, and the separate responsibilities of the governing body and management	Boards, executives, data governance leads

Part 1 – the foundation

Part 1 explains why data quality matters for analytics and ML, including the data characteristics that make quality hard (such as data shared or re-used from elsewhere), and introduces the vocabulary used in the rest of the series. Its concept framework ties together data quality management, data quality governance and data provenance, and it sets out a data life cycle model with processes that run across several stages. An informative annex gives examples and scenarios so readers can recognise quality issues in their own work. It builds on the AI vocabulary of ISO/IEC 22989 and ISO/IEC 23053 and is the right place to start.

Part 2 – the data quality model and measures

Part 2 is the most technical part. It provides three things: a data quality model, a set of measures, and guidance on reporting.

The model starts from ISO/IEC 25012. That standard groups its fifteen characteristics by viewpoint. Some are inherent, meaning they belong to the data values themselves: accuracy, completeness, consistency, credibility and currentness. Some are system-dependent, meaning they depend on the technology that stores and serves the data: availability, portability and recoverability. The rest have both aspects: accessibility, compliance, confidentiality, efficiency, precision, traceability and understandability. Part 2 keeps this foundation: fourteen of the fifteen ISO/IEC 25012 characteristics reappear in the same three groups (confidentiality is not among them, and an annex compares the two models). It then adds a fourth group of nine additional characteristics that matter particularly when data is used to train, test or feed ML models and analytics: auditability, balance, diversity, effectiveness, identifiability, relevance, representativeness, similarity and timeliness. In plain terms, representativeness asks whether the data reflects the target population and conditions, balance whether relevant classes or groups are proportionately present, diversity whether the data covers the variety of cases that occur, relevance whether the data is appropriate for the task, and similarity how alike records or datasets are, which matters, for example, when checking that test data is not a near copy of training data. Organisations can extend or adapt the model for their own needs.

For each characteristic, Part 2 defines one or more measures. A measure has a name, a description and a measurement function, often a ratio such as the number of records meeting a condition divided by the number of records examined, which yields a value between 0 and 1. The measures are building blocks: an organisation chooses those that fit its requirements, sets targets, and applies them consistently so results can be compared over time and between datasets. Part 2 also explains how to implement the model and measures for a specific analytics or ML task, and finally gives a reporting framework so that the people relying on results know what was measured, how, on which data, and with what outcome.

Figure 2 – The Part 2 model groups characteristics four ways and links them to measures, measures to results, and results to a report that is judged against requirements.

Part 3 – managing data quality

Part 3 contains requirements, written as "shall" statements, and guidelines, written as "should" statements, for establishing, implementing, maintaining and continually improving data quality management for analytics and ML. It is deliberately flexible so it can fit different AI development life cycles: what matters is that an organisation's own activities can be mapped to the stages of the data life cycle.

Its requirements are organised in layers. Overall data quality management covers what the organisation needs everywhere: a data quality culture, a way to handle data quality issues, competence, resources, integration with other management systems, documentation, data quality audit and assessment, and confirmation reviews. Life cycle-specific management sets requirements and expected work products for each stage, from motivation and conceptualisation, specification and planning through acquisition, pre-processing and augmentation to provisioning and decommissioning. Horizontal processes run across all stages: verification and validation, configuration management, change management and risk management. Further clauses deal with data quality in supply chains (data obtained from or prepared by others), the tools used to process data, and dependencies between data quality activities. Finally, project-specific management covers the context and intended use, data quality requirements, roles and responsibilities, tailoring, the data quality plan and the justification that the data is good enough. Part 3 itself does not prescribe detailed methods or metrics; those come from Parts 2 and 4. Because it is built around the life cycle and expects integration, Part 3 can sit alongside other management system standards an organisation already runs, such as ISO 9001, ISO/IEC 27001 or ISO/IEC 42001.

Part 4 – the process framework

Part 4 is the operational companion to Part 3. It sets out common organisational approaches for ensuring data quality for training and evaluation, regardless of the size or type of organisation. It describes how the data quality process applies to supervised ML, unsupervised ML, semi-supervised ML and reinforcement learning, and to analytics. The differences are real. In supervised learning the labels are part of the data, so labelling quality becomes a central concern. In unsupervised learning there are no labels, so attention shifts to coverage, consistency and how well the data supports meaningful groupings. Semi-supervised learning mixes a small labelled set with a large unlabelled one, so the quality of each and the way labels are propagated both matter. Reinforcement learning learns from interaction with an environment, so the quality of the environment data, rewards and recorded experience is what counts.

Part 4 pays particular attention to labelling for supervised learning, where its guidance is most detailed, including common ways of organising labelling work. It applies to training and evaluation data from different sources and follows that data through acquisition and composition, pre-processing, labelling, evaluation and use. It does not define specific services, platforms or tools. In practice, controlling labelling means clear labelling guidelines, trained annotators, checks of label accuracy and consistency, and annotations that stay traceable to the data they describe, whether the work is done in-house or by an external service.

Part 5 – governing data quality

Part 5 is written for governing bodies, such as a board of directors, and for the management to whom they delegate authority. It treats data quality as a leadership responsibility, not only a technical task, and starts from a common problem: unclear responsibilities for data. Its framework covers guiding principles, strategies and policies, business planning, accountabilities, risk management and the management processes for data quality. It then separates the governing body's responsibilities (understanding why data quality matters, creating an enabling environment, setting strategy and policy, and establishing oversight) from management's (implementing the strategy, enforcing policies, running data quality management processes and internal risk control). It builds on the data governance standard ISO/IEC 38505-1 and on ISO/IEC 38507, which covers the governance implications of AI. It deliberately does not repeat the management requirements of Part 3 or the process requirements of Part 4: where they answer how, Part 5 answers why and who.

Lesson 4 – How it works in practice

Following the data life cycle

The series ties data quality work to the data life cycle rather than to a single check before training. Part 1 sets out a data life cycle model, and Part 3 attaches its requirements to life cycle stages; SC 42 also publishes a general AI data life cycle framework, ISO/IEC 8183. Figure 3 follows the stage names used in Part 3.

Figure 3 – The data life cycle stages used in Part 3: requirements are set early, checked at every stage, and findings during use send data back for new acquisition.

Each stage raises different questions. At motivation and specification the question is why the data is needed and what it must be like for the intended use. During planning it is where the data will come from, under which rights, and how it will be checked. During acquisition it is whether the data arriving matches what was planned. During pre-processing, which in supervised learning includes labelling, it is whether cleaning, transformation and annotation preserve or improve quality, and whether every change is recorded. Augmentation, such as adding synthetic or transformed examples, raises the question of whether new data stays realistic and does not distort balance. At provisioning it is whether training, validation and test data are delivered and separated properly and represent the target conditions. During use and operation it is whether live data still resembles the data the model learned from. At decommissioning it is whether data is retired or deleted in line with obligations, and whether records needed for later evidence are kept.

How the layers fit together

Across these stages, Part 3's layers work together, directed by governance under Part 5. Organisation-wide management provides the culture, competence and resources; each project tailors the life cycle and writes a data quality plan; stage-specific checks and the horizontal processes produce evidence; and audit, assessment and reporting feed back to leadership. In spirit this is the familiar Plan-Do-Check-Act loop of quality management.

Figure 4 – Governance directs organisation-wide management; projects plan and run stage checks supported by horizontal processes; audit and reporting feed back to the project and to leadership.

Implementation step by step

Set direction. Leadership agrees why data quality matters for the organisation's analytics and AI, approves a policy, and names who is accountable for each important dataset. Without this, quality work tends to stop at the first deadline.
Inventory data and uses. List the datasets that feed models and key analytics, with their sources, owners, licences and the decisions they support. Record provenance from the start; reconstructing it later is expensive.
Write data quality requirements. For each use, translate the business need into requirements. Ask what could go wrong if the data were incomplete, stale, unbalanced or mislabelled, and who would be affected. Requirements should name the characteristic, the measure and the target.
Select measures and thresholds. Use the Part 2 model as a menu. Pick a small number of measures that really matter for this use rather than measuring everything, and agree thresholds with the people who will rely on the results.
Write the data quality plan. Record objectives, measures, thresholds, checkpoints in the pipeline, responsibilities, tools, and what happens when data fails a check.
Build controls into the pipeline. Automate checks where data enters, after transformations and before training. Quarantine failing data rather than silently dropping it, so problems are visible.
Run labelling as a controlled process. Write labelling guidelines with examples of hard cases, train annotators, measure agreement, review samples and record who labelled what. Where a supplier labels the data, agree responsibilities and evidence in a written supplier agreement.
Evaluate and report. Measure the datasets, compare results with requirements and publish a short data quality report alongside the dataset, so model developers and reviewers know its strengths and limits.
Monitor in operation. Track the same characteristics on live data, watch for drift and set triggers for investigation or retraining.
Improve. Analyse recurring failures, fix causes at the source, and feed lessons back into requirements and plans. Report the state of data quality to leadership regularly.

Roles and artefacts

Typical roles are a data owner, accountable for a dataset and its permitted use; one or more data stewards, who make sure daily work follows policy; data engineers, who build pipelines and controls; data scientists and ML engineers, who define requirements for training and evaluation data; annotators and labelling leads; and a quality or assurance function that reviews evidence independently. In small organisations one person may hold several roles; what matters is that responsibilities are clear.

Part 3 lists expected work products for each life cycle stage and process. The artefacts that make the work visible include a data inventory, data quality requirements, the data quality plan, labelling guidelines, provenance and lineage records, measurement results and data quality reports, records of failed checks and corrective actions, supplier agreements and management review minutes. Many teams also publish dataset documentation, sometimes called datasheets or data cards, which is a convenient place to summarise quality results for users of the data.

Lesson 5 – Assessment, certification and compliance

Is there a certificate?

As of the verification date there is no dedicated, widely established accredited certification scheme for the ISO/IEC 5259 series comparable to ISO/IEC 27001 or ISO 9001 certification. Parts 1, 2, 4 and 5 are mainly descriptive and guidance-oriented. Part 3 does contain requirements, so an organisation can state that its data quality management conforms to Part 3 and support that statement with evidence. Part 3 includes requirements on data quality audit and assessment, and ISO describes it as a basis for either self-assessed or third-party data quality assurance. If a certification body offers an assessment against the series, check carefully what is being assessed, against which part, and whether the body is accredited for that activity.

Ways to assess

Three kinds of assessment are common, and they mirror the general conformity assessment vocabulary:

First-party assessment: the organisation checks itself, for example through a gap analysis against Part 3 and an internal audit of how plans, controls and reports are actually used.
Second-party assessment: a customer checks a supplier, for example a company auditing its labelling vendor against the agreed supplier agreement and the labelling expectations of Part 4.
Third-party assessment: an independent body reviews the evidence and gives an opinion. For this series it most often happens inside a wider audit, such as an ISO/IEC 42001 certification audit.

Assessing the data itself

Separate from assessing the organisation is assessing a dataset. Here the Part 2 measures do the work. An assessor checks that requirements exist and are appropriate for the intended use, that the measures chosen fit those requirements, that measurement was done on the right version of the data, that results meet the thresholds or that deviations were approved, and that the report is honest about limitations. A dataset that meets every requirement can still be unfit if the requirements were poorly chosen, so assessors look at the reasoning behind requirements as well as the numbers.

Regulation and other frameworks

The series is voluntary. It becomes important in compliance work because laws and other standards ask for data quality without saying exactly how to achieve it. The EU AI Act (Regulation (EU) 2024/1689), in its article on data and data governance, requires training, validation and testing data for high-risk AI systems to be subject to appropriate data governance and management practices, and to be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. The 5259 series gives practical structure for showing how those expectations are met. Note that even adoption of a standard as a European (EN) standard does not by itself make it a harmonised standard that gives a legal presumption of conformity; that depends on a separate decision published by the European Commission. ISO/IEC 42001 includes controls on data for AI systems, including the quality of that data, and the 5259 series is a natural way to implement and evidence them.

When you describe your status, be precise. "We have implemented data quality management that conforms to ISO/IEC 5259-3, confirmed by internal audit" is a supportable claim. "We are ISO 5259 certified" is usually not, unless an accredited scheme is named and the certificate can be checked.

Lesson 6 – Worked example

The organisation and the use case

Harbourline Insurance, a mid-sized home insurer, wants to speed up storm claims. After a storm, adjusters fly drones over damaged roofs and photograph them. The insurer plans an ML model that looks at the photos, classifies roof damage into four levels (none, minor, major, destroyed) and suggests a repair estimate band. An adjuster will confirm every result before payment. The insurer has 120,000 historical drone images from three coastal regions. It plans to use an external labelling company to annotate them.

Step 1 – Governance and accountability

The executive committee, acting under authority from the board, approves a short data quality policy for AI. It names the head of claims as data owner for claims imagery and appoints a data steward in the analytics team. It asks for a quarterly data quality report on all models that affect customer payments. This applies the governance thinking of Part 5: leadership sets direction, assigns accountability and decides what it wants to monitor.

Step 2 – Requirements

The team asks what would go wrong with poor data. If the images over-represent one region, roofs common in other regions might be misjudged. If "destroyed" roofs are rare in the data, the model may under-recognise them, which is the most harmful error. If labels disagree, the model learns confusion. They write requirements, for example:

Representativeness: images cover every region and the five most common roof materials, with each material at least 5 percent of the training set.
Balance: every damage level has at least 3,000 labelled images; if not, more data is collected before training.
Accuracy of labels: on a double-labelled audit sample, agreement between annotators is at least 90 percent, and expert review confirms at least 95 percent of audited labels.
Completeness: at least 99 percent of images carry capture date, location and drone model in their metadata.
Currentness: images used for training are no older than five years, because roofing materials and building codes change.
Similarity: no test image is a near duplicate of a training image, checked automatically with an image similarity measure.

Step 3 – Measures and plan

The data steward maps each requirement to a characteristic and a measure from the Part 2 model, writes down the measurement function and agrees thresholds with the claims team. The data quality plan records where each check runs in the pipeline, who acts on a failure, and how results are reported. It also records provenance: which drone, which flight, which storm and which region each image came from.

Step 4 – Labelling with a supplier

Following Part 4, the team writes labelling guidelines with photo examples of borderline cases, such as wet roofs that look damaged and debris that hides tiles. They sign a supplier agreement with the labelling company that sets out who labels, who reviews, which sample the insurer audits, which agreement statistics are delivered with each batch, and what happens when a batch fails. Annotators draw segmentation outlines around damaged areas as well as assigning the damage level, so later reviewers can see what the label was based on.

Step 5 – Measuring and the first findings

The first full measurement shows three problems. One region supplies 70 percent of images, so representativeness fails for the other two. Only 1,900 images are labelled "destroyed", so the balance requirement fails. Annotator agreement is 84 percent overall, with most disagreements between "minor" and "major". The team does not lower the thresholds to make the numbers pass. Instead it collects more images from the under-represented regions, asks adjusters for additional confirmed "destroyed" cases from past claims, and rewrites the guideline for the minor-major boundary with clearer visual examples. A second labelling round reaches 92 percent agreement.

Step 6 – Reporting and approval

The data steward publishes a data quality report with the training dataset: what was measured, the methods, the results, the remaining limitations (for example, few images of slate roofs) and the decisions taken. The model team uses the report to choose evaluation slices, such as testing separately for each region and roof material. The claims director approves use of the model, with adjusters confirming every result, on the basis of both the model evaluation and the data quality report.

Step 7 – Operation and improvement

After launch, the pipeline measures the same characteristics on incoming storm images every week. Eight months later a new drone camera produces sharper, differently coloured images, and a similarity check against the training data flags a shift. The team investigates, finds that the model's confidence has dropped on the new images, and plans a retraining round with labelled images from the new camera. The quarterly report to leadership records the event, the response and the improvement: camera model is now a mandatory metadata field checked at acquisition. An internal audit later samples three datasets against the Part 3 requirements and finds one plan without a named owner, which is corrected.

Figure 5 – The insurer's path from governance to monitoring: gaps are fixed in the data, and monitoring feeds back into requirements.

Lesson 7 – Relationship to other standards and frameworks

The 5259 series sits in a crowded space. Knowing its neighbours helps you avoid duplicated effort and use each document for what it does best.

Standard or framework	Focus	Relationship to ISO/IEC 5259
ISO/IEC 25012 and ISO/IEC 25024	General data quality model of fifteen characteristics and its measurement, for structured data in computer systems	The foundation that Part 2 extends with characteristics needed for analytics and ML
ISO 8000 series	Data quality for master data, data exchange and data quality management in general	Part 2 also builds on it; 5259 adds the ML and analytics viewpoint and life cycle
ISO/IEC 8183	AI data life cycle framework	Describes the life cycle stages that 5259 management and processes attach to
ISO/IEC 22989 and ISO/IEC 23053	AI concepts and terminology; framework for AI systems using ML	Supply the AI vocabulary and system view the series builds on
ISO/IEC 42001	Certifiable AI management system, with controls that include data for AI systems	5259 gives detailed practice to implement and evidence the data quality aspects
ISO/IEC 23894	Guidance on managing AI risk	Poor data is a major AI risk source; 5259 provides treatments and measures for it
ISO/IEC 38505-1 and ISO/IEC 38507	Governance of data, applying ISO/IEC 38500; governance implications of AI use	Part 5 builds on both and applies them specifically to data quality for analytics and ML
EU AI Act, article on data and data governance	Legal requirements on training, validation and testing data for high-risk AI	The series offers a structured way to meet and demonstrate those expectations
NIST AI Risk Management Framework	Voluntary US framework for managing AI risk	Data quality and representativeness are among the issues it raises; 5259 measures can support it

A practical way to combine them: use ISO/IEC 42001 as the management system that holds AI governance together; use ISO/IEC 23894 to identify and assess AI risks; use the 5259 series to specify, measure, manage and govern the data quality that many of those risks depend on; and use ISO/IEC 25012 or ISO 8000 for enterprise data that is not used for AI. If you are subject to the EU AI Act, map each of its data expectations to the requirements, measures and evidence you hold under 5259.

Common pitfalls and best practices

Pitfalls

Measuring everything, deciding nothing. Teams compute dozens of statistics without requirements, so no one knows which results matter or what to do when they change.
Treating quality as one check before training. Data that passed once can fail later because sources, labelling teams or the world change.
Lowering thresholds to pass. Adjusting targets after seeing the results hides the real gap and undermines every later claim.
Ignoring labels as data. In supervised learning, inconsistent labels are a data quality defect, not a minor annotation detail.
Outsourcing without evidence. Buying data or labelling without agreed responsibilities, audit samples and quality statistics leaves you unable to support any claim.
Losing provenance. Without records of origin and transformation, you cannot explain a result, honour licences or repeat a fix.
Overstating status. Calling the organisation "certified" when no accredited scheme was involved damages trust with customers and regulators.

Best practices

Start from the intended use. Write requirements for each purpose, involving the people who will rely on the results and those who could be affected.
Use the Part 2 model as a menu, not a checklist. Choose the few characteristics that drive risk for the use case and measure them consistently.
Automate controls in the pipeline. Check data at entry, after transformation and before training, and quarantine failures visibly.
Treat labelling as a managed process. Guidelines, training, agreement measurement and review samples turn labelling into evidence.
Publish a data quality report with each dataset. State what was measured, how, the results and the known limits.
Monitor live data with the same measures. Comparing operational data with training data reveals drift early.
Give leadership a regular view. Make data quality a standing item in management reporting so that accountability is real.

Summary and key takeaways

The ISO/IEC 5259 series, from ISO/IEC JTC 1/SC 42, is a five-part family on data quality for analytics and ML; Parts 1 to 4 were published in 2024 and Part 5 in 2025.
Data quality is always judged against requirements for a specified purpose; the same data can be fit for one use and unfit for another.
Part 1 gives concepts and terms, Part 2 the model and measures, Part 3 management requirements, Part 4 processes including labelling, and Part 5 governance.
Part 2 builds on ISO/IEC 25012, reusing fourteen of its characteristics, and adds nine more for ML and analytics, such as representativeness, balance, diversity, relevance and similarity.
Quality work follows the data life cycle, from motivation and specification to provisioning and decommissioning, with organisation-wide, stage-specific, horizontal and project-level requirements in Part 3.
Labelling and supplier data need the same discipline as internal data, with guidelines, evidence and agreements.
There is no dedicated accredited certification scheme; conformity with Part 3 can be self-assessed or reviewed by others, often within ISO/IEC 42001 audits.
The series helps organisations meet the data expectations of ISO/IEC 42001 and the EU AI Act without replacing them.

Reflection questions

Pick one model or dashboard you work with. Which three data quality characteristics matter most for its purpose, and what threshold would you set for each?
Where in your organisation's data pipelines are quality checks currently missing, and what would change if failing data were quarantined rather than dropped?
If an external company labels or supplies your data, what evidence do you currently receive, and what would you add to an agreement with them?
Who in your organisation is accountable for the quality of the data behind your most important AI system, and how does leadership find out when it degrades?
How would you explain to a customer or regulator, accurately and without overstating, how your organisation uses the ISO/IEC 5259 series?