In an automotive project, having a long list of standards does not necessarily mean understanding the requirements applicable to the product. A standard may address an automotive-related subject but may not apply to the relevant vehicle category; a requirement may only apply when specific equipment is installed; a new standard may have been published while its implementation status in the target market still requires verification; and a component may be subject to additional technical obligations imposed by the vehicle manufacturer or customer beyond legal requirements. For this reason, one of the first important activities in product development, testing, or approval is identifying the Applicable Requirements.
This process should not end with searching a few keywords and collecting standard numbers. For each requirement, it should be possible to determine where it originates, which products fall within its scope, whether the intended configuration is covered, what its implementation status is, which version or amendment applies, and what evidence is required to demonstrate conformity. The outcome of this assessment can be managed through a Requirement Matrix or Regulatory Matrix and subsequently used as an input to the Test Plan, Design Verification program, Type Approval process, and other product evaluation activities.
Why Is Identifying Applicable Standards More Important Than Testing Itself?
Testing is valuable when it is performed to address a specific requirement. If the wrong requirement is selected, even a correctly performed test may generate information that the project does not need. Conversely, if an applicable requirement is not identified at all, the product may reach the final stages of development before the need for a design change, additional documentation, or another test becomes apparent.
For this reason, the logical sequence is not to first ask a laboratory, “What tests do you offer?” and then select suitable tests from its capabilities. The product, target market, configuration, and requirements should be identified first; the appropriate evaluation methods and required tests can then be determined.
This distinction is particularly important in the automotive industry because a vehicle may simultaneously be subject to requirements relating to braking, steering, field of vision, lighting, occupant protection, electrical equipment, emissions, cybersecurity, and many other areas. However, exactly which requirements apply to a particular vehicle must be determined from the scope and conditions specified in the relevant reference documents.
What Is an Applicable Requirement?
An Applicable Requirement is a requirement that is relevant to a particular product and configuration based on the scope and conditions defined in the applicable reference. This concept should not be confused with “every standard related to vehicles.”
For example, a regulation may cover only certain vehicle categories, or a particular requirement may apply only to vehicles equipped with a specified system. Therefore, vehicle category, mass, powertrain type, installed equipment, structural characteristics, and other product specifications may influence applicability, depending on the regulation.
The important point is that these factors cannot automatically be transferred from one regulation to another. The scope of each document must be assessed independently. The fact that vehicle category is a determining factor in one standard does not mean that all standards use exactly the same conditions.
Applicable, Mandatory, and Effective Do Not Mean the Same Thing
These three concepts must be distinguished. Applicability determines whether a requirement is relevant to a product based on its technical scope and conditions. Mandatory status concerns whether compliance is legally or contractually required, while the Effective Date determines when and under what conditions the requirement must be met.
Therefore, a standard may be relevant to a product in terms of subject matter and scope, while its mandatory status requires separate assessment. Similarly, a requirement may have a defined implementation schedule, and its status may differ across dates, product categories, or approval stages.
This distinction helps prevent incorrect decisions. Statements such as “this standard concerns vehicles, so it must be mandatory” or “it appears in the new list, so it applies to all vehicles immediately” are not sufficient grounds for decision-making without reviewing official sources.
For further information about the legal status of standards, see the article “What Is the Difference Between Mandatory and Voluntary Standards?”.
Step One: Define the Product Precisely
Before searching for standards, it is necessary to understand exactly what product will be evaluated. Expressions such as “passenger car,” “seat,” “lamp,” or “electronic control unit” do not always provide sufficient information for an accurate regulatory assessment.
At the vehicle level, the vehicle category and relevant technical characteristics must be identified. At the component level, it should be clear what function the component performs, which vehicles it is used in, and whether it is independently subject to specific approval or requirements or forms part of a larger system.
Product configuration is also important. Two variants of a vehicle may share the same commercial name, but the presence or absence of a particular system may result in different applicable requirements. Therefore, regulatory analysis should be based on the actual, defined specifications of the product, rather than merely its commercial name.
Step Two: Identify the Target Market and Project Objective
Mandatory standards cannot be determined without knowing the Target Market. Automotive requirements may be structured differently across markets, and the existence of a UN Regulation does not mean that it is implemented identically in every country.
The project objective must also be established. Is the product being developed for the domestic market? Is the objective to obtain Type Approval in another market? Is the component being manufactured for a specific vehicle manufacturer? Or is the project limited to internal product evaluation and Validation?
This distinction is important because regulatory requirements are not the only source of project requirements. A vehicle manufacturer may specify additional technical requirements or proprietary specifications that, even if they are not general legal obligations, are binding on the supplier under the relevant project contract.
Therefore, before preparing the Requirement Matrix, regulatory requirements and customer or project requirements should be clearly distinguishable.
Step Three: Determine the Vehicle Category or Product Classification
In automotive regulations, product classification can play a fundamental role in determining applicability. Within the UN regulatory framework, categories such as M, N, O, and L are used for different groups of vehicles, and many regulations specify which categories they cover in their scope.
However, knowing that a vehicle belongs to a particular category is not sufficient to determine all applicable requirements. A regulation may impose additional conditions beyond vehicle category. Therefore, vehicle category should be treated as one input to the scope analysis, not its final conclusion.
For components, regulation-specific classifications or definitions may also be important. When reviewing a regulation, examining its Scope and Definitions sections helps determine how the product is identified and classified within that document.
Step Four: Identify Authoritative Regulatory Sources
The Requirement Matrix should be developed using authoritative and traceable sources. Old project files, spreadsheets from previous products, or unofficial online lists may be useful starting points, but they should not be used as the basis for regulatory decisions without checking the original sources.
For UN Regulations, the official regulatory texts and amendments published within the UNECE WP.29 framework are important. For national requirements, the relevant official documents and authorities should be consulted, and implementation status should be verified using reliable information.
In Iran's automotive industry, the Table of 122 Vehicle Standards on the TAT website provides structured access to standard titles, related standard numbers, and information about their implementation status. This table can serve as a useful starting point for identifying requirements, but for significant technical and regulatory decisions, the latest relevant official documents and notifications should be the final reference.
Step Five: Review the Scope of the Standard
One of the most important steps in identifying requirements is reviewing the Scope. The title of a standard or regulation does not always provide sufficient information about its actual field of application.
A regulation may address a particular system, while its scope covers only certain vehicle categories or configurations. Some requirements within the document may also apply only under specific conditions.
Therefore, before studying the details of the test method, it is necessary to establish whether the regulation covers the product in question at all. Fully reviewing the test method of a document that falls outside the product's scope may consume project time and resources without providing technical value.
An effective regulatory review generally examines Scope, Definitions, Requirements, Transitional Provisions, and Test Procedures, although the exact order and structure may differ between documents.
Step Six: Pay Close Attention to Definitions
Terms that appear simple in everyday conversation may have specific technical definitions within a regulation. Concepts such as vehicle type, seat type, system, component, and product variant can be important in determining applicability.
If the definitions in the document are overlooked, the project team may classify the product according to its general understanding and consequently select incorrect requirements.
This is particularly important in UN Regulations because Type Approval generally relates to a defined product Type, and the regulation determines which characteristics are relevant to defining that Type for the purposes of the approval.
Step Seven: Extract the Conditions That Determine Applicability
After reviewing the scope and definitions, the conditions that determine whether each requirement applies to the product must be extracted. These conditions may depend on vehicle category, configuration, installed equipment, or other characteristics defined in the regulation.
This analysis should not remain solely in an engineer's memory. For each requirement, the matrix can include a column titled “Applicability Status and Basis” to record why the requirement is considered applicable or not applicable.
For example, instead of simply entering N/A or “Not Applicable,” it is advisable in critical projects to record the relevant reference clause and justification. This becomes important during design changes or audits; if the product configuration changes, the team can identify which previous applicability decisions need to be reviewed.
Step Eight: Identify the Applicable Version and Amendments
Knowing the regulation number is not enough. UN Regulations are amended over time and may have different Series of Amendments, Supplements, and Revisions. Technical requirements and transitional provisions may also change.
Therefore, statements such as “the product complies with R17” may provide insufficient information in a technical project unless the exact basis of evaluation is identified. It must be clear which version, amendment series, or set of regulatory provisions applies to the intended assessment or approval process.
This becomes even more important in multi-year projects. Requirements may have one status when initial design begins and may change before Type Approval or the Start of Production (SOP). Regulatory developments should therefore be monitored throughout the project.
If you are unfamiliar with the structure of UN Regulations, the article “What Is UNECE? The Relationship Between UN Regulations and Vehicle Standards in Iran” in the TAT Knowledge Base explains the overall structure of these regulations.
Step Nine: Review Transitional Provisions
In UN Regulations, Transitional Provisions can be particularly important in determining how new amendment series are introduced into the Type Approval process. These provisions may establish dates and conditions affecting the issuance of new approvals, acceptance of previous approvals, or their continued validity and recognition within the relevant framework.
For this reason, the publication date of an amendment alone cannot be used to conclude that all products must be evaluated against it from that date. The timing and conditions of implementation must be assessed according to the regulatory text and its applicable transitional provisions.
This is one reason regulatory planning should begin early in the project. If a product is intended to enter the market several years later, understanding current requirements alone is not sufficient; known changes that will affect the product at the time of approval or market introduction must also be considered.
Step Ten: Review National Implementation Status Separately
The existence of a UN Regulation and the inclusion of a product within its technical scope do not mean that it automatically applies in every country. The target market determines which regulatory requirements and procedures it has adopted or made mandatory.
In Iran, the status of standards and their implementation schedules should also be reviewed using the relevant sources. For structured information, the Table of 122 Vehicle Standards can be consulted, while the latest relevant official documents should be used as the basis for project decisions.
This distinction is fundamental: falling within the technical scope of a regulation and being legally required to comply with it in the target market are two related but separate matters.
How Are Iranian National Standards Related to UN Regulations?
In some areas, an Iranian national standard may be developed based on or related to a UN Regulation. In such cases, understanding the international regulation can help explain the origin of the technical requirements. However, the national standard and the UN Regulation should not be treated as identical documents without detailed review.
The referenced version, amendments, scope, and implementation status of the national standard must be examined separately. If a national standard refers to a particular version of a regulation, subsequent changes to the international regulation do not necessarily modify the national standard automatically, unless the applicable legal mechanism or reference provides for that effect.
Therefore, the Requirement Matrix should record the exact reference document that forms the actual basis of the project requirement.
What Is a Requirement Matrix?
A Requirement Matrix is a structured tool for collecting and managing product requirements. In regulatory projects, the terms Regulatory Matrix or Compliance Matrix may also be used. Its purpose is to move requirements beyond a scattered list and connect them with the information needed for assessment, decision-making, and conformity tracking.
A simple structure may include the following information:
| Reference | Requirement / Subject | Applicability | Basis | Implementation Status | Verification Method | Evidence |
|---|---|---|---|---|---|---|
| Regulation or standard | Requirement under consideration | Applicable / Not Applicable | Scope and conditions | Project-specific status | Test / Analysis / Inspection | Report / Approval |
This table is only a conceptual example, and the actual structure should be designed according to the organization's processes. In more complex projects, additional information such as document version, responsible owner, vehicle variant, approval status, change history, and other relevant details may be included.
The most important characteristic of the matrix is decision traceability. If a requirement is considered applicable, the basis for that decision should be documented; if it is considered not applicable, the justification should also be retrievable.
Does Every Applicable Requirement Need a Test?
No. The applicability of a requirement and the method used to demonstrate conformity with it are two different questions. Once a requirement has been identified as applicable to the product, the next step is to determine which method or evidence the relevant reference specifies for demonstrating conformity.
Some requirements are evaluated through testing, while others may require inspection, measurement, documentation review, or other defined methods. In product development projects, engineering analysis may also be an appropriate Verification method for certain design requirements.
Therefore, a Requirement Matrix should not automatically become a list of tests. First, the requirement and its conditions are identified; then the appropriate evaluation method is determined.
To review the tests and standards available at TAT, you can use the Table of Available Tests.
What Is the Difference Between a Regulatory Matrix and a Test Plan?
A Regulatory Matrix identifies which requirements apply to the product, why they apply, and the status of their assessment or conformity. A Test Plan, by contrast, focuses on testing activities and specifies how a test will be performed, on which specimen, against which acceptance criteria, and at what time.
These two tools should be connected. If a Test Plan includes an activity that has no corresponding requirement or engineering objective in the matrix, the reason should be examined. Similarly, if a requirement needs testing but no corresponding activity has been defined in the plan, some of the evidence required for Verification or conformity assessment may be missing.
This connection helps transform testing from an isolated laboratory activity into an integrated part of conformity management and product development.
How Is a Regulatory Matrix Related to DVP&R?
The DVP&R, or Design Verification Plan and Report, also relies on requirements traceability, but its focus is on planning Design Verification activities and recording their results. A Regulatory Matrix can serve as one of the sources of requirements feeding into the DVP&R.
For example, an applicable regulatory requirement may be incorporated into the product requirements, after which the Design Verification program defines how it will be verified. Customer requirements and internal engineering requirements may also be managed within the same process.
This structure helps ensure that regulatory compliance is not separated from product development. Legal requirements should be integrated into the engineering process from the early design stages rather than added to the product at the end of the project.
When Does Type Approval Enter This Process?
If the project objective is to obtain Type Approval, identifying applicable regulations is one of the foundations of the Homologation program. It is necessary to determine which approvals are required for the relevant vehicle Type, system, or component and what evidence must be provided to the competent authority.
Type Approval is not simply a collection of tests. Product configuration, technical documentation, the Type Approval Authority, designated Technical Services, and Conformity of Production requirements may also be important, depending on the applicable regulatory framework.
The article “What Is the Difference Between Type Approval and Homologation?” explains this process and the distinction between performing a test and issuing an approval.
Should Customer Standards Also Be Included in the Matrix?
If customer requirements are binding on the project, yes. However, their source should be distinguishable from regulatory requirements. A vehicle manufacturer may impose requirements beyond the minimum legal obligations, and a supplier may be required to comply with them under a contract or technical specification.
Combining these two sources without distinguishing them can create problems later. If a legal requirement changes, the affected items must be identifiable; similarly, if a new revision of a customer's technical specification is issued, its impact should be assessed separately.
Therefore, including a “Requirement Source” column in the matrix can be particularly useful.
How Do Configuration Changes Affect Applicable Standards?
Applicability is not determined once and for all. If the product configuration changes, some previous decisions may need to be reviewed.
Adding a new function, changing the vehicle category, modifying the powertrain architecture, or installing new equipment may affect applicable requirements depending on the regulation. Therefore, the change management process should also assess the potential regulatory impact of each change.
This is another reason to document the basis for applicability decisions. If the reason a requirement was considered applicable or not applicable is known, it becomes easier to determine whether that reasoning remains valid after a product change.
What Are the Common Mistakes in Identifying Applicable Standards?
One common mistake is copying the requirements list from a previous product without reviewing configuration differences. A new product may look similar, but a new function may trigger an additional requirement, or a changed characteristic may affect applicability.
Another mistake is relying on the title of a standard without reviewing its scope. The title may indicate the general subject of the document but does not define all the conditions of application. Using an outdated standard version, overlooking transitional provisions, and mixing customer requirements with legal requirements can also lead to errors.
It should also not be assumed that “if a laboratory performs a test, that test must be required for my product.” A laboratory provides its testing capabilities and services; project needs must be derived from the product's actual requirements.
When Should Applicable Standards Be Reviewed?
The earlier, the better. Regulatory requirements can affect product architecture, component packaging, component selection, software, and even supplier selection strategy. Identifying a new requirement after the design has been frozen may lead to costly modifications.
The initial review should preferably begin during the concept and requirements-definition stages and become more detailed as the product matures. Regulatory changes should also be monitored throughout the project to identify amendments to standards, regulations, and their implementation schedules.
Specific reviews before DV/PV, Type Approval, and the Start of Production (SOP) can also help ensure that the Requirement Matrix remains up to date and reflects the actual product configuration.
Who Should Determine Applicable Requirements?
This activity generally requires cooperation across several disciplines. The regulatory or Homologation team monitors regulations and market requirements; the engineering team understands product configuration and functionality; test engineers provide knowledge of evaluation methods; and suppliers may be responsible for reviewing requirements related to their own components.
In smaller projects, these responsibilities may be combined among fewer individuals, but the underlying principle remains the same: applicability decisions must be based on an understanding of both the regulation and the product. Reviewing a regulation without understanding the configuration is insufficient, and knowing the vehicle without examining the document's scope does not provide a reliable conclusion either.
For projects where applicable standards or test programs require review, TAT Engineering and Consulting Services can support technical requirements assessment and test planning activities.
A Simple Checklist for Starting a Regulatory Review
Before finalizing the matrix, the team should at least be able to answer the following questions: What exactly is the product, and what is its configuration? What is the target market? What is the vehicle category or component classification? Which regulatory sources are authoritative? What do the scope and definitions of each document specify? Which conditions make requirements applicable or not applicable? Which version applies? What is the implementation status? And what evidence or evaluation method will be required to demonstrate conformity?
If any of these questions remain unanswered, the requirement's status should not be treated as final. Recording the status as “To Be Determined (TBD)” during the assessment stage is far better than documenting a decision without a clear technical or regulatory basis.
An effective Requirement Matrix is not intended to hide project uncertainties; it should make them visible, traceable, and manageable.
A List of Standards Is the Starting Point, Not the Final Result
Identifying applicable standards does not mean collecting as many standards as possible. The objective is to understand which requirements must actually be managed for a specific product, a specific configuration, a specific market, and a specific point in time.
To achieve this, the process should begin with understanding the product, determining its classification, identifying official sources, reviewing scope and definitions, extracting applicability conditions, identifying the relevant version and transitional provisions, and then incorporating the implementation status in the target market. Only after these steps can each requirement be incorporated into the Verification Plan, Test Plan, or product approval process.
Therefore, when faced with a long list of standards, the appropriate question is not “Which ones should we test?” Instead, it is: “Which of these actually apply to my product configuration, why do they apply, and under which reference and version must I demonstrate conformity?” A documented answer to this question forms the foundation of a reliable Regulatory Matrix and a targeted Test Plan.