A vendor hosts the city’s constituent CRM and processes resident records only on the city’s documented instructions. How should controller versus processor roles be assigned?

Controller versus processor roles follow purpose and means, not hardware ownership. When a vendor hosts the city’s constituent CRM and processes resident records only on the city’s documented instructions, the city typically remains the controller: it decides why resident data is collected and how it will be used for constituent services. The hosting vendor typically acts as a processor, providing the technical environment and acting on the city’s behalf under contract. Help-desk agents who merely access tickets under city policy do not become controllers by viewing a record.

Calling the vendor always the controller because it owns hosting hardware confuses infrastructure custody with decision authority. Claiming neither party is a controller if a SaaS contract exists abandons required role clarity; contracts should assign and operationalize roles, not erase them. Treating individual help-desk agents as controllers each time they view a CRM ticket misapplies the concept—agents are usually workforce acting for the controller organization, not independent controllers.

Exam caveat: Security+ and privacy-governance items repeatedly test that the party determining purposes and means is the controller; a SaaS host following instructions is ordinarily a processor even when servers are offsite.

Operational check: ensure the CRM contract includes processor obligations (instructions only, confidentiality, subprocessors, breach notice, deletion/return, audit rights). Document city-side purposes in a processing register. Restrict vendor staff access, log administrative actions, and prohibit vendor secondary use of resident CRM data for the vendor’s own marketing or product development without a separate lawful basis and agreement.