Risk Assessment Report¶
Purpose. Records the information security risks identified for Soon, their analysis and evaluation per the Risk Assessment and Treatment Process (ISMS-DOC-06-2). Drives the Risk Treatment Plan and the Statement of Applicability.
Status: DRAFT — starter register. This is an initial, expert-judgement set of the most material risks, derived from the Information Asset Inventory and the context. It must be reviewed with named risk owners, who confirm the ratings and treatment decisions, before approval. Risk owners assigned 2026-08-13 by domain: Olaf (governance, people, privacy, supplier), Thomas (platform, access, product, network), Melvin (infrastructure, backups, availability).
Scoring: Likelihood (L) × Impact (I) = Score. 🟢 Low 1–4 · 🟡 Medium 5–9 · 🔴 High 10–25. "Initial" = inherent risk before/with current informal controls; "Residual" = target after the planned treatment is implemented.
Risk register¶
| ID | Risk (asset / threat → impact) | L | I | Initial | Treatment | Key controls | Residual (target) |
|---|---|---|---|---|---|---|---|
| R-01 | BYOD endpoints (END-01/02) lost, stolen or malware-infected → exposure of customer data/credentials | 4 | 4 | 🔴 16 | Modify | A.8.1, A.8.7, A.7.9, A.5.10; disk encryption, baseline, MDM/endpoint policy | 🟡 8 |
| R-02 | No central endpoint management → inconsistent, unverifiable endpoint security | 4 | 3 | 🔴 12 | Modify | A.8.1, A.8.9; MDM or documented hardening + attestation | 🟡 6 |
| R-03 | Credential compromise on SaaS tools lacking SSO/MFA. Confirmed 2026-07-04 (Melvin): the Soon GitHub org has MFA required by policy but not by the org-level "require MFA" setting — enforcement is on the honour system. | 3 | 4 | 🔴 12 | Modify | A.5.17, A.8.5, A.5.16; enforce SSO (WorkOS)/MFA everywhere feasible; enable GitHub org-wide MFA enforcement (immediate quick win). | 🟢 4 |
| R-04 | Over-provisioned / misused privileged access to AWS, Azure, GCP | 2 | 5 | 🔴 10 | Modify | A.8.2, A.5.18; least privilege, MFA, periodic access review | 🟢 4 |
| R-05 | Secrets/keys leaked (in code, chat, or misconfig) | 3 | 5 | 🔴 15 | Modify | A.8.24, A.8.4; GCP Secret Manager, secret scanning (Aikido), no secrets in code | 🟡 6 |
| R-06 | Source code / data exposed via AI tools (Cursor, ChatGPT, Gemini, Grok, OpenAI) | 3 | 3 | 🟡 9 | Modify | A.5.10, A.8.28; AI acceptable-use rule, no secrets/PII in consumer AI, enterprise terms | 🟢 4 |
| R-07 | Customer PII breach (Soon as processor) → GDPR fines, notification, churn | 2 | 5 | 🔴 10 | Modify | A.5.34, A.8.12, A.8.24, A.5.15; encryption, DLP, access control, breach procedure | 🟡 5 |
| R-08 | Confirmed 2026-07-03: Intercom (support/messaging) runs on Intercom's US-based stack, not EU-hosted → GDPR / "EU-only" claim breach. Other sub-processors believed EU-hosted, not yet systematically verified. | 3 | 4 | 🔴 12 | Modify | A.5.34, A.5.23; migrate to Intercom EU data hosting or replace (Linear S-303); verify remaining sub-processors; reconcile Security Overview. Owner: Olaf. | 🟡 6 |
| R-09 | Staging shares the production RDS host (rds-soon-soon-prod); unconfirmed whether staging exposes real customer data ("different state" — not yet defined) |
3 | 4 | 🔴 12 | Modify | A.8.11, A.8.33, A.8.31; mask/synthesize data, separate environments. Owner: Thomas — verify and clarify "different state," confirm data segregation. | 🟢 4 |
| R-10 | Sub-processor breach (Stripe, Intercom, Sentry, WorkOS, etc.) | 2 | 4 | 🟡 8 | Modify/Share | A.5.19–A.5.23; DPAs, due diligence, sub-processor list | 🟢 4 |
| R-11 | Suppliers used without DPA / security assessment | 3 | 3 | 🟡 9 | Modify | A.5.19, A.5.20; supplier register + due-diligence before onboarding | 🟢 4 |
| R-12 | Cloud misconfiguration (public S3, open security group, IAM error) | 3 | 4 | 🔴 12 | Modify | A.8.9, A.5.23; IaC review, config baselines, Aikido scanning | 🟡 6 |
| R-13 | Unpatched vulnerabilities in dependencies / images | 3 | 4 | 🔴 12 | Modify | A.8.8; dependency scanning (Aikido), patch SLA, pentest | 🟡 6 |
| R-14 | Production outage / loss of platform availability | 3 | 4 | 🔴 12 | Modify | A.8.14, A.8.16, A.5.30; AWS multi-AZ, monitoring, runbooks | 🟡 6 |
| R-15 | Backup failure or inability to restore (incl. ransomware). Confirmed 2026-07-04 (Melvin): automated daily RDS snapshots + manual dumps; storage encrypted at rest (KMS). Re-verified 2026-08-13: point-in-time recovery is available (LatestRestorableTime populated — in RDS, PITR is automated backups; the earlier "PITR not enabled" note was a misreading), retention raised 7 → 30 days, and the instance is Multi-AZ with deletion protection on. Remaining gaps: restore never tested end-to-end; snapshots live in the same AWS account, same region as the source DB (no cross-account/cross-region isolation — a ransomware event in that account could destroy both). |
3 | 5 | 🔴 15 | Modify | A.8.13; restore drill scheduled 2026-08-18 (M8) — never yet performed, copy snapshots to an isolated backup account/region (immutable where possible), correct customer-facing Security Overview. Owner: Melvin. | 🟢 4 |
| R-16 | No formal incident response → slow, uncoordinated handling; missed GDPR 72h | 3 | 4 | 🔴 12 | Modify | A.5.24–A.5.26, A.5.34; IR procedure + plans, breach notification | 🟢 4 |
| R-17 | Key-person dependency / single points of knowledge (small team) | 3 | 3 | 🟡 9 | Modify | A.5.37, A.6.3; document procedures, cross-train, backups of knowledge | 🟡 6 |
| R-18 | Leaver/contractor access not revoked promptly (JML gaps) | 2 | 4 | 🟡 8 | Modify | A.5.18, A.6.5; offboarding checklist, timely deprovisioning | 🟢 4 |
| R-19 | Phishing / social engineering of remote staff | 4 | 3 | 🔴 12 | Modify | A.6.3, A.8.5; awareness training, MFA, reporting culture | 🟡 6 |
| R-20 | Logging/monitoring gaps → incidents undetected | 3 | 3 | 🟡 9 | Modify | A.8.15, A.8.16; centralised logging, alerting on anomalies | 🟢 4 |
| R-21 | Confirmed 2026-07-02: attacker abuses a Soon product feature (free-text invitation message + team-logo upload) to send convincing phishing impersonating third-party brands (Microsoft, PayPal) to invitees | 4 | 4 | 🔴 16 | Modify | A.8.26, A.8.28, A.5.24–26; rate-limit/moderate free-text & logo uploads for new/unverified accounts, content validation, brand-impersonation detection, incident logged | 🟡 6 |
| R-22 | Confirmed 2026-07-03: the product has no native MFA for customer accounts using email/password login (mitigated only by offering social login / enterprise SSO as alternatives) | 3 | 4 | 🔴 12 | Modify | A.5.17, A.8.5; build native MFA for email/password accounts (product roadmap item); in the interim, encourage SSO adoption for higher-risk customers. Owner: Thomas. | 🟡 6 |
| R-23 | Customer data potentially processed by third-party LLM providers (OpenAI, Anthropic, Mistral, Deepseek, X.AI) via AI assistant/scheduling features, without confirmed DPA / zero-retention / EU terms | 3 | 4 | 🔴 12 | Modify | A.5.19–A.5.21, A.5.34; confirm what customer data reaches each provider, obtain/verify DPAs and data-handling terms, drop providers that don't meet GDPR comfort. Owner: Thomas (handed off, Q8). | 🟡 6 |
| R-24 | Fraud — insider misuse of privileged access. A founder/admin uses legitimate broad production access to read, export or alter customer data for personal gain. Small team = limited segregation of duties, so the technical ability exists and is hard to detect. | 2 | 5 | 🔴 10 | Modify | A.5.3, A.8.2, A.8.15, A.5.18; least privilege, CloudTrail + GuardDuty RDS/S3 monitoring (tamper-evident logs), quarterly access review, compensating oversight given SoD limits. Owner: Olaf. | 🟡 5 |
| R-25 | Fraud — billing/payment manipulation via Stripe. Subscriptions, discounts or refunds are manipulated (internally or by a compromised account) to divert funds or under-pay. | 2 | 3 | 🟡 6 | Modify | A.5.3, A.8.2, A.8.15; Stripe role separation + MFA, refund/discount changes reviewed, Stripe audit log retained and reconciled to accounting. Owner: Olaf. | 🟢 4 |
| R-26 | Fraud committed through the product. A customer's own employee manipulates schedules, worked hours or leave in Soon to inflate pay — Soon is the WFM system of record, so weak audit trail or over-broad in-app permissions would enable and conceal it, creating customer loss and liability for Soon. | 3 | 4 | 🔴 12 | Modify | A.8.15, A.8.26, A.5.15; immutable in-app audit trail of schedule/time changes, role-based permissions and approval workflows, customer-visible change history. Owner: Thomas. | 🟡 6 |
| R-27 | Fraud — account takeover of a founder/admin. Phishing or credential theft of an AWS/GitHub/Google admin lets an attacker act fraudulently using legitimate credentials (payment redirection, data theft, ransom). Compounded by R-03 (GitHub org MFA not enforced by setting) and R-19 (phishing). | 3 | 5 | 🔴 15 | Modify | A.5.17, A.8.5, A.6.3; enforce MFA org-wide, SSO where possible, phishing awareness, GuardDuty credential-anomaly detection, incident response. Owner: Thomas. | 🟡 6 |
| R-28 | Fraud — invoice / CEO fraud against Soon. A fake supplier invoice or spoofed "urgent payment" request from a founder causes a fraudulent outbound payment. Classic risk for a small, fully-remote team that approves payments over chat. | 3 | 3 | 🟡 9 | Modify | A.6.3, A.5.14; dual approval or out-of-band verbal verification for new payees and payment-detail changes, awareness training, no payment instructions actioned from chat alone. Owner: Olaf. | 🟢 4 |
Fraud risk (SOC 2 CC3.3)¶
SOC 2 requires that the organisation explicitly considers the potential for fraud when assessing risk — not only accident and external attack. Soon's fraud analysis covers the three angles an assessor expects:
- Fraud against Soon — insider misuse of privileged access (R-24), billing/payment manipulation (R-25), invoice/CEO fraud (R-28).
- Fraud using Soon's systems — account takeover of an admin leading to fraudulent action with legitimate credentials (R-27).
- Fraud through Soon's product — a customer's own staff manipulating hours or schedules for pay (R-26). This is Soon-specific: as the workforce-management system of record, the integrity of its audit trail is a customer-facing anti-fraud control.
Segregation of duties is inherently limited at four founders: the same people develop, deploy and administer production. Soon does not pretend otherwise. The compensating controls are detective rather than preventive — tamper-evident logging (CloudTrail with log-file validation, GuardDuty over RDS/S3 access), quarterly access reviews, peer-reviewed changes via pull request, and management review — and this limitation is recorded in the SoA under A.5.3.
Summary¶
| Initial level | Count |
|---|---|
| 🔴 High (10–25) | 20 |
| 🟡 Medium (5–9) | 8 |
| 🟢 Low (1–4) | 0 |
Note: R-15 initial score raised from 10 → 15 on 2026-07-04 after Melvin confirmed PITR is off and no restore has ever been tested; high-count unchanged.
The high-risk concentration is expected at this stage: controls exist informally but are not yet documented, implemented consistently, or evidenced. As the treatment plan is executed (policies tailored, MDM/endpoint baseline, SSO/MFA everywhere, supplier DPAs, incident response, residency confirmed), residual risk drops into the Low/Medium band, within Soon's Moderate appetite.
Next steps¶
- Review each risk with a named risk owner; confirm L/I and treatment.
- Transfer treatment actions into the Risk Treatment Plan (ISMS-DOC-06-4) with owners and due dates.
- Confirm the resulting applicable controls against the SoA.
- Re-rate residual risk once treatments are implemented; accept any residual at management review.
Change log¶
| Version | Date | Author | Comments |
|---|---|---|---|
| 0.1 | 2026-06-25 | Andrea Cardinali / ISMS | First draft — 20 starter risks from the asset inventory & context; ratings to be confirmed with risk owners. |
| 0.2 | 2026-07-02 | ISMS | Added R-21 — confirmed phishing/brand-impersonation abuse of a live product feature (reported 2026-07-02 weekly sync); see meeting log. |
| 0.4 | 2026-08-08 | ISMS | Added explicit fraud risk consideration (SOC 2 CC3.3): R-24 insider misuse of privileged access, R-25 Stripe billing manipulation, R-26 fraud through the product (hours/schedule manipulation), R-27 admin account takeover, R-28 invoice/CEO fraud; plus a section recording the segregation-of-duties limitation and its detective compensating controls. |
| 0.3 | 2026-07-03 | Olaf Jacobson | Resolved/updated R-08 (confirmed Intercom US-hosting gap), R-09 (owner Thomas), R-15 (owner Melvin, backups confirmed on). Added R-22 (no native product MFA) and R-23 (AI/LLM sub-processor data handling, owner Thomas). |
| 0.5 | 2026-07-20 | Andrea Cardinali | Summary counts corrected to 17 High / 6 Medium (R-04 and R-07 at level 10 are High per the acceptance criteria); no risk ratings changed. |
| 0.4 | 2026-07-04 | Melvin Jacobson | R-15 sharpened after Q5 answers: PITR not enabled, production retention 7 days (Knab 30), encryption at rest confirmed on, restore drill never done, snapshots live in the same account/region as prod — initial rating raised 10 → 15; treatment now names PITR + restore drill + off-account copy + Security Overview reconciliation as the specific actions. R-03 sharpened: GitHub org-wide MFA enforcement is off — added as an immediate quick-win treatment. |