A cybersecurity researcher recently discovered a publicly exposed database linked to CitySourced, a platform for local governments in the U.S., Canada, and the Caribbean. It contained approximately 42 million documents with personally identifiable information (PII) in plaintext, without any password or encryption. The records included names, physical addresses, email addresses, and phone numbers spanning a decade. The duration of the exposure remains unknown.
If you manage data governance for a municipality or a vendor-dependent public body, the key question isn't "could this happen to us?" It's "which oversight model do we apply to each platform, and can we prove it's working?"
The Decision You Are Facing
You've outsourced a citizen-facing function, like service requests or permitting, to a third-party platform that stores resident data you're responsible for. You must decide how much control, evidence, and monitoring to demand.
Treating every vendor the same can either overwhelm your team with audits or leave your highest-risk platform unchecked. Consider these three paths, each driven by specific requirements.
Key Factors That Affect Your Choice
Evaluate these factors before choosing a path.
1. What data does the platform hold, and for how long? Resident-submitted complaints with images and contact details are PII at scale. A decade of retained records significantly increases exposure compared to a platform that purges data quickly. If your Retention Rule isn't enforced contractually, vendors may keep everything.
2. Which law applies to the residents? A platform serving the U.S., Canada, and the Caribbean involves multiple legal regimes. Canadian residents' data may fall under the Personal Information Protection and Electronic Documents Act or provincial statutes. California residents bring the California Consumer Privacy Act and California Privacy Rights Act into scope. If any EU or UK residents are in the dataset, GDPR or the UK General Data Protection Regulation applies. Map jurisdictions first; the strictest applicable regime often sets your floor.
3. Is the vendor a processor? Where GDPR applies, Article 28 requires a binding contract with defined processing instructions, confidentiality, and sub-processor controls. Article 32 requires appropriate Technical and Organisational Measures, including encryption. Plaintext storage of resident PII is indefensible under that standard.
4. Can you detect exposure yourself? In this case, an outside researcher found the problem. If your only discovery mechanism is someone else's goodwill, your monitoring has a gap.
5. What's your breach clock? Under GDPR Article 33, the 72-hour notification to the Supervisory Authority starts when you're aware of a breach. If the vendor delays reporting an incident, your clock may run while you're uninformed. Your contract must close that gap.
Path A: Contractual Assurance with Periodic Evidence
Choose this when: the platform holds low-sensitivity data, retention is short, no special categories are involved, and the vendor can document its controls.
What it requires:
- An Article 28-style data processing agreement, or its equivalent under Canadian and U.S. state law, specifying encryption at rest and in transit, access controls, and secure deletion at contract end.
- Annual evidence: a current independent security attestation or audit summary, plus a written statement of storage configuration.
- A contractual obligation to notify you of incidents within a defined window, short enough to meet the 72-hour notification.
- Maintained inventory entries so the platform appears in your breach register and records of processing.
Limit: this path relies on vendor self-reporting. Don't use it for platforms that hold years of resident contact data. That profile calls for Path B.
Path B: Verified Controls with Continuous Monitoring
Choose this when: the platform retains identifiable resident data at scale, accepts file uploads, or stores records across multiple years.
What it requires:
- Everything in Path A, plus independent verification. Run external attack-surface scans against vendor-hosted endpoints and storage tied to your tenancy. An open, unauthenticated database is exactly what these scans catch.
- Data discovery across the vendor environment, where your contract permits, to confirm what categories of PII actually sit there versus what the contract says.
- Asymmetric encryption for data in transit and symmetric encryption for data at rest, with key wrapping and customer-controlled key management where feasible. Plaintext should never be an acceptable state.
- Access provisioning and deprovisioning reviews, enforced through policy-based access control or at least discretionary access control with documented ownership.
- Retention enforcement: a records disposition schedule the vendor must execute, with defensible disposal evidence. Ten years of complaint records rarely has a legal justification.
- Audit rights written into the contract and actually exercised.
Limit: it costs more in staff time. Reserve it for platforms where exposure would reach thousands or millions of residents.
Path C: Bring the Data In-House or Restructure the Engagement
Choose this when: the vendor can't or won't provide encryption evidence, resists audit rights, can't state where data is stored, or has already had an exposure it can't explain.
What it requires:
- A documented decision, ideally supported by a privacy impact assessment aligned to ISO/IEC 29134, recording why residual risk is unacceptable.
- Where GDPR applies and the processing is high-risk, consider prior consultation with the Supervisory Authority under Article 36.
- A migration plan with data purging at the vendor, confirmed in writing, followed by cryptographic erasure where keys are under your control.
- Interim compensating controls: restrict what residents can upload, minimize collected fields, and shorten retention immediately.
Limit: exit is disruptive. Only choose it when Paths A and B can't close the gap.
Summary Matrix
| Factor | Path A: Contractual Assurance | Path B: Verified and Monitored | Path C: Restructure or Exit |
|---|---|---|---|
| Data Sensitivity | Low, short retention | PII at scale, multi-year | Any, with unresolved exposure |
| Primary Drivers | GDPR Art. 28; contract terms | GDPR Art. 28, 32, 33; state and Canadian law | GDPR Art. 36; ISO/IEC 29134 findings |
| Evidence Source | Vendor attestation | Independent scans and audits | Documented risk decision |
| Encryption | Contractually required | Verified, customer-managed keys where feasible | Required before any continuation |
| Retention Control | Stated in contract | Enforced and evidenced | Immediate reduction, then data purging |
| Breach Readiness | Notice window in contract | Tested notification path | Reassessed at transition |
| Effort | Low | Moderate to high | High, one-time |
What to Do This Quarter
Inventory every platform holding resident data. Assign each to a path using the factors above. For anything on Path B, run an external exposure scan this month; don't wait for someone outside your organization to do it. Then check your contracts for three clauses: encryption, retention, and incident notice timing. Missing any one of them is a finding.
