Smart lamppost pilot with security and privacy gaps

I would prioritise by likelihood and impact, not by the vendor's convenience. The default administrator password and unsigned firmware are critical: they allow an attacker to take over devices, push malicious updates or join the lampposts to a botnet. The flat VLAN exposing camera streams is also critical because it turns a lighting pilot into a surveillance platform with weak access control. The 12-month retention without purpose is a privacy compliance issue, and the missing privacy impact assessment means the council cannot demonstrate that the processing is necessary and proportionate. My advice would be a split decision. Do not switch on CCTV, Wi-Fi or any function that collects personal data until the critical issues are fixed and a privacy impact assessment is completed. Air-quality and parking sensors that collect no personal data could go live in a limited, monitored mode if they are segmented from the cameras. A vendor promise to patch after go-live is unacceptable for internet-facing devices with default credentials. The public event is not a sufficient reason to accept a known critical risk.

The council needs a clear purpose and legal basis for each data type. CCTV should have defined coverage, signage, retention and access rules; if it is for traffic management, it should not be repurposed for crowd monitoring without a fresh assessment. Wi-Fi should not collect more device identifiers than necessary, and any analytics should use aggregated or pseudonymised data. Sensor data should be retained only as long as needed for the stated purpose, with a documented retention schedule and deletion process. I would require a privacy impact assessment before go-live, covering necessity, proportionality, data flows, retention, access, security and community consultation. Governance should include a named data owner, an approved user list, audit logs, a process for law-enforcement requests, and a published transparency notice. The council should also define who can change camera angles or add analytics, because scope creep is the main privacy risk in smart-city pilots. These controls should be written into the contract and verified at acceptance, not left as policy statements.

I would convert each finding into a testable acceptance criterion with an owner and date. Examples: no device responds to the default password; all firmware images are signed and verified before installation; camera traffic is on a dedicated VLAN with allow-listed destinations and no direct internet exposure; retention is enforced by automated deletion and can be evidenced; a privacy impact assessment is approved before any personal data is collected. The vendor should provide a remediation plan with root-cause fixes, not a patch schedule that leaves critical devices exposed. Acceptance should include an independent penetration test, configuration review, firmware update test and a sample deletion audit. Payment should be linked to passing these gates. I would also require a post-go-live monitoring period with incident reporting and a right to suspend devices that fail. The council should retain the ability to audit the vendor and to require removal of any function that exceeds the approved purpose.