Surveillance Technology Ordinance: Companion Recommendations and Implementation Notes

Surveillance Technology Ordinance: Companion Recommendations and Implementation Notes

Companion to the July 2026 Draft (Version 8.1) of the Automated Surveillance Technology Governance Ordinance

This document provides non-binding examples and recommendations for how the City of Oshkosh, the Oshkosh Police Department, the Information Technology function, and the designated Relevant Board or Commission may implement the ordinance. It is intended to guide administrative policy, procurement, and standard operating procedures. It does not itself create legal obligations, and where it differs from the adopted ordinance, the ordinance controls.

It is written primarily for staff in technical and operational roles who need practical starting points for meeting the ordinance's objectives. Section references point to the corresponding provisions of the Version 8.1 draft.

1. Administrative Structure and Role Designation

1.1 Cybersecurity Officer Designee

The ordinance permits the City to satisfy the Cybersecurity Officer role (Section 2.1) by formal designation rather than by requiring an existing job title, and expressly permits the designee to be a City employee or a qualified contractor or consultant engaged by the City, so long as the designation is in writing, the designee acts under the direction of a City official, and accountability remains with the City. Where existing staff capacity is limited, a contracted designee with a named accountable City official is a compliant configuration. A practical implementation approach would be for the City Manager or Information Technology Director to designate, in writing, the person responsible for the duties assigned under the ordinance and to identify backup coverage for absences or emergencies. Because the role carries certification and verification duties at multiple points (Sections 3.1, 3.5, 3.7), the designation should also name who may act when the primary designee is unavailable. Recommended assignments for this role include certifying the deactivation of emergency deployments under Section 3.1 and coordinating the independent architecture verification under Section 3.5, both of which the ordinance states as outcomes without naming the responsible official.

1.2 Respect for Existing Governance Authorities

The Relevant Board or Commission should operate as an advisory and auditing body rather than as a disciplinary or command body, consistent with Section 7.1. Internal policies should expressly recognize that nothing in the ordinance transfers authority reserved by law to the Police and Fire Commission, the Chief of Police, the City Manager, or the courts.

For the Police Department, operational procedures should be drafted by or under the authority of the Chief of Police so that the ordinance sets the policy floor while the Department retains appropriate control over workflows, staffing, and emergency-response mechanics.

1.3 Designating the Relevant Board or Commission

The ordinance (Sections 2.1 and 7.1) requires the Common Council to designate, by resolution, a Relevant Board or Commission to perform the oversight, review, and advisory functions of the ordinance, and allows the Council to designate an existing body or create a new one. Until a designation is made, the Council itself performs these functions. The choice is the Council's; the options below are offered to inform it, in rough order of fit.

Option A (recommended): establish a dedicated body, such as a Privacy and Data Ethics Commission. A purpose-built body (whether styled a commission, board, or advisory board) is the strongest fit because the workload is specialized and recurring: annual report review, RBAC change reports, exigent-access reports, audit results, complaint review, and biennial ordinance review. A recommended composition, consistent with the ordinance's vendor-conflict prohibition:

• One Common Council member, rotating annually.
• The City's Cybersecurity Officer as an ex officio, non-voting member, because the Officer produces certifications (Sections 3.1, 3.5, 3.7) that the body reviews.
• The Chief of Police or designee.
• At least three resident community members who collectively bring expertise in civil liberties, data privacy, technology or cybersecurity, or the interests of communities most affected by surveillance, appointed through the City's standard appointment procedures with staggered terms, and who are not current or former law enforcement.
• A composition in which current City employees and officers do not constitute a majority.

Option B: the Diversity, Equity, and Inclusion Committee. An existing Council-created advisory committee whose charge (advising the Manager and Council on equity and inclusion) aligns with the ordinance's disparate-impact analyses (Sections 3.2 and 7.2). Cautions: its five-member composition is small for this workload, its current charge would need to be amended by the Council to add these functions, and the technical review components (RBAC reports, audit results) fall outside its present expertise, which argues for adding technically qualified members if designated.

Option C: the Long Range Finance Committee. A fit for the procurement, cost-benefit, and contract-term aspects of the ordinance (Sections 3.1, 3.3, 7.2 cost-benefit reporting). Cautions: civil-liberties and community-impact review is outside its charge, and pairing it with a second body would split the oversight record.

Option D: the Common Council itself, or a standing Council committee. The most democratically accountable option, and the ordinance's default pending designation. This mirrors the committee-of-jurisdiction model used in some peer cities. Cautions: Council bandwidth, and the loss of the specialized, continuous attention a standing body develops.

Not recommended: the Police and Fire Commission. The PFC's statutory role under Wis. Stat. section 62.13 is personnel (appointment, discipline, promotion). Assigning it oversight of the technology used by the department whose chief it appoints and disciplines mixes lanes the ordinance is elsewhere careful to keep separate (Section 8.5), and its composition rules were not designed for this function. Whichever body is designated, the ordinance's structural rules apply: no member may have a financial interest in an actual or prospective Vendor, and the body acts in an advisory and oversight capacity only.

2. Security Outcomes and Technical Approaches

2.1 Outcome-Focused Security Model

The ordinance focuses on outcomes rather than mandating a single architecture (Section 3.5). Implementation documents should preserve that same approach. The controlling questions are whether the City remains the sole plaintext controller and sole key-holder, and whether the Vendor remains technically unable to access plaintext Agency Data under ordinary operation or in response to legal process directed solely at the Vendor.

2.2 Edge Inference and Secure Enclaves

Two examples of architectures that may satisfy the ordinance are:

• True edge inference or edge processing. AI inference runs on City-controlled edge hardware, and plaintext Agency Data never leaves that environment except under City-controlled protections.
• Protected remote processing using secure enclaves or equivalent confidential-computing methods. Data may be processed on remote infrastructure only if the City can verify, through attestation or equivalent technical evidence, that the Vendor and cloud provider cannot access plaintext Agency Data and that keys remain under City control.

These examples are illustrative only. The City may adopt other architectures if they meet the ordinance's required outcomes, and may record approved methods in the technical standards contemplated by Appendix A.

2.3 Vendor CISO or Superior Attestation

The ordinance keeps a senior officer of the Vendor on the line (Section 3.5). Procurement and contract documents should preserve the requirement that the annual compliance attestation be signed by the Vendor's Chief Information Security Officer, or a superior officer with equivalent authority, not merely by sales, support, or implementation personnel.

2.4 Architecture Verification Evidence

Section 3.5 calls for verification at initial deployment and at least once every two years thereafter, performed by an Independent Security Auditor whose work the City coordinates and reports to the Relevant Board or Commission. Staff should decide in advance what verification evidence the Vendor must produce on a repeatable basis, for example data-flow documentation, network-traffic or egress evidence showing only ciphertext leaves City-controlled hardware, key-management control documentation, and enclave attestation reports where applicable. Defining this evidence set during procurement avoids disputes later about what "verification" requires.

3. Records Retention, Legal Holds, and Fallback Controls

3.1 State Records-Retention Approval

Short retention periods for non-hit data should be treated as contingent on required approval from the applicable state records-retention authority (Section 4.2). In Wisconsin, that means Wis. Stat. § 19.21(4): a municipality may set retention schedules by ordinance, but periods shorter than seven years require approval by the Wisconsin Public Records Board, and records must be offered to the Wisconsin Historical Society at least 60 days before destruction unless the Society has waived notification for that record series. Staff should pursue the Public Records Board approval and the Historical Society waiver as part of implementation. Until such approval is obtained, the City can still honor the ordinance's privacy goals by implementing fallback controls that reduce practical use of stale non-hit data even if legal deletion cannot yet occur.

Examples of fallback controls include:

• Administrative suspension of routine user access to non-hit data beyond the intended retention period.
• Requirement for elevated supervisor approval for any access beyond the intended retention period.
• Segregation of older non-hit data into a restricted archive pending lawful disposal.

The ordinance requires extended retention of non-hit data (beyond the seven-day default, up to the thirty-day maximum) to be justified in writing and approved as provided by departmental procedure. The recommended procedure is approval by the Chief of Police or designee, with the justifications compiled for the annual review by the Relevant Board or Commission.

3.2 Legal Hold Process

The City should maintain a written legal-hold and preservation process covering public-records requests, litigation holds, evidence preservation duties, and court orders, consistent with Section 4.2 and the definition of Cryptographic Deletion in Section 2.1. Where lawful and technically feasible, preserved records may be copied or transferred into a separate controlled retention location so that operational datasets can continue to age out while preserved records remain available. Because cryptographic deletion is irreversible, the process should ensure a hold is applied to the relevant records, and their keys, before any scheduled deletion runs.

3.3 Audit Log Retention

Because state records-retention requirements may require longer retention than operational privacy preferences would otherwise suggest, activity logs and audit trails should be retained for the longer legally required period, in no event less than seven years, unless and until a shorter lawful schedule is approved (Section 4.2).

4. Historical Access and Emergency Use

4.1 Predicate-Gated Historical Access

The ordinance treats access to data older than twenty-four hours as non-standing, predicate-gated access rather than as a permanently assigned role capability (Section 4.3). The City may implement this using any reasonable method, including a temporary access flag, a just-in-time permission workflow, or another access-control method consistent with the ordinance.

The ordinance does not require a particular software design. It only requires that:

• no user role has standing historical access beyond twenty-four hours;
• judicial-order-based access is temporary and logged; and
• exigent access is temporary, documented, and reviewable.

4.2 Operationalizing the Off-Hours Exigent Check

Section 4.4 of the ordinance requires the Chief of Police to establish written procedures that define the authorizing rank (with coverage when that rank is unavailable), the documentation for each authorization, and the internal review that applies. The recommended content for those procedures is: authorization by a supervisory officer of rank Lieutenant or above, with fallback to the highest-ranking officer on duty when no Lieutenant or above is available; written documentation within two hours of the search or as soon thereafter as practicable; and reporting to the Relevant Board or Commission within twenty-four hours (the ordinance's outer bound is seven days). To make this practical during off-hours, the Chief may wish to adopt a short, durable checklist or decision aid that can be used quickly in the field or from home. A workable internal form might prompt the authorizing supervisor to record:

• the immediate threat or missing-person circumstance;
• why waiting for a judicial order would create material risk;
• the specific scope of the search requested;
• the rank and identity of the authorizing supervisor, and, where a Lieutenant or above was not available, the reason; and
• the follow-up deadlines for documentation (recommended within two hours), reporting to the Relevant Board or Commission (recommended within twenty-four hours; ordinance outer bound seven days), and initiation of retroactive judicial review (within seventy-two hours where applicable, per the ordinance).

That approach gives the Department operational flexibility while keeping the ordinance itself focused on outcomes and accountability. The ordinance requires retroactive judicial review to be initiated through appropriate legal channels without prescribing the filing pathway. The recommended pathway is through the Winnebago County District Attorney's Office, and the Department should coordinate the application format and filing route with that office in advance, using the retroactive-authorization procedure of Wis. Stat. § 968.373(8g) as a working template.

5. Access Control, Logging, and Justification Quality

5.1 Recommended Access Tier Model and Just-in-Time Elevation

Section 5.1 of the ordinance states access-control outcomes (least privilege, no standing historical access, documented authorization, heightened cross-jurisdiction authorization, and administrative separation) and directs the responsible department to define the specific roles by written administrative policy. A recommended four-tier model that implements those outcomes:

• Tier 1, real-time alert response (patrol officers): access to live hotlist-match alerts only; no retroactive search capability.
• Tier 2, active investigation search (detectives, investigators): retroactive search within the twenty-four hour window preceding the query, subject to documented case number and supervisor authorization for each search session; older data requires temporary access under Section 4.3 or exigent authorization under Section 4.4.
• Tier 3, cross-jurisdiction or extended search (supervisors or designated senior investigators): access to inter-agency shared data; requires written supervisor approval, documented legal predicate, and temporary access under Section 4.3 for data older than twenty-four hours.
• Tier 4, system administration (information technology staff): access to system configuration, audit logs, and RBAC management; no access to Agency Data content.

Section 4.3 makes historical access non-standing. In practice this means provisioning should default to the least-privileged tier, with elevation to historical access granted only for a specific, logged predicate and revoked when the search session ends. Where the system supports it, time-boxed or session-scoped permissions are a clean way to implement this.

5.2 Search Justification Quality

Section 5.2 requires a case number or, where none exists, a specific legal basis identifying the investigation or proceeding, and states that generic terms such as "investigation" are insufficient. Technical staff should configure the system, to the extent feasible, to require a structured justification field, reject or flag obviously generic entries, and make the justification a mandatory, non-skippable step before a search executes. Periodic sampling of justification quality is a natural input to the compliance-monitoring program under Section 7.6.

5.3 Immutable Logging and RBAC Change Notifications

Sections 5.2 and 5.3 require tamper-resistant logs and prompt notification of access-control changes. Implementation points worth confirming during procurement and configuration:

• search and export logs are append-only and not selectively modifiable or deletable by any user, including administrators, during the retention period;
• RBAC changes are logged automatically at the moment of execution, with no pathway to change permissions without logging;
• RBAC change reports are generated and delivered to the full Relevant Board or Commission; the ordinance requires a cadence no less frequent than monthly, and a weekly automated report is the recommended standard; and
• high-risk changes (granting elevated or cross-jurisdiction access, creating a new administrator account, or any change made outside normal business hours) trigger an out-of-cycle alert to the chair or designee of the Relevant Board or Commission; the ordinance requires prompt escalation under an administrative standard, and a one-hour alert is the recommended standard.

Automating the weekly report and the critical-alert path avoids reliance on manual reporting.

6. Third-Party Data Access and Just-in-Time Provisioning

Sections 4.7 and 5.5 govern access to outside surveillance or location-data networks whose data is not retained as Agency Data. The implementation goal is that such access is event-by-event, not standing.

Practical measures include:

• no persistent subscription, stored credential, or continuous feed to a third-party network without affirmative Council approval under Section 3.1;
• provisioning each access event for a specific authorized query, scoped to the data source, time window, and parameters, with access revoked immediately on completion;
• applying the same supervisor authorization for queries within twenty-four hours, and a judicial order for queries seeking older data, as required by Section 4.7; and
• logging each third-party access event as if it were a search of Agency Data, and including these events in the annual report.

Staff should also watch for the substitution rule in Section 4.7: a pattern of routine or programmatic third-party access can itself qualify as a deployment subject to the full Article III review.

7. Hotlist Management and Accuracy

Section 4.6 limits what may go on a hotlist and requires accuracy and completeness consistent with the data-quality principles of the federal Privacy Act of 1974. Useful implementation practices include:

• recording, for each entry, the documented case number, warrant, or alert identifier, the source system or agency, and an expiration or review date;
• scheduling periodic reviews to confirm entries remain current and justified, at intervals set by administrative policy; and
• maintaining a procedure to correct or remove entries promptly when a court, prosecuting authority, or originating agency resolves or withdraws the underlying matter.

8. Duty to Report and Non-Retaliation

Section 5.6 establishes an individual duty to report suspected misuse, enforced through the discipline provisions, with protection against retaliation. To make this usable rather than theoretical:

• identify the specific channel a user should use (the established misconduct-reporting process), and confirm it connects to the Section 7.3 incident-reporting flow to the Relevant Board or Commission;
• make the channel easy to find and, where appropriate, usable confidentially; and
• ensure the City's anti-retaliation protections clearly cover good-faith reports made under this Section.

A reporting duty only works if the place to report is clear and reporters are protected, so confirming the channel and the protection is the practical priority.

9. Individual Data Rights Intake

Section 4.8 gives residents a right to inquire whether their data is retained, and a limited right to challenge accuracy. A simple, repeatable intake process helps the City respond consistently. Consider:

• a single written intake point (form or designated contact) for inquiries and accuracy challenges;
• reasonable identity-verification steps so the City does not disclose data to the wrong person;
• a workflow that checks active-investigation and legal limits before responding;
• coordination with the City's Wisconsin Public Records Law process, since the saving clause in Section 4.8 neither expands nor limits those separate rights; and
• a way to log the request and outcome so the totals can be reported under Section 7.2.

10. Inter-Agency Sharing and Federal Process Handling

Sections 6.1 through 6.6 set a default of no sharing, with narrow, documented pathways. Implementation notes:

• keep vendor-operated network or cross-agency query features technically disabled by default, allowing only the narrow hit-notification function described in Section 6.4;
• use a standard Council-approved Memorandum of Understanding template for any ongoing sharing relationship, capturing the requesting agency, permitted data, purpose, recipient retention limit, and the recipient's no-re-sharing obligation;
• route any federal request, and any subpoena, national security letter, or similar process, to the City Attorney's Office, with no disclosure absent City Attorney sign-off except where a court orders immediate compliance (Section 6.6); and
• maintain the permanent disclosure-accounting record required by Section 6.5 so external disclosures can be reported annually.

Because the federal-access rule (Section 6.3) turns on a warrant served on the City, intake staff should be trained to recognize the difference between a warrant and other compulsory process, and to escalate rather than respond directly.

10.1 No-Conduit Certification and Look-Through Rule

These steps operationalize the anti-laundering, or "no-conduit," requirement now stated directly in Section 6.2 of the ordinance: a requesting agency may not be used as a pass-through to obtain Agency Data for a federal agency or any other entity that would otherwise need a warrant under Section 6.3, and every request must include a written certification to that effect. The measures below implement that requirement through Memorandum of Understanding terms and intake procedure.

Per-disclosure certification. Build a short written certification into the request-intake form so that no inter-agency disclosure proceeds without it. The requesting agency certifies that the request:

• is made on its own behalf, and not in whole or in part to obtain Agency Data on behalf of, at the direction of, or for furnishing to a federal agency or any other entity; and
• is not made for, and the resulting data will not be used for, any purpose prohibited under Section 4.5.

Look-through (true-originator) rule. Train intake staff that the originating purpose and the ultimate intended recipient, not the identity of the agency that physically submits the request, determine which pathway applies. A request that originates with, is directed by, or is intended to furnish data to a federal agency is handled under the Section 6.3 warrant pathway, regardless of which agency submits it.

Recipient use and re-sharing limits. Extend the Section 4.5 use restrictions to the recipient's use of any shared data, and include in the MOU template an express prohibition on re-sharing or making the data accessible to any third party, including other law enforcement or federal agencies.

Consequences. Treat a materially false certification, or the provision of Agency Data to fulfill a federal-originated request without Section 6.3 compliance, as grounds for immediate MOU suspension pending review by the Relevant Board or Commission, consistent with the Section 6.2 enforcement mechanism.

Legitimate joint work is not blocked. Genuine joint task-force activity in which a federal agency is properly participating is routed through the Section 6.3 warrant pathway, which already contemplates a state-court warrant issued where a federal agency participates in an authorized investigative capacity. The certification directs such requests to the warrant pathway rather than denying cooperation.

Recordkeeping. Capture the certification with the Section 6.5 disclosure-accounting record so it is auditable, and include certification-related suspensions or refusals in the annual report under Section 7.2.

11. Privacy Impact Assessment, Including Equity Analysis

Section 3.2 requires a Privacy Impact Assessment before procurement, and now includes a disparate-impact analysis and a siting-and-placement analysis. To produce a usable assessment:

• treat the equity analysis as a substantive section, describing whether the deployment could create or worsen disparate impacts on protected groups and what specific safeguards mitigate them; and
• document placement and siting criteria, including how locations are chosen and how that choice avoids targeting communities in a way not justified by the stated public-safety objective.

A reusable PIA template that tracks the Section 3.2 elements in order makes each future assessment faster and more consistent.

12. Open Meetings, Closed Session, and Redaction Practices

The Relevant Board or Commission will likely operate as a governmental body subject to open-meetings and public-records requirements. Internal procedures should identify when the Committee may rely on lawful closed-session grounds and how reports or minutes should be redacted to avoid disclosure of sensitive security or active-investigation information.

This subject is best handled through Committee rules of procedure or a separate administrative policy rather than by embedding detailed open-meetings mechanics in the ordinance itself.

13. Software Updates, Escalation Standards, and Security Fixes

Section 3.7 directs the responsible department to document its determination that an update qualifies as routine, and the City to document administrative standards identifying what categories of software or configuration changes are routine and what categories must be escalated as capability expansions. Those standards can be developed administratively and should avoid creating unnecessary delay for security patches.

A practical internal classification model could distinguish among:

• routine maintenance and security fixes that do not expand functionality;
• changes that alter data collection, retention, sharing, or analytics capabilities;
• emergency patching needed to address active or high-risk vulnerabilities; and
• major platform upgrades requiring formal review.

The point is to document the threshold for escalation, not to require Council review of every patch. A fast lane for genuine security fixes keeps the ordinance's patch-management expectations (Section 3.4) and its capability-review expectations from working against each other.

14. City-Operated Systems

Where the City directly deploys and operates a system without a third-party Vendor, the City should document how it achieves the same substantive protections required of external Vendors (Section 3.5). A practical self-operation compliance package could include:

• written designation of responsible officials;
• internal architecture and key-management documentation;
• internal logging and access-control standards;
• independent verification by the Independent Security Auditor; and
• a written variance or equivalency memo explaining which contract-specific vendor provisions do not literally apply and what internal control substitutes are used instead.

15. Annual Reporting and Community Meeting

Sections 7.2 and 7.7 call for an annual public report followed by a community meeting. To make the reporting load manageable, instrument the system from the start so the required metrics can be produced as a report rather than reconstructed by hand. The fields in Section 7.2 (search counts by role or category, historical-search counts with judicial-order and exigent breakdowns including the outcome of any retroactive judicial review, violations and outcomes, RBAC change summaries, external disclosures, third-party access events, data-rights requests, security incidents, cost-benefit, complaints, federal-process counts, the civil-rights impact analysis, and the list of capability expansions and routine-update determinations) map directly to logs and records the ordinance already requires, so most of the report can be generated if those logs are captured cleanly.

For the community meeting, decide in advance who hosts (Committee, Council, or jointly), schedule it within sixty days of the report, and provide both in-person and written or electronic comment options.

16. State-Law Change Conformance

If state or federal law changes, the City should first determine whether the new law truly requires weakening an existing local protection or merely sets a floor that the City can exceed. The ordinance intentionally preserves the stronger local rule unless controlling law requires otherwise (Section 9.1).

For administrative practice, the Relevant Board or Commission and City Attorney may wish to maintain a short conformance checklist:

1. What legal provision changed?
2. Does it expressly preempt stronger local protections?
3. Does it require any immediate operational change?
4. Can the City retain its stronger local rule?
5. What ordinance or SOP updates, if any, are needed?

17. Items Better Left Out of the Ordinance

To keep the ordinance durable and avoid over-prescription, the following subjects are generally better handled in this companion document, in procurement documents, or in departmental SOPs rather than in the ordinance text itself:

• detailed log field schemas and dashboard layouts;
• exact attestation payloads or software-update review timelines;
• precise alert-routing trees;
• field-level workflows for supervisors and investigators;
• specific access role and tier definitions, and RBAC reporting cadences;
• detailed secure-enclave implementation specifics;
• intake forms and identity-verification steps for data-rights requests; and
• staffing and budget assumptions, including the future fiscal note.

This preserves the ordinance as the statement of the City's end goals while allowing the City and Department to refine the means of implementation over time.