Security

Kloup handles fundraising data — investor pipelines, deal terms, soft commits, cap tables, partner-level commentary. The kind of data that, if leaked, ends conversations and sometimes companies. Security is not a feature we ship later; it's the substrate. This page describes our practices in plain language. Specifics held under NDA (audit reports, penetration test summaries, sub-processor inventory, security questionnaires) are available to customers — email security@kloup.com.

Data ownership and confidentiality

• You own your Customer Data. We process it only to deliver the Service.
• We never sell, syndicate, broker, or aggregate Customer Data, and we do not use it to train shared or third-party AI models.
• Investor pipeline contents, round terms, and data-room files are treated as Customer Confidential Information under written confidentiality obligations binding every employee and sub-processor with access.
• Internal access to Customer Data is restricted to a small on-call group, gated by SSO + hardware key, scoped to the operational task at hand, and audit-logged.

Encryption

• In transit — every connection runs over TLS 1.2 or higher, with HSTS enforced on app.kloup.com, api.kloup.com, and every customer subdomain. We disable legacy ciphers and pin to Cloudflare's modern profile.
• At rest — D1 (SQLite) and R2 (object storage) encrypt data at rest with AES-256 managed by Cloudflare. OAuth refresh tokens are additionally encrypted at the application layer with envelope encryption before being written, so a database read alone cannot reveal a token.
• Backups — encrypted snapshots in a separate bucket, scoped to the production account.

Authentication and authorisation

• Sign-in is Google OAuth only — no passwords stored, no shared accounts, no service users with broad rights.
• Access tokens are short-lived (1 hour) JWTs; refresh tokens (7 days) are HTTP-only-cookie-bound and rotate on use.
• Workspace access is membership-based: every API call independently validates the caller against the requested organisation. A leaked workspace id alone does not authorise access.
• Per-workspace roles (admin, manager, employee, advisor, current_investor, investor) gate every read and write at the API layer and are mirrored in the UI.
• Admin actions (role changes, member adds / removes, data-room permission changes) are recorded in an immutable per-workspace audit log.

Multi-tenant isolation

Each organisation's data is logically isolated by organization_id on every row in every table, with foreign-key cascades enforcing integrity. Middleware rejects any request where the authenticated user is not an active member of the target organisation. Tenants do not share databases, indexes, queues, or storage buckets at the application boundary — every data-room object is keyed by both organisation and resource id so a forged URL cannot escape its workspace.

Data room and watermarking

• Data-room links are scoped to a specific viewer and folder, with optional expiry, view caps, and download disablement.
• Documents are rendered with per-viewer dynamic watermarks (email + timestamp) — applied at request time, never baked into the stored file.
• Every view, download, and print intent is recorded in the data-room audit trail visible to workspace admins.
• You see who opened what, from where, for how long.

Infrastructure and hosting location

• Customer Data is hosted and processed primarily in the United States. Production databases (Cloudflare D1) and object storage (Cloudflare R2) live with primary storage in the eastern United States. Cloudflare's anycast edge serves cached and static assets from globally distributed nodes, but the canonical record of Customer Data lives in the United States.
• Some sub-processors operate in the US, EU, UK, or other regions. The full list (with country of processing) is in our Privacy Policy.
• Hosted on Cloudflare (Workers, Pages, D1, R2, KV, Queues, Logpush). No long-lived servers, no SSH surface.
• The application and API run on edge Workers that auto-scale and isolate execution per request.
• All deploys go through CI from a protected GitHub branch with required reviews and signed commits.
• Production secrets are stored in GitHub Actions environment secrets and pushed to Cloudflare on every deploy via signed action runs. No secret is ever committed to the repository, and no developer holds long-lived production credentials.
• Dependencies are pinned and continuously scanned. We patch high-severity CVEs within 7 days, critical within 48 hours.

Software development lifecycle

• Every change is reviewed by at least one engineer other than the author before merge.
• Static analysis, dependency audit, and type-check run on every pull request.
• Production database access is gated behind a reviewed runbook; ad-hoc reads on Customer Data are prohibited.
• Feature flags allow staged rollouts and rapid kill-switch on regressions.

Backups, recovery, and resilience

• Nightly D1 + R2 snapshots, retained for 30 days, encrypted with separate keys.
• Snapshots stored in a region distinct from the primary write region.
• Recovery is point-in-time per workspace. Documented RTO 24 hours / RPO 24 hours for full-tenant restore; partial-record restores are typically faster.
• The Service runs on Cloudflare's global anycast edge and degrades gracefully under regional faults.

Monitoring and incident response

• Application logs tail-shipped to Cloudflare Logpush, retained for 30 days. Authentication, admin actions, and data-room access are retained for 12 months.
• Anomalous-access alerts (impossible-travel sign-ins, bulk export, role escalations) page on-call.
• We commit to notifying affected workspace admins without undue delay and in any case within 72 hours of confirming a security incident that materially affects their data, with the information required to satisfy GDPR Article 33 / 34 and analogous laws.
• Post-incident, we publish a written root-cause analysis to affected customers within 30 days.

Vendor and sub-processor security

• Every sub-processor signs a written agreement with confidentiality, purpose limitation, and security obligations no less protective than these.
• We review sub-processor SOC 2 / ISO reports annually and re-evaluate on material changes.
• Customers are notified at least 30 days before adding a new sub-processor that handles Customer Data.

AI security posture

• AI features are opt-in. We pass only the minimum context required to fulfil a request.
• Where the provider offers a zero-retention or no-training mode, we use it. We do not consent to training on Customer Data.
• AI prompts and outputs are not used as training data for shared models, internal or external.
• Outputs are stored in your workspace as your Customer Data.

Vulnerability disclosure

Found something? We're glad to hear from you and we won't pursue legal action against researchers acting in good faith and within the bounds below.

• Email security@kloup.com with reproduction steps, the affected URL, and your reporter alias if you want one.
• Don't access, modify, or exfiltrate data that isn't yours. Reading the response that proves the vulnerability is enough — stop there.
• Don't run automated scanners against production. Use a workspace you own.
• Don't degrade service for other customers (no DoS, no resource bombs).
• Give us a reasonable disclosure window. We aim to acknowledge within 48 hours, fix critical issues within 14 days, and credit you publicly with consent.

We may offer monetary rewards for material findings at our discretion; we always offer credit and our gratitude.

Compliance

• We follow the principles of GDPR, UK GDPR, LGPD, and CCPA, and bind sub-processors to equivalent standards.
• SOC 2 Type II audit in progress with a recognised assessor; report available to customers under NDA when issued.
• Customers may request our security questionnaire response, sub-processor inventory, and most recent penetration-test summary at any time under NDA.

Contact

Security disclosures and questions: security@kloup.com.
Data Protection Officer: dpo@kloup.com.
Privacy: privacy@kloup.com.