Security

1. Our approach

Studio OS is built around isolated company workspaces, controlled AI actions and an auditable record of important workflows. We use a risk-based security program and are building our control baseline with ISO/IEC 27001 and secure-development practices as references.

Studio OS is not currently ISO certified and does not have a SOC 2 report. We say “designed with” or “aligned to selected practices” only where that is precise.

2. Architecture and tenant separation

Public HTTPS traffic terminates at a reverse proxy. Application backends and data services are not published directly to the internet.

Each tenant has a separate application backend configuration, database, restricted database login, secrets, authentication configuration and logical cache/queue scope. Core infrastructure is shared; tenant separation is not represented as a separate VM per customer.

3. Identity and access

Business APIs require authentication and administrative operations require elevated application access. Production configuration rejects known unsafe settings such as weak signing secrets and permissive production origins and hosts. Login throttling is applied.

An account can be restricted to Google or Microsoft sign-in, which closes password login and password reset for it. That is what makes multi-factor authentication enforced rather than merely available: the second factor cannot be bypassed with a password. It is enabled on administrator accounts.

Periodic access review and finer business authorization are tracked as active improvement work and should not yet be assumed for every system or role.

4. Data protection

Public traffic uses TLS. Tenant secrets are kept outside source control in restricted server-side files.

Access credentials for a connected mailbox, calendar and file store are encrypted in the database under a separate key held outside it. A copy of the database alone does not open them.

Backups are taken off-site once a day and encrypted to a public key before they leave the server, so the server cannot read its own backups. Restoring is a documented procedure that is tested on a schedule; the date of the most recent verified restore is available on request.

Exact encryption-at-rest coverage and measured recovery time and point objectives (RTO/RPO) are being validated, and will only be stated as commitments after testing.

5. AI action controls

Studio OS separates specialised agents and exposes typed tools. Consequential actions are designed to be proposed for human approval, or performed only within deliberately configured maturity guardrails.

Actions, approvals and outcomes can be associated with the workflow that caused them. Human review remains necessary for important decisions and communications.

6. Development and operations

Production releases use automated application tests and configuration validation, versioned static releases and rollback mechanisms.

We are adding recurring dependency, secret, source and container scanning, formal release review evidence, monitoring and independent security testing as the service grows.

7. Incidents and vulnerability reporting

We maintain incident-response, privacy-breach and recovery procedures. Monitored vulnerability reporting details and tested customer-notification targets are being finalised.

To report a vulnerability or a security incident, contact security@hiiustudio.ee. Please do not include secrets or unnecessary personal or customer data in an initial report.

8. Assurance and documents

Customers may request our current DPA, subprocessor information, data-handling summary and reasonable security questionnaire responses.

Answers are scoped to the configured service and dated; unknown or planned controls are identified rather than inferred.