Security Summary

1. 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.

2. Compliance

We hold no third-party security certification and do not claim one. What follows describes the controls we actually operate, so you can assess them on their merits rather than on a badge.

• 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 for your procurement process, tell us early. We would rather say so upfront than have it surface late in a review.

3. Infrastructure and data residency

The platform runs on managed cloud infrastructure with hardened configurations, network segmentation and restricted administrative access. Our website and forms sit behind Cloudflare for content delivery, DDoS mitigation and bot protection.

We prefer to keep customer data within the European Economic Area, and offer EU data residency for the platform. Where a component or sub-processor operates outside the EEA, transfers rely on a mechanism recognised under Chapter V of the GDPR.

To be confirmed before publication: the cloud provider and regions in use, and whether data residency is configurable per customer.

4. Encryption

Data in transit between your browser or systems and the platform is encrypted with TLS. Data at rest is encrypted using the storage-level encryption provided by our infrastructure. Secrets and credentials are held in a managed secret store rather than in code or configuration files.

To be confirmed before publication: minimum TLS version enforced, cipher policy, and the key management approach including rotation.

5. Access control

Access to production systems follows least privilege: engineers get only the access their role requires, access is granted through named accounts, protected by multi-factor authentication, and reviewed periodically. Administrative actions are logged.

Within the product, customers control access themselves. Roles and permissions are granular — permissions are assigned per action rather than per screen — and can be scoped to a network, an object or a single team, so a front-desk user, a finance user and an owner see different things. Changes are recorded in an audit log.

6. Tenant isolation

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 data. Industry solutions are installed as modules inside the customer’s own tenant rather than as separate deployments, which keeps isolation, permissions and audit consistent across every module.

To be confirmed before publication: the technical isolation model (logical separation, schema separation or dedicated instances) and whether dedicated deployments are offered.

7. Secure development

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. Dependencies are monitored for known vulnerabilities and updated as part of routine maintenance.

To be confirmed before publication: the specific tooling used for static analysis, dependency and secret scanning, and whether release approvals are formally recorded.

8. Logging and monitoring

We collect application, infrastructure and security logs, monitor availability and error rates, and alert on anomalies. Logs are retained for a defined period to support investigation, and access to them is restricted.

To be confirmed before publication: log retention periods and whether customer-accessible audit exports are available on all plans.

9. Vulnerability management and testing

We patch systems on a risk-based schedule, prioritising vulnerabilities by severity and exposure. Security findings from automated scanning, code review and reports from third parties are tracked to resolution.

To be confirmed before publication: penetration test cadence and the most recent test date, whether a summary report is available under NDA, and target remediation times per severity.

10. 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 a personal data breach occurs and we act as processor, we notify affected customers without undue delay so they can meet their own obligations under Art. 33 GDPR. 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.

To be confirmed before publication: the customer notification target time committed in the data processing agreement, and the status page or channel used for incident communication.

11. Backups and continuity

Customer data is backed up regularly, and backups are encrypted and stored separately from production. We maintain continuity and recovery plans so that service can be restored after a significant failure.

To be confirmed before publication: backup frequency and retention, the recovery point and recovery time objectives (RPO/RTO), and the date of the last restore test.

12. 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.

To be confirmed before publication: the published sub-processor list, its location, and the notice period given before a new sub-processor is added.

13. People

Everyone with access to customer data is bound by confidentiality obligations and receives security and data-protection awareness training. Access is granted on joining according to role and revoked promptly on departure or role change.

To be confirmed before publication: whether background screening is performed, and the training cadence.

14. What you control

Security is shared. The platform gives you the controls to hold up your side.

• Granular roles and permissions, scoped by network, object or team.
• An audit log of significant actions inside your tenant.
• Export of your data in standard formats such as CSV and PDF.
• Administration of your own users — provisioning, role changes and removal.

To be confirmed before publication: availability of single sign-on (SAML/OIDC), enforced multi-factor authentication for end users, IP allow-listing, and session policy controls.

15. 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 — to info@sintora.ai, and we will acknowledge your report, keep you informed while we investigate, and 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.

To be confirmed before publication: a dedicated security contact address and whether a formal responsible disclosure or bug bounty programme is offered.

16. Documentation for reviewers

For procurement and security reviews we can provide, under NDA where appropriate: our data processing agreement, the sub-processor list, certification documentation, completed security questionnaires and — where available — penetration test summaries. Contact info@sintora.ai to start a review.