Skip to content

Open Questions — answers needed from Olaf / Andrea

These are the things the ISMS cannot be accurate without — they need a human answer (not derivable from the code). Answer inline under each "Answer:" line, or run /isms:questions in Claude Code to be walked through them and have the answers applied to the right documents.

The first questions came from mining the real repos (soon-brain, soon-server, frontend, Soon-IaC, devops) on 2026-06-25. Several confirm/​correct discrepancies between the code and the customer-facing Security Overview. Round 1 answered live with Olaf on 2026-07-03 — see the applied changes in this PR.

Q1 — Exposed secrets (urgent) 🔴 — RESOLVED

Plaintext production secrets exist in devops/cfg/* (DB passwords, AWS keys, a live Stripe sk_live_ key, OpenAI key, backend app_secret) and a live Google Maps key in frontend/.env. Were any of these ever committed/pushed (in git history), and will you rotate them? This determines whether we log a security incident. Answer: Confirmed with Melvin — local-only, never pushed to GitHub. Not an incident. Still logged as a routine hygiene item (rotate + move to a secrets manager).

Exact registered legal name, country of incorporation, company-registry number (e.g. Dutch KvK), and registered address. (Drives scope, policies, DPAs.) Answer: Soon Technologies B.V. · KvK 75939401 · BTW/VAT NL860449403B01 (RSIN 860449403) · Herengracht 420, 1017 BZ Amsterdam · incorporated 26-09-2019.

Q3 — People & employment — MOSTLY RESOLVED

Confirm the founders/team and roles: Olaf (ISM), Thomas Picauly (tech lead), Melvin (eng — surname?), Alessandro (product — surname? is Alessandro Cardinali the same/related to consultant Andrea Cardinali?). Who are employees vs ZZP contractors? (Drives HR screening, NDAs, access.) Answer: Team Soon = all founders and shareholders: Olaf Jacobson, Thomas Picauly, Melvin Jacobson, Alessandro Cardinali. External: Andrea Cardinali — Alessandro's younger brother (not the same person; related-party relationship noted in Roles & Responsibilities given Andrea runs the independent internal audit). TODO(owner: Olaf): exact employment/contract construct (employee vs DGA/management fee vs ZZP) for each founder — not yet specified.

Q4 — MFA reality — RESOLVED (reveals a product gap + an enforcement gap)

The app code has no MFA, but the customer Security Overview says "MFA enforced for production access." Where is MFA actually enforced — AWS/GCP/Azure consoles, WorkOS admin, GitHub? Is it enforced for all admins? (Core control + discrepancy to fix.) Answer: Internally, risk-tiered: MFA required for sensitive systems (AWS, GitHub); lower-value tools use Google login (inherits Google's protections); unimportant tools use password only. In the product: no native MFA for email/password customer accounts — mitigated today only by offering social login (Google/Microsoft) and enterprise SSO as alternatives. This is a real product gap, not yet built — tracked as a new risk (R-22) and a Security Overview correction. Follow-up (Melvin, 2026-07-04): GitHub MFA is policy-required but not technically enforced org-wide — the GitHub org setting "require MFA for all members" is off. Policy expectation exists but is not blocked at the platform layer. Action: enable org-wide MFA enforcement on the Soon GitHub org (a five-minute setting change). Feeds into R-03 (SaaS credential compromise).

Q5 — Backups reality — RESOLVED (reveals two real gaps)

The only backup evidence found is manual mysqldump from 2023 stored locally, with no confirmed RDS point-in-time recovery — yet the Security Overview claims "automated PITR backups." What is the actual current backup setup (RDS automated backups + PITR enabled? encrypted? where stored? restore tested?)? (Major control + risk R-15.) Answer: Confirmed with Melvin, 2026-07-04: - Automated RDS snapshots on for both instances, plus manual backups also taken. - Retention: rds-soon-soon-prod = 7 days (RDS
Update 2026-08-08: Knab is no longer a customer and rds-knab-soon-prd no longer exists; the production instance is rds-soon-soon-prod. default). - Encryption at rest: Yes, both instances encrypted with AWS KMS. - PITR: NOT enabled — only daily snapshots. This contradicts the customer-facing Security Overview ("automated PITR backups") — real product/control gap, worsens R-15. - Restore test: never done end-to-end. Backups that aren't restore-tested aren't really backups (A.8.13); becomes an action item (own: Melvin) and monitoring metric M8.

Q6 — Environment segregation — OPEN, OWNER ASSIGNED

Staging shares the production RDS host (rds-soon-soon-prod). Is staging using real customer data or masked/synthetic data? Is this intended? (A.8.31 + GDPR; risk R-09.) Answer: Belief (unconfirmed): staging uses a different frontend but the same backend database "in a different state." TODO(owner: Thomas): verify and clarify exactly what "different state" means (separate schema? snapshot? logical partition?) and whether real customer data is exposed to the staging environment.

Q7 — Data residency — RESOLVED (confirmed gap)

Confirm all customer personal data stays in the EU. Known: AWS eu-west-1 (Ireland), GCP europe-west4 (Belgium), Cloudflare global edge. Does any personal data leave the EU (incl. via Cloudflare edge or any US service)? (GDPR residency claim.) Answer: Confirmed gap: Intercom runs on Intercom's US-based stack, not EU — should be migrated (EU data hosting add-on, or replace). Aside from Intercom, all services believed EU — not yet code-scanned to confirm. Tracked as Linear S-303 and a new risk entry.

Q8 — AI sub-processors — HANDED OFF

The product sends data to OpenAI, Anthropic, Mistral, Deepseek, X.AI (assistant / scheduling). Does customer personal data go to these? Which are on DPAs / zero-retention / EU terms? Should any be removed for EU/GDPR comfort? (Sub-processors + A.5.34.) Answer: TODO(owner: Thomas) — handed to Thomas to confirm.

Q9 — Certificate scope — RESOLVED

For the ISO certificate, do we scope only the core production platform (soon-server, frontend, solvers, supporting AWS/GCP) — or also internal services (soon-seer, soon-connect, etc.) and the devops tooling? (Defines the audit boundary.) Answer: Core production platform only — soon-server, frontend, solvers, supporting AWS/GCP infra. Internal services (soon-seer, soon-connect, etc.) and the devops tooling repo are excluded from certificate scope, added to Context & Scope exclusions with justification.

Q10 — Timeline & certification body — RESOLVED

Target certification date, and have you selected/contacted an accredited certification body? Also: expected pentest timing (Andrea sourcing in Utrecht)? (Drives the plan and what must be ready when.) Answer: SOC 2 Type 1 engaged: Aman (getagency.com) — $2,500, ISO 27001 stays with Andrea's network (his contacts, pricier, he leads that project). ISO target: Q1 2027 (set 2026-08-13), after SOC 2.

Penetration test — included, after a scope dispute (settled 2026-08-11).

  • The original note here said the $2,500 package "includes pentest". That was an assumption taken from the advertised page and a call, never confirmed in the SOW — and it sat in the ISMS unchallenged for five weeks.
  • On 2026-08-10 GetAgency stated a pentest was not included and offered one at $4,000, while Tad had separately written that a web application pentest was required. The two statements contradicted each other.
  • Olaf challenged this against the published offer (getagency.com/startups, captured 2026-08-10: "audit and pen test included", "SOC 2 audit + pen test, as low as $2,500 total", "Independent penetration test — included").
  • 2026-08-11, Aman in writing: "There was a miscommunication internally about whether the pen test was required for your type I; it is not… We're happy to include a free penetration test." GetAgency's position is that the page is an application for credits rather than a product page; they included the test regardless. No additional cost.
  • Awaiting from GetAgency (requested 2026-08-12): scope, access needed, timing, deliverables, whether one remediation re-test is included, and whether the report can be scoped to also support ISO 27001.
  • Sequencing: run the test after S-299 closes, so the report is not dominated by a known, already-planned finding.

Lesson recorded. Vendor scope belongs in the ISMS from the SOW or a written confirmation — not from a marketing page or a verbal call.

Also flagged earlier: GetAgency uses assessment partners for the pentest and the examination, which addresses the original independence concern about one firm doing both.

Round 1 also produced

  • Reporting workflow clarified: Slack first for speed (channel by issue type — Development / DevOps / General / Security — always @-mention the channel or specific people), email second for the audit paper trail. Applied to the Incident Response and Event Reporting procedures, the essentials page, and the home page (which now links directly to the #Security and #General Slack channels).
  • Linear S-303 created for the Intercom EU-residency gap (Q7).
  • Strategy note: SOC 2 Type 1 (GetAgency) and ISO 27001 (Andrea) are now both concretely in motion, on separate vendor tracks. ISO remains the primary certification goal; SOC 2 is no longer just a "maybe later."

How answers get applied

Running /isms:questions will record your answers here and update the affected documents (asset inventory, risk report, SoA, privacy/backup/access policies, context & scope) on a branch, then open a PR. New TODO(owner) items found in documents are also surfaced here automatically.