Honest, Transparent Security
We don't claim 'military-grade' or 'unbreakable' because those are marketing lies. Here is the complete, honest truth about how we protect your legacy, written for humans.
Architecture Overview
Where does my data actually live?
We use Amazon's top-tier data centers in Mumbai, with AWS Hyderabad as our backup fallback. Our system is serverless, meaning no computer stays on for hackers to poke at.
- Serverless: AWS Lambda, DynamoDB, S3, Cognito.
- Primary Region: ap-south-1 (Mumbai).
- Disaster Recovery: ap-south-2 (Hyderabad).
Data Residency & Silos
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. Each future silo stays isolated — data never crosses.
- Cognito Pre-Authentication Trigger routes users.
- Each silo has its own isolated database and file store.
- Cross-silo access is blocked by IAM policies.
Why AWS Mumbai?
Why AWS Mumbai for local compliance and security?
Amazon Mumbai provides the highest standard of security in India. Staying on Indian soil ensures your legacy follows local laws and remains available to your family without complications.
- DPDP Act 2023 compliance for Indian data.
- AWS infrastructure is ISO 27001, SOC 2, and FIPS 140-2 certified.
- Physical security managed by AWS.
Identity & Login
How do I sign up and log in safely?
Registration: Verified via Phone OTP and Email OTP. You set a security question and a 4-digit PIN.
Trusted Use: Daily access requires only your 4-digit PIN.
New Device: Triggers 2-Factor Security: Phone OTP first, then your PIN.
- AWS Cognito for user identity management.
- AWS SNS for SMS-based OTP delivery.
- AWS SES for email-based OTP delivery.
Shared Device Safety
Why can't my family open my vault app on a shared phone?
In shared-phone homes, fingerprints allow anyone registered to enter. A private 4-digit PIN keeps your vault private while kids play games or your spouse uses the phone.
- MPIN is app-specific, not device-wide.
- Biometrics (fingerprint/face) are a device-level convenience, not a Soult security layer.
- PIN is stored securely in device keychain/keystore.
- Session tokens expire and require re-authentication.
Why a 4-Digit PIN?
Is a 4-digit PIN really secure enough?
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 — 6 digits cause too many forgotten PINs, lockouts, and resets.
- Brute-force protection: 3 attempts trigger a 24-hour lockout.
- Lockout is enforced server-side via Cognito.
- PIN is never transmitted to the server; only a derived token.
- User experience decision to balance security and usability.
Data-at-Rest Encryption
What if someone steals a hard drive from your servers?
Data is AES-256 encrypted. Stolen hardware only contains meaningless characters. Master keys stay in separate secure hardware safes.
- DynamoDB tables encrypted at rest using AWS-owned keys.
- S3 buckets use Server-Side Encryption with KMS (SSE-KMS).
- All backups and snapshots are also encrypted.
Encryption Key Authority
Who holds the encryption keys?
Amazon's hardware holds them. Soult staff never see them. It's like a bank vault where the machine only recognizes your key.
- AWS Key Management Service (KMS) manages all master keys.
- KMS uses FIPS 140-2 validated Hardware Security Modules (HSMs).
Double-Lock Security
What is the double-lock security for sensitive fields?
For your secrets such as Will or Policy IDs, we add a Double Lock. Inside our database, those specific fields look like scrambled gibberish even to engineers.
- Client-side field-level encryption for designated sensitive data.
- Data is encrypted on the user's device before being sent to our servers.
Data-in-Transit Tunnel
Is my data protected on public Wi-Fi?
Data travels through a secure tunnel. Hackers on public airport Wi-Fi cannot see what you upload or read.
- TLS 1.2 or higher enforced for all API and data transfers.
- CloudFront provides an additional layer of protection against network attacks.
- File uploads use pre-signed S3 URLs, limiting direct API exposure.
Staff Access Boundaries
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.
- IAM roles follow the principle of least privilege.
- No direct production database access for developers.
- All administrative actions are logged and audited.
Executor Access Roles
Who can ever see my vault?
Regular Executor: Can raise a death or medical incapacity flag with OTP verification at every step.
Emergency Executor: (Spouse only, max one) can log in any time. Every action emails you and all named executors instantly.
- Role-Based Access Control (RBAC) implemented in application logic.
- Executor roles are stored as attributes in DynamoDB.
- State machine (AWS Step Functions) manages the handover process.
- Amazon SES sends transactional email notifications for all access events.
Family Handover Flow
How does my family actually get access to my vault after I pass?
The named Regular Executor raises a flag from their dashboard — death or medical incapacity. Each step is OTP-verified. Soult phones the executor to confirm identity, two internal approvers must both sign off, then the executor sees the vault in read-only mode.
- Multi-step verification process: OTP, phone call, dual internal approval.
- Handover state is managed in a dedicated DynamoDB table.
- Internal approval uses a secure, audited admin panel.
- Executor access is granted via a temporary, read-only IAM policy.
No Per-Item Sharing
Can I share one document with my CA or spouse today?
Not today. Your vault works like a bank locker — only you have the key. There is no per-item sharing, no per-folder access for an accountant, no time-limited share link.
- Current architecture is single-tenant access per vault.
- Granular sharing (per-item, per-folder) is a significant architectural change.
- Focus is on post-mortem handover, not active collaboration.
- This simplifies the security model and reduces attack surface.
Real-World Risks
What are the security risks I should know about?
We protect against hackers. We cannot stop you from being physically forced to share your PIN. Soult is for organisation and family continuity.
- Threat model focuses on remote, technical attacks.
- Does not protect against coercion, social engineering, or physical threats to the user.
Data on Indian Soil
Where exactly does my data live and is it on Indian soil?
Today, all user data sits in the India + GCC silo — Mumbai for live traffic, Hyderabad as the disaster recovery mirror. DPDP Act 2023 compliant.
- Primary: AWS ap-south-1 (Mumbai).
- DR: AWS ap-south-2 (Hyderabad).
- Data is not transferred outside these regions for Indian users.
- Complies with data localisation requirements.
Disaster Recovery Tiers
What happens if a server or entire region fails?
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: Service stops, operational recovery in 7–14 days.
Tier 4 — Soult shuts down: 90-day data export window for all users.
- AWS Auto Scaling for single-instance failure.
- DynamoDB Global Tables for cross-region replication.
- Route 53 DNS failover for regional outages.
- Business continuity plan for existential threats.
Immutable Audit Trail
Is there a record of every change made to my vault?
Yes. There is a footprint of every Creation, Update, or Deletion. You and your notifiers will always know exactly what changes have occurred.
- Append-only ledger using Amazon QLDB or DynamoDB Streams.
- Every mutation (Create, Update, Delete) is logged with user, timestamp, and payload hash.
- Audit logs are not user-deletable.
Data Use Limitations
Is my data ever used to train AI or sold to advertisers?
No. Your vault content is never used to train AI models or for marketing. Revenue is subscription-only. If we ever consider any new way of earning, we will ask you first — not notify, not announce — ask.
- Business model is subscription-based (SaaS), not data monetization.
- Terms of Service explicitly forbid use of user data for AI training.
- Technical access controls prevent data scientists from accessing vault content.
- No third-party marketing trackers in the core application.
Secrecy vs. Legacy
How can Soult hand over my vault if staff cannot see it?
We keep staff out but maintain a human-verified path for family. We use a KMS-Managed Key Recovery model for verified death/incapacity events only.
Soult is a bridge to your legacy, not a digital dead end.
- Break-glass procedure using a quorum of authorized officers to initiate KMS key access for handover.
Future Roadmap
What security features are coming next?
Near-term: One-click vault export, US silo (N. Virginia), SEA silo (Singapore).
Mid-term: Dedicated GCC silo, SOC 2 Type II.
Always-on: Ongoing audits, security hardening, infrastructure reviews.
- Regular penetration testing by third-party firms.
- Continuous monitoring with AWS GuardDuty, Security Hub.
- Dependency scanning and automated patching.
Honest Claims
The security industry is full of misleading buzzwords. Here’s what we claim, what we don’t, and why. We believe transparency is the highest form of security.
| Claim | Status | The Honest Truth |
|---|---|---|
| AES-256 Encryption | TRUE | Standard for all data at rest and in transit. This is the industry-standard, not a special feature. |
| Indian Data Residency | TRUE | All Indian user data is stored and processed in AWS Mumbai, with DR in Hyderabad. Compliant with DPDP Act 2023. |
| Serverless Architecture | TRUE | Reduces attack surface. No long-running servers to compromise. We use AWS Lambda, DynamoDB, S3. |
| Zero-Knowledge | TRUE | For double-locked fields only. Our staff cannot decrypt these specific fields. We are not a fully zero-knowledge system by design, to allow for family handover. |
| ISO 27001 Certified | PLANNED | Our infrastructure (AWS) is certified. Soult as a company is not yet certified, but we follow ISO 27001 principles. Certification is planned. |
| End-to-End Encryption | NOT BUILT | Not currently implemented. Data is encrypted in transit (TLS) and at rest (AES-256), but not end-to-end in the Signal/WhatsApp sense. |
| SOC 2 Type II Compliant | ROADMAP | This is a goal on our roadmap. It requires a lengthy audit process that we plan to undertake as we mature. |
| Military-Grade Security | MARKETING | This is a meaningless marketing term. We use specific, verifiable standards like AES-256 and FIPS 140-2. |
| Permanent Deletion | IMMEDIATE | When you delete your account, we cryptographically shred your data by destroying the encryption key, rendering all backups useless. |
| Unbreakable / Hack-Proof | NEVER | No system is unbreakable. We focus on multiple layers of defense, rapid detection, and transparent communication. |
| Blockchain | NOT USED | Blockchain is the wrong tool for this job. It's for decentralized, public trust. We need centralized, private trust. We use an immutable audit log instead. |
Data Deletion & Business Failure
How do I delete my data permanently?
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.
What happens 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 subscription payments handled?
Managed via Razorpay on the Soult website. No in-app purchases. This keeps billing separate from your vault device.
Common Myths
Why doesn't Soult use blockchain?
Blockchain is built for public verification on shared ledgers where parties do not trust each other. Soult vaults are private by design.
For change tracking, we use audit logs — every Create, Update, Delete is recorded with timestamp and actor. Blockchain would add cost, complexity, and reduce privacy without solving any user problem.
- Use case mismatch: Blockchain is for decentralization and transparency.
- Soult requires centralization and privacy.
- Immutable logs (QLDB) provide tamper-evidence without blockchain overhead.
- Performance and cost of blockchain are prohibitive for this application.
