Purpose and scope
This policy defines how Nexma protects the confidentiality, integrity, and availability of information processed by the Nexma platform — including customer-supplied spatial data stored in the Codex, account and authentication data, audit logs, and the systems used to operate the service.
It applies to all employees, contractors, and third parties who access Nexma systems or data, and to all environments — production, staging, and development — owned or operated by Nexma.
Roles and responsibilities
Security ownership is distributed but accountable. The following roles operate under this policy:
- Chief Executive — Owns the overall security posture of the company and approves this policy. Final accountability for material security decisions.
- Security Lead — Day-to-day owner of the security program. Maintains this policy, runs the access review and incident response programs, and reports posture to leadership.
- Engineering — Implements controls in the platform, performs code review and dependency hygiene, responds to security findings, and operates production infrastructure.
- All personnel — Complete security training on onboarding and annually thereafter. Report suspected incidents or policy violations promptly to the Security Lead.
Risk management
Nexma maintains a written inventory of risks to customer data and platform availability. Each risk is reviewed at least annually and after material changes — new vendors, architectural shifts, or significant incidents.
Risks are scored by likelihood and impact, with treatment decisions (mitigate, transfer, accept) recorded alongside the risk. The Security Lead reviews the risk register with leadership quarterly.
Asset management
Nexma classifies the assets it processes and applies controls proportional to their sensitivity:
- Customer content — Project data, spatial datasets, conversation history, and uploaded files belonging to customers. Treated as confidential and never used to train models without explicit consent.
- Codex storage — The Codex is the persistent file system that holds customer project state. Codex data is logically isolated per organization and stored in encrypted, access-controlled storage.
- Authentication material — API keys, tokens, signing secrets, and database credentials. Stored in a managed secret store, never in source control, and rotated on the schedule defined below.
- Personnel endpoints — Laptops used by Nexma personnel are required to have full-disk encryption, an active screen lock, and managed automatic updates.
Access control
Nexma applies least-privilege access controls across all systems, with multi-factor authentication required for administrative roles. The full access control program is described in the Access Control Policy.
Cryptography
Nexma uses industry-standard cryptography to protect customer data in storage and in transit:
- Data at rest — Customer data is stored in managed Postgres (Supabase) with AES-256 encryption at rest. Object storage uses provider-managed encryption with rotating keys.
- Data in transit — All connections to Nexma services require TLS 1.2 or higher. HTTP traffic is redirected to HTTPS, and HSTS is enabled on public endpoints.
- Key management — Application secrets and database credentials are stored in the platform secret store and accessed by services at runtime. Keys are rotated at least annually and on personnel change.
- Authentication secrets — Customer authentication is handled by Clerk; Nexma does not store customer passwords. Service-account tokens are hashed and stored salted.
Physical and environmental security
Nexma operates as a cloud-native service and does not maintain its own data center. Physical security of underlying infrastructure is the responsibility of subprocessors — primarily Vercel, Supabase, and Railway — each of which maintains SOC 2 or equivalent attestations covering physical access controls, environmental protection, and media disposal.
For Nexma personnel, work happens on managed endpoints. Office spaces (where present) require badge access and visitors are escorted at all times.
Operations security
Day-to-day platform operations follow documented procedures designed to prevent unauthorized change and detect deviation:
- Change management — Production changes are made via pull request, require at least one peer review, and pass automated tests and linting before merge. Emergency changes are documented and reviewed retroactively.
- Backups — Customer-bearing databases are backed up daily with point-in-time recovery for at least seven days. Backups are encrypted and stored separately from production.
- Logging — Authentication events, administrative actions, and security-relevant errors are logged. Application logs are retained for at least 90 days; audit logs for longer (see the Data Retention Policy).
- Monitoring and alerting — Uptime, error rates, and key performance metrics are continuously monitored. Anomalies trigger alerts to the on-call rotation.
- Patch and vulnerability management — Dependencies are tracked, scanned for known vulnerabilities on each build, and updated on a regular cadence. Critical patches are applied promptly.
Communications security
Internal communications use end-to-end encrypted channels where customer data may be discussed. External communications about security topics — including incident disclosures — go through the Security Lead.
Public security disclosures are coordinated through security@nexma.ai and follow the timelines defined in the Incident Response Policy.
System development and maintenance
Security is integrated into the development lifecycle through tooling and review:
- Peer code review — All changes to production code require pull request review. Reviewers are expected to consider security implications, not only functional correctness.
- Dependency scanning — Third-party dependencies are scanned on each build for known vulnerabilities. Findings above a defined severity threshold block release until remediated or accepted.
- Secret scanning — Repositories are scanned for accidentally committed secrets on each push. Detected secrets are rotated immediately.
- Automated testing — Unit, integration, and end-to-end tests run on every change. Authentication, authorization, and tenant-isolation paths have dedicated coverage.
Supplier relationships
Vendors and subprocessors that handle customer data are reviewed before onboarding, monitored over time, and listed publicly. Full requirements are documented in the Vendor Management Policy.
Incident management
Security incidents are detected, classified, contained, and disclosed according to the Incident Response Policy.
Compliance
Nexma is actively building toward SOC 2 Type II readiness. We do not currently hold a SOC 2 report; the controls described in this policy reflect the state of the program as we work toward audit.
Where applicable, Nexma also aligns with GDPR, CCPA, and Israeli privacy law obligations as described in the Data Processing Agreement.
Policy review
This policy is reviewed at least annually by the Security Lead and approved by the Chief Executive. Material changes are recorded in the version history and communicated internally before taking effect.
Contact
Questions about this policy, or about Nexma's security program more broadly, can be sent to legal@nexma.ai.