Tenant Setup

Tenant setup covers the decisions made at onboarding that shape every other configuration choice. These settings rarely change after launch, but they're worth thinking through carefully.

Organization profile

Name and display name. The legal entity name and the display name used in the dashboard. The display name can be updated later; the legal entity name should be set correctly at onboarding because it anchors signatures, evidence exports, and any formal documents the platform produces.

Primary administrator contact. The human contact responsible for tenant ownership. This is a role distinct from the identity provider account — it determines who Lattix engages for material operational decisions.

Time zone. The tenant's primary time zone for dashboard displays. Ledger records are always stored in UTC; the tenant time zone affects only presentation.

Subdomain

The tenant is accessed at a subdomain of lattix.io — for example, your-org.lattix.io. The subdomain is chosen at onboarding from a reserved pool. It is visible in every URL an end user interacts with and in invite links sent to external parties.

Choose a subdomain that is:

• Unambiguous — it will be how counterparties recognize your Lattix presence in URLs and emails.
• Durable — changing it later involves reissuing every outstanding Passport link and Data Room invite.

Custom domains (e.g., secure.your-org.com) are supported and can be configured after onboarding through your account team.

Administrative roles

Administrative roles are synchronized from the identity provider through attribute mapping (see Identity). The platform recognizes:

• Tenant owner — full administrative authority, including identity provider settings and billing. One or two owners is typical.
• Security administrator — policies, key management, tag schema, audit.
• Data steward — tag schema and classification oversight.
• Member — consumes Passport and Data Rooms; no administrative scope.
• Read-only — audit and review, no mutations.

Role assignments are made by mapping identity provider groups to these roles. See Identity for the mechanics.

Baseline retention

The retention baseline sets the minimum retention period for ledger events and policy versions tenant-wide. Individual policies and classifications can increase this baseline (for example, a classification bound to a regulated dataset might require a longer retention than the baseline), but cannot decrease it.

The baseline depends on your regulatory environment:

• Unregulated commercial workloads: commonly 2–3 years.
• HIPAA-covered data: 6 years is a typical floor.
• Defense-industrial CMMC data: 3–6 years depending on scope.
• Financial services: often 7 years.
• Long-term historical archives: indefinite is supported.

Changing the baseline after onboarding is possible but must be made with an understanding of how retention interacts with existing ledger entries. Reducing retention may require specific regulatory approval in some jurisdictions.

Regional and residency considerations

For tenants with data sovereignty requirements, the configured key management backend and the mesh-node deployment regions together determine where key material and plaintext ever exist. Discuss specific residency requirements with your account team at onboarding — the platform supports region-scoped KAS deployments and can be configured so that no key material leaves a specified jurisdiction.

Residency configuration is part of onboarding because it affects where backend resources are provisioned; it is not typically changeable after launch without a migration.

What to revisit periodically

Even though tenant setup is mostly stable, review it annually:

• Role mappings — are the identity provider groups mapped to administrative roles still accurate?
• Retention baseline — has a new regulation applied?
• Primary administrator contact — is the named person still in the role?
• Residency configuration — any new jurisdictional requirements?

An annual review avoids surprises during incident response or compliance audits.