Security policy

1. Scope and governance

This policy covers the Syntxt platform, the environments in which it is deployed, our corporate systems and this website. Accountability for information security sits with the Syntxt executive. Security requirements are treated as product requirements and are reviewed as part of the design of every feature, not as a control applied afterwards.

We are an early stage company. We do not currently hold ISO/IEC 27001 certification or a SOC 2 report, and we will not claim otherwise. Our control set is designed against those frameworks and formal certification is on our roadmap. We complete customer security questionnaires, participate in architecture reviews, and accept contractual security commitments proportionate to the assurance a customer requires.

2. Data residency and tenancy

• Each customer runs in a dedicated, logically and physically separated environment hosted in the market of the insurer.
• United Kingdom data remains in the United Kingdom, European Union data in the European Union, United States data in the United States, and equivalently for other markets we serve.
• Personal data is not transferred outside the agreed region except on the customer’s documented written instruction and under an appropriate transfer mechanism.
• Customer data, configuration, appetite rules and rating logic are never pooled with those of another customer. Every record in the data model carries a tenant identifier, so isolation is enforced at the data layer rather than only in application logic.

3. Encryption and key management

• All data in transit is encrypted using current versions of TLS. Legacy protocol versions and weak cipher suites are disabled.
• Data at rest, including databases, object storage and backups, is encrypted using industry standard algorithms.
• Keys are held in a managed key service with restricted administrative access and defined rotation.
• Application secrets are held in a managed secret store. Secrets are never committed to source control and never written to application logs.

4. Identity and access control

• Customer users authenticate through the customer’s own identity provider using enterprise single sign on, with multi factor authentication enforced by that provider.
• Authorisation is role based and mapped to the customer’s underwriting authority structure, including authority limits and separation of duties for four eyes approval.
• Syntxt personnel receive access on a least privilege basis, justified by role. Access is reviewed on a defined cycle and revoked promptly when it is no longer required or on departure.
• Administrative access to production is individually attributable, time limited, requires multi factor authentication and is logged.
• Shared or generic accounts are not used for administrative access.

5. Secure development

• All changes are peer reviewed before they reach the main branch. Direct changes to production are not permitted.
• Automated dependency and vulnerability scanning runs continuously, with static analysis and type checking in the build pipeline. Builds fail on the issues we have agreed to block on.
• Environments are separated. Production data is not used in development or test. Synthetic or pseudonymised data is used for evaluation and development wherever practicable.
• Infrastructure is defined as code and reviewed in the same way as application code.
• Patching follows severity based timelines, with critical vulnerabilities addressed on an expedited basis.

6. Logging, monitoring and auditability

• The application audit trail is append only. Every state change records the actor, the timestamp, the change and the prior value.
• Infrastructure and application logs are centralised, access controlled and retained in line with the retention agreed with each customer.
• Alerting covers availability, error conditions and defined security events.

7. Artificial intelligence governance

• Customer data is never used to train, fine tune or otherwise improve any model, ours or a third party’s. Model providers are engaged under terms that prohibit training on submitted content.
• The platform does not automatically accept, decline, price or bind risk. Every AI output is a proposal placed in front of an accountable human.
• Generated and extracted values carry a confidence score and a citation to the source material, so output can be verified rather than trusted.
• The AI layer is abstracted from any single provider, so models can be substituted, regionally restricted or removed to meet customer sovereignty, procurement and model risk requirements.
• Prompts carry only the data required for the task, and personal data is minimised.
• Model interactions are logged so that any AI assisted output can be reconstructed and explained after the event.

8. Resilience and continuity

• Automated backups are taken on a defined schedule, encrypted, and restoration is tested.
• Recovery point and recovery time objectives are agreed with each customer and set out in the services agreement.
• Source code escrow and continuity arrangements are available, so that a customer’s ability to operate is not dependent on the continued existence of any single supplier.

9. Suppliers

Sub processors and material suppliers are assessed before appointment and reviewed periodically. They are engaged under written contract with confidentiality, security and data protection obligations equivalent to those we owe our customers. We maintain a current sub processor list, available on request, and we do not appoint a new sub processor handling customer personal data without the customer’s prior authorisation.

10. Personnel

Employees and contractors are subject to background screening appropriate to their role and to written confidentiality obligations. Security awareness training is provided at onboarding and refreshed periodically. Access is removed as part of a documented leaver process.

11. Incident response

• We maintain a documented incident response process covering detection, triage, containment, eradication, recovery and post incident review.
• Customers are notified promptly and in writing of any incident affecting their data, with the detail available at the time and updates as the investigation progresses.
• Where an incident is a personal data breach, we support the controller in meeting regulatory notification obligations within the applicable timeframes.
• Specific notification commitments and service levels are set out in each services agreement.

12. Vulnerability disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability in this website or in our platform, please tell us through our contact form, marking your message for the security team, and give us reasonable time to investigate and remediate before any public disclosure. Please do not access, modify or delete data belonging to others, degrade our services, or use social engineering against our people or customers. We will acknowledge your report, keep you informed, and we will not pursue action against researchers who act in good faith and within these limits.

13. Review

This policy is reviewed at least annually and whenever there is a material change to our architecture, our supplier base or the regulatory environment in which our customers operate.