Best Practices for Cybersecurity in Election IT Procurement

This guide contains a set of best practices that election officials can use in their procurements to improve security outcomes. The best practices are intended to generate responses from potential vendors that can help election officials make informed decisions.

For each of the best practices, we provide a few classifications to help understand and prioritize their use. Each best practice can fall under multiple items within each category. For instance, a best practice may address hardware, software, services, or cloud-based IT, or it may apply to some combination of those. While we also provide descriptions of good and not-so-good responses, for all of this guidance, it’s up to the officials to know if a proposer’s response meets their needs.

The following table provides the format of each best practice and includes:

• A description of the best practice, numbered sequentially beginning with #1

• A classification of whether the best practice applies to people, processes, or technology

• Suggested applicability to all or only operational systems

• The type of IT to which the recommendation applies

• Suggested language you can put in your procurement documents

• A description of a good response or activity

• A description of a bad response or activity

• Some additional tips, if any

• Helpful references and links, if any

Viewing the Best Practices

You can click on the triangle for each to open up its contents. You can also view and download a PDF by hovering over the version at the bottom of the navigation bar (where it says “v:latest”) and selecting PDF. Or you can download this set of best practices in Excel format.

To get a link directly to any best practice, hover over the title just above the table and copy the link shown by the “#” to the right of the heading.

Best Practices

Best Practice #1: Individual Qualifications

Best Practice #1: Individual Qualifications

Number	Name	Category	Applicability	IT type
1	Qualifications and experience of individuals proposed for work	People	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide qualifications and experience of all proposed personnel, including subcontractors. In addition to basic qualifications (e.g., certifications obtained), include descriptions of experience in the area of elections or cybersecurity, or both. Where applicable, provide any specific knowledge and experience with state and local policies, architecture, and related aspects of the proposed work.
Good Responses	While combined experience of a team is valuable, it’s not always sufficient. To provide confidence that they understand the complexities of election infrastructure, as well as modern cybersecurity principles and practices, at least some personnel with significant time on the project will have experience with both elections and cybersecurity.
Bad Responses	Listing key personnel without specific names or qualifications. Lack of personnel with direct cybersecurity experience. For those listed, years of experience are provided as a qualification but with a lack of specifics on skills or role in security.
Tips	Expect demonstrated experience doing exact work that has similar cyber challenges (preferably within elections domain).
	Proposed personnel should have a number of years of experience appropriate to their proposed responsibilities as well as relevant degrees and certifications. (Note, however, that certifications can be obtained without demonstrating hands-on experience and should not, on their own, constitute qualification.)
	Look at the ratio of knowledge and experience in-house vs. with subcontractors. It is preferred to have qualifications in-house.
	A team of resources who have worked together on relevant projects are preferable to one that has not worked together on prior engagements. The sum of the whole may be greater than the parts.

Best Practice #2: Past Performance

Best Practice #2: Past Performance

Number	Name	Category	Applicability	IT type
2	Demonstrated past performance performing proposed work. Includes awareness of, and experience adhering to, applicable certifications and legal and regulatory requirements.	People	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide references, including contact information, for past performance with comparable-sized customers and, in particular, in the election environment. Ideally, these will be public sector election organizations at a state or local level. Contact information should include those responsible for the security portion of the project. Include work in a similar legal and regulatory environment and in obtaining any relevant certifications.
Good Responses	The contacts provided match the prior engagements that were similar to your organization’s needed approach. Ideally you will recognize at least some of the organizations, if not the names themselves. The references should be true cybersecurity people, or as close to one as exists in the client’s organization.
	The responder demonstrates an understanding of the legal and regulatory regimes applicable to the contract and other work in which the proposer is involved, including knowledge of local and state requirements as well as any applicable federal regulations.
Bad Responses	Generic statements of experience in the field or related field, but not citing any examples.
	Generic statement that legal and regulatory requirements will be met during the work.
Tips	Require comprehensive disclosure of projects of similar scope and complexity by the proposer within the past three years, whether they are included as a reference project or not. You want information on challenging project engagements as well as successful projects when you are considering past performance.
	Multiple references are a must. They can be from the recent past but should also include some more recent ones. Generally, references that are older than three years can be considered not useful. Evaluate references with points of contact to validate past performance to ensure that the proposer does quality work and has appropriate focus and experience with security requirements expected for this work.
	If the proposer indicates the contact is the only allowable reference (some organizations may only allow a procurement official to field reference calls), explain to the procurement official that you are checking on technical cybersecurity credentials and would like to speak with a technical representative.
	In addition to solicitations in which the proposer was selected, consider requesting information on similar solicitations pursued when the proposer was not selected.
References and Links	DHS Election Infrastructure Funding Considerations
	Brennan Center for Justice, A Procurement Guide for Better Election Cybersecurity

Best Practice #3: Personnel Policies

Best Practice #3: Personnel Policies

Number	Name	Category	Applicability	IT type
3	Proposer personnel policies regarding hiring and conduct standards, including background check, citizenship, and visa requirements.	People	All systems	Hardware, Software, Services, Cloud
Suggested Language	Describe your company process for background checks and security training of those who will be working on the project. Individuals working under this contract must have the same or equivalent background screening and IT security training as government employees.
Good Responses	Detailed descriptions of the types of vetting that occurs: criminal, financial, federal, etc.
Bad Responses	Statements that background checks are conducted with no additional details on the type or extent of vetting.
Tips	All personnel that work on the contract should have at least a national agency check and should be U.S. citizens. If some employees are not U.S. citizens, proposer should detail risk management procedures and provide results of background checks on those staff members or contractors.
	Proposer should provide their processes to ensure that malicious employees cannot compromise security (e.g., limited access and two-person rule for most critical jobs or functions, with appropriate access monitoring in place).
References and Links	National Agency Check Criminal History

Best Practice #4: Work Location

Best Practice #4: Work Location

Number	Name	Category	Applicability	IT type
4	Proposer location(s) where work will be performed and equipment supported as well as administrative and facility security at the location(s).	People	All systems	Services
Suggested Language	Provide all work locations and descriptions of physical and logical security requirements, handling of sensitive materials, and emergency and disaster backup provisions. Describe how you will manage various work locations from the perspective of election security. This includes adherence to government requirements that all work and data storage be maintained in the United States, as applicable.
Good Responses	Describes any work locations and, if multiple, the work performed at each. Facility security descriptions do not need to provide precise measures but should state basic approaches such as entry door badge requirements and presence of security systems.
Bad Responses	No defined policies. Not responsive to stated requirements (such as if, in the RFP, you state that personnel must/must not work in specific locations).
	Failure to specify the locations at which the proposer anticipates work. Vague statements about commitment to security and maintaining properly secure facilities.
Tips	Care should be exercised in using out-of-country contractors or contractor personnel who are not U.S. citizens. They are not inherently bad, but the government needs to be aware that there are risks that will be more difficult to quantify and control. Moreover, some countries may not be acceptable work locations and others may require special controls. Citizenship requirements may be set by the state or locality and may reflect the sensitivity of the products or services being procured.
	For most specialized election products and services, it is reasonable to expect development to occur in the United States by U.S. citizens. Generalized hardware and software will often have global supply chains, but election officials may want to have the final product developed by a U.S.-based company or, at minimum, one with an established U.S. presence and reputation.

Best Practice #5: Training Procedures

Best Practice #5: Training Procedures

Number	Name	Category	Applicability	IT type
5	Training procedures for the proposer.	People	All systems	Services
Suggested Language	Describe security training requirements for personnel. Include descriptions of different training for different types of personnel (e.g., system administrators, developers, administrative). Confirm that these same requirements also apply to any subcontractors.
Good Responses	All employees undergo security awareness training, and those in sensitive and critical security positions have more in- depth training (e.g., threat identification and risk identification). Proposer should describe training content, frequency, and testing approaches.
Bad Responses	Basic statements that employees undergo security training without further description of the type of training. Failure to describe specialized training for critical positions. Indications that suggest security training is ad hoc or otherwise lacks a systematic approach.
Tips	Security training from a reputable provider is most common. Training provided by internal personnel is acceptable if the person is sufficiently qualified.
	Look specifically for mentions of phishing, email, and browsers in training curriculum.
	If software development and customization will be provided under the project, request specific information on secure coding and development curriculum.
	Look for monitoring and reporting of training activities – e.g., 100% of all proposer personnel have completed required cybersecurity and awareness training.

Best Practice #6: Ownership

Best Practice #6: Ownership

Number	Name	Category	Applicability	IT type
6	Company ownership, board members, and stakeholders.	People	All systems	Hardware, Software, Services, Cloud
Suggested Language	Disclose all countries in which your organization operates. Describe the corporate structure and ownership (e.g., publicly traded corporation, privately held partnership, nonprofit). Disclose all board members or any entity with more than 10% ownership in the organization. Also, disclose any ownership in your company by non-U.S. persons or entities, regardless of ownership percentage.
Good Responses	Companies with foreign operations are not necessarily a problem but should be disclosed and disclosures researched for accuracy. Foreign ownership is not in itself a problem; however, it should be fully disclosed and you may want to put restrictions on certain countries.
Bad Responses	Failure to fully disclose foreign activities or interests.
Tips	At minimum, you should ensure that the organization does not come from a country with sanctions against doing business in the United States or have investors that are restricted, such as under the Committee for Foreign Investment in the United States (CFIUS).
	Regardless of percentage of ownership, look for multiple foreign interests that may add up to a significant stake.
	Include a clause in your contract requiring notification of any ownership changes to the election official.
References and Links	CFIUS homepage

Best Practice #7: Key Personnel

Best Practice #7: Key Personnel

Number	Name	Category	Applicability	IT type
7	Proposer process for identifying and approving changes of key personnel who perform most critical management and technical functions.	People	All systems	Services
Suggested Language	Describe the review process for key personnel that perform critical management and technical functions. Also identify the timing of notification to the government when a change occurs and the plan for replacing those key personnel.
Good Responses	Describes thorough vetting procedures as well as technical reviews. Indicates that the government will have the opportunity to review key personnel. With regard to contractor changes in key personnel, provides a sufficient notice period, typically at least 15 business days before the change. The replacement plan should indicate government review and approval and minimize any gap between personnel.
Bad Responses	States only that reviews will occur in an efficient manner and that replacements will meet required qualifications.
Tips	The government may choose to define what constitutes a “key person.” Alternatively, the government can request that the contractor define their criteria for “key persons” and the specific roles that they are proposing be key.
	Government should retain the right to refuse reassignment of a resource that remains employed by the contractor.

Best Practice #8: Access to Sensitive Systems

Best Practice #8: Access to Sensitive Systems

Number	Name	Category	Applicability	IT type
8	Proposer authorization procedures for personnel with access to sensitive information and systems.	People	Operational Systems	Services
Suggested Language	Define sensitive functions and sensitive positions, and describe how individuals involved in sensitive functions and with access to sensitive information are trained and tested for knowledge and job performance. Also describe your process for how access to sensitive functions relates to an individual’s assignment as key personnel.
Good Responses	Proposer clearly defines what constitutes a sensitive function and the related roles that are therefore considered sensitive positions. Personnel involved in sensitive functions should be trained and regularly tested (certified) for knowledge and job performance. Identification of specific personnel authorized to access sensitive information and systems as well as how and when that access will be revoked.
Bad Responses	Blanket statements of appropriate training or assertions that all personnel have substantial training, failing to acknowledge that certain positions require greater levels of training than others.
Tips	Look for proposers to identify administrator functions and who has access to those functions.
	Look for references to new hire and termination checklists that are completed for each new employee and each terminated employee.

Best Practice #9: Subcontractors

Best Practice #9: Subcontractors

Number	Name	Category	Applicability	IT type
9	Proposer policies and practices for subcontractor personnel.	People	All systems	Hardware, Software, Services
Suggested Language	If subcontractors will be used under this procurement, provide details on each subcontractor and the parts of the project in which they will be involved. The government should preapprove all subcontractors. Describe your process for selection and management of subcontractors, including how subcontractors are evaluated on an ongoing basis for meeting security requirements. Describe what information subcontractors will be allowed to access and how you will monitor their activities.
Good Responses	Subcontracting plans are complete and clearly define the tasks completed under a subcontract. Details are provided for how the subcontractors are vetted, selected, and managed.
Bad Responses	Plans to use subcontractors are incomplete or undefined. There is no evidence the subcontractors are vetted for security controls.
Tips	Most procurement offices will have specific requirements around subcontractor use and how requirements for the prime contractor apply to subcontractors. From a security perspective, it’s important to ensure that all security requirements also apply to subcontractors—including those involving the security of the subcontractors’ internal operations.
	Background check requirements should always apply to subcontractors.
	Monitoring of contractors and logging of events should have regular reporting, with sample reports available to the government.

Best Practice #10: Cybersecurity Risk Management

Best Practice #10: Cybersecurity Risk Management

Number	Name	Category	Applicability	IT type
10	Proposer’s regular process for identifying and remediating cyber risks, with particular focus on components and information that are critical for mission success and increased attention to these elements.	Process	All systems	Hardware, Software, Services
Suggested Language	Describe your processes for identifying specific cybersecurity risks and mitigating them in the election environment, and how the implementation of the mitigation processes will increase the likelihood of success on the current proposal. Be specific and provide specific examples of how this process has been successful in both confirming proper implementation and identifying needed changes. Include lab testing and third-party testing you regularly employ.
Good Responses	Includes identification of specific types of risks and the specific actions that were taken to mitigate them. These descriptions should be of a moderate to highly technical nature, referring to specific types of threats or attack vectors, specific port configurations, or the like. The proposer should be able to reference past experience and document their repeatable processes.
Bad Responses	Provides general statements about client satisfaction or periods of uptime without a known incident. Refers back to the list of engagements without providing specific examples of risk mitigated.
Tips	A good response may not refer to a specific contract so it doesn’t reveal a particular client, but should still be able to provide substantial information on approaches.
	It’s OK for a response to be understandable by a nontechnical reader, but it should give the clear impression that they understand the approach in a technical sense as well.
	Ideally there should be process alignment with the CIS Critical Security Controls, National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF), ISO 27000, or another standard risk management framework.
References and Links	CIS Critical Security Controls
	NIST Cybersecurity Framework
	ISO 27000 family

Best Practice #11: Incident Response

Best Practice #11: Incident Response

Number	Name	Category	Applicability	IT type
11	Security processes that include incident handling, recovery, and contingency arrangements to ensure availability. Includes incident response, such as when and how the government will be notified in the event of an incident.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide a description of processes you use for testing, patching, and anomaly handling.
	Define or provide documentation on incident handling, recovery, and contingency processes, including communication plans, backup procedures, and process for operational data availability. This should also include items such as log and audit, log analysis and assessment, and forensics capabilities.
	Define what constitutes an incident and any levels of severity. Include procedures for notifying the government in the event of incidents of each level of severity, to include responsibilities and liability. Additionally, provide a communication plan for handling an incident.
	If you have cybersecurity insurance, provide proof of coverage and describe any relevant details of the policy.
	[If the government has a security incident and event management (SIEM) system:] Are you capable and willing to provide logs in to the SIEM used by the government?
Good Responses	The incident handling process covers all major phases, through recovery and follow-up activities. Demonstrates the proposer’s ability to adequately respond to a variety of incidents. The best responses will include a thorough description of when and how the government will be informed of incidents for a given severity of incident. If asked, the proposer should be able to provide logs into the SIEM.
Bad Responses	Does not clearly identify all phases of incident handling. Procedures are general. The proposer demonstrates no experience or competency in handling incidents.
Tips	The communication plan should demonstrate preparation for public communications regarding incidents and breaches (e.g., holding statements, qualified individuals with experience in incident response and media, messaging management). Consider the Belfer Center’s Incident Communications Plan template for an example of how to construct a good plan.
	If you are operating a SIEM, make it clear to the proposer that even if they submit logs to you, they still maintain responsibility for detecting and addressing incidents.
References and Links	Belfer Center Election Cyber Incident Communications Coordination Guide

Best Practice #12: Transition Planning

Best Practice #12: Transition Planning

Number	Name	Category	Applicability	IT type
12	Transition plan for the end of the contract.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide a contract transition plan for the end of the contract.
Good Responses	Specifies how transition will occur, including status and planning documents that will be provided. Defines the time for these documents to be provided. The plan should cover data, transitioning administrative rights, and other critical services, and the approach to maintaining security throughout the transition. Lessons learned should be documented.
Bad Responses	Provides only remediation for its own performance or rationale to continue services.
Tips	If you have specific requirements for how data or systems should be handled in the termination of a contract, consider adding those to the language.
	Transition plan should clearly state contractor’s obligations during transition (e.g., side-by-side monitoring and operational management of systems with transition target; training documentation; change management database handoff; knowledge base handoff).
	Transition plan could include readiness assessments during the transition (initial contractor assessing any perceived gaps in the transition target’s capabilities and knowledge plus transition target’s assessment of their readiness to assume responsibilities).

Best Practice #13: Cybersecurity Responsibilities

Best Practice #13: Cybersecurity Responsibilities

Number	Name	Category	Applicability	IT type
13	Proposer’s understanding of the scope of security tasks under the project, responsibilities and processes for monitoring adherence to those requirements, and security controls and their applicability in the solution.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Clearly describe expected scope of cybersecurity-related tasks under this contract and who (e.g., contractor, government) is responsible for executing those tasks.
	Also clearly describe how you will monitor service and development processes to ensure adherence to the security requirements of this contract.
	In providing these descriptions, clearly articulate the security controls you intend to employ in the solution. Include hardware, software, and physical security measures, the risks that they mitigate, and any residual risks resulting after implementation of these controls.
Good Responses	Provides clear explanations of how the proposer will manage cybersecurity risk throughout and beyond the period of performance.
	Provides a specific standard or known set of controls. Descriptions include which controls apply to the specific work and why some controls do not apply. These descriptions should demonstrate knowledge of the standard and how it applies to the work at hand.
Bad Responses	Generic statements of implementing security measures throughout all aspects of the project.
	Vague statements that implementations will follow standards, even a specific standard, but no demonstration of experience implementing the standard or standards.
Tips	The extent to which a proposal can define the expectations and responsibilities can provide insight into the preparedness of the proposer to address cybersecurity challenges. At a minimum this must include access controls, storage location(s) for data at rest, authorization to storage location(s), implementation of secure transport (confidentiality and integrity), and logging.
	The proposer should be able to show how controls align with your desired best practices. To that end, it’s reasonable to request that the proposal include a mapping to best practices documents such as the CIS publication, the Essential Guide to Election Security.
References and Links	CIS’s Essential Guide to Election Security

Best Practice #14: Threat Environment Analysis

Best Practice #14: Threat Environment Analysis

Number	Name	Category	Applicability	IT type
14	Proposer’s understanding and staying aware of the threat environment, its proposed risk mitigation approaches, and identification of any residual risks.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide a description of the threat environment as it applies to the systems and their interconnections that are addressed in your proposal. Provide an assessment of the severity of threats, and identify and align mitigation approaches to the threats. Also, provide an assessment of the residual risks following mitigation actions.
	Describe how you monitor ongoing security threat changes and respond to evolving threats, including monitoring common vulnerabilities and exposures (CVEs) and any ability to receive and share real-time threat information. Indicate participation in information sharing networks, including the Sector Coordinating Council of the Election Infrastructure Subsector (EIS-SCC), the Information Technology Information Sharing & Analysis Center (IT-ISAC), the Election Infrastructure ISAC (EI-ISAC), and others.
Good Responses	Actual risks are shown, usually in a table that lists, for each threat, the risk likelihood and consequence presented by the threat—usually in low, medium, and high—both pre- and post-mitigation. Mitigation approaches are listed for each threat to show how likelihood and consequence changes. Mitigated risks are realistic; it is unrealistic for all risks to be mitigated completely.
	Proposer should participate in information sharing networks such as the EI-ISAC or other similar organizations. If not a member of the EI-ISAC, the proposer should commit to being sponsored for membership if awarded a contract.
Bad Responses	Proposer claims there are no risks or that they can be completely mitigated in all circumstances. No acknowledgment of residual risks. No stratification (e.g., low, medium, high) of initial or residual risks.
	Failure to identify concrete sources of cyber threat information.
Tips	This should be a listing of expected threats to your systems and how those threats will be mitigated by the proposer. This listing should be thorough and indicate significant thought.
	If the proposer has had a risk assessment performed internally or by a third party, ask to see their latest risk assessment.
	The decision of the acceptable level of residual risk is yours. The proposer should be providing you a realistic evaluation of residual risk, acknowledging that no solution is perfect.
	Not knowing or understanding ISACs is not disqualifying, but the proposer should be open to leveraging additional sources of security and threat information.
References and Links	DHS Election Security homepage (look for coordinating councils for information on the EIS-SCC)
	CIS’s EI-ISAC
	IT-ISAC

Best Practice #15: Data Transmission

Best Practice #15: Data Transmission

Number	Name	Category	Applicability	IT type
15	Processes for moving information, whether digitally or physically, to ensure that security is maintained at all times. This includes moving vote data, such as for tabulation or election night reporting. Specific focus on security requirements that apply to information and communication products or services.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Describe your process for moving data, whether digitally or physically, while maintaining appropriate security protection and data integrity. This includes between organizations such as the proposer and proposed subcontractors, and to the government, where applicable, during transitions to new systems and technologies.
	Also, specifically describe security requirements that apply to information and communication products and services.
Good Responses	For digital transfer of data, describes both data-in-motion requirements for secure communications (e.g., transport layer security (TLS), hypertext transfer protocol-secure (HTTPS)) and authentication requirements.
	For physical movement of data, describes physical security approaches, including tamper-evident seals as well as chain-of-custody monitoring.
	For deployment of new systems, describes expected downtime, backup procedures, and data security approaches during the transition.
Bad Responses	Describes only that secure approaches are taken without describing specific measures for establishing secure transport of information.
Tips	These days, it’s standard to use HTTPS for secure communications everywhere.
	There may be two separate policies or processes: one for the solution and one for transferring data between you and company. They should only differ in that the policies and processes for communication amongst one another may solely be documented process, whereas the policies and processes for HW and SW you are purchasing should be baked in.
	The proposed approach should align with a commitment to patching systems to ensure the latest security protections are in place, such as implementing the highest level of encryption standards.

Best Practice #16: Controls Implmentation

Best Practice #16: Controls Implmentation

Number	Name	Category	Applicability	IT type
16	Proposer’s agreement to implement a specific set of security controls such as the CIS Critical Security Controls	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Describe the specific security controls that you will implement. These may be international information security standards such as ISO 27000 or common sets of controls specific to elections, such as those described in the Essential Guide to Election Security.
Good Responses	If the government provides a set of controls, confirmation that the proposer will implement them. If the government does not provide a set of controls, the contractor should specify controls or principles it considers best practice.
Bad Responses	If provided: failure to confirm that the proposer will adhere to the set of controls.
	If not provided: failure to identify a candidate set of controls or best practices that the contractor believes will appropriately mitigate risk.
Tips	Include any set of security controls to which the proposer should adhere. Ideally this will be a public, recognized set of controls, but controls specific to your organization are OK too, whether as the primary set or in addition to others.
References and Links	CIS’s Essential Guide to Election Security
	ISO 27000 family
	NIST Special Publication (SP) 800-53

Best Practice #17: Acceptance of Security Practices

Best Practice #17: Acceptance of Security Practices

Number	Name	Category	Applicability	IT type
17	Proposer’s willingness to adhere to your organization’s established security practices.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Confirm that you will adhere to the required security practices under this contract. [Note: Be sure to provide reference to the security practices or a link to them.]
Good Responses	Confirmation that products and services will adhere to the required security practices. Describes experience implementing the same or similar security practices. References copy of proposer’s own information security plan or practices.
Bad Responses	No demonstrated experience implementing similar security practices or a lack of clear commitment to properly implement them as a part of this contract.
Tips	Proposer should be willing to provide a legal attestation to remain compliant with the jurisdiction’s cyber and information security policies, standards, and guidelines.
	Proposer should affirm that any changes in requirements will be accomplished within a reasonable, specified time frame.
	Ask for the proposer’s own information security plan to show alignment with your organization’s established security practices.

Best Practice #18: Security Service Level Agreements

Best Practice #18: Security Service Level Agreements

Number	Name	Category	Applicability	IT type
18	Service level agreements (SLAs) for security that can be defined and agreed to as a part of the contract that address day-to-day activities and activities around an election.	Process	All systems	Hardware, Software, Services, Cloud
Suggested Language	Define specific levels of service for key work activities including performance standards for each service.
	Expected outcomes for normal security activities and, separately, around the time of elections.
	Include your policies for response time, types of support (e.g., in-person, phone) provided, and approach to ensuring continuity of mission critical services (e.g., failure restoral, patching and updates, and other relevant service component failures).
	Clearly describe trigger points for deploying updates and the approvals needed on both the vendor and government sides. This response should address vulnerability detection and remediation, patching speeds, and incident response and escalation procedures.
	For those products that cannot be readily updated, describe controls and monitoring that will be used to identify suspicious access or activity.
Good Responses	Clear descriptions of pre-established measures of success that define specific quantitative goals that are stratified and provide definitions for each level (e.g., response of 15 minutes for critical issues, two hours for major issues). Specifies remediation actions for failure to achieve stated goals. Patching schedules and triggers for out-of-cycle patching are defined. Approval requirements are clearly defined. Clearly demonstrates sufficient capacity to be able to deliver according to the agreement. Demonstrated understanding of changing needs around an election.
Bad Responses	Not clearly defined service levels and normal maintenance/support functions. Solely an as-needed patching schedule with no definition for “needed.” No description of which approvals are necessary to approve deployment. Lacks specifics for goals or provides qualifiers to statements such as “usually” or “typically.”
Tips	Patching is a vital part of all hardware and software. Well-defined policies for patching should describe how, when, and with what approvals patching will occur, including any institutional steps required, such as re-certifications with the EAC.
	While the proposer should include an SLA in its RFP response, details of that SLA are commonly negotiated.
	SLAs should address patch and update management procedures for all systems managed by the proposer. Changes should generally be made on pre-production systems for testing prior to changes to production systems. The proposer should outline the request, approval, and testing process for emergency changes (i.e., critical changes with a limited window to apply to production).

Best Practice #19: Lifecycle Management

Best Practice #19: Lifecycle Management

Number	Name	Category	Applicability	IT type
19	Proposer’s experience in using standardized information technology lifecycle management processes for the exact scope of work. Includes proposer’s lifecycle approach for development of its own hardware and software.	Process	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Do you have a standardized lifecycle management process for information technology?
	If so, describe your experience in using that lifecycle management process for work of the same scope as this project. Describe the lifecycle processes used to manage hardware and software. How will these processes ensure that updates appropriately address security considerations?
Good Responses	Describes defined, repeatable processes and adherence to standards and standard processes such as ITIL or Control Objectives for Information and Related Technology (COBIT). Provides concrete examples of prior use of the process in its work.
	The proposer should use modern tools that are augmented by human inspection to validate that changes to do not degrade security.
Bad Responses	Failure to describe a previously defined and demonstrated lifecycle process used in management.
Tips	You may want to tailor this question to meet the type of procurement you are conducting. For instance, if data management is a primary aspect of this work, this would be a data lifecycle. If it is an IT hardware or software product, detailing the product lifecycle approach most appropriate, to include, for example, development, service and maintenance, and transition planning. For a service, a project management lifecycle would be most appropriate.
	You may want to specify that the proposer periodically provide a comprehensive list of all assets, including serial numbers, hardware and software versions, when they were last serviced, patched, updated, and upgraded (i.e., a transaction log of service on each piece of equipment). The service logs should provide sufficient data for you and the proposer to know when it needs to be upgraded, updated, or replaced, based on the policies, procedures, and contractual arrangements.
References and Links	Introduction to IT Infrastructure Library
	COBIT 2019

Best Practice #20: Security Plan

Best Practice #20: Security Plan

Number	Name	Category	Applicability	IT type
20	Security plan for proposed work.	Process	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Provide the security plan for implementing the security requirements and controls for the product or service. In the absence of the detailed plan, provide an outline of such plan along with examples of security plans for similar products or services provided under similar contracts you have been awarded and successfully implemented. The plan will be finalized in coordination with the government during the period of performance. If using a reference standard to develop your security plan, please identify which one.
	As part of this, include whether you have a responsible disclosure policy for vulnerabilities and, if so, include it with your submission.
	Describe the scope of responsibilities, assignment/ownership of tasks, and processes and procedures for adhering to security requirements and controls for the product or service.
Good Responses	Implementation plans should define security tasks, responsibility for tasks, and criteria for assessing adequacy of task results. Proposers should be realistic and assign responsibility in a meaningful way with consequences. Especially in an operation like elections that has strictly defined deadlines, proper planning matters. It will describe risks to the timeline and approaches to mitigating those risks. It should demonstrate an understanding of potential barriers, such as applicable laws and regulations or formal approval processes.
Bad Responses	Poorly developed implementation plans typically feature unrealistically aggressive timelines, oversubscribe resources, and underappreciate the potential for bumps along the road. An absence of or lack of detail in basic project management tools such as Gantt charts and hand-waving of risks are hallmarks of bad implementation plans.
Tips	Implementation is the “who” and “how.” A security implementation plan should describe the process of reaching a desired end state. In addition to basic timelines for implementation, it describes roles and responsibilities, resources needed to get the job done, and transition management.
	Specifically request that risks be carefully addressed and provide some known risks (e.g., implementation is not complete by the freeze period prior to an election) and ask for their mitigations.
	A system security plan (SSP) should be developed in accordance with a reference standard (like NIST SP 800-18) and should include information on how periodic auditing of the deployed system against the SSP will be performed to demonstrate continuing compliance. It should also address roles and responsibilities of contractor and government in achieving a formal Authorization to Operate, or ATO, if that is required in your jurisdiction.
References and Links	NIST SP 800-18

Best Practice #21: Security Monitoring

Best Practice #21: Security Monitoring

Number	Name	Category	Applicability	IT type
21	Proposer’s processes for monitoring adherence to standard information and physical security processes in its products and its own operations.	Process	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Describe your regular security audits and penetration analysis performed. Provide annual security audit reports conducted by an independent auditor.
	Are you willing to be subjected to external analysis and penetration testing by an organization of our choosing? This may occur during planning , implementation, post-implementation, or operations.
	Provide examples of prior security testing and evaluation reports, vulnerability assessment reports, and any related reports.
	Additionally, the government may require contractors and their suppliers to provide security testing reports and independent audit reports from similar work to this project that details the effectiveness of security controls and demonstrates timely correction of issues.
Good Responses	Contractor can provide history of past audits and penetration testing and resolution of findings. These should demonstrate sound processes and timely risk mitigation. They will show identified risks and mitigations. They should reflect adherence to a common standard or set of rules.
	Permission to conduct reviews and testing at any time during the contract using the government’s chosen auditors (e.g., state auditors, National Guard, the RABET-V® program, independent assessment specialists).
Bad Responses	Summaries clearly written for this proposal or a generic statement of auditing practices. Submitted reports are incomplete or fictitious examples and do not contain recognition of risks that need mitigation.
	Limits on reviews or insistence on the proposer conducting internal reviews.
Tips	Vulnerability reports should cover not only assets deployed for your specific project but also for core contractor functions and services, such as vulnerabilities in those systems as well as your production/UAT/QA/test systems).
	Claiming proprietary limitations is not acceptable, especially if a nondisclosure agreement is in place. The proposer may redact items to protect the identity of clients. Often, you will not get a full report, but rather a summary showing findings. There may also be restrictions on sharing this information publicly.
	Products should be subject to review before acceptance. Any item altered through a service contract should similarly be subject to review. The contractor may wish to limit the frequency with which audits or testing occur. A reasonable frequency is once or twice annually or whenever a new product is deployed.
	It is normal for vulnerability and penetration test results to have residual issues. The contractor explain false positives and address why any unaddressed high or critical priority issues. The contractor must be able to provide you procedural or other mitigations they have in place.
References and Links	CIS’s RABET-V Program

Best Practice #22: Security Certifications

Best Practice #22: Security Certifications

Number	Name	Category	Applicability	IT type
22	Companywide process certifications and demonstrated adherence to proposer’s documented processes.	Process	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Provide evidence of certification or registration according to national quality or security standards. Describe your adherence to standardized quality principles, such as through registration as ISO 9001 (general quality) and ISO/IEC 27001 (information security). Both are strongly preferred. If you do not follow a standardized quality principle, provide your documented processes and evidence that you monitor adherence to those processes.
Good Responses	Up-to-date proof of certified adherence to both standards. Organizations should be able to submit verifiable proof. Proposer can provide evidence of past testing and evaluation and related reports.
Bad Responses	Claims of adherence without certification. Claims of following an alternate approach that is not a well-recognized standard. Lack of evidence of testing and evaluation history.
Tips	Standardized quality principles are an objective way for an organization to demonstrate that it understands and adheres to industry best practices. It may be acceptable for an organization to not adhere to these principles, but, if so, it should be able to explain its rationale for not doing so.
	Smaller organizations are less likely to have these certifications. At a minimum, they should be able to provide evidence they have and follow documented processes.
	Organizations will often state their certification but not provide documentation. If an organization claims certification to a standard, ask for proof.
	If an organization says it adheres to a standard but is not certified, it should have evidence of its own internal evaluations. These are not just checklists, but detail how the organization manages its processes. There are some instances, like with EAC certification, in which you should consider requiring certification.
References and Links	ISO 9001 Quality Management
	ISO 54001 Application of ISO 9001:2015 for electoral organizations
	ISO 27000 family

Best Practice #23: Supply Chain Management

Best Practice #23: Supply Chain Management

Number	Name	Category	Applicability	IT type
23	Proposer’s supply chain management and selection process for suppliers, including contractor’s approach to evaluating replacement components or new technologies evaluated for use in the environment to ensure adequate security.	Process	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Detail your approach to supply chain management, including the selection process for suppliers. Provide specific information including, but not limited to:
	How is information regarding supply chain issues shared among the organization and suppliers? How do you handle content originating from non-U.S. sources?
	How do you review suppliers and their products to ensure that they do not contain security vulnerabilities or malicious content and are free from unexpected or unwanted procedures?
	Which processes are used to monitor compliance of suppliers to requirements of the contract? Describe any process for auditing suppliers’ ability to maintain security in their development process.
	What is your process for managing hardware and software that is no longer supported by the supplier to ensure continued maintenance of appropriate security? Describe your transition process for changes in suppliers to ensure security measures are continually met. How will you maintain appropriate communication with the government for such products?
Good Responses	Processes described provide confidence that proposer carefully evaluates origins and specific security characteristics of new technology or replacement components. The response should describe compliance monitoring requirements, testing practices, work locations, certifications, and supply chain risk management activities, such as requiring suppliers to follow established best practices such as NIST SP 800-161.
	Recognition of limitations in the updates process, such as that older components may not receive updates and that updates may be complicated by certification procedures. For those products that can be readily updated, description of a clear process for making updates and notifying the government when updates are available and the approach to implementing the update.
Bad Responses	Statements that the contractor uses only genuine or quality components without any reference to a process, quality assurance, or requiring suppliers to implement specific controls.
Tips	It may be appropriate to rely on an outside evaluator to assess new technology and replacement components.
	Open source software can be OK to use as part of a solution, but it should be long-standing, well-vetted software. Open source software can be as or more secure than proprietary solutions, but it, like all software, must mature.
References and Links	NIST SP 800-161 Supply Chain Risk Management
	CISA Resources for Supply Chain Management
	CIS’s Managing Cybersecurity Supply Chain Risks in Election Technology: A Guide for Election Technology Providers

Best Practice #24: Accessing Sensitive Information

Best Practice #24: Accessing Sensitive Information

Number	Name	Category	Applicability	IT type
24	Processes for managing and documenting access to different categories of sensitive information.	Process	Operational Systems	Software, Services, Cloud
Suggested Language	Describe how information sensitivity is categorized and how access to sensitive information is managed and documented for each category, including your ability to create reports and machine-readable data extracts for both private and public dissemination. Clearly designate responsibilities, obligations, and procedures for key aspects of a data governance plan (data owner, data steward, data retention, information sensitivity, etc.). Demonstrate your understanding of this jurisdiction’s data governance policies and practices and propose a data governance approach as part of your submission.
	Your response should include how various categories are treated when transmitted, such as when and how information is digitally signed and encrypted.
Good Responses	Acknowledges and properly addresses that different types of data have different sensitivities. Provides a sufficient stratification to address the different needs and describes appropriate controls for each. Should include descriptions of the types of data anticipated in the product or throughout the course of the project (e.g., voter personal information, candidate filings, precinct records).
	Proposer provides a clear data classification scheme and also describes how it will be continuously applied to data in the system(s).
Bad Responses	Describes an approach in which data are secured “as needed” or with “appropriate” security without clear thought on the types of data that will be encountered under the proposed work.
Tips	Proposer should affirm their acknowledgment and acceptance of requirements for jurisdictions to easily comply with a jurisdiction’s laws around providing non-sensitive public reports and data subject to your open records/open data laws within the timeline required under those laws.
	At minimum, the plan should describe which categories are signed and which are encrypted. For example, you should expect to see transmitted data of importance signed, while sensitive data should be both signed and encrypted.

Best Practice #25: Controls on Data Access

Best Practice #25: Controls on Data Access

Number	Name	Category	Applicability	IT type
25	Controls on data and access, including where the data reside, who has access, and how access rights are maintained; encryption approach; and incident capabilities, including logging and forensics.	Technology	All systems	Hardware, Software, Services, Cloud
Suggested Language	Describe in detail the controls placed on data and access to data. Include requirements for location, access rights, maintenance and enforcement of access rights, encryption, incident response and backup capabilities, and logging and forensics capabilities.
Good Responses	All controls should have clearly documented policies. For each control, the contractor should either include a link to the policy or describe the recommended control or control options. Though most applicable to cloud service providers, this also applies to first-party providers in which the contractor provides data management or the government manages controls. In the latter case, it should detail the options for managing controls available to the government and the manner in which those controls are managed.
Bad Responses	Overly optimistic statements that the provider can implement any required controls.
Tips	Logging of events should follow a common data format, such as NIST SP 1500-100.
	Look for data handling to include encryption for data both while in transit and while stored at rest.
	Access to the data is restricted to only those with the need to see it, by established and documented access control methods.
References and Links	NIST SP 1500-100 Election Results Common Data Format

Best Practice #26: Cloud Security

Best Practice #26: Cloud Security

Number	Name	Category	Applicability	IT type
26	Cloud security options.	Technology	All systems	Cloud
Suggested Language	If the solution will be hosted in a cloud or multi-tenant environment provided by Azure, AWS, or Google, include information on the adherence to the appropriate CIS Benchmark for Cloud Service Offerings. Explain the reason for any deviation from that Benchmark and provide any additional options that are available.
	If using another cloud provider, include the full menu of security options and services offered by the hosting provider, and which specific security options and services are included in the proposal.
Good Responses	The proposer should include all security options that are available, whether or not they will be used. While it’s not necessary to justify every decision, the chosen set should make sense.
Bad Responses	Anything less than the full list of security options.
Tips	The goal of including the full menu is to see what the provider has available. You may want to include a different set of security options as part of negotiations.
	Look for implementation of the solution in an approved “Gov” cloud with FedRAMP baselines of high and moderate, or the equivalent. This would cover many of the key security components, but documentation should be provided showing that secure features are enabled, such as encryption at rest.
	Be sure to ask about specific data compliance requirements in your state and jurisdiction. For instance, many states require cloud providers to keep all data within the United States. If you have this requirement, be sure to explicitly ask about it.
References and Links	CIS Benchmarks
	FedRAMP Cloud Service Providers
	FedRAMP Marketplace

Best Practice #27: Open Standards

Best Practice #27: Open Standards

Number	Name	Category	Applicability	IT type
27	Use of open standards and common approaches in software and common data formats.	Technology	All systems	Hardware, Software, Services, Cloud
Suggested Language	For user- and client-specific software and applications, confirm on which types of systems and, where applicable, browsers the product will have full functionality. In general, products should be fully functional on a host of systems, to include netbooks (such as Chromebooks) and all major browsers.
	If managing voter or ballot data, provide the data format(s) you are using and identify common functions supported with those formats (e.g., risk-limiting audits).
Good Responses	Applicable products are fully functional across a host of systems and browsers or, if not, a full description is provided as to why this is not possible.
Bad Responses	A lack of planning or formalized decision around the approach. Support only for specific browsers or systems that don’t represent the whole of your environment.
Tips	Development toward specific systems—even if they are the only systems you have in your environment—is generally frowned upon. This goes beyond compatibility: if something is developed in such a way that it only functions on a specific system, this may indicate that the proposer is not using the most common, and thus best-vetted, standards.
	While it is good to have flexibility to work across multiple versions of a browser, it should be expected that the software will be maintained to use the most current or very recent versions and have a policy of deprecating older versions that are no longer secure.
	Security audit functions are typically performed outside of the system and thus it is important that systems make data available for auditing in common formats that meet the auditing needs of the election officials.
References and Links	NIST SP 1500-100 Election Results Common Data Format

Best Practice #28: Security Architecture

Best Practice #28: Security Architecture

Number	Name	Category	Applicability	IT type
28	Security architecture for proposed or required solution.	Technology	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Provide a full description of the proposed solution’s security architecture. Describes completely how architecture will ensure security of election infrastructure.
Good Responses	A good response will provide diagrams, examples of mitigation of threats and risks, and descriptions of a proposed security architecture. It should demonstrate that the proposer understands their systems and how they fit into the larger context. It should include descriptions of all system components and detail multiple layers of security, internet connections, firewalls, intrusion detection and prevention systems, and other critical components. It should describe the security approach for each aspect of the system.
	When drafting a proposal, it’s often difficult to determine how much detail to provide, especially if there are page limits. Concisely written proposals are a signal that a vendor has put thought into their work. For this reason, it’s important to make it clear that the successful proposal will provide significant details on their approach to security.
Bad Responses	It’s OK for vendors to make claims that they use security approaches that are “state of the art,” “best in class,” “military grade,” or the like, but they need to back up those claims with details of security architectures and processes.
Tips	Most proposers will be reluctant to provide detailed information in a public document (assuming your jurisdiction’s laws require bid materials to be public). Work with your procurement team to allow for confidentiality of detailed security architecture information in your solicitation.
	Expect layered architecture that partitions most sensitive data/critical systems from less critical/sensitive ones.
	It’s OK to put a page limit on proposals, but allow for additional pages for diagrams of security approaches. If a vendor has implemented in a similar environment, they’ll be able to provide detailed diagrams fairly easily. This can help officials identify the best qualified proposers.
	Some (or most) of your solicitation reviewers may not have the breadth or depth of technical knowledge to assess detailed security architecture materials. Consider carving out an assessment of these materials to a separate group of tech reviewers and incorporate their findings/ratings into the other evaluation materials.

Best Practice #29: Cryptography and Key Management

Best Practice #29: Cryptography and Key Management

Number	Name	Category	Applicability	IT type
29	Approach to cryptography and key management for data security	Technology	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Describe your approach to cryptography, including which cryptographic modules and protocols you use, and how you conduct key management and manage the secrecy of private keys, if applicable.
Good Responses	Demonstrates understanding of where cryptography can and should be employed as well as familiarity with different types of cryptography and the rationale for the selection of the specific cryptographic solution proposed. In addition, thoroughly addresses cryptographic key management including protection of keys.
Bad Responses	General descriptions of the use of encryption as a means to protect data at rest or in transit.
Tips	Use of standard cryptographic modules is a must. We highly encourage you to permit only cryptographic modules validated under Federal Information Processing Standard (FIPS) 140-2.
	This best practice is intended for specialized applications leveraging cryptography. Standard encryption, like websites with HTTPS, should be on all systems.
References and Links	FIPS 140-3 Requirements for Cryptographic Modules
	FIPS 140 Validated Modules list

Best Practice #30: Software and Asset Ownership

Best Practice #30: Software and Asset Ownership

Number	Name	Category	Applicability	IT type
30	Ownership of software and other assets.	Technology	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	If the proposal includes commercial off-the-shelf (COTS) or modified off-the-shelf (MOTS) software, address ownership of the software and design assets both during the project and afterward. Also, address whether source code and other artifacts will be held in escrow or delivered to the government during the project, and ownership of IP rights at the end of the project.
Good Responses	Addresses ownership of all assets in the project, including software licenses and software developed (or modified) as part of the project.
	Includes statements that code will be delivered to the government, put in software escrow, or a similar mechanism to ensure that the government won’t be left with a build that can’t be updated should the proposer go bankrupt or otherwise cease operations.
Bad Responses	Insufficiently addresses ownership. The government should own licenses for COTS and MOTS software and should have a process for accessing source code for any proposer that has even a small risk of going out of business.
Tips	Some companies may not be willing to participate in software escrow. This may be OK, especially for larger, more established companies (such as Microsoft®) that are unlikely to go bankrupt and over which you have little contracting leverage. But for smaller organizations, the risk of failure is higher and should be mitigated.

Best Practice #31: Solution Certifications

Best Practice #31: Solution Certifications

Number	Name	Category	Applicability	IT type
31	Certifications received for the solution, including EAC, RABET-V verification, and applicable state or local security standards. Or, in lieu of certification, rationale for lacking certification and approach to ensure that security in the solution is mature and reliable.	Technology	Operational Systems	Hardware, Software, Services, Cloud
Suggested Language	Detail certifications obtained for the solution(s) you intend to deploy and how these meet applicable federal, state, or local security standards. If the solution(s) will not be certified, how will you ensure mature and reliable security? Additionally, describe your process for ensuring the certified system will be updated to reflect current security patches and updates to underlying components (e.g., operating systems, databases, communications systems).
Good Responses	For products with a known certification process, evidence of certification. For other products, a clear process for assessing security. For all products, a clear description of how updates will occur and how that affects certification or other validation processes.
Bad Responses	Lack of demonstrated knowledge of certification processes. Lack of procedures or assessing the security of implementations.
Tips	You will likely want to modify this question for the given Type of procurement, Especially when thinking of voting systems vs. non-voting election systems vs. backend COTS IT systems.

Best Practice #32: Protection of Personal Information

Best Practice #32: Protection of Personal Information

Number	Name	Category	Applicability	IT type
32	Personal information management, including transmission and approach to protection.	Technology	All systems	Software, Services, Cloud
Suggested Language	If personal information will be handled, describe how you will manage the minimization, collection, storage, and transmission of that personal information. Describe confidentiality and privacy approaches with regard to personal information.
Good Responses	Gives attention to minimization of personal information as a first measure for reducing risk.
	Where personal information must be collected, gives a thorough response for managing personal information through data security at rest and in transit. Provides anticipated encryption techniques and secure communication protocols.
Bad Responses	Suggests only that personal information will be protected at all times, without describing specific approaches.

Best Practice #33: Endpoint Protection

Best Practice #33: Endpoint Protection

Number	Name	Category	Applicability	IT type
33	Advanced endpoint protection on core systems.	Technology	All systems	Hardware, Software, Cloud
Suggested Language	Confirm that you have advanced endpoint protection for any server or workstation that is part of the core service offering. All systems accessing the core service offering must have advanced malware detection along with traditional anti-malware software. Specifically, the advanced malware software must allow root-cause analysis with forensics showing how infection occurred along with actions malware took.
Good Responses	Explicit confirmation that the relevant systems meet the requirements for advanced endpoint protection. The proposer should be able to provide details on how it employs this endpoint protection.
Bad Responses	General statements of endpoint protection without a description of the specific software used or its capabilities.

Best Practice #34: Specific System Experience

Best Practice #34: Specific System Experience

Number	Name	Category	Applicability	IT type
34	Experience with the needed system or service.	Technology	All systems	Hardware, Software, Services, Cloud
Suggested Language	Provide details on relevant experience with the [specific system or service]. Details should include experience meeting the specific requirements, transitionin from past systems, and planning for future transition or end of life.
Good Responses	Clear details that the proposer has installed, operated, or supported the relevant system or service and understands how to transition to and from it.
Bad Responses	General statements of understanding the technology or unsubstantiated claims of being able to manage transitions.