2026-0086 Support NIRIS Testing (NS) - FRI 12 Jun

PART 1 – BIDDING INSTRUCTIONS Bidders shall submit a proposal (all four parts in one (1) document) clearly providing the following information: a: Cover page with the following information: Company name; name(s) of assigned contractor personnel; role(s) and responsibilities assigned to each profiled contractor personnel. b: Evidence of successfully delivering one to three projects of similar scope to the statement of work within the last five years. Each evidence shall demonstrate proof of performance and be comparable in size and scope to the requirements of this role. Additionally, ensure to include a detailed case study that highlights the Purpose, Objective, Output and Outcome (PO3) mentioned in the table (Annex C). Evidence shall display the ability to manage and deliver standard conformance criteria and test reference components for NIRIS by following customer requirements. c: CVs of the proposed contractor personnel for the project. d: Detailed effort estimation (exclusively provided for evaluation purposes) covering the following: estimated total labour and operational costs associated with the delivery of services, including licensing, hosting and travelling; a breakdown of estimated effort per work package expressed in FTE, where 1 FTE represents one full-time resource working one standard working day (7.6 hours). Deadline Date: Friday 12 June 2026 Requirement: Support NIRIS Testing Location: Remote, with occasional on-site work at NCIA The Hague (NLD) Period of Performance: 15 July 2026 – 31 December 2026 Required Security Clearance: NATO SECRET PART 2: STATEMENT OF WORK 1. INTRODUCTION The NATO Information and Communication Agency (NCIA) located in The Hague, The Netherlands, is the Interoperability Assurance Authority for NATO. In light of this responsibility, the C2 Service Centre is looking for a service contract which can provide NCIA with testing and quality assurance support for the continued maintenance, validation and evolution of the Networked Interoperable Real-Time Information Services (NIRIS) software. 2. OBJECTIVES The list below defines the overarching objectives of the engagement and establishes the intended outcomes that the Contractor is expected to achieve through the delivery of the different work packages described in this document. These objectives serve as the guiding principles against which all deliverables shall be measured. The Contractor is expected to align their approach, methodology, and resource planning with these objectives throughout the duration of the engagement. Under the direction and guidance of the Solution Architect, Service Delivery Manager, Test Manager, and Project Manager, the services to be provided are related to the testing, validation, verification, quality assurance, and test automation of NIRIS software modules. It is envisioned that these services shall be provided by one experienced software test engineer. a: Develop, update, and maintain NIRIS test cases, test scenarios, test scripts, and test data in accordance with agreed requirements, priorities, technical direction, release planning, and project objectives. b: Perform manual, automated, functional, regression, integration, and system testing to support the continued maintenance, validation, and evolution of the NIRIS software baseline. c: Support the full software testing lifecycle of NIRIS, including test analysis, test design, test implementation, test execution, defect reporting, retesting, regression testing, and test documentation. d: Develop, update, and maintain automated test scripts and test automation assets to improve test coverage, repeatability, maintainability, and regression testing capability. e: Support integration and verification activities to ensure that developed, updated, or maintained NIRIS software components operate correctly within the wider NIRIS system and in line with agreed interface, interoperability, and operational requirements. f: Analyse, investigate, document, and report software defects, test failures, anomalies, and quality issues identified during testing, integration, verification, release preparation, or operational support activities. g: Support the verification of defect fixes and software changes by performing retesting, regression testing, and validation against agreed acceptance criteria and requirements. h: Develop, update, and maintain test documentation, including test plans, test cases, test execution reports, defect reports, regression test evidence, automation documentation, and other project deliverables as required. i: Contribute to virtual and in-person meetings, reviews, planning sessions, sprint ceremonies, technical discussions, test coordination activities, and release readiness reviews with NCIA stakeholders and project team members. j: Ensure that all testing activities, test artefacts, automated scripts, defect reports, and associated deliverables comply with applicable NCIA testing standards, quality requirements, configuration management practices, and agreed project procedures. k: Update and expand the produced test assets, automated test scripts, test data, and documentation as necessary to accommodate new, revised, or emerging requirements throughout the duration of the engagement. l: Support the improvement of NIRIS software quality, reliability, maintainability, interoperability, and operational readiness by providing structured testing, clear test evidence, and timely feedback to the project team. 3. SCOPE OF WORK The Contractor shall provide the following deliverables classified per service: Service A: NIRIS Test Case Development, Maintenance and Test Baseline Management Deliverable A1: Updated and maintained NIRIS test case baseline. Output: Updated, maintained, and improved NIRIS test cases covering agreed functional, technical, regression, integration and release-related test scenarios. The deliverable includes the development and maintenance of manual and automated test cases required to support NIRIS baseline development, defect verification, regression testing, release preparation, User Acceptance Testing, and operational validation activities. Test cases shall be developed or updated in accordance with agreed requirements, user stories, defects, change requests, release priorities, and project planning. The test case baseline shall include, where applicable, test cases for agreed NIRIS capabilities such as CESMO integration, historic track data capabilities, RTS subscription mechanisms, interface behaviour, configuration changes, interoperability scenarios, and other functionality included in the agreed release scope. Outcome: NIRIS testing remains structured, repeatable, traceable, auditable, and aligned with the agreed requirements, work items, release priorities, and operational use cases. The maintained test case baseline supports consistent verification of NIRIS functionality across development, integration, regression, acceptance, and release preparation activities. It also reduces testing ambiguity by ensuring that test cases clearly define the required preconditions, test steps, expected results, pass/fail criteria, assumptions, and dependencies. Acceptance Criteria: Assigned test cases are created, reviewed, updated, or maintained in accordance with agreed requirements, priorities, sprint planning, release scope, or work package timeframe. Test cases clearly define preconditions, test steps, expected results, pass/fail criteria, assumptions, and dependencies where applicable. Test cases are stored and maintained in the agreed test management, issue tracking, configuration management, or project repository environment. Test cases are traceable to relevant requirements, user stories, defects, change requests, release objectives, or operational scenarios where applicable. Obsolete, duplicated, incomplete, or no longer applicable test cases are identified and updated or proposed for removal. Test cases are reviewed and updated where required following software, configuration, interface, or requirement changes. Test cases are suitable for execution in the agreed development, integration, test, release, or acceptance environment. Test cases support manual, automated, regression, integration, interface, interoperability, or release-related testing where applicable. Test case updates are made available for review within the agreed timeframe. Test case limitations, blocked areas, or missing dependencies are documented and communicated when required. KPIs: Test Case Completion Rate (%): Percentage of assigned test cases created or updated within the agreed sprint, release, or work package timeframe. Target: ≥ 90% Test Case Review Acceptance Rate (%): Percentage of submitted test cases accepted without major rework. Target: ≥ 90% Service B: NIRIS Automated Testing and Test Automation Framework Support Deliverable B1: Updated NIRIS automated test suite. Output: Automated tests developed, updated, maintained, refactored, and executed to support repeatable verification of NIRIS functionality, regression testing, integration testing, interface testing, deployment verification, non-functional testing where applicable, and release validation. The deliverable includes the development and maintenance of automated test scripts, automated test data, test assertions, execution configurations, and supporting automation assets using the agreed tools, frameworks, repositories, and environments. Automated testing shall support the continued evolution and sustainment of the NIRIS software baseline and shall contribute to earlier defect detection, regression stability, and improved release confidence. Where technically applicable, the automated test suite shall be expanded to cover agreed functionality included in NIRIS baseline or release scope, including areas such as CESMO integration, historic track data access, RTS subscription behaviour, interface configuration, message handling, data filtering, and other assigned functional or regression scenarios. Outcome: Improved software quality and delivery confidence through repeatable automated testing, earlier defect detection, reduced manual testing effort, and strengthened regression coverage. The automated test suite supports more efficient verification of NIRIS changes across development, integration, release preparation, and sustainment activities. It also improves the ability to identify regressions and provides reusable test evidence for release readiness and governance decisions. Acceptance Criteria: Automated tests are developed, updated, maintained, or refactored for assigned functionality where technically applicable. Automated tests are executable in the agreed development, build, test, integration, or CI/CD environment. Automated tests include clear assertions, expected results, and pass/fail logic. Automated tests are committed, reviewed, and maintained in the agreed configuration management environment. Automated test failures are analysed and either corrected, reported, linked to known defects, or documented for follow-up. Automated tests do not introduce unacceptable instability into the automated test suite. Automated tests are updated where required following software, interface, configuration, data model, or environment changes. Automated tests are aligned with agreed coding, scripting, testing, and configuration management practices. Automation limitations, dependencies, unstable tests, or blocked scenarios are documented and communicated where applicable. Automated test execution results are made available to support defect analysis, regression testing, and release readiness decisions. KPIs: Automated Test Delivery Rate (%): Percentage of assigned automated test tasks completed within the agreed sprint, release, or work package timeframe. Target: ≥ 90% Automated Test Execution Success Rate (%): Percentage of automated tests executed successfully in the agreed environment, excluding failures caused by known product defects, unavailable external dependencies, or agreed environmental limitations. Target: ≥ 90% Service C: NIRIS Regression Testing, Release Preparation, Baseline Verification Deliverable C1: NIRIS regression and release verification package. Output: Regression testing, release testing, defect verification, test execution evidence, test conclusions, and release readiness inputs delivered for agreed NIRIS baselines, including planned NIRIS releases such as NIRIS 4.7 and NIRIS 4.8 where included in the agreed scope. The deliverable includes the preparation, execution, and reporting of regression tests, functional verification, integration verification, release candidate testing, defect retesting, and test evidence required to support acceptance and release decisions. It also includes the preparation and coordination of User Acceptance Testing plans where required by the NCIA Point of Contact or delegated staff. Outcome: Planned NIRIS baselines are tested, stabilized, verified, and prepared for acceptance and release in accordance with agreed schedules, release scope, and quality expectations. This deliverable reduces the risk of functional regressions, supports informed release decisions, and contributes to the operational readiness of the NIRIS baseline by providing clear evidence of test execution, pass/fail status, known defects, blockers, risks, and limitations. Acceptance Criteria: Regression and release test scope is agreed with the NCIA Point of Contact or delegated staff. Assigned regression, release, and baseline verification activities are completed in accordance with agreed release scope, sprint planning, project priorities, or work package timeframe. Test plans are created or updated for planned NIRIS baselines where required. Test cases and automated tests are prepared, updated, or selected for assigned release items. Regression tests are executed in the agreed test environment. Test execution results are documented through the agreed test management, issue tracking, configuration management, or reporting tools. Failed tests are analysed and linked to known or newly reported defects where applicable. Resolved defects assigned for verification are retested and documented within the agreed timeframe. Regression and release conclusions clearly identify pass/fail status, blocked tests, unresolved defects, risks, limitations, and release readiness considerations. Test evidence is made available to support release readiness, acceptance, and governance decisions. Risks, blockers, dependencies, and test limitations are communicated in a timely manner. User Acceptance Testing plans are prepared and coordinated with the NCIA Point of Contact or delegated staff where required. KPIs: Regression Execution Completion Rate (%): Percentage of planned regression tests executed within the agreed timeframe. Target: ≥ 95% Regression Pass Rate (%): Percentage of executed regression tests passed, excluding tests failed due to agreed open defects, unavailable external dependencies, or accepted environmental limitations. Target: ≥ 90% Service D: NIRIS Interface, Interoperability and External Event Testing Support Deliverable D1: NIRIS interface and interoperability test support package. Output: Interface and interoperability test cases, test execution results, defect reports, configuration observations, test evidence, and event support inputs covering agreed NIRIS interfaces, standards, data providers, consumers, and interoperability scenarios. This deliverable groups testing activities related to supported standards, external systems, data providers, consumers, and interoperability events. This may include, where applicable and agreed within the release or work package scope: interfaces with data providers and consumers; Link 16 / JREAP support; OTH-Gold support; DIS support; VMF support; AIS support; CESMO-related test support; OANT/SMAQ integration configuration and analyser limitation testing; TDLITS-related test support; INTEND-related test support; CWIX-related test preparation, execution support, analysis, and evidence collection; customer visit test support; other agreed interoperability, interface, or external validation events. Outcome: NIRIS remains verified against agreed external systems, data providers, consumers, standards, and NATO interoperability testing environments. This deliverable supports NIRIS interoperability assurance by verifying data exchange, message handling, interface configuration, protocol behaviour, system integration, and expected operational behaviour in representative test and event environments. It also supports early identification of defects, configuration issues, external dependencies, and interoperability risks. Acceptance Criteria: Interface and interoperability test scenarios are prepared, reviewed, or updated for agreed standards, protocols, external systems, data providers, or consumers. Tests verify data exchange, message handling, configuration, filtering, transformation, and expected interface behaviour where applicable. Test activities are executed or supported in the agreed development, integration, interoperability, customer, or event environment. Test evidence is captured for agreed interoperability events or formal test activities. Defects, limitations, configuration issues, dependencies, and environmental constraints are documented. Test support is provided for agreed interoperability events, including CWIX-related preparation, execution support, and post-event analysis where required. Test results and observations are made available to support technical analysis, stakeholder discussions, and follow-up actions. Interface and interoperability test support is aligned with the agreed NIRIS release scope, event objectives, and project priorities. Risks, blockers, limitations, and external dependencies are communicated in a timely manner. Lessons learned or improvement opportunities from interoperability events are documented where applicable. KPIs: Task Completion Rate (%): Percentage of assigned interface and interoperability-related tasks completed within the agreed sprint, release, event-support, or work package timeframe. Target: ≥ 90% Service E: NIRIS Test Data Preparation and Test-Event Support Capability Deliverable E1: NIRIS test data preparation and test-event support package. Output: Prepared, validated, maintained, and reusable test data, test scenarios, test execution results, and verification support for NIRIS test data generation, setup verification, regression testing, interoperability testing, and test-event preparation activities. This deliverable may include testing and verification support for: test data for setup verification; track generator functionality; basic track data generation; configurable number of tracks; configurable location and movement; test support for standard protocols used by NIRIS; test data supporting interoperability testing and analysis; test data supporting functional, regression, interface, deployment, or release-related testing; test data supporting historic track data verification where applicable; test data supporting CESMO-related testing where applicable. Outcome: Reduced dependency on external simulators for basic test scenarios and improved efficiency of NIRIS test-event preparation, verification, and analysis. This deliverable supports repeatable and controlled testing by ensuring that appropriate test data is available for agreed scenarios. It improves the ability to verify NIRIS functionality, configuration, interface behaviour, track processing, message handling, and release readiness in a consistent and reusable manner. Acceptance Criteria: Test data is prepared, validated, maintained, or updated for agreed verification scenarios. Generated or prepared test data supports setup verification, functional testing, regression testing, interface testing, interoperability testing, or release testing where applicable. Test data is configurable, reusable, or repeatable where required. Test data supports agreed test scenarios, including track generation, interface testing, protocol testing, or operationally representative workflows where applicable. Test data limitations, assumptions, dependencies, and configuration requirements are documented. Test data issues affecting execution are analysed, corrected, reported, or documented for follow-up. Test-event support activities are tracked and reported through the agreed project tooling. Test data is stored or referenced in the agreed test management, configuration management, or project repository environment where applicable. Prepared test data does not introduce misleading, invalid, or unusable test results. Test data and test-event preparation activities are aligned with agreed sprint, release, event, or work package priorities. KPIs: Test Data Availability Rate (%): Percentage of agreed test scenarios supported by available and usable test data. Target: ≥ 90% Service F: NIRIS Defect Reporting, Test Documentation, and Continuous Test Process Improvement Deliverable F1: NIRIS defect verification, test documentation, and improvement package. Output: Defects identified, analysed, documented, tracked, retested, and verified using the agreed issue tracking and test management tools, together with updated NIRIS test documentation, test reports, verification evidence, release test inputs, and practical test process improvement recommendations. This deliverable includes the preparation and maintenance of test documentation such as: test plans; test cases; test case reports; test execution reports; regression test reports; defect reports; defect verification evidence; test data documentation; interface and interoperability test documentation; release readiness inputs; updates following software, configuration, interface, or requirement changes; lessons learned and test process improvement inputs. The deliverable also includes practical improvement recommendations related to test automation, regression scope refinement, test data reuse, defect reporting quality, test execution efficiency, and improved reporting transparency. Outcome: NIRIS defects are reported clearly, analysed efficiently, and verified systematically, while NIRIS test documentation remains accurate, current, auditable, and suitable for development, testing, governance, sustainment, release preparation, and operational support. This deliverable improves software quality, supports timely stabilization of the NIRIS baseline, and strengthens the transparency and repeatability of the NIRIS testing process. It also enables better release decisions through clear reporting of test results, open defects, risks, blockers, limitations, and improvement opportunities. Acceptance Criteria: Defects are documented with clear title, description, reproduction steps, expected result, actual result, environment information, release/build found, severity or priority where applicable, and evidence where applicable. Defects are linked to relevant test cases, requirements, user stories, release items, or change requests where applicable. Resolved defects assigned for verification are retested within the agreed timeframe. Reopened defects include clear justification and supporting evidence. Defect status is maintained accurately in the agreed tool. Test documentation is updated in line with assigned work, agreed project priorities, release scope, and test outcomes. Test reports clearly identify scope, environment, execution status, pass/fail results, defects, blockers, risks, limitations, and conclusions. Documentation is stored in the agreed configuration management, test management, issue tracking, or project repository environment. Test documentation supports release, acceptance, governance, and operational support decisions where applicable. Documentation is delivered within the agreed reporting timeframe. Testing process improvement opportunities are identified and communicated. Proposed improvements are practical, relevant, and aligned with NIRIS delivery priorities. Agreed improvements are implemented or documented for follow-up. Lessons learned from sprint testing, release testing, defect verification, customer support, or interoperability events are captured where applicable. KPIs: Test Documentation Completion Rate (%): Percentage of assigned test documentation items completed within the agreed timeframe. Target: ≥ 90% 4. DELIVERABLES COMPATIBILITY The deliverables produced under this SOW shall be compatible with the NIRIS software baseline, supported interfaces, test environments, operational context, and development and testing infrastructure provided or approved by the NCI Agency. Accordingly, the following requirements shall be met: All test deliverables, including test cases, automated tests, test scripts, test data, test reports, defect reports, and verification evidence, shall be developed, maintained, executed, and reported in alignment with the existing NIRIS architecture, technology stack, interface definitions, data models, configuration principles, and agreed testing approach. Test deliverables shall support verification of agreed NIRIS functionality, including baseline functionality, regression scope, release candidates, interface behaviour, interoperability scenarios, deployment verification, defect fixes, and operationally relevant use cases. Testing deliverables related to CESMO integration, historic track data, RTS subscription mechanisms, and other agreed NIRIS enhancements shall be compatible with the applicable NIRIS data handling mechanisms, supported standards, agreed requirements, and release scope. Test deliverables shall support verification of NIRIS-supported data exchange formats and interfaces, including but not limited to Link 16, JREAP, VMF, NVG, OTH-Gold, DIS, AIS, CESMO, and other relevant Tactical Data Links or interface standards, where applicable. Automated tests, test scripts, test data generators, and supporting test utilities shall be compatible with the NATO Software Factory environment and the agreed NIRIS development and testing toolchain, including GitLab, CI/CD pipelines, artifact repositories, test execution tools, issue tracking tools, test management tools, and configuration management repositories, where applicable. Test automation and supporting test utilities shall be executable within approved containerized or virtualized environments to support portability, repeatability, and consistency across test environments. Test execution artefacts shall include clear and reproducible instructions, including environment configuration, test data, preconditions, execution steps, dependencies, assumptions, expected results, and pass/fail criteria. All test cases, automated tests, test scripts, and test data shall take into account relevant NIRIS performance, stability, scalability, and near real-time processing constraints, particularly where testing involves track processing, interface message handling, subscription services, recording, replay, or high-volume data scenarios. Defect reports and verification evidence shall be compatible with the agreed issue tracking, test management, and reporting processes, and shall contain sufficient information to support analysis, reproduction, prioritization, correction, and retesting. Any additional testing technologies, automation frameworks, libraries, simulators, test tools, or supporting utilities introduced as part of the deliverables shall be agreed in advance with the NCIA Point of Contact. All deliverables shall comply with applicable NCIA security policies, information handling requirements, secure testing practices, accreditation constraints, and environment access rules, as instructed by the NCIA Point of Contact or delegated staff. 5. WORK PACKAGES DELIVERY SCHEDULE The list below defines the delivery schedule for all work packages under this statement of work. Each work package represents a discrete and manageable unit of work, comprising one or more deliverables that together contribute to the overall objectives of the engagement. a: For each work package, the Contractor shall deliver the specified outputs within the indicated target delivery date and in accordance with the defined acceptance criteria. The delivery schedule shall serve as the baseline against which progress is monitored, reported, and managed throughout the duration of the engagement. b: The Work Packages Delivery Schedule and the scope of outputs may be subject to modification in the event of unforeseen circumstances or changes in the needs and requirements of NCIA customers, provided that such modifications do not affect the total price of the bid. Any such modifications shall be made by mutual agreement between NCIA POC and the Contractor and shall be documented in writing. c: Any modification to the percentage of individual work packages shall be permitted if agreed between NCIA POC and the Contractor in writing, provided that the total aggregate percentage of all work packages equals 100%. d: Each work package is considered complete only upon full acceptance of all associated deliverables and acceptance criteria. 2026 BASE: 15 July 2026 – 31 December 2026 WP 01: Deliverable A1 – Updated and maintained NIRIS test case baseline. Target Delivery Date: 30 September 2026 / 22 December 2026. Bid Percentage: 25% WP 02: Deliverable B1 – Updated NIRIS automated test suite. Target Delivery Date: 30 September 2026 / 22 December 2026. Bid Percentage: 20% WP 03: Deliverable C1 – NIRIS regression and release verification package. Target Delivery Date: 9 October 2026. Bid Percentage: 15% WP 04: Deliverable D1 – NIRIS interface and interoperability test support package. Target Delivery Date: 30 November 2026. Bid Percentage: 15% WP 05: Deliverable E1 – NIRIS test data preparation and test-event support package. Target Delivery Date: 30 November 2026. Bid Percentage: 10% WP 06: Deliverable F1 – NIRIS defect verification, test documentation, and improvement package. Target Delivery Date: 22 December 2026. Bid Percentage: 15% 6. PAYMENT MILESTONES AND PROOFS OF DELIVERABLE The payment shall be dependent upon successful acceptance of the deliverable completion report and the Delivery Acceptance Sheet (DAS). Final payment for each deliverable shall be determined in accordance with the extent to which the defined KPIs for that deliverable have been achieved (see Annex B: KPI-to-Payment Mapping Model). KPI validation shall be performed by NCIA POC. The Contractor may invoice one or more work packages together, provided they have been formally accepted. The invoiced amount shall be equal to the sum of the agreed total bid percentages stated in the latest agreed Work Packages Delivery Schedule. Invoices shall be accompanied with a Delivery Acceptance Sheet signed by the Contractor and the NCIA POC, or the assigned Service Delivery Manager. No payment shall be made for partially completed or non-accepted work packages. Payment Milestones: WP A / 01: Upon formal acceptance of the updated and maintained NIRIS test case baseline deliverables. WP B / 02: Upon formal acceptance of the updated NIRIS automated test suite deliverables. WP C / 03: Upon formal acceptance of the NIRIS regression and release verification deliverables. WP D / 04: Upon formal acceptance of the NIRIS interface and interoperability test support deliverables. WP E / 05: Upon formal acceptance of the NIRIS test data preparation and test-event support deliverables. WP F / 06: Upon formal acceptance of the NIRIS defect verification, test documentation, and improvement deliverables. 7. COORDINATION AND REPORTING The Contractor shall deliver the defined deliverables under the guidance of the NCIA POC, in coordination with the Project Manager, Service Delivery Manager, and relevant technical leads within the NIRIS project. The Contractor shall primarily deliver the services remotely, unless a specific deliverable explicitly requires on-site execution at an NCIA-designated location. The development and delivery of the deliverables shall follow an Agile approach, with activities planned, tracked and reviewed through agreed Sprint planning, execution, and review mechanisms. The Contractor shall: participate in regular coordination activities, including sprint planning, daily stand-ups (as required), sprint reviews, and other project meetings; maintain up-to-date progress tracking through the agreed tools (e.g. Jira or equivalent); communicate proactively any risks, issues, or deviations impacting the delivery of the agreed deliverables. For each deliverable to be considered complete and eligible for acceptance and payment, the Contractor shall submit a Deliverable Completion Report to the NCIA POC. The Deliverable Completion Report shall include, as a minimum: summary of the work performed; description of the delivered functionality or outcome; evidence of completion (e.g. code commits, test results, deployment artefacts, documentation); traceability to the agreed requirements and acceptance criteria. The Deliverable Completion Report shall be subject to review and validation by the NCIA POC. The NCIA POC shall provide formal feedback, including: acceptance or rejection of the deliverable; evaluation against the defined acceptance criteria and applicable KPIs; identification of any required corrections or follow-up actions. Only deliverables formally accepted by the NCIA POC shall be considered complete and eligible for payment in accordance with the defined payment milestones. 8. SECURITY Performance of the services described in this SOW requires a valid NATO SECRET security clearance prior to the start of the engagement. It is the responsibility of the contracting company to obtain and maintain the security accreditation of all individuals working on this arrangement. 9. CONSTRAINTS All the documentation provided under this statement of work shall be based on NCIA templates or the format agreed with the NCIA POC. All scripts, documentation and required code shall be stored under NATO Software Factory platforms and tools. 10. PRACTICAL ARRANGEMENTS This is a deliverables-based contract. The Contractor shall be provided a user account for access to the NATO Software Factory (Azure DevOps). This SOW requires scheduled travel on site in NCIA The Hague, twice per year or per request in any European sites. The travel, lodging and associated expenses for travel are included in the total price of the bid, such that NCIA shall not be invoiced. Extraordinary Travel (Purchaser Directed Travel) may be required to other NATO or non-NATO locations as necessary. In the event of such unforeseen meetings being called, the cost of all travel and subsistence will be addressed through a contract amendment. Extraordinary Travel expenses will be reimbursed in accordance with Article 5.5 of AAS+ Framework Contract. Such costs will be set as a separate PO line with a not-to-exceed value to cover and reimburse actual expenses upon submission of all receipts and invoices in line with NCIA processes. The services depicted in this SOW are expected to be carried by either one contractor personnel or a team of contractors for the duration of the agreement. It is up to the bidder to propose the size of the team that delivers the services and produces the deliverables within the timelines allocated. 11. QUALIFICATIONS [See Requirements] ANNEX B: KPI-TO-PAYMENT MAPPING MODEL This Annex establishes the mechanism by which the achievement of defined Key Performance Indicators (KPIs) shall be mapped to the payment due for each deliverable under this Statement of Work. It describes how KPI results will be evaluated and applied for the purpose of determining the final payable amount. Overall Payment Model For each deliverable, 70% Fixed Payment shall be released upon formal acceptance, subject to the deliverable meeting the applicable acceptance criteria. 30% Variable Payment shall be contingent upon KPI performance. Each KPI applicable to a deliverable shall be assigned an equal weighting within the 30% variable payment component (KPI Weight). The proportion of each KPI Weight payable shall be determined in accordance with the KPI scoring bands below. Meets or exceeds target (100%): 100% of KPI weight payable Minor deviation (90–99%): 90% of KPI weight payable Moderate deviation (80–89%): 75% of KPI weight payable Significant deviation (70–79%): 50% of KPI weight payable No compliance (< 70%): 0% of KPI weight payable Total Payment = Fixed Component + Variable Component Where: Fixed Component = 70% of deliverable value; Variable Component = Sum of (KPI Weight × Percentage of KPI weight payable). 8. SECURITY Performance of the services described in this SOW require a valid NATO SECRET security clearance prior to the start of the engagement. 11. QUALIFICATIONS Each contractor personnel must meet the following requirements: At least 5 years of professional experience in software testing and quality assurance, with a focus on complex software systems, networked applications, or distributed environments. Proven ability to communicate effectively in English, both orally and in writing, in a clear, structured, and professional manner. Demonstrated experience in working within Agile/Scrum environments, including participation in sprint planning, test planning, sprint execution, defect triage, sprint reviews, and release preparation activities. At least 3 years of professional experience in designing, writing, executing, and maintaining manual test cases, including functional, regression, integration, interface, and release-related test scenarios. At least 3 years of experience in defect identification, defect reporting, retesting, regression testing, and defect verification using issue tracking and test management tools. At least 2 years of experience testing RESTful services, APIs, messaging systems, or data exchange interfaces, including verification of request/response behaviour, data processing, data filtering, and error handling. At least 2 years of experience testing Web GUI, REST API, and command-line interfaces, preferably for networking products or interface-heavy software systems. At least 2 years of experience working with interoperability testing, including testing of data exchange, message handling, configuration, integration with external systems, or multi-system test environments. At least 2 years of professional experience working with test automation frameworks, such as Robot Framework, Gauge, Cucumber, Selenium, Playwright, Cypress, or similar. At least 1 year of professional experience with scripting or programming languages used to support test automation, test execution, troubleshooting, or environment configuration, such as Java, Python, Linux Bash, Ansible, or similar. At least 1 year of professional experience working with containerized or virtualized test environments, including Docker, or equivalent technologies. Demonstrated experience using development, testing, and configuration management tools such as Jira, Zephyr, GitLab, CI/CD pipelines, artifact repositories, or equivalent tools. Demonstrable experience in preparing and maintaining test documentation, including test plans, test cases, test execution reports, defect reports, verification evidence, regression reports, and release readiness inputs. Experience in defining test scenarios, acceptance criteria, validation approaches, or verification evidence for software deliverables. Demonstrable ability to troubleshoot and support issue analysis on Windows Server and Linux-based operating systems, including basic knowledge of IP addressing, routing, DNS, HTTP/HTTPS, Active Directory, certificate management, and service configuration. Demonstrable knowledge or experience in interoperability and data exchange standards, particularly within defence. Knowledge of Tactical Data Links, including Link 16, Link 22, OTH-Gold, JREAP, VMF, DIS, AIS, CESMO, or similar standards, is highly desirable. Experience working with distributed systems and multi-component architectures, including integration and testing across multiple data sources, services, interfaces, or external systems. Familiarity with secure testing practices, controlled test environments, information handling requirements, and working within regulated or accredited environments. Possession of relevant technical or testing certifications, including ISTQB, TMap, Microsoft, Red Hat, CompTIA, Cisco, or equivalent certifications, is desirable. The Contractor personnel must be a national of a NATO member nation.