Software-as-a-Service has been the dominant software delivery model in commercial IT for over a decade. The pattern is familiar: the vendor operates the application, the customer pays a subscription, the application is accessed through a browser, capacity scales with the subscription tier. For commercial buyers, the SaaS calculus is mostly about feature fit and price.
Public-sector buyers have to evaluate SaaS through additional lenses. Compliance posture, identity integration, data residency, exit obligations, and the operational responsibilities that do not transfer to the vendor all matter materially. This post is about what SaaS actually looks like for a federal agency, state government, university, or healthcare organization evaluating a cloud-delivered application.
What SaaS Provides
A SaaS application provides a defined scope: the software runs on the vendor's infrastructure, the vendor handles upgrades and patches, capacity is elastic, and access is over the internet. Common public-sector SaaS examples include Microsoft 365 for productivity, Salesforce for CRM, ServiceNow for IT service management, and any number of vertical applications for specific government and education functions.
The vendor's responsibility includes the application's availability, the underlying infrastructure, security of the platform, and feature roadmap. The customer typically does not have to operate servers, manage upgrades, or worry about underlying infrastructure performance.
This is the part that maps cleanly to commercial SaaS evaluation. The differences emerge in the dimensions commercial buyers do not have to think hard about.
Compliance Posture as a Procurement Filter
Public-sector SaaS evaluation begins with compliance authorization. For federal agencies, FedRAMP authorization at the appropriate level (Moderate or High) is typically the threshold. Agencies cannot procure SaaS that is not FedRAMP-authorized for the data sensitivity involved. State and local governments often inherit federal frameworks or operate under state-equivalent compliance regimes. Higher education institutions look for HECVAT documentation. Healthcare organizations require HIPAA Business Associate Agreements that cover the SaaS specifically.
A SaaS vendor without the relevant compliance posture is unprocurable for the workload, regardless of feature fit. This filter eliminates many commercial SaaS options before feature evaluation begins.
Identity Integration is Operational, Not Optional
Commercial SaaS often launches with a username/password store and adds enterprise SSO as an upsell tier. Public-sector deployments cannot operate that way. Authentication has to flow through the institutional identity provider (Login.gov, ID.me, Shibboleth, Entra ID, Active Directory) so accounts deprovision when staff leave, MFA enforces against the institutional policy, and audit logs capture authentication events for compliance review.
A SaaS vendor whose identity integration is on the upsell tier rather than the baseline is operationally awkward for public-sector buyers. The integration has to be configured, tested, and documented as part of deployment. This is operational work that does not show up in the vendor's marketing materials.
Data Residency, Sovereignty, and Exit
For workloads with data sovereignty requirements (federal CUI, state-specific student or patient data, US persons data under ITAR), the SaaS has to run in a region that satisfies the residency constraint. AWS GovCloud and Azure Government regions exist specifically for this requirement. Commercial SaaS vendors hosted in commercial cloud regions are not always usable for sovereignty-constrained workloads.
Exit also matters more in public-sector procurement than commercial. The institution has to be able to extract its data in a usable format if the vendor relationship ends, and procurement contracts typically specify the data export format and timeline. Commercial SaaS vendors with proprietary data formats and no documented export path can become procurement blockers.
What SaaS Does Not Cover
The SaaS vendor's responsibility ends at the application boundary. The customer's responsibilities include user provisioning and deprovisioning workflows, data classification within the SaaS, access reviews on a documented cadence, integration with the institutional security monitoring stack, exit planning, and the operational practices that satisfy audit cycles.
For public-sector buyers, these operational responsibilities are not optional and do not transfer to the SaaS vendor. The vendor operates the application; the institution operates everything around it.
The Procurement Pattern That Works
Public-sector SaaS adoption that runs smoothly tends to share a procurement pattern: compliance authorization confirmed up front, identity integration tested before contract signature, data residency and exit obligations contracted explicitly, and ongoing operational responsibilities documented and assigned to a named owner inside the institution. SaaS adoption that struggles tends to skip one or more of these steps and discover the gap later, usually during an audit cycle or a vendor transition.
For institutions building their cloud strategy, this is part of the broader operational discipline that distinguishes a procurement transaction from a managed engagement. We cover the analogous discipline for self-operated cloud workloads in AWS Cloud Hosting for Public-Sector Workloads.
Frequently Asked Questions
Does FedRAMP authorization automatically apply to all data in a SaaS application?
No. FedRAMP authorization applies at the system boundary the vendor documented during the authorization process. Data sensitivities outside that boundary, or features the vendor added after authorization but before re-authorization, may not be covered. Agencies have to verify the scope of authorization against the specific data and features they intend to use.
Can higher education institutions use commercial SaaS that is not FedRAMP-authorized?
Yes for most data classifications, with HECVAT documentation as the typical institutional review filter. Federal data the institution handles under federal grants or contracts may have FedRAMP requirements that flow down from the grantor.
What is the difference between SaaS and managed application hosting?
SaaS is a vendor-operated application. Managed application hosting is when a partner operates the institution's own application instance on cloud infrastructure. Cascade CMS publishing to an institutional production website is closer to managed hosting; the Cascade application is SaaS, the production site is managed hosting.
Should public-sector institutions prefer SaaS over self-operated applications?
The right answer depends on the workload. SaaS reduces operational burden and shifts responsibility to the vendor for the application tier. Self-operated applications give the institution more control over identity, data residency, customization, and exit, at the cost of operational responsibility. Most institutions run a mix.