Security

Topolo uses controls across sign-in, application access, data handling and service operations to protect the platform and the information entrusted to it. This page describes those controls at a service level. Available account features and customer-managed settings depend on the application and configuration in use.

Account and sign-in security

• Passkeys: Supported sign-in flows allow registered passkeys, with verification on the user's device and checks that the credential belongs to the account and sign-in request. • Two-factor authentication (2FA): Enrolled accounts can use authenticator-app codes as an additional sign-in check. Recovery codes support account recovery and are consumed when used. • Password protection: Password handling uses one-way hashing, password policies and controls for unsuccessful sign-in attempts. • Session management: Sessions have expiry and revocation controls. Supported account settings allow users to review active sessions and end access from a device. • Single sign-on across Topolo apps: Central sign-in supports access across Topolo applications. Each application still checks the permissions for the information and actions being accessed. Passkeys and 2FA depend on enrolment and the supported sign-in flow. Customers should enable available protections and maintain their recovery options.

Permissions and customer separation

Server-side access checks establish the caller's identity, organisation and relevant application, workspace or resource permissions. Read, write and administrative access are distinguished where the application supports those roles. Selecting a workspace or supplying a resource identifier does not itself grant access to it. Customer information is logically separated through these access controls and application data scopes. Administrators manage membership, roles and grants; users and connected tools remain subject to the permissions granted to them.

Encryption and data protection

Topolo service connections use HTTPS to protect information in transit. Managed storage services provide encryption at rest. Additional application encryption protects supported restricted content and stored integration credentials in the relevant services, with protection tied to the owning customer or resource context. The additional protection applied depends on the service and data type. Access to protected content and the keys needed to process it is controlled by the service. The encryption design supports controlled key rotation. Authorised service functions can process information when needed to deliver the requested feature; storage encryption does not remove the need for access permissions or appropriate sharing choices.

API, agent and integration access

API credentials and connected agents operate within their authorised organisation, application, action and resource scopes. Supported credentials have expiry and revocation controls. Removing a grant or revoking a credential withdraws the authority it provides, subject to the relevant service's token and session validation. Supported sensitive actions can require additional verification or approval. Approval checks bind the authorisation to the relevant action, request and resource. Customers can configure supported policies to require human approval for selected actions. Authorising an agent or integration does not automatically grant it unrestricted access to the platform or other customer workspaces. Customers control which connections they authorise and what information they instruct those connections to access or send. Supported external-service callbacks are checked using the verification mechanism for that integration before their events are processed.

File sharing and publication

Supported file-sharing features include view and download permissions, link expiry and revocation. Share creation and management check the caller's access to the selected files. Time-limited download links are checked for validity and expiry when used. Customers choose when to publish content or share it outside their workspace. Those choices affect who can access the information; account permissions cannot prevent a recipient from retaining information they have already received.

Browser and service protection

Browser-facing services use security headers and content restrictions to help control embedding, resource loading and browser capabilities. Request and origin checks help protect authenticated operations from unauthorised cross-site use. Public-facing flows use measures such as input validation, request limits and bot checks where applicable. Authentication controls include rate limiting and failed-sign-in protections. These controls help reduce abuse and unauthorised access alongside the protections supplied by our managed infrastructure providers.

Operational access and credential handling

Operational access is restricted to authorised personnel and systems that need it for service delivery, support, security or legal obligations. Personnel authorised to process customer personal data are subject to confidentiality obligations. Service credentials and connected-provider secrets are handled through controlled service functions. Credential-management responses limit exposure of stored secret material. Customers should keep their own credentials confidential, use appropriately limited grants and revoke access that is no longer needed.

Logging and incident response

Security and operational logging supports investigation of events such as unsuccessful sign-ins, changes to authentication settings and credential revocation. Authentication logging includes redaction of sensitive credential fields and reduced diagnostic detail in production. Logging detail, redaction controls and retention vary by service and purpose; further information about our processing is in the Privacy Policy . Topolo maintains processes to investigate security issues, contain incidents and address vulnerabilities. Where a personal data breach affects information processed on a customer's behalf, notification and cooperation are governed by the Data Processing Agreement and applicable law.

Secure development and release controls

Platform development uses version control, automated tests and checks for application behaviour, access restrictions and data protection. Engineering checks include dependency and secret scanning. Changes follow a controlled release process through separate development, staging and production environments. Security fixes and other changes are assessed and released through these engineering processes. Production and testing environments have separate configuration and access boundaries. Access to source, deployment tooling and operational credentials is restricted.

Data lifecycle and service continuity

Customers can use the export, deletion and account-management controls available in the relevant application, or make a request through our supported service processes. Available self-service functions vary by application. Customer instructions, applicable retention requirements and the DPA govern the handling of customer personal data when services end. Managed infrastructure and service health checks support availability and operational investigation. Backup and recovery tooling supports configured services, with permission checks on access and restore operations. Recovery work identifies the intended target and records operational progress. Backup coverage, recovery options and retention depend on the service and data involved. Customers should maintain exports or copies needed for their own business continuity and use the supported controls to manage access and retention.

Providers and contractual safeguards

Providers involved in delivering the service are identified in our subprocessor list . Their infrastructure protections operate alongside Topolo's application and operational controls. Annex II of the DPA describes the contractual technical and organisational measures. The DPA also addresses confidentiality, incident notification, assistance, subprocessors and applicable audit rights.

Contact and responsible disclosure

Contact security@topolo.io for security questions or vulnerability reports. Do not include credentials or unnecessary personal data. Intrusive security testing requires prior written authorisation and an agreed scope to protect the service and other users.