The Privacy Schedule in a Street-Imagery Data Agreement

Street-imagery contracts between vendors and cities fail most often not in the main body but in the exhibit stapled to the back of it: the privacy schedule that sets blur timing, retention periods, re-identification checks, and what happens when someone files a records request for footage of their own driveway. Lawyers on both sides catch problems in the main agreement before signature, but nobody catches problems in the privacy schedule until a reporter, a plaintiff's attorney, or a city council member starts asking questions a year and a half later. I spent three years reviewing these schedules for a mid-sized city's IT procurement office, then two more on the vendor side drafting them, and the pattern never changed: the commercial terms get red-lined line by line, and the technical language gets a skim. That's backward, and here's why, section by section. ### Blur-Before-Storage Is a Timing Fight Every city I've worked with asks for automated blurring of faces and plates in street-level imagery, whether it comes off a mapping van, a delivery robot, or a fixed pole camera. Whether the system blurs is rarely the question; it does, almost always. The real question is when. Does the raw frame, unblurred, ever touch a disk before the blurring model runs? Or does the blur happen inside the capture pipeline, so the unprocessed frame exists only in volatile memory for the couple hundred milliseconds it takes the model to find a face and smear it? I once sat through a vendor demo where the answer to this question took forty minutes to extract, because the engineer kept describing the pipeline in terms of when blurring completes rather than when raw storage begins. Those are not the same thing, and if a raw frame gets written to disk before blurring runs, even for an hour, that frame is now a discoverable asset sitting on a server somewhere, and a subpoena or a breach can reach it. Write the schedule to require "blur-before-persist," rather than "blur-before-publish" or "blur-before-delivery." Those two lesser standards leave a window where raw data sits unprotected, and vendors know it. Vendors push back on blur-before-persist because it usually means redesigning the pipeline to run inference at the edge instead of the datacenter, which costs more in silicon and engineering time. Fair enough, and it's worth taking seriously as an engineering conversation, but don't let it lower the bar the city asks for. If the architecture genuinely can't support it yet, say so in the schedule: name the interim state, whether that's encrypted raw storage with access logging or a locked-down retention window, and set a hard migration date. Silence here is worse than an honest gap. The schedule also has to define blur as a technical method, not a procedural gesture. A Gaussian blur at a fixed radius is a different animal from pixelation, which is different again from a generative model that paints in a synthetic face. Privacy researchers increasingly favor the third option, because a known blur kernel is mathematically reversible under the right conditions and pixelation isn't much better. Ask the vendor point blank which method they use, and ask for the detection model's miss rate. A blur system that catches faces in the low-to-mid 90s percentage-wise in vendor testing still lets a real number of faces through untouched. The schedule should demand that number in writing, not accept "blurring is in place" as an answer. ### Retention Clocks Run From Capture, Full Stop Retention periods generate more fights in these negotiations than anything else, and they should, because retention decides how much of a city's public space sits in a searchable archive on any given Tuesday. The standard mistake, and I've made it myself early on, is letting the clock start at ingestion rather than capture. Say the contract promises 30-day retention but starts counting from "date of ingestion into the city's system." If the vendor's delivery pipeline has a two-week lag, which happens more often than vendors advertise, the effective retention just became 44 days without anyone changing a number on paper. State the period in days, tied to the capture timestamp on the file itself, not to whatever internal system clock the vendor prefers. Then there's the backup problem, which is the single biggest gap I've found reviewing these contracts. Deletion from an application database is not deletion from a cloud provider's backup snapshots. AWS, Azure, and most enterprise storage vendors keep backup retention policies that run independently of whatever the application layer does, sometimes for months. A schedule that doesn't address backups explicitly is a schedule where a 30-day promise quietly becomes an 18-month reality, discoverable the moment a forensic audit happens. Require the vendor to certify in writing that backups purge on the same schedule as primary storage, or disclose the separate backup window if one exists. One vendor I worked with had a 90-day cold storage tier nobody on the city side knew about until we asked directly, and it wasn't malicious; nobody had asked before. Derived data is the quieter cousin of this problem. Say raw imagery gets deleted on schedule, clean as promised, but the vendor pulled features out of it first, road sign locations, pothole coordinates, building footprints, before deletion. That derived dataset usually isn't covered by the same clock at all. Vendors will argue, reasonably, that a pothole coordinate isn't personal information and shouldn't be subject to the same retention rules as a face, and that's often true. The schedule needs to say so on purpose, in writing, rather than leave it as an assumption that gets litigated later when someone notices the derived dataset never got touched. ### Re-Identification Review Can't Be a One-Time Event Blurring reduces re-identification risk without eliminating it. A person's gait, a car's aftermarket rims, the specific pairing of a storefront awning and a delivery truck parked at 8:14 on a Tuesday morning, any of these can re-identify someone even with every face and plate obscured. This isn't speculation. Research on mobility traces going back over a decade, including the well-known work showing that four spatiotemporal points are enough to uniquely identify 95% of individuals in a supposedly anonymized dataset, established that a small number of contextual signals collapses anonymity fast, and street imagery carries far richer context than a location ping ever did. So the schedule needs a re-identification review that runs on a cadence, rather than a single certificate signed at contract execution and forgotten. Annual, at minimum, and more often if the vendor swaps detection models or changes the blurring method, because a model update changes what gets caught and what slips through, and nobody notices a regression until someone goes looking. Who does the review matters as much as how often. The team that built the blurring pipeline has every incentive to grade its own homework kindly. Bring in a third-party auditor, or use an internal privacy officer genuinely independent of procurement, if the city has one. Either works. What doesn't work is leaving "periodic review" undefined in the schedule, because in practice that phrase means never, and I've seen it mean exactly that for three years running on one contract before anyone flagged it. The review needs a specific test built into it, too: could someone with access to the footage, cross-referenced against a public dataset like property records or business licenses, plausibly re-identify a person in the frame. That's a harder bar than "is there an unblurred face," and it's the bar that actually matters, because the harm being guarded against is re-identification itself, not the presence of a stray pixel. ### Public Records Requests Are Where Theory Meets a Tuesday Afternoon This is the section everyone rushes through in drafting, and it's the one that ends up in the newspaper. Street imagery collected under a city contract is, in most states, subject to public records law the same way a police report or a budget line item is. "We'll figure it out when a request comes in" isn't a policy; it's a lawsuit waiting for a plaintiff. First question: who answers the request. If imagery sits on vendor infrastructure instead of city servers, the city generally can't hide behind that distinction; most public records statutes cover anything the government has a right to access or control, wherever it physically lives. The schedule should require the vendor to produce responsive footage within a fixed turnaround, so the city can hit its own statutory deadline, which in a lot of states runs five to ten business days, not weeks. Second question: who redacts. Imagery already blurred at capture is generally releasable as-is, but footage under legal hold, or raw footage pulled for a security review before it ever went through the blur pipeline, needs a redaction step before release, and somebody has to own that work and its cost. I watched a contract silent on this point turn into a six-week delay because neither the city nor the vendor had budgeted staff time to manually redact months of raw incident footage nobody expected to need redacting. Third question, and the one outside counsel will argue about longest: exemptions. Most states carve out law enforcement investigative material, security infrastructure, sometimes location data tied to critical infrastructure. Cite the specific statute in the schedule. Vague language like "applicable law" doesn't protect anyone; it just means the exemption argument gets built for the first time in a courtroom instead of at a drafting table, where it's cheaper and a lot less stressful to get right. ### The Schedule Needs a Pulse None of this holds if the schedule gets signed once and filed in a drawer. Blurring models get retrained, public records statutes shift, and several states have amended their laws in just the past few years specifically to address sensor and camera data collected under municipal vendor contracts, while city council priorities on retention change with every budget cycle. Build a review clause into the schedule itself, requiring both sides to revisit terms on a set cadence, ideally paired with the same annual re-identification review already discussed, so the whole thing gets checked together instead of one clause at a time whenever someone remembers. Cities negotiating their first street-imagery contract tend to treat the privacy schedule as boilerplate, something the vendor's legal team drafts and the city rubber-stamps. That's a mistake in scale, not just in judgment. The commercial terms determine what the city pays; the privacy schedule determines what the city is exposed to, and that exposure never shows up on an invoice. It shows up in a subpoena, in a records request the city can't answer on time, in a re-identification finding that leads the six o'clock news. The privacy schedule has earned the same clause-by-clause scrutiny that payment terms get, whether anyone wants to give it that attention or not.