How do organisations implement Voluntary Voting Systems Guidelines (VVSG)?

What VVSG implementation looks like in practice

Voluntary Voting Systems Guidelines are not implemented as a single control deployment. Organisations implement them by treating the guidelines as a procurement, certification, operations, and assurance baseline. That means the system has to be selected against the guideline set, tested through the relevant election authority process, then operated in a way that preserves the certified state rather than drifting away from it after installation.

The practical question is whether the voting system in use is the same system that was evaluated and approved. That requires configuration discipline, version control, and change approval for software, firmware, ballot definitions, and supporting components. If election staff can alter the system outside the approved path, the organisation may still “have” a certified product on paper while operating something materially different in the field.

How procurement, testing, and certification fit together

VVSG implementation usually starts before purchase, because the procurement process should specify which requirements the system must satisfy and how evidence of conformance will be produced. Organisations then need a test and certification path that demonstrates the system meets the applicable guideline requirements under the authority that certifies it. That process is not just a vendor exercise; the election operator has to understand what was tested, what assumptions were made, and what deployment conditions were part of the approved configuration.

After certification, the real control point is deployment discipline. A system that passes testing can still become noncompliant if it is installed with unapproved components, unsupported peripherals, altered settings, or untracked updates. The strongest programmes treat certification artefacts, configuration baselines, and deployment records as operational evidence, not as one-time paperwork.

For teams that need implementation guidance on governance and control discipline, the broader security control logic behind this approach aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls and the operational control themes in NIST Cybersecurity Framework 2.0.

What keeps a voting system within approved bounds

Once deployed, VVSG implementation depends on preserving integrity across the election lifecycle. Chain of custody matters for devices, media, ballots, keys, and evidence because the trust model assumes that what is used in voting and tallying is the same material that was secured, tested, and approved. Auditability matters because an election authority must be able to reconstruct what happened if there is a question about configuration, operation, or results. Accessibility matters because compliance is not complete if eligible voters cannot reliably use the system as intended.

Operationally, that means organisations need clear ownership for who can touch the system, when maintenance can occur, how exceptions are recorded, and how incident response is triggered. If a device is replaced, a patch is applied, or a setting is changed, the organisation should be able to show that the new state remains approved or that it has been revalidated before use.

Practical implementation is easier when teams treat logging, review, and tamper evidence as part of the voting control environment. The implementation discipline is similar to the way NIST SP 800-88 Media Sanitization treats custody and disposition: the important issue is not only the asset, but whether its handling history remains defensible throughout its lifecycle.

Risk and Threat Considerations

VVSG implementation fails most often when an organisation assumes certification alone is enough. The main risks are configuration drift, uncontrolled maintenance, weak custody over removable media or devices, and gaps in audit evidence that make it impossible to prove the deployed system stayed within approved bounds. Those weaknesses matter because election systems are high trust environments, and even small deviations can create disputes about integrity or accessibility.

Failure mechanism: A system can be certified in one configuration and later operate in another because changes were applied without strict control, or because the organisation cannot demonstrate what changed, when it changed, and who approved it.

Impact: The election operator may lose confidence in the result, be forced into costly revalidation or investigation, or expose the election to claims that the deployed system no longer matched the approved design.

Practitioner Guidance

What to verify: Confirm that the certified configuration, fielded configuration, and audit records all match, including software versions, device inventory, ballot definitions, and maintenance history. If those three views do not reconcile, treat the deployment as unresolved until the discrepancy is explained.

Decision rule: If a change affects anything that was part of the approved baseline, require formal revalidation before the system is used operationally. If it is only a documented administrative action with no functional effect, still retain evidence so the configuration trail remains defensible.

What good looks like: The organisation can prove which system was certified, which system was deployed, and how it stayed within tolerance from setup through tabulation. The practitioner takeaway: VVSG implementation is a lifecycle discipline, not a certification event, so the most important control is the ability to keep the live system aligned with the approved one.

Related resources from NHI Mgmt Group

• Voluntary Voting Systems Guidelines (VVSG)
• How does Voluntary Voting Systems Guidelines work?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?