System Description (SOC 2)¶
Purpose. The description of the system required for a SOC 2 examination — the services provided, the commitments made to customers, the components that deliver them, the boundaries, and the controls around them. The service auditor reads this alongside the control matrix; it is the narrative the report is built on. Follows the structure of AICPA DC section 200. Also serves ISO clause 4.3 (scope) and control CC2.3.
Status: DRAFT. Infrastructure facts re-verified against the live AWS environment and the GitHub organisation on 2026-09-08. Section 9 states what is not yet in place. A Type 1 description must describe the system as it is, not as intended.
1. Types of services provided¶
Soon Technologies B.V. (KvK 75939401, VAT NL860449403B01, Herengracht 420, 1017 BZ Amsterdam; incorporated 26 September 2019) provides Soon, a multi-tenant, cloud-based Workforce Management (WFM) SaaS platform, sold by subscription in Team, Business and Enterprise tiers.
The platform provides:
- employee and shift scheduling, including intraday planning;
- time and attendance, and leave/absence management;
- labour forecasting and AI-assisted auto-scheduling;
- employee communications and calendar integration;
- customer dashboards, administrative tooling and APIs.
Customers are organisations that plan and manage their own workforce with Soon, ranging from SMEs to large multinationals, concentrated in healthcare, hospitality, manufacturing and contact centres, with users in Europe, Asia and the Americas.
Soon acts as a GDPR data processor for the personal data customers place in the platform; the customer is the controller.
The company is privately held, founder-run and fully remote, with no offices and no data centres. Three operating founders (Olaf Jacobson, Thomas Picauly, Alessandro Cardinali) are supported by contractors and one external security consultant. A fourth co-founder, Melvin Jacobson, is a shareholder with no operating role.
Customer-facing endpoints: app.soon.works (application and API; api.soon.works is a stale DNS record scheduled for removal under S-428),
www.soon.app (marketing), status.soon.works (status page), soon.works/trust (trust
centre) and soon.works/legal/* (terms, privacy, GDPR).
2. Principal service commitments and system requirements¶
Commitments made to customers
| Commitment | Statement | Source |
|---|---|---|
| Availability target | 99.5% monthly uptime | Availability Management Policy |
| Recovery time objective | 8 hours to restore service after a major failure | Availability Policy · BC/DR Plan |
| Recovery point objective | 24 hours maximum data loss | Availability Policy |
| Data residency | Customer data processed and stored in the EU (AWS eu-west-1) | Context & Scope §6 |
| Data deletion | Customer data deleted 90 days after contract end | Records Retention Policy |
| Sub-processor changes | Controllers notified before a new sub-processor begins processing | Vendor & Sub-processor Register |
| Data subject requests | Soon assists the controller within 5 working days | Record of Processing Activities |
| Personal data breach | Controller notified without undue delay, supporting the GDPR 72-hour duty | Breach Notification Procedure |
| Encryption | TLS 1.2+ in transit; AES-256 (AWS KMS) at rest | Cryptographic Policy |
| Support and security contact | In-app messaging, support@soon.works, security@soon.works | Trust centre |
The availability, RTO and RPO figures above are internal objectives. Any contractual uptime commitment is agreed individually per customer and must not exceed them.
System requirements — how Soon meets those commitments: production runs in a single AWS account in eu-west-1 with the database in private subnets and no public endpoint; changes reach production only through peer-reviewed pull requests with automated gates; access follows least privilege with MFA on critical systems; the platform is monitored continuously with alerting to a monitored security address; and daily encrypted database backups are retained for 30 days in production.
3. Components of the system¶
3.1 Infrastructure¶
Verified in AWS account 742816139593, region eu-west-1 (Ireland), on 2026-09-08.
| Layer | Implementation |
|---|---|
| Cloud organisation | AWS Organization: a management account, the production account 742816139593, and 404379474355 (Soon-LogArchive) in a Security OU holding the organisation CloudTrail (s3://soon-org-cloudtrail-logs), the audit-evidence store (s3://soon-isms-evidence, Object Lock GOVERNANCE 1095 days, SSE-KMS) and the isolated backup vault. A service control policy (ProtectSecurityLogs) prevents deletion or weakening of those logs, including by an administrator of that account |
| Compute | AWS ECS on Fargate (cluster soon-server-production-cluster-prod) and Lambda; container images in ECR. Production API task 2 vCPU / 4 GB, auto-scaling 2–4 tasks at 60% CPU |
| Database | AWS RDS for MySQL 8.4.9 — rds-soon-soon-prod (Multi-AZ, KMS-encrypted, deletion protection on, not publicly accessible, automated backups retained 30 days, giving point-in-time recovery across that window) and rds-soon-soon-dev (single-AZ, 7-day retention). All verified 2026-09-08 |
| Cache and queueing | ElastiCache (Redis) and Amazon SQS |
| Storage | Amazon S3 with account-level Block Public Access enabled; buckets versioned and encrypted by the shared Terraform module |
| Edge and frontend delivery | Cloudflare Pages (web application), Cloudflare DNS, CDN and WAF, and Cloudflare Access in front of the internal ISMS site |
| Network | VPC with public and private subnets; a shared public Application Load Balancer per environment with host-based routing; TLS 1.2+ terminated at the load balancer; the web application is served through Cloudflare's edge network (WAF managed rules to be confirmed); the production database sits in private subnets with no public endpoint (removed 2026-08-19, soon-server#1675); two NAT gateways in production provide the fixed egress addresses that customer telephony integrations allowlist |
| Privileged database access | Engineers connect through AWS Systems Manager Session Manager under the SoonDevDatabaseAccess permission set — no direct network path, every session logged (ISMS-DOC-A05-37-1) |
| Secrets | AWS Secrets Manager (values set out of band, 30-day recovery window in production) and SSM Parameter Store; injected into ECS tasks at start-up |
| Audit logging | soon-org-trail — organisation-wide, multi-region CloudTrail with log-file validation, delivering to the log-archive account (created 2026-08-13) |
| Monitoring and detection | Amazon CloudWatch (metrics, alarms, logs), AWS GuardDuty (CloudTrail, DNS, VPC flow logs, S3 data events, RDS login events, EBS malware scanning), Sentry (application errors) and PostHog (product analytics, EU cloud). Findings and alarms publish to the soon-security-alerts SNS topic, which emails security@soon.works |
| Log retention | Application logs (CloudWatch, Sentry) 90 days; CloudTrail and audit logs 1 year; ECS log groups 180 days production / 30 days development |
| Infrastructure as code | OpenTofu (≥1.10, AWS provider ~>5.0), state in s3://soon-terraform-state-742816139593 with native locking; roots for production and development; approximately 1,100 resources under management |
| Environments | Production and development in AWS eu-west-1. Staging currently runs on Azure (a Container App against a shared Azure MySQL instance) and holds no production data (confirmed 2026-09-09); its AWS replacement is written in OpenTofu but not yet applied |
| Google Cloud | connect.soon.works (the soon-connect integration service) runs on a Compute Engine instance in europe-west4 and is called by the backend; Google Maps Platform serves address lookup in the front end; a small number of secrets remain in GCP Secret Manager. Migration of soon-connect to AWS is tracked in Linear |
3.2 Software¶
| Component | Implementation |
|---|---|
soon-server |
Core WFM backend: Node.js 20, TypeScript, GraphQL (graphql-yoga), Prisma ORM, Express, Redis-backed queues. Deployed as a container to ECS |
frontend |
Customer web application: React 18, TypeScript, Vite, Apollo Client, Radix UI, installable as a PWA. A Microsoft Teams embedded experience is served from the same codebase. There is no separate native mobile application |
| Solver services | Auto-scheduling and intraday optimisation engines |
soon-connect |
FastAPI microservice handling third-party OAuth flows and credential storage for customer integrations |
soon-integrations |
Scheduled data-extraction service (Python/Flask) |
| Authentication | WorkOS for enterprise SSO and SAML (Microsoft Entra ID, Okta, Google Workspace) and directory sync; Google and Microsoft social login; email and password with bcrypt hashing and JWT sessions. Native MFA for email/password accounts is not yet available (§9) |
| Interfaces | GraphQL as the primary API, REST endpoints for webhooks and billing, and a Model Context Protocol server |
| Customer integrations | Google Calendar, Microsoft Outlook/365 Calendar, Unexus, Genesys, EvolveIP, Zoom — enabled per tenant |
| AI features | OpenAI is the only large-language-model provider in production use; an Anthropic client is retained for a planned provider that is not yet live. Client libraries for three further providers were present but unselectable and have been removed (§9) |
3.3 People¶
| Role | Person | Responsibility |
|---|---|---|
| CEO and Information Security Manager | Olaf Jacobson | Accountable for the ISMS; commercial and strategy; privacy/data-protection owner (no separate DPO); auditor contact |
| CTO | Thomas Picauly | Engineering, infrastructure, availability and change; grants and revokes production access |
| CPO | Alessandro Cardinali | Product and design; operations, administration and people |
| Co-founder (non-operating) | Melvin Jacobson | Shareholder only — no directorship, no salary, no ISMS responsibilities |
| External security consultant | Andrea Cardinali (CyberSquad) | ISMS advisory, drafting and independent internal audit. A related-party relationship (brother of Alessandro Cardinali) is disclosed and recorded in the consultancy agreement |
| Contractors | Engineering contractors (ZZP) | Bound by the same policies, confidentiality undertakings and access process as employees |
All personnel work remotely within the EU on privately owned devices governed by the Device Security Standard.
3.4 Procedures¶
| Procedure | Summary | Document |
|---|---|---|
| Change management | Every change reaches production through a GitHub pull request; direct pushes to the default branch are blocked. Automated gates run build, tests, lint, type and schema checks. Every release to production requires a second founder's approval, enforced by branch rulesets on soon-server, frontend and soon-terraform (verified 2026-09-05); release pull requests flag changes to authentication, customer-data paths, billing, infrastructure, IAM, cryptography and destructive migrations for that reviewer. soon-server additionally uses CODEOWNERS. Frontend deploys are atomic with immediate rollback (Cloudflare Pages); backend deploys roll out through ECS with health checks. Emergency changes are reviewed retrospectively by another founder within 5 working days |
ISMS-DOC-A08-32-1 |
| Access management | Least privilege and role-based access; joiner/mover/leaver process; MFA on AWS, GitHub and Google Workspace; AWS access through IAM Identity Center permission sets; quarterly access reviews | ISMS-DOC-A05-18-1 · Access Control Policy |
| Incident response | Severity scale P1–P4 with response targets (P2 within four working hours); reported through #security for speed and security@soon.works for the record; the ISM declares an incident; Linear holds the record; post-incident review for P1 and P2; scenario playbooks for ransomware and denial of service; a parallel personal-data breach procedure meets the GDPR 72-hour duty |
ISMS-DOC-A05-26-1 |
| Incident recording | Every incident, or a signed quarterly nil entry, is recorded in the Security Incident Register | ISMS-FORM-10-2 |
| Backup and recovery | Daily automated encrypted RDS snapshots (production 30 days, development 7 days) plus manual dumps; a restore is tested at least annually, live during the DR exercise | Backup Policy |
| Vulnerability management | Dependency and container scanning through GitHub Dependabot and Aikido, enabled on all six repositories (verified 2026-09-08); remediation targets Critical 7 days · High 30 days · Medium 90 days; annual penetration test | ISMS-DOC-A08-8-1 |
| Secure development | Peer review, CI gates, no hardcoded secrets, OWASP Top 10 awareness | ISMS-DOC-A08-25-1 |
| Control monitoring | Automated control checks run from the soon-grc repository and collect their own evidence; independent internal audit by the external consultant |
ISMS-DOC-09-6 |
3.5 Data¶
| Data | Examples | Classification |
|---|---|---|
| Customer workforce personal data | Employee names, work email, role, team, skills, schedules, worked hours, availability, leave dates and types, absence records, push tokens, IP addresses | Restricted |
| Customer account and configuration | Tenant settings, roles, permissions, integration configuration | Confidential |
| Authentication data | Credentials, tokens, session and SSO identifiers, third-party OAuth tokens | Restricted |
| Billing data | Subscription and invoice records. Card data is held by Stripe; Soon stores no card numbers | Restricted |
| Operational telemetry | Application and infrastructure logs and error traces, which may incidentally contain personal data | Confidential |
Soon does not process special-category data by design. Absence is recorded as a category and a period, never the nature of an illness. The classification scheme is Public, Internal, Confidential, Restricted. Full inventory: Information Asset Inventory.
4. System boundaries¶
In scope — the production platform that delivers the service commitments in §2:
| Component | Description |
|---|---|
soon-server |
Core WFM backend API |
frontend |
Customer-facing web application and Teams experience |
| Solver services | Auto-scheduling and intraday optimisation |
soon-connect, soon-integrations |
Customer integration services, including third-party OAuth credential handling |
| Supporting cloud infrastructure | Compute, database, storage, networking, secrets, logging and monitoring (§3.1) |
Out of scope: internal-only services (soon-seer), the devops tooling repository,
marketing and finance activity that does not touch customer data or production systems,
customer-side environments and identity providers, and the physical and environmental
security of data centres, which is inherited from AWS.
Note on scope alignment. Soon's ISO 27001 certificate scope decision of 2026-07-03 excludes
soon-connectand the integration and forecasting microservices as internal services. This SOC 2 description includes them, because they run in production, are reached by the customer-facing API and handle customer OAuth credentials, so they bear on the security commitments being examined. The difference is deliberate. The final boundary is to be confirmed with the service auditor when the report mechanics are settled.
Trust Services Criteria: Security (Common Criteria CC1–CC9) only. Availability, Processing Integrity, Confidentiality and Privacy are not in scope for this examination.
Type: SOC 2 Type 1 — the design and implementation of controls at a point in time.
5. Subservice organisations and the carve-out method¶
Soon uses the carve-out method. The controls of the sub-processors below are not included in this description or in the scope of the examination; Soon's own controls over the selection, contracting and monitoring of those providers are in scope, and are described in the Supplier Relationships Policy.
Sub-processors engaged for all customers:
| Sub-processor | Purpose | Personal data | Location |
|---|---|---|---|
| Amazon Web Services | All production hosting — ECS/Fargate, RDS, S3, Lambda, CloudWatch | All platform data | EU (eu-west-1) |
| Amazon SES | Transactional email — invitations, notifications, password resets | Names, email addresses | EU (eu-west-1) |
| Cloudflare | DNS, CDN, WAF, front-end hosting, Access | Request metadata | Global edge |
| Stripe | Subscription billing and payments (PCI DSS Level 1) | Billing contact data — no card data at Soon | EU / US |
| WorkOS | Enterprise SSO and SAML | Authentication identifiers | US (SCCs) |
| PostHog | Product analytics | Usage events, pseudonymous identifiers | EU cloud |
| Sentry | Application error tracking | Incidental, within stack traces | To be confirmed |
| Intercom | In-app support and messaging | Support conversations, contact data | US — EU migration in progress |
| Cloudinary | Image and media hosting (avatars) | Uploaded images | EU / US |
| OpenAI | AI scheduling and assistant features | Scheduling context — zero-retention terms to be filed | US (SCCs) |
| Google Maps Platform | Address lookup and geometry | Address queries | Global |
| Google Workspace | Internal identity, mail and document storage | Data handled by staff, including contracts and DPAs | EU |
Integration providers (Google Calendar, Microsoft 365, Unexus, Genesys, EvolveIP, Zoom) are engaged per tenant, only where a customer enables that integration. Internal corporate tools that do not process customer platform data are listed in the vendor register and are outside this description.
6. Complementary user entity controls¶
The Type 1 conclusion assumes customers operate the following controls. Soon's controls alone are not sufficient without them. Customers are responsible for:
- managing their own users, roles and permissions within Soon, and removing access promptly when a person leaves;
- choosing and enforcing an authentication method — SSO or social login is recommended, since native MFA for email/password accounts is not yet available;
- configuring and securing their own identity provider, including its MFA policy;
- the accuracy, lawfulness and minimisation of the personal data they enter, and their own controller obligations under GDPR;
- reviewing and approving integrations they enable, and the scopes those integrations are granted;
- reporting suspected security concerns to security@soon.works without delay.
7. Significant changes during the period¶
Not applicable to a Type 1 examination, which reports on controls at a point in time. Material changes since the ISMS was established on 2026-07-02 are recorded in the change log of each policy and in the git history of this repository. The most significant were the removal of the production database's public endpoint (2026-08-19), the creation of a validated organisation-wide CloudTrail (2026-08-13), the increase of production backup retention to 30 days (2026-08-13) and the enforcement of pull-request review rulesets on the principal repositories (2026-09-05).
8. Incidents¶
No information security incidents have been detected or reported since the ISMS was established on 2026-07-02, confirmed by the Information Security Manager on 2026-09-08. The nil position for the quarter and the process for recording future incidents are held in the Security Incident Register.
9. Known limitations and remediation in progress¶
Stated openly because a Type 1 description must reflect the system as it is. Each item is tracked in Linear and reviewed at the quarterly security review.
| Item | Position |
|---|---|
| Backup restore has never been tested end to end | Snapshots are taken and retained for 30 days with point-in-time recovery available across that window, but no restore has been performed and timed. The most significant open item; scheduled before the examination |
| Backups are not isolated off-account | Snapshots remain in the production account and region; an isolated copy in the log-archive account and a second region is designed but not yet applied |
| No MDM or EDR on endpoints | A deliberate decision (2026-08-08) for a fully remote team on privately owned devices. Compensating control: the Device Security Standard with quarterly verifiable attestation |
| No native product MFA for email/password customer accounts | SSO and social login are offered and inherit the identity provider's MFA. Native MFA is on the roadmap (risk R-22) |
| Pull-request rulesets cover three of six repositories | Enforced on soon-server, frontend and soon-terraform. soon-integrations, soon-connect and soon-grc are not yet confirmed |
| GitHub secret scanning, push protection and code scanning are not enabled | They require GitHub Code Security, which is not on the current plan. Compensating controls: secrets are injected from AWS Secrets Manager rather than committed, every change is peer-reviewed, and the annual penetration test covers the deployed application |
| AWS Config is not enabled | No automated configuration-drift detection. Console changes are recorded by CloudTrail and drift surfaces at the next OpenTofu plan |
| Segregation of duties is limited | The same small group develops, deploys and administers. Compensating detective controls: tamper-evident organisation-wide logging, mandatory peer review, and quarterly access review |
| Sentry is configured to send personally identifiable information with no scrubbing | Recorded as a nonconformity; remediation open |
| Unused AI provider API keys are declared in the development environment | Credentials for three providers not in use (DeepSeek, Mistral, xAI) were declared in the dev application secret list. Verified 2026-09-08: production never carried them — the production secret list holds the OpenAI key only. Code references and the dev declaration are removed (soon-server#1764, soon-terraform#79); revocation at each provider remains open |
| Intercom is US-hosted | EU migration in progress. Transfer mechanisms for several sub-processors are still being documented |
| Staging runs on Azure, outside the AWS production account | The AWS replacement is written in OpenTofu but not applied. The owner confirmed on 2026-09-09 that this environment holds no production data. That statement has not yet been verified against the database itself, which is the open action in S-493; until it is, the claim rests on the owner's assertion rather than on evidence |
| CloudTrail and account-level configuration are not yet codified | Infrastructure as code covers roughly 1,100 resources but not the organisation and audit-logging layer |
| No organisation-level GitHub backup and no independent Google Workspace export | Recorded in the BC/DR plan |
| Several ISMS policies remain in draft | An approval round is in progress; approval status is visible per document in the register |
| Penetration test not yet performed | Engaged with the service auditor's testing team for 21–23 September 2026 |
10. Complementary information¶
- The controls that address each Common Criteria point, and the evidence for them, are held in the SOC 2 control matrix and the evidence pack generated from the evidence store.
- Management's assertion, the criteria and the as-of date are to be agreed with the service auditor.
Related documents¶
- Context & Scope · Information Asset Inventory
- Statement of Applicability · Risk Assessment Report
- Vendor & Sub-processor Register · Record of Processing Activities
- SOC 2 Type 1 Readiness · Security Overview
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2026-08-08 | ISMS | First draft — service, scope and boundaries, data, infrastructure (verified against live AWS), sub-processors, control environment, known limitations, complementary user entity controls. |
| 0.3 | 2026-09-08 | ISMS | GitHub organisation-wide two-factor authentication enforced (both the requirement and the secure-methods restriction); all four members and the outside collaborator verified compliant, none removed. Removed from §9. |
| 0.2 | 2026-09-08 | ISMS | Restructured to follow AICPA DC section 200: added principal service commitments and system requirements (§2), separated the five component categories (§3), stated the carve-out method for subservice organisations (§5), added incidents (§8) and significant changes (§7). Facts re-verified against live AWS and the GitHub organisation on 2026-09-08: RDS is MySQL 8.4.9 Multi-AZ with 30-day retention (was stated as 7), the validated organisation CloudTrail now exists, and frontend delivery is Cloudflare Pages (Netlify is superseded). Corrected the claim that code and secret scanning are enabled — they are not. People section updated to three operating founders with Melvin Jacobson non-operating. Limitations expanded with GitHub organisation 2FA, AWS Config, Azure staging and Sentry PII. |
| 0.4 | 2026-10-16 | Olaf Jacobson | Policies matched to practice (owner decisions 2026-10-16): release-level review, annual restore test, emergency-change review within 5 working days, quarterly security review. |