Безпека

Cognitify runs on Microsoft Azure in the West Europe region (the Netherlands). Customer workspace data — contacts, deals, documents, and conversations — is stored there, and any replica or backup copy of it stays inside the European Union.

Production is a separate environment from the environments we develop and test in, with its own application, its own secret store, and its own file storage. Development and test environments are seeded with synthetic data; customer data does not travel into them.

The question every multi-tenant vendor should be asked is what stops one customer reading another customer’s rows. For most it is application code — a filter on every query, correct until the one query where somebody forgets. We did not want that to be the answer.

Every tenant-scoped table in our PostgreSQL database carries a row-level security policy, forced on, and the application connects as a role that is neither the owner of those tables nor permitted to bypass those policies. A query that forgets its tenant filter returns nothing, because the database — not the code above it — decides what the connection is allowed to see. Isolation therefore survives the mistakes that application-level filtering does not.

An automated attack suite runs against a real PostgreSQL instance on every change, attempting cross-tenant reads and writes from the application’s own role, and a completeness check fails the build if a newly added table is not covered by it. Isolation is a test we run, not a claim we make.

• In transit — all traffic to our applications and APIs is served over HTTPS with managed certificates; plain HTTP is redirected, not accepted;
• At rest — the database, file storage, and backups are encrypted at rest by the Azure platform;
• Secrets — credentials, API keys, and integration tokens live in Azure Key Vault and are injected at runtime. They are never committed to our source repositories, and an automated check rejects a change that tries.

• Roles and permissions — every action in the product is checked against a named permission, and permissions are granted through roles rather than per-person exceptions;
• Multi-factor authentication — accounts can require a time-based one-time code in addition to a password;
• Single sign-on — workspaces can authenticate through Google or Microsoft instead of passwords we store;
• Scoped API keys — programmatic access is issued per integration with the narrowest permission set that works, and can be revoked without disturbing anyone else;
• No shared accounts — an automated check fails our build if a shared or generic login is introduced, so every action traces to a person;
• Access reviews — a scheduled job surfaces who holds which access for periodic review, rather than leaving it to memory.

Security-relevant actions — sign-ins, permission changes, exports, deletions — are written to an append-only audit log. Each entry is chained to the one before it by a cryptographic hash, so removing or altering an entry after the fact breaks the chain and is detectable. We verify that chain automatically.

The log is exported on a schedule to storage configured so that the exported copy cannot be modified or deleted for its retention period, including by us.

• The database supports point-in-time restore to any moment within the last 35 days;
• File storage and the secret store have deletion protection enabled, so a deleted object or secret can be recovered within its retention window;
• Restores are rehearsed, not merely configured — we have performed a full restore end to end and recorded the result, because a backup nobody has restored is an assumption rather than a control.

Where our products use large language models — drafting replies, summarising conversations, answering from uploaded documents — the content is processed by Microsoft’s Azure OpenAI Service as our subprocessor by default, or by the provider a customer connects instead.

Your data is not used to train our models or anyone else’s: we do not train on it, and our default AI subprocessor is contractually barred from doing so. Cognitify staff access workspace content only for support, security, and abuse prevention.

• Dependency vulnerability scanning gates every release; a build with a known vulnerable dependency does not ship;
• The tenant-isolation and audit-integrity suites run against a real database, not mocks — a mocked database would pass the exact tests that exist to catch isolation bugs;
• The codebase is TypeScript under strict compilation, with automated linting and formatting enforced before a change can be pushed;
• Changes move through separate development and test environments before production.

We have built our controls to the SOC 2 Trust Services Criteria and maintain the evidence for them — the tenant-isolation matrix, access reviews, immutable audit export, vulnerability scanning, and restore testing described above are the controls themselves, each mapped to the criterion it satisfies. We have not yet undergone a SOC 2 audit, and we do not hold a SOC 2 report or an ISO 27001 certificate. Anyone telling you otherwise about us is mistaken, and we would rather you heard it here.

For the GDPR, Cognitify OÜ is the controller of account and website data and acts as a processor for the workspace data our customers put into the products. Our Data Processing Agreement is published at cognitify.ai/pages/data-processing-agreement/ and applies automatically as part of our Terms of Service. The subprocessors we rely on, with their processing locations, are listed at cognitify.ai/pages/subprocessors/.

If you believe you have found a security issue in a Cognitify product or on this website, please tell us at info@cognitify.ai with "Security" in the subject line. Include what you found, the steps to reproduce it, and what you think an attacker could do with it. We aim to acknowledge a report within three business days and to keep you updated until it is resolved.

We do not currently run a paid bug-bounty programme. We will not pursue legal action over good-faith research that follows this page: test only against accounts and data that are yours, do not degrade the service for others, do not access, modify, or retain anyone else’s data, and give us reasonable time to fix an issue before disclosing it publicly. If you inadvertently reach data that is not yours, stop and tell us.

If a security incident affects customer data, we investigate, contain it, and notify the customers concerned without undue delay, with what we know, what we have done, and what we recommend. Where we act as a processor and a personal-data breach occurs, we notify the affected customer so that it can meet its own 72-hour obligation to its supervisory authority under Article 33 of the GDPR.

No system is perfectly secure, and this page describes controls rather than guarantees. What we can commit to is that we will tell you the truth about them — as we have on this page — and that we will tell you promptly when something has gone wrong.

Security questions from prospective customers, vulnerability reports, and questions about our Data Processing Agreement (published at cognitify.ai/pages/data-processing-agreement/) all reach us at the address below.