Seniour Lysphere logo

Seniour Lysphere

Johannesburg, South Africa

Privacy Statement

We approach your personal details with the seriousness they deserve. This document explains how information arrives in our hands, what happens to it once it's here, and the choices available to you along the way.

Current as of January 2025

Information Lifecycle and Journey

When someone registers for our services at Seniour Lysphere, details emerge naturally through forms, correspondence, and system interactions. We're not gathering information for its own sake—each piece serves a function tied directly to the financial decision-making tools we provide.

What Arrives and How

Account creation brings us your name, email, and sometimes a phone number. These basics let us establish communication pathways. When you dive into our platform's features—comparing financial products, running scenarios, setting preferences—we learn about your priorities. Not through surveillance, but through the choices you make within the tools themselves.

Technical data flows in automatically. Server logs capture IP addresses and browser fingerprints. These aren't identifiers we requested, but they arrive nonetheless as part of how the internet works. We keep them because they help us spot security issues and understand where our systems strain under load.

  • Identity markers: full names, email addresses, contact numbers you choose to share
  • Interaction patterns: which comparison tools you engage with, what parameters you adjust, how often you return
  • Technical footprints: device identifiers, connection metadata, session timestamps
  • Communication records: messages sent through our support channels, feedback submissions, inquiry history

Purpose Behind the Intake

Financial comparison requires customization. If someone's exploring mortgage options versus investment accounts, showing both sets of data equally makes the platform less useful. We store preference data so the interface adapts—surfaces relevant tools first, remembers calculation assumptions, maintains continuity across sessions.

Security demands logging. When an account shows unusual access patterns from new locations or devices, we need historical records to validate legitimacy. Authentication processes lean on these logs. So do investigations when something goes wrong.

Improvement depends on usage patterns. We analyze aggregate behavior to identify where users get stuck, which features go unused, what workflows feel clunky. Individual sessions blend into statistical trends that guide development priorities.

Data Handling and Movement

Information doesn't sit static in our systems. People on our team access it for specific operational reasons. Support staff pull account details when troubleshooting reported problems. Engineers review technical logs during system diagnostics. Analysts work with anonymized usage data when evaluating feature performance.

Internal Access Controls

Access follows role logic. Customer service sees contact information and service history. Financial analysts never touch personally identifiable data—they work with stripped-down, aggregated datasets. System administrators have broader technical access but operate under monitored conditions with activity logging.

Key principle: We grant data access based on job necessity, not hierarchical position. Someone's seniority doesn't automatically expand their visibility into user information.

When Information Leaves Our Control

External movement happens under three conditions. First, when you explicitly request it—if you ask us to coordinate with a financial institution on your behalf, we share whatever's needed to complete that task. Second, when service providers require it—hosting infrastructure, email delivery systems, backup services all receive relevant data subsets. Third, when legal obligations demand it—court orders, regulatory inquiries, law enforcement requests that meet procedural standards.

Third-party vendors operate under contracts that limit how they handle information. They're tools for us, not independent data controllers. Cloud hosting providers store encrypted databases but can't decrypt content. Email services relay messages without retaining copies. These aren't perfect isolations, but they create structural barriers against misuse.

  • Infrastructure hosts maintaining servers and database systems in geographically distributed centers
  • Communication platforms handling email delivery, SMS notifications, and system alerts
  • Analytics services processing anonymized usage statistics for performance insights
  • Security vendors monitoring threat detection and providing fraud prevention layers

We don't sell user data. Never have. The business model doesn't depend on monetizing personal information through advertising networks or data brokers. Revenue comes from service subscriptions, not data extraction.

Protection Framework and Residual Risk

Security measures exist in layers. Databases encrypt data at rest using industry-standard algorithms. Transmission happens over TLS connections. Application code sanitizes inputs to prevent injection attacks. Authentication systems enforce multi-factor verification for sensitive operations.

What Safeguards Can and Cannot Do

Encryption protects against unauthorized access by external attackers and limits damage from hardware theft. It doesn't prevent misuse by authorized personnel who decrypt data for legitimate purposes. Access controls reduce insider risk but can't eliminate it entirely—someone with valid credentials who decides to act maliciously operates within system permissions until detected.

Monitoring catches anomalies after they occur. We log system events, review access patterns, and scan for suspicious activity. This creates accountability and enables forensic investigation. But detection always lags behind action—there's an unavoidable window between when something happens and when automated systems flag it for human review.

Honest assessment: No security architecture is impenetrable. We minimize risk through technical controls and organizational policies, but vulnerability exists in any system that stores and processes information. Breaches remain possible despite prevention efforts.

Incident Response Approach

When security events occur—unauthorized access attempts, system compromises, data exposure incidents—we follow a documented response protocol. Immediate containment limits damage. Investigation determines scope and root cause. Affected users receive direct notification with specific details about what information was exposed and what actions they should consider taking.

South African law establishes notification timelines and disclosure requirements. We meet those obligations and often exceed them. Transparency about failures builds more trust than attempting to obscure problems.

User Authority and Control Mechanisms

Your relationship with us isn't one-directional. Several mechanisms let you examine, modify, or terminate how we handle your information.

Access and Correction Rights

Account dashboards provide direct visibility into profile data. You can review what we have on file and edit most fields yourself. For information that requires verification before changes—things like registered email addresses or linked financial accounts—you submit modification requests that we process after confirming identity.

Comprehensive data exports are available on request. We compile everything associated with your account into a structured file. Format depends on data type, but readability matters—you shouldn't need specialized software to understand your own information.

Deletion and Restriction Options

Account closure triggers data removal workflows. We erase personal identifiers from active systems within reasonable timeframes. Some information persists in backup archives and system logs for defined retention periods—technical constraints prevent instant, complete removal from distributed infrastructure. But it becomes inaccessible for operational purposes immediately.

You can request processing restrictions without full deletion. This locks data from use in marketing, analytics, or feature personalization while keeping accounts active. Limitations prevent us from using information for purposes beyond essential service delivery.

  • Object to specific processing activities while maintaining other service features
  • Withdraw consent for optional data collection like usage analytics or improvement surveys
  • Request portability to transfer information to competing services
  • Challenge automated decisions that significantly affect your account status or access

These rights aren't absolute. Legal obligations sometimes require us to retain specific records even when you'd prefer deletion. Transaction logs relevant to financial regulations, communications pertinent to ongoing legal matters, or evidence needed for fraud investigations may survive removal requests. We'll explain when such exceptions apply.

Retention Logic and Disposal

How long we keep information depends on its category and purpose. Account data remains active while you use our services. After closure, identifiable details fade through staged deletion processes. Technical logs expire based on operational need—security events stay longer than performance metrics.

Category-Specific Duration

Financial comparison histories stick around for seven years to satisfy regulatory requirements around transaction records. Even though we're not a financial institution ourselves, the nature of our service puts us adjacent to rules governing record retention in the finance sector. Support communications remain accessible for three years to handle follow-up inquiries and track issue resolution patterns.

Marketing data—if you opted into such communications—gets purged more aggressively. Inactive recipients who haven't engaged in 18 months disappear from distribution lists. This isn't purely altruistic; sending to dead addresses hurts deliverability metrics and wastes resources.

Technical logs follow graduated retention. High-detail diagnostic data vanishes within 90 days. Aggregated performance metrics persist for two years to enable long-term trend analysis. Security incident records remain available for five years to support forensic work and pattern recognition.

These timelines aren't arbitrary. They balance operational requirements, legal mandates, and the principle that data shouldn't linger indefinitely. When retention purposes expire, deletion happens through automated workflows rather than depending on manual intervention.

Disposal Methods

Deletion means actual removal, not just marking records inactive. Database entries disappear through overwrite processes. Backup archives age out according to rotation schedules—after backup retention expires, data contained within becomes permanently inaccessible. Physical storage devices reaching end-of-life undergo destruction that renders data recovery technically infeasible.

Direct Communication Channels

Questions about how we handle your information shouldn't require navigating bureaucratic mazes. Reach us directly through these channels:

Phone: +27 11 675 4410
Mail: Roos St, Fourways, Johannesburg, 2068, South Africa

If internal resolution doesn't satisfy your concerns, South African law gives you the right to escalate complaints to the Information Regulator. We'd prefer to address issues directly first—external escalation tends to slow down resolution—but the option exists when needed.

For detailed information about tracking technologies, browser storage, and analytics implementations, refer to our separate Cookie Policy.