If you work in a state or local government office, you probably think about security a great deal. Physical security, personal security, and cybersecurity have become increasingly necessary and prevalent concerns for government offices, with both proactive and reactive policy mechanisms in place to manage security risks. Software-based systems are particularly vulnerable to security risks and require careful attention to validate their trustworthiness and manage associated risks.

A proactive policy that vets the security of your software-based systems, either during procurement or as part of a vendor contract, can significantly alleviate concerns about the cybersecurity of software-based technology products. The challenging aspect of designing policies for verifying the security of software-based systems is that the industry security standards for such systems are constantly evolving as the cybersecurity risk landscape changes.

The RABET-V™ program can be integrated into procurement policies, certification programs, and vendor contracts, and ensures that due diligence is conducted to update a technology product’s security baselines to the latest standards. This verification process ensures that software-based systems are developed and verified in accordance with the latest security, accessibility, and usability best practices. As a holistic assessment program, RABET-V introduces testing standards to better understand the security, reliability, and associated risks of a technology product.

This article describes how government offices can include RABET-V in their procurement policies and vendor agreements to help verify the technology security within their organizations.

Integrating RABET-V into Procurement Policies and Vendor Contracts

System procurement processes vary by state and municipality. For many jurisdictions, the procurement process begins with the development of a request for proposals (RFPs) that outlines the required functionalities and security features of a desired system. RFP requirements must align with applicable state and federal laws; however, officials typically have some discretion over core aspects of the system (The Council of State Governments’ report on procurement).

There are three major policy levers you can use to integrate the RABET-V program into your jurisdiction’s RFP.

A certification or approved list with a RABET-V mandate or an independent testing mandate

A common approach to RFPs is to create a certification or approved list for a technology product to be used in a jurisdiction and require verification against the latest RABET-V baseline. This approach can be used at both the state and the local level, as given by the following sample language:

For [Product] to be approved for use in [Jurisdiction], Vendor must provide a RABET-V "short report" showing a verified status against RABET-V [Baseline] dated within last 12 months prior to the deployment within [Jurisdiction].

Vendor must achieve a verified status against [Baseline] for each new version or at least once every [12 months], whichever is longer.

In addition to the requirements above, [Jurisdiction] may request Vendor complete a revision iteration prior to approval of any new version of the system.

[Jurisdiction] reserves the right to review the full RABET-V iteration report at any time. In-person or virtual reviews conducted with Vendor, in which the vendor shares the full report, are an acceptable form of review.

[Jurisdiction] RFPs relating to [Technology Category] must conform to these requirements.

The timeline for verifying the product may be modified based on whether the jurisdiction prefers to specify a shorter retesting period or triggers based on the type of change to the system.

Another way to approach using RABET-V for your certification or approved list of products in an RFP or vendor contract is to use language that requires technology providers to go through an independent testing program, like RABET-V:

For Product to be approved for used in [Jurisdiction], Vendor must provide evidence from an independent testing authority that Product has been verified as meeting a reasonable standard of best practices within the last 12 months.

Independent testing authority and allowable best practices are subject to acceptance by [Jurisdiction] and must meet the following minimum characteristics:

• Assess Vendor against widely accepted best practices for modern software and product development.
• Assess Product against widely accepted best practices for modern architectural design.
• Assess Product dependencies against known vulnerabilities and other common deficiencies, such as through a Software Bill of Materials analysis.
• Assess Product performance against widely accepted best practices for modern software performance, such as through compliance and penetration testing against the CIS Controls, NIST Special Publication 800-53 security control families, or other consensus-based, widely accepted best practices.

In addition to the requirements above, [Jurisdiction] may request Vendor complete an additional review prior to approval of any new version of the system.

[Jurisdiction] reserves the right to review applicable reports from independent testing at any time. In person or virtual reviews conducted with Vendor, in which the vendor shares the full report, are an acceptable form of review.

[Jurisdiction] RFPs relating to [Technology Category] must conform to these requirements.

For more information on software bills of materials, CIS Controls, and NIST security control families, please refer to the following resources: RABET-V architecture lead, John Dziurłaj’s 2025 article “Bills of Materials: What’s Really in Your Systems,” and RABET-V’s Security Requirements.

A security review with RABET-V or independent testing requirements

Another option for your jurisdiction to include RABET-V or a similar testing program in an RFP or vendor contract is to require a regular security review of all procured technology. Some sample language for this policy route is below:

Vendor must provide a RABET-V short Report showing a verified status against RABET-V [Baseline] at least once every [12 months] to demonstrate compliance with RABET-V security best practices.

OR

Vendor must provide evidence from an independent testing authority that Product has been verified as meeting a reasonable standard of best practices, like the RABET-V program, for review and verification.

Independent testing authority is subject to acceptance by [Jurisdiction] and must meet the following minimum characteristics:

• Assesses Vendor against widely accepted best practices for modern software and/or product development.
• Assesses Product against widely accepted best practices for modern architectural design.
• Assesses Product dependencies against known vulnerabilities and other common deficiencies, such as through a Software Bill of Materials analysis.
• Assesses Product performance against widely accepted best practices for modern IT system performance, such as through compliance and penetration testing against the CIS Controls, NIST Special Publication 800-53 security control families, or other consensus-based, widely accepted best practices.

In determining the latest baselines to include in the security review language, your jurisdiction may want to add that the relevant administrative body will determine the latest baselines. For more information on RABET-V’s reporting process, see the program manual.

An RFP scoring process that includes a security review process with internal and external reviews and testing

If your jurisdiction prefers to use scoring processes for your RFP’s, RABET-V can be integrated into the scoring process for security review. Here is a sample scoring guide:

Security Review Process [20 points]:

• Internal reviews and testing [5 points]:
  • Vendor demonstrates written policies for the application of internal testing processes and tools, such as, but not limited to unit and regression testing, dependency analysis, and internal development controls.
  • Vendor demonstrates consistent use of internal testing.
• External reviews and testing of product performance [5 points]:
  • Vendor demonstrates consistent use of external testing for modern, point-in-time IT system performance, such as through compliance and penetration testing against the CIS Controls, NIST Special Publication 800-53 security control families, or other consensus-based, widely accepted best practices.
• External review and testing of organizational performance and product architecture and dependencies [10 points]:
  • Vendor demonstrates consistent use of external assessment for modern software and/or product development, such as against the OWASP Software Assurance Maturity Model (SAMM).
  • Vendor demonstrates consistent use of external assessment for modern architectural design.
  • Vendor demonstrates consistent use of external assessment for known vulnerabilities and other common deficiencies within dependencies, such as through a Software Bill of Materials analysis.

Additional consideration can be given to external reviews and testing that:

• Follow industry best practices for security and accessibility.
• Leverages a product-specific threat model to inform verification assessments.
• Assumes a risk-based approach to all verification assessments.
• Clearly defines testing entity qualifications.
• Incentivizes continual improvement and incremental changes by simplifying verification and rewarding security maturity.

Use case for RABET-V in State Policy

The RABET-V program originated as a verification solution for non-voting election technology. It has since expanded outside of elections and is equipped to handle any software-based system. The following example is from the elections space, but can be applied to other government offices.

RABET-V meets requirements in Ohio’s Security Matrices

The Ohio Secretary of State’s office released new security matrices for ballot-on-demand voting systems and voter registration systems in September 2025. Both matrices include a requirement for a cybersecurity maturity assessment:

The vendor shall undergo a cybersecurity maturity assessment of the vendor’s software development and cybersecurity practices to provide assurances that these practices are matching the requirements of this matrix and the Secretary of State security directives. A copy of the report and remediation steps taken shall be included in the examination.

The RABET-V organizational assessment module utilizes SAMM as its basis for evaluation, building upon the SAMM model to incorporate usability and accessibility maturity scores. This module meets the requirements outlined in the state of Ohio’s system requirements matrix. Additionally, RABET-V supports functional testing of systems on an ad hoc basis and can meet all other requirements in Ohio’s matrices, including the specification for a Voting System Test Laboratory (VSTL) to perform the testing.

If your jurisdiction has functional requirements or specific assessor qualifications, consider RABET-V to be a partner in creating the assessment ecosystem that works for you.

Moving forward with RABET-V

Drafting policies to protect your office from harmful security breaches is a challenging task. RABET-V was created with this purpose at the forefront and has evolved with the intention of making the jobs of Chief Information Officers, IT analysts, and all those responsible for system implementations easier.

In case the above sample language does not pertain to your jurisdiction’s specific situation, here is some consolidated sample language that synthesizes many of the points made above:

Vendors must provide evidence from an independent testing authority demonstrating verification against recognized security best practices within the last 12 months for election technology products to be approved for use. This verification should assess organizational software development processes, architectural design, dependency vulnerabilities through Software Bill of Materials analysis, and product performance against industry standards like CIS Controls or NIST SP 800-53. Jurisdictions reserve the right to request additional reviews before approving new system versions and may review full verification reports at any time. Utilizing a testing program that evaluates products within their development context, employs risk-based approaches, defines clear testing qualifications, and incentivizes continual improvement is required.

For more information on the RABET-V program and to learn about our approach to system security verification, visit our website, subscribe to our newsletter, reach out to us at team@rabetv.org, and check out our previous article on how AI impacts RABET-V verification.

RABET-V™ is a trademark of the Center for Internet Security.