Case study ยท Security and compliance SaaS
European ISO 27001 compliance platform (client name under NDA)
Hardening an ISO 27001 Compliance SaaS for Production on AWS
A European information-security company had a working Next.js product that helps its customers run ISO/IEC 27001 programs: control libraries, evidence requests, gap assessments, risk and audit registers, access reviews, vendor registers and generated ISMS documents. The product ran on Supabase Auth and Vercel. Its customers audit security for a living, so the platform had to meet the same bar it helps them reach.
Siblings Software completed the application and moved it to production on the client's own AWS account: ECS Fargate, RDS PostgreSQL, Cognito, S3 and SES, with mandatory multi-factor sign-in, database-level tenant isolation and a release path where every change is scanned, rehearsed and gated before it reaches production.
At a glance
| Client | European information-security company (name under NDA) |
| Product | Multi-tenant ISMS SaaS for ISO/IEC 27001 programs |
| Engagement | Fixed-scope completion and production hardening |
| Timeline | September to October 2026 |
| Stack | Next.js 16, Prisma, PostgreSQL 18 on RDS, ECS Fargate, Cognito, S3, SES, GitHub Actions |
| Split of work | Siblings: application, CI/CD, release runbooks. Client: AWS account and Terraform |
| Status | Live on AWS since October 2026 |
- Delivery partner: Siblings Software
- Related services: DevSecOps services, Cloud migration services, Next.js development
- More examples: all case studies
The Challenge
The existing product worked as an MVP, but three things stood between it and paying enterprise customers. Authentication lived in a third-party service that did not match the contract's AWS target. Tenant isolation depended on application code, so one missed filter could expose another customer's compliance evidence. And there was no repeatable, auditable way to ship a change to production.
The contract fixed the target: GitHub Actions to Amazon ECR, two ECS Fargate tasks behind a load balancer, RDS PostgreSQL, Cognito and S3, inside the client's AWS account. The client's own infrastructure team owns that account and writes the Terraform. Siblings had to deliver an application that fits that platform exactly, without ever handling secret values.
What Siblings Built
We finished and hardened the product modules the client's customers use every day: the control library and mappings, evidence requests with file uploads, questionnaires and sheets, gap assessments, risk, audit, access-review and vendor registers, generated ISMS documents with an editor, reminders by email, metrics, and two-way Outlook calendar scheduling through Microsoft Graph.
Then we made the platform production-grade. Sign-in moved to Amazon Cognito with mandatory authenticator-app MFA, checked by the application on every session, so a password alone never reaches customer data. Tenant isolation moved into PostgreSQL itself with forced row-level security, no bypass role at runtime and an append-only audit log. Every request gets a fresh Content Security Policy nonce, every write is checked against cross-site request forgery, uploads are validated by content and size, and sensitive routes are rate-limited.
How Releases Work
Continuous integration checks dependency licences, scans for leaked secrets, keeps npm audit at zero findings, runs lint and type checks, and executes about twenty automated proof suites against a real PostgreSQL 18.3 database: tenant isolation, authentication and the MFA gate, application security, storage, calendar sync, deployment contracts and every product module.
Container images are built on pinned hardened base images and scanned with Trivy, which blocks the release on any fixable critical vulnerability. GitHub Actions authenticates to AWS through OpenID Connect, so there are no long-lived AWS keys in the repository. Images are pushed to ECR by immutable digest. Database migrations ship in a separate migrator image, are rehearsed against PostgreSQL 18.3 with the production role's exact permissions, and the ECS service update only proceeds once that exact digest has been migrated. Rollback is a redeploy of the previous digest.
Results and Current Status
The production readiness package closed on 13 October 2026. A live password-plus-authenticator sign-in on the production Cognito pool reached the application on 10 October, and during the rollout requests alternated between two ECS tasks while the encrypted session held across both, with no forced re-login. Email left the SES sandbox on 6 October. All automated proof suites pass in CI, and npm audit stays at zero.
A few items are deliberately the client's: connecting Microsoft Graph for live mailbox sync, scheduling the reminder and calendar jobs in their infrastructure, and loading their own data. A penetration test was outside this package. Each of those is documented in a runbook the client's team can follow without us.
How We Used AI Coding Agents Safely
Much of the code was written with AI coding agents working inside written rules for the repository. Those rules ban credentials, keys, tokens and customer data from prompts, require sanitized fixtures, and require a human review of every generated migration and every piece of security code. The CI gates above apply to agent-written changes exactly as they apply to human ones.
This is the delivery model we now use across projects. See DevSecOps services for the pipeline controls and AI code security for how we review AI-generated code.
Frequently Asked Questions
Yes. In this project the client's team owned the AWS account and the Terraform, and Siblings delivered the application, the CI/CD pipeline and a written contract between the two: environment and secret names, task size, health endpoints, migration steps and rollback. We never read secret values.
When you want us to, yes, as part of our platform engineering and cloud migration services. When your team already owns Terraform, as here, we document exactly what the application needs and leave the infrastructure with you.
Here, sign-in uses Amazon Cognito with a mandatory authenticator app, and the application itself checks enrolment on every session, so a token without a confirmed second factor never reaches customer data. Passkeys were deliberately not accepted as a replacement for the authenticator.
In PostgreSQL itself, with forced row-level security, so even a bug in application code cannot return another tenant's rows. The application connects with a role that has no way to bypass those policies, and automated tests prove the isolation with two tenants on every change.
Yes. This client's name stays private under a mutual NDA, which is why this case study describes the work without naming them. We can arrange a reference call with permission.
Need a SaaS product ready for security-conscious customers?
We complete, harden and ship products that have to pass enterprise security reviews. Start with DevSecOps services, cloud migration or platform engineering, or tell us about your product below.