LEGAL CENTER

SECURITY

Security Statement

The safeguards and operational boundaries used to protect Corporate Suite, the responsibilities customers retain, and the correct path for reporting a vulnerability.

Effective
August 3, 2026
Last updated
August 3, 2026
01

Security program

Corporate Suite uses a risk-based security program designed to protect the confidentiality, integrity, and availability of customer data. Security responsibilities are assigned across product, application, infrastructure, and operational owners. Safeguards are reviewed as the Service, threats, and legal requirements evolve.

This statement describes our baseline; it is not a certification, warranty, penetration-test report, or service-level agreement. We do not claim SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP, or another certification unless it is expressly documented in a signed agreement or current audit report.

02

Infrastructure and isolation

  • Production workloads and primary data services are defined through reviewed infrastructure as code in an approved AWS region.
  • Application and database services use private network boundaries where practical, with public traffic routed through managed edge, load-balancing, and web-application controls.
  • Workspace and organization identifiers are enforced at service authorization boundaries. Browser state is not treated as durable authorization truth.
  • Production databases, object storage, logs, queues, and secret containers use managed encryption controls appropriate to the service.
03

Encryption and secrets

  • Public application traffic is redirected to HTTPS, and production APIs require encrypted transport.
  • Production relational storage and declared object/log stores are encrypted at rest with managed keys.
  • Credentials, signing material, provider keys, and encryption secrets are kept in server-side secret stores and are not intentionally shipped in browser bundles.
  • Session cookies use security attributes appropriate to their cross-domain purpose, including secure transport and HTTP-only handling for session secrets.
04

Identity and access

  • Access follows least-privilege, role-based, and workspace-scoped authorization principles.
  • Production access is limited to authorized personnel and automated roles with a business or operational need.
  • Administrative, deployment, and runtime identities are separated, and production releases use exact-version, review-gated workflows.
  • Workspace administrators remain responsible for membership, role, connector, sharing, and retention choices available to them.
05

Secure development and release

  • Repository changes are reviewed and pass scoped quality and security checks before production eligibility.
  • Production artifacts are immutable, tied to an exact source revision, and scanned for high and critical image vulnerabilities before release.
  • Infrastructure changes use a reviewable, sealed plan; direct manual repair around infrastructure ownership is prohibited.
  • Dependencies and application boundaries are tested according to their risk, including authorization, tenant isolation, billing, and destructive-action contracts.
06

Logging, monitoring, and resilience

  • Services emit structured operational and security telemetry into access-controlled, retention-bounded systems.
  • Management activity, application health, infrastructure conditions, and selected security findings are monitored and alerted.
  • Production data services use backups, deletion protection, and documented recovery procedures; recovery evidence is distinct from configuration alone.
  • Capacity, releases, migrations, edge routing, and authenticated product behavior are verified as separate operational gates.
07

Incident response

We maintain procedures to identify, contain, investigate, remediate, and learn from suspected security incidents. If we confirm a personal-data breach affecting Customer Content, we will notify the affected customer without undue delay as required by our Data Processing Addendum and applicable law, provide available material information, and reasonably cooperate with the customer's response. Notices may evolve as an investigation develops.

08

Personnel and providers

Personnel with access to confidential information are subject to confidentiality duties and access restrictions. We use service providers only for defined operational purposes, assess them proportionate to risk, contractually restrict covered processing, and publish the providers that may process Customer Personal Data on our Subprocessors page.

09

Customer responsibility

  • Use secure authentication and immediately remove access that is no longer needed.
  • Review workspace roles, public sharing, integration scopes, agent permissions, and high-risk approvals.
  • Protect endpoints and networks, train users against phishing, and avoid sharing credentials.
  • Classify data, minimize sensitive content, configure retention, maintain independent exports where required, and use the Service only for authorized workloads.
  • Promptly report suspicious activity and preserve relevant evidence.
10

Report a vulnerability

Email [email protected] with “SECURITY” in the subject. Include the affected URL or component, reproducible steps, impact, relevant timestamps, and safe evidence. Do not include unnecessary personal data, secrets, or data belonging to another customer.

Act in good faith: avoid privacy violations, persistence, social engineering, denial of service, destructive testing, automated high-volume scanning, or accessing more data than needed to demonstrate the issue. Stop when you encounter customer data and report it. We will not pursue legal action for good-faith research that follows these rules, but this is not authorization to test third-party systems or disrupt the Service. We do not currently promise a bug bounty or payment.