|Trust CenterTidal was founded by Information security experts and ethical hackers with over 35 years of industry and Big 4 experience. We have designed, implemented, and audited SOC 2 Type II compliant software systems.
Industry standards and compliance frameworks this organisation is aligned with or currently certified against.
Downloadable security policies, compliance reports, and certificates. Some documents may require an access request.
Our ISO 27001:2022 certificate
Our Statement of Applicability for ISO27001:2022
Specific security measures this organisation has implemented, alongside their current operational status.
Operational information that is copied to a test environment should be adequately secured, and removed in a timely manner when testing is completed. Sensitive information (including personally identifiable information) should not be copied into the development and testing environments. ### Evidence - Periodic review of information used for development and testing
Software development and implementation teams review and report project plans regularly to determine whether projects are on track and to identify any impact on security of any deviations from the project plan on (information security) goals. ### Evidence - Periodic software development project updates
Dependencies are scanned for (information security) issues and vulnerabilities. ### Evidence - Configuration of a dependency scanner
Developed programming code is peer reviewed before being moved into production. ### Evidence - Evidence of peer reviews
Static code analysis is configured as part of the release pipeline. ### Evidence - Configuration of release pipeline - Review of releases that do not pass the static code quality gate ## Further guidance **Static Code Analysis**: A white box test, commonly referring to the running of Static Application Security Testing (SAST) tools that attempt to highlight possible vulnerabilities within ‘static’ (non-running) source code by using techniques such as Taint Analysis and Data Flow Analysis. SAST does not require code to be compiled, and can hence be applied in the code development stage.
Rules for the secure development of software and systems are defined and implemented. ### Evidence - Secure development framework
Code linters are configured as part of the release pipeline. ### Evidence - Code linter configuration for release pipeline(s) ### Further guidance **Code linter**: A tool that programmatically scans source code with the goal of finding issues that can lead to bugs or inconsistencies with code health and style. Code linters are commonly able to flag programming errors, bugs, stylistic errors, and suspicious constructs.
Developed information assets are provided with user- and technical system documentation to reduce any unnecessary dependency on subject matter experts. ### Evidence - User documentation - Technical system documentation ### Further guidance - Documentation may describe the development, implementation, operation and/or configuration of developed assets
Development, testing and operational environments are logically or physically separated to reduce the risks of unauthorized access or changes to the operational environment and to ensure no impact to production systems. ### Evidence - Evidence of separation of development, testing and production environments
Application secrets are separated from source code. ### Evidence - Configuration of a service for securely storing and accessing secrets, and/or; - Configuration of a static code analysis solution (SAST)
Dynamic application security testing is periodically performed on (relevant parts of) the code base. The results are evaluated and if needed acted upon. ### Evidence - Evidence of dynamic application security testing (DAST), either with a DAST tool or as part of a planned penetration test. ### Further guidance **Dynamic application security testing (DAST): ** A process of testing an application in an operating state to find security vulnerabilities (as opposed to SAST, which is performed on source code). DAST tools analyse programs while they are executing to find security vulnerabilities such as memory corruption, insecure server configuration, cross-site scripting, user privilege issues, SQL injection, and other critical security concerns.
All (internal and external) software developers working for the organisation acknowledge their understanding and compliance with the secure development framework. ### Evidence - Acknowledgement of Secure development framework
Project plans are in place to manage the development and implementation of software and systems, regardless whether this is managed inside or outside the IT organisation. ### Evidence - Roadmap for software projects - Translation of roadmap to development milestones - Team setup in Version Control software ### Further guidance - Elements of a project plan may include project objectives, roles & responsibilities, risk assessment, project plan, time frames and steps, key milestone, and functional and non-functional requirements.
Branch Policies are applied to all repositories that are involved in deploying changes to our production environments ### Evidence - Branch policies implemented on different repositories and pipelines ### Further guidance **Branch Policy: *** A set of rules and controls applied to certain branches in a version control system (such as Git). Branch policies are designed to ensure the integrity, quality, and security of the codebase. Common branch policies enforce access control, code reviews, (automated) testing, merge methods and restrictions, and code ownership. Also known as branch protection rules or branch restrictions.
Networks, systems and applications are continuously monitored for anomalous behaviour. ### Evidence - Logs of networks, systems and applications are contiously monitored
Logfiles of activities, exceptions, faults and other relevant events are protected (from unauthorized changes). ### Evidence - Evidence of restriction of access to Log files
Logfiles of activities, exceptions, faults and other relevant (information security) events are produced, stored, and analysed. Appropriate actions are taken to evaluate potential information security incidents. ### Evidence - Configuration of security information and event management (SIEM) solution - Evidence of review of events reported by the SIEM solution used
Capacity and performance of systems, applications and services are continuously monitored to ensure meeting expected and anticipated future capacity requirements. ### Evidence - Evidence of monitoring (and if needed - adjusting) of resource usage
Rules and procedures have been established to produce logfiles of activities, exceptions, faults and other relevant (information security) events. ### Evidence - Event logging policy
Potential incidents are classified and prioritised taking into consideration the likelihood and impact of the incident impacting the security and continued operations of services. ### Evidence - Review of incident in-take and assessment
Incidents are communicated and reported adequately and in a timely manner. Where relevant, incident root causes are identified and lessons learned are implemented to prevent similar incidents in the future. ### Evidence - Evidence of adequate and timely reporting of significant and disruptive incidents ### Further guidance - Significant and disruptive incidents are reported with undue delay to management and external bodies in accordance with applicable laws and regulations. - Root causes and lessons learned are identified where applicable to prevent similar incidents in the future.
An incident register has been established. Each incident is registered in the incident register, and categorised and prioritised for analysis and resolution. ### Evidence - Incident register
Incidents are resolved adequately to mitigate the impacts related to (significant) incidents and to ensure that services remain or become operational and secure in a timely manner. ### Evidence - Review of effectiveness and timeliness of incident response activities (planned and executed response actions)
Procedures and responsibilities are in place to identify, track, log, categorise, and classify incidents according to a priority, based on business criticality. ### Evidence - Incident response framework
The information security and privacy policies, standards and procedures have been communicated within the organisation. ### Evidence * Confirmations by employees that they have read and understand the information security policy
Rules and procedures for information security and privacy are defined and communicated. ### Evidence - Information security policy
Management regularly tests, assesses, and evaluates the effectiveness of technical and organisational security measures. ### Evidence - Management review of the ISMS - Results of corrective actions
An IT strategy and related objectives and action plans, budget and resources are set, approved and managed as part of organisation's overall business strategy. ### Evidence - IT organisation strategy (optional) - Information security objectives
Clear roles and responsibilities, including mandates and reporting lines, to identify, implement and manage the organisation's strategy, policies, and relevant statutory, regulatory and contractual controls are defined and assigned. ### Evidence - Definition of security roles & responsibilities
The organisation understands the internal and external context it operates in. ### Evidence * Organisation context ## Further guidance **Organisation context:** All matters that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system (ISMS).
Determine the boundaries and applicability of the information security management system. ### Evidence * Scope of the ISMS
Risk treatment plans identify all controls needed to implement the chosen information security risk treatment. ### Evidence - Statement of Applicability ### Further guidance **Specific requirement for ISO 27001:** A Statement of Applicability has been established which contains: - all necessary controls, - justification for their inclusion; - whether the necessary controls are implemented or not - justification for excluding any of the ISO 27001 Annex A controls.
The use of data is restricted according to its classification. ### Evidence - Periodic review of processing of classified data against the policy
Data in transit is appropriately encrypted to ensure the integrity and confidentiality of the data. ### Evidence - Evidence to determine strength of encryption configuration for data in transit
Sensitive and/or personal data is masked or sanitised where possible in line with applicable regulations. ### Evidence - Review of information assets to determine the need for masking - (if applicable) Evidence of masking
Rules for the effective use of cryptography, including cryptographic key management, are defined and implemented. ### Evidence - Encryption policy
Rules and procedures are defined and implemented to protect records from loss, destruction, falsification, unauthorized access and unauthorized release. ### Evidence - Records management policy
Rules and procedures are defined and implemented to classify data and assets according to the sensitivity and type of data. ### Evidence - Information classification policy
Rules and procedures are defined and implemented to ensure (personal) data collection, storage, retention and disposal is performed securely and in accordance with laws, regulations, and contracts. ### Evidence - Privacy policy
Data at rest is appropriately encrypted to ensure the integrity and confidentiality of the data. ### Evidence - Review of encryption configuration for data at rest
Data protection impact assessments (DPIAs) are performed in accordance with GDPR. ### Evidence - Data protection impact assessments ### Further guidance **Data Protection Impact Assessment (DPIA):** An assessment of the impact of envisaged processing operations on the protection of personal data, before the processing is started. **It is required when** a type of processing (in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing) is likely to result in a high risk to the rights and freedoms of natural persons. The following examples are offered to help assess whether a project involving data processing should receive a DPIA: * If you’re using new technologies * If you’re tracking people’s location or behavior * If you’re systematically monitoring a publicly accessible place on a large scale * If you’re processing personal data related to “racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation” * If your data processing is used to make automated decisions about people that could have legal (or similarly significant) effects * If you’re processing children’s data * If the data you’re processing could result in physical harm to the data subjects if it is leaked
Data is retained for a defined period of time to fulfill the identified purpose or as required by law, and is securely disposed of at the end of this period. ### Evidence - Configuration of data retention for storage systems - Evidence of deletion of data that is no longer required ### Further guidance The records management policy specifies the rules for retaining and/or disposing of data. When setting system-specific retention policies for data, we should evaluate: 1) Regulatory requirements to retain and/or dispose of data after a certain time 2) Requirements following from the data classification 3) The principle of data minimisation, i.e. to dispose of data when it has no further value for the organisation. Data should be disposed of, destroyed or erased in a secure way. Data disposal should include all originals, copies and archived records of the data.
Third party access to our networks, systems, and other services is removed when supplier contracts end. ### Evidence - Evidence of removal of third party access
Rules and procedures have been defined and implemented to mitigate information security risks of working with suppliers (and other partnerships) ### Evidence - Supplier security policy ### Further guidance The following scenarios may trigger a risk assessment when working with a (new) third party: - outsourcing of (critical) processes to third parties - providing third parties with access to (personal or confidential) data. - providing third parties with access to our network, systems and/or other services under our responsibility. Third party controls should be implemented to ensure compliance with statutory, regulatory and contractual controls.
Non-disclosure agreements are in place with all suppliers that have access to classified and other restricted information. ### Evidence - Non-disclosure agreements (NDAs) with relevant third parties ### Further guidance The information classification policy and business impact analysis (BIA) provide more details on which information is considered restricted.
Information security risk assessments are performed for suppliers where risks are associated with the use of their products or services. ### Evidence - Supplier risk assessment(s) ### Further guidance A risk assessment should be performed prior to starting the cooperation, and when the risk profile changes (e.g. due to procuring additional services from the supplier)
Data protection Agreements (DPA) are included in supplier contracts in line with GDPR requirements. ### Evidence - Data protection agreements with third parties
Agreements (contracts and service level agreements) with third parties include organisation's risk assessment and requirements. ### Evidence - Contracts with third parties
Any assets (and devices) provided to third parties as part of other service delivery to should be returned when supplier contracts end. ### Evidence - Evidence of return of assets provided to third parties
Third party service delivery and agreements are monitored to obtain assurance over third party service delivery against the organisation's security objectives, measures and performance targets. ### Evidence - Review of service delivery ### Further guidance The third party may provide assurance as follows: - A valid ISO 27001 certification - A SOC2, SOC3, or ISAE3402 report covering the service scope and -period - Insight in the operating effectiveness of their own ISMS - Service Level Reporting The nature and extent of assurance required is dependent on the risk profile of the third party.
A Vulnerability Disclosure and Reporting Policy (VDRP) is implemented to facilitate the responsible and secure reporting of vulnerabilities within the organization's information systems. ### Evidence - Vulnerability disclosure and reporting policy ### Further Guidance This VDRP outlines the procedures and guidelines for internal and external parties to report potential security weaknesses and vulnerabilities they may discover in the organization's IT infrastructure and information assets.
System, applications and services are periodically subjected to vulnerability assessments and tests (e.g. red teaming, penetration testing) to validates the robustness and effectiveness of technical information security measures. ### Evidence - Security test report
Protection against malware is in place to detect and eradicate malicious code. ### Evidence - Evidence of installed anti-malware software
Penetration tests and other security verification tests should be performed on a regular basis. Software security testing can be performed as part of a specific release, or as part of a wider information security test. ### Evidence - Penetration test report
The organisation has a clear understanding and situational awareness on evolving threats and attacker tactics in the current threat landscape, and their potential impact on the business. This information supports strategic decision-making, risk assessment, and resource allocation. ### Evidence - Analysis of external threat reports and news
Software and firmware are kept up to date by deploying critical security patches and application updates in a timely manner. ### Evidence - Evidence of implementation of critical security patches / applicable patch levels - Overview of active security concerns/unpatched vulnerabilities
The organisation implements and configures a threat intelligence solution that monitors publicly known vulnerabilities in software and hardware in use by the organisation, and informs the organisation of any threats detected. ### Evidence - Configuration of a threat intelligence solution - Evidence of follow up of identified threats
The attack surface of the codebase is minimized by limiting duplicate code and removing unnecessary/unused functions. ### Evidence - Evidence of duplicate code review
Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows. ### Evidence - Network architecture overview - Evidence of (virtual) segmentation of information flows
Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows. ### Evidence - Network architecture overview
Endpoints are adequately protected and the use of these devices is authorised by management. ### Evidence - Endpoint configuration and handling policy ### Further guidance **Endpoint:** Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].
Endpoints are periodically reviewed to ensure that they remain adequately protected. ### Evidence - Evidence of endpoint compliance from mobile device management (MDM) software in use or the device itself. ### Further guidance **Endpoint:** Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].
Secure baseline configurations consistent with industry-accepted system hardening standards are in place for applicable systems, applications, services, and networks. The clocks of information processing systems used by the organization are synchronized to approved time sources. ### Evidence - Secure baseline
Networks and network devices are secured, managed and controlled to protect information in systems and applications. This includes the logical or physical segmentation of information flows. ### Evidence - Evidence of firewall configuration - Evidence of port scan on production environment
Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date. ### Evidence - Statutory, regulatory, and contractual requirements
An internal audit function has been established. The function is tasked with assessing compliance with relevant statutory, regulatory and contractual controls, and the effectiveness of the compliance function. ### Evidence - Internal audit framework
Internal audits are being performed and the results are reported to relevant management. Internal audit reports shall be available as evidence of the audit programme(s) and the audit results. ### Evidence - Internal audit report(s)
Internal audits are conducted at planned intervals to provide information on whether standards and requirements that the organisation is subject to are effectively implemented and maintained. ### Evidence - Internal Audit Plana
Disaster recovery testing is performed periodically. ### Evidence - Report of disaster recovery test ### Further guidance **Disaster recovery test** An exercise conducted to validate the effectiveness of the business continuity plan and identify areas for improvement. Tests may involve simulations of various scenarios to assess an organisation's readiness and enhance response capabilities, and, where applicable, the switch-over of critical business functions, supporting processes and information assets to the disaster recovery environment.
The restore of information from a backup is periodically tested and evaluated against RPO and RTO targets. ### Evidence - Report of test of restore procedure
Rules and procedures are defined and implemented to create, maintain, and test backup copies of information, software and systems. ### Evidence - Backup policy
Business impact analyses (BIAs) are performed periodically to determine the maximum tolerable downtime for each critical function and identify dependencies between functions. ### Evidence - Business impact analysis
Backups of data, software and/or system images are created periodically to ensure the availability of the data to satisfying Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). ### Evidence - Evidence of backup configuration - Log of backups performed
Rules and procedures have been defined and implemented to continue and recover business services, and to limit losses, in the event of severe business disruption. ### Evidence - Business continuity framework #### Further guidance The business continuity framework should include: - a policy statement - procedure for performing a business impact analysis (BIA) - rules for performing continuity risk assessments - procedure to respond to incidents and communicate in the event of a crisis - contracted RPO, RTO, and up-time for critical business services - disaster recovery scenarios and dependencies
Internal and external risks that the organisation is exposed to are identified, assessed, reported and documented. ### Evidence - Risk assessment report(s)
Risks are mitigated to an acceptable level by regularly assessing appropriate information security risk treatment options, and identifying and implementing appropriate mitigating controls. ### Evidence - Risk Treatment Plan(s)
A risk management framework has been implemented and is continuously improved based on 'lessons learned' during its implementation and monitoring. It has been approved and is being reviewed annually by management. ### Evidence - Risk management framework
All individuals becoming employees, including key function holders, sign confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information. ### Evidence - Non -disclosure agreements (NDAs)
All individuals departing from employment, including key function holders, undergo a comprehensive exit process. This process includes revoking access rights. ### Evidence - Access review showing Leavers have been removed
All individuals becoming employees, including key function holders, are informed, and held subject to, acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior. ### Evidence - Acceptable use policy
Clear roles and responsibilities, including mandates and reporting lines, to identify, implement and manage the organisation's strategy, policies, and relevant statutory, regulatory and contractual controls are defined and assigned. ### Evidence - Records of skills, experience and qualifications for employees with specific roles regarding information security
All individuals becoming employees, including key function holders, are screened prior to them performing activities subject to screening. ### Evidence - Results of employee screening
All individuals departing from employment, including key function holders, undergo a comprehensive exit process. This process includes returning company assets. ### Evidence - Evidence of return of assets by Leavers
All employees, including key function holders and contractors, receive appropriate training. ### Evidence - Records of security (awareness) training
All individuals becoming employees, including key function holders, are informed, and held subject to, acceptable and unacceptable rules of behavior for the use of technologies, including consequences for unacceptable behavior. ### Evidence * Acceptable use of assets
All users receive and register access to information assets under an unique ID, to ensure traceability and individual accountability for actions taken by the individual. Non-personal identification methods (e.g. shared credentials, group accounts) are tightly controlled. ### Evidence - Review of generic and shared user accounts
Employees receive access commensurate their roles & responsibilities based on the 'need to know', 'least privileges', and 'segregation of duties' principles. Privileged access rights are tightly controlled and regularly reviewed. ### Evidence - Evidence that privileged identities are tightly controlled
Employees receive access commensurate their roles & responsibilities based on the 'need to know', 'least privileges', and 'segregation of duties' principles. Privileged access rights are tightly controlled and regularly reviewed. ### Evidence - Authorisation setup (SOLL matrix)
Access control procedures are in place defining how access is managed, who is allowed to access what and how, and which authentication methods and requirements apply where. ### Evidence - Access control policy
Procedures are in place to provision, update, and revoke access rights in a timely manner. Access rights are reviewed periodically. ### Evidence - Periodic review of user access rights
Authentication methods are appropriately implemented and sufficiently robust to adequately and effectively ensure that access control policies and procedures are complied with. Strong (two-factor) authentication methods are enforced where applicable. ### Evidence - Configuration of secure authentication for all users, or; - List of users with their authentication mechanisms
Endpoints are adequately protected and the use of these devices is authorised by management. ### Evidence - All employee endpoints are registered in the asset inventory and enrolled in our mobile device management (MDM) solution ### Further guidance **Endpoint:** Any device which stores or processed information (e.g. laptops, mobile devices) whether owned by the organization or owned privately and used on behalf of the organization [bring your own device (BYOD)].
The organisation has established, and maintains, an asset inventory. The inventory contains all information assets supporting the organisation's business functions and supporting processes, and maps information assets and dependencies on other internal and external systems and processes. ### Evidence - Inventory of assets
Rules for the secure installation of software and updates on operational systems are defined and implemented. ### Evidence - Change management procedure ### Further guidance - changes to information systems may also include system configuration changes, updates to existing security measures, and installation of acquired software - the rules may include the need for controlled recording, testing, assessing, approving, implementing and verifying of new software and code before it is put into production. - Emergency changes (i.e. changes that must be introduced as soon as possible) follow procedures that provide adequate safeguards.
Operating Procedures are in place for operational activities associated with information security. ### Evidence - Operating procedures for IT management ### Further guidance Procedures need to be in place for activities that meet the following requirements: * the activity needs to be performed in the same way by many people or be able to be handed over to someone else; * the activity is new or performed rarely and presents a risk if not performed correctly; Documented operating procedures should be reviewed and updated when needed, and changes authorised. ### Examples of relevant operational activities: * How to install and configure systems * How to process or handle certain information * How to perform backups and restores * How to manage scheduling inter-dependencies between systems * How to handle errors or other exceptional conditions * How to ask for external support and escalate unexpected technical difficulties * How to handle storage media * How to restart systems or services * How to handle audit trails and system logs * How to monitor services for capacity, performance, and security * How to maintain systems, networks, and applications
Third parties this organisation works with that may process customer data.
Error and performance monitoring. Diagnostic data may incidentally include user identifiers. Processed in Sentry's EU data region in Frankfurt; the provider entity, Functional Software, Inc., is established in the United States and Standard Contractual Clauses cover support access. Error logs are retained for 90 days.
Product analytics used to measure feature usage and improve the platform. Hosted on PostHog Cloud EU in Frankfurt; the provider entity, PostHog, Inc., is established in the United States and Standard Contractual Clauses cover support access.
Hosts the platform, database and backups in the EU region West Europe, replicated across multiple EU availability zones. Also generates the document embeddings behind semantic search, through Azure OpenAI.
Provides the language model behind the in-app AI assistant. Receives the prompts submitted by users and the platform content retrieved to answer them. Processed in the United States under Standard Contractual Clauses.
Answers to commonly asked questions regarding this organisation's security and privacy practices.
Yes. Users are authenticated via Keycloak, with support for Single Sign-On (SSO) and Multi-Factor Authentication (MFA).
We apply the principle of least privilege to employee access. Development and production environments are segregated, and all user activity is logged and monitored.
Yes. Our Information Security Management System (ISMS) is certified against the ISO/IEC 27001:2022 standard. The certificate scope, validity period and the full certificate are available for download in this Trust Center.
Tidal Control runs on Microsoft Azure in the West Europe region. Our infrastructure is provisioned and managed as code using Terraform, ensuring consistent, repeatable, and best-practice configuration.
Your data is stored in the EU. The platform, database and backups run on Microsoft Azure in the West Europe region, replicated across multiple EU availability zones.
Two supporting services process a limited set of data outside the EU, both under the European Commission's Standard Contractual Clauses. The in-app AI assistant runs on Anthropic in the United States, which receives the prompts you submit and the platform content retrieved to answer them. Transactional email such as notifications and invitations is sent through Postmark in the United States, which receives recipient name, email address and message content.
The full list of subprocessors, with the purpose and location of each, is published in this Trust Center.
No. Tidal Control uses a multi-tenant architecture in which each customer receives their own dedicated platform tenant, and data is inaccessible to other tenants.
Backups are encrypted with AES 256-bit encryption and replicated across multiple EU availability zones.
Cryptographic keys, secrets, and credentials are safeguarded in Azure Key Vault.
Yes. Data is encrypted both at rest and in transit using a strong cryptographic configuration. Backups are encrypted with AES 256-bit encryption.
The platform runs across multiple Azure availability zones, with data and backups replicated across multiple EU zones to support resilience and availability.
Yes. We manage all personal data in line with the GDPR and our Privacy Policy, and we maintain Data Processing Agreements with the third parties involved in delivering the service.
Yes. We act as processor for the personal data you manage in Tidal Control. The processor terms are set out in article 12 of our SaaS Terms and Conditions, which together with your contract form the data processing agreement referred to in the GDPR. Some of the subprocessors we engage are established outside the EEA; those transfers are covered by the European Commission's Standard Contractual Clauses agreed with the subprocessor concerned. Our subprocessors are listed in this Trust Center. If you need a single DPA document for your own vendor records, contact us and we will provide one.
We continuously monitor for vulnerabilities using Dependabot (third-party dependencies) and Sentry. We also conduct periodic threat modeling to identify and mitigate risks.
All code changes go through mandatory code reviews enforced by branch policies, and third-party dependency vulnerabilities are managed through Dependabot.
Third-party vendors are regularly reviewed for adherence to our security policies and standards, and Data Processing Agreements are in place where personal data is involved.