Security & Responsible Disclosure

1. Our promise to researchers

We treat a security report as a favour, not an attack. If you follow the rules below, we will acknowledge you quickly, keep you informed, fix the issue, and credit you if you want the credit. We will not threaten you, and we will not use the report against you.

Machine-readable contact details are published at /.well-known/security.txt.

2. Safe harbour

Security research conducted in good faith, within the scope in section 3 and the rules in section 4, is authorised by Vedatricks. For such research:

• we will not initiate or support legal action against you, including under the Information Technology Act 2000;
• we will not report you to law enforcement for the research itself;
• if a third party brings a claim about your research and you complied with this policy, we will make that authorisation clear to them and to any court;
• we consider your activity to fall within any applicable “authorised access” exception, to the extent it is within our power to say so.

Safe harbour ends the moment you go outside these rules — for example by exfiltrating data, degrading service, or extorting us. It does not authorise you to break a law we cannot waive, and it does not cover systems belonging to our customers or our vendors.

3. Scope

4. Rules of engagement

• Use your own accounts and your own data. Register a trial account if you need one. Never test with a real customer’s account.
• Stop at proof. As soon as you can demonstrate access, stop. Do not read, copy, modify or delete data that is not yours. If you see personal data, stop immediately, do not save it, and tell us what you saw in general terms.
• No denial of service, no volumetric testing, no brute forcing at scale, and no automated scanning that generates significant load. Keep request rates at a level a human could plausibly produce.
• No social engineering of our staff, customers or vendors, and no physical intrusion.
• No malware, backdoors, persistence, or changes to configuration.
• Identify yourself in traffic. Where you can, set a custom user-agent or a header such as X-Research: your-handle so we can distinguish you from an attacker.
• Do not extort. Do not condition disclosure on payment.
• Report promptly and keep it confidential until we have fixed it or the timeline in section 9 has passed.

5. How to report

Email hello@vedatricks.com. We do not publish a PGP key yet, so if the finding is sensitive, send a first message with no detail in it and we will agree an encrypted channel with you before you send the rest.

A good report contains:

• the affected host, URL or endpoint, and the date and time of testing;
• the vulnerability class, and clear step-by-step reproduction instructions;
• a minimal proof of concept — a request and response, a short screen recording, or a screenshot;
• the impact you believe it has, and any prerequisites such as an authenticated session;
• whether any data was accessed, and confirmation that you did not retain it;
• how you would like to be credited, or that you would rather stay anonymous.

Please send one issue per report, in English, and do not post it publicly first.

6. What to expect from us

1. Acknowledgement within 3 business days, from a named person.
2. Triage — a validity decision and a severity rating — within 10 business days.
3. Updates at least every 14 days while the issue is open.
4. Notification when the fix ships, with an invitation to re-test.
5. Credit in section 13, if you want it, and a note in our release notes where that is appropriate.

If we decide a report is not a vulnerability, we will explain our reasoning rather than close it silently. You are welcome to disagree, and we will look again.

7. Severity and remediation targets

8. Rewards and recognition

Our current position on monetary rewards is [ ● ]term not yet agreed; this document is in legal review. Regardless of that, every valid report gets a written thank-you, public credit at your option, and a direct line to the engineer who fixed it. We do not require an NDA to accept a report and we do not make payment conditional on silence.

9. Coordinated disclosure

• Please give us 90 days from your report before publishing, or until the fix ships if that is sooner.
• If we need longer, we will ask, explain why, and agree a date with you rather than let the clock run out silently.
• We are happy for you to publish a write-up afterwards, and we will review a draft for factual accuracy if you want us to.
• Please do not include customer data, personal data or working exploit payloads against live systems in a public write-up.
• If a vulnerability is being actively exploited, we may need to notify customers and the Data Protection Board before a fix is complete. We will tell you if that happens.

10. How we secure our systems

Stated plainly, with no badge we have not earned.

Infrastructure and network

• TLS on every public endpoint, with HTTP redirected to HTTPS.
• Cloudflare in front of our public properties for DNS, WAF, rate limiting and bot protection.
• Cloudflare Turnstile human verification on public forms and on the website assistant.
• Security response headers, including a content security policy, on our public sites.

Application

• Parameterised database access; CSRF protection on state-changing requests; output encoding.
• Tenant scoping enforced at the data layer and covered by automated tests that fail the build on a cross-tenant read.
• Rate limits on authentication, API and export endpoints; honeypot fields and minimum-time checks on public forms.
• Multi-factor authentication and session limits for administrative accounts.
• Field-level encryption at rest with a blind index for identifying fields in our clinical product.
• Append-only, hash-chained audit logging in products holding health records.

Engineering process

• Version control with review before merge; staged deployment through a test environment.
• Automated test suites and secret scanning gate the deployment pipeline.
• A database backup is taken before every production schema migration.
• Dependencies are updated on a regular cadence and on advisory.

Data and access

• Named staff accounts with least privilege; access revoked on exit; periodic access review.
• Access logs retained for at least 12 months, as Rule 6 of the DPDP Rules 2025 requires.
• Support access to customer data is logged, and break-glass impersonation is recorded in an audit trail.
• A documented incident-response runbook with a 72-hour regulatory reporting path.

We do not hold ISO/IEC 27001 or SOC 2 certification. We will say so plainly rather than imply otherwise. Where a control is provided by a vendor who does hold a certification, we name the vendor rather than claim the certification.

11. What we are still building

Publishing the gaps is part of the point. The current programme of work is [ ● ]term not yet agreed; this document is in legal review, with target dates at [ ● ]term not yet agreed; this document is in legal review. We update this list as items land rather than removing them quietly.

12. For customers and buyers

• Our processor commitments, security annex and sub-processor list are at /legal/dpa/.
• Our breach-notification commitments are in section 10 of the Privacy Policy and section 10 of the DPA.
• We complete standard security questionnaires under NDA. Email hello@vedatricks.com with your questionnaire and your timeline.
• To report a suspected compromise of your own account — not a vulnerability in our software — email hello@vedatricks.com with “ACCOUNT COMPROMISE” in the subject and call +91 88578 60930. We will lock the account and preserve logs while we investigate.

13. Thanks

This is where we credit the researchers who report to us. Nobody is listed yet. The first valid report goes here, under the name or handle you choose, on the date we fixed it — or nowhere at all, if you would rather not be named.