AWS Partner Network (APN) Blog

Importance and Impact of Compliance for SaaS Solutions on AWS

By Cheryl Cage, Sr. Security Partner Strategist – AWS
By Bill Tarr, Sr. Partner Solutions Architect – AWS SaaS Factory

If you are a software-as-a-service (SaaS) provider, you are well aware that your customers are looking to adopt your SaaS solutions, based on trust. Trust that your solution is reliable, scalable to their needs, and most importantly capable of securing their valuable proprietary data.

Compliance with security and privacy standards are an effective way to communicate to your customers the solution meets industry standards and handles user data in alignment with customer expectations.

When it comes to improving your security posture and growing your SaaS business, compliance can be a valuable part of your strategy for a myriad of reasons:

  • Legal requirements: SaaS companies are often subject to various regulations and laws related to data protection, privacy, and security. Compliance with these regulations is not only legally required, but can also help to avoid costly fines and legal actions.
  • Trust and reputation: Customers trust SaaS companies with their sensitive data and expect that it will be protected. Compliance with industry standards and regulations can help to build and maintain trust.
  • Accessing new markets: Compliance with certain standards and regulations may be required to access new markets or to work with certain customers, particularly in highly regulated industries.
  • Risk management: Compliance can help SaaS companies to identify and manage risks associated with data protection and security. Requirements often include implementing policies, procedures, and controls to help mitigate risks and prevent data breaches.

Building with a plan for compliance can also influence the design and architecture of your SaaS solution, and compliance can help avoid technical debt down the road.

In this post, we’ll break down some of the factors SaaS providers need to consider in designing and building their compliant solution, and highlight resources and services within Amazon Web Services (AWS) that you can leverage in your journey.

Compliance as the Foundation of Security

Security and privacy frameworks provide the tools to build out cybersecurity programs, stand up policies and procedures, and implement necessary technical controls to safeguard the confidentiality, availability and integrity of information. These frameworks provide a blueprint for managing risk and reducing vulnerabilities and are designed to consider the risks organizations face and how attackers can exploit security weaknesses.

For SaaS providers, these frameworks can be used to demonstrate their solutions meet the security requirements of customers, whether with government laws and regulations of their specific industries.

In some cases, organizations choose to pursue an attestation or certification such as, Service Organization Control 2 (SOC 2) and/or International Organization for Standardization 27001 (ISO 27001) to improve business operations and boost their competitive advantage. In other cases, businesses must meet regulatory compliance obligations and comply with laws for how to handle payment cards, personally identifiable information (PII), and other sensitive data.

Security requirements of frameworks generally map to a group of controls that each define some aspect of security. These controls may require self-attestation of compliance, or attestation by a third party, which may take the form of periodic reviews, or continual compliance with systems that monitor the state of compliance with a control.

Achieving compliance will be an ongoing process, but regular monitoring and reporting can help make adhering to these frameworks a standard part of business operations. Good security controls, data privacy, and data management should be foundational components of a SaaS application from the beginning.

Shared Responsibility Model and Compliance

For SaaS providers building on AWS, it’s important to understand the Shared Responsibility Model in terms of compliance. AWS is continuously audited and maintains certifications and accreditations across the globe, including SOC 2, ISO 27001, Federal Risk and Authorization Management Program (FedRAMP), Payment Card Industry Data Security Standard (PCI DSS), and others to help customers meet security and compliance requirements.

When systems are built in the AWS cloud, AWS and its customers share those compliance responsibilities. Some controls can be inherited from AWS, some are shared, and some controls are the customers responsibility, as Figure 1 below describes.

Just as AWS has a SOC 2 attestation, FedRAMP authorization, and ISO certification, SaaS providers that need to be compliant will have to go through the same compliance processes. It’s important SaaS providers understand which components they are responsible for within the scope of services that comprise their environment.


Figure 1 – AWS Shared Responsibility Model.

A few resources to mention that are important as you plan your SaaS architecture:

  • Customer Compliance Guides (CCG) provide a consolidated view of AWS security practices based on the configurable options for AWS services and compliance topics and control requirements mapped to common frameworks (SOC 2, ISO 27001, FedRAMP, National Institute of Standards and Technology Cybersecurity Framework (NIST CSF)).
  • AWS Services in Scope by Compliance Program is a list of services assessed and approved for specific compliance frameworks and regulations. For example, for Health Insurance Portability and Accountability Act (HIPAA), customers may use any AWS service in an account designated as a HIPAA account, but only process, store, and transmit protected health information (PHI) in HIPAA-eligible services defined on this page and in the Business Associate Addendum (BAA).
  • AWS Artifact provides access to AWS compliance reports and agreements between AWS and you as a SaaS provider which may be required by your compliance auditor. Some reports will list inheritable controls for “of the cloud,” helping customers understand the scope of controls that are shared and their responsibility.

Compliance Impact on SaaS Architecture

In the following sections, we’ll examine how compliance concerns influence our thinking on a number of core SaaS concepts. In doing so, we’ll refer back to the AWS whitepaper about SaaS Architecture Fundamentals and the SaaS Lens for the AWS Well-Architected Framework. Please refer to these guides for general SaaS guidance.

Tenant Isolation Implications

Tenant isolation is the process of protecting tenant resources, and denying any attempts to access other tenants’ resources. The options for isolating tenant infrastructure, in SaaS, break down primarily into “silo” and “pool.” Check out the SaaS whitepaper’s “Full stack silo and pool” section for background reading.

Figure 2 – Silo vs. Pool model of tenant isolation.

It’s a misconception that compliance frameworks or regulations, particularly those covering highly regulated industries, prohibit the use of pooled resources. In fact, most frameworks offer no guidance on tenant isolation, even FedRAMP primarily specifies “a full application test which attempts to use provisional access of one tenant to compromise another tenant.” (FedRAMP Penetration Test Guidance)

Be prepared to prove you will “introduce isolation strategies across all layers of the architecture, providing specific constructs that ensure that any attempt to access a tenant resource is valid for the current tenant context.” (SaaS Lens)

If you’re going to pool resources, the focus is on ensuring isolation policies are applied at every layer of our application. ln Figure 3, you can see how isolation policies need applied at our API, compute, and storage layers. AWS Identity and Access Management (IAM) is essential for isolation of pooled resources, and techniques like Dynamic Policy Generation and Attribute Based Access Control (ABAC) provide mechanism to apply isolation policies.

Figure 3 – Isolation policies in a SaaS solution.

Despite the lack of explicit prohibition of pooled resources in most compliance frameworks, SaaS providers that serve highly-regulated industries should still consider customer preference. You may need silo resources to accommodate silo resource requests as higher cost pricing tiers.

Compliant Tenant Onboarding

In silo environments, you must ensure all tenant environments are running the same compliant version of software. As you onboard new tenants, and as we deploy new versions of our software, you need to be able to provide assurances the version every tenant is running meets our compliance standards.

Figure 4 – Compliant tenant onboarding.

AWS Organizations and AWS Control Tower can help you centrally provision tenants and set up Service Control Policy (SCP) guardrails that can prevent accidental modification of accounts. Landing Zones Accelerator on AWS (LZA) can assist with setting up security configurations with log archive and audit accounts, so evidence of activity is available to auditors.

Compliance Implications for Data Storage

Discussions around data in a SaaS solution begin with understanding how you’ll partition your tenant data. In some ways, this is similar to tenant isolation, but consider there is “often a temptation to view data partitioning and tenant isolation as interchangeable. These two concepts are not meant to be equivalent. When we talk about data partitioning, we are talking about how tenant data is stored for individual tenants.” (SaaS Whitepaper)

You need to consider how you partition data for compliance purposes just like tenant isolation. This may include making decisions to segregate data based on its sensitivity, in addition to isolation concerns.

Figure 5 – Segregating sensitive SaaS data.

Data partitioning decisions may align with data encryption requirements, as well as backup and restore policies, data retention, data sovereignty, and offboarding, including decisions about how to configure storage and databases around the capabilities of the services you are using.

For example, an Amazon Simple Storage Service (Amazon S3) bucket and its folders can be configured to encrypt with AWS Key Management Service (AWS KMS) by default, offering the option of data encrypted with tenant-specific keys.

Figure 6 – Encrypting tenant Amazon S3 data.

Multi-Tenant Auditing, Logging, and Monitoring

You need to inject tenancy into everything our application emits, including logs, traces, and metrics. For compliance purposes, it’s important to ensure logs are aggregated into a centralized logging solution, and access to those logs is restricted in an audit account.

For verifying the history of access to your resources, turning on AWS CloudTrail for all accounts and regions. Eensure access logs are turned on for services that produce them; for example, Logging calls to Amazon API Gateway and Logging Amazon Cognito API Calls.

Managing Tenant Identity

You also need to manage tenant users and their access to your SaaS solution; this includes ensuring users are authenticated and connected to a specific tenant context. This context contains the information you pass along to every layer of your application, like logging and monitoring as we just discussed, and in fact every layer of your solution.

Our compliance story is strengthened by a single source of truth for tenant identity, rather than tenant services and logic spread throughout our solution. Leveraging an identity provider (IdP) can provide controls you can inherit around your identity management, simplifying your compliance story.

Getting Started with Security and Compliance

We’ve looked at some of the reasons SaaS compliance may be challenging, so let’s examine the journey towards compliance. For many SaaS providers, this may mean making incremental progress even if you don’t yet know what compliance frameworks your customers will require.

Many controls and requirements defined by compliance frameworks are founded on the best practices for cloud architecture. AWS has several free resources that can ensure your solution is following best practices, which can help prepare your architecture in anticipation of future compliance requirements.

Members of the AWS Partner Network (APN) can leverage programs, including the AWS Global Security and Compliance Accelerator (GSCA), that help SaaS providers meet their customers’ compliance needs. The AWS SaaS Factory program provides expert guidance to SaaS providers at any stage of the SaaS journey.


In this post, we examined a number of aspects of compliance on AWS and reviewed concerns you should keep in mind as you design and build your SaaS applications, cross-referencing the best practices for SaaS with compliance requirements.

We’ve provided a number of free resources you can leverage to align with compliance best practices while building our SaaS solution. Finally, we discussed how you can use AWS compliance services to monitor your solution.

About AWS SaaS Factory

AWS SaaS Factory helps organizations at any stage of the SaaS journey. Whether looking to build new products, migrate existing applications, or optimize SaaS solutions on AWS, we can help. Visit the AWS SaaS Factory Insights Hub to discover more technical and business content and best practices.

SaaS builders are encouraged to reach out to their account representative to inquire about engagement models and to work with the AWS SaaS Factory team.

Sign up to stay informed about the latest SaaS on AWS news, resources, and events.

About AWS Global Security and Compliance Acceleration

Global Security and Compliance Acceleration on AWS Program (GSCA) supports businesses globally that need to meet security, privacy, and compliance requirements for financial services, healthcare, privacy, and public sector. This includes both commercial and public sector workloads.

AWS Partners with compliances needs are encouraged to reach out to their account representative to understand program requirements and to engage with the GSCA team.