Security & Trust

Yes, technically we can — and we want to be upfront about that rather than let "AES-256 encrypted" imply something it doesn't.

Here's exactly how it works: every file and every piece of written content is encrypted before it's stored, using a unique encryption key generated specifically for that item (never reused across files). That per-item key is itself encrypted by a master key that only our server holds. In practice, this means:

• Nothing is ever stored as plain, readable text or files on disk — everything sits encrypted at rest.
• Because our server holds the master key, we have the technical ability to decrypt your content — for account recovery, to help your family after a loss, or to support you if something goes wrong.
• We do not access your content outside of those situations. Every time content is decrypted, an internal record is created — what was accessed, when, and by what process (a real user download, or an internal script) — so this isn't just a promise with nothing behind it.

What this doesn't mean: this is not a "zero-knowledge" system where even we couldn't read your data if compelled to. A handful of providers offer that model, but it comes with a real trade-off — if you forget your password or pass away, a truly zero-knowledge vault becomes permanently unopenable, for anyone, including your family. We've made the opposite trade-off deliberately: your family can actually get access when it matters most, and the cost of that is us holding the technical ability to decrypt, used only for legitimate account recovery and support.

This is the entire premise of the product, so we want to answer it honestly rather than with something vague.

Because we hold the encryption key (see above), your vault does not become permanently locked if you're no longer able to provide a password. Your family will be able to regain access.

What we haven't finished yet: the actual step-by-step process for how a family member proves who they are and requests that access — what documentation we ask for, how long it takes, who at KithKeep handles it — isn't formalized or published yet. We're not going to pretend this is fully built when it isn't. This is one of the next things we're working on, and we'll update this page with the real process once it exists, rather than describe something aspirational.

In most places, a valid will has to be the physical, signed, witnessed original — a photo or PDF of it generally has no legal force on its own.

Store your documents in KithKeep so your family can find them, understand what exists, and know where to look. Keep the signed original somewhere physical and secure, and make sure someone knows where that is.

(Note: a "Where is the original document kept?" field next to legal documents is planned but not yet built. Once it exists, this section will point to it directly.)

We don't have a finalized, published policy for this yet — no committed notice period, no one-click export tool, no written wind-down commitment.

We're saying that plainly rather than making something up. This is a real gap we intend to close before this page is considered complete, and before we'd feel comfortable calling KithKeep launch-ready in the fullest sense.

We don't yet have a finalized policy for what happens to your data if your plan lapses or you're over your storage limit after a downgrade.

What we can commit to now: we will never delete a deceased family member's voice recordings or stories for non-payment. Beyond that specific commitment, the detailed policy (grace periods, read-only access, etc.) is still being worked out, and we'll publish it here once it's real.

Your data is hosted on Render, in Oregon, United States.

Encrypted backups of the database exist. Right now, this is done manually rather than on a fully automated recurring schedule — we're working toward a real, scheduled backup policy and will update this page with the specifics (frequency, retention, geographic redundancy) once that's in place.

I'm Rajan Gurung, the founder of KithKeep.

I didn't start this because of one dramatic personal story — I started it because I looked closely at what actually goes wrong for families, and the pattern was hard to ignore. The most common failure isn't a missing document, it's that nobody knows where the document is when it matters. Existing tools mostly stop at document storage — they don't help you hold onto the things that actually mattered about a person: their voice, their stories, the way they wanted to be remembered. And in aged care specifically, there wasn't really a tool built for this at all.

That gap — practical and emotional, together, in one place — is what KithKeep is trying to fill. I'm building it as a solo founder right now, which means when something's wrong, there's a real person on the other end who'll actually fix it, not a support queue.

We don't yet have a defined retention policy for this scenario. It's a real, open question we intend to answer as part of the broader data-retention and shutdown-policy work above, rather than a separate decision made in isolation.