Skip to content
RunWhen

Security Incident Response Procedures

In the event that RunWhen detects a security incident that may involve customer data, this document outlines key contacts and communication procedures.

RunWhen’s highest priority is to maintain a safe and secure environment for customer data. We run an industry-leading information security operation that combines stringent processes, an expert incident response team, and multi-layered information security and privacy infrastructure. This document explains our principled approach to managing and responding to data incidents in the RunWhen Platform.

Incident response is a key aspect of our overall security and privacy program. We have a rigorous process for managing data incidents: actions, escalations, mitigation, resolution, and notification of any potential incidents that impact the confidentiality, integrity, or availability of customer data.

Data Incident Definition

RunWhen defines a data incident as “a breach of RunWhen’s security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Data on systems managed by or otherwise controlled by RunWhen.” While we take steps to address foreseeable threats to data and systems, data incidents don’t include unsuccessful attempts or activities that don’t compromise the security of customer data (e.g. unsuccessful login attempts, pings, port scans, denial of service attacks, and other network attacks on firewalls or networked systems).

Data Breach Types

Four types of data breaches the team at RunWhen has identified (not mutually exclusive; an incident may be re-evaluated as the situation evolves):

  • Workspace Potential Data Breach
  • User Identity Data Breach
  • User Suspected Breach
  • Ongoing Breach

Data Breach Communications

Workspace Potential Data Breach — Contacting Users

If the team at RunWhen has reason to suspect that an incident has occurred involving a potential breach of Workspace data, the team will make all commercially reasonable efforts to contact all users that have “admin” role via email. A Workspace may have unlimited users with an “admin” role (configured in the corresponding workspace and in the UI).

User Identity Breach — Contacting Users

If the team at RunWhen has reason to suspect that an incident has occurred involving a potential breach of user identity (login) data, the team will make all commercially reasonable efforts to contact the impacted users by their primary email. The system maintains a primary email address for each user that can be edited on the profile page.

User Suspected Breach — Contacting RunWhen

If a user has reason to believe that there has been a security incident that RunWhen did not detect, contact security-and-compliance@runwhen.com.

Ongoing Breach — Roles and Responsibilities

If either a RunWhen user or the RunWhen team has reason to suspect there is an ongoing breach, the company’s standard protocol is:

  1. Communication: Establish contact between the user with administrative privileges (“Admin User”) for the Workspace and the RunWhen Local agent installed in any user cluster and the RunWhen escalation team (“RunWhen Team”).
  2. Mitigate Risk of Concurrent Workspace Data Breach: Delete the RunWhen Local agent namespace in the end user cluster to secure data at risk (Admin User). On receiving Admin User authorization, delete the RunWhen Local Object and corresponding authorization token in the RunWhen Platform (RunWhen team).
  3. Mitigate Risk of Historic Workspace Data Breach:
    • If the Workspace uses RunWhen-managed encrypted GCP buckets for Enterprise Task Output Data, RunWhen Team will request authorization for deletion from Admin User for either (a) deletion of historic data, or (b) rotation of credentials to access historic data and, upon receipt, proceed accordingly. If there is any ambiguity or no response and the RunWhen Team has reason to believe there is material risk, the RunWhen Team will proceed with (b).
    • If the Workspace uses user-managed storage, the Admin User is responsible for taking actions appropriate with their organization’s security incident response procedures.

Breach Disclosure

If there is a data breach, the company will make commercially reasonable efforts to disclose an anonymized version of the event publicly via the company blog unless the User requests it remain private. Timelines may vary depending on the depth of remediation required.

PII Data

The RunWhen Platform is not intended to carry any individually identifiable data beyond names and emails of RunWhen users (no SSNs, driver’s license numbers, passport numbers, health/biomedical information). If such data is leaked into the RunWhen system via User or third-party contributed troubleshooting code, the company will make commercially reasonable efforts to remove this code from the RunWhen Platform until the issue can be remediated, and to delete any Enterprise Task Output Data where it may have appeared stored in RunWhen-managed encrypted buckets.

Following Industry Best Practices

RunWhen follows industry best practices in this area, matched to those of our cloud provider, Google Cloud Platform. See Google Cloud’s incident response processes for reference. When RunWhen declares an incident, we designate an incident commander who coordinates response and resolution and forms a response team with specialists from different teams. The incident commander manages the incident from declaration to closure.

For questions or to report a concern, contact security-and-compliance@runwhen.com.