ISO/IEC 25012: ISO/IEC 25012 – Tutorial (about 60 minutes)

ISO/IEC 25012 is the international standard that describes a general model of data quality: a set of fifteen named characteristics, such as accuracy, completeness, currentness and recoverability, that together describe what "good data" means inside a computer system. Data owners, data stewards, analysts, architects, testers, quality managers and auditors use it to talk about data quality in one shared language, to write measurable data requirements and to plan data quality evaluations. After this tutorial you will be able to explain the model, choose the characteristics that matter for a given use of data, turn them into requirements with targets, and plan how to measure and improve them.

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

Course overview

Edition and status: the current and only edition is ISO/IEC 25012:2008, Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model, first edition, published in December 2008 by ISO and IEC through their joint committee ISO/IEC JTC 1/SC 7 (Software and systems engineering). It is in force: at its most recent systematic review it was confirmed without change (stage 90.93, "standard confirmed", January 2025), and no revision project is listed. Its measurement companion, ISO/IEC 25024:2015 (Measurement of data quality), is also published and was last confirmed in 2022. Verified 2026-10-29 via the ISO catalogue data mirrored by the Institute for Standardization of Serbia (iss.rs), because iso.org blocks automated access.

Who it is for: data engineers, analysts and data scientists, database and application developers, architects, testers, data governance and data management professionals, product owners, quality and compliance staff, and anyone who has to say whether a set of data is "good enough" for a purpose. It is also a helpful foundation before you study data quality measurement (ISO/IEC 25024), the ISO 8000 data quality series or the ISO/IEC 5259 series on data quality for analytics and machine learning.

Prerequisites: none. You only need a general idea of what a database or a spreadsheet of records is. Every term is explained when it first appears.

Learning objectives. After this tutorial you will be able to:

Explain why a data quality model is useful and where ISO/IEC 25012 sits in the SQuaRE family of standards.
Describe the two points of view of the model, inherent and system dependent, and place each of the fifteen characteristics correctly.
Explain each characteristic in plain words and give a realistic example of a defect for it.
Select and prioritise the characteristics that matter for a specific context of use and write measurable data quality requirements.
Plan a data quality evaluation that uses measures in the style of ISO/IEC 25024 and an evaluation process in the style of ISO/IEC 25040.
Explain what conformity and certification mean (and do not mean) for this standard.
Relate ISO/IEC 25012 to ISO/IEC 25010, ISO/IEC 25024, ISO 8000, ISO/IEC 5259 and the DAMA body of knowledge.

Lesson 1 – Origins, purpose and scope

Why a data quality model is needed

Almost every organisation says that its data is an asset, and almost every organisation has a story about bad data: parcels delivered to an old address, invoices sent with the wrong tax rate, a dashboard that shows two different revenue figures for the same month, a machine learning model trained on records where half the age values were zero. When people try to fix these problems, they quickly find they lack a shared vocabulary. One person says the data is "wrong", another says it is "out of date", a third says it is "inconsistent", and a fourth says the real problem is that nobody can find it. These are different problems with different causes and different owners.

A quality model is a structured list of characteristics that together describe quality. Once a group agrees on a model, it can ask precise questions: which characteristics matter for this use of the data, how much of each is required, how will we measure it, and who is responsible for it. ISO/IEC 25012 provides exactly such a model for data. It does not tell you how good your data must be; it tells you which aspects of quality exist so that you can decide, for your own context, how good each aspect must be.

The SQuaRE family

ISO/IEC 25012 belongs to the SQuaRE series, short for Systems and software Quality Requirements and Evaluation, numbered ISO/IEC 25000 to 25099. SQuaRE replaced two older series: ISO/IEC 9126 (software product quality) and ISO/IEC 14598 (software product evaluation). The series is organised into divisions. A management division explains how the family is used; a quality model division defines models (ISO/IEC 25010 for software product quality and quality in use, ISO/IEC 25012 for data); a measurement division defines measures (for example ISO/IEC 25024 for data); a requirements division explains how to specify quality requirements; and an evaluation division describes how to evaluate (for example ISO/IEC 25040).

Before SQuaRE, quality models looked mainly at software: is the program reliable, efficient, maintainable? But many systems are mostly about data. A customer relationship system, a land registry or a clinical records system can run perfectly as software and still deliver poor results because the data inside it is poor. SC 7 therefore added a model specifically for data, published in 2008. It was published before ISO/IEC 25010 (first edition 2011, current edition 2023) replaced the older ISO/IEC 9126-1 software model, so it is older than the software model it now sits beside; the data model itself has not needed to change and was confirmed again in 2025.

Scope

ISO/IEC 25012 defines a general data quality model for data held in a structured format within a computer system: think of records in tables, fields with types and allowed values, and relationships between entities. That is its primary focus. Many teams also apply its ideas to semi-structured data such as JSON documents or event streams, and to data used for analytics and machine learning, but you should know that the standard was written with structured data in mind and that newer standards (such as the ISO/IEC 5259 series) address analytics and machine learning data more directly.

According to its catalogue description, the model can be used to establish data quality requirements, to define data quality measures, and to plan and perform data quality evaluations. In practice that covers many situations: specifying what a data supplier must deliver, defining acceptance criteria for a data migration, setting quality goals for a master data programme, checking data before it feeds a report or model, or deciding where a data quality problem is coming from.

What ISO/IEC 25012 does not do

It does not set target values. It never says that 98 % completeness is good; you decide targets based on your context of use.
It does not define a management system, so it is not a "certify the organisation" standard like ISO 9001 or ISO/IEC 27001.
It does not prescribe tools, data profiling techniques or a particular data architecture.
It does not provide the detailed measures; those come from ISO/IEC 25024, or from measures you define yourself.

Keep this boundary in mind. ISO/IEC 25012 is the vocabulary and structure layer. It is short, abstract and stable, and its value comes from how you use it together with measures, processes and governance.

Lesson 2 – Key concepts and vocabulary

The terms below are explained in our own words. The standard's official definitions are worded more precisely, and you should consult the purchased text for formal work. What matters here is that you understand the ideas well enough to apply them.

Data – facts, measurements or descriptions recorded in a fixed form so that people or programs can store, exchange and process them. In practice: the values held in fields and records.
Data quality – how well the properties of a data set meet the needs that users have stated, and the needs they take for granted, in the conditions where the data is actually used. Quality is always relative to a need and a use, never absolute.
Data quality model – an agreed list of characteristics that gives you a structure for writing data quality requirements and for judging data against them. ISO/IEC 25012 is such a model.
Data quality characteristic – a named group of related data properties that together describe one aspect of quality, for example accuracy or currentness. The model has fifteen.
Inherent data quality – the point of view that looks at the data itself: its values, the rules and constraints on those values, the relationships between values, and its metadata. It describes the intrinsic potential of the data to meet needs.
System-dependent data quality – the point of view that looks at how far a computer system achieves and keeps the quality of the data it holds. It depends on the technology: hardware, system software such as backup tools, and other software such as migration tools.
Context of use – the users, goals, tasks, resources and environment in which data is used. The same data can be good for one context (a yearly statistical report) and poor for another (same-day delivery routing).
Entity and attribute – an entity is a thing about which data is held (a customer, an order, a patient); an attribute is a property of that entity (a postcode, an order date). Most characteristics are judged at attribute, record or data set level.
Metadata – data that describes other data: field definitions, units, formats, allowed values, source, owner, last update time. Several characteristics, especially understandability and traceability, depend heavily on good metadata.
Syntactic accuracy – how close a value is to the set of values that are correctly formed for its domain. "Lodnon" is a syntactic error for a city field because it is not a valid city name at all.
Semantic accuracy – how close a value is to the set of values that are correctly meaningful for the real thing it describes. "Paris" for a customer who actually lives in London is well formed but semantically wrong.
Data quality requirement – a statement of the quality a data set must have for a context of use, ideally expressed as a characteristic, a measure and a target, for example "at least 99 % of active customer records have a postcode that is valid for their country".
Data quality measure – a defined way to quantify a characteristic, usually a ratio such as "records with a valid value divided by records checked". ISO/IEC 25024 provides a catalogue of such measures.
Quality measure element (QME) – a basic count or value used to build a measure, such as "number of records checked" or "number of records with an empty mandatory field". SQuaRE describes QMEs in ISO/IEC 25021.
Data quality evaluation – a systematic examination of the extent to which data meets specified requirements, producing results that support a decision (accept, reject, improve, monitor).

Two ideas that shape everything else

First, quality depends on use. A delivery address that is accurate to the street but not the flat number is fine for a regional sales report and poor for a courier. This is why the model is applied per context of use, and why the first step of any data quality work is to describe that context.

Second, quality has two sources. Some problems come from the content: someone typed the wrong birth date, a supplier sent a stale price list, two systems recorded different values. Other problems come from the systems that hold and move the data: the database is down when the report runs, the backup cannot be restored, the migration tool truncates long names. The inherent and system-dependent points of view separate these two sources, which also tends to separate responsibilities: business data owners for content, technology teams for the systems.

Lesson 3 – Structure of the model: fifteen characteristics in two points of view

The heart of ISO/IEC 25012 is a classification of fifteen characteristics according to the two points of view. Five characteristics are purely inherent, three are purely system dependent, and seven belong to both points of view, because both the data content and the technology influence them. Figure 1 shows the structure.

Figure 1 – The fifteen characteristics grouped by point of view: five inherent, seven in both, three system dependent.

Inherent characteristics

These five describe the data content itself. You can, in principle, judge them by comparing the data with reality, with rules or with other data, without caring which database it sits in.

Accuracy – the data correctly represents the true value of what it describes. It has the two aspects explained earlier: syntactic (well formed for the domain) and semantic (true for the real entity). Example defect: a product weight recorded in grams in a field defined as kilograms.
Completeness – the data about an entity has values for all the attributes that are expected in the context, and the data set contains all the expected entity instances. Missing values in mandatory fields and missing records (customers who exist but are not in the file) are both completeness defects.
Consistency – the data contains no contradictions and fits together with related data in the context. This can be within one record (a delivery date before the order date), across records about the same entity (two addresses for one customer in two systems), or across similar entities (one region coding countries with two letters, another with three).
Credibility – users trust the data and are willing to believe it. Credibility includes the idea of authenticity: the origin of the data and its attributions are genuine. Data from a verified official register is usually more credible than data scraped from unknown websites, even before anyone checks its accuracy.
Currentness – the data is of the right age for its use, in other words up to date enough. An exchange rate from last week is current enough for an annual budget and far too old for a payment.

Characteristics in both points of view

These seven depend on the data and on the system. Each has an inherent side (for example, how the values or metadata are designed) and a system-dependent side (how the technology preserves or delivers that quality).

Accessibility – the people who need the data can actually get at it, including people with a disability who rely on assistive technology or adapted settings. Inherent side: offering text equivalents and clear labels; system side: an interface that works with screen readers.
Compliance – the data follows the rules that apply to it: standards, agreed conventions and legal or regulatory requirements about data. Examples: dates stored in an agreed international format, country codes from a standard code list, retention rules required by law.
Confidentiality – the data can be accessed and interpreted only by authorised users. This is the security aspect inside the data quality model: classification and masking on the content side, access control and encryption on the system side.
Efficiency – the data can be stored and processed at the required speed without wasting storage, processing power or other resources. Free-text fields that must be parsed every time, or codes so ambiguous that they need repeated lookups, reduce efficiency even when the values are correct.
Precision – the data is exact enough, or discriminating enough, for its use. A geographic coordinate with two decimal places identifies an area of roughly a kilometre; a courier needs more. Note that precision is different from accuracy: a value can be very precise and still wrong.
Traceability – there is a record of who accessed the data and of every change made to it. Who changed this credit limit, when, and from which value? Traceability is closely related to the wider practice of data lineage, but in this model its emphasis is on recording access and changes.
Understandability – users can read the data and work out what it means, because it uses suitable languages, symbols and units. Clear field names, documented code lists and units in the metadata are typical ways to raise it.

System-dependent characteristics

These three are achieved almost entirely by the technology that holds the data.

Availability – authorised users and applications can retrieve the data when they need it. A perfect data set in a database that is down at month-end has an availability problem.
Portability – the data can be moved to, loaded into or swapped onto another system without losing the quality it had. Migrations that silently change character encodings or truncate decimals damage portability.
Recoverability – after a failure, the data can be brought back to an agreed level of service and quality, for example through backups, replication and tested restore procedures.

Reading the model correctly

Three remarks help you avoid misreadings. First, the characteristics are not ranked; none is "more important" in the standard. Importance comes from the context of use. Second, they are not independent: improving confidentiality by masking data may lower understandability for some users, and improving currentness with more frequent loads may affect efficiency. Third, the model is a checklist of aspects, not a list of tests. For each characteristic you still need measures, and those measures need targets that someone has agreed.

A useful way to remember the split is to ask: "Could this problem exist if the data were printed on paper?" Wrong values, missing values, contradictions, unbelievable sources and stale values would all still be visible on paper: inherent. A database outage, a failed restore or a broken migration would not exist on paper: system dependent. Problems such as confidentiality or understandability have a foot in both worlds.

Lesson 4 – How it works in practice

ISO/IEC 25012 tells you what to look at; it does not provide a step-by-step method. In practice, organisations combine it with the requirements and evaluation ideas of the wider SQuaRE family and with their own data governance. The typical cycle is shown in Figure 2 and described below.

Figure 2 – A typical cycle for applying the model: from context of use to requirements, measurement, evaluation and improvement.

Step 1 – Describe the context of use

Write down which data set you are talking about (for example, "active customer records in the CRM"), who uses it, for which tasks, and what happens when it is wrong. Concrete consequences such as "failed deliveries cost money" or "regulatory reports must be resubmitted" turn an abstract discussion into a business case.

Step 2 – Identify stakeholders and needs

Data quality has many stakeholders: the people who create the data, those who consume it, the data owner who is accountable for it, the data steward who looks after its definitions and rules day to day, the technology team that runs the systems, and sometimes regulators or customers. Each group cares about different characteristics. Interviews and short workshops are usually enough to collect needs.

Step 3 – Select and prioritise characteristics

Go through the fifteen characteristics as a checklist and ask, for each one, "Does this matter for this use, and how much?" Typically three to six characteristics are critical, a few more are relevant, and some are not applicable. Record the reasons. This tailoring step is where the model saves most time, because it stops teams from both forgetting important aspects and measuring everything.

Step 4 – Write requirements with targets

A good data quality requirement names the data, the characteristic, the measure and the target, and sometimes the scope and frequency. Compare "addresses must be good" with "at least 99 % of active customer addresses pass postal validation, checked weekly". The second can be tested, discussed and agreed. Where possible, base targets on the cost of defects and on what the business process can tolerate, not on round numbers.

Step 5 – Choose measures

For each selected characteristic, choose one or more measures. ISO/IEC 25024 provides a catalogue of data quality measures organised by the same fifteen characteristics, most expressed as ratios between 0 and 1. You may use them as they are, adapt them or define your own, but document the formula, the data needed, the measurement method and the meaning of a high or low value.

Step 6 – Measure

Measurement can be automated (data profiling, rule checks in pipelines, database queries, monitoring of uptime and restore tests) or manual (sampling records and checking them against a trusted source, surveying users about credibility or understandability). Semantic accuracy usually needs a reference: an authoritative register, a field visit, a confirmation from the customer.

Step 7 – Evaluate and decide

Compare results with targets and decide: accept the data, reject a delivery, release with known limitations, or start improvement. Report results per characteristic so that owners can see where action is needed.

Step 8 – Improve and monitor

When targets are missed, look for root causes rather than only cleansing the symptoms. Inherent defects are often best prevented at the point of capture (validation rules, picklists, reference data), while system-dependent defects need technical fixes (capacity, backup, migration testing). After improvement, keep measuring on a schedule, because data quality drifts as people, processes and systems change.

Roles and artefacts

Role	Typical responsibility in data quality work
Data owner	Accountable for a data domain; approves requirements, targets and priorities.
Data steward	Maintains definitions, rules and metadata; investigates inherent defects.
Data producer	Creates or captures the data; follows capture rules.
Data consumer	Uses the data; states needs and reports issues.
Platform or IT team	Runs the systems; responsible for system-dependent characteristics such as availability and recoverability.
Evaluator	Plans and performs measurement and reports results, internal or independent.

These role names are common data management practice, not terms defined by ISO/IEC 25012. Typical artefacts are a data quality requirements specification (a table of characteristic, measure, target and owner per data set), a measure catalogue, a data quality rule set implemented in tools, an evaluation report, and an issue log with root causes and actions.

Using the model across the data life cycle

The model is useful at every stage of a data set's life. At design time it helps you write field definitions, constraints and metadata that support accuracy, compliance and understandability. At acquisition it gives you acceptance criteria for data from suppliers or other systems. In operation it structures monitoring dashboards. During migration it reminds you to check portability, precision and completeness before and after the move. At retirement it reminds you that confidentiality and compliance still apply to archives.

Lesson 5 – Assessment, certification and compliance

Is there an ISO/IEC 25012 certificate?

There is no ISO certification scheme for ISO/IEC 25012 in the way that there is for management system standards such as ISO 9001 or ISO/IEC 27001. ISO itself does not certify anyone, and ISO/IEC 25012 contains a model rather than requirements for an organisation's management system. What an organisation can honestly say is that it uses the ISO/IEC 25012 model to specify and evaluate its data quality. A few certification bodies and test laboratories offer their own evaluations of data sets or of data quality practices that are built on ISO/IEC 25012 and ISO/IEC 25024. Such marks are private schemes: check who operates them, what exactly was evaluated (which data set, which characteristics, which targets) and when, before you rely on them.

What a data quality evaluation looks like

A data quality evaluation applies the model to a specific data set and context. In SQuaRE the general evaluation process is described in ISO/IEC 25040, which walks through establishing the evaluation requirements, specifying the evaluation (measures and criteria), designing the evaluation activities, executing them, and concluding with a report. Applied to data, this means: agree the purpose and scope, choose characteristics and measures, set acceptance criteria, collect the measurements, judge the results and record the conclusions and limitations.

Figure 3 – How a characteristic becomes a number: measure, measure elements, measured value, and a judgement against the agreed target.

How measures are built

Most data quality measures follow the same pattern: count the items in scope (records, fields, values, requests, restore tests), count the items that satisfy or fail a rule, and divide. For completeness, the rule might be "mandatory field has a value". For syntactic accuracy, "value matches the allowed format or code list". For semantic accuracy, "value agrees with the trusted reference". For currentness, "record was updated within the allowed age". For availability, "requests for the data succeeded within the agreed time". Because these ratios fall between 0 and 1, they are easy to compare and trend, but each one is only as good as its rule and its scope. A completeness ratio of 1.0 on a column nobody uses tells you nothing useful.

Some characteristics are harder to measure with automated rules. Credibility and understandability often need user feedback or expert review. Semantic accuracy needs a reference source or sampling against reality. Recoverability needs actual restore tests, not just the existence of backup files. A credible evaluation is open about which measures were automated, which were sampled, and what the sample size was.

Internal and independent evaluations

Most evaluations are internal: a data quality team or data stewards run them as part of data governance. Independent evaluations are used when the stakes are higher, for example when a regulator relies on submitted data, when a data supplier must prove quality to a buyer, or before a large migration. In both cases the value comes from clear requirements and transparent methods, not from the label "ISO".

Compliance and regulation

ISO/IEC 25012 is voluntary. However, many laws and supervisory rules require data to be accurate, complete, up to date or protected: data protection laws ask for accurate and up-to-date personal data and for security, financial supervisors expect accurate and complete risk data, and AI regulation increasingly asks for good quality training data. The model does not replace these legal requirements, but it gives you a structured way to translate them into characteristics, measures and evidence. For example, a legal duty to keep personal data accurate becomes requirements on accuracy and currentness, with measures and a review cycle.

Lesson 6 – Worked example: delivery addresses at a parcel company

Harbourline Logistics (a fictional company) delivers about 40,000 parcels a day for online shops. Customers enter addresses in many shops' checkouts; addresses also arrive from a call centre and from partner carriers. All of them end up in a customer address hub that feeds route planning and customer notifications. Failed first-time deliveries are rising, and the operations director asks the data team for a structured view of the problem. All figures in this example are illustrative.

Step 1 – Context of use

The data set is "delivery addresses of parcels due in the next 48 hours". It is used by the route planner (an automated system), by drivers (through a handheld app) and by the notification service that sends delivery time messages. Wrong or late data causes failed deliveries, extra kilometres, complaints and, for some addresses, breaches of data protection rules if the wrong person receives a message.

Step 2 – Stakeholders

The operations director acts as data owner. A data steward in the customer service team owns address rules. Producers are the shops, the call centre and partners. Consumers are route planning, drivers and the notification service. The platform team runs the address hub.

Step 3 – Selected characteristics

Working through the fifteen characteristics, the team rates them as follows.

Characteristic	Priority	Reason in this context
Accuracy (syntactic and semantic)	Critical	A wrong postcode or house number sends the van to the wrong place.
Completeness	Critical	Missing flat numbers and missing phone numbers cause failed deliveries.
Currentness	Critical	Changed addresses must reach the planner before routes are built at 04:00.
Precision	High	Coordinates must be fine enough to identify the right entrance.
Consistency	High	Hub and shop data disagree for some customers.
Confidentiality	High	Addresses and phone numbers are personal data.
Availability and recoverability	High	The planner cannot run without the hub at 04:00.
Traceability	Medium	Needed to investigate who changed an address and when.
Credibility, understandability, compliance	Medium	Partner data is trusted less; driver notes must be readable; postal formats apply.
Accessibility, efficiency, portability	Low for now	No current issues; portability will matter for the planned platform move.

Step 4 and 5 – Requirements and measures

Syntactic accuracy: at least 99.5 % of addresses have a postcode in the valid format for their country (rule check on every record).
Semantic accuracy: at least 98 % of addresses match the national address register, and a weekly sample of 200 failed deliveries is reviewed for address errors.
Completeness: at least 97 % of addresses in multi-occupancy buildings include a flat or unit number; at least 95 % of parcels have a contact phone number.
Currentness: 99 % of address changes received before 03:30 are in the hub before route building.
Precision: coordinates stored to at least five decimal places for all addresses.
Consistency: fewer than 0.5 % of customers have conflicting active addresses in the hub and the source shop.
Availability and recoverability: the hub is available for the 04:00 route build on at least 99.9 % of days; a full restore is tested monthly and completes within one hour.
Confidentiality and traceability: only authorised roles can view full addresses; every change records user, time, old and new value.

Step 6 and 7 – Baseline results

The first measurement shows syntactic accuracy at 99.7 % (target met), semantic accuracy at 95.1 % (missed), flat-number completeness at 89 % (missed), currentness at 92 % (missed), precision met, consistency at 2.3 % conflicting (missed), availability met, and a restore test that took three hours (missed). Traceability is partial: changes from the partner feed are not logged with the source.

This result is already useful: it shows that the problem is not "bad data" in general. Formats are fine; the real issues are semantic accuracy, missing flat numbers, late updates, conflicting copies and a weak recovery capability. Each has a different cause and a different owner.

Figure 4 – The improved address flow at Harbourline: validation at entry, one hub, a change log and tested recovery.

Step 8 – Root causes and improvements

Semantic accuracy: the checkout forms accepted any text. Harbourline offers shops an address lookup service that validates against the national register at entry, and flags unverified addresses for driver attention.
Completeness: the flat-number field was optional. The validation step now asks for it when the register shows a multi-occupancy building.
Currentness: the call centre exported changes in a nightly batch at 05:00, after route building. The export is replaced by an immediate update.
Consistency: shops kept their own copies and resent old addresses. A rule now treats the most recently verified address as authoritative and notifies the shop of conflicts.
Recoverability: the restore procedure was untested and slow. The platform team changes the backup approach and tests restores monthly.
Traceability: the partner feed now writes the source and batch identifier into the change log.

Three months later, semantic accuracy is 98.4 %, flat-number completeness 97.6 %, currentness 99.3 %, conflicts 0.4 % and restores finish in 40 minutes. Failed first-time deliveries fall noticeably. The team keeps a weekly dashboard per characteristic and reviews targets each quarter. Before the planned move to a new platform, it adds portability requirements: record counts, encodings and coordinate precision must be identical before and after migration.

Notice what the model contributed. It did not fix anything by itself. It gave the team a checklist that surfaced recoverability and traceability, which nobody had raised; a vocabulary that separated content problems from system problems; and a structure for requirements that the data owner could approve.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 25012 is rarely used alone. Figure 5 shows its closest neighbours, and the table compares them.

Figure 5 – ISO/IEC 25012 inside SQuaRE (solid lines) and its links to other data quality frameworks (dotted lines).

Standard or framework	What it provides	How it relates to ISO/IEC 25012
ISO/IEC 25010 (product quality model)	Quality characteristics of software and systems, such as functional suitability, reliability, security and maintainability	Sister model for the software side. Use 25010 for the system and 25012 for the data it holds; together they cover the whole product.
ISO/IEC 25024 (measurement of data quality)	A catalogue of data quality measures and measure elements	Direct companion: it turns each 25012 characteristic into measurable quantities.
ISO/IEC 25040 (evaluation process)	A general process for planning and performing quality evaluations	Provides the method for evaluating data against requirements built on the 25012 model.
ISO 8000 series (data quality)	A multi-part series on data quality, including concepts, master data exchange and a data quality management process reference model (Part 61)	Complementary: 25012 describes characteristics; ISO 8000 adds data quality management processes and requirements for exchanging quality master data.
ISO/IEC 5259 series (data quality for analytics and machine learning)	Terminology, quality measures, management requirements and process framework for analytics and ML data	Newer series for AI and analytics data; builds on the same idea of characteristics and measures and extends it with ML-specific concerns such as representativeness and labelling.
DAMA-DMBOK (DAMA International)	A body of knowledge for data management, including data quality, governance, metadata and master data	Not a standard. Describes practices and roles; often uses its own "data quality dimensions" that overlap with the 25012 characteristics.

Mapping to everyday "dimensions"

Many data teams use lists of data quality "dimensions" from vendor tools or from DAMA-style practice, such as accuracy, completeness, consistency, timeliness, validity and uniqueness. These lists are useful but vary between sources. ISO/IEC 25012 offers a stable, internationally agreed reference you can map them to: "timeliness" is close to currentness; "validity" (conforms to format and rules) is close to syntactic accuracy and compliance; "uniqueness" (no unwanted duplicates) is usually treated as an aspect of consistency or accuracy, depending on the source. Writing down such a mapping lets a team keep its familiar terms while staying aligned with the standard.

Links to governance and security standards

Confidentiality, availability and recoverability overlap with information security and business continuity. If your organisation already runs an information security management system (ISO/IEC 27001) or business continuity management (ISO 22301), reuse their controls and evidence for those characteristics rather than building a parallel process. Likewise, an AI management system (ISO/IEC 42001) expects data quality to be managed for AI systems; the 25012 characteristics are a natural way to express those data requirements.

Common pitfalls and best practices

Common pitfalls

Treating data quality as one number. A single "quality score" hides the fact that a data set can be accurate but stale, or complete but unavailable.
Measuring every characteristic everywhere. Effort goes into measures that no decision depends on, and the important problems get lost in the noise.
Setting targets without a context of use, for example "100 % for everything". Targets that cannot be reached, or that do not matter, are ignored.
Measuring only what is easy to automate. Format checks are easy; semantic accuracy, credibility and recoverability need reference data, sampling, user feedback or restore tests, and are often skipped.
Confusing precision with accuracy, or traceability with lineage, and therefore measuring the wrong thing.
Cleansing data repeatedly downstream instead of fixing the cause at capture or in the system.
Claiming to be "ISO/IEC 25012 certified" when no ISO certification exists for the model.

Best practices

Start from a specific data set and context of use, and write down who uses the data, for what, and what a defect costs.
Use the fifteen characteristics as a checklist, record which ones are critical, relevant or not applicable, and why.
Express every requirement as data set, characteristic, measure, target and owner, and get the data owner to approve it.
Assign inherent characteristics mainly to business owners and stewards, and system-dependent ones mainly to platform teams, with shared ownership for the seven in both.
Document each measure's formula, scope and method, ideally reusing ISO/IEC 25024 measures so that results are comparable over time.
Prevent defects at the source with validation, reference data and clear metadata, and test recovery for real.
Monitor on a schedule and revisit targets when the context of use changes, for example when the data starts feeding a machine learning model.

Summary and key takeaways

ISO/IEC 25012:2008 is the SQuaRE data quality model; it is current, was last confirmed in 2025, and has no newer edition.
It defines fifteen characteristics in two points of view: five inherent, three system dependent, and seven in both.
Inherent quality is about the data content and its rules and metadata; system-dependent quality is about how technology preserves and delivers that data.
Quality is always judged for a context of use; the standard sets no targets, so you must.
Good requirements combine a data set, a characteristic, a measure, a target and an owner; ISO/IEC 25024 supplies matching measures and ISO/IEC 25040 an evaluation process.
There is no ISO certification for ISO/IEC 25012; organisations use the model and may undergo private, clearly scoped evaluations.
The model works best as a shared vocabulary and checklist inside wider data governance, alongside ISO 8000, ISO/IEC 5259 and DAMA-style practice.

Reflection questions

Pick a data set you work with. Which three characteristics are most critical for its main use, and which three could you safely rate as not applicable? Why?
Write two measurable requirements, one for an inherent characteristic and one for a system-dependent characteristic, for that same data set.
Think of a recent data problem in your organisation. Was its root cause in the content, in the systems, or both, and who should have owned the fix?
Which of your data quality checks are automated today, and which characteristics are not measured at all because they need sampling, references or user feedback?
If your data started feeding a machine learning model tomorrow, which targets would you change and which new concerns would you need to add?