Technical and Organisational Measures

1. Organisation and access

• Production and Customer Data access is limited to necessary persons and purposes on a need-to-know basis; authorised persons are bound to confidentiality.
• Physical access to data centres and hardware is controlled under the security measures of the infrastructure and data-centre providers.
• Customers administer their users, roles and teams. Administrative actions are authorised server-side.
• Passwords use a current one-way hash; email verification, session rotation, CSRF protection and rate limits protect account and public endpoints.
• Credentials, API keys and production secrets are kept outside source code in protected environment variables.

2. Tenant separation and confidentiality

• Application access is centrally restricted to the authenticated tenant and additionally enforced through PostgreSQL Row-Level Security.
• Private attachments are not publicly served; retrieval requires authorisation or a high-entropy limited status link and is rate-limited.
• Webhooks and API access use revocable secrets or tokens; stored API tokens are hashed.

3. Transmission and storage

• HTTPS/TLS protects web traffic and encrypted connections are used to supported infrastructure and email services.
• Attachments, exports and backup artefacts use private object storage; encryption at rest follows Laravel Cloud and its infrastructure providers’ security measures.
• Sensitive state snapshots and credentials that must be stored by the application are encrypted or hashed at application level.

4. Availability and recovery

• Managed database backups and a separate procedure for backing up referenced attachments support recovery after technical or physical incidents. The restore procedure for the database and referenced attachments is tested in isolation and documented.
• Asynchronous processing with retryable jobs, failure states and operational checks reduces data loss during temporary failures.
• Production state and key background processes are monitored; maintenance and security updates are applied based on risk.

5. Integrity, deletion and incidents

• Inputs, upload types and sizes are validated; signed URLs, tenant checks and transactions protect against unauthorised or inconsistent processing.
• Security-relevant events and errors are logged where necessary. Logs and Customer Data are kept separate from public content.
• Writes are tenant-specific and material ticket, billing and deletion operations are transactional. Retention periods, the read-only transition, controlled deletion and automatic removal of deletion exports form the deletion concept.
• Changes are automatically tested and reviewed before release. Dependencies are regularly checked for security updates.
• Incidents are contained, investigated and documented, and affected Customers are notified without undue delay using available information.

6. Review

Measures are regularly reviewed and adjusted where necessary, taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing, and the likelihood and severity of risks. Changes must not materially reduce the agreed protection level.