SaaS #

Software as a Service (SaaS) represents the highest abstraction level in the cloud computing service pyramid. In this model, all the complexity of physical infrastructure, operating systems, programming language runtimes, databases, and the application program code itself is completely hidden from our view. As customers, we consume the software product as a finished application, directly through a web browser, desktop app, or mobile app. The document collaboration tools, corporate email, CRM (Customer Relationship Management) applications, and daily project management systems we use are the real-world embodiment of SaaS. Although it offers instant operational convenience without needing to hire a server engineer, adopting SaaS leaves critical responsibility areas on our side that are very often neglected — leading to high-level data security gaps.

SaaS Architecture Models: Single-Tenant vs Multi-Tenant #

Behind the scenes, cloud providers design SaaS infrastructure using one of two main architectural approaches: Single-Tenant or Multi-Tenant.

  • Single-Tenant (Dedicated Architecture): Each customer gets one isolated application instance and database running on dedicated virtual servers. This model offers high-level security privacy and feature customization latitude, but with very expensive rental prices and slow application update processes because updates must be done one by one.
  • Multi-Tenant (Shared Architecture): Thousands of customers (tenants) share one web application instance and one database engine simultaneously. Data between customers is separated logically within database tables using a unique identification ID (tenant ID). This model is very popular because of its outstanding operational cost efficiency and simultaneous feature update releases for all users.
flowchart TD
    subgraph MultiTenant["SaaS Multi-Tenant Architecture"]
        direction TB
        UserA["Customer A (Tenant A)"] -->|"HTTP Request"| App["Shared Web Application Server"]
        UserB["Customer B (Tenant B)"] -->|"HTTP Request"| App
        
        App -->|"SQL Query with Tenant ID = A"| DB[(Shared Database Engine)]
        App -->|"SQL Query with Tenant ID = B"| DB
        
        subgraph Database["Logical Isolation in Database Table"]
            direction LR
            Row1["Row 1: Tenant_ID = A, Data..."]
            Row2["Row 2: Tenant_ID = B, Data..."]
            Row3["Row 3: Tenant_ID = A, Data..."]
        end
        DB -. "Logical Isolation" .-> Database
    end

Security Implications of Multi-Tenancy #

Because the database is logically shared, there’s a technical risk called Tenant Leakage. A bug in the application server’s program logic can cause database queries to pull data belonging to Tenant B and display it in Tenant A’s dashboard. As SaaS users, we must demand written commitments and system audit transparency from the provider to guarantee this data isolation works without gaps.

The Spectrum of Remaining User Responsibilities #

Although the cloud provider manages 90% of the technical aspects of SaaS, there’s a remaining 10% of governance and security responsibility we must absolutely manage ourselves. Failure in this 10% area is the main cause of company data leak incidents in the cloud.

1. User Identity and Access Management (IAM Lifecycle) #

In SaaS, the system’s security defense boundary shifts entirely from the network level (firewall) to the identity level (user login). We’re the ones who must manage our employees’ access lifecycle:

  • Negligent Deprovisioning: When an employee resigns, their accounts across all company SaaS applications (like Slack, Jira, Salesforce) must be deactivated the same day. Forgotten active accounts of former employees are the most common industry secret leak channel.
  • Single Sign-On (SSO) & IdP: Connect all SaaS application logins to our company’s centralized Identity Provider (like Okta or Google Workspace SAML/OIDC) so employee access revocation can be done instantly from one place.
  • Multi-Factor Authentication (MFA) Enforcement: Login credentials are phishing’s primary target. We must enable forced MFA policies in the SaaS admin panel for all accounts without exception.

2. Data Classification and Governance #

SaaS providers don’t know what data we put into their applications. We’re the ones who must classify data and manage access rights inside the application:

  • Data Export Rights: Restrict which users are allowed to download the entire customer database (CSV/Excel format) from the CRM application to prevent data theft by insiders.
  • Link Sharing Leaks: In document collaboration services (like Google Drive or Microsoft 365), make sure public link sharing is disabled by default to prevent internal financial documents from being indexed by search engines.

3. Data Portability and Independent Backup #

Relying on the SaaS provider’s backup guarantees is a dangerous operational Single Point of Failure (SPOF). If an internal system failure happens on the provider’s side, or our company account gets suspended due to administrative payment issues, we lose access to our business operational data.

We must design an asynchronous automation pipeline (for example, using scheduled serverless functions) to periodically pull important data from the SaaS API and archive it in our own cloud storage.

Here’s a simple Node.js script example that periodically triggers customer contact data retrieval from a SaaS service’s API endpoint to archive into local/private storage as proactive backup:

// ✓ CORRECT: Periodically back up SaaS data to storage we control ourselves
const axios = require('axios');
const fs = require('fs/promises');
const path = require('path');

const SAAS_API_URL = 'https://api.saas-crm.internal/v1/contacts';
const BACKUP_DIR = path.join(__dirname, 'backups');

async function runSaaSBackup() {
  try {
    console.log("Starting SaaS CRM data backup...");
    
    // Request data with encrypted API Key authentication
    const response = await axios.get(SAAS_API_URL, {
      headers: {
        'Authorization': `Bearer ${process.env.SAAS_API_TOKEN}`,
        'Accept': 'application/json'
      },
      timeout: 10000 // 10 second timeout limit
    });

    const dataToBackup = response.data;

    // Ensure the backup directory is available
    await fs.mkdir(BACKUP_DIR, { recursive: true });

    // Save backup with a unique timestamp filename
    const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
    const backupFilePath = path.join(BACKUP_DIR, `crm-contacts-backup-${timestamp}.json`);
    
    await fs.writeFile(backupFilePath, JSON.stringify(dataToBackup, null, 2));
    console.log(`Backup successfully saved to: ${backupFilePath}`);
  } catch (error) {
    // Send backup failure notification to the SRE / Ops team
    console.error("CRITICAL ERROR: Failed to retrieve backup data from SaaS API:", error.message);
    process.exit(1);
  }
}

runSaaSBackup();

Operational and Financial Risks of SaaS Adoption #

Before we decide to hand over our entire business process to a third-party SaaS solution, carefully evaluate the following risks:

  1. Data Vendor Lock-in: Some SaaS vendors deliberately make data export difficult. They let us import data very easily, but when we want to migrate out, they only provide export features in unstructured PDF format or limit the amount of data exportable via API.
  2. Connectivity Dependency & Outages: Pure SaaS applications run entirely over the internet. If the office internet connection goes down, or the cloud provider hosting the SaaS suffers a global power outage, our employees can’t work at all. We must prepare a written business continuity plan for this worst-case scenario.
  3. Exponential Cost Increases (Pricing Seat Trap): SaaS business models generally use per-user-per-month billing (per-user/seat pricing model). This model feels very cheap when our team has 5 people. But when the organization grows to 500 employees, the monthly SaaS bill skyrockets dramatically and often exceeds the cost of maintaining our own server cluster.

When our business data is stored on third-party SaaS servers, the legal responsibility for data compliance remains with our company.

SaaS Compliance Evaluation Checklist: #

  • Physical Data Location (Data Sovereignty): In which country is the SaaS vendor’s data center physically located? Would storing financial customer data abroad violate our national data sovereignty laws?
  • Data Processing Agreement (DPA): Does the vendor provide a written DPA contract document guaranteeing they won’t sell our business data or use it to train their AI models unilaterally?
  • Formal Security Certifications: Check whether the SaaS vendor regularly performs independent security audits and publishes SOC 2 Type II or ISO 27001 certifications to prove the reliability of their internal systems.

When to Use SaaS vs When to Build Yourself? #

The fundamental principle in software engineering is: “Build for differentiation, Buy for commodity” — build your own applications for your core business differentiators, buy SaaS for commodity needs.

Use SaaS if:
  ✓ The application need is common and standard across the industry (examples: company email, payroll attendance systems, sales CRM, IT help desk ticketing). There's no competitive added value in spending time coding your own email system.
  ✓ Operational speed is the top priority (time to value).

Consider Building / Self-Hosting if:
  ✗ The application is a core product that's the main competitive advantage of the business.
  ✗ Industry regulations absolutely prohibit storing data outside our local server jurisdiction.
  ✗ Per-user license costs (seat pricing) at large scale exceed the operational costs of an internal engineering team.

Summary #

  • SaaS delivers maximum operational convenience by handing 100% of hardware, OS, database, and program code management to the vendor.
  • Data governance responsibility never disappears — we still must manage user provisioning, internal access authorization, and sensitive data classification.
  • Enforce MFA (Multi-Factor Authentication) policies and integrate logins with centralized SSO to minimize identity security gaps.
  • Beware of Vendor Lock-in risk by always automatically and periodically exporting backup data to storage we control.
  • Audit the vendor’s data sovereignty regulations and security certifications (SOC 2/ISO 27001) before moving business data to a SaaS platform.
  • Apply the Build for Differentiation, Buy for Commodity philosophy to decide when to rent SaaS and when to build applications from scratch.

← Previous: PaaS   Next: Choosing a Service Model →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact