The EAC will use each manufacturer's quality assurance system and its internal procedures for controlling changes to, and versions of, it's voting systems when determining when a voting system is a "new" system.

Tight project schedules and other realities of voting system testing and certification have generally made manufacturers choose to move forward with “at risk” testing performed well before test plan approval. This reality conflicts with the requirement that the VSTL inform the EAC in writing once test cases have been completed. The EAC has generally not seen test cases until after test plan approval, even for "at risk" testing that may have occurred much earlier. In order to remedy this situation and to allow the EAC to more productively and appropriately comment on test cases before they have been run, the following clarification is noted: require the VSTLs to notify the EAC in writing and to upload test cases to the VRT when requested by the EAC before any tests have been run using the particular test case or test cases. This process will allow EAC to review test cases proximate to when they will be run and will hopefully eliminate any issues arising from after-the-fact test case review that might cause meaningful and potentially harmful delays in the testing and ultimate certification of the voting system

Based upon VSTL feedback and recommendations, EAC shall receive Virtual Machines (appliances) from the VSTL for the trusted build. Trusted builds shall include this virtual machine and any related items, so that the system can be constructed or restored on another machine. Trusted builds shall be in the Open Virtualization Format (OVF)

The initial practical application of the TRR process has lead the EAC to conclude that one item needs to be modified in the TRR in order to achieve the stated purpose of this program requirement. In order to be truly ready for testing, a voting system must be able to do substantially more than simply read a fully filled square or oval for optical scan systems.

There is a discrepancy between the VSTL manual and the Cert manual that requires clarification. The statement in question (“The TRR does not apply to modifications.”) is in the VSTL manual and was overlooked during the revision and editing of the manuals.  The TRR applies to applications to test full systems and modifications.  Additionally, if the application is for a system modification, the VSTL is responsible for reviewing no less than 1% of code that has changed in every software package, module or product.

This NOC outlines the process under which the EAC, VSTL and voting system manufacturer can come to a mutually acceptable agreement regarding the testing of any new technology that is submitted for certification under the extensions clause of the VVSG and Section 3.2.2.4 of the Program Manual - via TTA meetings (as detailed in this NOC).

This notice of clarification is to clarify the information needed to describe changes to a system accepted in to the testing and certification program as a modification. In addition to the general description currently given as part of the system overview for modifications, each Test Plan and Test Report must include a detailed listing of all the changes made to the modified system. This can be included in the body of the Test Plan and Test Report (if it is a small number of changes); or referred to in the system overview and included as an Appendix (if it is a large number of changes). The detailed description shall include: name of component and/or module, version number and brief description of the change.

This notice of clarification is to clarify the way discrepancies are listed in the Test Report. Discrepancies noted during testing shall be entered in the test report as individual occurrences, not batched based on test case or component. The only discrepancies that may be batched or grouped are source code discrepancies and TDP discrepancies. In addition, even though source code TDP discrepancies may be batched or grouped, the number of occurrences of each identified discrepancy must be tallied and the total number noted in the section for that batch (i.e. source code or TDP).

System validation is an extremely important pre-election and post-election activity. The system identification tools required by the manual are intended for Federal, State, and local officials to identify and verify that the equipment used in elections is unmodified from its EAC certified version.

The replacement of certain obsolete or end-of-life COTS components in an EAC certified voting system with equivalent components is permitted. Using the process outlined above, the equivalence of the replacement components can be demonstrated and be considered for a de minimis classification provided the change meets the requirements of section 3.5 of the EAC’s Program Manual and this clarification. The EAC will continue to monitor the use of COTS products in voting systems and make appropriate changes to its procedures in instances in which it sees minimal risk to voting system integrity and potential cost savings.