How a technology policy gets adopted by a council or board

Reference article · 5 min read

Most technology policies stall in the weeks between a finished draft and a vote, not in the drafting. An acceptable use policy, a records retention schedule, or a rule on staff use of generative AI can be well written and still sit for months because nobody decided what form the item should take, who had to clear it before it reached an agenda, or what the governing body is actually being asked to approve.

The path is more predictable than it looks. It divides into four parts: choosing the instrument, clearing internal review in the right order, writing a staff report the body can act on, and drafting delegation and review language that prevents a new vote every time a technical detail changes.

Decide what instrument you actually need

Not every technology policy belongs on a council or board agenda. Ask your clerk and your attorney which instrument the matter requires. The answer depends on your charter, your state's local government code, and your own adopted rules, which vary. Some subjects, including surveillance technology, retention schedules, and law enforcement data, are governed by law that dictates both the instrument and the process.

Ordinance. Used where the policy creates enforceable duties on the public, imposes penalties, or amends a municipal or county code. Ordinances commonly require more than one reading and a waiting period before taking effect.
Resolution. A single-meeting action that states the body's position, adopts a document by reference, or delegates authority to staff. Most internal technology policies that need legislative blessing travel this way.
Administrative directive or policy manual update. Issued by the chief executive, manager, or department head under authority the body already granted. Faster, and appropriate for operational detail.
Board policy. School boards, transit boards, and special districts often maintain a numbered policy series with companion administrative regulations.
Budget or appropriation action. New spending, positions, or a contract above the staff signing threshold is a separate item, even on the same agenda.

Settle ownership and the review chain early

Name one owner who is responsible for the text, the calendar, and the answers at the dais. Committees do not hold pens well.

Legal review. Counsel should see the draft twice: once early for form and authority, once on the final version attached to the report.
Labor review. If the policy changes discipline, monitoring, working conditions, or the tools employees use, it may trigger a bargaining or notice obligation. Those obligations and their timelines differ by state and by contract, so involve HR and labor relations before the item is calendared.
Records and disclosure. The records officer should confirm that retention, legal hold, and disclosure handling in the draft match the schedule you operate under.
Clerk's calendar. Agenda packets close well before the meeting. Work backward from that deadline and treat it as fixed.

Write the staff report for the decision

The report is the record. Write it so a member who has never heard of the system can vote with confidence.

Recommended action, in the exact language the body will move.
Background, including what rule governs today and why it is insufficient.
What changes for employees, for residents, and for existing contracts.
Fiscal impact, stated plainly, including a statement of none where that is true.
Legal review, noting counsel has approved the item as to form.
Alternatives considered, including doing nothing.
Attachments: the clean policy, a redline against the current version, and any referenced standard.

Separate the policy from the standards beneath it

The most common drafting error is putting technical detail in the adopted instrument. Encryption choices, supported versions, and approved product lists change faster than a governing body meets. Adopt principles, responsibilities, and enforcement in the policy. Put the changeable specifics in standards the CIO maintains administratively.

Make the delegation explicit. Language authorizing the chief information officer to issue, amend, and publish standards consistent with the adopted policy, with notice to the body on material changes, keeps staff from returning to the dais for routine updates.

Give the policy a real effective date. Ordinances often carry a waiting period set by law. For internal policies, an adoption date and a later operative date give staff time to train, update forms, and notify vendors. Say which systems and contracts in flight are covered and which are grandfathered until renewal.

Build the review cadence into the text

A policy without a review clause goes stale quietly. Write the cadence into the document: a scheduled review by the owning department, a short report to the body on defined topics such as exceptions granted and incidents, and a review triggered by a new system class, a new law, or an audit finding. Tie the reporting date to something already on the calendar, such as budget adoption.

How to start, and what to carry into contracts

Pull the current rule and mark what is out of date. Ask the clerk which instrument similar items used and how far out the calendar is booked. Circulate a one-page summary to legal, HR, and records before you draft, and ask each what would make them object. Then write the draft, the standards, and the staff report together, because the report exposes gaps in the policy.

Once adopted, the policy should reach your agreements. Require in solicitations and contracts that the vendor conform to the adopted policy by reference, that data location, retention, and deletion match your schedule, that the vendor give notice before material changes to subprocessors or to models handling your data, that vendor-held records stay producible under public records law, and that data returns to you in a usable format at termination.

HQT works with state and local agencies on technology policy, standards development, and systems engineering.

Frequently asked questions

Does an IT policy need a city council vote, or can staff adopt it administratively?

It depends on what the policy does and what authority already exists. Policies that bind only internal staff operations can often be issued as an administrative directive under authority the governing body previously delegated, while policies that create duties on the public, impose penalties, or amend the code generally require a legislative action. Local charters, state law, and adopted rules differ, so confirm the answer with your clerk and your attorney before you draft.

What is the difference between a resolution and an ordinance for a technology policy?

An ordinance is legislation that typically amends the code and, in many jurisdictions, requires more than one reading and a waiting period before it takes effect. A resolution is usually a single-meeting action that records the body's position, adopts a document by reference, or delegates authority to staff. Most internal technology policies that need the body's approval move as resolutions, but the required form varies by jurisdiction and subject matter.

What should the staff report for a technology policy include?

At minimum it should state the recommended action in the exact language the body will move, the background and why the current rule is insufficient, what changes for employees and residents, the fiscal impact, confirmation of legal review, alternatives considered, and attachments. The attachments should include the clean policy, a redline against the current version, and any standard referenced in the text. Write it so a member unfamiliar with the system can vote without asking for a continuance.

How can IT update technical standards without going back to the council each time?

Keep the durable material in the adopted policy and move changeable technical detail into standards and procedures maintained administratively. Include delegation language in the adopted instrument that authorizes the chief information officer to issue, amend, and publish those standards consistent with the policy, with notice to the body on material changes. That structure lets routine updates happen without a new agenda item.

How often should an adopted technology policy be reviewed?

Write the cadence into the policy rather than relying on memory. A common approach is a scheduled review by the owning department on a fixed interval, plus a review triggered by a new class of system, a change in law, or an audit finding. Tying the report date to something already on the calendar, such as budget adoption, makes the review more likely to actually happen.