Data retention & processing policy

Last updated: 2026-04-29

This policy describes how long ArcSentinel keeps each category of personal

data, on what legal basis, and how it is destroyed.

It supports the GDPR's storage-limitation principle (Art. 5(1)(e)), our

NIS2 obligations on traceability, and customer due-diligence reviews.

Retention table

DataRetentionReasonMethod of removal
Account record (users)Until you delete itYou decide when to leaveHard DELETE, cascades to dependent rows
Workspace records (targets, cases, scans, intel_entries)Until you delete the parent record or your accountYou own the dataHard DELETE
Sealed vault entries (vault_entries)Until you delete the entry or your accountYou own the data; we cannot read it anywayHard DELETE
API keys (api_keys)Until you revoke or until expires_atActive session credentialsHard DELETE on revoke; nightly job purges expired rows
Activity log (activity_log) — operational events24 months from creationLegitimate interest: incident investigation, NIS2 traceabilityNightly job removes rows where created_at < now() - interval '24 months'
Activity log — auth failures (auth.login_failed, security.*)12 monthsSufficient for forensic correlationSame nightly job, separate predicate
Notifications (notifications)6 months after read_at, 12 months if unreadReduce noise; not load-bearingNightly job
Backups30 days rollingDisaster recovery; longer retention is unnecessary riskSnapshot rotation; oldest snapshot is cryptographically destroyed
CDN / web logs14 daysOperational debugging onlyProvider-managed rotation
Error reports (Sentry, optional)90 daysBug triageSentry default; we never extend

Deletion mechanism

When you delete your account:

  1. The users row is hard-deleted.
  2. PostgreSQL cascades the delete to every dependent table via the

foreign-key constraints in apps/web/src/lib/schema.sql.

  1. A data.deleted audit row is written without your user id; it is

anonymous evidence that the deletion happened.

  1. Backups containing the data are overwritten on the next 30-day

rotation; we do not selectively scrub backups, but the encryption keys

protecting them are destroyed when they age out.

Destruction of credentials

  • Passphrase: only the bcrypt hash is stored; on delete the row vanishes.
  • API key: only the Argon2id hash is stored; revocation removes the row.
  • Vault entry: the ciphertext and IV are deleted. We never had the

decryption key.

Anonymisation

Where retention is necessary for legal compliance after account deletion

(e.g. a subpoena referencing an incident), we retain only:

  • the kind of the action,
  • a coarse timestamp,
  • a hashed (salted SHA-256) IP fragment.

No identifying fields are retained.

Review cadence

This policy is reviewed at every minor release and at least once per

calendar year. The owner of this policy is ArcNode

info@arcnode.dev.

Subject access

To request a copy of everything we still hold under retention rules use

Settings → Security → Export data or write to

info@arcnode.dev. Statutory response window is

30 days.