Skip to main content
Users should understand what information Orbit receives, why it is processed, where it is stored, and what controls they have. The exact commitments must match the system’s actual technical and contractual behavior.

​
14.1 Data minimization

Collect only what is needed to provide, secure, and improve the service under the stated policy. Optional analytics should be distinguished from essential operational records. Avoid retaining full content in diagnostic logs when metadata is sufficient.

​
14.2 Purpose limitation

Data supplied for one purpose should not silently become available for unrelated purposes. If data may be used for model improvement, that use must be described clearly and handled according to the applicable settings, contracts, and law.

​
14.3 Retention and deletion

Each data category should have a retention period or a clearly stated retention rule. Deletion workflows should cover primary storage and relevant derived copies, subject to legitimate legal, security, and backup constraints. The company should not promise instant deletion from every backup unless the architecture can deliver it.

​
14.4 Access control

Internal access to customer data should be limited by role and operational need. Privileged access should be logged and periodically reviewed. Support staff should not be given broad access merely because it is convenient.

​
14.5 Data residency and compliance

Claims about geographic storage, regulatory compliance, certifications, or enterprise controls should be made only when verified for the relevant service and configuration. A privacy policy is not itself proof of compliance.

​
14.6 User trust

Clear privacy documentation, accurate settings, and reliable deletion processes are more valuable than vague claims that a product is “fully private.” Trust should come from understandable commitments and evidence that the system follows them.