Privacy shield

No, CogniVis does not process or store customer data for AI training purposes. We use only LLM providers that commit not to train on data entered by users. Alternatively, we can deploy CogniVis using local LLMs installed on the customer’s servers, which do not require data sharing.

By default, data is stored in Poland (the EU) or, on request, at the customer’s premises or with a selected cloud service provider. When LLM platforms are used, data may be processed by external providers, such as OpenAI, or stored locally, depending on the selected model. CogniVis stores data for the duration of the agreement and deletes it 30 days after the agreement ends.

Data is protected with TLS 1.3 encryption during transmission. For example, when knowledge is indexed, data is retrieved through APIs protected by TLS 1.3, and communication is also encrypted using TLS when messages are sent to LLM systems.

After each deployment, we subject our software to penetration testing in line with OWASP standards to identify and mitigate security threats.

APIs are protected with TLS 1.3 encryption for every endpoint, together with an additional token-based authentication layer for endpoints that require it. This is designed to prevent unauthorised access and misuse.

CogniVis provides regular backups as part of selected plans, ensuring redundant, secure data storage and recovery.

Where required, we offer deployment of CogniVis on the customer’s servers, or alternatively with OVH or AWS, which hold SOC 2 and ISO 27001 certifications.

Yes, single sign-on (SSO) integration can be implemented on request. SSO improves security by centralising authentication, reducing password-related risks and enabling better access control through existing identity management systems, such as Microsoft Azure AD.

CogniVis uses role-based access control (RBAC) with user groups to assign permissions precisely. When integrating with specific third-party solutions, access levels for each data source are defined during implementation.

This depends on the settings. If encryption is enabled, we can see only the number of questions and token usage—we do not have access to the questions or answers. If encryption is disabled, we can analyse the questions asked, which helps us refine and optimise AI performance. We strongly recommend keeping encryption disabled during the initial implementation phase so that the system can be adapted to your needs more quickly.

CogniVis follows GDPR-compliant data storage and deletion principles. Temporary data, such as cached data and in-memory operations, is not stored for longer than necessary and is deleted immediately after processing. Persistent data is stored only for as long as required to provide the services and fulfil legal obligations. Data retention periods are reviewed regularly to prevent unnecessary storage. Customers have full control over their data and can request its deletion at any time in accordance with Article 17 of the GDPR. When deletion is requested, CogniVis ensures that data is deleted securely and irreversibly, with a maximum retention period of 30 days after the agreement ends.

CogniVis follows a structured incident response process to minimise impact and ensure transparency. 1. Detection and assessment – continuous monitoring detects threats. Critical incidents are analysed within 4 hours of detection. 2. Containment and mitigation – affected systems are isolated, API keys are rotated and, where necessary, password resets are enforced. 3. Investigation and analysis – security experts assess the cause of the breach and implement measures to prevent recurrence. 4. Customer notification – in the event of a data breach, affected users are notified by email as quickly as possible, with details of the breach, the data affected and recommended actions. 5. Personal data – in the event of a personal data breach, the relevant authorities are notified within 72 hours. 6. Remediation and prevention – security policies are updated and improved measures are implemented to prevent future incidents.

We use MFA for all accounts, particularly privileged accounts, with support for mobile applications. Our password policy requires a minimum of 16 characters, favours passphrases, checks password strength and blocks weak passwords. We integrate SSO and monitor unusual logins, reducing the risk of account takeover.

We apply the principle of least privilege, conduct regular access reviews and use a process for approving elevated permissions. We use IAM for centralisation, automate onboarding and offboarding, and grant administrative access temporarily on a just-in-time basis. These measures reduce exposure and support audit compliance.

We centralise application and system logs, establish behavioural baselines and monitor the infrastructure in real time. SIEM generates alerts for anomalies and suspicious access attempts, while regular log analysis supports early incident detection. Operations involving sensitive data are also recorded, making investigations easier.

Our password policy requires at least 16 characters, favours passphrases, does not enforce rotation without an incident, checks strength during creation and blocks commonly used passwords. Accounts are locked after failed attempts. Passwords are stored only as hashes using strong algorithms such as bcrypt or Argon2.

BYOD is permitted only when there is no better alternative. A BYOD policy applies, with company data containerisation, restricted access to sensitive information and procedures for securely removing data from devices. Employees are trained in safe personal-device practices to reduce the risk of data leaks.

Remote access is provided through strongly encrypted VPNs, with traffic segmentation and usage monitoring. Network infrastructure is audited and updated regularly. Remote work is subject to physical security rules, including clear-screen and clear-desk policies. These measures reduce the risk of eavesdropping and device takeover.

We maintain an inventory of components and versions, prioritise security patches and automate package management. Updates are verified in a test environment that mirrors production, with regression testing and a rollback plan. We create backups before changes, and document and version everything to ensure reproducibility.

We follow OWASP Secure Coding Practices, use trusted libraries and apply the principle of least privilege in code. We conduct security-focused code reviews and use SAST and DAST. Security is considered from the design stage, while coding standards are enforced and checked automatically for consistency.

We rigorously validate all input, favouring allowlists of permitted values. We sanitise output and handle JSON/XML parsing and serialisation securely. We use prepared statements and mechanisms to prevent XSS, CSRF and injection attacks. Default behaviour is fail-safe to limit the impact of errors.

We regularly organise red team versus blue team exercises, phishing simulations and incident scenarios. We analyse the results and update detections, procedures and training to improve team readiness. The testing programme is refreshed to address new attack vectors and measures real improvements in response.

We have a DR plan defining critical systems, RTO and RPO. We document recovery procedures for different scenarios and test them at least once a year. We analyse test results and make improvements to reduce downtime and minimise data loss if services fail.

We design redundancy for critical components, along with backup power and cooling, and regularly test failover. Our business continuity plan defines critical functions, remote working arrangements and alternative locations with the necessary resources. Communication channels and roles are defined for crises, speeding up the response.

We apply data minimisation and the need-to-know principle. Automated mechanisms are in place to delete or archive outdated information, together with secure, irreversible deletion methods. We maintain logs of operations involving sensitive data and conduct regular access reviews to reduce the risk of misuse and meet compliance requirements.

We encrypt data in transit using TLS 1.3 and apply additional application-level end-to-end encryption to particularly sensitive information. We rotate certificates and block unencrypted connections, maintaining compliance with the latest standards. This strengthens confidentiality beyond the transport layer and protocol alone.

We protect APIs using OAuth 2.0 or OpenID Connect and transmit identity information as JWTs. We apply rate limiting, monitor usage and rotate keys. We validate parameters, use secure serialisation and version APIs with deprecation plans and migration support. Documentation and testing are kept up to date.

We maintain an automated register of open-source components, including their versions and licences. New components undergo multi-stage quality and security checks and are reviewed for compliance with our licensing policy. We monitor project channels and maintain forks for critical dependencies, along with our own security fixes where necessary.

Email is filtered in multiple layers, with reputation and content analysis and attachment sandboxing. For domains, we maintain SPF, DKIM and a DMARC policy with ongoing reporting and gradual tightening from monitoring to rejection. This significantly reduces spoofing and phishing across the organisation.

We create full backups according to a schedule and store them in secure, geographically separate locations. We regularly test restoration and document procedures, while preparing additional backups before updates. These practices shorten recovery times and limit data loss in the event of a failure.

We segment the network using VLANs and firewalls between segments. Network devices are configured according to the principle of least privilege, firmware is updated regularly, unnecessary services are disabled, strong passwords and key policies are enforced, and logging and monitoring are enabled for all devices to detect anomalies more quickly.