Penetration Test & Remediation Procedure

Documents the path from docs/compliance/pentest-rfp.md's current state — RFP drafted, vendor shortlist chosen, never sent — to an executed test and a closed remediation cycle. State this plainly: this entire procedure is aspirational today. No penetration test has ever been run against stratify. pentest-rfp.md has "no findings doc, no re-test log, nothing indicating the RFP was sent" (register/facts.md). This document is the shape the first real cycle should take, and step 1 below is the actual, immediate blocker to starting it.

1. Fix the stale scope — the actual blocker

pentest-rfp.md §1 currently scopes the engagement against infrastructure that no longer exists:

• Says: "Web: apps/web auf Vercel EU" and "Backend: Supabase EU" (implying Supabase Cloud).
• Reality: production cut over to self-hosted Docker on Hetzner on 2026-06-03 — Vercel is

deactivated, and Supabase is self-hosted on the same Hetzner box, not Supabase Cloud (register/facts.md, "Infrastructure — current state").

• The RFP brief template (§7) also names "Vercel + Supabase" in the subject line and body text sent

to vendors.

This must be corrected before the RFP is sent to any vendor. Sending a scope document that describes the wrong hosting model would misdirect the tester's reconnaissance and network-layer testing, and would misrepresent stratify's actual attack surface to a vendor being asked to quote a fixed-scope engagement. Concretely: update §1's infrastructure bullets to Hetzner self-hosted Docker + Traefik + self-hosted Supabase, and update §7's brief template to match, before proceeding to §2.

2. Send to the shortlist

Once §1 is corrected, send the RFP to the four-vendor EU shortlist already drafted in pentest-rfp.md §4:

Budget cap: €25k for the initial engagement, per pentest-rfp.md §6 and the pre-seed budget line (10% of the round = CHF 50k, split so the initial test stays within €25k, with re-test at Phase C budgeted separately).

3. Scope priorities — already flagged P0

pentest-rfp.md §2 already prioritises the test types; the two most consequential for this ISMS are worth reiterating here explicitly, since they map directly onto the two structural controls this ISMS relies on most:

• Supabase RLS-bypass via anon key (P0) — the primary defence for every personal-data table.
• Audit-log tamper-resistance (P0) — the compliance-critical control behind every claim this

ISMS makes about the audit trail being non-bypassable-by-app-bug.

Both are marked P0 in the existing RFP and should stay P0 in whatever the corrected scope document says — this procedure does not change the priority ordering, only confirms it should survive the infra-scope correction in §1.

4. Findings triage — severity-based SLA

No dedicated vulnerability-management procedure (PRO-06) exists yet to inherit an SLA from, so this procedure defines its own, to be reconciled with PRO-06 once that is written:

Every finding, regardless of severity, gets a tracker entry (issue or equivalent) referencing the report finding ID, so remediation can be traced back to the specific test that surfaced it.

5. Remediation verification and re-test

• Criticals and highs get verified, not just marked fixed. Per pentest-rfp.md's own timeline

(§5: T+5 P0-findings fixed, vendor verifies via re-test, T+10 gates public launch), the vendor — not the person who wrote the fix — confirms closure for anything P0/critical.

• If the original vendor offers a re-test window as part of the engagement (Cobalt.io's PtaaS model

is well suited to this), use it; otherwise negotiate a fixed re-test fee up front as part of the RFP response (pentest-rfp.md §7 already asks vendors for delivery-timeframe and re-test terms).

• A Phase C re-test (KYC/Sumsub/Onfido, Stripe Connect payouts, suitability engine going live) is

already anticipated as a separate ~€20k engagement (pentest-rfp.md §8) — this procedure's scope is the Phase A initial test; the Phase C re-test should be re-scoped fresh against whatever the infrastructure looks like at that point, not assumed to be a rerun of the same brief.

6. Evidence this procedure produces

• The corrected RFP document itself (post §1 fix), dated.
• Vendor responses and the selection decision.
• The signed engagement/contract.
• The vendor's final findings report.
• The tracker entries and remediation evidence for each finding, by severity (§4).
• The re-test confirmation for every critical/high finding (§5).

7. Review

Reviewed whenever a scope-relevant infrastructure change occurs (another hosting migration, a new major integration), and otherwise annually or ahead of any planned public launch milestone — the RFP itself is explicitly staged as "sende vor Public Launch."