Export your data and close your organisation

You can export your organisation’s data at any time. When you close an organisation, or its subscription ends, its data is deleted within 30 days, except where a legal hold you have placed is still active.

This page covers:

• Exporting everything an organisation holds
• Exporting or deleting one person’s data, for access and erasure requests
• Closing an organisation, what happens during the 30 days, and how deletion works

Export an organisation

Only the organisation’s owner can export it.

Open organisation settings

Go to Settings → Organisation. The Your data section is on the Details tab.

Start the export

Select Export all data. The export runs in the background; its progress is shown in the list below the button.

Download the archive

When the export is ready, select Download. The archive is available for 7 days, then it is removed.

What the archive contains

The download is a .tar.gz archive of JSON Lines files:

Path	Contents
clickhouse/<database>/<table>.ndjson	Every Shield360 table in every ClickHouse database of every project and environment: traces, logs, metrics, collector data, guard events, spend, directory data and so on
postgres/<set>.ndjson	The organisation, projects, environments, members, roles, invitations, database configurations, collector and ingest policies, install keys and devices, API keys, connectors, subscriptions, agent access, the audit log and legal holds
manifest.json	What was exported, row counts, anything skipped and why, and which columns were left out

Secrets are never exported. Vault secret values, passwords, API keys, collector and agent tokens, provider credentials, private keys and password hashes are left out; their names, prefixes and metadata are included, and records say whether a secret is stored (hasStoredSecret, hasCredentials). The manifest lists every column that was excluded.

If a ClickHouse database is shared with another organisation, only rows that carry your organisation’s database configurations are exported, and tables without that column are skipped and listed in the manifest.

Requesting an export and every download are recorded in the organisation’s audit log (Govern → Records → Audit log).

Export or delete one person’s data

To answer an access or erasure request from one of your own people, open their page: Discover → AI usage → People → the person. The This person’s data section offers:

• Export their data: a .tar.gz of every record about the person across all of the organisation’s databases, downloadable for 7 days.
• Delete their data: removes the same records. Type the person’s name to confirm.

You need the Change what is collected permission (collector.policy) for both.

Records are found by the person’s user name as the collector reports it, and by any email or UPN your directory connector links to that user name. Shield360 searches the collector tables (usage, output sessions, application and site activity, browsing, network observations, machine states, heartbeats, guard events), coding-agent and SDK traces and logs, AI code provenance and rework, vendor spend and seats, AI account readings (exported as masked identifiers; deleted on erasure), and directory records. Each table is either searched or documented as holding no data about a person; a table Shield360 does not recognise is reported rather than silently skipped.

Caution

Deletion cannot be undone. If a legal hold names the person, deletion is refused until the hold is released.

Every erasure is recorded in the audit log with who erased whom and how many rows were removed from each table. The audit log entries themselves are kept: they describe the administrator’s actions.

Collectors keep reporting new activity from the person’s machine. To stop that, revoke the machine as described in Fleet. Directory records reappear on the next directory sync while the person is still in your identity provider.

Close an organisation

Only the owner can close an organisation.

Export first

Download an export if you want a copy. You can still export while the organisation is closing.

Close it

In Settings → Organisation, select Close organisation and type the organisation’s name to confirm.

In Shield360 Cloud, an organisation is also closed automatically when its subscription ends: when it is cancelled outright, or when a cancellation scheduled for the end of the paid period takes effect. Starting a new subscription before the deletion date reopens it.

During the 30 days

• The organisation is read-only: collectors and API keys stop sending data, and settings cannot be changed.
• Members can still read everything, and the owner can still export it.
• Legal holds can still be released.
• The owner can cancel the closure from the banner in Settings → Organisation, and the organisation becomes active again.

Deletion

A job runs every day and deletes every organisation whose deletion date has passed:

1. Legal holds are checked first. If any legal hold in the organisation is active, nothing is deleted. The reason is shown to the owner in organisation settings and recorded in the audit log, and the next run checks again. Deletion goes ahead once every hold is released.
2. ClickHouse data is deleted. A tenant database Shield360 created for one of your projects is dropped. A database that only your organisation uses, but that Shield360 did not create, has its Shield360 tables emptied. A database another organisation also uses is never dropped or emptied: only rows that belong to your organisation’s configurations are deleted.
3. Records are deleted. Projects, members, roles, configurations, keys, policies, export archives and the audit log are deleted. Accounts of people who belonged to no other organisation are deleted. Released legal holds cannot be deleted, so the people they named are removed from them.
4. A tombstone is kept as evidence: the organisation’s id, when it was closed and deleted, and counts of what was removed. It holds no names or content.

The job is safe to re-run. If anything fails part way, nothing in PostgreSQL is touched, and the next run finishes the work.

Self-hosted deployments

Closing works the same way. The owner can also choose delete the data now when closing; a legal hold still stops it. The organisation’s own ClickHouse database is emptied rather than dropped, because Shield360 did not create it.

Export archives are kept on local disk by default, in EXPORT_STORAGE_DIR (default ./data/exports in the application directory). Set EXPORT_STORAGE=s3 to keep them in an S3 bucket instead.

Archives are encrypted at rest either way:

• Local disk. Each archive is encrypted with AES-256-GCM as it is written, in 64 KiB chunks that are each authenticated, and decrypted as it is downloaded. The key is derived for each archive from EXPORT_ENCRYPTION_KEY. If that is unset, Shield360 uses the secret it encrypts vault values with (SHIELD360_VAULT_ENCRYPTION_KEY, then NEXTAUTH_SECRET). If you change the secret, archives that are already built can’t be read. They expire within seven days anyway.
• S3. Every object is written with server-side encryption: SSE-S3 by default, or SSE-KMS when EXPORT_S3_KMS_KEY_ID is set. The archive itself is not encrypted again, because the browser downloads it straight from S3.

Caution

With more than one Shield360 web replica, use S3 storage, or make EXPORT_STORAGE_DIR a volume that every replica mounts. Otherwise a download can reach a replica that does not have the archive.

With S3 storage:

• Each archive is streamed to the bucket as a multipart upload while it is built. Neither memory nor disk holds the whole archive.
• A download still goes through Shield360, which checks who is asking and records the download in the audit log. Shield360 then redirects the browser to a link that is valid for five minutes.
• Archives are deleted when they expire. Add a bucket lifecycle rule that expires objects after 8 days as a backstop.
• Credentials come from the AWS SDK’s default chain, for example an IAM role for the pod’s service account on EKS. Grant s3:PutObject, s3:GetObject, s3:DeleteObject and s3:AbortMultipartUpload on the prefix, and s3:ListBucket on the bucket.

Variable	Default	Purpose
EXPORT_STORAGE	local	Where finished archives are kept: local or s3
EXPORT_STORAGE_DIR	./data/exports	Local archives, and scratch space while any export is built
EXPORT_S3_BUCKET	none	The bucket, when EXPORT_STORAGE=s3
EXPORT_S3_PREFIX	none	A folder inside the bucket, for example exports/
EXPORT_S3_REGION	AWS_REGION	The bucket’s region
EXPORT_S3_KMS_KEY_ID	none	A KMS key for SSE-KMS; SSE-S3 is used otherwise
EXPORT_ENCRYPTION_KEY	the vault secret	The secret that local archive keys are derived from
EXPORT_MAX_BYTES	53687091200 (50 GB)	Largest export Shield360 will write; larger exports fail with a message
DATA_EXPORT_SCHEDULE	*/5 * * * *	How often queued exports are built and expired ones removed
ORGANISATION_DELETION_SCHEDULE	41 3 * * *	When the daily deletion job runs (UTC)
BASE316_WEBHOOK_SECRET	none	Cloud only: the signing secret for Base316 subscription events

---

Organisation overview

How organisations, projects and database configurations fit together

Configuration

Every environment variable Shield360 reads