Interlocal agreements for shared systems: governance and exit

Reference article · 6 min read

Two or more agencies sharing one system is a common way to afford software that none of them could justify alone. A county and its municipalities share a computer aided dispatch system. A group of cities share a permitting platform. A council of governments runs an ERP that member jurisdictions log into. The technology is usually the easy part. The problems that surface three years in come from the interlocal agreement: the document that says who decides, who pays, who owns the data, and what happens when a member wants out.

These agreements go by different names depending on the state, including joint powers agreements, intergovernmental agreements, and interlocal cooperation agreements. They are creatures of state statute, and the authorizing statute constrains what the agreement can do, whether it can create a separate legal entity, how it must be filed or recorded, and what the participants may and may not promise each other. Confirm the governing authority with your attorney before drafting, because the rules differ meaningfully between states and change over time.

Governance: who decides, and by what vote

The single most useful thing an agreement can do is name the decision maker for each type of decision, then set the vote required.

• Board composition. Say whether each member gets one seat regardless of size, or seats scale with contribution. Name the position, not the person, so turnover does not break the board.
• Vote thresholds by decision type. Routine operating decisions can pass on a simple majority. Reserve supermajority or unanimous consent for changes that shift cost allocation, admit a new member, replace the core system, or amend the agreement itself.
• Deadlock and quorum. Define what happens when the board cannot reach a threshold. A standing rule that the status quo continues is better than an unwritten stalemate.
• Operational authority. Separate board decisions from the day to day authority of the host agency or administrator. Configuration changes, patching, and user provisioning should not require a board meeting.
• Change control. A shared system needs one roadmap. Establish how a member requests a change, how it is prioritized, and who pays when a change benefits one member only.

Cost allocation and what happens when usage grows

Cost formulas that were fair at signing drift as jurisdictions grow at different rates. Write the drift into the agreement rather than renegotiating under pressure.

• State the allocation basis explicitly. Fixed equal shares, population, assessed value, call volume, named users, or transaction counts each produce different winners. Pick one, define the data source, and name who calculates it.
• Set a recalculation cadence. Annual recalculation against the prior period is common. Consider a cap on how much any member's share can rise in a single year, with the excess phased in.
• Separate capital from operating. Say who funds initial implementation, who funds refresh and major version upgrades, and how a new member buys into capital already spent.
• Handle non-appropriation. Member governments budget annually and cannot always bind future councils. Decide in advance what happens when a member does not appropriate: suspension, a cure period, or treatment as notice of withdrawal.

Data ownership, access, and public records

Shared systems blur custody, and public records law does not follow the server.

• Ownership stays with the originating agency. State that each member owns the records it creates and that the host or joint entity holds them as custodian, not as owner.
• Define cross member visibility. Specify which record types other members can see, at what granularity, and whether access is read only. Enforce it with roles in the system, not with a promise.
• Assign records request responsibility. The member whose record is requested should respond to the request. The host should be required to assist with retrieval and prohibited from releasing another member's records unilaterally.
• Account for differing retention schedules. Members may sit under different schedules. The system has to support member specific retention and legal holds.
• Note sector rules. Criminal justice data carries additional federal and state security and audit requirements. Confirm current requirements with your state's control agency rather than relying on a prior year's checklist.

Who holds the vendor contract

Either the host agency signs and members participate through the interlocal agreement, or a separate joint entity signs in its own name. Both work, but the agreement should address:

• Flow down. Service levels, uptime credits, security obligations, data return rights, and termination assistance should benefit every member, not only the signer.
• Remedies. If members are not parties to the vendor contract, give them a defined path to enforcement, such as a duty on the signer to pursue remedies on request.
• Single point of direction. Name who may issue direction to the vendor. Vendors receiving conflicting instructions from several members will default to whoever speaks loudest.
• Renewal and escalation. Require board approval before renewal, price escalation, or scope expansion.

Liability when one member's mistake affects everyone

Allocate responsibility so a single bad act does not become a shared loss.

• Make each member responsible for its own acts and omissions, subject to your state's limits on public entity indemnification and any governmental immunity provisions.
• Address credential and access failures specifically. If a member's compromised account causes an incident, say who bears notification, credit monitoring, and forensic costs.
• Give the board a suspension remedy so access can be cut quickly without terminating the whole arrangement.
• Require insurance or pooled coverage at defined limits, and confirm the coverage actually reaches shared technology risk.
• Include a dispute ladder: staff escalation, board review, then mediation, before litigation.

Exit: notice, buyout, and data extraction

Exit terms determine whether members negotiate in good faith for the life of the agreement.

• Notice tied to the fiscal year. A withdrawal effective mid budget year is disruptive to everyone. Require notice far enough ahead that remaining members can rebuild their budgets.
• Financial settlement. Define the departing member's obligation for unamortized capital and for its share of any remaining vendor commitment, using a stated formula.
• Data extraction as a right, not a favor. Specify the format, completeness (including attachments, audit logs, and code tables), the timeline, and who pays. Require a test extract on a set cadence so nobody discovers at exit that the export is unusable.
• Transition access. Provide a defined period of read access after the effective date, and address whether the departing member may take an assignment of its own vendor licenses.
• Dissolution. Say what happens if the whole arrangement ends: who keeps the contract, how residual assets and reserves are divided, and how records are returned.

How to start

1. Confirm the statutory authority and any filing or recording requirement with counsel before drafting.
2. Draft governance, cost allocation, and exit first. Choose the system afterward.
3. Ask the vendor, in writing, what its export produces, whether it supports member specific retention and role based separation of member data, and what it charges for termination assistance.
4. Put a test extract and a governance review on a recurring calendar, not in a binder.

HQT works with state and local agencies on systems engineering and technology advisory support for shared and multi agency platforms, including data separation, extraction, and transition planning.

Frequently asked questions