Security

1. Overview

Nami stores performance reviews, calibration grades, feedback, goals, and survey data on behalf of your organization. We take the confidentiality, integrity, and availability of that data seriously. This page is a deliberately honest description of what we do today, what infrastructure we rely on, and what is still on our roadmap. We will not claim certifications we do not have.

For how we collect and use personal data, see our Privacy Policy. For contractual terms, see our Terms of Service.

2. Infrastructure

We do not operate our own data centers. Nami runs on third-party cloud infrastructure whose security programs are independently audited. Each provider's certifications cover the layer of the stack that provider runs; certifications of subservice organizations are not certifications of Nami itself.

• Application hosting and edge delivery: Vercel — independently audited under SOC 2 Type II and ISO 27001
• Database, authentication, and edge functions: Supabase, running on Amazon Web Services — Supabase is independently audited under SOC 2 Type II
• Underlying cloud: Amazon Web Services — SOC 1, SOC 2 Type II, SOC 3, ISO 27001, ISO 27017, ISO 27018, PCI DSS, and many other attestations

Attestation reports from these providers are available directly from them, generally under NDA.

3. Data Residency

Our primary database is hosted in the European Union (Ireland, AWS region eu-west-1). All Customer Data — reviews, ratings, calibration grades, feedback, goals, surveys, audit log entries, and workspace configuration — lives there.

Our application and edge functions run on Vercel and Supabase edge networks that may terminate TLS at points of presence around the world for performance. Customer Data is only processed in memory at those edge points for the duration of the request; persistent storage is the EU database described above. Subprocessors such as Slack, Stripe, and Google process limited categories of data in the United States or other jurisdictions as described in our Privacy Policy.

4. Encryption

• In transit: All traffic to and from Nami is encrypted with TLS 1.2 or higher. HTTP traffic is redirected to HTTPS. HSTS is enabled on our production hostnames.
• At rest: All Customer Data is encrypted using AES-256 at the storage layer, including database contents and automated backups.
• Secrets: Application secrets (OAuth client secrets, signing keys, third-party API keys) are stored in managed-secret stores provided by Vercel and Supabase and are injected as environment variables. Secrets are never committed to source control.
• Keys: Encryption-key material is managed by our infrastructure providers (AWS KMS, Vercel, and Supabase). We do not store or manage raw key material ourselves.

5. Authentication

• Slack OAuth 2.0: Users sign in exclusively through Slack. We do not store user passwords.
• Multi-factor authentication: If your Slack workspace requires MFA or SSO, that requirement is inherited by Nami sign-in automatically.
• Sessions: Sessions are managed through short-lived, signed tokens issued by Supabase Auth and stored in HTTP-only, Secure, SameSite cookies.
• OAuth state: OAuth state parameters are signed with an HMAC secret and verified on the callback to prevent cross-site-request-forgery attacks against the install flow.
• Slack bot tokens: Slack bot tokens have a 12-hour TTL and are auto-rotated by our refresh routine. Tokens are stored server-side only and are never exposed to the browser.
• Webhook signature verification: Slack events, interactivity, slash commands, and Stripe webhooks are cryptographically verified using HMAC signatures with constant-time comparison before any side-effect.

6. Access Control and Tenant Isolation

Each workspace's data is isolated at the database layer. A user from one workspace cannot read or modify data belonging to another workspace, regardless of the request path.

• Row-level security (RLS): PostgreSQL RLS policies are enforced on tables that hold Customer Data. Policy checks run inside the database engine, not in application code.
• Cross-tenant validation triggers: Database triggers reject writes that would associate a record with a workspace the acting user does not belong to.
• Role-based access inside a workspace: Admin, HR, Manager, and Employee roles limit what each user can see and do. Grade releases, calibration data, private calibration notes, and HR-only views are gated at the database layer.
• Anonymous responses: Anonymous survey and feedback authors are stored as a workspace-scoped pseudonym; authorship is not surfaced in the dashboard or audit log.
• Principle of least privilege: Internal access to production systems is restricted to authorized personnel and scoped to the minimum needed for their role. Access requires SSO and MFA.

7. Audit Logging

Sensitive state changes are recorded to an in-database audit log and retained for the lifetime of the workspace. Logged events include:

• Performance cycle status transitions (launched, closed, released)
• Calibration grade changes, grade reasons, and grade releases
• User role changes (Admin, HR, Manager, Employee assignments)
• Review assignment changes (assigned, reassigned, removed)
• Goal lifecycle events (created, updated status, archived)

Audit log access is restricted to Admin and HR roles within the workspace that owns the data. Audit log entries are append-only by application logic; they are not exposed through any general data-export endpoint.

8. Backups and Disaster Recovery

• Continuous backups: Our database provider runs continuous point-in-time recovery and daily snapshots. We do not store backups outside the managed provider.
• Backup retention: Backups are retained for up to thirty (30) days, then deleted on a rolling basis. Backup contents are encrypted at rest with AES-256.
• Recovery objectives (target, not contractual): Recovery point objective (RPO) of up to one (1) hour; recovery time objective (RTO) of up to twenty-four (24) hours for the application tier. Enterprise customers may negotiate stricter contractual targets in a separate agreement.
• Multi-region failover: The application tier runs on Vercel's global edge with automatic failover. The database tier runs in a single region; cross-region failover is on our roadmap.
• Backup testing: Restore is tested periodically against non-production environments to validate that backups are usable.

9. Secure Development

• Code review: Every change to the production codebase goes through pull-request review before merge.
• Static analysis: TypeScript strict-mode type checking, ESLint, and CI-level test suites run on every pull request.
• Dependency monitoring: We use automated dependency scanning to alert us to security advisories in third-party packages, and we patch high- and critical-severity advisories on an expedited cadence.
• Secret-scanning: Source control is scanned for accidentally-committed credentials. Detected secrets are rotated immediately.
• Tenant-isolation test coverage: Cross-tenant isolation invariants — that workspace A cannot read or write workspace B's data — are covered by automated tests exercised against the database.
• Production deploys: Production deploys are triggered by merges to the main branch and ship through Vercel with automatic rollback support.

10. Vulnerability Management

• Patch cadence: Critical vulnerabilities in production dependencies are patched within seven (7) days of a fix becoming available; high-severity within thirty (30) days; medium and lower on the normal release cadence.
• Penetration testing: Independent third-party penetration testing is on our roadmap (see Section 13). The summary letter will be available to customers on request.
• Responsible disclosure: We welcome reports from security researchers — see Section 14.

11. Logging and Monitoring

• Application logs: Structured request and error logs are emitted by the application and edge functions, retained for up to thirty (30) days, and available to engineering for incident response.
• Database logs: Database query, connection, and error logs are retained by Supabase per its standard retention policy and surfaced through its dashboard.
• Error alerting: Unhandled errors and unusual rate-of-failure patterns are surfaced via dashboard alerts and routed to engineering on call.
• OAuth-install health probe: A dedicated probe routinely signs and verifies an OAuth state token to confirm the install flow is healthy end to end.

12. Organisational Security

• Endpoint security: Workstations used to develop and operate the Service have full-disk encryption, screen-lock policies, and current operating-system patches.
• SSO + MFA: Administrative access to our infrastructure providers requires SSO and multi-factor authentication.
• Least privilege: Access to production data and infrastructure is granted on a need-to-know basis and revoked when no longer needed.
• Confidentiality: Personnel with access to Customer Data are bound by written confidentiality obligations.
• Incident drills: Internal incident-response runbooks are reviewed periodically.

13. Compliance Roadmap

We are transparent about where we are in our compliance journey. The list below distinguishes what is in place today from what is planned.

• Infrastructure attestations (today): Supabase, Vercel, and AWS are independently audited under SOC 2 Type II and other frameworks. Their attestations cover the hosting, authentication, and storage layers of the Service. They do not, however, attest to Nami itself.
• GDPR / UK GDPR / Swiss FADP (today): A Data Processing Agreement covering Standard Contractual Clauses for international transfers (and the UK International Data Transfer Addendum where relevant) is available to any customer on request via hello@namihr.com. Our primary database resides in the European Union.
• SOC 2 Type II for Nami itself (planned): An independent SOC 2 Type II audit of Nami is on our product roadmap. We will publish the attestation report here once the audit concludes.
• Third-party penetration testing (planned): We plan to commission an annual third-party penetration test and publish a summary letter on request.
• ISO 27001 / HIPAA / PCI DSS / FedRAMP: We do not currently claim ISO 27001, HIPAA, PCI DSS, or FedRAMP certification. If your procurement process requires one of these and you want to discuss it, write to hello@namihr.com.

14. Responsible Disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability in Nami, please email hello@namihr.com with a description of the issue, the steps to reproduce, and any proof-of-concept material.

While testing, please do not: access or modify data belonging to other customers; run automated scanners that generate significant load; perform denial-of-service testing; social-engineer our personnel or vendors; or publicly disclose the issue before we have had a reasonable opportunity to investigate and remediate (we ask for ninety (90) days).

We will acknowledge valid reports within five (5) business days, keep you updated on remediation progress, and credit researchers who wish to be credited. We do not currently operate a paid bug bounty.

15. Incident Response

In the event of a confirmed security incident that results in unauthorized access to, or disclosure of, Customer Data, we will:

• Investigate the nature and scope of the incident promptly
• Contain and remediate the incident
• Notify affected workspace administrators without undue delay and, where GDPR or comparable laws apply, within seventy-two (72) hours of becoming aware of the incident
• Provide a description of the incident, the categories and approximate number of records affected, the likely consequences, and the measures taken or proposed
• Notify relevant data-protection authorities and other regulators where required by applicable law
• Cooperate with affected customers in their own notification and remediation efforts

For the avoidance of doubt, the following are not security incidents requiring notification under this Section: failed login attempts, denied connection attempts, port scans, automated probe traffic, and other unsuccessful probes that do not compromise the confidentiality, integrity, or availability of Customer Data.

16. Your Side of the Shared-Responsibility Model

Security is a shared responsibility. The controls described above are the controls we operate. You are responsible for:

• Configuring strong controls in Slack itself, including MFA, SSO where available, session length, and idle timeout
• Granting Admin and HR roles in Nami only to people who need them, and revoking them promptly when responsibilities change
• Promptly deactivating Slack users when employees leave so they lose Nami access automatically
• Reporting suspected compromise of your account or any unusual activity to hello@namihr.com without delay
• Maintaining your own backups of any Customer Data you consider critical, using the CSV-export features in the dashboard
• Ensuring your use of the Service and any data your users submit complies with the laws of the jurisdictions where you operate