Skip to content

Privacy (PDPA and UU PDP) ​

Kestrel is built to be deployable under Singapore's Personal Data Protection Act (PDPA) and Indonesia's Personal Data Protection Law (UU PDP). Both allow monitoring of company devices, but they expect notice, purpose limitation and data minimisation, and UU PDP expects a data protection impact assessment (DPIA) for systematic monitoring. This page lists the controls Kestrel gives you; it is not legal advice.

Where data lives ​

All telemetry, alerts and audit records stay on your own server (PostgreSQL and ClickHouse in your Docker Compose stack). Nothing is sent to a vendor cloud.

What the agent collects ​

Detection runs on the device on full-fidelity events. What it watches:

  • Process starts and stops, image loads, command lines, signer and hash of programs.
  • Opens of sensitive files (browser credential stores, wallets, messenger and cloud credential files, decoys), not their contents (except the evidence capture below, which keeps copies on the PC after a data-theft alert).
  • Network connections and DNS queries.
  • Registry writes to autorun and security-relevant keys, scheduled tasks, services, WMI subscriptions.
  • PowerShell script blocks and AMSI content.

It never captures keystrokes, screenshots or browsing history. Admin remote access is the one deliberate exception to "no screen capture": it is interactive, admin-initiated, limited by the device's install profile, visible to the employee and audited, and frames and file contents are never stored. See Remote access.

Evidence capture for suspected data theft ​

Evidence capture is the second deliberate exception, besides remote access, to "content never leaves the device". After an ST-02 or ST-04 alert the agent keeps, encrypted on the PC, copies of the files the suspicious process tree staged, copies of the credential stores it read and a 60-second capture of its network connections. Nothing is captured in the background: every bundle is tied to one alert and one process tree.

  • What reaches the server automatically: only the list of contents (paths, sizes, times), filtered by the device's privacy settings like other uploads.
  • When content is uploaded: only when an administrator clicks Collect evidence on the incident. The employee is then told in the tray: "IT collected evidence from this PC for a security investigation".
  • Who can see it: every role with read sees the list of contents; only administrators (evidence.download, interactive session, not API tokens) can collect, download or delete. Downloads are AES-256 encrypted zips with a one-time password that is never stored.
  • Accountability: every collection, download, deletion and automatic expiry is in the hash-chained audit log.
  • Retention: on the PC, the policy's "Keep uncollected bundles on the PC" (default 14 days); on the server, Evidence bundles in Settings (default 14 days from upload). Both delete the content and keep the metadata and audit trail.
  • Never in telemetry: bundle contents never go into telemetry, ClickHouse or Hunt.
  • Turning it off: each part (staged files, list of secrets, copies of secrets, connection capture) can be turned off per policy; see Policies.

The copies can contain the employee's real passwords, cookies and personal files. Mention evidence capture in the employee notice and in your DPIA. Details: Evidence capture.

Upload controls (per policy) ​

The filters apply to what leaves the device. Alerts and their evidence are always uploaded.

ControlEffect
Upload raw events for huntingOff: only alerts and their evidence are uploaded.
Upload full command linesOff: command lines are cut to the program and its flags.
Replace user names with a hashUser names become a stable salted pseudonym. The server applies the same to the signed-in user in health reports, review requests and alert process users.
Upload DNS queriesOff: no DNS telemetry.
Upload script contentOff: PowerShell and AMSI content is replaced by [redacted].
Never upload paths underPath prefixes (for example personal folders) are never uploaded; the event keeps its type and process.

Retention ​

Set under Settings > Branding, privacy & retention > Data retention. Defaults: events 30 days (7 days on the PostgreSQL fallback), alerts 365 days, audit log 730 days. Collected evidence bundles: 14 days by default (1 to 365).

Notice and transparency ​

  • The tray app's Help & privacy tab shows the organisation's monitoring notice (Markdown, set per policy under Branding & notice) and a plain list of what Kestrel records and does not record.
  • Write the notice to cover what is collected, why, how long it is kept, who can see it and whom to contact. Mention remote access if any profile allows it.
  • Remote sessions always show a banner and a tray notification.

Accountability ​

  • Every analyst hunt query is written to the audit log, because hunting reads employee activity.
  • Uninstall token reveals, response actions, policy changes and every remote-access session and file operation are in the hash-chained audit log.
  • Use roles to limit who can hunt and who can act (see Settings).

Breach notification ​

Ransomware incidents add a manual checklist step to assess breach notification (PDPC within 3 days under PDPA, 3 x 24 hours under UU PDP). For stealer incidents the checklist assumes data may have left the device and lists what to rotate per data category; decide on notification with your data protection officer.

Released under the Apache License 2.0. SigmaHQ rules are under the Detection Rule License 1.1.