Responsible Disclosure

Safe harbour

If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will not report you to law enforcement for accessing our systems in the course of it. We will work with you to resolve the issue, and we will credit you publicly if you want that — or stay quiet if you do not.

Good faith means you stayed in scope, stopped as soon as you confirmed a vulnerability, did not access, modify, retain or exfiltrate anyone else's data, and gave us a reasonable chance to fix the issue before telling anyone else.

This is our commitment, not legal advice, and it cannot bind third parties. Where your research touches one of our subprocessors, their own policies apply to their systems.

How to report

Email security@grantverse.io. Please tell us what you found, the impact you believe it has, and the steps to reproduce it — a short proof of concept is worth more than a scanner report. Include any accounts, IP addresses or timestamps you used so we can find your traffic in our logs, and say whether you would like to be credited.

Please do not open a public issue for a security report.

What you can expect from us

• We acknowledge your report within 2 business days.
• We tell you our severity assessment, and whether we could reproduce it, within 5 business days.
• We aim to fix critical and high-severity issues within 7 days of confirming them, or to explain why it will take longer.
• We coordinate public disclosure with you, normally within 90 days of your report.

These are targets we hold ourselves to, not contractual guarantees. If we are going to miss one, we will tell you before the deadline rather than after it.

We do not currently run a paid bug-bounty programme. We would rather say so plainly than imply a reward that is not coming.

In scope

• grantverse.io, www.grantverse.io, and the application
• The public and authenticated APIs, including the Institutional API
• Authentication, session handling, and multi-factor enrolment and verification
• Authorisation between tenants — anything letting one startup, investor or advisor read or change another's data
• Billing, webhooks, and plan entitlement gating
• Data export and erasure paths

Cross-tenant data access, authentication bypass, and anything exposing a founder's financials to another user are our highest-severity classes. Say so in your subject line and we will move faster.

Out of scope

• Denial of service, volumetric load testing, or anything that degrades service for real users. Please do not stress-test production.
• Social engineering of our staff, customers or suppliers; physical attacks.
• Automated scanner output with no demonstrated impact, including "missing header" and "weak cipher" findings with no exploit path.
• Self-XSS, or issues requiring a victim to paste attacker-supplied code into a console.
• Attacks requiring a fully compromised device or a malicious browser extension.
• Email spoofing claims that do not account for our published SPF, DKIM and DMARC records.
• Vulnerabilities in third-party services we consume — please report those to their vendors, and tell us so we can assess our exposure.

Rules of engagement

• Test only against accounts you own. If you need a second account to demonstrate a cross-tenant issue, create one — please do not use a stranger's.
• If you reach someone else's data by accident, stop, do not save it, and tell us in your report. We will treat that as good faith.
• Do not run automated scans that generate sustained load. Email us first and we will agree a window and a source address.
• Do not modify or delete data you did not create, and do not leave persistent artefacts on production.
• Do not publish details before the coordinated date we agree with you.