NESA — NESA Security and Data Protection

Terms and Conditions · Privacy Policy · Security and Data Protection

This statement forms part of the NESA Terms and Conditions. It describes how NESA protects your information, what we can and cannot do with it, and the limits you are accepting when you rely on us. Section 19 lists, in our own words, what is still outstanding.

The short version

Your vault is encrypted with keys we do not have. They are derived on your device from your password. We store ciphertext. A full copy of our database, plus every key we possess, yields nothing readable from it.
That guarantee covers your vault. It does not cover the whole product. The emergency layer wrapped around your vault holds real information in the clear, and section 4 lists every field of it. We would rather show you that list than let one true sentence imply a bigger one.
There is no back door, no master key, and no support reset. If you lose your password and your recovery key, your vault is permanently unopenable — by you, by us, by anyone.
Nothing opens all at once. Four rungs, and the bottom two open no vault section at all.
One feature deliberately sends your information out of the encrypted boundary. When you ask Scribe to read a document, that document is decrypted and sent to an outside AI service. It happens only when you ask, only for the document you named. Section 5.
We do not track you. A disclosed location is one reading, taken when a rung opens.

The trade is real and you should see it before relying on NESA: the property that stops an attacker reading your vault also stops us helping you back into it. Save your recovery key somewhere you will still have it in five years. It is the single most important thing you will do in this product.

1. The problem this design solves

NESA has to hold two properties that pull against each other.

Confidentiality. Nobody but you should be able to read your vault — not an attacker, not an insider, not us.

Release. When something happens to you, and you are not there to authorize anything, the right information has to reach the right people quickly.

Most products resolve this by quietly keeping a key. They tell you your data is private and hold the means to read it anyway — for support, for recovery, for "operational reasons". It works, and it means the promise is a policy rather than a fact, and policies can change, be overridden, or be compelled.

NESA resolves it in two moves. First, the cryptography. Your vault is encrypted under a key that exists only on your device, wrapped in ways only you can undo. Second, the ladder. Even with the cryptography right, a system that could only choose between "nothing" and "your medical file" would be forced into bad decisions, so we added rungs below both, where being wrong is close to free.

There is a cost to the second move, and it is the honest subject of section 4: to route an emergency without decrypting anything, the system has to hold some things in the clear.

2. How your vault is encrypted

2.1 The keys

Key	What it does	Where it lives
Your private key	Unwraps the keys to your vault sections and documents	Generated on your device. Stored on our servers only in wrapped form — three wrappings, described below. We never hold it unwrapped, and no server path can unwrap it.
Password wrapping	Lets your password open your private key	Your password is stretched with PBKDF2-SHA256 at 600,000 iterations against a stored salt, and the result wraps your private key with AES-GCM-256. Accounts created before we raised that figure are on 310,000 until the next time that password is set; the parameters travel with each wrapping, so an older one still opens. The server sees the wrapped key and the salt. It never sees your password — the vault password is checked entirely on your device, because the server has nothing to check it against.
Recovery key	A second, independent way to open your private key	A high-entropy key generated on your device, which you are shown once and must save. It wraps your private key the same way. We never see it. If you lose it and your password, nothing can open your vault. If you do not remember being shown one, ask us before you rely on it.
Passkey wrapping	Lets Face ID or a hardware key open your vault	Optional. Uses the passkey standard’s PRF extension to derive a key on your device. The biometric never leaves your phone; we see only a public key.
Section and document keys	Encrypt the actual contents	Each section and document has its own key, encrypted to your public key. This is what makes it possible to open one category to one person without exposing anything else.

Content is encrypted with AES-GCM-256. Keys are wrapped with RSA-OAEP-2048 using SHA-256. Everything in transit runs over TLS. We use the browser’s own audited cryptographic implementations and we do not write our own primitives.

2.2 Two things about changing your password

Changing your password does not revoke anything else. Your recovery key and every passkey you registered wrap your private key directly, not your password, so they keep working. Changing your password is not "revoking the other ways in", and we do not want you to believe it is.
A password reset performed with your recovery key retires that recovery key and issues a new one. Save the new one.

2.3 Locking your vault

If your phone is lost or stolen you can lock your vault. Locking deletes every registered passkey, requires a fresh sign-in, and blocks reads and writes at the database level rather than in the app — so a session already open on the stolen device cannot get past it.

Locking your vault does not close disclosures that are already open. If a rung has opened to somebody, locking does not take it back. Standing down the alert does that. These are two different actions and we would rather say so than have you discover it.

3. What we can and cannot do

We commit to this table contractually.

Our systems	Specifically
The server can do	Store and return ciphertext. Decide whether a rung opens and to whom. Deliver a wrapped key to a person a rung entitles. Write the disclosure record. Enforce a revocation, a lock, or a withdrawal.
The application cannot do	Read your vault sections or your documents’ contents. Unwrap your private key. Reset your vault password or recover your vault. Open a rung to someone you never gave a job to. Widen a disclosure beyond what that job covers. Open rung 3 by a route you did not choose. Turn on live location sharing on your behalf. Note the word. This row is about the product. Section 8.2 describes what direct operational access to the database can do, which is more.

Our systems

Specifically

The server can do

Store and return ciphertext. Decide whether a rung opens and to whom. Deliver a wrapped key to a person a rung entitles. Write the disclosure record. Enforce a revocation, a lock, or a withdrawal.

The application cannot do

Read your vault sections or your documents’ contents. Unwrap your private key. Reset your vault password or recover your vault. Open a rung to someone you never gave a job to. Widen a disclosure beyond what that job covers. Open rung 3 by a route you did not choose. Turn on live location sharing on your behalf. Note the word. This row is about the product. Section 8.2 describes what direct operational access to the database can do, which is more.

If we ever change a line in this table, that is a material change to the Terms, and you will get at least 30 days’ notice by email before it takes effect — not a quiet edit to a web page.

4. What is encrypted, and what is not

This section is the most useful thing in this document. "Encrypted" is a word that invites a bigger reading than any real system can support, so instead of the word, here is the list.

4.1 Encrypted so that we cannot read it

For everything below, we hold ciphertext and no key. A complete database dump combined with every credential we possess yields nothing readable.

Every vault section and everything in it — your address, your financial accounts and balances, your dependants’ details, your pets’ details, your secret locations, your employer and salary, your cultural, funeral and personal wishes.
The contents of every document you upload.
The contents of the group conversation.
Anything you broadcast to your circle.
Your private key, in all three of its wrapped forms.

No card number, no bank credential and no biometric exists anywhere in NESA, in any form. There is nothing of that kind to lose.

4.2 Held in the clear, so that an emergency can be routed

The layer that decides who to page, and pages them, cannot itself be encrypted to you — it has to work when you are unconscious. So the following is readable by our systems, and to anyone who obtained our database.

What	Why it is in the clear
Names and phone numbers	Your contacts, and everyone you named — the roster of your circle, with their email addresses and phone numbers. The members of a circle can also see one another’s names while an alert is running; section 6.2.
Document names and filing lines	The bytes of a file are encrypted. Its name is not. A row reading "Financial power of attorney" is a readable fact that you have one, even though its contents are unreadable.
The shape of your vault	Which categories you keep, and exactly who can open each. Not the contents — the structure.
The account of what happened	What somebody wrote when they raised a concern about you, in their own words. This is often the most sensitive plain text in the system.
Statements made under the rung-3 route	The written assertion that you cannot act for yourself, in full, permanently, and never editable or deletable by anyone including us. Its permanence is the accountability that makes the route defensible.
The reachability payload	Coarse location, movement, battery, and who else to call — with their phone numbers.
The disclosure record	What opened, to whom, when, and on what basis.
Working credentials	Push channel identifiers and outstanding invitation links. These are not merely identifiers: somebody holding our database could use them to page your devices, or accept an invitation meant for someone else. We hold them because a notification cannot be delivered and an invitation cannot be accepted without them.
Billing identifiers	The references our payment processor gives us. No card number, no expiry, no bank detail — those never reach us at all.
What you agreed to, and when	Which document, which version, and the moment — recorded by our servers rather than by your app, and not editable by either of us afterwards. Part 2.2 of the Privacy Policy.

The single sentence: someone with our whole database reads every account of a welfare concern, every incapacity statement, your area-level location, your whole contact roster with phone numbers, every filename, the shape of your vault, your billing identifiers, and the working credentials in the last row above — and reads no address, no medical record, no financial account, no dependant’s details, no secret location, and no document contents.

One consequence of how roles work belongs here rather than buried. The Personal category — legal name, date and place of birth, citizenship, address, contact details — is included in every job, because without it nothing else is usable. So the smallest job you can give somebody still shows them your date and place of birth. Your address is inside the encrypted vault; but date of birth travels with every role, and that is a deliberate trade rather than an oversight.

We are working to shorten this list. Encrypting document filenames is already queued. We will say so here when it lands rather than quietly improving the description.

4.3 Invitation links do not expire

An invitation you send to somebody stays valid until it is used or you remove it. There is no automatic expiry today. If you invited someone a year ago and they never responded, that link still works. You can remove it from your account.

5. Scribe, and the one place your information leaves

This is the largest confidentiality caveat in NESA and it deserves its own section rather than a line in a vendor table.

5.1 What happens

Scribe is the assistant that helps you fill your vault. It can do data entry from what you tell it, and it can read a document you point it at. Both of those require it to actually see the words.

What you type into Scribe is sent to an outside AI service — Anthropic — to produce the reply. It leaves the encrypted boundary in plain text.
A document you ask Scribe to read is decrypted on your device and sent to that service, in full, as an image or a file. Only a short list of document types can be read at all — 5.2.

5.2 The rules around it

Because this is the exception to everything else in this document, it is bounded deliberately:

Most of your vault cannot be read at all. Reading is limited to a named list of document types — identity documents, medical cards and medication lists, vehicle and pet insurance, travel documents, utility accounts, and a few practical lines such as funeral wishes, recipes and charitable giving. Everything else has no read button anywhere in the product: your will and other legal papers, financial statements, anything under Secret locations, anything belonging to a dependant, and your family stories and personal letters. You can store those. You cannot send them. Our servers enforce this, not only the app. A read names the document, and the server looks up that document’s own filing and refuses anything the list does not cover — so the limit does not depend on the app you are running. One thing it cannot do: the decryption happens on your device, so a modified app could hand the server one document’s name with another document’s picture. We would rather bound the claim than overstate it.
Uploading a document does not send it anywhere. Dropping a file into NESA encrypts it and stores it. Reading it is a separate, explicit action on that specific file.
Nothing reads a document on upload, on selection, or on a timer. There is no background scanning of your vault. Ever.
The trade is stated on the button, every time. Not in a settings page you read once, and not only here.
Scribe proposes; you confirm. Anything it suggests for a field stays pending until you accept it, and anything it could not write is said out loud in the conversation rather than silently dropped.
You can switch Scribe off, and off is enforced on our side. Not a preference the app promises to honour: with Scribe off the server refuses the request outright, so no version of the app — ours, a modified one, or a future one — can send anything. Turning it back on is a deliberate act, and the moment you agreed is recorded.
You can send part of a page instead of all of it. Draw a box around the line you want read, and only what is inside it is encoded and sent. The cropping happens on your device before anything leaves it, so the rest of the page is never transmitted — not held back at the other end, never sent.
Every read is listed, in Settings. The document’s own name, where it was filed, when it was sent, and whether the whole page or only part of it went. No content: not the reply, not the fields that came back, not a summary. That list is assembled by your own device from what your app did, rather than authored independently by our servers — so it is a record of your app’s actions. Moving it server-side is queued work.

5.3 What the AI provider does with it

We are on that provider’s standard commercial terms, and this is what they say. Our use of the service runs under its commercial terms rather than its consumer ones, which incorporate a data protection agreement. Under those terms: what we send is not used to train anyone’s models, and it is deleted by the provider within 30 days of being received or generated. That 30 days is the provider’s published default rather than a term we negotiated, and it can be longer in narrow cases they set out — chiefly where they are investigating a breach of their usage policy.

We also send no account identifier with a request — no user ID, nothing but the model, the instructions and the text itself. You are pseudonymous at that provider by construction rather than by their policy, which is a stronger thing to rely on.

A document you asked Scribe to read is still the one thing our own deletion process cannot reach, because it went to somebody else’s system. What has changed is that it is no longer open-ended: it is deleted there within 30 days. That is a real limit on the deletion right, and we would rather bound it than bury it. We have asked for a zero-retention arrangement, which would remove the window entirely. That request is pending; we will say so here if and when it is in place.

6. How an activation works

6.1 The four rungs

Rung	What opens	What it takes
0 · Status	That something was raised, and the group conversation. No vault section at all.	Any signal. No waiting period, because there is nothing to protect.
1 · Reachability	A named area rather than an address, movement, battery, last-seen, and who else to call. Still no vault section. It opens to the person who raised it and to the subscriber’s first calls, never the whole circle.	One concerned person holding a duty role. The anomaly path — a sustained departure from the subscriber’s own pattern — needs the mobile application and is not available; section 10.
2 · Act for me	The categories belonging to the job each paged person accepted — and only those, so a house-and-animals holder gets no medical section. NESA holds no precise coordinates at any rung.	Two independent things: two duty-role holders in different roles, or one plus an anomaly once that path exists (section 10).
3 · Full scope	Everything pre-authorized for that situation. Secret locations only under the named-verifier route.	You, authenticated. An enrolled institution. Or the route you chose in advance.

Rungs 0 and 1 open no vault section, and that is enforced in one place — the code that assembles a disclosure returns an empty set below rung 2, before any read happens. The rung is never taken on trust from a stored value; it is recomputed from the record of what actually happened, every time a decision is made.

6.2 Rules that hold across every rung

Activation can only open what was granted in advance. It never invents a permission.
Agreement is not corroboration. The second person must add something they saw or tried. There is no way to simply concur — no reaction, no one-tap agree.
There are no precise coordinates to disclose. The system does not store a latitude and longitude for you at all. What a rung can carry is a named area and whether you are moving. This is a property of the data model, not a display choice, so there is nothing in the traffic for an inspector to find.
One reading per event, not a feed. If a situation escalates, that is a new event and takes a new reading. The number of readings equals the number of things that happened.
Every alert expires, and can be ended early by someone confirming the subscriber is fine.
The banner each person sees is rendered for that person, never posted as one shared message — a shared message would push one person’s entitlement to everybody in the room.
An open alert makes the circle visible to itself. While an activation is running, everyone holding a job can see who else is in the room — their names, not their contact details — because somebody who cannot see who else was called cannot coordinate with them. It closes again when the alert ends. Section 8.4 of the Terms sets this out in full.

6.3 One deliberate exception the owner controls

If you trigger an emergency yourself, the message that goes to your circle carries your precise coordinates — encrypted to your circle — to everyone who accepted a role, rather than the area-level reading a rung would produce. This is the one place precise position appears anywhere in NESA. It is your own deliberate act rather than something the system decided, and you should know two things about it: it goes to everybody who accepted, not to a rung-scoped subset, and it cannot be recalled.

7. What "revoked" does and does not mean

This section exists because the honest answer is narrower than the word suggests, and we would rather write it down than have a reviewer find it.

When you revoke a job, or stand down an alert, the server stops serving that person anything. From that moment they can read nothing further. That part is real, enforced at the database, and it is what revocation is for.

One thing it does do, and it is worth saying. Ending one job does not close access that another job the same person still holds independently justifies. If somebody holds both Medical and House and animals and you end the second, your medical section stays open to them, because the first job still covers it. Revocation closes what that job opened, not everything that person can see.

Three things it does not do:

It does not reach into what they already fetched. If a section was open to somebody and their app collected the key for it, revoking does not remove that key from their device. We do not currently re-encrypt a section after a revocation, which means a determined person who kept what they were given retains the ability to read that section’s contents as they were. Revocation stops future access; it does not undo past access.
It does not un-read the group conversation. When someone is removed we rotate the conversation key so they cannot read what is said afterwards, and messages sent before that stay readable to whoever held the old key. If the rotation itself fails — it can, and it is designed not to block the removal when it does — the removed person could still read what follows. We are making that failure visible to you rather than only to our logs.
It does not recall a delivered message. Nothing can.

So: revoke early, and treat revocation as closing a door rather than as erasing a memory. Re-encrypting sections on revocation is work we intend to do, and we will change this section when it is done.

8. Who at NESA can see what

Most security statements describe staff access in terms that cannot be checked. Here is the actual position, including the part that is uncomfortable.

8.1 Inside the product

There is no administrator in NESA. No admin role, no support-impersonation feature, and no way for one signed-in account to read another account’s information. No member of our staff has an in-product view of your vault, your people or your records. Nothing in the application would let us look at you.

Two operational switches sit outside the product. One stops NESA sending notifications globally; the other silences them for a single account. They exist for testing and incident control, they reveal nothing about anybody, and the risk they carry is the opposite one — that somebody believes they are covered while nothing would be sent. We treat either being left in the wrong state as an incident.

8.2 Outside the product

Below the application sits the database, and someone has to be able to operate it. That access is real and we will not pretend otherwise.

Operational database access cannot read your vault. Not any of it. The private key is wrapped by your password, your recovery key and your passkeys, none of which we hold. This is the strongest control in this document and it holds against us as completely as against an attacker.
Every table enforces per-account isolation, and it is tested. One thing does not: an internal health record showing how many accounts a scheduled job processed is readable by any signed-in user. It contains counts and internal identifiers rather than anybody’s information, and we are closing it.
Operational database access can read everything in section 4.2 — your roster with phone numbers, the account of a welfare concern, attestation statements, filenames, the shape of your vault. It can also write: that access could in principle open a grant or create an activation directly, bypassing the product’s own rules. It still could not read your vault, because that needs a key we do not have — but it could cause a disclosure of the plaintext layer that the product’s record would not attribute to us.
Resetting an account from the database does not open a vault. It produces a new key, and a new key does not decrypt old data. There is no path from operator to plaintext.
We are a very small company, and that access is currently held by one person. There is no separation of duties and no second approver. We are not going to describe a control structure we do not have. Building one, and rotating the credentials that hold it together, is the top item on our security plan.

One consequence, stated plainly because it will otherwise be found rather than told. The disclosure record is complete against every actor in the product — every rung, every recipient, every refusal. It is not complete against direct operator action on the database, which the product’s own record does not see. So the honest form of "every disclosure is on the record" is: against everyone except the operator. Reducing that gap is on our security plan; until it is closed, this is what is true.

8.3 What you can see for yourself

Not yet. Everything is written down, but the screen that shows it to you is still being built. Ask us in the meantime and we will send it.

9. Recovery, without a back door

If this happens	What you do
You forget your password	Use your recovery key. It opens your vault and lets you set a new password. Using it retires that recovery key and issues a new one — save it.
You lose your device	Sign in on a new device with your password. Your vault is intact; it was never on the device.
You lose your device and you had only Face ID set up	Your password still works. Passkeys are an additional way in, never the only one.
You lose your password and your recovery key	Your vault cannot be opened. Not by you, not by us, not by anyone, ever. This is the honest and unavoidable consequence of the design, and it is the reason the recovery key exists.

Print your recovery key or write it down, and put it somewhere you would still find it in five years — a safe, a filing cabinet, a password manager. Do not photograph it and leave it in your camera roll. Do not email it to yourself.

10. Signals, and the limits on them

This section describes a layer that is switched off. It is disabled in the database rather than merely unbuilt, so it cannot run by accident.

NESA is designed to read your steps, your movement and — if you allow it — your location, in order to explain away ordinary silence so that nothing escalates unnecessarily. None of that is collected today. There is no mobile application to collect it, and the setting that would enable it is constrained at the database to a single value: off. Any part of the system that asks whether there is a movement anomaly currently gets the answer "unavailable", and unavailable is never treated as "nothing wrong".

When it does exist, these commitments apply:

Your personal pattern is computed and held on your device, not uploaded. What reaches our servers is the conclusion, not the picture.
Signal data is displayed nowhere, to you, to the people you named, or in any internal tool.
Motion and location are separate permissions, and motion-yes-location-no is a supported choice.
Losing a signal makes NESA quieter, never louder. A path that has lost its evidence switches off rather than escalating on weaker grounds.
Signals are used for nothing else — no analytics, no research, no product metrics, no model training.

11. What Scribe cannot do

Scribe is bounded by architecture rather than by instruction:

No model decides what opens. What a job covers was fixed when you assigned it, and the rung is computed by deterministic code that re-checks the evidence, your current people and your current revocations at the moment of release.
No model can widen a disclosure. There is no path from a model output to a grant.
Scribe writes nothing without your confirmation.
No advice. Scribe does not interpret, triage, recommend, or improvise, and it is tested against attempts to make it.

What a model does see is set out in section 5, and only that.

12. Signing in

We would rather be accurate here than impressive.

Signing in is email and password. That is currently the only way into an account. There is no multi-factor authentication on sign-in today, no SMS codes, and no authenticator app. Adding a second factor is on our security plan and we are not going to claim it before it exists.
Your vault has a second lock. Signing in does not open it: the vault unlocks separately, with your vault password, your recovery key, or a passkey using Face ID, Touch ID or a hardware key. So a stolen session alone does not read your vault.
No SMS is used for anything security-critical. SIM-swap attacks are common and this is exactly the kind of account they target.
Locking your vault requires a fresh sign-in, not an existing session — so a thief holding an open session cannot undo it. Requiring a re-authentication before other sensitive changes is on our plan and is not built yet; we are not going to list it as though it were.

13. Two ways to use NESA

NESA runs as a phone application and as a web version, from separate addresses. Same account, same vault, same encrypted data — a different interface for a different device.

The web version locks itself after 15 minutes idle, with a warning first. Each tab unlocks separately; unlocking one does not unlock another.
There is a shared-computer mode. Tell NESA the machine is not yours and it locks after two minutes, offers no passkey, and keeps no session behind you.
Location on a laptop is weaker and we say so on the screen. A browser grant is per-browser, and movement is only observed while the tab is open. It is not a substitute for a phone.
Scanning is phone-only. On a laptop you upload instead.

14. What we defend against

Threat	What protects you
Our servers are fully compromised	Your vault contents remain unreadable. The attacker gets ciphertext, plus everything in section 4.2 — which is a real loss, and is why that list is published rather than summarised.
Someone with operator access misuses it	They cannot read a vault. They can read the section 4.2 layer, and the product’s own record does not see them. Section 8.2.
Your account is taken over	A session alone does not open your vault — that needs your vault password, recovery key or passkey. You can lock the vault, which deletes passkeys and blocks reads at the database. Requiring re-authentication before other sensitive changes is on our plan and is not built — section 12.
Someone in your circle raises a false alarm	One person reaches rung 1 at most, which opens no vault section. Rung 2 needs a second independent thing, and the second person must add something they saw or tried.
Two people collude	They reach rung 2, and rung 3 only if you chose the two-person route. Every statement is permanent and named, there is a 24-hour delay with alerts to you throughout, and choosing the verifier route or "nobody but me" removes the path entirely.
Your phone is stolen	Your vault does not open just because a session is open — it needs your vault password, your recovery key or a passkey. Vault keys live in memory only while you are unlocked and are cleared when you sign out. Lock your vault remotely and every passkey is deleted, a fresh sign-in is required, and reads are blocked at the database.
The AI is manipulated	No model authority over what opens or over whether a rung opens; strictly structured inputs and outputs; nothing executes from model output.
A subpoena or warrant arrives	We can produce ciphertext and the section 4.2 layer. We cannot produce vault contents. We notify you unless legally prohibited.
The service is knocked offline	Rate limiting on the paths that face the internet. Being unavailable during an emergency is itself a safety failure, and multi-region deployment with tested failover is on our plan rather than in place.

15. How we build, and how we check

15.1 Engineering

Every change goes through linting, type checking and an automated test suite before it can ship, and a failing suite blocks the merge. Row-level security is enabled on every table in the database, with tests that assert one account cannot read another. Decision logic for activation is written as pure, separately tested code, so the rung a given set of evidence produces is asserted directly in tests rather than inferred from behaviour — which matters more here than anywhere else, because a defect in that code means somebody is not reached.

Automated dependency, secret and static-analysis scanning in the build is on our plan and is not in place yet. We would rather tell you which parts of the usual list we have than imply all of it.

15.2 Independent assurance

In September 2026 we prepared a full audit package for independent security review, and ran a claims audit alongside it — an internal review not of "can an attacker do this" but of "when the product tells somebody something is true, is it true". Much of this document is a direct result of that work, including sections 4, 7, 8 and 12, each of which corrects something we had previously described more favourably than the code supported. That independent review has since been completed — an external reviewer examined the package in September 2026 — and we are working through what it found. Section 19 lists what remains open.

Still to come, in order: an external penetration test; a written information security program to the New York SHIELD Act standard; a specialist breach law firm on retainer and cyber liability insurance bound; SOC 2. We will not describe any of them as done before they are.

15.3 Vendors

Every vendor with access to personal information is reviewed before engagement, and putting a written data protection agreement in place with each is part of the same pre-launch programme as the rest of this section. The Privacy Policy names them. Our AI provider is the one where the terms matter most: we are on its standard commercial terms, which carry a data protection agreement and a 30-day retention window, and we have asked for the zero-retention arrangement that would close that window. That request is pending. Section 5.3.

15.4 If something goes wrong

We maintain a written incident response plan with named roles and pre-drafted notifications. If an incident affects your information we will notify you without undue delay and within 60 days at the outside, sooner where any applicable law or our own standard requires. We would rather tell you early and imprecisely than late and polished.

16. The claims we make, and the ones we do not

We say	And we mean
We cannot read your vault	Your private key is wrapped by your password, your recovery key and your passkeys, none of which we hold. No server path unwraps it. We do not extend this sentence to the whole product — section 4.2 is the boundary.
Encrypted on your device, with keys we do not hold	Our preferred phrasing. We do not use the term "zero-knowledge" about NESA as a whole: it is true of the vault and false of the emergency layer, and a phrase that invites the wrong reading is worse than a longer sentence.
Encrypted on save, not on keystroke	A small correction to something we have said elsewhere. Your information is encrypted when it is saved, not character by character as you type. It never leaves your device before that.
A disclosure is recorded	Recorded, append-only, and yours to see — though the screen that shows it to you is still being built, so today you ask us and we send it. Not cryptographically signed; we have said "signed" in marketing material and it was wrong. Section 8.2 states who the record does not cover.
No compliance claim at all	We are a personal health record vendor under the FTC Health Breach Notification Rule, not a HIPAA covered entity. We do not describe ourselves as "HIPAA-compliant", "HIPAA-aligned", "bank-level" or certified to any standard. We hold information of a kind that invites those words and we are deliberately not using any of them. When we have an attestation, we will name it and you will be able to check it.
We do not track you	One location reading per rung event, at area level, deleted with the alert. No precise coordinates for you exist anywhere in the ladder — there is nothing to coarsen, because there is nothing precise being held. The single exception is a message you send yourself, which carries precise coordinates because you chose to send it, and which cannot be recalled. Retention here is a commitment being built; see 8.6 of the Privacy Policy.
Some paths are not available	The passive layer is disabled at the database, and other paths need permissions we do not have. The Terms say so path by path, and your in-app coverage display is the live answer.
No system is perfectly secure	True of us as of everyone. What we claim is specific and testable, not absolute.

If you find a statement in our marketing, our application, or our sales materials that overstates what is written here, tell us at security@getnesa.com and we will correct it. This document is the authoritative technical description of how NESA protects your information and it governs over any marketing, website or sales material. Where it and the Terms address the same subject, the order of precedence in the Terms applies.

17. What we ask of you

Save your recovery key somewhere you will still have it in five years. Nothing else in this list matters as much.
Choose a strong vault password. It is stretched hard before it becomes a key, but it is still the thing an attacker would attack.
Turn on a passkey if your device supports it. It is faster and it is not a password anybody can guess.
Make sure someone has actually accepted a job. A full vault with nobody assigned cannot open to anyone.
Keep your vault current. At rung 2 the people you named act on the address and medical details you entered.
Revoke early rather than late, given section 7.
Tell us immediately at security@getnesa.com if you think your account or a device has been compromised.

18. Reporting a vulnerability

If you believe you have found a security issue, tell us at security@getnesa.com. We aim to acknowledge within one business day and to give a substantive response within five.

We commit to good-faith researchers: we will not pursue legal action against you for research conducted in accordance with this section — research that avoids privacy violations, does not degrade the service, does not access, modify or exfiltrate data belonging to anyone but you, and gives us a reasonable opportunity to fix the issue before public disclosure. We will credit you if you would like to be credited.

19. Current status

NESA is in closed beta and is built in stages. This version of this document was rewritten after a September 2026 security audit, and several sections say less than the previous version did because the audit showed the previous version said more than the code supported. We think that is the right direction for a document like this to move.

Known and outstanding, in our own words rather than after somebody else finds them: the passive layer is off; the rung-3 gate has no screen yet, so in practice rung 3 currently opens to nobody but you; no institution is enrolled, so that path cannot fire; revocation does not re-encrypt (section 7); the screen showing your own activation record is still being built (section 8.3); there is no second factor on sign-in (section 12); and we are on our AI provider’s standard commercial retention rather than the zero-retention arrangement we have asked for, which is still pending (section 5.3).

Your in-app coverage display is the authority on which activation paths are working for your account. This statement is reviewed at least annually and whenever the architecture materially changes. Questions to security@getnesa.com.