Platform Documentation
Platform Documentation
Breadcrumbs

Data Loss Prevention

Purpose

This Data Loss Prevention (DLP) Policy establishes RunWhen's approach to minimizing the risk of unauthorized access, leakage, or loss of sensitive or enterprise-provided data. The policy defines our controls, governance structure, and technical processes for preventing data loss across RunWhen-managed infrastructure and services.

This document complements and references the following RunWhen security and compliance policies:


Scope

This policy applies to:

  • All enterprise data flowing through or stored within the RunWhen Platform

  • All employees, contractors, and service accounts with access to production environments

  • All components of the RunWhen architecture, including:

    • API gateways

    • Ingress infrastructure

    • Kubernetes-based services

    • Service mesh (mTLS / zero trust networking)

    • Managed GCP storage and telemetry infrastructure

    • RunWhen on-prem agent (“RunWhen Local”)


Ownership and Governance

The DLP process and controls are owned jointly by:

  • Head of Engineering

  • Head of Security/Compliance

The policy is reviewed at least annually or following any material changes in the platform’s architecture, data classification practices, or customer requirements.


Risk-Based Approach to DLP

RunWhen applies a risk-based strategy focused on minimizing the collection, persistence, and propagation of sensitive enterprise data:

  • Default Non-Persistence: Unless explicitly configured by the user, RunWhen avoids persisting Enterprise Task Output Data.

  • Minimal Surface Area: Data flows are streamlined to limit the number of services or storage systems exposed to sensitive content.

  • Data Classification: As detailed in our Data Security Framework, data is classified and handled accordingly, with automation artifacts treated as operational metadata and not inherently sensitive unless specified.


Technical DLP Controls

RunWhen enforces a combination of architectural, operational, and platform-level controls.

Encryption

  • In Transit: TLS 1.2+ is enforced across all ingress and service-to-service communication (Secure-By-Design Principles).

  • At Rest: Data in RunWhen-managed buckets is encrypted using GCP-managed keys; customer-specific key access can be requested.

Access Control

  • Least Privilege: All identities—user, service, admin—operate under least privilege principles with scoped access to only required workspaces or functions.

  • Short-Lived Credentials: All access tokens and API credentials default to short lifetimes, minimizing long-term exposure.

Workspace Isolation

  • Logical separation of customer data is enforced via workspace boundaries, supporting tenant-level segregation.

Network Security

  • All ingress is routed through a hardened ingress controller, with SSL passthrough, request limits, and service mesh integration.

  • Internal service traffic is protected by Linkerd, which provides mTLS, traffic policy enforcement, and telemetry.

Logging and Monitoring

  • Administrative and infrastructure-level access is logged and monitored via GCP Admin Activity Logs.

  • Tracing of ingress traffic is performed via OpenTelemetry and exported to centralized observability infrastructure.

  • Anomalous patterns are detected through integration with internal alerting systems.


Data Retention and Disposal

  • Enterprise Output Data is not stored unless the user explicitly enables retention.

  • Ephemeral task artifacts are discarded after completion.

  • Any retained data is subject to regular review and eventual deletion per customer retention policies or contractual requirements.


Incident Response for Data Loss

In the event of suspected or confirmed data leakage, the procedures defined in RunWhen's Security Incident Response Procedures are followed, including:

  • Immediate containment

  • Root cause analysis

  • Notification of affected parties (as required)

  • Remediation and retrospective review


Exclusions and Justification

RunWhen does not operate a traditional DLP scanning engine (e.g., content-based email or endpoint scanning) because:

  • Enterprise data does not flow through or reside on employee endpoints.

  • The platform does not store sensitive customer documents or PII by default.

  • Data minimization and transient processing mitigate the core risks addressed by traditional DLP systems.


Contact and Questions

For questions or further details on our DLP policy or data security program, please refer to our Security Contact page or email security@runwhen.com.