User Account Lifecycle Standard

User Account Lifecycle

This doc explains how we manage user accounts throughout their entire lifecycle on the Wealthy platform, from creation and active use to suspension and eventual deletion. This standard applies to all user types: customers, partners, and internal staff.

Stage 1: Onboarding / Account Creation

Customer Onboarding

The customer onboarding process is a self-service flow:

Registration → OTP Verification → KYC Verification → Profile Creation → Account Ready

1. Registration: A user registers through the mobile app or web application.
2. Verification: They verify their phone number with an OTP and complete the KYC process (PAN, Aadhaar, bank account).
3. Creation: Our system then creates their user profile, authentication credentials, and any necessary trading or investment accounts across our services (Hagrid, Fury, Taxy, etc.).

Partner & Internal Staff Onboarding

Partner and internal staff accounts are created by an administrator after the necessary agreements are signed or internal approvals are given. This includes provisioning access to specific systems based on their role.

Stage 2: Active Account Management

• Periodic Access Reviews: The security team and team leads conduct quarterly reviews of all user permissions and group memberships to ensure the principle of least privilege is maintained.
• Dormant Account Detection: Accounts with no login activity for over 6 months are flagged for review. If an account is inactive for 12 months, we notify the user and may suspend the account if there is no response.
• Permission Change Tracking: All changes to permissions are logged with details on who made the change, who it affected, what was changed, and why.
• Business Ownership Validation: All partner, internal staff, and privileged accounts must be associated with an approved business requirement and a designated business owner.
• Access Request Process: User accounts and access are provisioned only after formal approval through ticketing systems such as Plane or Freshdesk. For urgent requirements, users may email the DevOps team directly while keeping senior stakeholders like CTO and respective manager in CC.
• Access Deactivation: Once the assigned work is completed or the user is no longer required, the respective manager or department head raises a sunset request for access removal.
• Unassigned Accounts: Any account that cannot be associated with an active business process or designated business owner is disabled accordingly.

Stage 3: Account Suspension

An account may be suspended for several reasons:

When an account is suspended, login and transactions are blocked, but existing investments are maintained. The user is notified, and the decision is documented.

Stage 4: Soft Delete (Account Deactivation)

A soft delete is the primary mechanism for account deletion. It anonymizes the user’s PII while retaining transaction records for regulatory compliance.

Pre-Conditions

Before an account can be deleted, the following must be true:

• The client has no active investments under Wealthy’s management.
• The client is not part of a family account.
• There are no pending transactions awaiting settlement.

Process

1. The user requests account deletion through the app or support.
2. The system verifies the pre-conditions have been met.
3. The user’s PII (like phone number and PAN) is scrubbed from their profile. The email address is retained for the audit trail.
4. Authentication is disabled, and non-essential data is removed.
5. The user is notified of the successful deactivation.

Stage 5: Hard Delete (Permanent Removal)

A hard delete permanently removes all user data from our systems. This occurs automatically 1 year after the soft delete to comply with SEBI’s record retention requirements.

After a hard delete, no user data remains, and the user cannot be reactivated. They would need to register for a new account if they wish to return.

Stage 6: Reactivation

A user can request to reactivate their account only during the 1-year soft-delete retention period. This requires identity verification and fresh KYC.

Data Retention Matrix

Privileged Access — Tier Definitions & Review Cadence

Implements Privileged Access Management Policy (POL-018). Privileged access is never standing — it is granted just-in-time to a named person for a specific task and reclaimed when the task ends. The tier a grant falls into drives approval authority + review cadence.

Review procedure (for every tier)

1. Access owner (CTO for Tier 1, respective lead for Tier 2/3) pulls the current grant list from IAM / GKE / Workspace admin / Vault / Artifact Registry audit logs.
2. Each grant is validated against: is the person still in that role? Was the grant used since last review? If not used, is it still needed?
3. Unused grants are revoked; needed grants are re-attested.
4. Report summary goes to ISRMC (Tier 1, 2) or the team lead’s sprint review (Tier 3). Evidence filed with GitHub Issue label access-review.
5. Break-glass accounts (Tier 1): every use is a quarterly-reported event with a post-use review, regardless of cadence.

Emergency elevation (break-glass)

If a production incident requires elevated access outside the standard approval flow:

1. On-call SRE calls CTO (or CISO when appointed); CTO grants the minimum access required for the incident.
2. Access is time-bound (typically minutes to hours). Ticket raised in parallel for the audit trail.
3. Access is reclaimed when the incident closes; post-incident review logs the grant.
4. Unused emergency elevations are treated as a finding at the next access review.

Service accounts — non-human privileged identities

Service accounts with privileged access follow the same tier model as humans, with two differences:

• No JIT flow; access is configured and persistent. Tier is assigned based on the blast radius if the key leaked.
• Authentication is workload identity (no key files) where possible. Where a key is unavoidable, it rotates quarterly per POL-018.
• Tier 1 / 2 service accounts are listed in the Access Review report alongside human accounts.

Related Documents

• Authentication & Authorization (STD-003)
• Endpoint Security Standard (STD-009)
• Privileged Access Management Policy (POL-018)