DEV Community

Chethna
Chethna

Posted on

ISO 27017 and ISO 27018 for Multi-Tenant SaaS: A Practical Engineering View

Multi-tenant SaaS architecture creates an interesting security challenge: multiple customers can share an application and infrastructure, but each customer's information must remain appropriately isolated.

For Indian SaaS engineering teams, ISO/IEC 27017 and ISO/IEC 27018 provide useful perspectives on managing cloud security and protecting personal information in applicable public cloud processing environments.

1. Start With Tenant Isolation

Tenant isolation should be enforced throughout the application stack, not just at the user interface.

Depending on the architecture, controls may include:

  • Server-side authorization checks.
  • Tenant-aware database access.
  • Object-level access validation.
  • Storage permissions and access policies.
  • Encryption and appropriate key management.
  • Security logging and monitoring.
  • Automated tests for cross-tenant access.

A tenant identifier alone is not a security boundary. Applications must validate that every request is authorized for the relevant tenant and resource.

ISO 27017 provides cloud-specific security considerations that can help organizations assess these responsibilities within their broader control environment.

2. Include Privacy in Data Lifecycle Design

SaaS platforms may process names, email addresses, employee records, account information, and other personally identifiable information.

ISO 27018 focuses on applicable public cloud environments where a provider acts as a PII processor. Engineering teams should understand where such information enters the system, where it is stored, which services can access it, and how it is retained or deleted.

Deletion workflows should consider more than the primary production database. Depending on the architecture and applicable requirements, customer information may also exist in backups, logs, replicas, exports, and testing environments.

3. Map Cloud Responsibilities

SaaS providers often depend on an underlying cloud provider. Security responsibilities may be inherited, shared, or managed directly by the SaaS organization.

Create a responsibility matrix that identifies ownership for infrastructure configurations, identity controls, application security, monitoring, incident response, backups, and customer-facing security commitments.

Clear ownership reduces the risk of gaps caused by assumptions between teams or suppliers.

4. Integrate With an Existing ISMS

ISO/IEC 27001 provides the requirements for an Information Security Management System. Rather than building a completely separate cloud security program, organizations can map relevant ISO 27017 and ISO 27018 considerations into existing risk assessment, control management, supplier oversight, and incident processes.

This approach can reduce duplicated work while retaining the specific cloud security and privacy considerations relevant to the service.

5. Make Changes Reviewable

A change to a database schema, authorization layer, cloud configuration, or third-party integration may affect security assumptions.

Teams should connect architecture changes with risk reviews, code reviews, testing, deployment records, and updated documentation where needed. Automated tests can help detect cross-tenant access problems before release.

6. Maintain Evidence That Reflects Reality

Useful evidence may include architecture diagrams, access reviews, security test results, supplier records, incident procedures, data lifecycle documentation, and control review records.

Evidence should describe the actual production environment, not an outdated design or a process that exists only on paper.

Engineering takeaway: Multi-tenant security is a system-wide design responsibility. Connecting cloud security controls with privacy and data lifecycle practices makes the resulting framework more useful than treating each requirement as a standalone checklist.

Top comments (0)