How fund and founder data is protected
Fund data kept apart in the database, one permission check everywhere, files scanned before opening and short-lived links. Planned controls marked as such.
Last updated
How fund and founder data is protected
Delsivo is at the design partner stage. Controls marked Built are written and tested in the code, ahead of the pilot. Controls marked Planned are designed and built with the product. Neither is a certification, and nothing here has been audited.
Separation between funds
One fund can never reach another fund's deals, founders or files, even through a bug in a screen.
Enforced by the database
PlannedEvery deal, document, interview, room, guest and search index row carries its fund, and the database refuses links between records of different funds.
One permission check everywhere
PlannedThe same check runs for pages, APIs, search, AI answers, background jobs, notifications and exports, always at the narrowest scope: fund, deal, folder, file.
Unknown records answer "not found"
BuiltAsking for another fund's record answers "not found", without saying whether it exists, and the attempt is recorded as a security event.
One record per fund for each founder
PlannedA founder who applies to two funds has two separate records. Nothing is shared or matched across funds.
Founder portals
Founder pages run apart from the investor app, so a portal can't be used to reach fund data.
Portals kept apart from the app
BuiltEvery request is routed by its address: a fund's portal answers only portal pages, app pages answer only on the app's own address, and anything else gets a plain not found page. Portals run on a separate domain from the investor app, so founder and investor sessions are never shared.
Founder sessions tied to one portal
BuiltFounders sign in with a one-time code sent to their email. The session cookie works only on that fund's portal, and a cookie replayed on another portal is refused and logged.
One founder account, approved per fund
BuiltFounders use one Delsivo account for every fund. A portal gets a sign-in only after the founder approves that fund, through a single-use code that lasts 60 seconds and works only on that portal's own address.
Domain ownership checks
PlannedA custom domain is attached only after a DNS ownership record checks out, and daily checks catch a domain that stops pointing at the portal.
No custom code on portals
PlannedFunds brand portals with logos, colours, fonts from a list and copy. Custom CSS and JavaScript aren't offered, and uploaded logos are cleaned of scripts.
Report this portal
PlannedEvery portal footer has a link to report a portal that looks like phishing or impersonation. Reports alert Delsivo staff, who can suspend the portal.
Decks, recordings and files
A file can't be previewed, read by AI or downloaded until it has been checked.
Scanned before use
PlannedEvery upload is scanned for malware before anyone can preview it, AI can read it or it is added to search. Suspicious files stay quarantined.
Private, encrypted storage
PlannedDecks, interview recordings and room documents are kept under private storage paths, encrypted at rest, with keys generated by the server rather than from file names.
Short-lived links after a check
PlannedDownload links last 15 minutes at most and are issued only after a permission check on that exact file version. Emails link to the page, never to the file.
Deletion removes derived copies
PlannedDeleting a file or a deal stops access at once, then removes previews, extracted text, search index rows and AI caches.
Guests see only what is shared
PlannedData room guests are named, their access expires, and preview-only guests never get a download link. Revoking a guest ends their access at once.
AI processing
AI works only on what the person asking is allowed to see, and people make every decision.
Permission-aware retrieval
PlannedSearch and AI answers are filtered by the asker's permissions before anything reaches a prompt, so a restricted file can't leak through a summary or citation.
Contact details removed
PlannedFounder phone numbers and email addresses are replaced before content goes to an AI provider, unless the task needs them.
Providers that don't train on your data
PlannedAI providers are used under terms that don't train on submitted content. Those terms are confirmed for each provider before any fund's content is processed.
Documents treated as untrusted
PlannedDecks, room files and web pages are handled as data, never as instructions. The AI has no tools that send messages, change stages or change permissions.
Citations checked
PlannedEvery finding must cite a real deck slide, transcript timestamp or document page. Quotes that can't be found in the source are dropped.
People decide
PlannedAI never changes a deal stage, passes on a founder or sends a message. A Partner approves every message to a founder, and overrides need a recorded reason.
Accounts and staff access
Few people can see data, and each of them sees only what their role needs.
Invitation-only accounts
BuiltNobody can create an account in the investor app without an invite to their email. Passwords are stored hashed, and a reset signs out every other device.
Two-factor sign-in
BuiltRequired for Delsivo staff. Offered and recommended to every fund role, and required for the roles a fund asks for.
Roles with least privilege
PlannedAdmin, Partner, Analyst, Committee member and Guest expert each see only what their role and the deal's access allow. Founders never see internal ratings or notes.
Support access only with permission
BuiltDelsivo staff can view a fund's workspace only after a fund Admin grants time-limited, read-only access. Data room files and recordings stay hidden unless the grant says otherwise.
One-step account lock
BuiltStaff can lock an account and end all its sessions at once, with a reason recorded in the audit trail.
Audit trail and monitoring
Every action leaves a record that the app itself can't rewrite.
Separate logs database
BuiltThe audit trail, security events and AI call logs live in their own database, apart from fund data.
Audit trail of every action
BuiltActions by fund users and Delsivo staff are recorded with who, what, when and from where.
AI call log without content
PlannedEach AI call records its purpose, model, prompt and rubric version and references to the documents used, never deck text, transcripts or contact details.
Security events and alerts
PlannedFailed sign-ins, bot checks, rate-limit hits, cross-fund attempts, quarantined files and access by revoked guests are recorded, and serious ones alert staff.
Nothing sensitive in logs
BuiltLogs never contain passwords, sign-in codes, tokens, deck or transcript text, or full founder contact details.
Abuse prevention
Public entry points are checked before anything reaches the data.
Cloudflare Turnstile
PlannedPublic forms, sign-in, founder sign-in codes, applications and portal reports use Cloudflare Turnstile to tell people from bots.
Rate limits and validation
BuiltEvery public endpoint is rate limited across servers, and every input is validated with length limits.
Signed webhooks
PlannedEvents from payment, email, transcription and scanning providers are accepted only with a valid signature.
Security headers
PlannedHTTPS everywhere with HSTS, a content security policy, and protection against framing and content sniffing. Microphone and camera are allowed only on interview pages.
No card data at Delsivo
BuiltPayments run on Stripe's hosted checkout and Razorpay Checkout. Delsivo receives only the card brand and last 4 digits.
How long data is kept
Funds set how long decks, recordings and transcripts are kept. Daily jobs are designed to delete everything else when its period ends.
- Decks, transcripts, form answers and room documents
- Set by the fund
- Interview audio and video
- Set by the fund, can be shorter than transcripts
- Quarantined files
- 30 days, unless staff release them with a reason
- Email bodies
- 90 days
- AI call logs (no document text)
- 90 days
- Audit trail and security events
- 1 year
- Consent and notice records
- Kept as proof after deletion, with personal details removed
Founders can ask for a copy, a correction or deletion
The fund is the controller of the data founders send it, so the fund decides each request. Founders are designed to ask from their workspace on the fund's portal, and the request reaches the fund's Admins with a 30-day due date. Funds can also log requests that reach them another way, and Delsivo helps when a request comes to us.
Deleting a founder is designed to remove their profile, answers, contact details, decks, recordings, transcripts and everything derived from them, including previews, search index rows and AI caches. De-identified counts and the record of consents and notices stay, so reports still add up and consent can be proven.
Every export and deletion is recorded in the audit trail. More detail: GDPR and UK GDPR, India's DPDP Act and what founders can expect.
If something goes wrong
The plan for a security incident, from the first alert to what we change afterwards.
Detect
Serious security events, spikes in failed sign-ins, quarantined files and portal reports alert Delsivo staff by email.
Contain
Staff can lock an account and end its sessions in one step, revoke founder or guest sessions, suspend a portal, or rotate a key.
Tell you
If a breach affects your fund's data, we tell your Admins without undue delay, with what we know, so you can meet your own duties as controller.
Notify and learn
We help you notify your supervisory authority within the 72-hour GDPR and UK GDPR deadline, the Data Protection Board of India and affected founders. Then we record what happened and what we changed.
Aligned with the frameworks, not certified
Delsivo holds no certifications and shows no badges. This is a roadmap, not a certification: we keep a control register mapped to SOC 2, ISO/IEC 27001, the GDPR and UK GDPR, India's DPDP Act and the CCPA, and this is where each one stands.
| Framework | Where we are | Next step |
|---|---|---|
| SOC 2 | Not audited. Controls, built and planned, are mapped to the Trust Services Criteria in an internal register. | Build the controls with the product, write the policies and risk register, then prepare for a Type I audit. |
| ISO/IEC 27001:2022 | Not certified. The same controls are mapped to Annex A. | Set up the management system (scope, policies, risk treatment) alongside the SOC 2 work. |
| GDPR and UK GDPR | Designed for the processor role: recording consent, access and erasure tools, fund-set retention and a public subprocessor list. | Finalise the data processing agreement with EU standard contractual clauses and the UK Addendum, and records of processing. |
| India's DPDP Act 2023 | Designed for funds as data fiduciaries: notices on portals, recorded consent for recordings, rights requests and retention limits. | Finish the legal review of the privacy policy and name a grievance officer. |
| CCPA as amended by the CPRA | Designed for the service provider role: no selling or sharing of personal information, and rights requests handled with the fund. | Add service provider terms to the data processing agreement. |
Also planned
The operational work around the product controls: testing, backups, reviews and policies. None of it is in place today.
- Planned: Cloudflare web application firewall and bot rules in front of delsivo.com, the app and fund portals
- Planned: Automated tests on every code change, including cross-fund, portal host and AI retrieval tests, blocking merges that fail
- Planned: Dependency and secret scanning on every code change
- Planned: Prompt-injection tests on decks, room files and web pages before any model or prompt change goes live
- Planned: Paired voice and text interview tests, so the same evidence gets the same assessment either way
- Planned: Point-in-time database restore, nightly encrypted backups and a monthly restore drill
- Planned: An external penetration test, covering portals, data room guests and AI retrieval, before the first paying fund after the pilots
- Planned: A written key rotation procedure and separate keys per environment
- Planned: Quarterly review of staff access, fund Admins and active data room guests, and a staff offboarding checklist
- Planned: Written security policies, a risk register and a breach notification runbook
- Planned: Signed data processing agreements and security reports collected from every provider
Found a security problem? Tell us.
Email hello@delsivo.com with “Security” in the subject. A dedicated security address will replace it; the trust centre and our security.txt will change on the same day.
Please include what you found, where, the steps to reproduce it and what an attacker could do with it. We aim to reply within two working days, keep you updated while we fix it, and credit you if you would like.
To report a fund portal that looks like phishing or impersonation, use the Report this portal link in the portal's footer, which opens our contact form with the address filled in, or write to the same address.
We don't run a paid bug bounty yet.
Rules for testing
- Test only against your own account, or a fund workspace or portal you are allowed to use.
- Don't access, change or delete another fund's or founder's data. If you reach any by accident, stop and tell us.
- Don't submit applications to real funds' portals, contact founders, or upload real malware.
- No denial of service, spam, social engineering of staff or funds, or physical attacks.
- Give us a reasonable time to fix a problem before you share it publicly.
We will not pursue good-faith research that follows these rules.
Security questions
Security, privacy or procurement questions? Email hello@delsivo.com.