Money, property & valuablesImportant documents & WillMedical wishes & emergency infoMemories, stories & voice notesRelationships & trusted people
Security & privacyHow Soult worksExecutor & handover flowLegal validitySecurity WhitepaperBlog & life guidesHelp centreAbout Soult
Pricing
Corporate Employee WellnessChannel Partners
My AccountStart Protecting Today
🛡Security Whitepaper

Architecture crafted for
life's continuity.

A transparent account of the technology behind your digital life vault. We move past cold industrial jargon to provide a secure, human-centric bridge for your family.

01Crafted infrastructure

System design

Practical perspective

Where does my data actually live?

We use Amazon's top-tier data centres in Mumbai (ap-south-1), with AWS Hyderabad (ap-south-2) as our backup region. Our system is “serverless,” meaning no computer stays on for hackers to poke at.

Technical logic

100% AWS Lambda. Multi-region redundancy (ap-south-1, ap-south-2). Fresh execution context per request.

01aSilo architecture

Region-locked silos

Practical perspective

Where does each user's data go?

When you sign in, an Identity Directory checks your country and routes you to the right silo. Today only the India + GCC silo is live. Indian users sit there by default. GCC users sit there too, with explicit consent at signup. Each future silo stays isolated — data never crosses.

Technical logic

Edge: CloudFront + Route 53. Identity Directory routes by phone/email to region. No PII stored in directory. Today: India + GCC silo (ap-south-1, ap-south-2). Roadmap: US silo (us-east-1, us-west-2), SEA silo (ap-southeast-1, ap-southeast-3), dedicated GCC (me-central-1 when stable).

02Partnership

Why AWS Mumbai?

Practical perspective

Local compliance and security.

AWS Mumbai provides the strongest data-centre footprint in India. Staying on Indian soil ensures your legacy follows local laws and remains available to your family without complications.

Technical logic

Multi-Region DR strategy. Failover endpoints in ap-south-2. Native Cognito localised phone support and FIPS 140-2 compliant cryptographic modules.

03Identity access

Authentication flow

Practical perspective

Sign up and log in safely.

Registration: verified via Phone OTP and Email OTP. You set a security question and a 4-digit MPIN. Trusted use: daily access requires only your 4-digit MPIN. New device: triggers 2-factor security — phone OTP first, then your MPIN.

Technical logic

Multi-channel OTP verification. Credentials: salted, slow-hashed security answer and MPIN. Re-auth on new device triggers 2FA logic.

04Household privacy

MPIN on shared devices

Practical perspective

Why can't my family open this?

In shared-phone homes, fingerprints allow anyone enrolled to enter. A private 4-digit PIN keeps your vault private while kids play games or your spouse uses the phone.

Technical logic

4-digit MPIN stored as a salted, slow hash on the server. Server-side validation with a 3-strike lockout counter stored in DynamoDB. Lockout duration: 24 hours. Reinstall, device wipe, or device change does not reset.

04aThe PIN-length choice

Why a 4-digit PIN?

Practical perspective

Is 4 digits really secure?

Yes — because the protection is the lockout, not the length. Three wrong tries and your vault locks for 24 hours. Even a thief with your phone gets only 3 guesses before the door slams shut. We chose 4 over 6 deliberately: longer PINs cause more forgotten codes, lockouts, and resets — and memory complexity is the real enemy of security in practice, not raw entropy.

Technical logic

4-digit search space: 10⁴ = 10,000. Brute-force mitigation: server-side counter, 3-strike lockout for 24 hours. Practical entropy with lockout exceeds raw entropy of unprotected 6-digit. Trade-off accepted: usability gain > marginal entropy gain.

05Storage safety

Hard drive risk

Practical perspective

What if someone steals a hard drive?

Data is AES-256 encrypted at rest. Stolen hardware contains only meaningless ciphertext. Master keys live in separate secure hardware modules, never on the same disk as the data.

Technical logic

S3 SSE-KMS and DynamoDB encryption. AES-256-GCM used for authenticated encryption. Bucket policies enforce encryption at-write.

06Authority

Key management (KMS)

Practical perspective

Who holds the keys?

Amazon's hardware security modules hold them. Soult staff never see them. Think of a hardware safe whose lock only recognises a key the system itself constructs — no human ever holds the physical key.

Technical logic

Envelope encryption via AWS KMS. Customer Master Key (CMK) stays in HSM. Data keys generated per envelope, encrypted under CMK, never exported in plaintext.

07The double lock

Field-level security

Practical perspective

Double-lock security for your most sensitive fields.

For your secrets (Will IDs, policy numbers, account numbers), we add a second lock. Inside our database, those specific fields look like scrambled gibberish even to engineers with database access.

Technical logic

KMS Field-Level Encryption applied to high-sensitivity columns. Unauthorised table reads cannot expose high-sensitivity content without specific IAM rights.

08The tunnel

Encryption in transit

Practical perspective

Spy-proof Wi-Fi.

Data travels through a secure TLS tunnel. Anyone snooping on public airport or café Wi-Fi sees only encrypted gibberish — nothing about what you upload or read.

Technical logic

TLS 1.2+ minimum (TLS 1.3 preferred). API Gateway HTTPS enforcement. CloudFront signed URLs (15-minute expiration) for direct asset reads.

09Staff boundaries

The “no-human” principle

Practical perspective

Can Soult staff see my secrets?

No. We built a restricted access mechanism. Staff have no “decrypt” button for your vault. Your content is scrambled code to our engineers in normal operations.

Technical logic

Zero human kms:Decrypt permission for user vault keys in routine IAM policies. Least-privilege IAM across all roles. No individual holds “full access” credentials.

10Executor roles

Two executor roles

Practical perspective

Who can ever see my vault?

Regular Executor (typically a family member): has their own dashboard listing the users they manage. Can raise a death or medical incapacity flag. OTP verified at every step. Every step emails you AND every executor you named.

Emergency Executor (typically the spouse, only one allowed): no flag check needed. Can log in to your vault any time. While they are in, your vault becomes read-only for you. You get an email instantly.

The emergency role is for medical emergencies and time-critical situations. The regular role is for handover after death or long-term incapacity.

Technical logic

Strict RBAC. Two role classes: EXECUTOR_REGULAR (multiple allowed) and EXECUTOR_EMERGENCY (max 1, spouse only). Regular role gates on vault_accessible_flag = true; emergency role bypasses flag. Every state transition fires Amazon SES notifications to user and all named executors. Forced READ_ONLY state on user account when emergency executor is logged in.

11The legacy handover

Handover protocol

Practical perspective

How does my family actually get access?

The named Regular Executor raises a flag from their dashboard — death or medical incapacity. Each step is OTP-verified. Every step emails you and all your other executors, so nothing happens behind your back. Soult phones the executor on the registered number to confirm identity. Government registries (CRS and KRA) are used as a cross-check, but treated as supporting evidence only — records often take months to update. Direct phone and email contact with the executor and family is the primary verification. Two internal Soult approvers must both sign off before access is granted. The executor then sees the entire vault in read-only mode.

Technical logic

Multi-step gate: (1) executor flag raise from dashboard with OTP, (2) outbound phone verification, (3) CRS/KRA cross-reference (advisory), (4) two-person internal approval, (5) vault_accessible_flag set to true. All transitions logged to append-only audit log. Notifications via Amazon SES to user + all executors at every step. Read-only enforcement at API layer; no write/delete endpoints exposed to executor session.

11aSharing reality

No sharing, by design

Practical perspective

Can I share one document with my CA or spouse?

Not today. Your vault works like a private locker — only you have the key. There is no per-item sharing, no per-folder access for an accountant, no time-limited share link. The only way another person ever sees inside your vault is through the executor flow described above — and even then, they see everything in read-only mode. There is no per-item or per-folder granularity yet.

Technical logic

No collaboration mechanism implemented. Sole access paths: (1) authenticated owner session, (2) executor session post-verification. No share-link generation, no scoped tokens, no per-resource ACL. Roadmap consideration only — not built.

12Honesty

Reality check

Practical perspective

What are the risks?

We protect against hackers, account takeover, and insider access. We cannot stop you from being physically forced to share your PIN. Soult is for organisation and family continuity — not protection from a coerced disclosure under duress.

Technical logic

Threat model excludes physical coercion. Mitigates: exfiltration, account takeover, insider access. Out of scope: PIN extraction under duress, device compromise post-unlock.

13Sovereignty

Indian soil

Practical perspective

Where exactly does my data live?

Today, all user data sits in the India + GCC silo — Mumbai for live traffic, Hyderabad as the disaster recovery mirror. Indian users by default. GCC users with explicit consent at signup, since they share the same physical location. Future silos for the US, Southeast Asia, and a dedicated UAE region will be deployed as we expand. Each silo stays isolated — data of users from one region never crosses into another.

Technical logic

Active silo: ap-south-1 (Mumbai) primary, ap-south-2 (Hyderabad) DR. Live replication; failover automated. DPDP Act 2023 compliant. GCC users included in this silo with documented consent and standard contractual clauses on file.

13aDisaster tiers

Disaster recovery tiers

Practical perspective

What happens at each level of failure?

Tier 1 — one server fails: invisible to users, AWS replaces in minutes.
Tier 2 — Mumbai region down: Hyderabad takes over within an hour. No data loss.
Tier 3 — both regions down at once: service stops. Operational recovery in 7–14 days. Full data integrity verified within 60 days.
Tier 4 — every Indian region destroyed: we cannot recover today. Cross-silo backup replication is on the roadmap as we add the US and SEA silos. Until then, manual user backup is the strongest mitigation.

Technical logic

Tier 1: AWS EC2 / Lambda self-healing. Tier 2: cross-AZ failover < 1hr. Tier 3: RTO 7–14d (operational), RPO up to 60d (full data integrity verified). Tier 4: not mitigated today; cross-silo replication into us-east-1 / ap-southeast-1 on roadmap.

14Visibility

The audit trail

Practical perspective

Record of changes.

A complete footprint of every Create, Update, or Delete on your vault. You and your nominated notifiers will always know exactly what changes have occurred.

Technical logic

Append-only audit log. Tracks write operations (CUD). Read events excluded for user privacy and performance balance.

14aUsage limits

Data usage boundaries

Practical perspective

No selling, no training, no surprises.

Your vault content is never used to train AI models or for marketing. When AI features are used in the app, the data for that session is processed in-context only — never retained for model improvement. Revenue is subscription-only. If we ever consider a new way of earning — any change at all — we will ask you first. Not notify. Not announce. Ask. And we will only ask if we genuinely believe it benefits you.

Technical logic

Data isolation. No vault content fed into AI/ML training pipelines. AI features process data in-context per session only — no retention for model improvement. Revenue model independent of vault content. Future monetisation changes gated on explicit per-user opt-in — not announce-and-proceed.

14bThe handover tension

Privacy vs handover

Practical perspective

The bridge choice.

Chat apps focus on absolute secrecy — if you lose a key, they can't help you. That is a failure for a life vault. We prioritise verified handover over total blindness. We keep staff out but maintain a human-verified path for family. Soult is a bridge to your legacy, not a digital dead end.

Technical logic

KMS-managed key recovery model, gated on verified death or incapacity events only. No staff-side decrypt during normal operations; recovery path requires the multi-step gate described in §11.

15Future path

Roadmap

Practical perspective

What is shipping next?

Near-term: one-click vault export (today users back up manually); US silo (N. Virginia, DR Oregon); SEA silo (Singapore, DR Jakarta); cross-silo backup replication so something always survives even if a whole region is lost.

Mid-term: dedicated GCC silo when AWS UAE region matures; SOC 2 Type II.

Always-on: ongoing audits, security hardening, infrastructure reviews.

Technical logic

Phase 1 (active): one-click encrypted export, US silo bring-up. Phase 2: SEA silo, cross-silo cold backup replication, WAF, SSL pinning on mobile clients. Phase 3: dedicated me-central-1 silo, SOC 2 Type II, hardened multi-region KMS.

16Veracity

Honest claims

Every marketing claim, checked. What is true today, what is planned, what is not built, what we do not use.

ClaimStatusThe practical truth
Staff-inaccessible vaultTRUEIAM locks prevent humans from seeing content during normal ops.
Data residency in IndiaTRUEAll data stays strictly within India (Mumbai / Hyderabad).
ISO 27001 & ISO 9001 certifiedTRUEIndependently audited security and quality management. 27001 PDF ↓ · 9001 PDF ↓
AES-256 encryptionTRUEAll vault contents encrypted with industry-standard AES-256-GCM.
One-click vault exportPLANNEDNot built today. Users take manual backups. Coming in an upcoming release.
Per-item sharingNOT BUILTNo sharing or collaboration today. Executor flow is the only access path.
Cross-silo backupROADMAPBackup replication across silos comes when US/SEA silos deploy.
Recovery if both Indian regions fail7–14d / 60dOperational recovery 7–14 days. Full data integrity verified within 60 days.
Account deletionIMMEDIATE10-second confirmation, then permanent key destruction.
AI training on user dataNEVERVault content is never used for AI model training, even when AI features are used in-session.
BlockchainNOT USEDWrong tool for a private vault. We use audit logs instead.
Zero-knowledge architecture (full vault)PLANNED 2026Today: KMS-managed envelope encryption with staff-inaccessible IAM. Full zero-knowledge across the vault is a roadmap item, not a current claim.
17 — Support & Erasure

Common questions

How do I delete my data?

Deletion is immediate and permanent. After a 10-second confirmation pause, we destroy your encryption key. Old backups become unreadable from that moment. Take a manual backup first if you want to keep anything — the one-click export feature is coming in an upcoming release.

What if Soult shuts down?

We open a 90-day sunset window. You download everything in plain readable formats. We will not sell your data, transfer your vault to a buyer without consent, or delete vaults during this window.

How are subscriptions billed?

Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.

Erasure protocol details?

Immediate user-key revocation across primary, replica, and any backup storage. Stored ciphertext rendered globally unreadable. Sunset window: 90 days, mandatory; reminders weekly via Amazon SES; sale or transfer of vaults gated on per-user consent.

18 — Common Myths

Why doesn't Soult use blockchain?

Blockchain is built for public verification on shared ledgers where parties do not trust each other — cryptocurrency, supply chains across rivals, public land records. Its strength is making tampering visible to the world.

Soult vaults are the opposite of public — they are private by design. The user is the only party with stake in the data. Tampering intent is low: it is the user's own data, kept for the user's own family.

For change tracking, we use audit logs (see section 14) — every Create, Update, Delete is recorded with timestamp and actor. Blockchain would add cost, complexity, and reduce privacy by exposing patterns to a public ledger — without solving any user problem.

Reconsidered if and when verified-public attestation becomes a real user requirement.

More on what Soult can and cannot do — read the Legal Validity page. For the executor protocol in detail, see Executor & Handover Flow.

Get Started Free →
Available on iOS & Android

Your Digital Life and Afterlife,
Secured.

Useful every day — organise your assets, memories and important documents in one private vault. Built to pass everything on to your family exactly as you intend, whenever the time comes.

Rated 5.0/5 — every review.
16 on App Store · 18 on Google Play · 34 total
Your vault is encrypted at every layer — AES-256 at rest, TLS in transit, and unlocked only by you.
ISO/IEC27001CERTIFIEDISO 27001 ↓Information SecurityISO9001CERTIFIEDISO 9001 ↓Quality Management
AES-256Encryption in transit & at rest
AWSAWSSecure Cloud Hosting