Security and privacy.

1. Who can get in

1.1 Accounts

A school creates its own nOS account, and its administrators invite colleagues by email. There are two roles inside a school: member and administrator. The invitation is the only way into an existing school's account, and administrators can remove a person at any time. The only other role is nOS staff, described below.

1.2 Signing in

People sign in with a password or with their Google account. Passwords are stored only as one-way hashes, must be at least ten characters, and are checked against lists of passwords exposed in public breaches. nOS does not offer multi-factor sign-in today. A school whose Google accounts require multi-factor authentication can have its people sign in with Google to get that protection. Sign-in attempts are rate-limited, and repeated failures are logged and flagged.

1.3 Sessions

A signed-in session ends after a period of inactivity, which the school chooses in Settings (from 15 minutes up to 8 hours; 12 hours if it does not choose). Changing a password ends every other session, and people can see and end each signed-in device in Settings.

1.4 nOS staff

nOS is a small company. The only person with access to production systems and to a school's data is the founder. That access is used only to give support, or to keep the service running, never to read a school's data out of curiosity. When staff view a school's account, the use is recorded in the nOS audit log, with the reason. We do not currently hold staff training or background-check programs, because there are no other staff; the founder is bound by the confidentiality terms in our agreements.

2. How data is protected

2.1 In transit

Everything between a browser and nOS travels over TLS, with HTTPS enforced by strict transport security.

2.2 At rest

The database and the stored files are encrypted at rest by our providers, Neon and Vercel. Credentials a school gives us for its student information system are additionally encrypted by nOS with AES-256-GCM before they are stored, and links we send to students are stored sealed.

2.3 School separation

Each school's data is kept apart from every other school's. That separation is enforced in nOS's own code on every request: each query is tied to the school and the person making it, and automated checks fail a release that tries to read data without that scope. It is an application-level control; it is not a separate database for each school.

2.4 The database

The production database is reachable only with credentials, over an encrypted connection. nOS runs with a limited database role that cannot change the database's structure; changes to the structure are made through a separate release step.

2.5 Student information systems

When a school connects its student information system (SIS), nOS fetches only from the address the school entered, and every such request is checked so that it cannot be pointed at nOS's own internal network. nOS writes back to the SIS only when the school asks, and only after the school has reviewed what will be written.

2.6 Live collaboration

When several people work in a school's account at once, their live messages (who is online, where their cursor is, what they are following) are encrypted in the browser with a key unique to that school before they leave it. Our realtime provider, Ably, carries only ciphertext and keeps no history. Ably is a UK company and may route that ciphertext outside the United States. A school that would rather not use it can ask us to turn live collaboration off.

3. Hosting and recovery

3.1 Where it runs

nOS runs on cloud infrastructure in the United States, from the providers listed in section 6.

3.2 Backups

Our database provider, Neon, keeps point-in-time backups of production data. We have not yet rehearsed a full restore from them, so we do not claim a recovery time. We are scheduling a restore test, and will update this page when it is done.

3.3 Updates

Dependencies are audited for known vulnerabilities before each release, and a release is blocked when a serious advisory affects production code. Critical fixes ship first.

4. How we build

Every change goes through automated checks before it is released: type checking, linting, a large automated test suite, a secret scan and a check of the dependency list. These checks are the review of record; we are a one-person engineering team and do not claim a second human reviewer on each change. Releases are made by one script, from a clean, tagged copy of the code, and checked after they go live.

5. If something goes wrong

nOS monitors for unusual activity, including repeated sign-in failures, and raises an alert to the founder. If a school's data is affected by a security incident, we will notify the school's administrators no later than 72 hours after we confirm the incident, say what we know, and help the school meet its own notice duties. To report a vulnerability, write to bennettmiller@nosplanner.com.

6. Subprocessors

nOS uses a small number of companies to run the service: Vercel (hosting and file storage), Neon (database), Anthropic (nOS AI), Ably (live collaboration), Upstash (rate limiting), an email provider, Stripe (billing, no student data), Google (optional sign-in) and Sentry (error monitoring). What each does, the data it can reach and where it is located is on our Subprocessors list. If we add a company that handles student data, schools get advance notice as set out in the Data Processing Agreement.

7. Certifications

nOS does not hold SOC 2, ISO 27001 or any other certification of its own, and has not had an independent penetration test. Our hosting and database providers hold their own audits. We complete security questionnaires for schools that need them, and we will walk your IT team through any of this directly.

8. Contact

Security, privacy and data-processing questions: bennettmiller@nosplanner.com. See also the Privacy Policy, Data Processing Agreement and all legal documents.

Last reviewed October 4, 2026. We update this page when our practices change.