Trust Center
Security Summary
A control matrix for security reviews, with what each status rests on, and the technical and organisational measures behind the platform.
- Status
- In force
- Version
- 1.0
- In force from
- 8 September 2026
Sintoralabs OÜ · Registry code 17456201
This English text is the authentic version of this document. Translations into other languages are provided for convenience only; in the event of any discrepancy between a translation and this English version, the English version prevails.
1. Control matrix
The controls a security review asks about, each with a status and what that status rests on. The explanations are below the table; the table is the answer.
A status is never assigned automatically. Where there is no evidence in code, in configuration or in a document, the status is “to be confirmed” — not “confirmed” because a control is usual, and not because another page says so. Most rows are therefore open: what this website can show you is the website, and the platform is a separate system.
What the table grades is whether you can verify a control from public evidence — not whether we operate it. Most of these controls are undertakings we give under Annex 3 of our data processing agreement, which is a contract; a contract is a commitment rather than a proof. A row that is open is not a control we lack. It is a control you would have to take our word for, and the row says which word.
14 controls: 1 confirmed by evidence, 10 to be confirmed, 3 not implemented.
- Confirmed
- There is evidence we can point at, and the row names it.
- To be confirmed
- The control is claimed, and there is no public evidence you could check for yourself. That does not mean the control is absent — several are undertakings in Annex 3 of our data processing agreement, and the row says so. What is missing is in the row too.
- Not implemented
- This does not exist today. The row says what that means for a review.
| Control | Status | What it rests on |
|---|---|---|
| Encryption in transit | Confirmed | For this website the server requires HTTPS: it sends HSTS for a year including subdomains, and the content security policy upgrades any HTTP subresource to HTTPS.
|
| Encryption at rest | To be confirmed | Customer data is encrypted at rest using the storage-level encryption the infrastructure provides, and secrets and credentials are held in a managed secret store rather than in code or configuration files.
|
| Tenant isolation | To be confirmed | The platform is multi-tenant: each customer is a separate tenant, and data is segregated so that one tenant cannot read or affect another’s. Industry solutions install as modules inside the customer’s own tenant rather than as separate deployments.
On the Advanced tier of Sintora Meetings, the compute your organisation’s Meetings runs on is dedicated and sits inside your own tenant: the tenant, the data model, the permissions and the action log stay the same as for the rest of the platform. On Lite and Standard, Meetings runs on shared compute.
|
| Role-based access control | To be confirmed | Permissions inside the product are granular — assigned per action rather than per screen — and can be scoped to a network, an object or a single team. Access to production systems follows least privilege, through named accounts, reviewed periodically.
Access to meetings in Sintora Meetings is governed by the same roles and permissions of your organisation as the rest of the platform: Meetings runs inside your own tenant rather than as a separate product with an access model of its own.
|
| MFA for privileged access | To be confirmed | Privileged access to production systems is protected by multi-factor authentication. Inside the product, MFA is available to your users and an administrator can require it.
|
| Audit logs | To be confirmed | An audit log of significant actions inside your tenant is available on every paid plan and exportable by your own administrators. Administrative actions on our side are logged.
Significant actions in Sintora Meetings are recorded in a log inside your own tenant — the same log as for the rest of the platform, on every paid plan.
|
| Backup and recovery | To be confirmed | Customer data is backed up regularly, backups are encrypted and stored separately from production, and continuity and recovery plans exist.
|
| Infrastructure monitoring | To be confirmed | We collect application, infrastructure and security logs, monitor availability and error rates, and alert on anomalies. Access to those logs is restricted.
|
| Vulnerability management | To be confirmed | We patch systems on a risk-based schedule, prioritising vulnerabilities by severity and exposure, and track findings to resolution.
|
| Secure development lifecycle | To be confirmed | Changes go through version control, peer review and automated checks before release. Environments are separated, and production data is not used for development or testing. Release approvals are recorded in version control rather than in a separate change-management system.
|
| Security awareness training | To be confirmed | Everyone with access to customer data completes data protection awareness training on joining and annually thereafter.
|
| Independent penetration test | Not implemented | We have not commissioned an independent penetration test. What that means: When one is done, we will provide the summary under NDA. We publish no remediation targets by severity — those are agreed in a signed order form. |
| ISO/IEC 27001 | Not implemented | We hold no ISO/IEC 27001 certificate. What that means: We hold no external-auditor certification in any form and we claim none. If a certificate is a hard requirement of your procurement, say so at the start. |
| SOC 2 | Not implemented | We have no SOC 2 report, of either Type I or Type II. What that means: No SOC 2 audit has been performed. For a procurement review we provide the data processing agreement, the sub-processor list and a completed security questionnaire. |
Every row was checked against this website’s own code and the published documents; the oldest of those checks was made 3 September 2026, the most recent 12 September 2026. A row moves to “Confirmed” only together with evidence named in the row itself — never because a control looks usual.
2. Our approach
Sintora holds the operational core of a business — customers, contracts, conversations, money. That concentration is the point of the platform, and it is also why security is treated as part of how the product is built rather than as a layer added afterwards.
This summary describes the measures we apply. It is written for buyers, security reviewers and procurement teams who need to understand our posture before going into a detailed assessment.
3. Compliance
Our position on certification is in the table above: we hold none from any external auditor, and we claim none.
- GDPR — we are established in the European Union and process personal data under the GDPR, as a controller for our own data and as a processor for customer data.
- Recognised industry frameworks are used as a reference for how we structure access control, change management and incident response — as a working model, not as a certification we have passed.
- Contractual commitments — the obligations that matter to you are in the data processing agreement, which we are happy to sign.
If a certification is a hard requirement of your procurement process, tell us at the start of the review.
4. Infrastructure and data residency
The platform runs on managed cloud infrastructure. Cloudflare is engaged for DNS, content delivery, WAF, DDoS mitigation and bot protection; which of those are enabled in front of a given property is to be confirmed, and the one we can point at today is the Turnstile check on our forms.
Where a component or sub-processor operates outside the EEA, transfers rely on a mechanism recognised under Chapter V of the GDPR.
The providers we engage for compute, storage and backups are engaged for locations within the European Economic Area, and they are named on the sub-processor list. The specific regions and availability zones are not confirmed, and the list marks them as such beside each value. Per-customer residency beyond the EEA is not offered today and would be a signed-agreement matter if you need it.
5. What we do not publish
The following are provided on request, under NDA where appropriate, rather than published here. An exact configuration on a public page is a starting point for anyone probing it, and a published version number goes stale.
- The enforced TLS version, the cipher policy, and the key management and rotation approach.
- The technical isolation model — how tenant environments are separated.
- The specific tooling used for static analysis, dependency scanning and secret scanning.
- Backup frequency and retention, recovery objectives, and the date of the last restore test.
We publish no recovery point or recovery time objective as a commitment: a published objective is a promise, and a promise about recovery belongs in a signed agreement where it can be scoped.
Dedicated single-tenant deployments are not part of the standard plans; they are possible under a signed agreement.
6. Log retention
Website and server logs are retained for 30 days.
7. Incident response
We maintain an incident response process covering detection, triage, containment, eradication, recovery and post-incident review. Roles and escalation paths are defined in advance so that response does not depend on improvisation.
Where we act as controller, we notify the Estonian Data Protection Inspectorate within 72 hours where the breach is notifiable, and affected individuals where the risk is high.
Where a personal data breach affects customer data, we notify the affected customer without undue delay and in any event within 72 hours of becoming aware — the same commitment as the data processing agreement, which is the document that binds us. Notification goes to the administrative contact on your account by email; we do not run a public status page today.
8. Sub-processors and suppliers
We assess providers before engaging them, and bind each to a data processing agreement with confidentiality and security obligations at least as protective as our own. Providers are reviewed periodically, and material changes to the sub-processor list are communicated to customers so they can exercise their rights under the data processing agreement.
The current sub-processor list is Annex 2 of the Data Processing Agreement, published on this site. A new sub-processor is notified in advance of it starting processing, and you may object; if we cannot resolve the objection you may terminate the affected part of the service. The length of that notice is to be confirmed and will be stated in the data processing agreement, which is the document that binds us.
9. People
Everyone with access to customer data is bound by confidentiality obligations. We do not perform third-party background screening.
Data protection awareness training on joining and annually thereafter is an undertaking we give under Annex 3 of the data processing agreement. It is a row of the table above, with the status it actually has: we hold no completion record you could check, so the row says so rather than this paragraph asserting the cadence as a fact.
10. What you control
Security is shared. Roles and permissions, the audit log inside your tenant and multi-factor authentication are rows of the table above, with the status each of them actually has. The rest of what you operate is here.
- Export of your data in standard formats such as CSV and PDF.
- Administration of your own users — provisioning, role changes and removal.
Single sign-on over SAML or OIDC is available for enterprise deployments through the platform's own identity layer: your people authenticate against your corporate identity provider — Microsoft Entra ID, Google Workspace, Okta — and reach every suite, including Command Center, without a separate Sintora password. It is one platform capability rather than a feature of any single product.
IP allow-listing and configurable session policy are not available today; they are on the roadmap.
11. Reporting a vulnerability
If you believe you have found a security vulnerability, please report it to us before disclosing it publicly. Send details, including steps to reproduce and any proof-of-concept, and we will credit you if you would like that.
Please do not access, modify or delete data belonging to others, degrade the service, or run automated scanning that affects availability while testing.
Report a suspected vulnerability to info@sintora.ai with “security” in the subject. We acknowledge receipt and will tell you what we found and when it is fixed. How quickly we acknowledge is to be confirmed and is not published as a commitment until it is — the same treatment as the sub-processor notice period above, and for the same reason: a response time on this page is a promise, and no document we have signed carries one. We run no bug bounty programme and offer no reward, and we will not pursue anyone who reports in good faith, does not access other people’s data and gives us a reasonable chance to fix the issue before publishing.
12. Documentation for reviewers
For procurement and security reviews we can provide, under NDA where appropriate: our data processing agreement, the sub-processor list, completed security questionnaires and — where available — penetration test summaries. Contact info@sintora.ai to start a review.