CISQ (Consortium for Information & Software Quality): CISQ – Tutorial (about 60 minutes)

CISQ, the Consortium for Information & Software Quality, is an industry group that writes standards for measuring software automatically from its source code: how big it is, and how well it is built inside. Its best-known result is ISO/IEC 5055, which counts serious coding and architecture weaknesses that hurt security, reliability, performance efficiency and maintainability. Engineering leaders, architects, developers, quality and security staff, and buyers of outsourced software use CISQ measures to set targets, compare systems and write acceptance criteria into contracts. After this tutorial you will be able to explain what CISQ produces, read and use ISO/IEC 5055 results with care, size software with Automated Function Points, estimate technical debt with the CISQ method, and place all of this beside related standards.

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

Course overview

Edition and status: CISQ is not a single document but a consortium that produces several specifications, so "edition" means the current version of each. CISQ was co-founded in 2010 by the Object Management Group (OMG) and the Software Engineering Institute (SEI) at Carnegie Mellon University and has operated as an OMG-managed group. In October 2025 the EDM Association completed its acquisition of OMG's assets, and CISQ was named among the communities that moved with OMG. The central quality standard is ISO/IEC 5055:2021, first edition, published 30 March 2021 by ISO/IEC JTC 1 and adopted from the OMG specification Automated Source Code Quality Measures (ASCQM; OMG version 1.0 in 2020, 1.1 in 2022). It is still the published edition (no later edition or amendment is listed in the IEC catalogue as of the verification date). CISQ's newer data protection and resource sustainability measures are being developed as further parts of the standard (planned as ISO/IEC 5055-2 and 5055-3); drafts are not yet standards, so this course teaches the 2021 edition. The sizing standard Automated Function Points (OMG AFP 1.0, December 2013) was published by ISO/IEC as ISO/IEC 19515:2019. Automated Enhancement Points (OMG AEP 1.0, 2017) and the Automated Technical Debt Measure (OMG ATDM 1.0, December 2017) are OMG specifications. Verified 2026-10-29 against the CISQ website, the OMG specification catalogue and the IEC catalogue entry for ISO/IEC 5055:2021.

A note on copyright: this tutorial explains the CISQ specifications in its own words. It does not reproduce their weakness lists, detection patterns or formulas. For contract or audit use, obtain the official texts from OMG, ISO, IEC or your national standards body.

Who it is for: software engineers and architects, development and QA leads, application security staff, IT and portfolio managers, vendor and procurement managers, and auditors who need an objective view of code quality. No earlier knowledge of CISQ or ISO standards is assumed.

Prerequisites: none. A general idea of how software is written, built and released will help you follow the examples.

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

Explain why CISQ was created, who stands behind it and which problems its standards address.
Distinguish structural quality from functional quality and explain why it needs to be measured from source code.
Describe the structure of ISO/IEC 5055: four measures, CWE-based weaknesses, detection patterns, base and derived measures.
Explain the purpose of Automated Function Points, Automated Enhancement Points and the Automated Technical Debt Measure.
Plan and run a CISQ-based measurement programme, including thresholds, tools, baselines and reporting.
Judge what a CISQ measurement result does and does not prove, and use it fairly in supplier contracts.
Relate CISQ standards to ISO/IEC 25010, ISO/IEC 25023, MITRE CWE, IFPUG function points and secure coding standards.

Lesson 1 – Origins, purpose and scope

The problem CISQ set out to solve

Most software testing checks behaviour: does the application do what the requirements say, and does it do it quickly enough on the test environment? That kind of testing is essential, but it misses a whole class of problems. An application can pass every functional test and still contain a SQL query built by gluing user input into a string, a database connection that is never released, a loop that calls a remote service thousands of times, or a tangle of modules that nobody dares to change. None of these show up as a failed test case on day one. They show up later as a security breach, a production outage at the end of the month, a cloud bill that keeps rising, or a simple change that takes six weeks.

These problems live in the internal structure of the code: how it is written and how its parts are put together. CISQ calls the property being harmed structural quality. Before CISQ, many organisations already used static analysis tools to look for such problems, but every tool counted different things, used different severity scales and produced scores that could not be compared. Outsourcing contracts often promised "good code quality" without any agreed way to check it. Two suppliers could each claim a quality score of "A" and mean entirely different things.

CISQ was founded to give the industry a common, automatable yardstick. The idea is simple: agree, as an industry, on a list of severe weaknesses that should never be in production code, define precisely how to recognise them in source code, and define how to count them. Once the definitions are shared, different tools can produce comparable results, and buyers and suppliers can write measurable targets into agreements.

Who is behind it

CISQ was co-founded in 2010 by two well-known bodies. The Object Management Group (OMG) is a not-for-profit standards consortium known for UML, BPMN and many other specifications. The Software Engineering Institute (SEI) at Carnegie Mellon University is known for its work on software process maturity and secure coding. CISQ ran as a special interest group managed by OMG, with sponsors from industry, including static analysis vendors, and with participation from large software users, system integrators and government agencies. Its long-time executive director, Dr. Bill Curtis, was one of the authors of the original Capability Maturity Model, which helps explain CISQ's focus on measurement as a basis for improvement.

In October 2025 the EDM Association, a data management industry association, completed the acquisition of OMG's assets, and its announcement listed CISQ among the OMG communities that are now part of the combined organisation. For a learner this change of ownership matters little: the published specifications keep their content, and the ISO/IEC versions are owned by ISO and IEC anyway. It is still worth checking the CISQ and OMG pages for the current home of each specification.

What CISQ produces

CISQ's output falls into three groups, which the rest of this course explores:

Structural quality measures – the four automated measures of security, reliability, performance efficiency and maintainability, first adopted by OMG as separate specifications (the security measure, for example, in December 2015), then combined into ASCQM and published by ISO and IEC as ISO/IEC 5055:2021.
Sizing measures – Automated Function Points (AFP), which became ISO/IEC 19515, and Automated Enhancement Points (AEP), which size both functional and non-functional code.
Technical debt measure – the Automated Technical Debt Measure (ATDM), which estimates the effort needed to fix the CISQ weaknesses left in the code.

CISQ has also worked on newer topics, such as a data protection measure, a resource sustainability measure and a joint working group on exchanging software bills of materials between tools. It also publishes research. The most quoted is a series of reports on the cost of poor software quality in the United States; the 2022 edition, written by Herb Krasner, estimated that cost at about 2.41 trillion US dollars. Treat such figures as broad estimates that show the size of the problem, not as precise accounting.

Scope: what CISQ measures and what it does not

CISQ standards measure the software product, specifically its source code and related artefacts such as database schemas and configuration. They do not assess development processes, organisational maturity or management systems. They do not replace functional testing, user acceptance, penetration testing or architecture review. They also do not tell you how good your requirements are. They answer two narrow but valuable questions: "How big is this software?" and "How many severe structural weaknesses does it contain, in which quality areas?" Keeping that scope in mind prevents the most common misuse of CISQ results, which is treating a clean scan as proof that the software is secure or fit for purpose.

Lesson 2 – Key concepts and vocabulary

CISQ uses a small vocabulary very precisely. Learn these terms first; the rest of the course builds on them.

Structural quality – how well the software is built internally: the soundness of its code and architecture, judged against good coding and architectural practice. It contrasts with functional quality.
Functional quality – how well the software does what its users and requirements expect. Functional testing measures it; CISQ standards do not.
Weakness – a flaw in code or architecture that can lead to a vulnerability, failure, waste of resources or high maintenance cost. In ISO/IEC 5055 every weakness is a severe violation of good practice that should be removed.
CWE (Common Weakness Enumeration) – the public catalogue of software and hardware weakness types maintained by MITRE. Every ISO/IEC 5055 weakness has a CWE identifier, which gives tools and developers a shared reference.
Quality characteristic – one of the broad quality areas of the ISO/IEC 25010 product quality model, such as security or maintainability. ISO/IEC 5055 provides one measure for each of four characteristics.
Detection pattern – a precise description of the structural elements and relationships in parsed code that reveal a weakness. One weakness can have several detection patterns, because it can appear in different forms.
Knowledge Discovery Metamodel (KDM) – an OMG metamodel, published as ISO/IEC 19506, for representing software structure independently of programming language. CISQ uses it to express detection patterns unambiguously.
Static analysis – examining code without running it. CISQ measures are designed to be computed by static analysis tools.
Base measure – in ISO/IEC 5055, the number of weakness occurrences found for one quality characteristic.
Derived measure – a value calculated from base measures, such as weakness density (occurrences divided by a size measure) or a sigma level (occurrences relative to the number of opportunities checked).
Function point – a unit of functional size based on the data a system maintains and the transactions it offers users, independent of programming language. The IFPUG method is the best-known manual way to count them.
Automated Function Points (AFP) – CISQ's rules for counting function points automatically from source code and database structure, close to the IFPUG method but without counter judgement.
Automated Enhancement Points (AEP) – a CISQ size measure that counts both functional and non-functional code changed in a release, to support productivity analysis for maintenance work.
Technical debt – the future cost created by structural shortcuts left in the code. The principal is the effort to fix them; the interest is the extra cost paid while they remain, such as slower changes or extra computing resources.
Automated Technical Debt Measure (ATDM) – the CISQ method for estimating the principal: the effort to remove the ISO/IEC 5055 weaknesses still in the code at release.
Conformant tool – a static analysis tool whose supplier claims, and ideally demonstrates, that it implements the CISQ detection patterns and counting rules.
False positive – a reported weakness that, on inspection, is not real. False positives inflate counts and must be managed in any measurement programme.

Why "structural" matters so much

Some weaknesses are visible inside a single function or class: an exception that is caught and silently ignored, a method with too many parameters, a variable used before it is set. Others only become visible when a tool follows data and calls across components, layers and technologies. Examples are user input that travels from a web form through several classes into a database query, a user interface layer that bypasses the business layer to call the database directly, or a transaction that is opened in one component and never closed in another. CISQ has long stressed that these cross-component, architectural weaknesses are fewer in number but tend to cause the most serious production incidents and are the most expensive to fix. That is why CISQ measures are meant to be applied to whole applications, not only to single files.

Measurement, not judgement

A recurring idea in CISQ is that a measure should be reproducible. Two people who analyse the same code with tools that implement the standard correctly should get the same counts. That is why the standard defines exactly which weaknesses count and how to detect them, and why it leaves out "matters of taste" such as naming style. The aim is a measure that can stand up in a contract dispute, not a code review opinion.

Lesson 3 – Structure of the CISQ standards

Figure 1 – How CISQ work becomes OMG specifications and, for quality and sizing, ISO/IEC standards.

CISQ follows a consistent path: experts from member organisations draft a specification, OMG adopts it through its own process, and for some specifications OMG then submits the result to ISO/IEC JTC 1, the joint information technology committee of ISO and IEC, which publishes it as an international standard. Figure 1 shows the main specifications and where each one ended up.

ISO/IEC 5055 – the four structural quality measures

ISO/IEC 5055 defines four measures, one for each of four characteristics of the ISO/IEC 25010 product quality model. A team of experts from 24 organisations in North America, Europe and Asia reviewed a long list of candidate weaknesses and kept only those judged severe enough that they should be removed from the code. The resulting counts, as published by CISQ, are shown below.

Measure	Number of weaknesses	Typical examples
Security	73	SQL injection, cross-site scripting, buffer overflow, hard-coded credentials
Reliability	74	Improper synchronisation between threads, improper error handling, null pointer dereference
Performance efficiency	18	Expensive operations inside loops, memory that is never released, inefficient data access
Maintainability	29	Excessive coupling, calls that skip architectural layers, dead code, excessive complexity

The four lists together contain 138 unique weaknesses. The per-measure numbers add up to more than that because some weaknesses belong to two measures. A buffer overflow, for example, can crash a system (reliability) and can also let an attacker take control (security). MITRE has added all of these weaknesses to the CWE catalogue, and CWE offers views that group them: the "CISQ Quality Measures (2020)" view groups the quality weaknesses by characteristic, and a separate view covers CISQ's data protection measures.

How a measure is built

Figure 2 – The layers of an ISO/IEC 5055 measure, from quality characteristic down to counted occurrences.

Figure 2 shows the layered design. At the top is a quality characteristic from ISO/IEC 25010. ISO/IEC 5055 was written to match the 2011 edition of that model, which had eight characteristics; the 2023 edition has nine and renamed some, but security, reliability, performance efficiency and maintainability are still there. The authors used the subcharacteristics of each characteristic to check that the chosen weaknesses cover the whole area, not just one corner of it.

Under each measure sits its list of weaknesses, each tied to a CWE identifier. Under each weakness sit one or more detection patterns, expressed with the Knowledge Discovery Metamodel so that they do not depend on a particular language or tool. A static analysis tool parses the code, builds its own model of the structure, looks for the patterns and records every occurrence.

The base measure for each characteristic is simply the number of weakness occurrences found. Raw counts are hard to compare between a small and a large system, so organisations usually compute derived measures: weakness density, such as occurrences per thousand lines of code or per function point, and sigma levels, which express the rate of weaknesses relative to the opportunities checked, in the style of Six Sigma quality engineering. The standard defines the counts; how you normalise and what targets you set are decisions for the organisation.

Automated Function Points and Automated Enhancement Points

Size measures matter because almost every useful management number needs a denominator: cost per function point, defects per function point, weaknesses per function point. Manual function point counting by certified counters is respected but slow, expensive and somewhat subjective; OMG and CISQ material notes that manual counts by different counters have been shown to differ by ten percent or more. Automated Function Points (OMG AFP 1.0, 2013; ISO/IEC 19515:2019) define counting rules that a tool can apply to source code and database structure. They follow the IFPUG Counting Practices Manual, release 4.3.1, as closely as possible and replace the points where a human counter would use judgement with fixed rules. AFP targets transaction-oriented applications that store data, such as typical business systems. It does not size the non-functional parts of an application, and it does not cover enhancement counting.

Automated Enhancement Points (OMG AEP 1.0) fill that second gap. Modern applications contain a lot of code that delivers no user-visible function, such as logging, security plumbing, integration and infrastructure code, yet changing it still costs effort. AEP counts both functional and non-functional code touched in a release and combines them into one function-point-like size, so that maintenance and enhancement productivity can be analysed fairly.

The Automated Technical Debt Measure

Figure 3 – How the CISQ technical debt measure adds up the adjusted effort to fix each remaining weakness.

The Automated Technical Debt Measure (OMG ATDM 1.0, December 2017) turns ISO/IEC 5055 findings into effort. CISQ surveyed experienced developers to set a default time to fix each weakness type in well-built code. Each occurrence's default effort is then adjusted for factors that make the fix harder, such as the complexity of the component that contains it and how widely that component is used by the rest of the system. The adjusted efforts are added up per weakness, then per characteristic, then across all four characteristics, as Figure 3 shows. The result estimates the principal of the technical debt. The interest, such as slower changes and wasted computing resources, is described conceptually but is not part of the calculation.

Work in progress

Two newer measures were being turned into additional parts of ISO/IEC 5055 at the time of writing: a data protection measure, focused on weaknesses that expose personal or sensitive data, and a resource sustainability measure, focused on code that wastes computing resources and energy. Both were still drafts. Until they are published, treat them as useful guidance, not as requirements.

Lesson 4 – How it works in practice

Knowing the standards is one thing; getting value from them is another. A CISQ measurement programme follows a cycle much like any other quality measurement: decide what you want to learn, measure consistently, act on the results and measure again.

Figure 4 – A practical CISQ measurement cycle: prepare once, then measure and improve every release.

Step 1 – Set goals and scope

Start with the question you want answered. Typical goals are: find the applications in a portfolio that carry the most operational risk; set acceptance criteria for a supplier; track whether a modernisation project is improving or degrading the code; or estimate the budget needed to clean up before a major change. The goal determines which measures you need (all four, or only security and reliability), which applications are in scope, and whether you also need size (AFP or AEP) and debt (ATDM) figures. Define the scope precisely: which repositories, which languages, whether generated code and third-party libraries are included.

Step 2 – Select a tool

CISQ measures are computed by static analysis tools, and tools differ widely in their coverage. Some only analyse one file at a time and therefore cannot find architectural weaknesses that span components. Others build a model of the whole application across languages and layers. Ask suppliers which ISO/IEC 5055 weaknesses they detect for each language you use, how they handle cross-layer analysis, and what independent evidence they have. Ask for evidence of conformance to the standard, and remember that coverage still varies by language and framework, so check against your own technology stack.

Step 3 – Configure and baseline

Run the tool on the current code before setting any targets. This baseline tells you where you stand and prevents arbitrary targets. Record the tool name and version, the configuration, the code version analysed and the size measure used. Without these details, later results cannot be compared with the baseline.

Step 4 – Analyse and triage

Analyse the complete application, not just the changed files, at least for major releases. Then triage the results. Some findings will be false positives; some will sit in code that is about to be deleted; some will be in third-party code you do not control. Agree rules for excluding findings, document every exclusion and keep the original counts. A measure that can be quietly edited loses its value as evidence.

Step 5 – Compute measures

Report the base counts for each characteristic, then the derived measures your goals need: density per thousand lines or per function point, a sigma level, the technical debt estimate, and the size of the release. Show trends over time, not only single numbers. A rising density over three releases tells a clearer story than one figure.

Step 6 – Compare with thresholds and act

Thresholds come in two forms. The first is a zero-tolerance list: weaknesses that must not be present at all, such as injection flaws or hard-coded passwords in internet-facing systems. The second is a target level: a maximum density or a minimum sigma level for each characteristic, or a maximum debt per function point. Fix the most dangerous weaknesses first, usually security and reliability findings in critical paths, rather than chasing the easiest ones to bring the count down.

Step 7 – Re-measure every release

Run the analysis in the build pipeline so developers see new weaknesses within minutes, and run a full application analysis for each release. The goal is a downward trend in severe weaknesses and a debt figure that stays under control as the system grows.

Roles and artefacts

Role	Typical responsibilities	Typical artefacts
CIO, CTO or portfolio owner	Sets goals, funds remediation, uses results for risk and investment decisions	Portfolio risk dashboard, debt estimates
Architect	Interprets architectural weaknesses, defines layer rules, prioritises structural fixes	Architecture rules, remediation plan
Developers	Fix weaknesses, learn to avoid them, review pipeline findings	Pull requests, triage notes
Quality or measurement lead	Runs analyses, maintains tool configuration, owns baselines and exclusion rules	Measurement plan, release reports
Procurement or vendor manager	Writes thresholds into contracts, checks supplier evidence	Statement of work clauses, acceptance reports
Security team	Defines the zero-tolerance list, links findings to threat models	Security acceptance criteria

Using CISQ in contracts

One of the original reasons for CISQ was outsourcing. A buyer can state in a request for proposal or statement of work that delivered code must contain no occurrences of named critical weaknesses, must stay below an agreed density for each characteristic, and must be checked with an agreed tool at each delivery. Because AFP gives an objective size, the same agreement can also define productivity or price per function point. Good contracts name the tool and version, describe the triage process and set up a baseline for inherited code, so the supplier is not penalised for weaknesses it did not create.

Lesson 5 – Assessment, certification and compliance

There is no organisational certificate

Unlike ISO 9001 or ISO/IEC 27001, the CISQ standards are not management system standards, and there is no accredited scheme that certifies an organisation as "ISO/IEC 5055 certified". The standards define how to measure software. What you can claim is a measurement result: "Release 4.2 of the claims system was analysed with tool X version Y on date Z, and contained these counts for the four ISO/IEC 5055 measures." Be wary of anyone offering a company-level certificate in CISQ.

What is assessed, and by whom

The object of assessment is a specific version of a specific software product. Assessments are done in three ways:

Self-assessment – the development team runs a tool in its own pipeline. This is the cheapest and most frequent form and is the basis for continuous improvement.
Second-party assessment – the buyer analyses code delivered by a supplier, or requires the supplier to provide the tool output, as part of acceptance.
Independent third-party analysis – an outside specialist analyses the code, for example before an acquisition, during a dispute or before a large modernisation investment.

Tool conformance

Conformance in CISQ is first a property of the tool: does it detect the weaknesses as specified and count them as the standard says? Tool suppliers state which weaknesses and languages they cover. Ask suppliers for evidence of conformance, and test a tool yourself by running it on code samples that contain known weaknesses. Remember that no tool covers every language and framework equally, so two conformant tools can still report different counts on the same code.

People

Measures only help if developers know how to avoid the weaknesses in the first place. CISQ and OMG have described a knowledge certification for individual developers on the weaknesses behind ISO/IEC 5055; CISQ's ISO 5055 page refers to it as becoming a certified "Dependable Developer". Such a certificate is about a person's knowledge, not about the quality of any particular product. Check the current CISQ or OMG pages for availability before relying on it.

Reading a result fairly

A CISQ measurement result is strong evidence about one thing: the presence of specific, severe structural weaknesses that a tool can find. It is not evidence that the software is free of other defects. Logic errors, missing requirements, insecure configuration, weaknesses in third-party components and problems in runtime infrastructure are mostly outside its reach. When you report, always state:

the product, version and scope analysed, including what was excluded and why;
the tool, version and configuration;
the base counts per characteristic, before and after triage;
the size measure used for any density, and how it was obtained;
the trend against the baseline and any thresholds in force.

Compliance and regulation

No general law requires ISO/IEC 5055 by name. It is used voluntarily and through contracts. However, CISQ has positioned the standard as a way to provide objective evidence for secure software development expectations, for example when organisations respond to government guidance on software supply chain security, and as input to software bills of materials or supplier reports that show which known weaknesses remain unfixed. In such settings, CISQ measures support compliance claims; they do not prove compliance on their own.

Lesson 6 – Worked example

Harbourline Insurance (a fictional company) runs a twelve-year-old claims processing system written in Java with a large relational database. It has decided to outsource a two-year modernisation programme to a system integrator. The board has two concerns: past outsourcing projects delivered code that worked in testing but caused outages in production, and nobody can say how much the existing system's problems will cost to fix. The IT director decides to use CISQ standards to make quality and size measurable. All figures below are invented for teaching.

1. Goals and scope

The measurement lead writes a one-page measurement plan with three goals: know the current structural quality of the claims system; set objective acceptance criteria for the supplier; and estimate the effort needed to remove inherited weaknesses. In scope are the Java services, the web front end and the database schema and stored procedures. Generated code and third-party libraries are excluded from the counts, but library versions are listed separately for vulnerability management.

2. Tool selection

Harbourline shortlists two static analysis tools. It asks each supplier which ISO/IEC 5055 weaknesses they detect for Java, JavaScript and SQL, and whether they analyse calls across layers into the database. It then runs both on a test application seeded with known weaknesses. One tool finds most single-file problems but misses a seeded injection that flows from a web form through three classes into a stored procedure. Harbourline chooses the other tool, because cross-layer weaknesses are exactly the ones that caused its past outages.

3. Baseline

The first full analysis gives the baseline. The system measures about 9,000 Automated Function Points. The tool reports, after triage, 41 security, 96 reliability, 22 performance efficiency and 310 maintainability occurrences. The ATDM estimate for fixing them all is about 1,900 hours. The architects look closer and find that many reliability findings are empty exception handlers in the payment module, and that the maintainability findings cluster in two huge classes that every change touches.

4. Writing the contract

Procurement and the security team draft the acceptance criteria:

No new occurrences of a short zero-tolerance list of security weaknesses, including injection, cross-site scripting and hard-coded credentials, in any delivery.
For each characteristic, the density of weaknesses per function point in delivered code must not exceed the baseline density, and must fall by an agreed percentage by the end of year one.
The technical debt estimate per function point must not increase from one release to the next.
Productivity is reported as Automated Enhancement Points delivered per month, so that work on non-functional code such as logging and integration is counted fairly.
Both parties use the same tool, version and configuration; disputed findings go to a joint triage meeting, and exclusions are recorded in a shared log.

The supplier agrees, and asks that the 41 inherited security weaknesses be fixed under a separate, funded work package rather than counted against its first delivery. Harbourline accepts: separating inherited debt from new debt is fair and keeps the measures honest.

5. Running the programme

The supplier adds the analysis to its build pipeline, so developers see new findings on every merge request. Harbourline runs its own full analysis on each delivery. In the third delivery the security count drops to 4, but the performance efficiency count jumps. Investigation shows that a new reporting feature calls the database inside a loop for every claim line. Because the contract measures every characteristic, this is caught at acceptance instead of during the next month-end batch run.

6. Using the debt figure

The debt estimate helps the IT director plan. The two huge classes account for a large share of the maintainability debt, and they are also where most change requests land. The board funds a targeted refactoring of those classes first, because that is where the interest, in the form of slow changes, is highest. Low-risk debt in rarely changed modules is accepted and monitored.

7. Reporting

Each quarter the measurement lead presents a one-page report: counts and densities for each characteristic, the trend since the baseline, the debt figure, AEP delivered, and a list of exclusions with reasons. The report states clearly what the measures cover and what they do not. Functional defects, user satisfaction and penetration test results are reported separately, so nobody mistakes a clean structural scan for overall quality.

What the example shows

Harbourline used all three parts of the CISQ portfolio together: ISO/IEC 5055 for structural quality, AFP and AEP for size, and ATDM for debt. It built a baseline before setting targets, separated inherited debt from new debt, chose a tool based on evidence and kept the measurement process transparent. Those choices, more than the numbers themselves, are what made the programme credible to both sides.

Lesson 7 – Relationship to other standards and frameworks

CISQ standards are deliberately narrow, so they are almost always used alongside other standards. The table below shows the main neighbours and how they relate.

Standard or framework	Owner	What it covers	Relationship to CISQ
ISO/IEC 25010	ISO/IEC JTC 1/SC 7	Product quality model: characteristics and subcharacteristics of software quality	Provides the four characteristics that ISO/IEC 5055 measures; CISQ adds source-code-level measures for them
ISO/IEC 25023	ISO/IEC JTC 1/SC 7	Measures of system and software product quality	Its measures mostly look at external behaviour; ISO/IEC 5055 complements it with measures of internal structure
MITRE CWE and CWE Top 25	MITRE	Catalogue of weakness types and a yearly list of the most dangerous ones	Every ISO/IEC 5055 weakness has a CWE identifier; CWE is the shared vocabulary, ISO/IEC 5055 selects and counts
IFPUG function points (ISO/IEC 20926)	IFPUG	Manual functional size measurement	AFP automates counting in a way that follows the IFPUG manual as closely as possible
ISO/IEC 19506 (KDM)	OMG, ISO/IEC JTC 1	Language-independent model of software structure	Used to express ISO/IEC 5055 detection patterns precisely
Secure coding standards (SEI CERT, MISRA)	SEI, MISRA	Language-specific rules for writing safe and secure code	Rules that developers follow; many violations map to CWE weaknesses that CISQ counts
OWASP Top 10 and ASVS	OWASP	Awareness list and verification requirements for web application security	Overlap in injection and similar flaws; OWASP covers design and configuration too, CISQ measures code
NIST SSDF (SP 800-218)	NIST	Practices for a secure software development process	Process framework; CISQ measures can supply evidence that code review and analysis practices work

How to think about the relationships

A useful mental model is three layers. At the top, quality models such as ISO/IEC 25010 define what quality means. In the middle, catalogues and coding rules such as CWE, SEI CERT and MISRA describe specific flaws and how to avoid them. At the bottom, measures such as ISO/IEC 5055, AFP and ATDM turn the presence of flaws and the size of the code into numbers you can track and compare. Process frameworks such as the NIST SSDF or a CMMI-based improvement programme sit beside these layers and describe how an organisation should work; CISQ measures help show whether that work is producing well-built code.

Choosing between overlapping options

If your goal is to teach developers what not to do, coding standards and the CWE Top 25 are a natural start. If your goal is to compare applications or suppliers objectively, you need a defined measure with fixed counting rules, which is what ISO/IEC 5055 adds. If you need to size work for estimating or contracting, choose between manual IFPUG counting, which captures user requirements well, and AFP, which is fast, repeatable and based on the code that actually exists. Many organisations use both: IFPUG for early estimates from requirements, AFP for measuring what was delivered.

Common pitfalls and best practices

Pitfalls

Treating a clean scan as proof of security. ISO/IEC 5055 counts selected severe structural weaknesses. It says nothing about missing requirements, logic errors, runtime configuration or third-party component vulnerabilities.
Comparing raw counts between systems of different size. A large system will usually have more occurrences. Use density or sigma levels with a stated size measure.
Changing tools or settings between measurements. Different tools and configurations find different occurrences; a sudden drop may reflect the tool, not the code.
Gaming the numbers. Teams can lower counts by fixing many trivial findings or by excluding code without justification, while the most dangerous weaknesses remain.
Setting targets before a baseline. Arbitrary thresholds are either unreachable, which demotivates, or too loose, which achieves nothing.
Analysing only changed files. Architectural weaknesses span components and only appear in a whole-application analysis.
Blaming suppliers for inherited debt. Contracts that make a new supplier responsible for old weaknesses create disputes and hidden workarounds.

Best practices

Start from goals. Decide which decisions the measures will support before choosing what to measure.
Baseline first, then set targets, and express targets as trends or densities, plus a short zero-tolerance list for the most dangerous weaknesses.
Choose tools by evidence, testing them on your own languages and on code with known weaknesses, and fix the tool version for comparisons.
Make triage transparent. Keep original counts, record every exclusion with a reason and review exclusions regularly.
Prioritise by risk: security and reliability weaknesses in critical, frequently used components before cosmetic maintainability findings.
Combine measures: structural quality with size and debt, and CISQ measures with functional testing, penetration testing and operational data.
Build it into the pipeline so developers see new weaknesses early, and train them on the weaknesses that recur most.

Summary and key takeaways

CISQ is an industry consortium, co-founded in 2010 by OMG and the SEI, that defines automated measures of software size, structural quality and technical debt.
Structural quality is about how software is built internally; it causes many serious incidents and costs that functional testing does not reveal.
ISO/IEC 5055:2021 defines four measures (security, reliability, performance efficiency, maintainability) built from 138 unique severe weaknesses, all with CWE identifiers.
Each measure counts occurrences of weaknesses found through precisely defined detection patterns; density and sigma levels are derived from these counts.
Automated Function Points (ISO/IEC 19515) size software automatically in line with IFPUG; Automated Enhancement Points add non-functional code for maintenance productivity.
The Automated Technical Debt Measure estimates the effort to fix remaining weaknesses, adjusted for complexity and exposure.
There is no organisational certification; results describe a specific product version measured with a specific tool and must be reported with that context.
CISQ measures work best with a baseline, transparent triage, risk-based priorities and other quality evidence alongside them.

Reflection questions

Think of an application you know well. Which kinds of structural weakness would you expect to find in it, and which of the four ISO/IEC 5055 measures would they affect?
Your organisation wants to compare the code quality of three suppliers. What would you need to fix in advance so that the comparison is fair?
How would you explain to a business sponsor the difference between a low weakness count and a secure application?
If you had to write a zero-tolerance list for an internet-facing system, which weakness types would you put on it and why?
Where would technical debt figures change a decision in your own work, such as release planning, budgeting or choosing between rewriting and refactoring?