Software as a Service: Using a Complete Provider-Operated Application

Software as a Service provides a complete application over a network.

Customers create accounts, configure features, import data, and use the product. The provider operates the application stack, releases updates, and maintains its underlying infrastructure.

SaaS outsources application operation, but the customer still owns how people access it and how organizational data is governed.

Buying a subscription changes responsibilities; it does not remove them.

A concrete example: hosted company email

Instead of operating mail servers, spam filters, storage, and client synchronization, a company subscribes to hosted email.

The provider handles the service platform. The company still decides:

who receives an account,
who can administer the tenant,
retention policy,
domain configuration,
device access,
and what happens when an employee leaves.

SaaS versus IaaS and PaaS

With IaaS, the customer manages operating systems and applications.

With PaaS, the customer deploys its application to a managed runtime.

With SaaS, the provider supplies and runs the application itself. The customer primarily configures and uses it.

The boundaries are useful models, though real offerings can mix layers.

Multi-tenancy

Many SaaS products serve multiple customer organizations on shared infrastructure.

The provider must isolate:

data,
identity,
configuration,
encryption,
performance,
and administrative actions.

Customers should understand tenant boundaries and available dedicated options for high-risk workloads.

Configuration versus customization

Configuration uses supported settings:

roles,
workflows,
fields,
notifications,
policies,
and branding.

Customization may add scripts, extensions, or custom integrations. Deep customization increases value but can complicate upgrades, security, and migration.

Prefer supported extension points over modifications that depend on undocumented behavior.

Identity and single sign-on

Organizations should connect SaaS access to centralized identity where practical.

Single sign-on and automated provisioning can:

enforce multi-factor authentication,
apply account lifecycle,
remove access promptly,
and reduce separate passwords.

Emergency administrator accounts need strong protection and monitoring.

Roles and least privilege

Default administrator access is convenient but risky.

Define roles for:

ordinary users,
managers,
support,
billing,
security,
and system administration.

Review privileges regularly, especially for contractors, integrations, and former employees.

Data ownership

Contracts and product controls should clarify:

who owns uploaded and generated data,
where it is stored,
how it is used,
whether it trains provider models,
how long it is retained,
and how deletion works.

"Your data" can have different legal and operational meanings without precise terms.

Data export

A usable exit requires more than a download button.

Evaluate whether export includes:

records,
relationships,
files,
comments,
audit history,
configuration,
and stable identifiers.

A proprietary archive is not useful if no replacement system can interpret it.

Backup and recovery

The provider may maintain platform backups, but customers need to know:

recovery objectives,
retention,
restore granularity,
customer-initiated restore options,
and protection from accidental user deletion.

A provider's disaster recovery may restore the whole platform without restoring one customer's deleted record.

Availability

Review:

service-level commitments,
maintenance behavior,
status communication,
support response,
regional architecture,
and historical incidents.

An SLA credit may compensate a fraction of subscription cost but does not recover business work lost during an outage.

Business continuity

Ask how work continues if the SaaS product is unavailable.

Possible controls include:

offline procedures,
cached critical reports,
alternate communication channels,
periodic exports,
and manual emergency workflows.

Continuity effort should reflect how essential the application is.

Integrations

SaaS applications connect through APIs, webhooks, marketplace extensions, and automation tools.

Each integration adds:

credentials,
permissions,
data transfer,
rate limits,
versioning,
and failure handling.

Review third-party extensions separately; provider approval does not always mean comprehensive security assessment.

Audit logs

Important SaaS products should record:

sign-in,
administrator changes,
data export,
permission updates,
integration creation,
and sensitive actions.

Logs need adequate retention and export to central security monitoring when required.

Compliance

Provider certifications can support an organization's compliance program.

They do not automatically make the customer's use compliant. Configuration, data selection, user access, retention, and business process remain customer responsibilities.

Understand the exact services, regions, and controls covered by each report.

Updates

SaaS providers often release continuously.

Customers gain security patches and features without performing deployment, but changes can affect workflows and integrations. Useful providers offer:

release notes,
deprecation windows,
sandbox tenants,
feature controls,
and migration guidance.

Critical automation should not depend on undocumented interface details.

Pricing

SaaS pricing may depend on:

user seats,
active users,
storage,
transactions,
feature tier,
API volume,
or support level.

Unused accounts and duplicated tools create ongoing waste. Total cost also includes administration, integration, training, and migration.

Vendor risk

Evaluate:

financial stability,
security practices,
subprocessors,
roadmap,
support,
contract terms,
acquisition risk,
and shutdown or export provisions.

The smaller the replacement window, the more important tested export and continuity plans become.

Shadow SaaS

Employees can adopt online tools without organizational review.

This creates:

unmanaged data copies,
weak access controls,
duplicate spending,
and difficult offboarding.

Governance should provide usable approved options rather than relying only on prohibition.

Knowledge check

How does SaaS shift responsibility compared with PaaS?
Why does single sign-on improve account lifecycle?
What should a practical data export preserve?
Why might provider backup not recover one accidentally deleted record?
How can an approved marketplace extension still add risk?

The one idea to remember

SaaS lets an organization use a provider-operated application instead of running the stack. The customer still governs identities, permissions, data, integrations, continuity, cost, and exit, so subscription convenience needs active ownership.