Skip to content
Incident response

What happens when something goes wrong

Incidents happen to every platform. What distinguishes a mature one is how quickly it is noticed, how honestly it is communicated, and whether the same failure recurs.

Reporting an issue

How to read this page

This page is maintained by RapidRoot to answer common security and privacy questions about our platform. It describes practices that are in place today and clearly labels anything that is planned. It is not a certification, an audit result, or independent verification.

Email security@rapidroot.in with what you observed, how to reproduce it, and the impact you believe it has. Please do not test against other customers' data, run automated scans that degrade the service, or publish details before we have had a chance to respond.

Our response process

  1. 1

    Acknowledge

    We confirm receipt of the report so you know a human has it.

  2. 2

    Triage

    We reproduce the issue where possible and assess severity based on the data and customers exposed.

  3. 3

    Contain

    Limit exposure first — revoke a credential, disable a path, or roll back a change.

  4. 4

    Remediate

    Ship a fix and verify it in production rather than assuming the patch worked.

  5. 5

    Review

    Establish the root cause and the change that prevents the same class of issue recurring.

Communication philosophy

  • Affected customers are told what happened, what data was involved, and what we are doing — in plain language.
  • We would rather send an early update with incomplete information than go silent while we investigate.
  • We do not describe an incident as resolved until the fix is verified in production.
  • Where notification is legally required, we follow the applicable requirements for the jurisdictions involved.
No bug bounty yet

RapidRoot does not currently run a paid bug bounty programme. We still want the report, and we will credit researchers who ask to be credited.