Writing a surveillance technology use policy and impact report

Reference article · 7 min read

A growing number of cities and counties, and a few states, require an agency to produce two written documents before it acquires or begins using a surveillance technology: an impact report and a use policy. The ordinances differ in scope and in what they call these documents, but the structure is consistent. The impact report describes the system, what it collects, what it costs, and what it could do to people. The use policy sets the rules the agency agrees to be held to afterward. Both are public records, both are usually attached to a council or board agenda item, and both are read closely by people who will testify.

Staff often treat the two as a single writing assignment and produce one document that describes the product in the vendor's language and promises to use it responsibly. That is the version that comes back from the dais with amendments, or with a continuance. The sections below separate the two documents, say what belongs in each, and show the difference between sentences that hold up in a public hearing and sentences that invite rewriting.

Confirm what is covered before you write

Read your own ordinance first, and read it with counsel. Definitions of covered technology are usually broad, reaching any equipment or software capable of collecting information about individuals or groups, with a list of exclusions for routine office and infrastructure systems. Three points cause most of the trouble:

The trigger is not only purchase. Many ordinances also cover a new use of an existing system, acceptance of donated or grant-funded equipment, a no-cost pilot or trial, and entering a data-sharing agreement that lets your agency query another jurisdiction's system. A free trial that quietly becomes operational is a common source of after-the-fact findings.
Approval is legislative, not administrative. Where the ordinance requires governing body approval, a department head cannot sign a subscription and treat the policy as paperwork to follow later.
Requirements change. Some states layer additional obligations on specific technologies, such as separate policy and publication requirements for automated license plate readers or for military-style equipment. Confirm current requirements with the official source and your counsel rather than relying on a prior year's template.

The impact report: describe the system honestly

The impact report is descriptive. It should let a reader who has never heard of the product understand what will happen in their neighborhood. Cover, at minimum:

Purpose. State the specific problem and how the system addresses it. Avoid listing every capability the product has if you do not intend to use all of them.
Information collected. Enumerate each data element, including information collected incidentally about people who are not the subject of any investigation. Say whether collection is continuous or event-based, and what precision the data carries.
Fiscal cost. Acquisition, recurring license and storage, staff time to operate and audit, training, redaction and public records burden, the funding source, and what happens to the recurring cost when grant funding ends.
Civil rights and civil liberties impact. Describe plausible harms rather than asserting there are none: uneven deployment across neighborhoods, chilling effects on lawful activity, consequences of a false match, and the difficulty a person would have learning they were affected. A report that claims no impact reads as unserious.
Mitigations and alternatives. For each identified harm, name the specific control. List the less intrusive alternatives you considered and why they were insufficient.
Data flows. Where data is hosted, which subprocessors touch it, whether the vendor may access or reuse it, and whether other agencies can query it by default.

The use policy: write rules, not intentions

The use policy is operative. Every sentence should be something an auditor could test. Include authorized uses stated as an exclusive list, expressly prohibited uses, the job classifications permitted to access the system and at what level, any required approval before a particular query or deployment, retention periods and how deletion is enforced, the conditions under which data may be shared and with whom, training required before access is granted, audit methods and cadence, the complaint path for members of the public, and the consequences of a violation.

Reconcile retention against your state records retention schedule and evidentiary hold obligations before you publish a number. A policy promising rapid purge that conflicts with a litigation hold will be amended, either from the dais or later by your records officer.

Language that survives public comment

The pattern is the same in every category: replace a promise about intent with a rule that names an actor, a period, or a mechanism.

Weak: The system will be used for legitimate public safety purposes.

Stronger: The system may be used only for the purposes listed in Section 3. Any additional use requires an amendment to this policy approved by the governing body.

Weak: Data will be retained no longer than necessary.

Stronger: Records are deleted automatically [N] days after collection by a scheduled process, except records placed under a documented legal hold, which are listed in the annual report by count.

Weak: Access is limited to authorized personnel.

Stronger: Access is limited to the classifications listed in Section 5, enforced by role in the system, and the account list is reviewed and reduced quarterly by the system owner.

Weak: Audits will be conducted periodically.

Stronger: The department audits a random sample of queries each quarter, the audit is performed by staff outside the using unit, and results are reported annually.

Avoid capability language copied from marketing materials, avoid the passive voice where it hides who acts, and do not promise anything the system's logs cannot prove.

What to ask the vendor and put in the contract

Ask for a full field list and the audit log schema, and confirm the logs are complete, tamper-evident, and exportable without vendor assistance. Ask what the product can do that you do not intend to enable, whether those functions can be disabled, and how you can verify they are off. Ask whether deletion is enforced by configuration, whether it propagates to backups and to any vendor-side copies, and how deletion is evidenced. Ask whether sharing with other customer agencies is on by default.

In the contract, require that the agency owns its data, that the vendor may not use it for product development or model training without written consent, that the vendor gives notice of legal process where lawfully permitted, that audit logs are exportable in a usable format, that a deletion certificate is issued at termination, and that the vendor supplies the usage figures your annual report requires. Make the award or the go-live contingent on adoption of the use policy, so a rejected or heavily amended policy does not leave you holding a signed subscription.

Running the process

Draft both documents with the people who will operate the system, post them early enough for real comment, and publish a redline showing what changed in response. Configure the system on day one to produce the counts your annual report will need, rather than reconstructing them a year later. Keep the policy under version control and send every substantive amendment back through the same approval path.

HQT works with state and local agencies on technology governance, systems engineering, and the documentation that supports public review of a proposed system.

Frequently asked questions

What is the difference between a surveillance impact report and a surveillance use policy?

The impact report is descriptive: it explains what the system is, what data it collects, what it costs to buy and operate, and what effects it could have on civil rights and civil liberties. The use policy is operative: it states the authorized uses, who may access the system, how long data is kept, when it may be shared, what training is required, and how use is audited. Most ordinances require both to be published before the governing body votes. They serve different readers, so combining them into one document usually weakens both.

Does a free trial or grant-funded equipment require a surveillance impact report?

In many jurisdictions, yes. Ordinances commonly define the trigger as acquisition or use rather than purchase, which captures no-cost pilots, donated equipment, grant-funded systems, and new uses of technology the agency already owns. Check the specific language in your ordinance with counsel, because scope and exclusions vary and are amended over time.

Can we adopt the vendor's template use policy?

A vendor template is useful as a starting checklist of system capabilities, but it is written to describe the product rather than to constrain your agency. It typically omits the local elements reviewers care about most: named job classifications with access, retention reconciled to your state records schedule, sharing restrictions, audit cadence and who performs the audit, and the consequences of a violation. Rewrite it in your own terms before it goes on an agenda.

How long should we retain data from a surveillance system?

There is no single correct period, and the answer is set by your state records retention schedule, any technology-specific state requirements, and evidentiary hold obligations, not by the vendor's default configuration. Set the period with your records officer and counsel first, then confirm the system can enforce it automatically and that deletion reaches backups and any vendor-held copies. A policy that promises a shorter period than your retention obligations allow will have to be amended.

What belongs in the annual surveillance report many ordinances require?

Typically a summary of how often the system was used and for what purposes, any data sharing that occurred, the results of audits, complaints received, violations found and the action taken, and the actual annual cost. The practical lesson is to configure logging and reporting when the system is first deployed, since reconstructing a year of usage counts after the fact is difficult and often incomplete.