A city migrates staff email to a SaaS provider. Under the cloud shared responsibility model, which split is most accurate?
Select an answer to reveal the explanation.
Short Explanation
Think of SaaS like renting a secure apartment building: the landlord hardens the building, but you still lock your door and control who gets keys. The city owns identities and the data in the boxes; the provider owns the app stack underneath. Mixing those up leaves the wrong team watching the wrong controls.
Full Explanation
Under the cloud shared responsibility model for SaaS email, the provider typically secures the underlying application, platform, and infrastructure that deliver mailboxes, while the customer remains responsible for identities, access decisions, and the confidentiality of data placed in those mailboxes. For a city migrating staff email, that means configuring MFA, conditional access, mailbox permissions, DLP and retention settings, phishing reporting culture, and classification of what content may live in mail—while trusting the provider for physical facilities, hypervisor layers, and the SaaS application stack itself. Security+ emphasizes that "cloud" does not mean "someone else owns all risk"; responsibility splits by service model, and SaaS puts the heaviest remaining load on identity and data governance.
Claiming the city owns datacenter power and cooling while the provider owns mailbox permissions reverses the SaaS split: facility power is the provider's concern, and mailbox ACLs and user awareness remain municipal duties. Asserting the provider owns all identity lifecycle decisions leaves the city without control of joiners, movers, leavers, and privileged roles—an untenable posture for government email. Declaring encryption and SaaS email out of scope for municipal risk ignores both shared-responsibility charts and public-sector compliance expectations around sensitive correspondence.
Exam caveat: shared-responsibility items often flip customer and provider duties; map the service model (IaaS/PaaS/SaaS) before assigning controls. Operationally after migration, verify federation or directory sync, MFA enrollment coverage, admin role reviews, mailbox audit logging, and that encryption and retention settings match policy—not merely that mail routes through the SaaS brand.