2026 eDiscovery RFI.pdf

PDF 477 KB Posted

Attached to
eDiscovery review platform
Solicitation number
15DDHQ-26-RFI-FAIT02
Issued by

About this file

RFI Summary: DEA eDiscovery Review Platform

This is a Request for Information (RFI) issued by the Drug Enforcement Administration (DEA) to conduct market research on commercial eDiscovery review platforms intended to replace the agency's current Relativity-based case management system. The RFI number is 15DDHQ-26-RFI-FAIT02, with responses due no later than 10:00 AM Eastern on May 1, 2026. This RFI does not constitute a binding commitment and does not obligate the Government to reimburse proposal preparation costs or issue a subsequent RFP. Failure to respond may preclude participation in future acquisitions, as the market research will inform whether this effort is solicited as a small business set-aside, Fair Opportunity Exception, or standard competitive procurement.

The DEA seeks solutions supporting its entire eDiscovery workflow across the Electronic Discovery Reference Model (EDRM), including identification, preservation, collection, processing, review, analysis, and production of electronically stored information (ESI). Key requirements span 235 specific capability items addressing document collection and processing (56+ items), searching across vast datasets (48+ items), document review and analysis (80+ items), production formatting and delivery (50+ items), and reporting (1 item). The solution must handle up to 100 TB of data with 30% annual growth, support 9,000+ active custodians for legal holds, preserve evidentiary metadata, integrate with DEA systems including Microsoft Exchange, Teams, IMPACT case management, and SharePoint, and comply with Section 508 accessibility, FedRAMP High, FISMA, and CJIS security standards. The anticipated contract period is one base year with four one-year options. Vendors must demonstrate prior performance on similar-sized and complexity engagements while disclosing and mitigating organizational conflicts of interest per FAR Subpart 9.5, and must provide rough order of magnitude pricing for licensing, cloud/software costs, implementation labor, training, data migration, and AI-related expenses, identifying which costs align with the case management system and investigative ecosystem future states.

View the file

Other files

File Type Posted
2026 eDiscovery RFI Amendment 0001.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

15DDHQ-26-RFI-FAIT02

Department of Justice (DOJ) / (U) REQUEST FOR INFORMATION Drug Enforcement Administration (DEA)

REQUIREMENT NAME: eDiscovery review platform.

1.0 REQUEST FOR INFORMATION (RFI) PURPOSE AND DISLAIMERS

The Drug Enforcement Agency Administration (DEA) is issuing the following Request For Information (RFI) to obtain market research information related to DEA’s eDiscovery review platform.

This RFI does not constitute a Request for Proposal (RFP) and is not to be construed as a commitment by the Government. In accordance with the Federal Acquisition Regulation (FAR) Part 10 – Market Research and FAR 52.215-3, Request for Information or Soliciting for Planning Purposes (Oct 1997), please be advised that this is an RFI only, and does not obligate the Government to reimburse any cost associated with preparation and/or submission of a capabilities statement. This RFI neither guarantees that the Government will issue an RFP, nor that it will award a contract for these services.

This RFI may be used to determine an acquisition strategy for this requirement, and failure to respond to this RFI may preclude participation in any subsequent acquisition. For example, if the market research conducted via this RFI indicates that two or more small business entities are capable of performing the requirements, the effort may be solicited as a small business set aside, or if market research indicates only one vendor is capable, a Fair Opportunity Exception (FOE) may be requested. However, in no instance will a respondent’s capability statement be used as a proposal.

2.0 REQUEST FOR INFORMATION NUMBER: 15DDHQ-26-RFI-FAIT02

3.0 REQUIREMENT OVERVIEW

The digital age has brought about an unprecedented surge in the generation, collection, and storage of vast amounts of information. This presents both opportunities and challenges for the DEA. The proliferation of digital technologies, surveillance systems, social media platforms, and interconnected systems and databases empowers the DEA workforce with access to a wealth of information, opening new avenues for investigation, drug poisoning prevention, and strategic decision-making. However, the sheer volume and diversity of data also pose significant challenges in terms of extraction, standardization, analysis, interpretation, and visualization.

Adapting to this informational landscape will reshape how DEA operates and underscores the critical role of data in combating organized cartel structures. This shift also emphasizes the networked nature of the threat, offering opportunities to map, identify, and target networks through data, particularly as traditional investigative tools face growing limitations in the evolving landscape.

AREAS OF INTEREST: The requirements are subject but not limited to;

1. Commercial off the Shelf Case Management Systems

2. Case Management Tools and Customization

3. Reporting and Auditing (i.e., compliance with DEA investigative reporting policies)

4. Case and Task Management: Case/Investigation management to include document workflow and approvals

5. Data Sorting and Analytics

6. Criminal organization network Mapping

7. Cloud Migration: Technologies that can enhance our current infrastructure including hybrid approaches.

8. Security: Robust security measures safeguarding sensitive data and mitigating cybersecurity risks.

9. System Configuration: Integration capabilities with existing systems and platforms to ensure seamless transition and interoperability

10. System Integration

11. Federal Cybersecurity Compliance (e.g., FEDRAMP)

12. Enterprise solution supporting worldwide operations.

13. User-friendly interfaces and intuitive functionalities to enhance employee productivity and customer experience.

14. Ongoing support, maintenance services and enterprise training to ensure optimal performance and uptime.

15. Integration of geospatial and temporal analysis, visualization and AI.

16. Data migration strategy for existing legacy case management system (Relativity).

4.0 REFINEMENT OF REQUIREMENTS

DEA’s current Case Management environment: DEA currently uses Relativity for their eLitigation Investigative and Case Management needs. Relativity is a DEA system that is managed, operated, and maintained by DEA’s Information Systems Division (TC) in conjunction with the DEA’s Digital Evidence Lab (SFL9) eDiscovery Unit. In its current form and as installed, Relativity provides DEA personnel with the ability to ingest, review, analyze, produce and audit (compliant with DEA policy) DEA data and data produced to the DEA.

DEA’s Investigation Environment Future State:

Base Case Management System: DEA is assessing the capabilities of available law enforcement investigative case reporting, evidence tracking, and data management software to replace Relativity and augment current systems DEA utilizes to meet law enforcement, forensics, and drug related requirements. A case management system supporting DEA’s law enforcement community requires a web-based intuitive user-friendly interface (Section 508 compliance), the ability for document management (manage workflows, audit data input to ensure compliance

(i.e., DEA policy) and audit trail (e.g., time-stamped records, user ID tracking, role- and permission-based access control, etc.), be minimally customizable solution for agency specific needs, provide deconfliction capabilities, be capable of handling internal requests for ingestion, review, analysis, production, and presentation in conformance with the Electronic Discovery Reference Model (“EDRM”). The case management system should have the following technical requirements: integrate with other federal systems (e.g., APIs), ensure high levels of security and compliance (e.g., FedRAMP High, FISMA, CJIS, etc.), cloud-based or on-premises or hybrid deployment models, and user roles and permissions (e.g., RBAC and ABAC).

DEA Investigative Ecosystem: Further, DEA is assessing the possibility of a full DEA ecosystem with a combination of the base case management system (see above) and leverage existing capabilities to include the early parts of the EDRM, specifically identification, legal holds, and data preservation, structured and non-structured data search and analytics (i.e., analytics to identify patterns, trends, and intelligence), support for multilingual capabilities, and incorporate AI/ML capabilities. These would form a comprehensive and technologically advanced system meeting the diverse needs outlined for a DEA law enforcement platform.

5.0 ORGANIZATIONAL CONFLICT OF INTEREST INFORMATION

Organizational Conflict of Interest (OCI) for this RFI pertains to demonstrated compliance. As such, replies from industry partners interested in this opportunity must clearly demonstrate their understanding and strict compliance as this RFI pertains to FAR Subpart 9.5:

Contractors must strictly avoid any potential organizational conflict of interest (OCI), including the appearance of a perceived OCI condition, and/or prior existence of an OCI condition, by disclosing any potential conflicts to the contracting officer and taking steps to mitigate or avoid them, often by following FAR Subpart 9.5 which outlines procedures for identifying and managing OCIs; this includes situations where a contractor might gain an unfair competitive advantage through prior knowledge of government requirements due to previous work with the Drug Enforcement Administration.

Key points about OCI guidance for contractors are as follows:

• Disclosure is key: Contractors must actively disclose any potential conflicts of interest to the contracting officer, even if they seem minor.

• Avoid biased ground rules: A contractor should not be involved in developing specifications or requirements for a future contract where they intend to compete.

• Unequal access to information: If a contractor has access to sensitive government information that could give them an unfair advantage in a competition, they must manage that information appropriately.

• Mitigation strategies: If an OCI is identified, the contractor will need to demonstrate they have taken steps to mitigate the conflict, such as recusing personnel involved, creating information barriers, or modifying their proposal.

• Compliance with FAR Subpart 9.5: The DEA expects contractors to comply with the FAR Subpart 9.5 and all relevant supplemental guidance regarding organizational conflicts of interest, which outlines procedures for identifying, evaluating, and addressing potential conflicts.

In responses to the questions below, please provide past performance (contract number, government point of contact/telephone number/email) that accurately substantiates and supports your role as a contractor with performance similar in size and complexity to the DEA’s requirement. Past performance must be reported in a manner that shows Official Conflict of Interest (OCI) has been preserved.

6.0 PERIOD OF PERFORMANCE

The anticipated period of performance is one base year with four, one-year options.

7.0 RFI SUBMISSION INSTRUCTIONS

All eligible vendors are requested to submit their responses electronically NLT 10:00 am (eastern) 1 May 2026. Negative responses (not interested and/or not capable) are also requested.

All communications shall be submitted via email. Telephone calls with not be entertained. Please submit via email to fac.proposal.submission@dea.gov, robert.j.radke@dea.gov and lindsey.j.clark@dea.gov with the subject line: RFI Response:15DDHQ-26-RFI-FAIT02 -eDiscovery review platform..

Responses should be prepared in accordance with the vendor’s determined format. Vendors should respond to each item below. Vendors should limit their responses to no more than 50 pages total, 8.5 x 11 sheets, with font size no less than 12-point.

Responses are expected to be Unclassified. However, if certain pieces of information must exceed this level of classification, responses must be classified appropriately, must be portion marked, and sent electronically using the network appropriate to the information classification level. The overall classification should be marked at the top and bottom of each page. Vendors should include information on the Security Classification Guide (SCG) used to classify the document on the front page of the submittal. If submissions include proprietary information, such submissions must properly label that information and clearly indicate any limitations on its disclosure. The DEA will handle response information as sensitive and not share it outside of government evaluators, but it will not sign NDAs for RFI responses. Respondents are also requested to inform of any potential or actual OCI that may arise relevant to the subject matter in the RFI response. Please contact the RFI’s POCs to request email addresses/delivery instruction for information that is higher than Unclassified.

Vendors who are capable and interested in this opportunity are requested to respond to all sections below.

NOTE: The Contractor MUST overtly demonstrate experience, technical knowledge, and Past Performance in all listed competence areas.

mailto:fac.proposal.submission@dea.gov mailto:robert.j.radke@dea.gov mailto:lindsey.j.clark@dea.gov

8.0 REQUEST FOR INFORMATION:

1. (U) COMPANY INFORMATION:

COMPANY NAME: CAGE CODE:

POC(NAME/PHONE/EMAIL): UEI:

2. WHAT IS YOUR COMPANY’S SOCIOECONOMIC STATUS UNDER NAICS 541611

SMALL (please specify type) LARGE

3. WHAT IS YOUR COMPANY’S SOCIOECONOMIC STATUS UNDER NAICS 541330

SMALL (please specify type) LARGE

4. IS YOUR COMPANY CAPABLE/INTERESTED IN THIS OPPORTUNITY?

Yes / No (If no, any information regarding why you are not interested/capable is appreciated.

If yes, please proceed to 5. CAPABILITIES)

5. CAPABILITIES

Item Section EDRM

Model Requirement Description

1 General Security and Access

All EDRM Stages

Any changes to data must be traceable and reportable

Any changes to data must be traceable and reportable so that DEA can determine what changes were made throughout the EDRM process and report on ESI discovery and disclosure efforts as well as for chain of custody issues

2 General Security and Access

All EDRM Stages

Establishing Electronically Stored Information Disclosure and Discovery

(“ESIDD”)

databases

The delivered solution must allow for establishment of ESIDD databases for each case or cases as necessary

3 General Security and Access

All EDRM Stages

Handle large ESI data

The delivered solution must be capable of holding and maintaining up to 100 TB of data (DEA databases, images, native documents) with growth of approximately 30% per year. If vendor faces a maximum storage capability, vendor must state that maximum.

4 General Security and Access

All EDRM Stages

Preserving Evidentiary Metadata Throughout the EDRM

The delivered solution must preserve evidentiary metadata throughout all stages of ESI Disclosure & Discovery and all EDRM stages, including at a minimum the information commonly contained in a Load File (e.g. Concordance Load File) including, but not limited to:

collection source, mime type, source ID, custodian, author, begdoc#, enddoc#, docid (eid), pgcount, groupid, parentid, attachids, attachlist, begattach, endattach, properties, record type, from, to, cc, bcc, subject, convindex, docdate, text filepath, date time sent, date time crtd, date time svd, date time mod, date time recvd, date time accd, file size, file name, application, file extension, filepath, native link, folder id, paragraph request number, md5 hash, message header, attach, count, file type, comments, message type, extended properties, and generate conversation / message threading index regardless of platform.

5 General Security and Access

All EDRM Stages

Compliance

The delivered solution shall require that the Contractor comply with requirements of section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794(d) throughout its performance of the contract.

6 General Security and Access

All EDRM Stages

Access through DEA network, VDI, or VPN

The delivered solution shall have the capability to allow the user to use all aspects of the delivered solution through the DEA network, or remotely over a VPN connection or a VDI connection.

7 General Security and Access

All EDRM Stages

Access through single application

The delivered solution shall consist of a single application requiring one login to perform all functions. The delivered solution's administrative interface may be a separate application.

8 General Security and Access

All EDRM Stages

Access with

DOJ PIV

and/or CAC

The delivered solution shall have the capability to validate users with Smart Card technology, specifically DOJ PIV and/or CAC authentication

9 General Security and Access

All EDRM Stages

Access controlled/ role-based

The delivered solution shall have the capability to limit/grant access to certain functionality by Role Based Access Controls (RBAC).

10 General Security and Access

All EDRM Stages

Access controlled/ role-based

The delivered solution shall provide standard roles and allow the creation of additional roles. Access must be tailorable at the named resource level.

11 General Security and Access

All EDRM Stages

Accessible for use for all of DEA's Electronically Stored Information

(ESI)

Disclosure & Discovery

The delivered solution shall be capable of supporting all of DEA's ESI Disclosure & Discovery needs including, but not limited to all phases of the Electronic Discovery Reference Model (EDRM), Freedom of Information Act (FOIA) requests, internal and external investigations, congressional inquiries, and privacy act requirements.

12 General Security and Access

All EDRM Stages

Collaboration, Case Management and Tracking

The delivered solution shall include Case Management and Tracking and shall allow legal and access professionals the ability to collaborate in the processing of each ESI Disclosure & Discovery case.

13 General Security and Access

All EDRM Stages

Coordinate secure remote sharing

The delivered solution shall have a collaborative and private access ability (e.g. secure remote sharing of data with other agencies and expert witnesses), with access capabilities restricted to view only and as defined by the user granting the access.

14 General

Access

All EDRM Stages

Preliminary Design Document

Provides a detailed description of the delivered solution design for the pilot phase, as well as a detailed breakout of the functional design. Addresses issues such as, interfaces with other delivered solutions and hardware considerations.

15 General Security and Access

All EDRM Stages

Preliminary Design Document

The Design Document shall include, at a minimum:

- Requirements reference;

- Use Case reference;

- Delivered solution architecture;

- Relationship diagram(s);

- Detailed functional hierarchy;

- Logical and physical schemas and data-flow diagrams;

- Module design and program specifications;

- Screen mock-ups;

- Delivered solution sizing specifications related to the delivered solution architecture including database and file utilization specifications;

- Performance expectations; and

- Back-up/recovery plan

16 General Security and Access

All EDRM Stages

Security Does the software have an existing ATO with any DOJ Component? If not, is the software able to obtain an ATO under the current Risk Management Framework (RMF) requirements under DOJ 8500 and NIST RMF Requirements?

17 General Security and Access

All EDRM Stages

The delivered solution must be compatible information technology used by DEA

The delivered solution shall be capable of receiving ESI collected from information technology used by DEA, including, but not limited to virtual infrastructure (e.g. VDI), laptops, servers, tablets, smart phones, and cloud services (e.g.

software as a service (SaaS), infrastructure as a service (IaaS), platform as a service (PaaS)).

18 General

Access

All EDRM Stages

The delivered solution must be compatible with all major DEA systems

The delivered solution shall be compatible with and capable of collecting and importing ESI from major DEA systems and applications, including but not limited to all Outlook ESI (e.g., email, calendar, tasks, notes. etc.…), Instant messaging (e.g. Microsoft Teams, Skype), All network drives (e.g.

share drives and home directories), Various types of documents and file types including Microsoft Office documents (e.g., .msg, .doc .docx, .xls, .xlsx, .ppt, .pptx), Adobe documents (e.g. .pdf or Adobe portfolio, including embedded documents) and other document types (e.g. zip, CAD), Microsoft Visio, Microsoft Office 365, and systems, including, but not limited to, Microsoft Teams, DEA’s case management system (“IMPACT”), and SharePoint

19 Capacity and Legal Hold

Identification, Preservation, & Collection

Import ESI data from applications as they are added to DEA's infrastructure

The delivered solution must permit the import of ESI data from all major DEA systems and applications, including but not limited to email, resident hard drives, share drives, the cloud, the Enterprise Business System, Teams, IMPACT, and others as added to DEA’s approved software and hardware list.

20 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall have the capacity to import from a potential 9,000 accounts from Microsoft Active Directory as potential Legal Hold Custodians.

21 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall have the capacity to manage at least <<9,000>> active custodians

22 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall have the capacity for DEA personnel to manage legal holds

23 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide the user with options to view and track the legal hold status

24 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide the user with options to capture information like legal hold name, attorneys or access professionals assigned (for approval purposes), list of associated matters, list of recipients (which includes custodians and non-custodial data sources (“NCDS”)), date and time the hold is issued, name of the user issuing the hold, effective date range of the hold, date created, date approved, date sent, date acknowledged, date released etc. for each legal hold

25 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide the user with options to create legal hold notice templates for future use

26 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide the user with options to design a notice for each of the hold operations (Issue, Resend, Escalate, Reissue)

27 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user to attach a legal hold issue notice along with other notices to a legal hold

28 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow applicable legal team resources to select entire groups or departments for legal hold notice distribution

29 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user the capability to issue, send, and track all legal holds by custodian

30 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user the capability to track all legal holds by non-custodial data sources (NCDS) such as email systems

31 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user to upload and associate documents relevant to a particular legal hold

32 Capacity

Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall support the capability to collect legal hold status metrics such as counts of legal holds, number of custodians, custodians who have acknowledge receipts, count of holds released, actions taken by custodian, etc.

(detailed metrics TBD)

33 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide ability to display snapshot/dashboard of high-level metrics for each legal hold such as number of custodians/data stewards who have acknowledged the receipt of hold notice, number of custodians/data stewards who have not acknowledged the receipt of the hold notice, number of custodians/data stewards released from the legal hold

34 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall restrict the users from viewing and/or editing a legal hold that has already been issued

35 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall permit re-issuing legal holds only to active and newly added custodians

36 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall support dynamic text inserts in the legal hold notice

37 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow a custodian or data steward to ask/send questions to legal team

38 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall support scheduling, conducting and tracking of multiple interviews per custodian/data steward in a hold.

Ideally, the system will help set up automated reminders for record custodians and their supervisors

39 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow import of legal holds and matters (information and data) from third party eDiscovery and ESI Disclosure & Discovery solutions. This includes, but is not limited to: Microsoft “e-discovery” solutions (e.g. Office 365 and Microsoft Exchange Online) and inputs from other non-DEA entities in industry standard formats (e.g.

load files).

40 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall provide the user with options to notify appropriate members when a custodian/data steward information changes (location, employment status).

41 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow litigation team members to manually send alerts/notifications to supervisors and to receive acknowledgment within the delivered solution.

42 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user to send email notifications based on role types and receive acknowledgment within the delivered solution.

43 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user to customize the reminders schedule

44 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold The delivered solution shall allow the user to set reminders for resending or escalating holds for non-compliant custodians

45 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold System shall allow the user to send litigation notices to external resources, including outside counsel, vendors and contractors

46 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Capability to deliver all Litigation notices via E-mail to any agency employee.

47 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Capability to create Litigation Hold and Release Templates and the ability to customize the Hold Notice language.

48 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Litigation Holds/Releases/Surveys shall be digitally signed by the custodian and stored in the system.

49 Capacity

Hold

Identification, Preservation, & Collection

Legal Hold Automatically E-mail reminders to continue to retain documents for litigation purposes on a customizable periodic basis.

50 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Automatically E-mail reminders to custodians that have not signed a Litigation Hold Notice on a customizable periodic basis.

51 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Send E-mail users a notice when a Litigation Hold has been removed, they no longer need to retain Email for litigation purposes.

52 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Automatically email a copy of the signed notice to the custodian upon completion of the notice.

53 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Capability to perform Custodian Surveys and to customize the survey form.

54 Capacity and Legal Hold

Identification, Preservation, & Collection

Legal Hold Capability to display, by matter and on a single screen for the end user, important information on the status of each litigation hold notice including the identity of the custodian, the date of the hold notice, whether and when the custodian signed the hold notice, and date information on upcoming reminder or follow up notices.

55 Capacity and Legal Hold

Identification, Preservation, & Collection

User Capacity The delivered solution shall have the capacity to allow a specified number of concurrent users and an unlimited number of named users.

56 Document Collection

Collection & Processing

Document types

The delivered solution shall have the capability to import the following document types at a minimum:

- Microsoft PST files

- Loose emails in .msg format

- Microsoft Office documents such as:

- Word processing documents (e.g., .doc);

- Microsoft Teams data

- Spreadsheets (e.g., .xls);

- Presentation program files (e.g., .ppt);

- Visio documents

- notetaking files (e.g., Microsoft One Note);

- Adobe files (e.g. pdf, Adobe archive, and files embedded in Adobe files)

- SharePoint

- WordPerfect documents

- Web Pages

- Pictures

- Zip Files and their contents

- CAD files

- Common video formats (e.g.

MPEG, MOV, MP4, WMV, FLV,

AVI, ASF, QT, SWF, 3GP, WMA,

OGG, AAC)

57 Document Collection

Collection & Processing

Integrity Checks

The delivered solution shall incorporate the following automated, DEA-specific, integrity checks during the data loading process:

- For productions that include native files, the delivered solution shall verify that the native file exists at the path specified by the native file link in the database upon completion of data load.

- For productions that include native files, the delivered solution shall report any file paths that exceed 217 characters for Microsoft Excel files and 255 characters for all other file types.

- For all types of productions, the delivered solution shall validate date fields within the database and report the bad date records in an exception file.

- For delimited text file productions, the delivered solution shall read and store time and time zone values from separate fields or combined date and time fields. If no time zone information is provided, the system shall allow an administrator to set an assumed time zone value.

- For delimited text file productions, the delivered solution shall check consistency of zero padding in Bates number fields.

58 Document Collection

Collection & Processing

Integrity Checks

The delivered solution shall examine the Bates format(s) in a case and report the alphabetic prefix(es) and the number of digits for the numeric portion of the Bates number.

- Load files should conform to ANSI, UTF-8, UTF-16LE, and UTF-BE (UTF-32) standards

59 Document Collection

Collection & Processing

NIST Filtering The delivered solution shall have the capability to filter out system documents (NIST Filtering).

60 Document Collection

Collection & Processing

Statistics The delivered solution shall store statistics upon data load such as document types, the number of documents in the repository, the date documents were loaded, and shall provide the ability to generate a report on those statistics.

61 Document Collection

Collection & Processing

Statistics Upon data load, the delivered solution shall store statistics such as the number of emails and the number of attachments loaded and shall be able to generate a report on those statistics.

62 Document Collection

Collection, Processing, Review & Analysis

Adding data to a case while a case is in use

The delivered solution shall be capable of adding new data to a case while users are accessing and using the case.

63 Document

Collection, Processing, Review & Analysis

Custom fields in database

The delivered solution shall allow an unlimited number of custom fields in the database. The vendor must describe the limits or constraints.

64 Document Collection

Collection, Processing, Review & Analysis

Data dictionary The delivered solution shall provide a data dictionary built from all data loaded into the case (including word counts).

65 Document Collection

Collection, Processing, Review & Analysis

Data dictionary The delivered solution shall provide the user the ability to view the data dictionary.

66 Document Collection

Collection, Processing, Review & Analysis

Hidden Columns

The delivered solution shall identify documents with hidden columns by marking the documents in a field in the database.

67 Document Collection

Collection, Processing, Review & Analysis

Hidden Rows The delivered solution shall identify documents with hidden rows/columns by marking the documents in a field in the database.

68 Document Collection

Collection, Processing, Review & Analysis

Hidden Text The delivered solution shall identify documents with hidden text by marking the documents in a field in the database. An example of hidden text is font text identical to the background, typically white on white.

69 Document Collection

Collection, Processing, Review & Analysis

Moving between datasets

The delivered solution shall be capable of moving records from one dataset to another dataset that has a different field structure.

70 Document Collection

Collection, Processing, Review & Analysis

Normalizing data fields

The delivered solution shall load new data to a case with different fields than data previously loaded to the case and normalize the fields to DEA standard field names and field types.

71 Document Collection

Collection, Processing, Review & Analysis

Overlay data capabilities

The delivered solution shall overlay data into a case. For example, an outside party produces an EDRM XML collection that contains bad dates. The DEA requests the outside party to provide a corrected version, but in the interim, the end-user wants to review/tag the documents. When the corrected data is redelivered, the data will overlay the existing data using a unique record identifier to match the new data to the correct records.

72 Document Collection

Collection, Processing, Review & Analysis

Overlay data capabilities

The delivered solution shall automatically run processes to populate fields during a bulk overlay that were run in the initial data loading.

73 Document Collection

Collection, Processing, Review & Analysis

Removing data from a case while case in use

The delivered solution shall be capable of removing documents from a case while users are accessing and using the case.

74 Document Collection

Collection, Processing, Review & Analysis

Tracked changes documents

The delivered solution shall identify documents with tracked changes by marking the documents in a field in the database.

75 Document Collection

Collection, Processing, Review & Analysis

Foreign language identification

The delivered solution shall identify foreign language documents by marking the documents in a field in the database.

76 Document Collection

Processing Allow auto-decryption

The delivered solution shall permit the import of passwords and private keys for automatic decryption. The software should also make use of a password bank that can unlock documents without altering metadata and allow for the reprocessing of the decrypted archive while maintaining the preexisting tree/evidence structure

77 Document Collection

Processing Audio and video files

The delivered solution shall load audio files (e.g. voicemail, .wav, .mp3), video files and associated meta data.

78 Document Collection

Processing Capturing folder names

The delivered solution shall process data files according to information provided in the structure of folder names (e.g., CASE# | Company-Firm | Custodian | Production Date) and shall capture information from the different levels of the folder structure into different fields in the database.

79 Document

Processing Conversion to readable formats - Automatic

OCR

The delivered solution shall have the capability to automatically OCR non-text-based documents when they are imported and to generate an exception handling report or log file for documents or ESI that cannot be automatically converted to OCR.

80 Document Collection

Processing Conversion to readable formats -compound files

The delivered solution shall have the ability to load native files, including email stores, loose files, PDF files, and compressed archive files (e.g., .zip, .rar, .L01, E01, AD1), and shall have the ability to extract all files from compound files and create a separate record for each extracted file (e.g., .zip, .rar, .L01, E01, AD1). The application shall not include the original compound file as a document.

81 Document Collection

Processing Delimited text files

The delivered solution shall load delimited text file with specific delimiters and field order, and image cross-referenced files and JPG files.

82 Document Collection

Processing Delimited text files

The delivered solution shall load delimited text file with specific delimiters and field order, image cross-referenced files, single or multi-page OCR text files and TIFF or PDF files.

83 Document Collection

Processing EDRM XML load files

The delivered solution shall load EDRM XML load files.

84 Document Collection

Processing E-mail files from a wide variety of formats

The delivered solution shall load email files from a wide variety of formats, such as, PST, MSG, EML and DBX.

85 Document Collection

Processing E-mail Header Information

The delivered solution shall extract and load all email header information (e.g. IP addresses)

86 Document Collection

Processing Extract metadata

The delivered shall extract metadata values during the data loading process and load the metadata into fields in the application without modifying the original document or changing system and document metadata values.

87 Document Collection

Processing Extract text The delivered solution shall extract text from all native files, including email messages and attachments, during the data loading process and load all text in a field.

88 Document Collection

Processing Extracting embedded metadata in pdf portfolios

The delivered solution shall extract embedded metadata for each document contained in a PDF portfolio file during the data loading process.

89 Document Collection

Processing Extracting metadata from native files

The delivered solution shall extract metadata from each native file and load it into searchable fields during the data loading process.

90 Document Collection

Processing Hash values The delivered solution shall provide MD5, SHA-1, and SHA-256 hash value(s) in a field for native documents loaded.

91 Document Collection

Processing Identify un-processable Files, Including Encrypted Files

The delivered solution shall identify any un-processable files in an exception handling report or a log file during the data loading process with the reason why the file could not be processed. Examples of reasons are corrupted, password protected, encrypted, unsupported file type, path too long (e.g., file path exceed 217 characters for Microsoft Excel files or 255 characters for other file types).

92 Document Collection

Processing Load native and text files with varying encoding

The delivered solution shall load native and text files with varying encoding, such as, ASCII, UTF-8.

UTF-16, UTF-32

93 Document Collection

Processing Load native files from all levels of a folder structure

The delivered solution shall load native files from all levels in a folder structure.

94 Document Collection

Processing Load report for loaded productions

The delivered solution shall provide a load report for all loaded productions including the number of documents, number of pages, date loaded, request/production identifier, exception files, and unsupported files.

95 Document Collection

Processing Loading extracted OCR text

The delivered solution shall load extracted and OCR text into fields without limitations due to the size of the text.

96 Document Collection

Processing Problem file report

The delivered solution shall for all exceptions in the data loading process, provide a problem file report, including the file name and path of the document and description of the problem. For example:

corrupted, encrypted password protected, unsupported file type, path too long (file path exceeds 217 characters for Microsoft Excel files and 255 characters for all other file types).

97 Document Collection

Processing Records for exception files

The delivered solution shall create an exception handling report or log file for exception files (e.g., non-supported, corrupted, password protected, encrypted) and include an exception field describing the problem; extract meta data available from the exception file and store it in fields; store a link to the exception file.

98 Document Collection

Processing Separate records based on size of embedded or attached file

The delivered solution shall be configured to create or not create separate records for embedded and attached objects based on the size (in KB) of the embedded or attached object.

99 Document Collection

Processing Separate records based on type or MIME type of embedded or attached file

The delivered solution shall be configured to create or not create separate records for embedded and attached files based on the file type or MIME type of the embedded or attached file.

100 Document Collection

Processing Separate records for each native file

The delivered solution shall create a separate record for each native file during the data loading process. For example, separate records are created for an email and each attachment to the email.

101 Document Collection

Processing Structured & Conceptual Analytics

The delivered solution should process and load files so as to allow all files to be used in analytical processes, including but not limited to:

- Text searching,

- Concept searching,

- Data and file clustering,

- Categorization of documents,

- Technology Assisted Review (TAR), Continuous Active Learning

(CAL),

- Email threading analysis and view,

- Textual near duplicate analysis,

- Repeated content analysis,

- Language identification analysis

102 Document Collection

Processing Text Messages and Instant Messages

The delivered solution shall load short messages (SMS), including cellular text messages, online instant and chat messages, and social media messages (e.g., tweets).

103 Document Collection

Processing Tiff or PDF Images and Bates endorsement

The delivered solution shall load all native ESI, create single page tagged image file format (TIFF) images or portable document format (PDF) files for each page, and apply Bates endorsement to documents upon loading, which should not cover any original document content

104 Document Collection

Processing TIFF or PDF placeholder

For all exception files loaded, the delivered solution shall create and indicate the problem on the TIFF or PDF placeholder image, allow configurable fielded information to be written on the image, and load the problem description in a field in the database.

105 Document Collection

Processing Uniquely number and hash native files

The delivered solution shall uniquely number and create hash values for native files, email messages, and attachments during the data loading process and store the unique number and value in a field.

106 Document

Processing, Review & analysis

De-duplication & Near- Deduplication Percentages

The delivered solution shall determine the extent of similarity between files and assign a percentage of similarity.

107 Document Collection

Processing, Review & analysis

De-duplication & Near- Deduplication Percentages

The delivered solution shall allow administrators to set a threshold for considering documents near duplicates, such as 85% similar or 90% similar.

108 Document Collection

Processing, Review & analysis

De-duplication with new and prior data

After loading new data into the delivered solution, users shall have the option to de-duplicate newly added data against previously loaded data using MD5 or SHA.

109 Document Collection

Processing, Review & analysis

De-duplication with new and prior data

The delivered solution must be able to use the MD5 or SHA algorithm to assign unique hash values to newly processed files and compare them to previously hashed and loaded records for the purpose of segregating and/or removing files with identical hash values. De-duplication should allow for the enrichment of the files that were de-duplicated against so that all metadata is preserved

110 Document Collection

Processing, Review & analysis

Identifying near duplicates

The delivered solution shall identify exact and near duplicates. Near duplicates are electronic files with similarities in content, metadata, or both (e.g. document versions, emails sent to multiple custodians, different parts of email chains, or similar proposals sent to several clients).

111 Document Collection

Processing, Review & analysis

Parent/Child The delivered solution shall maintain parent/child relationships between emails and attachments when loading email files. If conceptual and Boolean searching are both provided, the delivered solution shall allow the user to set either as their default search type.

112 Document Searches

Identification, Review & Analysis

Ability to choose between conceptual and

The delivered solution shall identify concepts - words and phrases with similar meanings in context - across all productions for a case and present

Boolean searches the most frequently occurring concepts to users as search options.

113 Document Searches

Identification, Review & Analysis

Concept searching

The delivered solution shall be able to search for a concept entered by a user.

114 Document Searches

Identification, Review & Analysis

Concept searching exclusion

The delivered solution shall allow an administrator to exclude repeated text from concept searching, such as a disclaimer at the end of every email in a production.

115 Document Searches

Identification, Review & Analysis

Fuzzy searching

The delivered solution shall provide compensating search functions to help reduce the impact of low Optical Character Recognition (OCR) confidence levels (e.g. fuzzy searching).

116 Document Searches

Identification, Review & Analysis

Hit highlighting

The delivered solution shall highlight terms in the all files that met the search criteria (Hit Highlighting)

117 Document Searches

Identification, Review & Analysis

Identify and review e-mail discussion threads

The delivered solution shall have the capability to identify and review E-mail discussion threads.

118 Document Searches

Identification, Review & Analysis

Near duplicates

The delivered solution shall have the capability to identify near duplicates.

119 Document Searches

Identification, Review & Analysis

Option to include attachments in searches

The delivered solution shall have the capability to return searches for emails with the option to either include or not include associated attachments regardless of search criteria specified for the email itself.

120 Document Searches

Identification, Review & Analysis

Predictive Coding and searching

When a set of documents is selected from searching, the delivered solution shall be able to execute a follow-up query that will present more documents like the selected ones (predictive coding or technology assisted review).

121 Document Searches

Identification, Review & Analysis

Preview in search results

The delivered solution shall have the capability to ‘preview’ E-mails in a search result set. The user should not have to ‘open’ an E-mail to make a quick assessment of the relevance of a document. This functionality can be a preview pane (similar to the Microsoft Outlook preview pane) or by other means such as a balloon appearing when the user hovers the mouse over an E-mail.

122 Document Searches

Identification, Review & Analysis

Save searches The delivered solution shall have the capability to save search criteria and results including ability to further refine a search.

123 Document Searches

Identification, Review & Analysis

Schedule searching

The delivered solution shall have the capability to schedule searches.

Results added to a case as a result of a schedule search shall be distinguishable from existing search results.

124 Document Searches

Identification, Review & Analysis

Search accuracy and repeatability

The delivered solution shall reliably search a dataset. Running the same search against the same documents more than once shall return the same results.

125 Document Searches

Identification, Review & Analysis

Search by document identifier

The delivered solution shall provide the ability to navigate to a specific Bates number, record number or document identifier (UUID/GUID) during document search.

126 Document Searches

Identification, Review & Analysis

Search by document

The delivered solution shall be able to search for application assigned Bates and document numbers, and Bates and document numbers provided by the producing party.

127 Document Searches

Identification, Review & Analysis

Identifier by application assigned Bates

The delivered solution shall be able to search for all documents with application assigned Bates/document numbers in a given range.

128 Document Searches

Identification, Review & Analysis

Search by document identifier by producing party

The delivered solution shall be able to search for all documents with a producing party provided Bates/document numbers in a given range.

129 Document Searches

Identification, Review & Analysis

Search by field and field exclusion

The delivered solution shall be able to search for a term in a specific field, while excluding occurrences of the term in all other fields.

130 Document Searches

Identification, Review & Analysis

Search by prefix

The delivered solution shall be able to search for all documents with a specific prefix.

131 Document Searches

Identification, Review & Analysis

Search notifications

The delivered solution shall provide email notifications when new documents are added to the delivered solution that meet pre-established search criteria. The delivered solution will enable the user to turn notifications on or off.

132 Document Searches

Identification, Review & Analysis

Search segregation

The delivered solution shall place a new document that meets preestablished search criteria in a folder for review.

133 Document Searches

Identification, Review & Analysis

Search Options with Attachments

The delivered solution shall provide clear, direct access to/from parent emails in an e-mail chain as well as their attachments.

134 Document Searches

Identification, Review & Analysis

Search sorting The delivered solution shall allow the user to show or hide search results (e.g., domains, file types).

135 Document Searches

Identification, Review & Analysis

Search variations

The delivered solution shall search automatically on variations of search terms (tense, inflection, plurals, etc.)

and provide the user with the ability to turn this function on or off. This functionality shall be available with conceptual and Boolean searching.

136 Document Searches

Identification, Review & Analysis

Search within a search

The delivered solution shall be capable of searching within a search (nested searches) as a user selected option.

137 Document Searches

Identification, Review & Analysis

Searching across all cases and documents

The delivered solution shall search across all cases (tens of thousands of document productions and hundreds of millions of documents). The vendor must explain if additional hardware or software is needed to achieve this.

138 Document Searches

Identi…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .