Otaly maps its security program to industry-recognized frameworks and publishes formal audit materials when they are available. Current control areas include:

• SOC 2 security, availability, and confidentiality criteria as a control baseline.
• ISO/IEC 27001-aligned information security management practices.
• GDPR and UK GDPR — data protection by design and default, Standard Contractual Clauses for international transfers, and a Data Processing Addendum available on request.
• CCPA/CPRA — rights for California consumers and contractual flow-down to subprocessors.
• PCI DSS — handled via PCI-certified payment processors so that Otaly never stores raw card data.

Security summaries, audit reports, and penetration-test summaries are shared under appropriate confidentiality terms when available.

• Otaly runs on enterprise-grade cloud infrastructure with isolated production environments, hardened base images, and infrastructure-as-code change management.
• All production data is encrypted at rest using AES-256 and in transit using TLS 1.2+ with modern cipher suites.
• Network access to production is restricted via private networks, security groups, and a zero-trust authentication layer that enforces device posture and short-lived credentials.
• We maintain continuous logging, monitoring, and alerting across infrastructure and application layers, with retention aligned to compliance and forensic needs.

• We follow the OWASP ASVS and OWASP Top 10 as baseline application-security requirements.
• Code is reviewed by a second engineer before merging to main. Security-sensitive changes require an additional reviewer from our security team.
• Static application security testing (SAST), software composition analysis (SCA), and secret-scanning run on every pull request.
• Dynamic application security testing (DAST) and authenticated scans run continuously against staging.
• An independent third party performs a penetration test of Otaly at least annually, and after major architectural changes.

• Customer data is logically isolated and tagged so we can apply the right retention, residency, and access policies.
• Sensitive fields (e.g., authentication secrets and integration tokens) are encrypted at the field level using a managed key service.
• Backups are encrypted, geographically replicated, and tested for restorability on a regular cadence.
• Data deletion: when you delete content or your account, we propagate deletion to backups within 90 days, except where retention is required by law.

• Customer content sent to AI subprocessors is governed by data processing agreements that prohibit training on your data.
• Prompts and outputs are isolated per workspace; we do not blend customer data across tenants.
• We monitor AI features for prompt-injection patterns, abusive content, and unsafe tool-use, and we restrict the actions AI agents can take on a Host’s behalf.
• Hosts can disable AI features at the workspace or event level.

• Multi-factor authentication (MFA) is available for all accounts and required for administrators.
• Single sign-on (SSO) via SAML 2.0 and OpenID Connect is available on Enterprise plans, with optional SCIM user provisioning.
• Internal access to production data follows least-privilege and just-in-time principles. All access is logged and reviewed.
• Otaly employees use hardware-backed phishing-resistant authenticators for production access.

• Otaly is designed for high availability with multi-zone deployments and automated failover.
• We publish a real-time status page and announce incidents transparently.
• Recovery objectives: RPO ≤ 1 hour and RTO ≤ 4 hours for Tier-1 services; tested at least annually.

We carefully review all subprocessors before engaging them and require them to maintain security and privacy controls equivalent to ours. Our current list of subprocessors is available on request and is updated when we add a new one. Enterprise customers can subscribe to subprocessor change notifications.

Otaly maintains a documented incident-response plan that is tested regularly. In the event of a security incident affecting customer data, we will: (a) investigate promptly; (b) contain and remediate the issue; (c) notify affected customers without undue delay and within the timelines required by law; and (d) provide a written incident report to affected customers.

We welcome reports from security researchers. If you believe you have discovered a vulnerability in our Services, use the contact form and include “security report” in your message. We aim to acknowledge good-faith reports within two business days and to keep researchers informed as we investigate. We will not pursue legal action against researchers who follow this policy in good faith and avoid privacy violations, service disruption, or destruction of data.