# Security and trust

> How Naven protects the service and the information in it, set against the two frameworks organizations ask about — SOC 2 and ISO/IEC 27001 — and marked honestly: in place, partial, or not yet.

- Page: https://navenapp.com/trust
- Last updated: 2026-10-08
- Published by: Naven, a free messaging app that runs in a web browser (https://navenapp.com/about)

- **SOC 2:** Not audited — readiness below
- **ISO/IEC 27001:** Not certified — readiness below
- **In transit:** HTTPS only, TLS 1.2+, HSTS
- **Operator access:** Code, passkey and password
- **Report a problem:** [security@navenapp.com](mailto:security@navenapp.com)
- **Certification:** None claimed

## Where Naven stands

**Naven has not been audited for SOC 2 and is not certified to ISO/IEC 27001, and it shows no badge for either.** A SOC 2 report is written by an independent CPA firm after it tests controls over a period; ISO 27001 certification is issued by an accredited certification body. Neither has happened. This page is the preparation: every control below describes what Naven actually does today, with the part of each framework it answers, so an auditor — or a school or company reviewing Naven — can see exactly what exists and what does not. It is a description of practice, not a warranty or a promise ([Terms §11](https://navenapp.com/terms#no-promises)).

Of the 24 controls below: **11 in place**, **9 partial**, **4 not yet**.

## Controls, framework by framework

SOC 2 references are to the 2017 Trust Services Criteria (revised points of focus, 2022). ISO references are to ISO/IEC 27001:2022 Annex A.

| Control | What Naven does | SOC 2 | ISO 27001 | Status |
| --- | --- | --- | --- | --- |
| Security policy | The policies on this page, published and dated, reviewed whenever the service changes. | CC1.1, CC5.3 | A.5.1 | Partial |
| Roles and governance | One operator runs Naven. There is no board, security committee or segregation of duties yet. | CC1.2–CC1.5 | A.5.2, A.5.3 | Not yet |
| Risk assessment | Risks are handled as they are found and recorded in the code history; there is no formal, periodic risk register. | CC3.1–CC3.4 | Clause 6.1, 8.2 | Not yet |
| Operator sign-in | The operator console needs a code emailed to the operator, a passkey and a password. Sessions end after 2 hours, or 30 minutes idle, and every action carries a CSRF token. | CC6.1, CC6.2 | A.5.15, A.8.5 | In place |
| Member access | Every request is checked against a verified Firebase sign-in; access rules limit each member to their own conversations and data. | CC6.1, CC6.3 | A.5.15, A.8.3 | In place |
| Least privilege for services | Secrets live only in the hosting platform's secret store, never in code; the email key can only send. | CC6.1 | A.8.2, A.5.17 | In place |
| Encryption in transit | HTTPS only; TLS older than 1.2 is refused; HSTS for a year including subdomains. | CC6.7 | A.8.24 | In place |
| Encryption at rest | Data sits with Cloudflare and Google, which encrypt stored data by default. Naven adds no encryption of its own at rest. | CC6.1 | A.8.24 | Partial |
| Call encryption | Direct and relayed calls are encrypted by the browsers (DTLS-SRTP); calls through Naven’s own call server are encrypted by the devices (AES-GCM, keys exchanged with ECDH) and passed on by a server that is not given the keys; Agora calls are encrypted with a key Agora is never given. None of these is end-to-end verified. | CC6.7 | A.8.24 | In place |
| Boundary protection | Clickjacking and framing blocked; rate limits on sign-in, reports and forms; origin checks on real-time connections. | CC6.6 | A.8.20, A.8.23 | In place |
| Malicious content | Messages, pictures and voice notes are screened before they send; uploaded pictures are stripped of location data. | CC6.8 | A.8.7 | Partial |
| Monitoring | Service health is probed every five minutes; every error members hit is counted without identifying anybody, and shown to the operator. | CC7.2 | A.8.15, A.8.16 | Partial |
| Incident response | The plan below. Schools with a data processing agreement are told of a breach affecting their data within 72 hours. | CC7.3–CC7.5 | A.5.24–A.5.28 | Partial |
| Vulnerability reports | Reports go to security@navenapp.com and are answered by a person. | CC7.1 | A.8.8 | Partial |
| Penetration testing | No independent penetration test has been done. | CC4.1 | A.8.8 | Not yet |
| Change management | Every change is a commit in version control, checked by automated test suites, and deployed only from a clean copy of what was committed. | CC8.1 | A.8.32, A.8.25 | In place |
| Secure development | Security reasoning is written beside the code it protects; regression tests cover consent, deletion, the console, screening and layout. | CC8.1 | A.8.25–A.8.29 | In place |
| Vendors and sub-processors | Every outside service is listed, with what it receives and its own policy, at [/subprocessors](https://navenapp.com/subprocessors). Formal vendor reviews are not done. | CC9.2 | A.5.19–A.5.23 | Partial |
| Backups and recovery | Naven's own database on Cloudflare keeps a point-in-time history that can be restored. The Google database has no backup on its free plan. | A1.2, A1.3 | A.8.13, A.5.30 | Partial |
| Availability | A public status page; the service runs on Cloudflare's network with no single server to fail. | A1.1 | A.8.14 | In place |
| Data retention and deletion | Every kind of data has a published retention period; deleting an account removes it from every table, file store and sign-in. | C1.2, P4.3 | A.8.10, A.5.34 | In place |
| Privacy notice and choice | A detailed privacy policy, a children's notice, and verified parental consent for under-13s. | P1–P3 | A.5.34 | In place |
| Business continuity | No written continuity plan beyond the recovery steps below, and production credentials are held by the founder alone. | A1.2 | A.5.29, A.5.30 | Not yet |
| Security awareness | The operator is the only person with access. There is no staff training programme because there is no staff. | CC2.2 | A.6.3 | Partial |

## Policies

### Information security

Naven collects only what the [privacy policy](https://navenapp.com/privacy) lists, keeps it for the periods it gives, and restricts access to the one operator and to the services named on the [sub-processors page](https://navenapp.com/subprocessors). Secrets are stored only in the hosting platform's secret store. Nothing about a member is kept in their browser beyond what section 8 of the privacy policy lists.

### Access control

Only the operator can reach member data outside the app, through a console that needs three things: a code emailed to the operator, a registered passkey, and a password. Console sessions end after two hours, or after thirty minutes without use. Service credentials are scoped to what each job needs.

### Incident response

- **Contain:** pause the affected feature (the console has switches for sending, calls and sign-ups) and rotate any exposed secret.
- **Assess:** establish what data, which accounts and which period were affected, from the service's own logs.
- **Notify:** tell affected members, and parents for children, without undue delay; tell schools and organizations within 72 hours where their agreement says so; tell regulators where the law requires.
- **Fix and record:** correct the cause, add a test that would have caught it, and write down what happened.

### Change management

Every change is committed to version control with a description of why, checked by the relevant automated test suites, built, and deployed only from a clean copy of the committed code. Changes that affect what the privacy policy or terms say update those pages in the same change.

### Backup and recovery

Naven's own database can be restored to an earlier point in time. Uploaded files are stored with Cloudflare. The conversation database at Google has no backup on the free plan, which is recorded as a gap above.

### Vendor management

An outside service is added only when Naven needs it, is listed publicly with what it receives before it receives it, and is removed from the list when it is no longer used.

### Vulnerability disclosure

Report a security problem to [security@navenapp.com](mailto:security@navenapp.com) with enough detail to reproduce it. Please do not access other people's data, degrade the service, or test against accounts that are not yours. Naven does not pursue good-faith researchers who follow these rules, and does not offer paid rewards.

## Before an audit

What would have to exist before a SOC 2 Type I audit or an ISO 27001 certification could reasonably start:

- A legal entity to be audited and to sign agreements, rather than an individual.
- A written risk assessment and risk register, reviewed at least yearly.
- Backups for the conversation database, and a tested restore.
- An independent penetration test, and fixes for what it finds.
- A second person with emergency access, so continuity does not rest on one.
- Written reviews of the main vendors' own reports (Cloudflare and Google publish SOC 2 reports).
- Log retention long enough to cover an audit period.

© 2026 Naven · [Privacy](https://navenapp.com/privacy) · [Terms](https://navenapp.com/terms) · [Compliance](https://navenapp.com/compliance) · [security@navenapp.com](mailto:security@navenapp.com)

Last updated 2026-10-08