What Parascope collects from your estate, where it is stored, how long each kind of record is kept, and what happens when you leave.

Parascope reads your infrastructure through each source's own API and keeps what it finds, with history. This page sets out the four things a data-protection review needs: what lands in the platform, where it sits, how long each category survives, and what the deletion path does. Retention figures below are the platform defaults, taken from the configuration the retention worker reads.

What Parascope collects

Most of what Parascope collects is metadata about machines and services. For each object a source exposes, Parascope stores an identifier and name, the configuration the source reports, the relationships the object participates in, and the history of how those values changed. A virtual machine contributes its name, its ID, its power state, its CPU and memory allocation, and its place in a cluster. It does not contribute the contents of its disks.

Each collector separates two kinds of field. Config fields are intentional state, and a change to one is recorded in change history. Metrics fields are runtime counters such as CPU utilisation, and they are held on the current record without a history entry. That split is why change history stays readable at estate scale.

One category is worth calling out to a privacy reviewer, because it is people data arriving through a machine-data pipeline. Several sources model humans as first-class objects, and where you connect such a source, those objects are collected as configuration items like any other. Keycloak users, Jira users, Backstage users, OpenStack users, and NetBox contacts carry names and email addresses, and in the Keycloak case usernames and given and family names as well. If that is outside the scope you want, the control is which sources you connect and which credentials you give them, since a collector reads what its credential can read.

One collector goes further than an API call. The Linux collector opens an SSH session to the host and streams a read-only shell script over stdin, writing no files to the target and leaving no agent behind. OS Collection lists what that script reads.

Personal data the platform itself holds

Separate from collected infrastructure data, the platform processes a bounded set of personal data to run your account:

Category	What it holds
Team member accounts	Username, email address, given and family names, and authentication state, held in your tenant's identity realm.
Audit metadata	The acting user's email, the source IP address, the event type, and a timestamp for each recorded security event.
Billing records	Stripe customer and invoice identifiers plus a billing contact address. Card details are entered on Stripe's hosted checkout and are not held by Parascope.
Support correspondence	Whatever you send to the support and security addresses.

Parascope Limited acts as processor for the data in your tenant, and you are the controller. A data processing agreement is available on request from [email protected] and is currently in legal review; that address also takes access and erasure requests.

Where the data lives

The platform runs on Hetzner Cloud in Helsinki, Finland. Your tenant database, the stream storage that carries collected data, the Kubernetes Secrets holding platform credentials, the primary backups, and the export bucket are all in that region.

Two flows leave it, and both are deliberate:

Offsite backup replica. A copy of the database backups and WAL archives is mirrored to Cloudflare R2, encrypted before upload. It exists so that a single-provider incident cannot destroy both the running platform and every backup of it. Availability, Backups and Disaster Recovery covers the mechanism.
AI features. When you use the natural-language query or advisor features, prompt content reaches Anthropic in the USA under standard contractual clauses. AI Features and Your Data states exactly what is sent, how permission filtering bounds it, and how to turn the features off.

Subprocessors lists each third party that touches tenant data, its role, and its transfer mechanism.

How long each category is kept

A retention worker runs inside your tenant's API service and sweeps once per day under an advisory lock, so one replica prunes a given database at a time. Deletes run in small batches with a commit per batch.

Record	Retention	How it is enforced
Change history	730 days	`ci_changes` and `ci_field_changes` are monthly partitions. A partition whose entire range predates the window is dropped as a catalog operation. A configured window under 90 days is refused, with no drops.
Security audit log	90 days	Row prune on the daily sweep. Export the log to CSV first if your own policy needs a longer archive. An export covers a date window of up to 31 days, so a full-retention archive is three or four exports, each one covering exactly the range you asked for.
LLM spend records	90 days	Row prune. Only the current UTC day gates a spend cap, so older rows are an audit tail.
Cost conservation reports	90 days	Row prune. The consumption solver writes roughly 288 rows a day on a busy tenant.
Pending correlation candidates	90 days	Row prune of pending candidates. Confirmed candidates are the provenance of a live relationship and are kept; rejected ones are the engine's re-discovery memory and are kept.
Collector statistics	14 days raw, 730 days hourly rollups	Closed UTC hours are folded into an hourly rollup table, then raw rows are deleted once their bucket exists. The longest window the product can request is 7 days, so the raw window stays fully populated.
Tenant exports	7 days	An hourly sweep deletes every object version under the export's key and nulls the key on the record. The record survives as an audit trail.

Two honest notes on the change-history figure. The window is the same for every tenant, with no per-plan variation. And it is not yet load-bearing: no tenant holds two-year-old change data, so the drop has had nothing to drop in production so far.

Archived configuration items carry a retention control you set yourself. Under Settings → Lifecycle you set how long a CI stays archived before permanent removal, between 1 and 365 days, with 7 days as the default. Removal runs when you trigger it, and a dry run reports what a real run would delete.

Source credentials

Source credentials you enter in Parascope are stored encrypted (AES-256-GCM) in your tenant's dedicated database and delivered only to your collectors over TLS; the platform's collectors read them one source at a time under an audited reveal grant. Encryption states the at-rest scope precisely, including what is not covered.

The handling around that is worth stating in full, because it is what makes the grant auditable:

There is one write path, PUT /api/v1/sources/{id}/credentials. It encrypts the values, returns none of them back, and advances a non-secret marker recording when the credential last changed. The matching DELETE erases the encrypted blob.
Reading a credential back goes through a single endpoint, GET /api/v1/sources/{id}/credentials/reveal. It requires an explicit sources:reveal_credentials grant on the API key, which admin or service tier alone does not confer, and it writes a source_credentials_revealed entry to the security audit log on each call.
The sources list returns no credential values to any caller. A collector fetches one source at a time through the reveal endpoint and caches the result until the change marker moves.
Each encrypted blob is bound to its tenant and source through the cipher's additional authenticated data, so a blob copied onto another source's row or into another tenant's database fails authentication.

Managing Credentials covers the day-to-day workflow.

Exporting your data

A full tenant export is available from Settings → Account → Data Export, gated to superadmins. It produces structured JSON covering your configuration items, relationships, change history, and configuration, with the user records from your identity realm included on request.

The archive is encrypted with AES-256-GCM in the export worker before it reaches object storage, so the bytes at rest in the bucket are ciphertext. Download runs through an authenticated route in the product that decrypts and streams the archive to you. The platform mints no presigned storage URLs, and the notification email links to your settings page and carries no link to the archive itself. An archive above the size ceiling (500 MiB by default) fails the export with a clear error before encryption, so an oversized run stops early.

After 7 days the sweep deletes the object and its prior versions. The export record stays visible and reports that the archive is gone, so a stale link in your own records resolves to an explanation. Request a fresh export whenever you need one.

Deleting a tenant

Deprovisioning runs as a durable workflow. The sequence is fixed:

Immediately. The Stripe subscription is cancelled, so billing stops at the point of the request. The tenant's messaging access is revoked, which stops further ingestion and cuts off the collectors and any paired appliance. The tenant is recorded as deprovisioning and retired from collection, and its stored data stays readable through the grace window that follows.
A 30-day grace period. The workflow sleeps. A request with no recorded timestamp gets the full grace window anchored at that moment, so a missing field cannot collapse the wait. Reactivating during the window aborts the teardown, and the workflow re-reads tenant state after the sleep to confirm the tenant is still slated for deletion before it destroys anything, writing an audit row when it aborts.
Teardown. Export objects and their versions are deleted under the tenant's prefix. The Helm release is uninstalled, which removes the running workloads. The tenant database and its role are dropped. The tenant's message streams and then its messaging account are deleted, revoking the account's signed credential. The identity realm is deleted. Control-plane keys bound to the tenant are revoked, so a non-expiring key cannot outlive the tenant it belonged to.
Record. The tenant transitions to a deprovisioned state and an audit entry is written.

Two properties of that workflow matter to a reviewer. It fails closed on the two steps that could leave something live behind it: a failure to cancel billing or to revoke a control-plane key halts the run for a human to confirm, because a torn-down tenant with a live subscription or a live key is the worse outcome. And a failure to delete export objects is recorded on the workflow result and written to the audit trail, so surviving ciphertext becomes someone's follow-up. Since a run can halt for operator attention, this page describes the sequence and puts no completion time on it.

One residue is worth knowing about. Dropping the database does not reach into backups already taken. Your tenant's rows persist in the encrypted backup set until the retention jobs age them out, which Availability, Backups and Disaster Recovery describes: copies in the primary store age out on their dump ladder, and the off-provider mirror is pruned on a schedule of its own, roughly ninety days at the outside. That schedule is the answer we give, not an opening position. Backup copies are not edited to remove individual records, because rewriting a dump destroys the property that makes it a backup, and the copies held in the off-provider mirror sit under a lock that refuses deletion to every credential the running platform holds, for twenty-five days on mirrored database dumps and fifty-five days on mirrored write-ahead-log archives. Lifting that lock would dismantle a control that exists to survive ransomware, so we do not lift it for an erasure request, and while it holds we could not delete those copies early even if we wanted to. What happens instead: send the request to [email protected], we erase from the live systems when we action it, and the backup copies age out on the schedules above. The bound to hold us to is the roughly ninety days those schedules give, with mirrored write-ahead-log copies gone at sixty.

Verify it yourself

The export path is in the product. Open Settings → Account → Data Export and trigger one. The download control resolves to a Parascope API route, which you can confirm in your browser's network panel; there is no object-storage URL to inspect, because none is issued.
The audit-log window is observable. Open Settings → Audit Log and filter to a date range beyond 90 days. The absence of older events is the retention sweep. Export CSV takes a copy before the window closes; it exports the last 31 days unless you set a date filter, says which window it exported, and refuses a range wider than 31 days rather than quietly returning a shorter file. The endpoint behind it is rate limited separately from the rest of the API.
Archived-CI retention is yours to set. Settings → Lifecycle shows the current threshold, and Dry Run reports what a removal would delete without deleting it.
Change history depth is visible per CI. Open any configuration item's history tab, or query /api/v1/changes with a date range, and read how far back the record goes. Change History covers the query surface.
Platform availability and incident history are on the status page at parascope.instatus.com, hosted independently of the platform it reports on.
The DPA, an erasure request, or a residency question goes to [email protected]. Data-handling controls with their own verify pointers are listed in the control matrix.

Data Handling and Retention