County IT Resilience: CJIS, Elections, Recovery, and Procurement

County and municipal IT teams support services residents may need at the worst possible moment: public safety, courts, elections, records, and the systems employees use to serve the community. Resilience is not a backup appliance or a document that is opened once a year. It is the ability to understand what must keep working, who is responsible, and how the organization will restore service when something goes wrong.

A useful playbook does not need to be long. It does need to connect technical recovery with agency responsibilities. Begin with the services people depend on, then work backward to the systems, data, networks, vendors, and decision-makers required to keep them available.

Start with services, not hardware

Build a concise service map for the systems that matter most. For each service, record the business owner, technical owner, affected departments, support contacts, and dependencies needed to restore it. Include identity, network paths, external services, databases, and information users need to complete their work.

The service map should answer practical questions. If a server is available but staff cannot authenticate, is the service recovered? If a court application depends on a network link managed by another provider, who coordinates the response? If a vendor must participate in a recovery step, how does the county reach that person outside normal business hours? Naming dependencies in advance prevents an incident from becoming a search for owners and phone numbers.

Keep the map maintainable. A smaller list with current owners and real dependencies is more valuable than an exhaustive inventory no one trusts. Review it after a system change, vendor transition, or change in agency responsibility. Include a date and owner for each review so users can distinguish current information from a stale contact list.

Define applicable CJIS responsibilities locally

For systems that handle criminal justice information, each agency should determine which requirements apply to its own responsibilities, systems, and relationships. The requirements and roles are not necessarily identical for every county. Identify who within the agency is responsible for deciding how applicable requirements are addressed, and document the controls, hosting boundaries, vendor roles, access practices, and evidence relevant to the system.

Do not treat a generic security statement as proof that a particular environment meets an agency’s requirements. Ask how administrative access is handled, which parties can reach the system, how changes are managed, and what records are available for the agency’s own assessment. Make the answers part of system operating documentation so people responsible for technology, procurement, and governance are working from the same description.

Use the FBI CJIS Security Policy, version 6.1 as a primary reference when determining relevant policy provisions. The source is guidance for understanding the policy text; the agency must determine how its own circumstances and applicable roles relate to it. Do not assume a single checklist or generic vendor claim resolves that determination for every county.

The goal is not to turn the IT team into a compliance department. It is to make responsibilities explicit and ensure that procurement, operations, and recovery plans do not contradict the agency’s own requirements. Where responsibilities cross organizational boundaries, write down who provides information, who makes the relevant decision, and where evidence will be retained.

Plan election continuity before deadlines become urgent

Election systems have important dates, decision-makers, and operating procedures. That makes election continuity a good candidate for a focused tabletop exercise. Confirm which services are in scope, who can authorize changes, how access is handled, which vendors support the environment, and what the response path is if a critical service becomes unavailable.

Test the decision process as well as the technology. Who informs election officials? Who decides whether an alternate access path is appropriate? Where does the team record restoration status? A tabletop lets participants identify stale contact information or unclear handoffs without making changes to a live election environment. Keep the scenario specific enough to prompt useful decisions, while avoiding unnecessary sensitive operational details in materials distributed broadly.

The CISA Election Infrastructure Cybersecurity Readiness and Resilience Checklist is an official reference that election offices can use when considering preparedness. It does not make every county’s roles, systems, or requirements identical. Each jurisdiction should decide what is applicable to its own operations, authorities, and election services.

Where network separation or other controls are part of the agency’s plan, document what is separated, how approved access works, and how the environment would be restored. The design should reflect local responsibilities and system needs rather than a general assumption about what election continuity means. Identify the people who can explain those decisions during an exercise and ensure contact paths are current.

Prove recovery with an exercise

A backup report is useful evidence, but it does not establish that a service is usable after restoration. Choose a recovery scenario for a critical service and include the application owner, infrastructure team, identity and network owners, and people who can verify that the workflow works.

Agree on recovery objectives with the business owner. Define how much downtime and data loss the service can tolerate, then check whether the technical plan supports those expectations. During the exercise, follow the recovery sequence, confirm dependencies, test access, and record the evidence. If the exercise is a tabletop, use it to find coordination gaps; schedule a controlled technical restore test separately to validate the actual path.

Keep the scenario grounded in a service outcome. Restoring a database is not sufficient if employees cannot authenticate or the application cannot reach it. Ask the person who owns the workflow to demonstrate a meaningful task after restoration, and record what was verified rather than merely recording that a system started. Where an exercise cannot safely test a live dependency, state that limitation and agree how it can be evaluated.

After-action work matters. Assign owners and dates to gaps, update the runbook, and repeat the test after significant changes. A recovery plan that has been practiced is easier to use than one that exists only as a document.

Make procurement support the operating plan

Procurement can reinforce resilience when the scope of work identifies responsibilities clearly. Ask vendors to document service ownership, escalation routes, recovery roles, access practices, records provided to the agency, and how a restoration test will be evidenced. Clarify which organization makes decisions during an incident and which party is responsible for carrying them out.

These questions help the county compare more than product features. They show whether the proposed service can fit the agency’s actual operating model. Keep responses in the contract file and service documentation so the team does not have to reconstruct expectations under pressure. Avoid relying on broad assurances where an operational detail—such as who initiates recovery or how a dependency is contacted—can be stated directly.

Exercise the playbook with a realistic scenario

A tabletop can test whether the playbook works for the people expected to use it. Select a critical service and describe a plausible disruption, such as loss of connectivity to a hosted system or an unavailable identity service. Give participants only information they would reasonably have at the start, then introduce new facts as the discussion progresses.

Ask the group to identify who declares an incident, who contacts the provider, which services must be restored first, and how the county will communicate status to affected departments. Include a complication: a key contact cannot be reached, a decision-maker is unavailable, or a dependency has changed since the last review. The purpose is to expose unclear handoffs, not to grade individual participants.

Keep exercises safe for live public services. A discussion-based tabletop does not require an actual outage or changes to production systems. If the team later performs a technical recovery test, plan it separately with the system owner and necessary safeguards. End with a brief list of actionable findings rather than an unprioritized transcript of every idea raised.

Make the playbook usable on incident day

The document should be easy to find through an approved, resilient access path. Include the service name, business owner, technical owner, vendor escalation details, dependencies, decision roles, and location of current recovery procedures. If sensitive access information is needed, reference the approved credential process rather than embedding secrets in the playbook.

Give each section an owner and a review trigger. A staff change, contract renewal, network redesign, or application move can make a once-accurate contact or dependency list stale. Record when the information was last validated and how an operator should flag a suspected error.

After an exercise, make updates part of the normal operating record: assign the change, agree on a due date, and confirm the revised procedure with people who will use it. This keeps resilience from depending on one employee’s memory. Logical Front’s Local Government services support public-sector infrastructure and continuity planning. A practical map of what must keep working—and who is responsible when it does not—is a useful place to begin.