Trust & Security

Automation should save time without creating risk. This page explains how we handle data, access, retention, and incident response when building and supporting automations.

For procurement requests (DPA, security questionnaire, data-flow diagram), contact: security@kasperautomation.com

General contact: hello@kasperautomation.com

Summary

  • We process data only to deliver the workflows you request.
  • We aim to minimise data exposure and avoid unnecessary storage.
  • We use least-privilege access and secure credential handling.
  • We document your setup (workflows, runbooks, data flow) so it isn't a black box.
  • We define retention and deletion rules for logs and support data.
  • We have an incident process and a direct security contact.

Definitions

Customer / Controller
The client who decides why and how personal data is processed.
Kasper Automation / Processor
The service provider building/supporting workflows on the customer's instructions.
Subprocessor
A third party that may process personal data on our behalf (e.g., hosting, monitoring, support tooling).
Workflow execution data
Metadata or logs created by the automation runtime during workflow runs.

Hosting models

We support the following delivery models. The responsibilities and data exposure depend on which model you choose.

Client-hosted (recommended)

You run the automation runtime in your own environment (your cloud account or servers). We build and support workflows within that environment.

  • Customer controls infrastructure, networking, and data residency.
  • Credentials and tokens can be stored within the customer environment.
  • We deliver workflows, documentation, and runbooks for handover.

Managed by us (if offered)

We host and operate the automation runtime to deliver the service.

  • Kasper Automation operates the runtime and supporting monitoring needed for reliability.
  • Access, logging, and retention are defined up front.
  • Subprocessors may be involved for hosting and monitoring (see Subprocessors).

What data we process

The data processed depends on the tools you connect and the workflows you request. Typical categories include:

  • Contact details (names, emails, phone numbers)
  • CRM records (lead/customer fields, statuses, notes)
  • Operational messages (email/Slack/Teams content you route through workflows)
  • Files you intentionally pass through workflows (documents, exports)
  • Identifiers and metadata required to run workflows (record IDs, timestamps, event types)
  • Error and diagnostic data needed for reliability (limited logs)

We do not sell customer data and do not use it for advertising.

Data flow overview

Most automations follow this pattern:

  1. A source system triggers an event (e.g., new lead, form submission, stage change).
  2. The automation runtime applies your rules and transformations.
  3. One or more destination systems receive outputs (e.g., project tasks, Slack notifications, CRM updates, reports).

What we try to avoid

  • Storing full payloads when not required
  • Logging sensitive fields unnecessarily
  • Broad "admin" access when narrower scopes will work

Client-specific diagram

A client-specific data-flow diagram is available on request for your exact tool stack and hosting model.

Request it at: hello@kasperautomation.com

Access controls

We apply least-privilege access as a default approach.

Principles

  • Access is limited to what is required for the agreed scope of work.
  • Where possible, access is granted to named accounts and scoped roles.
  • Temporary access is preferred for troubleshooting where feasible.
  • Access is removed when no longer needed.

Credentials and secrets

Workflows often require API keys or OAuth tokens. Our approach:

  • Prefer OAuth where available
  • Store secrets using secure mechanisms appropriate to the hosting model
  • Do not request or store credentials outside agreed channels and secure storage
  • Support credential rotation and revocation on request and when access ends

Retention and deletion

Retention depends on your hosting model and chosen tools. We document the retention rules for your setup, including logs and support data.

Typical retention categories

  • Workflow execution logs
  • Error logs
  • Monitoring/alerting events
  • Support communications (email/tickets)
  • Backups (if applicable to the hosting model)

Deletion

Upon termination of services, we will delete or return customer data that we control, subject to legal and contractual requirements.

If you have specific retention requirements (e.g., 30 days), specify them during onboarding.

Subprocessors

We maintain a list of subprocessors used for hosting, monitoring, support, and analytics (where applicable).

View subprocessors list →

We will notify customers of material subprocessor changes where contractually required.

Security incident process

If a security incident affects customer data, we follow this process:

  1. Detect and triage
  2. Contain and remediate
  3. Investigate scope and root cause
  4. Notify affected customers without undue delay
  5. Document corrective actions and improvements

To report a vulnerability or security concern: security@kasperautomation.com

Data Processing Addendum (DPA)

If your organisation requires a DPA for GDPR/UK GDPR, we can provide one.

View DPA →

Security questionnaires

We can complete vendor security questionnaires and provide responses aligned to your hosting model.

Send questionnaires to: security@kasperautomation.com

FAQs

Do you sell or reuse our data?

No. We process customer data only to deliver and support the workflows you request.

Can you build without direct access to our systems?

Often yes. We can work with scoped accounts, staging environments, or via pairing with your team.

Do you store our CRM/client data?

We design workflows to minimise storage. Some tools may keep execution/error logs for reliability; we document what is stored and for how long.

Can we require client-hosted only?

Yes. If you require client-hosted, we will deliver and document that model.

Do you provide a DPA?

Yes. See /dpa.html.

Legal