A school-district CISO wants structured risk analysis of a student chatbot architecture before procurement. Which approach best applies threat-modeling practice?

Threat modeling should precede procurement for municipal AI so purchase decisions reflect identified trust boundaries and abuse cases. A school-district CISO should run a structured threat-modeling workshop on the student chatbot architecture before procurement—covering identity integration, student data stores, prompt paths, plugins, logging, and third-party hosting. Early workshops surface excessive data access, weak tenant isolation, and unsafe tool permissions while the district can still negotiate requirements or reject unfit vendors.

Accepting a vendor-provided threat-model report on the chatbot architecture before procurement decisions outsources structured analysis to the vendor and does not perform independent threat modeling, leaving district-specific trust boundaries and student-data abuse cases unverified. Running an automated threat-modeling scan on the chatbot architecture before procurement decisions produces tool-generated lists rather than collaborative design analysis and misses context-specific threats around identity integration, data access, and plugin permissions. Sending a standardized threat-modeling questionnaire on the chatbot architecture before procurement decisions collects checklist answers rather than structured threat analysis and fails to map how the chatbot handles student data flows and third-party hosting.

Exam caveat: threat modeling before buy is the expected practice; accepting a vendor-provided threat-model report on the chatbot architecture before procurement decisions is not a substitute for pre-procurement workshops. Operational check: facilitate a cross-functional workshop, produce a threat list with mitigations as procurement requirements, and make contract award contingent on addressing critical findings.