Worklenz is built to help teams manage projects, collaborate with clients, and keep work moving with confidence. We apply practical security controls to help protect the platform and the information entrusted to us.
This page provides an overview of Worklenz security practices. For details about the handling of personal information, please read our Privacy Policy. Use of Worklenz is also governed by our Terms of Use.
Security controls
Worklenz uses defence in depth: several complementary safeguards across transport, authentication, authorisation, application behaviour, deployment, and recovery. No single control is sufficient on its own, so these layers are designed to work together.
Secure communication
Worklenz supports HTTPS/TLS to protect data in transit between users and the platform. Production deployments use security headers including Content Security Policy, HTTP Strict Transport Security, clickjacking protection, MIME-type protection, referrer policy, and permissions policy headers.
Application protection
Worklenz applies multiple safeguards to help reduce common web-application risks:
- CSRF protection for state-changing main-application requests.
- Request validation and input sanitisation.
- Protection against parameter pollution.
- Rate limiting for selected API and sensitive endpoints.
- Detection and blocking of suspicious SQL-injection patterns.
Identity and access
Access to Worklenz is protected through authenticated user accounts. Passwords are hashed before storage, and access to organisations, projects, and client-facing areas is controlled according to membership and permissions.
The Worklenz client portal uses a separate authentication flow from the main application’s session-based authentication.
Workspace administrators should grant the minimum access needed for each person, review access periodically, and remove access promptly when a person’s responsibilities change.
Authorisation boundaries
Worklenz separates access across organisations and projects. Application requests are evaluated in the context of the authenticated user and the relevant workspace or project membership. Client-facing access is isolated from the main application and uses its own authentication mechanism.
These boundaries help teams share the right information with the right people while maintaining control over internal project data.
Data protection
Worklenz processes customer data to provide and operate the service, as described in our Privacy Policy and Terms of Use.
Where supported, sensitive integration tokens are encrypted before storage. Before enabling a third-party integration, customers should review the permissions granted and the third party’s applicable terms and privacy practices.
Data ownership
Customers retain ownership of the content they submit to Worklenz. This may include project information, task content, files, comments, time entries, and other information created or uploaded through the platform. Worklenz uses this content to provide and operate the service as described in the Terms of Use.
Retention and deletion
Worklenz retains personal information only for as long as necessary for the purposes described in the Privacy Policy or to meet applicable legal obligations. When information is no longer required, it is deleted, destroyed, or anonymised as appropriate.
For account deletion, use the process described in our Privacy Policy.
Third-party services
Some Worklenz features may connect to third-party services. Enabling an integration can allow data to be exchanged with that provider. The collection, processing, and storage of data by a third party is governed by that provider’s own terms and privacy practices.
Customers should connect only the services they need and regularly review connected integrations and their permissions.
Deployment and backups
Worklenz is open source and can be self-hosted. Organisations that self-host Worklenz control their deployment environment, including infrastructure, networking, access controls, monitoring, backups, and recovery procedures.
Worklenz Cloud production services run in a managed cloud environment. Production data is protected through regular automated backups.
Self-hosted Worklenz deployments can be configured with automated database backups and retention settings. Deployment operators should maintain protected backups and test restoration procedures regularly.
Production access
Access to Worklenz Cloud production systems is restricted to authorised team members; it is not available to all team members or developers. Administrative access is protected by layered identity and network controls.
Availability and secure operations
Worklenz uses application-level controls intended to support reliable and secure operation, including request limits for selected endpoints and safeguards designed to detect suspicious request patterns.
For self-hosted deployments, the operating organisation is responsible for establishing its own availability, monitoring, incident-response, recovery, patching, and change-management practices.
Security engineering and operations
Quality management
CeyDigital maintains an ISO 9001:2015 certified Quality Management System (QMS). This certification reflects our commitment to consistent processes, quality management, and continual improvement across the organisation.
ISO 9001:2015 is a quality-management certification. It is not an information-security certification.
Code review and change management
Changes to Worklenz are developed through a pull-request workflow. Every pull request is reviewed before it is merged. When a proposed change does not meet the expected quality, security, or implementation standard, changes are requested before approval and merge.
Build and release checks
Worklenz uses automated continuous-integration checks for backend, frontend, and client-portal changes. These checks include TypeScript compilation and production build validation.
Before a release is deployed to production, it is tested by the Worklenz quality-assurance team. Automated testing also helps identify bugs and verify core product functionality.
Dependency maintenance
Worklenz uses automated dependency monitoring. The engineering team regularly maintains and upgrades dependency packages as part of ongoing software maintenance.
Error monitoring and response
Worklenz uses industry-standard error monitoring and real-time alerting to help identify and investigate application errors and security-related events. Alerts are delivered to authorised team members so issues can be assessed and addressed.
Source-code transparency
Worklenz is open source. Customers and contributors can review the public core source code, deployment configuration, security policy, and release history through the public repository. Open development enables the community to inspect the product and report potential security issues responsibly.
Vulnerability management
We welcome responsible reports from security researchers and the community. Confirmed vulnerabilities are assessed, prioritised, and addressed through the Worklenz development and release process. See Report a vulnerability for private reporting channels.
Incident management
Worklenz maintains procedures to identify, assess, investigate, and respond to potential personal-data breaches. When an incident is reported or detected, the team evaluates the issue, determines the appropriate response, and takes corrective action as required.
Service providers and vendor management
Worklenz works with selected service providers to support the operation and delivery of the service. Depending on their role, these providers may include infrastructure, email delivery, analytics, help-desk, payment, or other service providers.
We evaluate service providers and their safeguards as part of our vendor-management process. Customers should also evaluate third-party integrations before enabling them in their Worklenz workspace.
International data transfers
Where personal information is stored or transferred across borders, Worklenz applies appropriate safeguards intended to protect the information and maintain its integrity. Further details are available in the Privacy Policy.
Shared responsibility
Security works best as a shared responsibility. We encourage customers to:
- Use strong, unique credentials.
- Remove access when team members or contractors no longer need it.
- Review organisation, project, and client-portal permissions regularly.
- Keep self-hosted Worklenz installations and supporting infrastructure current.
- Protect self-hosted infrastructure and backup storage.
- Review permissions before enabling integrations.
Security frequently asked questions
Is Worklenz available for self-hosting?
Yes. Worklenz is open source and can be deployed in an environment controlled by your organisation. Self-hosting gives you control over infrastructure, data storage, networking, backups, and operational security.
Who is responsible for securing a self-hosted deployment?
The organisation operating the deployment is responsible for its hosting environment, network configuration, operating systems, database, backup storage, monitoring, access controls, and update process. Worklenz provides the application software and its documented configuration options.
Does Worklenz support secure data transport?
Worklenz supports HTTPS/TLS for encrypted communication between users and the platform. Deployments should be configured to use HTTPS in production.
How can I request account deletion?
Follow the account-deletion request process in the Privacy Policy.
How can I report a security issue?
Use GitHub Private Vulnerability Reporting, or email [email protected] or [email protected]. Please do not disclose suspected vulnerabilities through public GitHub issues, discussions, or social media.
Security resources
Report a vulnerability
We welcome responsible vulnerability reports from security researchers and the community.
Please do not report potential security issues through public GitHub issues, discussions, or social media. Instead, use one of these private channels:
- Submit a private GitHub advisory (preferred).
- Email [email protected] or [email protected].
Please include a clear description of the issue, its potential impact, steps or proof-of-concept code to reproduce it, and the affected components.
