Public works wants a third-party SaaS product for online permitting. Which architecture implication should the security architect emphasize first?
Select an answer to reveal the explanation.
Short Explanation
Every new vendor is another set of keys to the city's data—architecture is not just boxes you own. Assess how that SaaS holds data, who can reach it, and how it plugs into your stack. HTTPS alone is not a vendor risk assessment.
Full Explanation
Selecting a third-party SaaS product for online permitting expands the municipal trust boundary to include the vendor's people, processes, platforms, and subprocessors. Architecture work therefore begins with assessing third-party security posture, data handling, residency, encryption, identity integration, API exposure, logging, incident notification, and exit/portability—not with assuming liability transfer equals risk transfer. Security+ frames third-party and supply-chain risk as an architectural concern: once citizen PII and workflow data leave city-controlled systems, control effectiveness depends on contractual, technical, and monitoring safeguards around that vendor.
Asserting that SaaS never affects municipal risk because vendors absorb all liability confuses legal clauses with residual operational risk; citizens and regulators still hold the city accountable for service confidentiality and availability. Onboarding any HTTPS-using vendor without review treats transport encryption as a complete vendor assessment, ignoring account takeover, insecure APIs, weak tenant isolation, and poor backup practices. Claiming only open-source on-prem tools create third-party risk is inverted—commercial SaaS introduces concentrated third-party dependency that must be governed.
Exam caveat: "HTTPS is enough" and "vendor liability removes risk" are classic distractors; the correct emphasis is expanded trust boundary and due diligence. Operationally, require security questionnaires or SOC reports as appropriate, map data flows and integrations, enforce SSO/MFA into the SaaS where possible, limit admin roles, enable audit logs exported to municipal SIEM, and define offboarding steps before production go-live.