Lorla - Security Policy

This Policy describes the security design of Lorla as built; it is not a warranty.

Effective date: 29 June 2026 Last updated: 29 June 2026

1. Overview

Lorla is a mobile time-capture app for attorneys, operated by GrowthX Group LLC dba Cyberaktive (a Wyoming limited liability company). It connects to Clio Manage (API v4, per-user OAuth, CA region) and is built offline-first. Because attorneys handle privileged, confidential client data, Lorla applies data minimization, on-device encryption of the most sensitive fields, encryption in transit, and prompt deletion. Lorla is distributed globally; how we handle the rights and cross-border transfers of users in the EU/EEA, UK, Canada, and Australia is described in the Privacy Policy. Security contact: security@cyberaktive.com.

2. Authentication and authorization

• Per-user OAuth. Lorla connects to Clio through Clio's OAuth flow on a per-user basis in Clio's CA hosting region. Each attorney authorizes access to their own Clio account.
• Least privilege. Lorla requests only the Clio access it needs: reading your matters, writing time entries back to Clio, reading your basic Clio account identity, and managing the webhooks that keep your matter list in sync (Matters read; Activities read/write; Users read; Webhooks read/write). It does not request broad or global Clio scopes.
• Token storage. On the device, Clio OAuth access and refresh tokens are stored in the operating system's secure credential store (expo-secure-store), never in the App's on-device database and never in plaintext app storage. On the backend, tokens are stored encrypted in Supabase Vault (pgsodium authenticated encryption), never as plaintext columns.
• Token lifecycle. The access token is rotated on each successful Clio OAuth refresh. The refresh token is non-rotating by Clio's design (Clio does not return a new refresh token on refresh), so the same refresh token persists until you de-authorize Lorla, at which point it is deleted.

3. Data at rest

• On-device database. Operational data is stored on-device in WatermelonDB. Five fields that can contain privileged client or narrative content are encrypted at rest with field-level AES-256-GCM via a custom encrypted-field decorator: matter description, client name, queued billing note, match-reason explanation, and active-timer note draft.
• Encryption key. A 256-bit symmetric key is generated on the device at first run, stored exclusively in the device secure store (expo-secure-store), and never transmitted off the device or to the Lorla backend.
• Plaintext fields. Non-privileged operational fields (Clio numeric identifiers, status enums, timestamps, durations, flags, and opaque internal keys) are stored unencrypted because they contain no client-identifying narrative.
• Backend storage. The Lorla backend runs on Railway (US West, California) with a Postgres database holding the server-side sync queue and related records. This data is encrypted at rest at the storage/infrastructure level by Railway's underlying cloud provider (Google Cloud Platform), which encrypts customer data at rest by default; Railway does not separately encrypt individual volumes at the software level. Clio OAuth tokens are additionally encrypted at the application layer in Supabase Vault (pgsodium authenticated encryption). A queued entry's billing note is held only until the entry is successfully written to Clio, then cleared from the backend record.
• AI-narrative relay (not active at launch). The optional AI billing-narrative feature is off at launch (see Section 6). If and when that feature is enabled under a signed business-associate agreement, any AI-generated narrative would be relayed only - passed through to your device and not persisted server-side. This relay behavior applies solely to that feature when enabled; at launch no narrative content is generated, relayed, or stored.

4. Data in transit

All traffic between the App and both the Clio API and the Lorla backend is encrypted using TLS 1.2 or higher. Certificate pinning is not currently implemented.

5. Data retention and deletion

• Matter cache TTL. Cached Clio matter data is automatically evicted after a 30-day time-to-live.
• Queue retention. Queued time entries are retained only until they are successfully synced to Clio or discarded by the user.
• Wipe on sign-out. The on-device store is wiped on explicit sign-out (and on first launch of the encrypted build).
• De-authorization deletion. When an attorney revokes Lorla's authorization in Clio, Lorla deletes the corresponding Clio data: the on-device matter cache and time-entry queue are wiped and the matching backend records are deleted.

6. AI / voice features and BAA gating

Lorla's optional voice-transcription and AI-narrative features rely on third-party processors (Deepgram for transcription, Anthropic Claude for narrative drafting). These features are disabled at initial launch and are gated behind signed business-associate agreements with each provider. Until those agreements are in place and the features are explicitly enabled, no audio is sent to Deepgram and no content is sent to Anthropic. When enabled, the providers, capacities, and processing regions will be disclosed in the Privacy Policy before activation.

7. Infrastructure and sub-processors

We maintain an internal register of all third-party providers, their capacity, and the regions where data is processed: Railway in US West (California, United States); Supabase as the application-layer encrypted store for Clio OAuth tokens (Supabase Vault / pgsodium) supporting the backend; Deepgram and Anthropic in the United States (both off at launch, confirmed before activation).

Sub-processor security. We use established providers that maintain their own security and compliance programs (Railway publishes its compliance posture at trust.railway.com; Supabase, Deepgram, and Anthropic publish equivalent security documentation). We limit the data each provider receives to what its role requires, do not add a sub-processor without recording it in this register, and before enabling the BAA-gated AI/voice providers we will have a signed business-associate agreement and a confirmed processing region in place. Where users in the EU/EEA, UK, Canada, or Australia are affected, transfers to these US-based providers rely on the safeguards described in the Privacy Policy ("Where your data is processed" and "Your rights by region").

8. Access controls and operational security

• Secret management. Backend credentials and the Clio OAuth client secret are stored as managed environment variables in Railway (encrypted at rest by the platform), never committed to source control. Clio OAuth user tokens are stored encrypted in Supabase Vault (pgsodium), separate from application config.
• Production access. Production infrastructure (Railway, Supabase) is accessible only to the company principal; there is no contractor or third-party production access. Access is protected by the providers' account authentication with multi-factor authentication (MFA) enabled.
• Logging. Application logs capture operational metadata and HTTP status codes only; privileged client content (billing notes, matter narratives) is excluded from logs by design - the stored backend error template records status codes, never client content.
• Backups. Database backups are provider-managed by Supabase and Railway, encrypted at rest; retention follows the provider's managed-backup cycle.
• Least privilege. Internal access follows least-privilege; only the principal holds production credentials.

9. Rate limiting and abuse protection

Lorla honors Clio's API rate limits using a header-driven throttle: the sync engine reads Clio's rate-limit and Retry-After response headers and backs off accordingly, so flushing the offline queue after reconnection does not burst past Clio's per-token limit.

10. Incident response and breach notification

If we become aware of a security incident affecting personal data we hold, we will investigate promptly, take steps to contain and remediate it, and notify affected users and any required authorities in line with applicable law. Where the law of a user's jurisdiction imposes a specific breach-notification standard, we will follow it - for example, notification to the relevant supervisory authority without undue delay and, where feasible, within 72 hours under the EU/UK GDPR, and notification of affected individuals and the regulator where a breach poses a real risk of significant harm (Canada PIPEDA) or is an "eligible data breach" likely to result in serious harm (the Australian Notifiable Data Breaches scheme). Because the encryption key for the five sensitive on-device fields never leaves the device, those fields are not readable from any backend or backup compromise; our incident response is scoped accordingly. Our security contact for incident reports is security@cyberaktive.com.

11. Vulnerability reporting

We welcome responsible disclosure of security issues. Report suspected vulnerabilities to security@cyberaktive.com and we will acknowledge receipt within 72 hours and investigate promptly. We do not currently operate a formal bug-bounty program.

12. Changes

We may update this Policy as the product evolves (for example, when voice/AI features are enabled). The "Last updated" date will change accordingly.

13. Contact

Security questions: Liam Barnes, GrowthX Group LLC dba Cyberaktive, liam@cyberaktive.com.