Twynity

Twynity Security Overview

How 4th-IR Group AG protects the Twynity platform and your data — April 2026

Security is a product feature. Twynity processes voice, facial imagery and the biometric identifiers derived from them. These are among the most sensitive categories of personal data, and once exposed, they cannot be reissued. The Twynity platform is built to protect them through a layered set of technical, organisational and contractual controls. This overview summarises the most important ones. It is intended for prospective users, customers and their security teams, and is kept deliberately short; a fuller description is available to enterprise customers under NDA.

1. How we think about security

Three principles drive our security posture:

  • Least privilege. People and systems see only what they need to do their job. Nothing more.
  • Separation. Biometric data, the live-consent vault, and the operational Twyn environment are segregated so that compromise of one does not cascade into the others.
  • Defence in depth. Multiple independent controls at each layer — so a single failure is not a breach.

2. Infrastructure

The Twynity platform is hosted on enterprise-grade cloud infrastructure in Switzerland, the European Economic Area and the United States, provided by AWS and Microsoft Azure. These providers are independently certified to international security standards (including ISO/IEC 27001 and SOC 2 Type II). We build on top of that baseline with our own security engineering.

3. Data protection

  • Encryption in transit. All data moving between you, the Twynity platform and our subprocessors is protected with TLS 1.2 or higher.
  • Encryption at rest. All data stored by Twynity is encrypted at rest using AES-256 or equivalent.
  • Key management. Cryptographic keys are managed in cloud HSMs with strict access controls and automated rotation.
  • Segregated biometric storage. Voice samples, facial imagery, derived identifiers and Twyn models are stored in an environment that is logically separated from general account data and from session-interaction data.
  • Live-consent vault. The on-camera consent recording used to evidence your consent is held in a separate, access-restricted compliance vault. It is not used for any operational purpose.

4. Access control

  • Role-based access. Every access is tied to a named role with a defined need-to-know. No one has standing access to biometric data.
  • Multi-factor authentication. Required for all 4th-IR personnel accessing production systems.
  • Hardware-backed privileged access. Privileged actions in production require a hardware security key and are logged.
  • Just-in-time access. Access to sensitive environments is granted time-limited, with approval and an audit record.
  • Access logging and review. All access to biometric data and to the live-consent vault is logged and reviewed periodically.

5. Application security

  • Secure software development lifecycle. Peer code review, static analysis, dependency scanning and security testing before release.
  • Secrets management. No credentials in code or configuration files; secrets held in managed vaults.
  • Regular vulnerability scanning. Continuous scanning of both infrastructure and application dependencies.
  • Third-party penetration testing. At least annually, and after any major architectural change, by an independent security firm.
  • Red-team exercises on the consent flow. Deliberate attempts to bypass liveness, face-match, voice-match and phrase-match, to harden the most sensitive enrolment step.

6. Operational security

  • Network segmentation. Production environments are isolated from corporate networks; sensitive workloads run in private subnets.
  • Monitoring and detection. Centralised logging, anomaly detection, and alerting on suspicious activity.
  • Backup and recovery. Encrypted backups; tested recovery procedures; documented recovery objectives.
  • Business continuity. Written continuity plan covering people, process and systems, tested at least annually.
  • Personnel security. Background checks where permitted by law; confidentiality and security training on joining and at least annually thereafter.

7. Subprocessor security

Every subprocessor that processes personal data on our behalf is bound by a written data processing agreement requiring security measures at least equivalent to our own. We select subprocessors only where they hold recognised third-party security certifications (typically SOC 2 Type II and/or ISO/IEC 27001) and where their contract gives us audit rights. The current subprocessor list is published at [twynity.ai/legal/subprocessors — URL to be confirmed].

8. Incident response

We maintain a documented incident response process aligned with GDPR Articles 33 and 34. If we identify a personal data breach that is likely to affect you, we will:

  • notify the relevant data-protection authority within 72 hours, where required by law;
  • notify affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms;
  • investigate and document the incident; apply remediation; and review our controls to reduce the chance of recurrence.

9. Transparency to interlocutors

When a Twyn interacts with a third party in real time, the platform makes clear to that person that they are interacting with an AI-driven Virtual Persona, in line with the EU AI Act's transparency requirements. Users cannot disable these transparency features, and attempts to circumvent them are treated as a security and policy incident.

10. Certifications and assurance roadmap

Our certification and assurance roadmap is deliberately paced so that each step is earned, not just ticked. Prospective customers can ask [email protected] for our current state and expected milestones under NDA. We align our design against the EU AI Act, GDPR, the Swiss FADP, the UK GDPR, and applicable US state biometric laws (including the Illinois BIPA).

11. Reporting a security concern

If you believe you have found a security issue affecting the Twynity platform, please contact info@4th-IR.com. We welcome responsible disclosure: we will not pursue legal action against researchers who act in good faith, give us a reasonable time to remediate, and do not access data beyond what is necessary to demonstrate the issue.

12. Further information

Enterprise customers and their security teams can request a fuller security package under NDA, including our Data Protection Impact Assessment, architecture diagrams, penetration test summaries and sub-processor due-diligence records. Contact info@4th-IR.com.

Document control. Twynity Security Overview. Version 1.0 — April 2026. Issued by 4th-IR Group AG, Alpenstrasse 16, 6300 Zug, Switzerland. To be reviewed at least annually and following any material architectural change.

Related documents: Twynity Privacy Policy; Twynity Biometric Data Notice; Twynity Data Protection Impact Assessment; Twynity Subprocessor List; Twynity Platform Terms of Use.