When a vendor serving local governments leaves a database open to the internet, the reaction inside most organizations follows a pattern. Someone asks whether the vendor passed its security questionnaire. Someone else points out that the contract has a breach notification clause. Then the conversation moves on.
The CitySourced exposure shows why that pattern fails. A researcher, Jeremiah Fowler, found a publicly accessible database of roughly 42 million documents, with personally identifiable information in plaintext and no password protection or encryption. The records were largely images of code violation reports and complaints, and some held a decade's worth of names, physical addresses, email addresses, and phone numbers. CitySourced serves local governments in the U.S., Canada, and the Caribbean. The database has since been restricted. It is still unknown how long it was exposed.
These myths persist because vendor risk programs often measure paperwork instead of exposure. Here are five worth retiring.
Myth 1: "A completed security questionnaire means the vendor's controls are in place."
Reality: A questionnaire records what a vendor says about its compliance controls at a point in time. It doesn't verify them. An unauthenticated, unencrypted database is the kind of condition that no attestation can rule out, because it can appear after the questionnaire is signed through a misconfigured storage setting, a migration, or a forgotten test environment.
The exposed repository also included several top-level application directories and other operational folders. This suggests the exposure wasn't a single misplaced file but a broader configuration problem. Control design review should ask whether authentication and encryption are enforced by default, and automated control testing should confirm it continuously. Point-in-time answers can't do that.
Myth 2: "We only need to worry about the data we hand to the vendor."
Reality: Your residents hand data to the vendor too. In this case, the exposed records were largely citizen-submitted code violation reports and complaints. Those submissions carried names, addresses, emails, and phone numbers that the government agency may never have seen directly.
For your regulatory inventory, this changes the scoping question. Don't ask only what you transmit to the vendor. Ask what the vendor's platform collects on your behalf, from whom, in what format, and for how long. Images of reports are easy to overlook in a data map because they don't look like structured records, yet they can hold the same sensitive personal data as a database field.
Myth 3: "Encryption and access controls are the vendor's problem, not ours."
Reality: Accountability for resident data stays with the agency even when custody sits with a vendor. Residents who see their information exposed will not distinguish between the platform and the city that endorsed it. Your regulatory obligations for safeguarding personal data generally follow the data, not the contract.
This is why enterprise risk oversight should treat critical vendors as extensions of your own environment. Your cybersecurity risk register should carry entries for vendor-held data, with an owner on your side, a defined cyber risk appetite, and key control indicators you can observe, such as evidence of encryption at rest and authentication enforcement on data stores.
Myth 4: "If the researcher found it and the vendor fixed it, the matter is closed."
Reality: The fix addresses the exposure. It doesn't answer the questions regulators, auditors, and residents will ask. It is unknown how long the database was accessible. Without access logs, you cannot determine whether anyone other than the researcher retrieved the data. That unknown is itself a finding.
Your incident response structure should treat a vendor-reported or researcher-reported exposure as an information security incident until proven otherwise, with a defined path to assign a severity level, request log evidence from the vendor, and make a documented determination on notification. Closing the matter because the database is now restricted skips the assessment that your obligations likely require. Note that a researcher's disclosure is a stroke of luck. Your program shouldn't depend on it.
Myth 5: "Public trust is a communications issue, not a risk issue."
Reality: Trust is the asset a government digital service runs on. Civic reporting platforms only work when residents are willing to submit their names and contact details alongside a complaint about a neighbor or a local business. Plaintext exposure of that information gives residents a concrete reason to stop participating, and the cost shows up as lower engagement in the very channels agencies built to improve service.
That makes trust a risk portfolio item with its own impact criteria on your risk prioritization matrix. Local government agencies are uniquely sensitive targets because of the disruption an attack could cause. Treat the reputational and participation impact as part of inherent risk, not as a downstream messaging task.
What to do instead
Replace the paperwork-first model with an exposure-first one. Start with these steps.
Audit what's actually holding your data. Inventory every vendor platform that collects or stores resident information, including image and document repositories. Confirm for each one what is stored, where, and for how long.
Require evidence, not assertions. For vendors holding sensitive personal data, ask for proof of encryption at rest, authentication enforcement on all data stores, and the results of recent external configuration scans. Build these into contract terms and risk-based audit planning so that audit fieldwork reaches your highest-risk vendors on a defined cycle.
Build in continuous verification. Where you can, apply control testing automation to external attack surface checks of vendor-hosted assets tied to your data. A quarterly questionnaire cannot catch a misconfiguration that lasts a week.
Contract for logging and notification. Require retention of access logs sufficient to determine scope after an exposure, and a defined timeline for the vendor to notify you of any information security event affecting your data.
Rehearse the vendor-origin scenario. Run a tabletop exercise in which a researcher, not your monitoring, tells you a vendor has exposed resident data. Test who decides, who contacts residents, and who talks to regulators.
The lesson of this incident isn't that one vendor failed. It's that a program built on attestations will always learn about exposure last.
