Data Retention Policy

1. Customer-controlled retention

Retention is customer-controlled per tenant. Each workspace's retention settings declare the customer's retention policy for its operational records, audit events and export artifacts; no automated purge currently enforces those declared values (see below). The exception is attachment file content, which has an enforced, customer-adjustable retention policy (see section 2). OgmaQ does not impose its own shorter retention on customer workspace content.

2. Automated deletion of attachment files; no other automated purge

Attachment file content is subject to an enforced workspace retention policy: by default, an attachment's file content is permanently deleted 30 days after its record enters the archive (reaches a terminal status). Each customer workspace can adjust the number of days or turn this deletion off entirely. Only the file content is deleted — the attachment's metadata (name, provenance, classification) and the record's audit trail are retained, and each deletion is itself recorded in the audit trail. A deletion that has been carried out cannot be reversed. Provider-side backup copies are subject to the hosting provider's retention and are outside this policy's control; no certified-destruction claim is made.

No other automated purge currently runs. Deletion of other workspace content is a reviewed, manual administrative workflow: a deletion request is checked against the tenant's settings and any open obligations before any removal is carried out. Separately, a signed-in user can delete their own account in-app: the sign-in identity is removed immediately and the user profile is minimised (see Account lifecycle below), and each self-service deletion is recorded in the tenant's privacy request queue. Where audit traceability requires it, deletion may currently be effected as anonymisation — personal fields are minimised while the record identifier is retained (see Account lifecycle below).

If prohibited or sensitive data (for example patient data or special-category personal data, which are restricted by default — see the Acceptable Use Policy) is discovered in workspace records, its removal or anonymisation is handled as a reviewed action with the customer as controller. It is not automatically purged, and audit traceability obligations are considered before any change.

3. Account lifecycle

When a user leaves an organisation, their account is deactivated and may then be anonymised; a user may also delete their own account in-app, which removes the sign-in identity immediately and minimises the profile — the display name is replaced with a neutral label, the email address is cleared, and a durable neutral reference is retained for traceability. Historical audit-support records are preserved for record integrity — the trail of who did what remains intact even after the person's account is anonymised. Name text captured inside historical workspace records at the time of an action is not retroactively rewritten by anonymisation.

4. Tenant offboarding

When a customer leaves the service, the standard path is export first, then reviewed deletion of the tenant's data. Where a legal hold or similar obligation applies, the affected records are retained until the hold is lifted.

5. Retention schedule (structured placeholders)

The table below structures the categories a final retention schedule will cover. Where a period is not yet defined, it is deliberately left as a placeholder rather than an invented number.

6. Contact

Retention questions and deletion requests: the in-app privacy request workflow or privacy@ogmaq.com (general contact: hello@ogmaq.com). These role-based aliases route to the OgmaQ team; hello@ogmaq.com is the general contact if you are unsure which to use.