Security

1. Overview

Nami stores performance reviews, feedback, goals, and survey data on behalf of your organization. We take the confidentiality and integrity of that data seriously. This page describes, in concrete terms, how we protect it — what we do today, what infrastructure we rely on, and what is on our compliance roadmap.

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

2. Infrastructure

Nami runs on SOC 2 Type II–attested infrastructure. We do not operate our own data centers; instead, we rely on established providers whose security programs are independently audited.

• Application hosting: Vercel, a SOC 2 Type II and ISO 27001–certified platform running on hyperscale cloud infrastructure
• Database and authentication: Supabase, a SOC 2 Type II–attested platform running on AWS
• Underlying cloud: Amazon Web Services (SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018)

Attestation reports from our infrastructure providers are available directly from them under NDA on request.

3. Encryption

• In transit: All traffic to and from Nami is encrypted with TLS 1.2 or higher. HTTP traffic is redirected to HTTPS.
• At rest: All Customer Data is encrypted using AES-256 at the storage layer, including database contents and automated backups.
• Keys: Encryption keys are managed by our infrastructure providers. We do not store or manage raw key material ourselves.

4. Authentication

• Slack OAuth 2.0: Users sign in exclusively through Slack. We never store user passwords.
• Multi-factor authentication: If your Slack workspace requires MFA, 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 cookies.
• Bot tokens: Slack bot tokens are stored server-side only and are never exposed to the browser.

5. 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: 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, and HR-only views are gated at the database layer.
• Principle of least privilege: Internal access to production systems is restricted to authorized personnel, scoped to the minimum needed for their role.

6. 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
• Calibration grade changes and grade releases
• User role changes
• Review assignment changes

Audit log access is restricted to Admin and HR roles within the workspace that owns the data.

7. Subprocessors

We use the following subprocessors to deliver the Service. All are contractually obligated to process data only on our instructions and to maintain appropriate security controls.

We notify workspace administrators at least thirty (30) days before adding or replacing a subprocessor that processes Customer Data.

8. Data Handling

• Minimization: We collect only what is needed to deliver the Service — names, email addresses, Slack IDs, and the performance content users choose to submit. We do not collect IP addresses for profiling, device fingerprints, biometric data, or location data.
• Retention: Customer Data is retained for the life of your subscription, then purged from production within 30 days of termination. Backups containing your data are retained for up to an additional 30 days before permanent deletion.
• Export: Workspace administrators can export review, feedback, goal, and survey data in CSV format directly from the dashboard.
• Deletion: Workspace administrators can request deletion of their workspace or of specific user records by emailing hello@namihr.com.
• AI training: We do not use Customer Data to train AI or machine learning models without the workspace administrator's explicit prior written consent.

9. Compliance Roadmap

We are transparent about where we are in our compliance journey. Below is an accurate picture of our current posture.

• Infrastructure attestations (today): Nami inherits SOC 2 Type II attestation from Supabase, Vercel, and AWS as subservice organizations. These attestations cover the hosting and data-storage layer of the Service.
• GDPR (today): A Data Processing Agreement covering Standard Contractual Clauses for international transfers is available to any customer on request via hello@namihr.com.
• SOC 2 Type II (planned): An independent SOC 2 Type II audit of Nami itself 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.

We do not currently claim HIPAA, PCI DSS, ISO 27001, or FedRAMP compliance. If your procurement process requires one of these and you want to discuss it, write to hello@namihr.com.

10. 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 applies, 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, likely consequences, and the measures taken or proposed
• Cooperate with affected customers in their own notification and remediation efforts

Failed login attempts, denied connection attempts, port scans, and other unsuccessful probes are not incidents for the purposes of this section.

11. 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 and steps to reproduce.

While reviewing our Service, please do not: access or modify data belonging to other customers; run automated scanners that generate significant load; perform denial-of-service testing; or publicly disclose the issue before we have had a reasonable opportunity to investigate and remediate.

We will acknowledge valid reports, keep you updated on remediation progress, and credit researchers who wish to be credited.