An open-data CSV on the city portal accidentally includes extra email columns. An analyst mirroring the portal for OSINT should treat those addresses how?
Select an answer to reveal the explanation.
Short Explanation
A leaked column on the open-data portal is a records spill, not a starter kit. Note it, tell the data owners, and leave the inboxes alone. Publishing a mistake does not turn OSINT into a phishing factory.
Full Explanation
When an open-data CSV on the city portal accidentally includes extra email columns, an analyst mirroring the portal for OSINT should record the accidental publication as a records-handling issue and must not treat the column as a phishing target list. Accidental publication creates a civic data-governance finding; it does not create a license to abuse the addresses that spilled. Loading them into a resident phishing campaign because “the portal already published them” converts a spill into unauthorized social engineering against the public the city serves. Selling the extra column as a marketing list to offset the open-data program commercializes personal contact data and conflicts with public-trust use of municipal open data. Guessing municipal-default passwords for every extra mailbox reframes OSINT as credential attacks on residents or staff. Exam caveat: PORP requires analysts to flag accidental open-data exposures and stop short of weaponizing the spilled fields for outreach, sale, or password guessing. Operational check: snapshot the CSV URL and unexpected columns, notify open-data or records owners through the approved channel, document that addresses were not used for phishing or password guessing, and continue any authorized OSINT only on fields the program intended to publish.