How we respond when something is wrong.

This policy is maintained by RoadWave USA LLC (“RoadWave”) and applies to any suspected unauthorized access to, acquisition of, loss of, or disclosure of personal information held by RoadWave — whether through external attack, internal error, third-party vendor compromise, or lost / stolen device or credential. It also covers near-miss incidents that did not result in disclosure but warrant the same containment posture.

1. 1Anyone at RoadWave (or a vendor, researcher, or user) who suspects a security incident reports it to safety@getroadwave.com or directly to the founder.
2. 2We aim to acknowledge and triage security reports as soon as reasonably practical during working hours. For serious incidents, we begin containment as quickly as possible once discovered. The incident is logged with a severity level — Low, Medium, High, or Critical — based on what data may be affected and whether the issue is ongoing.
3. 3If the report is Medium or above, the incident is treated as Active until ruled out. We do not wait for confirmation to start containment.

For any incident at Medium severity or above, the following are notified immediately:

• •RoadWave founder / incident lead — point of accountability for the response.
• •Engineering — for technical containment and forensics.
• •Counsel — when there is a reasonable likelihood that personal information was involved or that breach-notification statutes are triggered.
• •Hosting, database, email, DNS, and infrastructure providers — notified when their platform is implicated or when credential rotation depends on them.
• •Law enforcement — when the incident involves unauthorized intrusion, extortion, or credible threats. See our Law Enforcement Request Policy.

The first response is to stop the bleeding. Depending on the nature of the incident, containment may include:

• •Revoking all active sessions and forcing re-authentication.
• •Rotating database credentials, service-role keys, and API tokens for any implicated provider.
• •Disabling the affected feature, route, or RPC at the platform level.
• •Pausing inbound writes (read-only mode) when integrity of the data is in question.
• •Cutting off third-party integrations until they can be verified.

If the suspected vector is a compromised credential, the credential is rotated before any further investigation. If the vector is unknown, we treat all production secrets as presumptively compromised and rotate them.

Before remediation overwrites state, we preserve:

• •Server logs (application logs, edge logs, database logs) covering the incident window.
• •Audit trails of administrative actions taken during the response.
• •Snapshots of affected database tables.
• •Any communication that surfaced the incident — bug reports, abuse reports, vendor advisories.

Preserved evidence is held in a write-protected location for at least the longer of: the duration of the active investigation, any preservation request received under our law enforcement policy, or two years.

1. 1Reproduce the issue in a non-production environment where possible.
2. 2Determine root cause — what allowed the access, what data was accessible, and over what window.
3. 3Patch the vulnerability and verify the patch holds under the same conditions that surfaced it.
4. 4Audit related code paths for the same class of issue.
5. 5Re-deploy and confirm production telemetry is clean.

Concretely:

• •Notification is sent to the email address on file for each affected user, from safety@getroadwave.com.
• •The notification describes — in plain English — what data was involved, when the incident happened, what we believe the cause was, what we have done to remediate, and what (if anything) the user should do.
• •Where required by law, regulators are notified within statutory timelines (e.g. GDPR Article 33 — within 72 hours of becoming aware where the incident is likely to result in a risk to rights and freedoms).
• •Public disclosure is made on the RoadWave site for incidents affecting a significant portion of the user base, and where doing so does not interfere with an ongoing law enforcement investigation.

We default to over-notifying rather than under-notifying. If we're unsure whether a given user's data was affected, we tell them anyway and explain the uncertainty.

Within 30 days of an incident's closure, the incident lead writes a post-incident review covering: timeline, root cause, what worked, what didn't, follow-up work, and concrete changes to this policy if the response surfaced a gap. The review is shared with the team and retained for at least three years.

If you've found a vulnerability, suspect an account compromise, or believe your data has been affected, write to safety@getroadwave.com with as much detail as you can share. We aim to acknowledge and triage security reports as soon as reasonably practical during working hours. For serious incidents, we begin containment as quickly as possible once discovered.

See also: our Law Enforcement Request Policy and Trust & Safety Protocol.