Data Deletion Policy

1. Overview

At Miigwech AI Solutions, we respect your right to control your personal information. The miigCloud platform is designed for sovereign deployment on your infrastructure, giving you complete control over your data. Here's how you can manage or delete your data:

miigCloud is designed for sovereign, customer‑controlled deployment. In most cases, you (the customer) operate the infrastructure and directly control data stored in miigCloud components (e.g., object storage, databases, logs).

This policy explains:

• What data miigCloud typically stores
• Where deletion and retention are controlled by you vs Miigwech
• Recommended patterns for secure deletion and retention

2. Data Categories in miigCloud Line

In a standard deployment, miigCloud may handle:

• Identity and access data - User accounts, roles, password hashes, tokens, API keys.
• Application data - Objects in S3‑compatible storage (e.g., Garage), database records, files managed by your workloads.
• Operational logs - HTTP/audit logs for admin UI and APIs, system events.
• Ephemeral data - Cache, temporary files, and transient request data.

Exact data categories depend on how you configure and use your instance.

3. Who Controls Deletion

Because miigCloud is deployed on your infrastructure:

• You control storage systems (disks, Garage/S3, PostgreSQL, backups, snapshots).
• You control when data is deleted, anonymized, or retained under your own policies.
• Miigwech does not reach into your environment to delete or retain customer data unless explicitly agreed in a managed‑service contract.

If Miigwech also operates a hosted miigCloud instance on your behalf, that hosted environment will have a separate, written data retention/deletion schedule as part of your service agreement.

4. Deletion Mechanisms (Typical Patterns)

4.1 User Accounts and Access

Administrators can disable or remove accounts using the miigCloud admin interface or API. Typical effects:

• Disable user – prevents login; account and historical logs remain.
• Delete user (where implemented) – removes the user record; logs may keep a non‑identifying reference (e.g., numeric ID) for integrity.

Because RBAC and audit trails are core to sovereignty, we recommend:

• Deactivate users for most HR/lifecycle events.
• Use anonymization or log rotation (see 4.3) if you need to remove identifying info from historical logs.

4.2 Application Data (Buckets, DB records, files)

Deletion of application data (buckets, objects, database rows) is fully under your control:

• Use your S3/Garage tooling, database tools, or application logic to delete data.
• miigCloud does not silently mirror or back up your data to Miigwech‑controlled infrastructure.

If you implement CLI tools (e.g., sovereign-cloud user delete, bucket delete) those are part of your operational playbook, not hardwired guarantees from Miigwech. Document them in your internal runbooks rather than in a public policy unless they are stable, supported commands.

4.3 Audit Logs and System Logs

By default, miigCloud can record audit logs (e.g., timestamp, method, path, status, remote IP, user/id) for security and compliance.

Recommended pattern:

• Short‑term detailed logs (e.g., 30–90 days) for investigations.
• Optional longer‑term, reduced logs (e.g., summarized or anonymized) if you need historical metrics without personal identifiers.

Implement log rotation and deletion via:

• PostgreSQL retention jobs (e.g., scheduled DELETE FROM audit_logs WHERE timestamp < ...)
• Filesystem rotation for any text logs (e.g., logrotate).

miigCloud itself does not force a retention schedule; you define this based on your legal and policy obligations.

5. Ephemeral and "Burn‑After‑Read" Features

If you enable components like miigFlashPaper (burn‑after‑read / TTL notes):

• Notes are stored in memory or short‑lived storage by design.
• Burn‑after‑read notes are deleted as soon as they are successfully viewed once.
• TTL notes are deleted automatically after their configured lifetime expires.

These behaviors are part of the miigCloud application logic and are intended to minimize persistence of sensitive message content.

6. Backups, Snapshots, and Emergency Deletion

Because miigCloud runs inside your environment:

• Backups and snapshots (e.g., database dumps, volume snapshots, tape/remote backups) are created, stored, and deleted according to your own policies.
• If you restore from an older backup, previously deleted data may reappear until it is deleted again.

For emergency deletion (e.g., key compromise, incident response), your administrators can:

• Revoke credentials and tokens
• Delete specific datasets (buckets/DBs)
• Purge or rotate logs
• Destroy or overwrite storage volumes

Miigwech can provide guidance or scripts as part of support, but the actual deletion is performed by your team (unless you have a managed‑service contract that states otherwise).

7. Irreversibility and Recovery

miigCloud is intentionally designed so that:

• Miigwech does not maintain "shadow copies" of your data outside of your control.
• If your team deletes data from your environment (and from any backups/snapshots you control), Miigwech cannot restore it for you.

You are responsible for implementing and testing a backup and recovery strategy consistent with your own retention obligations and risk tolerance.

8. Alignment with Sovereignty and Privacy Frameworks

This approach to data retention and deletion is intended to support:

• OCAP® principles (Ownership, Control, Access, Possession) for First Nations data governance
• PIPEDA and applicable Canadian privacy laws regarding limiting collection, retention, and use
• Data sovereignty expectations where communities and public bodies require that data remain in their legal and physical control
• The spirit of "right to erasure" under GDPR‑like frameworks, to the extent you implement deletion/anonymization workflows in your environment

9. How to Exercise Deletion or Retention Choices

Because miigCloud is deployed in your environment:

• End‑users should send access/erasure requests to your organization, not to Miigwech.
• Your administrators can then:
  • Disable/delete accounts in miigCloud
  • Delete or anonymize records in underlying databases and storage
  • Apply log retention/deletion policies per your governance framework

If you operate a Miigwech‑hosted instance, details of how we execute deletion on your behalf (and timelines) will be documented in your service agreement and/or Data Processing Addendum.