RFI 424358-FEM.pdf

NCIA-ACQ-1.017(07.25)

NCIA/ACQ/2026/07300

Friday, 12 June 2026

NCIA Request for Information (RFI)

To: Industry Partners

Subject: FORENSICS EVIDENCE MANAGEMENT (FEM) SYSTEM

RFI-424358-FEM

1. The NATO Communications and Information Agency (NCIA) is conducting market research to identify qualified vendors and gather input on potential solutions to support the upcoming acquisition for a Forensics Evidence Management (FEM) System. To that end, we are issuing the attached Request for Information (RFI) 424358 to solicit feedback from capable and interested industry partners.

2. This RFI is issued for planning and budgeting purposes only and is not a request for bids.

It is part of NCIA’s effort to ensure it has a clear understanding of the marketplace, available capabilities, estimated costs and potential acquisition strategies.

3. We value your insight and invite you to:

a. Share relevant corporate capabilities and experience;

b. Review and comment on our draft requirements (Annexes A & B) with a view in providing recommendations for improving performance outcomes, competition, and efficiency; and identifying any risks or concerns that should be considered during planning.

4. Submission instructions and additional details can be found in the enclosure to this RFI.

5. Only companies from a NATO member country can participate in or respond to this RFI

(https://www.nato.int/cps/en/natohq/nato_countries.htm).

6. Should you have any questions or need clarification, please contact Leonora Alushani, Contracting Officer at RFI-424358-TSSU@ncia.nato.int.

7. We thank you in advance for your time and input, and we look forward to engaging with you as we shape this potential acquisition.

For the Chief of Acquisition:

Leonora Alushani Contracting Officer https://www.nato.int/cps/en/natohq/nato_countries.htm

Enclosure:

• Request for Information with Annexes A

• Distribution List

Distribution List

1. NATO Delegation (Attn: Infrastructure Adviser)

1. Albania 12. Greece 23. Poland

2. Belgium 13. Hungary 24. Portugal

3. Bulgaria 14. Iceland 25. Romania

4. Canada 15. Italy 26. Slovakia

5. Croatia 16. Latvia 27. Slovenia

6. Czechia 17. Lithuania 28. Spain

7. Denmark 18. Luxembourg 29. Sweden

8. Estonia 19. Montenegro 30. Türkiye

9. Finland 20. Netherlands 31. United Kingdom

10. France 21. North Macedonia 32. United States

11. Germany 22. Norway

2. All NATEXs

Table of Contents

REQUEST FOR INFORMATION

A. Introduction

B. Purpose

C. Background

D. Submission Instructions

E. Disclaimer

F. Use of Information Provided through Responses

G. RFI Point of Contact

Annex A – Requested Information

Annex B – Epics and User Stories

Annex C – Response Template

REQUEST FOR INFORMATION

A. Introduction

1. The NATO Communications and Information Agency (NCIA) is conducting market research to identify potential sources and gather information regarding industry capabilities to support a Forensics Evidence Management (FEM) System. This Request for Information (RFI) is issued solely for informational and planning purposes and does not constitute a Request for Proposal (RFP), Request for Quotation (RFQ), or invitation for bid.

B. Purpose

1. The purpose of this RFI is to obtain input from industry to help inform the NCIA’s acquisition planning. Responses to this RFI will assist in refining requirements, identifying capabilities, budget planning and shaping the strategy for any future solicitation.

C. Background

1. Digital forensics within NCIA is performed in support of cybersecurity incident response, cyber threat investigations, and related technical analysis activities. The digital forensics team is responsible for the acquisition, handling, tracking, preservation, examination, and disposition of digital evidence and associated physical media. These activities support investigations affecting the NATO Enterprise and NATO Operations and Missions networks.

2. The effective management of forensic evidence is essential to maintaining evidential integrity, chain of custody, accountability, traceability, and operational confidence throughout the forensic lifecycle. Evidence may include, but is not limited to, storage media, mobile devices, laptops, removable media, forensic images, exported artefacts, supporting documentation, and other items collected or generated during cyber investigations.

3. The current Forensics Evidence Management capability provides a means to record and track evidence handled by the digital forensics team. However, the existing solution has been in service for an extended period and requires modernization to better support current operational needs, improved usability, stronger auditability, more efficient workflows, and alignment with modern evidence management practices.

4. The future Forensics Evidence Management solution is expected to support the secure and controlled management of evidence from intake through storage, transfer, examination, reporting, retention, and disposal. This includes the ability to identify and label evidence, maintain chain of custody, record handling actions, manage storage locations, support evidence movement, generate reports, and provide appropriate access control and audit logging.

5. This RFI seeks industry feedback on how a future Forensics Evidence Management capability could be delivered primarily through a Commercial-Off-The-Shelf solution, using standard product capabilities, configuration, and limited customization wherever feasible. The intended outcome is to enable Purchaser personnel to manage forensic evidence securely, consistently, and efficiently, while minimizing administrative burden and avoiding unnecessary bespoke development.

D. Submission Instructions

1. Interested parties are invited to respond in accordance with the instructions below:

a. Submit responses via the email address in section G no later than 12:00 hours

Central European Time (CET) on 06 July 2026.

b. Responses should be submitted using the Excel Response template provided in Annex C

c. The following can be included as a reference in your responses and attached as separate documents:

i. Company brochures or product literature (optional)

ii. Attachments such as past performance references (optional)

d. Use the following subject line for submission

i. “Response to RFI 424358-FEM – [Company Name]”

e. All responses should address the items listed in Annex A – Requested

Information.

E. Disclaimer

1. This RFI is for planning and informational purposes only and shall not be construed as a solicitation or obligation on the part of the NCIA. The NCIA does not intend to award a contract based on responses to this RFI. Respondents are solely responsible for all costs incurred in responding to this RFI. The NCIA will consider and analyse all information received from this RFI and may use these findings to develop a future solicitation. The NCIA will consider all responses as confidential commercial information and will protect it as such.

2. NCIA reserves the right, at any time, to cancel this informal market survey, partially or in its entirety. No legal liability on the part of NCIA for payment of any sort shall arise and in no event will a cause of action lie with any prospective participant for the recovery of any costs incurred in connection with the preparation of documentation or participation in response hereto. All effort initiated or undertaken by prospective informal market survey participants shall be done considering and accepting this fact.

F. Use of Information Provided through Responses

1. Confidentiality of Responses

The NCIA may incorporate industry comments and responses, in part or in whole, into a future release of a solicitation. Should respondents include proprietary data in their responses that they do not wish to be disclosed to the public for any purpose, or used by NCIA (except for internal evaluation purposes), they must:

a. Mark the title page with the following legend:

This document includes data that shall not be disclosed outside NATO and shall not be duplicated, used, or disclosed – in whole or in part – for any purpose other than for NCIA internal evaluation purposes, unless otherwise expressly authorised by [insert company name]. This restriction does not limit the NCIA’s right to use information contained in this data without restriction if it is obtained from another source. The data subject to this restriction are contained in sheets [insert numbers or other identification of sheets]

b. Mark each sheet of data it wishes to restrict with the following legend:

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this document.

G. RFI Point of Contact

1. Leonora Alushani

2. RFI-424314-NPKI-TPT@ncia.nato.int.

Annex A – Requested Information

A.1 Purpose and Desired Outcome The purpose of this Request for Information is to obtain industry feedback on the attached draft Epics and User Stories for a Forensics Evidence Management (FEM) System, provided in Annex B.

The Purchaser’s intent is to validate whether the required operational outcomes can be achieved primarily through existing Commercial-Off-The-Shelf products, standard managed service offerings, configuration, and limited integration wherever possible. The Purchaser does not intend to drive the requirement toward a fully custom-developed solution unless industry feedback demonstrates that this is necessary to achieve the required operational outcomes.

The desired outcome of this RFI is to help the Purchaser refine the attached Epics and User Stories before any potential future solicitation. Industry feedback should help determine whether the required capability can be achieved through existing products and standard managed service offerings, whether the requirements should be adjusted to better align with market capabilities, and where customization or bespoke development may create avoidable cost, complexity, or risk

Respondents are requested to review the Epics and User Stories provided in Annex B and provide structured feedback using the response template in Annex C. Response should focus on practical product capability, managed service delivery, implementation approach, risks, constraints, and recommendations.

Marketing material may be included as supporting information; however, respondents are invited to complete the response template in Annex C to allow consistent comparison of industry responses.

Due to limitations of the publication page, this document has been published as 1 single PDF. Those of you who wish to provide a response and want to receive the excel version of Annex B and C please reach out to the undersigned via RFI-424358- TSSU@ncia.nato.int.

A.2 Scope of Requested Feedback Respondents are requested to provide feedback on the degree to which their proposed product, platform, service, or combination thereof aligns with the attached Epics and User Stories.

The Purchaser is particularly interested in understanding:

1. Which Epics or capability areas are well supported by the respondent’s existing Commercial-Off-The-Shelf products or standard managed service offerings.

2. Which capabilities can be achieved through standard configuration.

3. Which capabilities would require customization, integration, professional services, or bespoke development.

4. Which capabilities are not supported.

5. Which User Stories may be too specific, unnecessarily complex, or misaligned with common product or managed service capabilities.

6. What alternative approaches the respondent would recommend where a User

Story is not supported, and why the alternative would better achieve the underlying operational intent.

mailto:RFI-424358-TSSU@ncia.nato.int mailto:RFI-424358-TSSU@ncia.nato.int

7. Whether there are industry-standard capabilities, workflows, or product features that should be considered but are not currently reflected in the Epics and User Stories.

8. How the capability would be implemented, maintained, upgraded, and supported by the Contractor.

9. How licensing, renewal, sustainment, support, and service management would typically be structured.

A.3 Response Approach To reduce response burden and support meaningful comparison across submissions, respondents should first provide feedback at the Epic or capability level.

Detailed User Story-level responses are only required where:

• the capability is not supported natively by the proposed product, platform, or service;

• the capability would require customization;

• the capability would require significant integration;

• the respondent recommends an alternative approach;

• the User Story creates implementation complexity, cost, risk, vendor lock-in, or technical constraints; or

• the User Story should be clarified, consolidated, removed, reprioritized, or reframed.

Respondents should avoid treating the attached User Stories as a compliance matrix. The Purchaser is seeking industry feedback on the feasibility, maturity, and suitability of the required capabilities, including whether the User Stories should be adjusted to better align with existing Commercial-Off-The-Shelf products and standard managed service models.

A.4 Areas of Interest Respondents are requested to address the following areas in their response and to prioritize responding to A.4.1 through A.4.4, responding to the other areas when applicable and time permitting.

A.4.1 Overall Fit Respondents should provide a summary of the overall fit between the attached Epics and User Stories and their proposed solution or service. This should include areas of strong alignment, areas of partial alignment, and areas that are not supported or would require significant adaptation.

A.4.2 COTS and Managed Service Alignment Respondents should identify which capabilities are available through existing Commercial-Off-The-Shelf products, which are available through standard managed service offerings, and which would require configuration, integration, customization, or professional services.

A.4.3 User Story Exceptions, Gaps, Risks, and Recommended Changes For User Stories that are not fully supported, or where the respondent recommends a different approach, respondents should identify the relevant User Story, describe the issue or gap, and provide a recommended approach.

Relevant feedback may include, but is not limited to:

• the User Story is not supported;

• the User Story is partially supported;

• the User Story requires configuration;

• the User Story requires customization;

• the User Story requires third-party integration;

• the User Story assumes a custom workflow rather than a standard product or service workflow;

• the User Story may introduce unnecessary cost, complexity, risk, or vendor lock-in;

• the User Story should be clarified, consolidated, removed, or reprioritized; or

• the operational intent could be achieved through an alternative product capability, workflow, or managed service approach.

A.4.4 Recommended Additional Capabilities Respondents should identify any industry-standard capabilities, workflows, or service features that are not reflected in the attached Epics and User Stories but should be considered by the Purchaser.

A.4.5 Implementation, Operation, and Sustainment Respondents should describe how a comparable capability would typically be implemented, transitioned into service, operated, maintained, and upgraded. This should include key Purchaser responsibilities, key Contractor responsibilities, common dependencies, implementation risks, training considerations, and sustainment considerations.

A.4.6 Configuration, Customization, and Integration Respondents should describe which capabilities can typically be configured by the Purchaser or Contractor, which changes would require vendor professional services, which changes would require custom development, and how customizations or integrations are maintained through upgrades. Respondents should also identify relevant APIs, connectors, import/export mechanisms, and integration patterns applicable to the proposed solution or service.

A.4.7 Licensing, Renewal, and Support Model Respondents should describe the typical licensing, renewal, support, and service model for the proposed capability. This should include relevant licensing metrics, support tiers, software update arrangements, renewal model, optional modules or add-ons, and any separate costs for implementation, migration, training, integration, or sustainment.

Annex B – Epics and User Stories

In attachment

Annex C – Response Template

In attachment

Tracking ID Epic / Goal User Story / Description

FEM Forensics Evidence Management System (FEM) Implementation of a new Forensic Evidence Management (FEM) system to catalogue, query, and manage forensic evidence artefacts acquired by the cybersecurity investigators and analysts.

FEM-E1 Evidence Management Ability to track and manage physical and logical evidence throughout its lifecycle FEM-E1-BA Business Value Enables accurate tracking and management of evidence, reducing errors and improving efficiency

FEM-US-1.1 As a Forensic Analyst, I want to be able to record the complete lifecycle of logical and physical forensic evidence, so that I can track the history of each piece of evidence from its initial capture to its destruction.

FEM-US-1.2 As a Forensic Analyst, I want to be able to attach multiple files to cases at any point during the investigative process, so that I can easily associate relevant documents with each case.

FEM-US-1.3

As a System Engineer, I want the solution to provide default evidence item field templates, field types, and controlled values based on the selected evidence item type, so that evidence can be registered consistently using relevant metadata fields.

FEM-US-1.4 As an Administrator, I want to be able to customize field labels and types within the tool, so that I can tailor the system to meet our specific needs.

FEM-US-1.5 As an Administrator, I want to be able to integrate the evidence management system with our existing authentication and authorization systems, so that we can ensure secure access to sensitive information.

FEM-US-1.6

As a Technical Lead, I want the solution to be fully deployed, configured and operational within the purchaser's airgap classified environment, without reliance on external or network dependencies, so that it can function securely and independently in a classified setting

FEM-US-1.7

As a System Engineer, I want the solution to have an Application Programming Interface (API) to allow automation or programmatic usage of all system functions, including case and evidence management, reporting and administrative actions.

FEM-US-1.8 As a Forensics Analyst, I want the solution to provide a Graphical User Interface that is intuitive and easy to navigate.

FEM-US-1.9 As a Forensics Analyst, I want the solution to produce destruction certificates when required

FEM-US-1.10 As a Service Delivery Manager, I want the solution to support user-defined dates/timestamps for case records completion and other target milestones

FEM-US-1.11 As a Service Delivery Manager, I want the solution to track Forensics Analyst responsible for the case, exhibits, records, and files associated with the system.

FEM-US-1.12 As a Service Delivery Manager, I want the solution to track the exact department/section/user that is working on the case, exhibits, records, and files associated with the system.

FEM-US-1.13

As a Service Delivery Manager, I want the solution to provide real-time visibility and reporting on the status and location of all evidence, including the ability to perform muster and verification activities, so that I can ensure accountability, integrity, and completeness of evidence at any point in time.

FEM-US-1.14 As a Forensics Analyst, I want the solution to facilitate the cataloguing, recording and storage of a wide range of physical evidence from all common devices

FEM-US-1.15

As a Service Delivery Manager, I want the solution to support expected case, evidence, storage, and user volumes so that operational growth does not degrade the availability, performance, or usability of the evidence management service

FEM-US-1.16 As a System Engineer, I want the solution to be integrated with the Purchaser's existing diodes systems, which allow transfer of any evidence files from NU/NR systems to NS Raw Evidence Storage.

FEM-US-1.17 As a System Engineer, I want the solution to be integrated with the Purchaser's existing case management/ticketing system (JIRA/Confluence) to that tickets/cases management can be automated.

FEM-US-1.18 As a Security Officer, I want access to be restricted based on roles and permissions so that only authorized users can access sensitive data

FEM-US-1.19 As a security Officer, I want system logs to be forwarded to the purchaser's SIEM solution in near real-time so that security monitoring, auditing, and incident detection can be centralized.

FEM-US-1.20 As an Analyst, I want the ability to export (PDF) the evidence item history in form of the purchaser provided Chain of Custody template.

FEM-US-1.21

As a Service Delivery Manager, I want multiple authorized users to concurrently access and use the full functionality of the solution so that forensics operations can continue without user contention or workflow disruption

FEM-E1-NFR-1 The system shall ensure the protection and integrity of evidence by preventing tampering and unauthorized modifications.

FEM-E1-NFR-2 The system shall provide secure access to sensitive information through integration with our existing authentication and authorization systems.

FEM-E1-NFR-3 The system's network communication shall be secured with Transport Layer Security (TLS) version 1.2 or higher using NATO PKI.

FEM-E1-NFR-4 The system shall collect and safeguard audit logs for all activities performed and have them automatically and securely forwarded to the purchaser's SIEM near real-time

FEM-E1-NFR-5 The system must enforce role-based access control (RBAC) for all cases, evidence, with auditable access controls, also encrypting data so only the specified members have the ability to access and decrypt.

FEM-E1-NFR-6 The solution must support at least 5 authorized concurrent users accessing the full functionality of the solution without material degradation of core workflows

FEM-E2 Raw Evidence Storage (RES) Secure storage for digital forensic artefacts

FEM-E2-BA Provides a secure and reliable solution to store digital evidence and protect it against unauthorized access, tampering or loss.

FEM-US-2.1 As a Forensics Analyst, I want to store digital forensic artefacts securely, so that I can ensure the integrity of evidence.

FEM-US-2.2

As a System Administrator, I want to ensure that only authorized administrators can define or modify configuration and policy changes to the storage solution, so that I can maintain control over the storage environment.

FEM-US-2.3 As a Forensics Analyst, I want to access digital forensic artefacts stored on the RES solution via a secured method, so that I can easily retrieve and analyze evidence.

FEM-US-2.4 As a Service Delivery Manager, I want the solution to support scalable storage capacity for digital evidence so that operational needs can be met without storage constraints impacting ingestion, retention, or access

FEM-US-2.5 As a Forensics Analyst, I want the system to provide the ability to securely store any form of digital evidence collected.

FEM-E2-NFR-1 The RES solution must ensure the integrity and security of digital forensic artefacts through encryption and access controls.

FEM-E2-NFR-2 The solution shall be provided in high-availability (HA) and redundant to ensure continuous operation with no data loss even in the event of hardware failure.

FEM-E2-NFR-3 The solution must support a minimum of 500TB of usable storage capacity at initial deployment, with ability to scale beyond this threshold.

FEM-E3 Migration, Backup, Archiving, and Enclave Infrastructure Ensure business continuity through backup, archiving, and enclave infrastructure

FEM-E3-BA Migrate the current solution to the new solution and ensures that critical systems and data are always available, reducing downtime and improving overall resilience

FEM-US-3.1

As a System Administrator, I want the contractor to configure all systems and workloads with anti-virus/anti-malware solution and managed by the update systems as agreed in the design, so that I can ensure security is maintained.

FEM-US-3.2 As a System Engineer, I want the contractor to integrate, configure and uplift the current Purchaser's archival solution that so that cases and artefacts can be archived and retrieved properly without errors on-demand.

FEM-US-3.3

As a System Engineer, I want the contractor to deliver, implement, configure a backup solution so that the delivered solution (FEM, Raw Evidence Storage) is resilient to failures and can be reliably restored with minimal disruption.

FEM-US-3.4

As a System Administrator, I want the contractor to configure all systems and workloads to be monitored through the Purchaser's existing monitoring systems (e.g. SolarWinds) within the applicable domains as agreed in the design, so that I can ensure monitoring is maintained.

FEM-US-3.5

As a System Administrator, I want the contractor to migrate the current Purchaser evidence management database, Raw Evidence Storage and Archival. Migration should completed error-free, including all data elements.

FEM-E3-NFR-1 Performance: The backup and archival solutions should be able to handle a minimum of 10 terabytes of data per calendar month.

FEM-E3-NFR-2 Security: All data stored on the Raw Evidence Storage solution shall be encrypted using AES-256.

FEM-E3-NFR-3

Reliability: The contractor shall ensure that the Evidence Management (EM) solution and Raw Evidence Storage (RES) solution systems would be updated to reflect all data archival activity and that the data had been moved to separate physical media.

FEM-E4 Labelling, Signing, and Tagging Ability to label, sign, and tag physical evidence for tracking and verification purposes

FEM-E4-BA Improves the integrity of physical evidence by ensuring it is properly labeled, signed, and tracked throughout its lifecycle

FEM-US-4.1

As a Forensics Analyst, I want to print waterproof, tamper-evident labels with user-customizable text and barcodes (UPC, EAN-13, QR Code) from my workstation using a barcode printer, so that physical evidence can be uniquely identified and tracked and without requiring direct hardware integration with the core FEM/RES solution

FEM-US-4.2 As a Forensics Analyst, I want to read barcodes (UPC, EAN-13, QR Code) using a barcode scanner, so that physical evidence can be quickly identified and verified.

FEM-US-4.3 As a Forensics Analyst, I want to use RFID scanners to read and write RFID tags on physical evidence, so that evidence can be tracked and verified efficiently.

FEM-US-4.4 As a Forensics Analyst, I want to capture digital signatures using a stylus pen and digital signature pad, so that evidence chain-of-custody can be securely recorded.

FEM-E4-NFR-1 The labelling, signing, and tagging functionality must ensure the integrity of physical evidence by preventing tampering or alteration.

FEM-E4-NFR-2 The system must be compatible with the last 2 version of the Microsoft Windows identified in the A2SL

FEM-E4-NFR-3 The solution must support printing waterproof, tamper-evident evidence labels with user-customizable text and barcodes, with minimum label size of 60mm x 25mm

FEM-E5 Evidence Bags and Containers Secure storage containers for physical evidence FEM-E5-BA Provides a secure way to store physical evidence, protecting against tampering or contamination

FEM-US-5.1

As an Forensics Analyst, I want to store standard 3.5” hard disk drives and mobile devices such as smartphones in re-sealable, plastic air bubble padded, anti-static evidence bags, so that I can protect the evidence from damage during transportation and storage.

FEM-US-5.2

As an Forensics Analyst, I want to store larger electronic devices such as laptops and tablets in re-sealable plastic air bubble padded, anti-static evidence bags, so that I can protect the evidence from damage during transportation and storage.

FEM-E5-NFR-1 The evidence bags should be made of durable, tamper-evident material to prevent unauthorized access or contamination of the evidence.

FEM-E5-NFR-2 The bags should have secure sealing mechanisms to ensure that they remain closed during transportation and storage.

FEM-E6 Digital Camera and Accessories Ability to capture images of physical evidence for documentation purposes

FEM-E6-BA Improves the accuracy and detail of evidence documentation, reducing errors and improving overall efficiency

FEM-US-6.1 As a Forensic Analyst, I want to be able to take pictures of physical evidence using a digital camera which is compatible with the solution delivered, so that I can attach these images as files to forensic case records.

FEM-US-6.2 As a Forensic Analyst, I want to be able to transfer images from the digital camera to my Windows workstation, so that I can attach them to forensic case records.

FEM-US-6.3

As a Forensic Analyst, I want the digital camera to support removable storage with sufficient capacity for extended evidence photography activities, so that image capture can continue without interrupting evidence collection to offload storage.

FEM-US-6.4 As a Security Officer, I want the digital camera to be without any radio communication capabilities (e.g.

Bluetooth, WIFI), so that it can be taken into restricted/secured environments.

FEM-E6-NFR-1 The delivered digital camera must support removable storage media with sufficient capacity to capture the expected volume of evidence images during normal collection activities without requiring mid-activity offload.

FEM-6-BOM-1

The vendor shall provide a digital camera supporting removable storage media and shall include sufficient compatible removable storage media to support normal evidence photography activities, concurrent evidence collection activities, and continued operation without interruption to offload storage during evidence collection.

FEM-E7 Evidence Search and Retrieval Enable efficient and flexible search across all cases and evidence within the solution

FEM-E7-BA Allow analysts to rapidly locate and correlate, and validate case and evidence data across the entire dataset

FEM-US-7.1 As an Analyst, I want to search cases and evidence across the entire solution using standard criteria so that I can quickly locate relevant information

FEM-US-7.2 As an Analyst, I want to search using multiple and combined criteria across selected data sources so that I can refine the results

FEM-US-7.3 As an Analyst, I want to search using custom or extended attributes across the entire dataset so that I can query newly added or case-specific data fields

FEM-US-7.4 As an Analyst, I want to perform bulk searches across all data sources so that I can query multiple cases or identifiers at once

FEM-US-7.5 As an Analyst, I want to retrieve associated evidence for each case so that I can understand relationships quickly

FEM-US-7.6 As an Analyst, I want the system to explicitly identify missing results so that I can detect gaps or errors in my queries

FEM-US-7.7 As an Analyst, I want to optionally include RES and containerized data in searches so that I can balance completeness and performance

FEM-US-7.8 As an Analyst, I want visibility into search scope and progress so that I understand what data has been searched

FEM-E7-NFR-1 The system must return search results within 5 seconds for FEM/Case data under normal operating conditions

FEM-E7-NFR-2 The system must support searching across FEM/Cases data by default and allow optional inclusion of RES and containerized data where technically feasible

FEM-E7-NFR-3 The system must support searching within RES, compressed, and containerized data formats where supported and clearly identify when formats are unsupported

FEM-E7-NFR-4 The system should support bulk queries with large input sets (e.g. hundreds of identifiers) without significant degradation

FEM-E7-NFR-5 The system should allow attributes to be indexed and searchable without requiring system redesign

FEM-E7-NFR-6 The system must indicate selected search scope (e.g. RES included/excluded) and provide status for long-running searches

FEM-E7-NFR-7 The system should support indexing of both metadata and content for support formats and clearly report indexing limitations

Company Name Product / Platform / Service Product Version Primary point of contact Deployment models available SaaS / Private Cloud / On Prem / Etc.

Proposed Delivery Model Product / Manage Service / Product with Managed Service, etc.

Relevant Implementation Experience Similar Customers or use cases (if applicable)

Summary of recommended solution(s)

Respondent Information

This document includes data that shall not be disclosed outside NATO and shall not be duplicated, used, or disclosed – in whole or in part – for any purpose other than for NCIA internal evaluation purposes, unless otherwise expressly authorized by [insert company name]. This restriction does not limit the NCIA’s right to use information contained in this data without restriction if it is obtained from another source.

Statement of Confidentiality

Overall alignment with the attached User Stories Strong / Moderate / Limited / Other Summary of strongest areas of alignment Summary of weakest areas of alignment Areas likely to require configuration Areas likely to require customization Areas likely to require third-party integration Areas not supported General comments or assumptions

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Overall Fit

Please provide a short summary of the overall fit between the attached User Stories and your existing COTS / SaaS solution

Epic Overall Alignment Supported Natively Supported through Configuration Requires Customization Requires Integration Not Supported Prof Services Req Comments

MA-E1

MA-E2

MA-E3

MA-E4

MA-E5

MA-E7

Strong:

Moderate:

Limited:

Not Supported:

Capability is partially supported by may require configuration, integration, process adaptation , or limited services Capability is only partially supported and would require significant work or adaptation Capability is not supported by the proposed product, platform or service

Legend

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Capability is substantially supported by existing product or standard service capability

Respondents are requested to complete this section for each Epic or major capability area. Detailed User Story-level responses are only required in the next section where there is a gap, partial alignment, customization requirement, integration requirement, or recommended alternative.

Epic / Capability-Level Response Matrix

User Stories Issue Type Explanation / Concern Recommended Approach Rationale Expected Implementation Approach

MA-US-1.1

MA-US-1.2

MA-US-1.3

MA-US-1.4

MA-US-1.5

MA-US-1.6

MA-US-1.7

MA-US-1.8

MA-US-1.9

MA-US-1.10

MA-US-2.1

MA-US-2.2

MA-US-2.3

MA-US-2.4

MA-US-2.5

MA-US-2.6

MA-US-2.7

MA-US-2.8

MA-US-2.9

MA-US-3.1

MA-US-3.2

MA-US-3.3

MA-US-4.1

MA-US-4.2

MA-US-4.3

MA-US-5.1

MA-US-5.2

MA-US-5.3

MA-US-5.4

MA-US-5.5

MA-US-5.6

MA-US-5.7

MA-US-5.8

MA-US-6.1

MA-US-6.2

MA-US-6.3

MA-US-6.4

MA-US-7.1

MA-US-7.2

MA-US-7.3

MA-US-7.4

MA-NFR

MA-NFR-1

MA-NFR-3

MA-NFR-5

MA-NFR-6

MA-NFR-8

MA-NFR-9

MA-NFR-10

MA-NFR-11

MA-NFR-12

Respondents are requested to identify whether the recommended approach would be achieved through:

User Story-Level Exceptions, Gaps, Risks, and Recommended Changes

For each Epic marked as "Partial", "Requires Customization", "Requires Integration", "Requires Professional Services", or "Not Supported", respondents should complete the applicable portions in this section. This section should be completed only for User Stories that are not fully supported by existing COTS functionality, or where the respondent recommends a different approach.

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Recommended Capability Reason for Recommendation Typical Implementation Approach Relevant Product / Service Feature

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Recommended Additional Capabilities

Respondents should identify any industry-standard capabilities, workflows, or service features that are not reflected in the attached Epics and User Stories but should be considered by the Purchaser

Question Response Typical implementation duration for a comparable deployment Recommended implementation approach Recommended implementation phases Key Purchaser responsibilities during implementation Key Contractor responsibilities during implementation Common implementation risks and blockers Recommended training approach Knowledge transfer approach Data migration considerations Service transition considerations Upgrade and sustainment approach How the managed service would be monitored and reported (if applicable) How service quality, availability, and performance would typically be measured

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Implementation, Operation, and Sustainment

Respondents should describe how a comparable capability would typically be implemented, transitioned into service, operated, maintained, and upgraded. This should include key Purchaser responsibilities, key Contractor responsibilities, common dependencies, implementation risks, training considerations, and sustainment considerations

Capability configurable by Purchaser administrators Capabilities configurable by the Contractor as part of the managed service Changes requiring vendor professional services Changes requiring custom development Whether customizations are preserved during upgrades Available APIs Available connectors or integrations Import / Export mechanisms Common integrations for similar implementations Integration limitations or constraints Approach to maintaining integrations over time Approach to security testing or validation of integrations

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Configuration, Customization, and Integration

Respondents should describe which capabilities can typically be configured by the Purchaser or Contractor, which changes would require vendor professional services, which changes would require custom development, and how customizations or integrations are maintained through upgrades.

Respondents should also identify relevant APIs, connectors, import/export mechanisms, and integration patterns applicable to the proposed solution or service.

Typical licensing model Description of licensing model Minimum licensing quantities or term commitments Required modules, add-ons, or feature licenses Optional modules or add-ons Renewal model Support tiers available Software updates included Managed service costs included or separate Implementation costs included or separate Approach to maintaining integrations over time

Use or disclosure of data contained on this sheet is subject to the restriction on the cover page of this document

Licensing, Renewal, and Support Model

Respondents should describe the typical licensing, renewal, support, and service model for the proposed capability. This should include relevant licensing metrics, support tiers, software update arrangements, renewal model, optional modules or add-ons, and any separate costs for implementation, migration, training, integration, or sustainment.

Yes Not supported Strong No Partial Support Moderate Partial Requires Configuration Limited

Requires Customization Not Supported Requires Integration Recommend Alternative Requires Clarification Recoomment Revision Recommend Removal