NESA — NESA Privacy Policy

Terms and Conditions · Privacy Policy · Security and Data Protection

This covers the NESA product. Part 3 describes collection that has not begun and will not begin without asking you again. Part 6 is our Consumer Health Data Privacy Policy and stands as a distinct notice. Part 7 sets out your rights and how to use them.

The short version

We cannot read your vault. Your keys are derived on your device. We hold ciphertext. This is architectural, not a promise about our intentions.
That covers your vault, not the whole product. The emergency layer around it holds real information in the clear so that it can page people while you are unconscious. Section 2.2 lists every field of it, because one true sentence should not be left to imply a bigger one.
One feature sends your information out. When you ask Scribe to read a document, it is decrypted and sent to an outside AI service. Only when you ask, only for the document you named, and only for a short list of document types — your will, your financial statements and your passwords cannot be sent at all. Part 4 explains it in full.
When the mobile app exists, NESA will read your steps, your movement and — if you allow it — your location. Not to watch you. To be able to say "she is up and moving" instead of opening anything. Part 3 explains this in full, and it is the most important new thing in this version.
We do not track you. Where your location is disclosed during an activation, it is a single reading taken at that moment, never a continuing feed. Live sharing exists, but only you can switch it on.
Turning a permission off makes NESA quieter, never louder. No path ever escalates on weaker evidence because you declined to give us stronger evidence.
We never sell your information. We never share it for advertising. We never use it to train anyone’s AI models.
Everything that opens is recorded — what opened, to whom, and why, including when you were unconscious for all of it. The screen that shows you that record is still being built; until it ships, ask us and we will send it.
You can see, correct, export and delete what we hold, at any time, for free, without explaining why.

Questions, requests, complaints: privacy@getnesa.com.

Part 1 — Who we are and what this covers

1.1 Who we are

NESA is operated by Interim Adult, Inc., a Delaware corporation ("we", "us"). We are the controller of the personal information described here. Our privacy lead can be reached at privacy@getnesa.com.

1.2 Who this policy covers

It covers the NESA application, your account, your vault, activation, and our website. It covers information about four groups, and three of them never signed up for anything:

Subscribers — people with a NESA account and a vault.
People a subscriber names — those asked to take on a job. You are asked, and you may decline. We hold information about you either way.
People who make a statement — someone who attests that a subscriber cannot act for themselves, or a named verifier who confirms it. Your statement is recorded permanently under your name.
Visitors — people who use our website without an account.

The NESA waitlist has its own, shorter policy, which continues to govern waitlist information until it is migrated into an account. We will not migrate it without telling you. A waitlist entry is stored separately from your account, and deleting your account does not remove it — ask us at privacy@getnesa.com and we will remove both.

1.3 Our regulatory position, stated plainly

NESA holds health information but is not a HIPAA covered entity. It operates as a personal health record vendor under the Federal Trade Commission’s Health Breach Notification Rule (16 CFR Part 318). Your vault is your own personal health record; we are its custodian.

We make no compliance claim of any kind about NESA. We do not describe it as "HIPAA-compliant" — that phrase is discouraged for vendors in our position and would be misleading — and we do not claim any certification we have not obtained. If we ever handle information on behalf of a HIPAA-covered entity, that will require a Business Associate Agreement, and we will have one.

Part 2 — What we hold

2.1 What we cannot read

For everything below we hold ciphertext and no key. A complete copy of our database, combined with every credential we possess, yields nothing readable from it. We can never turn this list into the next one — not for a support request, not for debugging, not for a subpoena, not for a regulator, not for you.

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, and of anything you broadcast to your circle.
Your vault password, your recovery key, and your private key in any usable form.
Your personal movement pattern, which is computed and held on your own device and never uploaded.

There is no card number, no bank credential and no biometric anywhere in NESA, in any form. Your face and fingerprint stay on your phone; we see only a public key.

2.2 What we hold in the clear, and why

The layer that decides who to page, and pages them, has to work while you are unconscious — so it cannot be encrypted to you. The following is readable by our systems, and would be readable by anyone who obtained our database. We would rather publish the list than let the word "encrypted" do more work than it can.

What	Why it is in the clear
Names and phone numbers	Your contacts and everyone you named — the roster of your circle, with email addresses and phone numbers.
Document names and filing lines	A file’s contents are encrypted; its name is not. A row reading "Financial power of attorney" is a readable fact that you have one. Encrypting filenames is queued work.
The shape of your vault	Which categories you keep and exactly who can open each. The structure, not the contents.
The account of what happened	What somebody wrote, in their own words, when they raised a concern about you. Often the most sensitive plain text in the system.
Statements under the rung-3 route	The written assertion that you cannot act for yourself, in full, permanently. Nobody can edit or delete it, 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 numbers.
The disclosure record	What opened, to whom, when, on what basis, and what was refused.
Account and billing identifiers	Your email address and, once payments go live, the identifiers our payment processor gives us so we know your subscription is current. No card number, no expiry and no bank detail is ever stored by us, in any form.
Delivery credentials	Push channel identifiers and outstanding invitation links. These are not merely identifiers — they are working credentials, and somebody with our database could use them to page your devices or accept an invitation meant for someone else. We hold them because there is no way to deliver a notification or an invitation without them.
Which days you used Scribe	A per-day usage count, kept so we can manage capacity. Not what you said — that we do not keep — only that you used it.
What you agreed to, and when	Each time you accept these documents or turn Scribe on, we record which document, which version of it, and the moment — written by our servers rather than by your app, so that it is a record and not something either of us can edit afterwards. Kept while your account exists and erased with it.

The single sentence: someone with our whole database reads every account of a welfare concern, every incapacity statement, your coarse location, your whole contact roster with phone numbers, every filename, and the shape of your vault — and reads no address, no medical record, no financial account, no dependant’s details, no secret location, and no document contents.

2.3 Information you give us

Account information

Your email address, and a phone number if you provide one for notifications. A display name if you set one.

Vault contents

Whatever you upload, encrypted on your device before it reaches us. We receive and store ciphertext. We do not receive the keys.

Your people, and the jobs you gave them

Name, email address, phone number, relationship, and the job you asked them to do. We hold their response — accepted, declined, or a counter-offer — and the date of it. We use this to send the ask, to set up their credentials, to check periodically that they are still reachable, and to open the right thing to the right person during an activation.

You must have their permission before you name them. When you do, we tell them directly what they are being asked, by whom, what it would mean, and how to decline or withdraw. We do not rely on you to have explained it. A declined ask is kept only as a record that it was declined, so we do not ask them again.

An invitation link does not expire on its own. It stays valid until it is used or you remove it. Automatic expiry is queued work; until it lands, remove invitations you no longer want outstanding.

Payment information

Handled by our payment processor. We never see or store your full card number. During a free trial we hold no payment method at all, because we have not asked you for one.

Support and correspondence

What you write to us, and our replies. If you paste sensitive information into a support ticket it exists there in readable form — please do not, and we will delete it if you do.

2.4 Information generated by an activation

When something is raised, we record what happened. This is the audit trail, and it is deliberately thorough — it is what lets you see afterwards exactly what was done in your name.

What was raised, by whom, and what they wrote. The free text a person types when they report a concern is held in readable form. It has to be, because a human may need to weigh it.
What the alibi check found — whether there was recent movement, and therefore whether the matter ended there.
Which rung opened, to whom, and on what basis, including which second signal corroborated it.
The location reading taken at that moment, if location applied at that rung.
Attempts that were refused or that failed, not only ones that succeeded. An attempt to open something that the system rejected is exactly the kind of thing you should be able to see.
Any statement made under the rung-3 route — its full text, the name of the person who made it, and the time. This is permanent by design. Section 9.3 of the Terms explains what that person is asserting.
How it ended — expired, stood down, or closed by evidence arriving.
That the circle was made visible to itself. While an alert runs, the people holding jobs can see one another’s names whatever you had set; their contact details stay behind that setting, and it closes again when the alert ends. Section 8.4 of the Terms.

2.5 Information collected automatically

Technical and device information — IP address, device type, operating system, app version, timestamps. Used to operate the service, secure it, and detect attacks.
Security events — sign-ins, failed sign-ins, changes to your people, changes to what a job opens, changes to your rung-3 route.
Nothing else. We run no crash reporter, no error-reporting service, no product analytics, no session recording and no advertising pixels. There is no third party anywhere holding a record of how you use NESA.

We do not run advertising trackers, marketing pixels, or third-party analytics that build a profile of you. We use only the cookies and local storage the service needs. There is no advertising anywhere in NESA and there will not be.

2.6 The group conversation is outside the vault

When an activation opens, the people involved get a conversation. Its messages are encrypted to the people in it and we cannot read them. But it is not your vault, and it does not have your vault’s protections — in particular, everyone in that conversation sees the same messages, so the per-person limits you set do not apply inside it. Nothing from your vault is ever posted into it. But people paste things into chats, and if someone types your medication list into a message, everyone in the room can read it. Please tell the people you name not to do this.

2.7 Information we do not want

Please do not put account passwords, banking credentials, or card numbers in your vault. Please do not put another person’s records in your vault unless you have their consent and a reason.

Part 3 — Signals: what NESA reads about you

This Part describes collection that begins when the NESA mobile application exists. Until then none of it happens, because there is no application capable of it. We are telling you now, in full, rather than adding it quietly later.

3.1 What this is for, before what it is

It would be easy to read this Part as a request to watch you. It is closer to the opposite, and the honest framing matters enough to put first.

The hard problem in a service like this is not noticing that something is wrong. It is not overreacting to ordinary silence. Someone who has not opened an app in nine hours might be asleep, might be on a hike with no reception, or might have fallen in the bathroom. Today those look identical. Steps, movement and device state are what tell them apart.

These signals are what keep your vault shut. They are what let NESA answer a worried phone call with "she is up and moving" instead of opening your medical section to somebody. Their primary output is a reason not to escalate.

3.2 What we collect, and why

Signal	What it is for	Notes
Steps and motion state	Proving you are alive. This is the basis of the alibi check and of your personal pattern. It is the one that matters.	Read from your phone’s health and motion services with your permission. Collected in batches, not continuously.
Location	Distinguishing off-grid from collapsed at home, and giving the person who is worried somewhere to look.	Separate permission. You may grant motion without location. See 3.4.
Device state	Whether your phone is powered and reachable, and whether it is charging. Plugged in overnight is a strong "asleep, not collapsed" signal.	Sampled when the phone happens to be awake, not continuously.
Health measurements	Heart rate, sleep and walking steadiness would deepen your personal pattern.	Not collected. A later phase, with its own separate permission, and it will not begin without us asking you again. See Part 5.

None of this is displayed anywhere in the product. It is consumed by the engine that decides whether to escalate. It is never shown to the people you named, and there is no screen — for you or for us — that renders it as a record of your movements. A small number of our staff can reach it under the controls in 6.6, when investigating a specific problem. That is the honest position: not that no human being could ever see it, but that nothing displays it, and access is restricted, logged and reviewed.

3.3 Three things about this that are not obvious

Each of these is a real consequence of how the technology works, and each is the kind of thing you would reasonably be annoyed to discover later.

Your phone already recorded your steps before you gave us permission

Phones keep step and motion history whether or not NESA is installed. When you grant permission, NESA can query that existing history — including a period before you gave permission, and before you had an account. We do this for one reason: it lets your personal pattern be built in minutes rather than over weeks, so the alibi check protects you from the first day rather than the second month.

You should know it happens. You can decline it and still grant ongoing permission — the pattern then builds forward from today, and everything still works, just later. If you decline it, we do not query it. If you grant it and then withdraw, we delete the historical portion along with the rest.

When your phone reconnects, it uploads what happened while it was offline

Your phone keeps recording steps, motion and position with no network at all. When connectivity returns, that buffered history uploads. This means we come to hold a record of your movement during a period you may have believed you were entirely disconnected.

There is a good reason for it: six hours of ordinary walking arriving at once is what retroactively closes a concern somebody raised at hour three, with evidence, without anybody having to phone around. It is also the thing that gives rung 1 real content — last seen at the trailhead at six, moving, forty per cent battery — for the person trying to find you. But it is not obvious from the outside, so we are saying it here.

Your personal pattern stays on your phone

The model of what is normal for you — your ordinary step count, your ordinary rhythm — is computed and held on your device and is not uploaded to us. What reaches our servers is the conclusion, not the picture: that today is or is not far outside your normal. We do not hold a profile of how you live, and we have designed it this way deliberately.

3.4 Two permissions that are not the same thing

The permission for NESA to read signals as evidence is a different grant from the permission for a named person to see where you are. We keep them apart in the product and here.

	The signal permission	The disclosure permission
What it allows	NESA to read motion, location and device state as evidence.	One named person to see roughly where you are during an activation.
Scope	Global, between you and NESA. Never set per person.	Per person, per job.
Who sees the data	Nobody.	Only that person, only at their rung, only for the length of the alert.
Turning it off	The dependent paths switch off. Nothing becomes more sensitive.	That person gets status only. Nobody else is affected.

The signal permission is deliberately not per-person. If it were, the most privacy-conscious person would end up with the weakest protection, which is exactly the wrong way round.

3.5 Our commitment when you say no

Withdrawing a permission makes NESA quieter, never louder. A path that has lost the evidence it depends on switches off. It never falls back to escalating on weaker grounds. A system that grew twitchier the more privacy you asked for would be most dangerous to the people most careful about it, and we will not build that.

Before you decide, NESA shows you exactly which paths stop working without each permission. If you decline, we honour it. You can withdraw at any time, in the app or in your phone’s settings, and withdrawal deletes what was collected under it.

3.6 Permissions lapse, and we will tell you

Phone operating systems re-prompt periodically and quietly downgrade background permissions. People lose coverage without deciding to. We commit to:

checking permission state every time the app opens, and on a regular check from our servers, rather than once at setup;
distinguishing "you turned this off" from "your phone downgraded it", and telling you which;
notifying you when a path goes dark, rather than letting it fail silently;
showing you which paths are working right now, and why any are not;
never claiming coverage we no longer have.

3.7 What we do not do with signals

We do not track you. A disclosed location is one reading taken when a rung opens. There is no continuous feed and no position history in the audit log. 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, never the passage of time.
We do not switch on live location for you. Live sharing exists in NESA and only you can start it and only you can end it. Activation never turns it on for you.
We do not infer health from motion. Steps are not a diagnostic and we do not treat them as one.
We do not use signals for anything but the alibi check and escalation. Not for analytics, not for research, not for product metrics, not for training anything.
We do not sell or share them. Ever, under any definition.

Part 4 — Scribe, and the one place your information leaves

This is the largest exception to everything in Part 2, and it gets its own Part rather than a line in a vendor table.

4.1 What happens

Scribe is the assistant that helps you fill your vault. It can do the data entry from what you tell it, and it can read a document you point it at. Both require it to see the actual 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, as an image or a file, in full. Only a short list of document types can be read at all — 4.2.

4.2 The rules around it

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 in 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 and there will not be.
The trade is stated on the button, every time — not once in a settings page, and not only here.
Scribe proposes; you confirm. Nothing it suggests is saved until you accept it, and anything it could not write is said out loud 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.

4.3 What the AI provider does with it

Set out here because an earlier version of this policy said the retention question was open. Our use of that service runs under its commercial terms rather than its consumer ones, and a data protection agreement is incorporated into them. Under those terms: what we send is not used to train anyone’s models, and it is deleted by the provider within 30 days.

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.

One consequence follows for your rights under Part 7. Everything else we hold, we can delete. A document you asked Scribe to read is the one thing our deletion process cannot reach into, because it went to somebody else’s system — but it is not kept there indefinitely: it is deleted 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.

4.4 What Scribe cannot do

No model decides what opens to anybody. Scribe has no authority over activation, over rungs, or over grants.
Signal data is never sent to a model.
Nothing you say to Scribe is used to train any model, ours or anyone else’s.

Part 5 — What we do with it

5.1 Our purposes

What we do	Why
Store and sync your encrypted vault	To provide the service you subscribed to
Read steps, movement and device state, and compare them with your own pattern	To tell ordinary silence from a real problem — and mostly to conclude that nothing needs to happen
Weigh what has been raised and open a rung	To carry out what you set up, proportionate to what is actually known
Contact the people you named, and re-confirm them periodically	So the people your setup depends on can actually be reached
Send you the after-the-fact account of every activation	Because you are entitled to know what was done in your name
Authenticate you	To keep your account and your setup from being taken over. Stepping up authentication before sensitive changes is planned and not yet built — section 12 of the Security and Data Protection Statement.
Maintain the audit log, including refused attempts	So you can see everything that happened, and so we can investigate if something went wrong
Take payment and administer your subscription	To bill you and to meet tax and accounting obligations
Answer your support requests	Because you asked us something
Detect abuse, fraud, and attack	To protect you and every other subscriber
Fix defects and improve the service	Using aggregated and de-identified operational data. Never vault contents, and never your signal data
Meet legal obligations	Tax, accounting, breach notification, lawful process

5.2 Three things we will not do

These are commitments, not current practices we might revisit. Changing any of them would be a material change under section 9.1 and would require notice to you first.

We do not sell your personal information. Not as that word is used in ordinary English, and not as it is defined in the CCPA, the CPRA, or any state privacy or health-data statute.
We do not share your information for cross-context behavioral advertising or targeted advertising. There are no ad networks or data brokers anywhere in NESA.
We do not use your information to train AI models, and our terms with our AI provider do not permit them to train on what we send. This covers everything we hold — the vault, signal data, activation records and support correspondence.

5.3 Automated processing and AI

NESA uses automated systems, including AI components, to run activation. Because these act on sensitive information, we tell you plainly how they are bounded:

No AI component decides what opens. Scope comes from the job you assigned and the rung that opened.
Whether a rung opens is decided by a deterministic engine, which re-checks the evidence, your current people and roles, and your current revocations at the moment of release.
The activation engine sends nothing to any model. Escalation decisions are made by our own deterministic code, and no vault content is involved in them.
The one exception is Scribe, on your explicit instruction, for the document you named. Part 4.
You are notified of every activation, and the complete record is kept: what was raised, what the alibi check found, which rung opened, to whom, on what basis, and when. The screen that shows it to you is still being built — write to privacy@getnesa.com and we will send you yours.
You can dispute an outcome. Write to privacy@getnesa.com or support@getnesa.com — either reaches the same people. A person, not a system, reviews it, and we tell you what we find.

We do not use automated processing to make decisions about your eligibility, your pricing, or your access to the service, and we do not profile you.

Part 6 — Consumer Health Data Privacy Policy

A distinct notice about health information, provided to meet Washington’s My Health My Data Act, Nevada SB 370, Connecticut’s health-data provisions, and comparable laws. We apply it to every NESA user in every state.

6.1 What we treat as consumer health data

We take the broadest available definition: any information that identifies your past, present or future physical or mental health status — diagnoses, conditions, symptoms, treatments, medications, allergies, procedures, devices, providers, appointments, insurance details, reproductive or sexual health information, gender-affirming care information, biometric or genetic information, and any inference about your health drawn from anything else we hold.

We also treat the following as health data, because it can imply health status even though it is technically something else:

Motion and step data, and the conclusion that your movement is far outside your own normal.
Anything a person wrote when raising a concern, which often describes symptoms or behaviour.
Any statement that you are unable to act for yourself, and the fact that one was made.
The fact that a medical rung opened, and the identity of a recipient who is a clinician.

6.2 How it is collected, and why

It reaches us in four ways: you upload it to your vault, already encrypted on your device; NESA reads motion signals with your permission; a person tells us something when raising a concern or making a statement; or it is generated as a record when a rung opens.

We collect it for one purpose: to hold it for you, to judge whether anything needs to happen, and to open it to the people you named when your setup says so. We do not analyze it, derive insights from it, or build health profiles.

6.3 Consent

We collect consumer health data only with your affirmative, opt-in consent, given separately from your acceptance of the Terms, and only for the purposes above. Specifically:

Vault health content requires your consent at the point you provide it.
Motion and location signals require their own separate consent, distinct from your consent to the Terms and from each other.
Querying your existing step history requires its own consent, distinct again, because it covers a period before you were asked. See 3.3.
Health measurements — heart rate, sleep, walking steadiness — are not collected at all. If we ever add them, we will ask you separately under Part 6, and silence will not count as agreement.

We ask for a separate authorization before any disclosure that could be considered a sale. Since we do not sell health data, we expect never to ask. If that changed you would have to say yes first; silence, continued use, and pre-ticked boxes are not consent.

You may withdraw any consent at any time, in the app or by writing to privacy@getnesa.com. Withdrawal stops future collection, deletes what was collected under it, and — per 3.5 — makes NESA quieter rather than louder. It cannot recall a disclosure already made.

6.4 Who receives consumer health data

The people you named, only what their job opens, only at the rung that opened, and only for the duration of that alert. Vault content is encrypted so that it can be opened by that person and by no one else, including us. The reachability details at rung 1 are not — they are part of the plaintext layer in 2.2.
Service providers strictly necessary to store or transmit it, under written contract, barred from using it for their own purposes, and — where applicable — bound by a Business Associate Agreement. In practice these providers hold ciphertext.

We do not disclose consumer health data to affiliates for their own purposes, to advertisers, to data brokers, to model developers, or to anyone else. We do not sell it. The only other circumstance in which any of it could leave us is valid legal process, dealt with in 8.4 — and even then what we can produce is ciphertext and the information in 2.2, never the contents of your vault.

6.5 Your health data rights

In addition to Part 7: the right to confirm whether we hold consumer health data about you, to know who has received it, to withdraw consent, and to have it deleted — from our live systems, from our backups as they age out on the cycle in 8.6, and from every service provider we can reach. We confirm to you when each step is done. The one place we cannot reach is set out in 4.3, and it is bounded at 30 days.

6.6 Access inside NESA

No employee can read health content held in a vault, because it is encrypted with keys we do not hold, and no path exists that would let us. Access to the information in 2.2 is operational database access, described honestly in 8.2 — it is held by very few people, it is used to run the service rather than to look at you, and we are not going to describe review procedures we have not built. Health data is never used for testing, demonstrations, or training.

Part 7 — Your rights

7.1 What you can ask for

We give every right below to every user, wherever you live. We do not ask which state you are in before deciding what you are entitled to.

Right	What it means
Know and access	What we hold about you, where it came from, why we have it, and who has received it. You can also get a copy.
Correct	Fix anything inaccurate. You can edit your vault and your setup yourself at any time.
Delete	Delete your data, including signal data, from our live systems, from backups on their retirement cycle, and from our service providers. We will tell you if a narrow legal obligation requires us to keep something, what it is, and for how long.
Portability	A copy of everything, in a usable format. The tool that produces it is being built. Until it ships, ask us at privacy@getnesa.com and we will assemble it by hand — the parts we hold in the clear directly, and the encrypted parts by walking you through getting them out yourself, since only you can decrypt them.
Opt out	Of sale, of sharing for advertising, of targeted advertising, and of profiling. We do none of these, so there is nothing to opt out of — but the right exists and we honour it.
Withdraw consent	For any signal, for historical step data separately, for notification channels, and for anything else you agreed to.
Limit sensitive data use	We already limit use of sensitive personal information to what is necessary to provide the service.
Appeal	If we refuse a request, we tell you why and how to appeal. An appeal is reviewed by someone not involved in the original decision, within 45 days.
Non-discrimination	We will not charge you more, give you less, or degrade your service because you exercised a right.

7.2 How to make a request

Email privacy@getnesa.com, or use the privacy controls in your account. We will not charge you, will not ask why, and will not make it difficult. We will verify that the request is really from you — for a vault-related request that means authenticating to your account, because we cannot safely take anyone’s word for it.

We aim to respond within 30 days and will tell you if we need to extend, and why. You may use an authorized agent with written authorization we can verify.

7.3 If you are not a subscriber

These rights are yours too, and this section says specifically what you can do.

If someone named you, you can ask what they recorded about you, correct it, decline the ask, or withdraw entirely at any time. We will tell the subscriber you have withdrawn, because a path of theirs may stop working — we will not disclose the contents of your correspondence with us.
If you made a statement under the rung-3 route, you can ask us for a copy of what you signed and when. You cannot delete it, and we tell you so before you make it: it is a permanent record, it is shown to the subscriber, and its permanence is the accountability that makes the route defensible. This is a narrow, disclosed exception to the deletion right, and it is the only one in this policy.
If you are a named verifier, the same applies. You act under your own professional obligations, which are yours and not affected by this policy.

7.4 Universal opt-out signals

We honour the Global Privacy Control and equivalent browser-level signals. Since we do not sell or share personal information for advertising, the signal has nothing to switch off — we recognize it regardless.

7.5 Complaints

Please tell us first at privacy@getnesa.com; we would rather fix it. You may also complain to the attorney general of your state or to the Federal Trade Commission, and nothing in our Terms restricts your ability to do so.

Part 8 — Sharing, security, retention

8.1 Who else handles your information

Each provider acts on our written instructions, is barred from using your information for its own purposes, and is bound by a data protection agreement and, where health information could be involved, a Business Associate Agreement. They hold ciphertext; none of them can read your vault either.

Who	What they do	What they can read
Supabase	Our database, authentication and file storage. Everything passes through it.	Ciphertext stays ciphertext. Everything in 2.2 is readable.
Netlify	Serves the application and holds the waitlist form.	Standard web request logs. Not your data.
Anthropic	Provides the AI behind Scribe. Part 4.	Whatever you type into Scribe, and any document you ask it to read, in the clear. The only external service any part of NESA sends your content to.
Apple, Google, Mozilla	Deliver push notifications to devices.	The notification payload and a per-device channel identifier. Notifications say to open NESA; they do not carry your information.
Stripe	Will take payment when subscriptions go live.	Your card details, which we never see. Not yet connected.
An uptime monitor	Tells us if a scheduled job stops running.	Counts only. It carries no identifiers by design.
Legal document services, where offered	Prepare and execute legal instruments.	Under their own terms and privacy policy.

That is the complete list of processors handling your account. Two things sit outside it: our website’s hosting provider also holds the waitlist form entries, which are stored separately from accounts (1.2), and the waitlist page loads typefaces from Google, which sees the IP address of anyone who visits it. We run no analytics of any kind — no product analytics, no session recording, no behavioural tracking, no advertising pixels. We will give notice before adding any processor that would handle personal information in a materially new way.

8.2 Who at NESA can see what

There is no administrator inside 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.

Two operational controls sit outside the product and affect you, so you should know they exist. One is a global switch that stops NESA sending notifications at all; the other silences notifications for a single account. Both are ours, both are used for testing and for incident control, and neither reveals anything about you. If notifications are off for your account you may believe you are covered when nobody would be paged, so we treat leaving either in the wrong state as an incident rather than a configuration detail.

Below the application sits a database, and someone has to be able to operate it. That access is real:

It cannot read your vault. Not any of it. Your private key is wrapped by your password, your recovery key and your passkeys, and we hold none of them. Resetting an account from the database produces a new key, and a new key does not decrypt old data. There is no path from operator to your vault contents.
It can read everything in 2.2 — your roster with phone numbers, the account of a welfare concern, attestation statements, filenames, the shape of your vault.
We are a 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.
Access to it is used to operate the service — to investigate a fault, to run a scheduled job, to fix data. Not to look at you.

One consequence, stated because it will otherwise be found rather than told. The disclosure record is complete against every actor in the product. It is not complete against direct operator action on the database, which the product’s own record does not observe. So the honest form of "every disclosure is on the record" is: against everyone except the operator. Narrowing that gap is on our security plan.

8.3 Disclosures because your setup said so

The main way information leaves NESA is the one you designed: a rung opens and delivers what the job you assigned entitles that person to see. Every such disclosure is recorded, and you are told afterwards that it happened. The screen showing the full record is still being built; until it ships, ask us and we will send it. This is not a privacy exception — it is the product.

8.4 Legal process

If we receive a subpoena, warrant, or other legal demand, we will review it, insist on proper process, and object to demands that are overbroad or unlawful. We will tell you before we produce anything, unless we are legally prohibited from doing so. Where a gag order applies we will challenge it where we reasonably can, and tell you as soon as we are permitted to.

There is a hard limit on what any demand can obtain. We can produce ciphertext, everything listed in 2.2, and the activation records in 2.4. We cannot produce the contents of your vault, because we cannot decrypt it. That is a property of the system, not a policy we could be ordered to change. Note that 2.2 is a real list, and a determined demand would reach all of it.

We intend to publish a transparency report covering the demands we receive and how we responded.

8.5 Business transfers

If NESA is acquired or merged, your information may transfer as part of it — as ciphertext, subject to this policy as it stands. We will tell you before it happens and give you the chance to export your vault and close your account first. An acquirer cannot decrypt your vault either.

8.6 How long we keep things

Items marked Live are running today. Items marked Committed are decided and being built; we are telling you the commitment rather than waiting until it runs, and you should hold us to it. Nothing here is aspirational. Retention runs on a scheduled job, so a sweep that stops running is a fault on our side and not a change to this table — we monitor for it.

What	How long
Vault contents (ciphertext)	While your account is active, then through the 60-day window in which you can take a copy, then erased	Live
Your people, their jobs and their responses	While the job exists; erased with the account. A declined ask is kept as a bare record that it was declined	Live
The account of a welfare concern, and the location payload	Stripped from the record 90 days after the alert closes. The row survives — what opened, to whom, when — but the words somebody wrote about you, and where you were, do not	Committed
The rest of the disclosure record	7 years. Long, deliberately: this is the record of what was done in your name and the basis of any dispute about it	Committed
Statements made under the rung-3 route	Permanent, and not deletable by anyone including us. See 7.3	Live
Notification records	90 days	Live
Liveness signals	30 days	Live
Messages in the group conversation	12 months after the alert closes	Committed
Broadcasts you send, including any location you shared	Erased with your account, and on a 12-month schedule before that. Today these persist until the account is erased, which is longer than it should be and is being fixed	Committed
Raw signal data — steps, motion, device state (Part 3)	30 days rolling. Evidence about the recent past; after a month it has no purpose	Committed
Historical step data queried at install	Same 30-day window, counted from collection	Committed
Your personal pattern	Held on your device only. Never uploaded. Gone when you uninstall or withdraw the permission	Committed
Billing records	As long as tax and accounting law requires, ordinarily 7 years	Live
Support correspondence	3 years, or sooner on request	Live
Technical and security logs	12 months, unless part of an active investigation	Live
Backups	Retired on a rolling schedule not exceeding 90 days	Live
Everything else	Erased with your account, and not before. Closed access grants, spent invitations, historical conversation keys and similar records currently have no schedule of their own. Giving each of them one is queued work and this row will shorten as it lands	Committed

Deleting your account

You can ask us to delete your account from your settings. When you do:

A 30-day window opens before erasure begins, and the people you named are told that you have asked. It is deliberately a pause rather than an immediate wipe, so a request made in a bad moment can be undone.
Coming back at all during that window cancels it. Signing in with your password, using your recovery key, opening the vault with Face ID or a passkey — any of them stops the erasure, and so does the app quietly restoring your session when you open it. We deliberately did not make undoing it a button you have to find: somebody who asked to close their account under pressure from another person is the last person who should have to be seen doing something deliberate to take it back.
Then everything above is erased, on the schedule shown, along with your vault ciphertext, your keys, your files, your invitations and your account. Take a copy of anything you want to keep first, because after this nobody can reconstruct it — not even us, and especially not us.

What survives, and why

We would rather list these than let "we delete everything" stand as a sentence that is not quite true.

The permanent statements in 7.3, which exist in order to be permanent.
Anything a legal obligation requires us to keep — chiefly billing records. We will tell you what, and for how long.
Infrastructure logs and database backups, which age out on their own cycles rather than on request. Backups do not exceed 90 days.
Anything anybody else already has. A document opened to somebody during an activation, and saved by them, is on their device. We cannot reach it.
Anything sent to our AI provider, per 4.3 — the one place your own content went outside our systems. Our deletion process cannot reach it; the provider deletes it within 30 days.
Your own devices, which hold your keys and any local copies until you remove the app.

8.7 Where your information is held

In the United States. NESA is offered only in the United States and we do not transfer personal information outside it in the ordinary course of the service.

8.8 Security

Our security program is described in full in the NESA Security and Data Protection Statement, which forms part of the Terms. In summary: encryption on your device with keys we do not hold; encryption in transit and at rest for everything else; a vault that unlocks separately from signing in, with Face ID or a hardware key as an option; no SMS used for anything security-critical; an append-only record of every disclosure; and no in-product administrator of any kind. Section 15.2 of that statement sets out our assurance programme and section 19 lists, in our own words, what is outstanding — including that there is no second factor on sign-in today, and that our written information security program is still to be produced.

No system is perfectly secure, and we do not claim otherwise. What we claim, specifically, is that a full compromise of our servers would not expose the contents of your vault.

8.9 If there is a breach

We maintain a written incident response plan with named roles and pre-drafted notifications. Putting a specialist breach law firm on retainer is on our plan and not yet done. If a breach affects your information we will notify you without undue delay and in any event within 60 days as required by the FTC Health Breach Notification Rule, and sooner where any state law or our own standard requires — we work to the shortest applicable clock and the broadest applicable trigger, and we aim to beat both.

8.10 Children and other people’s information

NESA is for adults. It is not directed to anyone under 18 and we do not knowingly collect information from children directly. Do not name a minor as one of your people or as an attester. If you believe a person under 18 has an account or has been named, write to privacy@getnesa.com and we will remove them.

Subscribers can store information about their dependants, including children, in the Dependants section of their vault. That information is encrypted and we cannot read it. The subscriber is responsible for having the authority to hold it. If you are that person, or their guardian, and you want to know what is held or ask for it to be removed, write to privacy@getnesa.com — we will help, within the limits of not being able to read it ourselves, and we will tell the subscriber.

The same applies to anyone else whose details appear in a subscriber’s vault — an emergency contact, a vet, a neighbour. Write to us and we will act.

Part 9 — Changes and contact

9.1 Changes to this policy

We will update this policy as NESA develops and as the law changes. The version and date at the top will change with it.

If a change is material — a new purpose, a new category of information, a new recipient, or any change to the three commitments in 5.2 — we will email you at least 30 days before it takes effect rather than rely on you noticing. We keep prior versions available so you can see what changed.

Two specific commitments. If we begin collecting a signal we do not collect today — health measurements are the obvious candidate — we will ask you separately and will not begin until you say yes. And if we ever build a feature that reads the contents of your vault, even on your own instruction, we will tell you before it ships and it will not be switched on for you by default.

9.2 Contact

Privacy, and any request under Part 6: privacy@getnesa.com

Security concerns and vulnerability reports: security@getnesa.com

Everything else: support@getnesa.com

Interim Adult, Inc., a Delaware corporation. Postal address available on request; we will accept privacy requests in writing if you prefer paper.