Data encryption policy

1. Purpose

This policy describes the intended encryption and data protection principles for SCIENTYCA public website, checkout, tenant systems, file storage, backups, AI credit ledgers, and administrative tools.

2. Data in transit

All production traffic must use HTTPS with modern TLS. Administrative interfaces, Stripe webhooks, API calls, tenant access, and file transfers must reject insecure transport. HSTS should be enabled after production domain validation.

3. Data at rest

Production databases, object storage, backups, logs containing personal data, and tenant files should be encrypted at rest using managed encryption or equivalent server-side encryption. Secrets, API keys, Stripe keys, database credentials, and webhook secrets must never be stored in public code repositories.

4. Passwords and authentication

Passwords must be hashed with a modern adaptive password hashing algorithm. Multi-factor authentication should be available for superadmin and high-privilege tenant users. Session cookies must be secure, HTTP-only, same-site aware, and rotated after privilege changes.

5. Tenant separation

Tenant data must be separated by database, schema, tenant ID, or equivalent access control boundary. Superadmin access must be audited. Tenant provisioning, suspension, exports, and deletion should create immutable audit entries.

6. Backups

Backups must be encrypted, access-controlled, and tested for restoration. Backup retention should follow the service agreement and legal obligations. Deleting a tenant must include a documented backup expiration path.

7. AI and third-party processing

Only the data required for the selected LabRat operation should be sent to AI services. AI requests should be logged for security, billing, and credit accounting without storing more customer content than necessary.

8. Payment data

Card data should be handled by Stripe Checkout or another certified payment provider. SCIENTYCA should store Stripe customer, session, payment, subscription, and invoice identifiers, not raw card numbers.

9. Monitoring and incident handling

Security-relevant events should be logged, including login attempts, failed payments, superadmin actions, tenant changes, API errors, webhook failures, and suspicious form submissions. Incidents must be triaged, contained, documented, and communicated according to applicable law.

10. Review

This policy should be reviewed whenever hosting, payment, AI provider, tenant architecture, or superadmin permissions materially change.