NABL Software and IT System Testing Laboratory Accreditation 2026: AI, Cybersecurity, VAPT and ISO 17025
NABL Software and IT System Testing Laboratory Accreditation 2026: AI, Cybersecurity, VAPT and ISO 17025
Updated: 13 September 2026
Software testing is increasingly becoming a conformity-assessment problem.
A modern software product may control a medical device, process financial transactions, communicate with industrial equipment, operate an IoT network or make decisions using artificial intelligence.
In those situations, a test result can affect safety, security, regulatory compliance or market acceptance.
That raises a question familiar to physical measurement laboratories:
How can a customer know that the testing laboratory itself is technically competent?
NABL 137 addresses that question for Software and IT System Testing Laboratories.
What changed in NABL 137 in 2026?
NABL announced on 29 April 2026 that it had released an amended version of NABL 137 .
The current document register lists:
- Document: NABL 137
- Title: Specific Criteria for Accreditation of Software & IT System Testing Laboratories
- Issue: 01
- Original issue date: 14 October 2019
- Amendment: 02
- Amendment date: 28 April 2026
The 2026 version substantially broadens the relevance of the criteria to current digital technologies.
Which technologies does NABL 137 now cover?
NABL 137 states that software and IT systems may include, but are not limited to:
- telecom software and protocols;
- embedded systems;
- mobile devices and mobile applications;
- e-governance applications;
- data analytics software;
- medical software and Software as a Medical Device;
- artificial intelligence and machine learning systems;
- large language models, including edge-AI deployments;
- blockchain-enabled systems;
- cryptographic security systems;
- cyber-physical systems;
- e-procurement software;
- process and control software;
- web applications and websites.
This makes NABL 137 highly relevant beyond traditional software QA companies.
Which testing parameters can fall under the criteria?
NABL 137 identifies areas including:
- functionality;
- performance and efficiency;
- usability;
- accessibility;
- application security;
- network security;
- endpoint security;
- information security;
- cloud security;
- reliability;
- interoperability;
- maintainability;
- portability;
- code review;
- conformance testing.
A laboratory should still apply only for the parameters for which it can demonstrate genuine competence.
Does ISO/IEC 17025 apply to software testing?
Yes.
NABL 137 explicitly states that its supplementary criteria are based on ISO/IEC 17025:2017 and are to be used together with that standard.
This is an important distinction.
ISO/IEC 17025 is often associated with physical testing and calibration, but its competence framework can also be applied to laboratories performing controlled software and IT-system testing.
The laboratory still needs to demonstrate:
- competent personnel;
- suitable methods;
- controlled equipment and tools;
- appropriate facilities and environmental controls;
- validated or verified methods where required;
- controlled data;
- valid results;
- technically valid reporting.
Why software test tools are treated like equipment
NABL 137 treats software test tools, their hosting platforms, associated plug-ins, add-ons and devices required for testing as equipment.
This creates a strong parallel with conventional laboratory metrology.
In a physical laboratory, changing an instrument can affect the result.
In a software laboratory, changing the:
- test-tool version;
- plug-in;
- patch level;
- operating system;
- browser;
- cloud environment;
- configuration;
- automated test suite;
can also affect the result.
Configuration management becomes a laboratory-quality issue
NABL 137 requires software testing tools and associated systems to be controlled through configuration management.
The laboratory should know which configuration produced a test result.
A useful configuration record can include:
- tool name;
- version;
- patch level;
- license details where applicable;
- plug-ins and dependencies;
- operating system;
- browser or runtime version;
- user roles and permissions;
- network configuration;
- test-data version;
- automated test-suite version.
Without this information, repeating the same test may not reproduce the same conditions.
Open-source tools can be used, but control still matters
NABL 137 specifically addresses situations where laboratories use equipment outside their permanent control, including open-source software tools and cloud-hosted testing tools.
The laboratory should maintain evidence relevant to use, including validation of open-source tools where applicable and configuration information at the time of testing.
An open-source tool is therefore not automatically disqualified.
The real question is whether the laboratory understands and controls the tool sufficiently for the intended testing.
Cloud testing creates additional evidence requirements
Cloud infrastructure can change the test environment without the laboratory physically touching a server.
NABL 137 addresses cloud and remotely accessed testing environments.
Relevant evidence can include:
- provider and service details;
- cloud configuration;
- region where relevant;
- virtual-machine or container configuration;
- network connectivity;
- bandwidth;
- access controls;
- test-data controls;
- tool and software versions.
A result generated in a cloud environment should be reconstructable well enough to explain what was actually tested.
Why the test environment must be separated
NABL 137 states that testing should be conducted in an environment segregated from production and development environments.
This helps reduce several risks:
- production activity changing test results;
- developers altering software during testing;
- test data contaminating production systems;
- uncontrolled access;
- loss of evidence about the tested version.
The laboratory should also prevent concurrent activities from interfering with testing where they could invalidate results.
Performance testing needs controlled simulation
Performance and load testing often require a virtual environment that simulates real users or production traffic.
Examples include:
- virtual users;
- simulated network bandwidth;
- latency settings;
- database state;
- server-resource limits;
- concurrent transactions.
NABL 137 requires such special configurations to be documented, including the reason the simulation is believed not to invalidate the result.
This is important because a performance number has little meaning without the conditions under which it was produced.
VAPT under NABL accreditation
NABL 137 includes Vulnerability Assessment and Penetration Testing, commonly called VAPT, within its software and IT-system testing terminology.
VAPT can involve:
- systematic vulnerability scanning;
- controlled penetration testing;
- identification of security weaknesses;
- evaluation of exploitability or impact;
- reporting of discovered vulnerabilities.
Accredited VAPT work still needs a clearly defined method and scope.
A laboratory should know:
- what targets are authorized;
- what attack techniques are permitted;
- what tools and versions are used;
- how evidence is preserved;
- how sensitive vulnerability information is protected;
- how results are reviewed before reporting.
Why cybersecurity testing needs strong access control
A cybersecurity test laboratory may hold highly sensitive information.
This can include:
- source code;
- credentials;
- vulnerability information;
- network architecture;
- customer data;
- attack logs;
- cryptographic material.
NABL 137 therefore emphasizes access controls, secure transmission and controlled handling of test artefacts.
Physical and digital security become part of laboratory integrity.
AI and machine-learning system testing
The 2026 amendment explicitly brings AI/ML systems and large language models into scope.
This is a major development because AI testing is different from conventional deterministic software testing.
A traditional function might produce the same output for the same input every time.
An AI system may depend on:
- training data;
- model version;
- prompt or input formulation;
- randomness settings;
- retrieval sources;
- system configuration;
- deployment environment.
Testing therefore requires much stronger control of context and versioning.
What should an AI testing laboratory record?
The exact evidence depends on the test, but a strong record may include:
- model name and version;
- deployment configuration;
- test dataset or benchmark version;
- prompt or input set;
- evaluation metric;
- acceptance criterion;
- software dependencies;
- hardware or accelerator details where relevant;
- randomness or sampling configuration;
- observed output;
- review and approval.
If those details are missing, repeating the AI test later may produce a different system state.
LLM testing creates new conformity-assessment questions
Large language models can generate outputs rather than selecting from a fixed list of deterministic results.
Possible test areas may include:
- functional behaviour;
- security;
- performance;
- robustness;
- interoperability;
- application-specific safety or regulatory requirements.
The laboratory should avoid vague claims such as "AI tested" without stating what was tested and how.
IoT and cyber-physical systems need hardware-software context
IoT and cyber-physical systems combine software with physical devices, sensors, networks and sometimes actuators.
A laboratory may need to control:
- firmware version;
- hardware revision;
- network protocol;
- sensor configuration;
- cloud endpoint;
- mobile application;
- security configuration;
- power state and operating conditions.
Testing only the mobile application while ignoring the device firmware may not represent the full system.
Medical software needs additional caution
NABL 137 includes medical software and Software as a Medical Device within its listed system types.
Medical-software testing can involve high-consequence decisions.
The laboratory should distinguish between:
- NABL accreditation of testing competence;
- product regulatory approval;
- medical-device certification;
- customer-specific acceptance.
NABL accreditation does not by itself replace all other product-regulatory requirements.
Secure coding and code review
The amended criteria include secure coding and code-review concepts.
Code review can examine issues such as:
- unsafe input handling;
- authentication logic;
- authorization;
- data exposure;
- cryptographic use;
- dependency risk;
- error handling;
- security-sensitive configuration.
The laboratory should define the method, tools, rule sets and review criteria used.
Accessibility and usability are now explicit quality areas
NABL 137 includes accessibility and usability among testing parameters.
Accessibility testing considers whether software can be used by people with a wide range of abilities and disabilities.
A test laboratory should identify:
- the accessibility requirement or standard;
- the technology under test;
- automated testing tools;
- manual review steps;
- assistive technologies where applicable;
- acceptance criteria.
Interoperability testing
Interoperability asks whether systems can exchange and use information correctly across platforms or organizational boundaries.
This is particularly relevant for:
- health systems;
- government platforms;
- financial systems;
- industrial IoT;
- telecom systems;
- cloud services.
The test environment should identify the exact protocol, interface, data format and system versions being evaluated.
What does laboratory competence look like for software testing?
Software testing competence is not proven only by having experienced developers.
Competence should be connected to the actual test scope.
| Testing area | Competence may require |
|---|---|
| Performance | Load modelling, statistics, infrastructure and performance-tool expertise |
| VAPT | Security methods, authorization boundaries, attack techniques and evidence handling |
| AI/ML | Model evaluation, datasets, metrics, version control and domain knowledge |
| Accessibility | Accessibility criteria, manual review and relevant assistive technologies |
| Embedded systems | Hardware-software interfaces, firmware, protocols and system-level test methods |
Method verification and validation still matter
NABL 137 specifically emphasizes test-method verification and validation under ISO/IEC 17025.
Before using a method, the laboratory should know:
- what requirement it evaluates;
- what inputs are needed;
- what tools are used;
- what output is produced;
- what constitutes a pass or failure;
- what limitations apply.
A popular tool does not automatically create a validated laboratory method.
How should a laboratory prepare for NABL accreditation?
- Define the scope. Choose the software and IT-system test parameters the laboratory can demonstrate competently.
- Study NABL 137. Map every applicable supplementary requirement.
- Map ISO/IEC 17025. Build the core laboratory competence framework.
- Control tools. Establish versions, configuration, licensing and validation records.
- Control test environments. Record infrastructure, access, network and simulation conditions.
- Demonstrate personnel competence. Link people to authorized testing activities.
- Validate methods. Define repeatable test processes and acceptance criteria.
- Secure test artefacts. Protect customer software, credentials and vulnerability evidence.
- Run internal audits. Follow real projects through the complete system.
- Use the current application form. NABL's register lists NABL 151 for testing laboratories with Amendment 07 dated 18 August 2026.
Common accreditation mistakes
- Calling a software company a laboratory without defining controlled testing activities.
- Using constantly changing cloud environments without recording configuration.
- Using open-source tools without validation or version control.
- Running tests in the live production environment without justified controls.
- Allowing developers to modify the system while accredited testing is in progress.
- Reporting VAPT results without a defined authorized scope.
- Claiming "AI compliance" without defined metrics or acceptance criteria.
- Failing to preserve test data and evidence.
- Using test-tool outputs without technical review.
Why this is a strong India niche in 2026
The April 2026 amendment directly names some of the fastest-growing digital technologies in India:
- AI and machine learning;
- large language models;
- cloud systems;
- cybersecurity;
- IoT;
- blockchain;
- medical software;
- embedded systems.
That gives software testing laboratories, cybersecurity firms and specialist verification providers a defined NABL framework for demonstrating testing competence.
It also creates a new problem for customers:
How do you distinguish a company that sells software-testing services from a laboratory accredited for a defined testing scope?
The answer is to verify the current NABL certificate and scope, not simply look for an accreditation claim on a website.
What customers should verify
- Is the organisation currently NABL accredited?
- Is the specific software or IT testing discipline in scope?
- Does the scope cover the required parameter, such as security, performance or interoperability?
- Does the laboratory have the appropriate test environment?
- Does the report clearly identify the software version tested?
- Are important test tools and methods identifiable?
- Does the report distinguish accredited testing from other consulting services?
The bigger opportunity: digital conformity assessment
NABL 137 shows that laboratory accreditation is moving beyond traditional physical testing.
Digital systems now need evidence about:
- security;
- performance;
- interoperability;
- reliability;
- accessibility;
- AI behaviour;
- hardware-software integration.
That creates a growing intersection between software engineering, cybersecurity, metrology and conformity assessment.
For technical laboratories, this is one of the most important new accreditation niches to watch in 2026.
Frequently asked questions
What is NABL 137?
NABL 137 is the Specific Criteria for Accreditation of Software & IT System Testing Laboratories. The current NABL register lists Amendment 02 dated 28 April 2026.
Can a software testing laboratory be accredited to ISO/IEC 17025?
Yes. NABL 137 applies supplementary sector-specific criteria together with ISO/IEC 17025:2017 to Software and IT System Testing Laboratories.
Does NABL 137 cover AI and large language models?
Yes. The 2026 amended criteria explicitly list artificial intelligence, machine learning and large language models, including edge-AI deployments, among the software and IT systems that may be tested.
Does NABL accreditation cover VAPT laboratories?
NABL 137 includes Vulnerability Assessment and Penetration Testing within its software and IT-system testing criteria. The laboratory still needs an accredited scope that covers the applicable security-testing activities.
Can accredited testing use cloud or open-source tools?
NABL 137 addresses cloud-hosted, customer-provided and open-source tools. The laboratory must maintain suitable controls and records covering matters such as validation, access, versions, configuration, licenses where applicable, connectivity and test data.
Does NABL accreditation mean the software product itself is approved?
Not automatically. NABL accreditation demonstrates laboratory competence for activities within the accredited scope. Product regulatory approval, certification or market authorization may involve additional requirements.
Sources checked
- NABL: Accreditation Documents register . The current register lists NABL 137, Issue 01, Amendment 02 dated 28 April 2026.
- NABL: News & Announcements . NABL announced the amended NABL 137 on 29 April 2026.
- NABL 137: Specific Criteria for Accreditation of Software & IT System Testing Laboratories .
- NABL: Accreditation overview . NABL accredits testing laboratories as per ISO/IEC 17025.
Editorial note: Software, AI and cybersecurity technologies change quickly, and accreditation criteria can be amended. This article explains official public NABL information available as of 13 September 2026. Laboratories should use the current NABL 137, current NABL 151 application form, ISO/IEC 17025:2017 and any applicable sector or regulatory requirements before applying or claiming accredited capability.
Comments
Post a Comment