SaaS Security: 7 Customer Responsibilities

Your SaaS is not a sitting duck, but it is only as secure as the configuration and practices you, the customer, control. While the vendor secures the infrastructure and application code, you are still responsible for user access, data handling, and integration security—areas where most breaches actually occur. This article breaks down the shared responsibility model, the specific tasks that remain on your plate, and how to avoid the most common pitfalls.

Formula

The customer risk score is a rough indicator of how much security responsibility you carry, based on the size of your user base and how long you have been using the service. The formula is:

Customer Risk Score = (Users / 100) × Plan Factor + (Months in Service / 12) × 0.5

Where:

• Users – the number of active user accounts in your organization.
• Plan Factor – 1 for Basic, 2 for Pro, 3 for Enterprise (higher tiers often include more integrations and custom features, increasing your configuration surface).
• Months in Service – how long you have been using the SaaS.

The result is a unitless score. A higher score suggests that you have a larger and more complex environment, which typically means more security tasks you own.

Worked Example

Using the default values: 12 months in service, 50 users, and a Pro plan (factor 2).

1. Users / 100 = 50 / 100 = 0.5
2. 0.5 × Plan Factor (2) = 1.0
3. Months in Service / 12 = 12 / 12 = 1
4. 1 × 0.5 = 0.5
5. Total = 1.0 + 0.5 = 1.5

The calculator shows a risk score of 1.5. This is a baseline—it does not tell you if you are secure, but it reminds you that your responsibility grows with your usage.

Background: The Shared Responsibility Model

The idea of shared responsibility originated with cloud infrastructure (IaaS) and has been adapted for SaaS. In simple terms, the vendor is responsible for the security of the service—the servers, the application code, the network, and the physical data centers. You are responsible for security in the service—how your users authenticate, what data you put in, and how you configure the settings. This is not a legal disclaimer; it is a practical division of labor. If a hacker breaks into the vendor’s database, that is on the vendor. If a hacker logs in with a weak password that you allowed, that is on you.

What the Vendor Handles (and What They Don’t)

Most SaaS providers will secure the following without any action on your part:

• Physical security of data centers.
• Network security like firewalls and intrusion detection.
• Application-level vulnerabilities such as SQL injection or XSS.
• Encryption at rest and in transit (often, but check your contract—some require you to enable it).
• Uptime and availability of the service itself.

What they do not do:

• Manage your user accounts—who has access, when they leave, and what permissions they hold.
• Enforce strong passwords or multi-factor authentication—they can offer it, but you must enable it.
• Control what data you upload—if you put sensitive customer data in a public file, that is your decision.
• Secure your own network—if your employees use the SaaS from compromised devices, the vendor cannot fix that.
• Back up your data—most SaaS vendors do not guarantee backups of your specific data; you need to export it regularly.

Customer-Owned Security Tasks: The Real Work

Here are the concrete items that fall under your responsibility, in order of importance:

1. Identity and Access Management (IAM): Provisioning and deprovisioning accounts. When an employee leaves, you must disable their access. This is the single most common cause of SaaS breaches.
2. Multi-Factor Authentication (MFA): Enabling MFA for all users. Many SaaS tools support it, but if you do not turn it on, you are relying on passwords alone.
3. Data Classification and Handling: Knowing what data you are putting into the SaaS. If it is personal data subject to GDPR or HIPAA, you must ensure the vendor’s terms allow it and that you have the necessary agreements.
4. Configuration Reviews: Regularly checking settings like public sharing, external collaboration, and API permissions. Defaults are often permissive.
5. Integration Management: If you connect the SaaS to other tools via APIs, you are responsible for the security of those connections. A compromised integration can expose data.
6. Incident Response: If a breach occurs on your side, you must have a plan to respond. The vendor will notify you, but you need to decide how to communicate with your users and regulators.
7. Compliance: If you are in a regulated industry, you must ensure your usage of the SaaS meets your compliance requirements. The vendor may provide certifications, but you are responsible for your part of the compliance.

Common Problems and How to Avoid Them

The most frequent mistakes customers make are:

• Relying on the vendor for backup: Many SaaS providers explicitly state that you should export your data regularly. If you do not, a ransomware attack or accidental deletion can be catastrophic.
• Ignoring audit logs: Most SaaS tools log user activity. If you never review these logs, you will not spot a compromised account until it is too late.
• Using the same password across services: Even with MFA, a reused password can be a risk if one service is breached.
• Not reviewing third-party apps: Users often authorize third-party apps to access their SaaS accounts. These apps can have weak security, and you may not even know they are connected.

To avoid these, set a quarterly review schedule. Check user lists, remove inactive accounts, review connected apps, and export your data to a secure location.

How to Choose a SaaS Vendor with Security in Mind

When evaluating a SaaS product, look beyond the feature list. Ask these questions:

• Does the vendor offer SSO (Single Sign-On) and MFA? If yes, are they included in your plan or an upsell?
• What is their data retention and deletion policy? Can you export all your data in a standard format?
• Do they have SOC 2 or ISO 27001 certifications? These are third-party audits of their security controls.
• What is their incident notification process? How quickly will you be informed of a breach?
• Can you restrict data residency to a specific region?

Remember that a vendor with strong security certifications still requires you to do your part. The certifications are a baseline, not a guarantee.

Costs of Ignoring Your Responsibilities

The financial impact of a data breach is significant, but the cost of your inaction can also be regulatory. If you store personal data and fail to protect it, you may face fines under GDPR, HIPAA, or other regulations. Beyond that, there is the reputational damage and the cost of notifying affected users. These costs far exceed the time it takes to implement basic security hygiene like MFA and regular access reviews.

Alternatives to Full SaaS Dependence

If you are uncomfortable with the shared responsibility model, consider a hybrid approach. Keep the most sensitive data in a system you control, and use SaaS for less critical functions. For example, use a project management SaaS for task tracking, but keep your customer database on your own infrastructure. Alternatively, you can use a cloud provider’s managed services (like a database) where you have more control over security configurations, but that is not SaaS—it is more like IaaS or PaaS, and you will have even more responsibility.

Frequently Asked Questions

Does the SaaS vendor ever take responsibility for my data loss?

Sometimes, but it depends on the contract. Most vendors will have a clause limiting their liability to the amount you paid them. They are not liable for lost business or regulatory fines. You should always maintain your own backups, even if the vendor claims to have redundancy.

What is the most important thing I can do to secure my SaaS?

Enable multi-factor authentication (MFA) for every user. This is the single most effective control you can implement. It stops the majority of account takeover attacks, which are the leading cause of SaaS breaches.

Can I rely on the vendor’s security certifications like SOC 2?

Yes, but only as a baseline. SOC 2 shows that the vendor has controls in place, but it does not cover your specific usage. You still need to configure the service correctly and manage your users.

What should I do if an employee leaves the company?

Immediately deactivate their account in every SaaS tool you use. If you have SSO, this can be automated. If not, you need a manual process to ensure access is revoked. Also, check if they had any connected apps or API tokens that need to be revoked.

Is it safe to store sensitive data in a SaaS application?

It can be, if you take precautions. Check the vendor’s encryption standards, ensure you have a data processing agreement, and classify the data. If the data is highly sensitive, consider additional encryption at the application level before uploading it.

How often should I review my SaaS security settings?

At least quarterly. Set a calendar reminder to review user lists, permissions, connected apps, and audit logs. More frequent reviews are better for high-risk environments.

Related

• GTA 6 Music System: Stream Playlists Explained
• Dollar Cost Averaging: How It Works
• How to Check Whether Your Mobile Network Is Affected By an Internet Shutdown

in t | Time in service (months) | months | 12 | 1 | 1200
in u | Number of users | users | 50 | 1 | 100000
sel p | Plan type | Basic=1, Pro=2, Enterprise=3
out risk | Customer risk score | - | (u / 100) * p + (t / 12) * 0.5 | 1