How ISO 25010 Frameworks Reduce Technical Debt in Long-Term Projects

ISO/IEC 25010 is the international standard that defines what software quality actually means – nine measurable characteristics a product either meets or doesn't. 

The current edition, ISO/IEC 25010:2023, is part of the broader ISO/IEC 25000 SQuaRE family and gives development teams a shared vocabulary for making quality trade-offs explicit: which characteristics matter most for this product, which can be deprioritized, and which gaps are worth fixing before they become expensive.

Unlike a testing certification, the model works at the level of expectations rather than process. It gives product, engineering, QA, and business teams a common framework for deciding what "good enough" should mean in context. 

In 2026, that question applies just as much to cloud platforms, mobile products, and AI-enabled systems as it does to traditional business software.

Executive Summary

ISO/IEC 25010 is a quality model that evolved beyond ISO 9126 and, in its 2023 edition, defines nine product-quality characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, and safety.Used well, it shifts quality from a vague aspiration to a set of explicit trade-offs: teams decide which characteristics matter most for their domain, translate them into requirements and engineering practices, and then revisit them continuously rather than treating quality as a one-time release gate.In 2026, the model remains relevant because it is technology-agnostic: it can be used to assess traditional business software, cloud platforms, mobile products, and increasingly AI-enabled systems. Its practical value lies in giving product, engineering, QA, and business teams a common framework for discussing what "good enough" should mean in context. 

How Is ISO 25010 Different from ISO 9126 and ISTQB?

The earlier ISO/IEC 9126 standard grouped software quality into six high-level characteristics: functionality, reliability, usability, efficiency, maintainability, and portability. 

ISO 25010:2011 expanded that model to eight characteristics by adding security and compatibility, and refining terms such as functionality into functional suitability and efficiency into performance efficiency.

The 2023 revision goes further by introducing safety as a standalone characteristic and renaming usability to interaction capability and portability to flexibility. 

Several sub-characteristics were also updated in the 2023 edition.

For example, reliability now uses faultlessness instead of maturity, interaction capability introduces elements such as inclusivity and self-descriptiveness, and security/flexibility gain new emphasis through sub-characteristics such as resistance and scalability.

The difference between the two lies mainly in how they categorize and define those characteristics of software quality requirements that we call non-functional.

ISO 25010 is also only one part of the broader ISO/IEC 25000 SQuaRE family, which covers quality models, measurement, and requirements.

ISTQB serves a different purpose. It is a software testing certification scheme focused on tester knowledge and testing practices. The two are complementary: ISO 25010 helps teams answer "which quality characteristics matter for this product?", while ISTQB-informed testing practices help determine how to validate whether those expectations are being met.  

So, in short, we move from this –

ISO/IEC 9126 categorization of software quality requirements. (Source: Journal Of Object Technology)

- to this - 

ISO/IEC 25010 categorization of software quality requirements (Source: ISO20500.com)

– and then to this:

Update on ISO 25010, version 2023 (Source: Quality.Arc42)

So what is QA, then?

What Does “Quality” Actually Mean in Software?

Quality may be defined as the non-inferiority or superiority of something; a measure of that thing being suitable for its intended purpose (fitness for purpose) while satisfying customer expectations. 

Simply put, the quality of an application basically boils down to the way it’s working.

One additional precept that informs our work is: “Anything can be measured, but that does not mean that everything should be measured.”

A quality app must meet the following requirements:

• must work without crashing or producing errors,

• must be stable,

• all of its functionalities must work, too,

• must make all necessary calculations,

• must show accurate data,

• all users must have appropriate permissions.

As you will see in a minute, those requirements are all included in ISO 25010.

The Cost of Invisible Defects

It is a common misconception that a "bug-free" application is inherently a high-quality one. A product can pass every functional test, never crash, and still harbor invisible defects that will drain your budget over time.

For instance, an app can be completely functional but utterly unmaintainable. When that happens, adding a simple new feature takes weeks instead of days. A system might work perfectly for 100 users, but if it lacks performance efficiency, scaling it up will cause your cloud infrastructure costs to skyrocket. These architectural flaws are usually discovered too late, often when user growth forces a complete, expensive rewrite.

By applying the ISO 25010 framework early, you treat software quality not just as a technical checklist, but as an insurance policy for your budget. It helps you catch and mitigate structural risks before they compound into financial liabilities.

How ISO 25010 Creates Business Value

The mechanism behind ISO 25010 is straightforward once you separate the framework from the work it enables.

Without a shared quality model, every team makes implicit trade-offs. A backend engineer pushes hardest on reliability. A product manager pushes hardest on new features. A QA lead pushes hardest on regression. A security architect pushes hardest on authentication flows. None of them is wrong, and none of them sees the full picture. Quality decisions get made in scattered conversations, and the gaps surface in production.

ISO 25010 turns those scattered conversations into one structured one. The chain of value runs like this: shared vocabulary → explicit trade-offs → fewer surprises in production → less rework → faster shipping with confidence.

Concretely: when product, engineering, QA, and business agree that performance efficiency and security matter most for a banking app while interaction capability and accessibility take priority for a public-facing healthcare portal, every subsequent decision (architecture, testing, monitoring, hiring) gets oriented around the same priorities. The cost of misalignment, which usually shows up as expensive rework after launch, drops sharply.

The framework's business value compounds when teams use it continuously. A one-time release-gate check captures a snapshot. Treating ISO 25010 as the lens for ongoing reviews captures the trajectory.

What Are the Nine Quality Characteristics in ISO 25010?

The standard categorizes application quality into nine characteristics and lists the aspects that need to be verified before release.

1. Functional Suitability. Does the App Do What It Should?

• What it does: Verifies whether the software includes the right functions and delivers correct results for the problem it was built to solve.

• Why it matters (impact): Ensures high task completion rates. Perfect functional completeness matches market needs, which directly reduces early user churn and increases product adoption.

2. Performance Efficiency. Does the App Use Resources Well?

• What it does: Measures whether the app delivers acceptable response times and throughput without wasting infrastructure, memory, or processing power.

• Why it matters (impact): Protects profit margins. Efficient resource utilization optimizes cloud infrastructure costs (AWS/Azure) and protects conversion rates by ensuring load times remain under 2 seconds during traffic spikes.

3. Compatibility. Can the App Work Alongside Other Systems?

• What it does: Assesses whether the application can share an environment and exchange information with other existing products without conflict.

• Why it matters (impact): Accelerates time-to-market. High interoperability ensures your software integrates seamlessly with enterprise legacy systems (like CRM or ERP), removing technical blockers during B2B sales cycles.

4. Interaction Capability. Can the Intended Users Actually Operate It?

• What it does: Evaluates how easily intended users can understand, navigate, and receive support from the software interfaces. This includes accessibility checks, often tested automatically via the axe DevTools browser extension.

• Why it matters (impact): Lowers customer support overhead and ensures regulatory compliance. An inclusive interface, like the one we built for the Merck DORA healthcare app, drastically reduces onboarding friction. Furthermore, EU-facing products must meet specific legal baselines such as WCAG 2.2 accessibility standards. 

This closely aligns with the mandatory EN 301 549 European standard for digital accessibility

5. Reliability. How Does the App Hold Up in Real Conditions?

• What it does: Tests whether the application continues to perform consistently under both expected and unexpected load or network conditions.

• Why it matters (impact): Protects brand reputation. High fault tolerance and rapid recoverability guarantee system uptime, saving the business from costly SLA downtime penalties and loss of institutional trust.

6. Security. Does the App Protect Data and Maintain Trust?

• What it does: Ensures the software restricts unauthorized access, protects sensitive information, and creates verifiable accountability. Delegated authorization is frequently handled by the OAuth 2.0 authorization framework.

• Why it matters (impact): Shields the business from liability. Rigorous security mechanisms mitigate the risk of data breaches and ensure strict compliance with the NIS2 cybersecurity directive and GDPR.

7. Maintainability. How Easy Is It to Change the App Over Time?

• What it does: Measures how efficiently the product's codebase can be modified, adapted, analyzed, and tested after its initial launch.

• Why it matters (impact): Accelerates the product roadmap. Strict modularity ensures that future feature releases are shipped up to 20% faster, preventing the codebase from becoming an expensive "spaghetti" structure.

8. Flexibility. Can Software Adapt to Different Environments?

• What it does: Evaluates the software's ability to be successfully installed, replaced, or scaled across changing hardware, software, or usage contexts (formerly "portability").

• Why it matters (impact): Prevents vendor lock-in. Prioritizing flexibility ensures the product is "Cloud-Ready," allowing for cost-effective, seamless infrastructure migrations (e.g., from AWS to Azure) as data volumes grow.

9. Safety. Does the System Avoid Causing Harm?

• What it does: Identifies whether the product avoids causing unacceptable risk to people, business assets, or the environment during its operation.

• Why it matters (impact): Mitigates critical real-world risks. In regulated verticals like HealthTech, IoT, or FinTech, verifiable fail-safe behaviors prevent automation errors from causing physical or financial harm.

How Do Teams Use ISO 25010 to Measure Quality in Practice?

Software development is a process, and ISO 25010 is the lens we use to keep that process honest. It turns vague “does this work?” into a structured set of questions across nine characteristics, so we can see not just whether the software works today, but whether it will keep working under real conditions tomorrow.

At Monterail, the starting point is still simple: the core flows have to work, every time. We verify that with functional tests, exploratory sessions, and regression suites. 

The problem is that repeated routines create blind spots; people naturally optimize for the areas they touch most often and quietly ignore the rest.

That is where ISO 25010 becomes our backstop. After we close the Jira board for a given iteration, we take the product back to the standard and ask, characteristic by characteristic, “What are we not seeing?”

For example:

• Performance efficiency: Do we have actual response-time benchmarks using realistic production-like data, or does the system just feel fast in development?

• Reliability: Have we tested what happens when something fails, or only the happy path where everything behaves as expected?

• Interaction capability: Can intended users actually navigate the product, recover from mistakes, and get the assistance they need, including in less-than-ideal real-world conditions?

• Safety: If this product influences real-world actions or critical decisions, have we thought seriously enough about fail-safe behavior, hazard warning, and safe integration?

Internally, we do not treat ISO 25010 as a one-time release checklist. Instead, we use it as an ongoing framework for thinking about software quality throughout the development lifecycle.

Not every characteristic matters equally on every project. Installability is critical for mobile apps, for example, but far less important for an internal web dashboard. Still, reviewing all nine characteristics helps prevent important quality concerns from being ignored simply because they were never explicitly discussed.

ISO 25010 also helps us make better sense of day-to-day QA work. We already track defects, tasks, and test execution in Jira, but the model gives that information a clearer structure by helping us ask:

• Which quality attributes were deliberately prioritized?

• Which trade-offs were made consciously?

• Which areas still present risk and should be discussed with the client?

We have also reflected ISO 25010 principles more directly in our engineering workflow, for example, by treating performance efficiency through monitoring targets and service-level objectives, reliability through failure testing and recovery policies, security through dependency scanning and threat modeling.

ISO 25010 does not replace testing tools or engineering practices but gives teams a shared framework for deciding what software quality should actually mean for a given project.

What Must Be True for ISO 25010 to Work in Your Org

Four conditions decide whether ISO 25010 actually delivers on the value its framework promises.

Integration: The model has to fit your existing delivery workflow. ISO 25010 reviews bolted on as a separate ceremony rarely survive the second sprint. The model works when characteristic-based questions show up in sprint planning, code review templates, definition-of-done checklists, and post-incident reviews. Pick three or four characteristics most relevant to your product and embed them in the rituals you already run.

Compliance: Quality characteristics intersect with regulatory regimes (GDPR, NIS2, HIPAA, sector-specific frameworks). Map each relevant characteristic to the compliance obligations it touches. Security and safety usually carry the heaviest regulatory load. Decide upfront which characteristics are negotiable and which are not.

Scalability: The framework should adapt to project size. A two-person mobile MVP doesn't need the same depth of review as an enterprise platform serving regulated workflows. Scaling ISO 25010 means reviewing fewer characteristics in less depth for small projects, and applying the full nine-characteristic lens with formal review cycles for large or critical ones. Treating it as a fixed checklist regardless of project scale produces ceremonial overhead with no benefit.

Institutional trust: Multi-team adoption requires buy-in across product, engineering, QA, and business. If only QA owns ISO 25010, it becomes a testing exercise. The framework delivers value only when product, engineering, and business each own the characteristics most relevant to their work. Distribute ownership across functions, agree on which characteristics matter most for which products, and revisit those decisions as the product evolves.

Conclusion: Is ISO 25010 Suitable for Every Project and Team?

In short: yes, but as a framework, not a fixed checklist.

ISO 25010 is broad enough to be useful across almost any software project, but it is not a one-size-fits-all action plan. Not every quality characteristic matters equally in every context. 

A consumer mobile app, for example, will prioritize usability, portability, and performance efficiency very differently from an internal back-office system used by a small team on a controlled network.

What ISO 25010 provides is a shared framework for deciding which aspects of quality matter most for a specific product and its users.

It is particularly useful early in development, when teams are still defining requirements and making architectural decisions. Involving QA at this stage helps surface risks while they are still relatively inexpensive to address: unclear requirements, fragile user flows, or technical choices that may later undermine reliability, security, or maintainability. 

But ISO 25010 remains useful even when a project is already underway. Many teams already have established testing practices for functionality, browser compatibility, or regression coverage, but that does not make the standard redundant.

Applying ISO 25010 at this stage helps expose blind spots by asking a simple question: Which quality characteristics have we not evaluated properly?

A team may have thoroughly tested UI behavior, for example, while paying little attention to accessibility, resilience under unstable network conditions, or long-term maintainability.

That is the real value of ISO 25010. It does not prescribe how to test software; it helps teams make quality expectations explicit, so trade-offs are intentional rather than accidental.