Privacy Policy

MySuSu — Data Protection Policy & Procedures

This Data Protection Policy establishes the governance, administrative controls, technical controls, and operational procedures that MySuSu uses to ensure the lawful, secure, and compliant processing of Personally Identifiable Information (PII) and financial data.

It aligns with recognized data protection standards, including National Data Protection Acts and central bank regulatory directives, ISO/IEC 27001, ISO/IEC 27701, PCI-DSS principles for payment information handling, and GDPR-equivalent international principles for global compliance readiness.

1. Introduction & Governance Framework

1.1 Purpose of the Policy

The purpose of this policy is to define how MySuSu governs personal and financial data throughout its lifecycle, protects that data against misuse or unauthorized access, and demonstrates accountability to regulators, customers, and partners.

1.2 Scope

• All MySuSu systems, applications, databases, integrations, and analytics pipelines
• All employees, contractors, third-party service providers, and agents
• All PII and financial data processed by the organisation
• All environments, including production, staging, development, and backups

1.3 Governance Roles

2. Data Classification Scheme

MySuSu uses a formal, multi-level classification scheme to determine the handling rules for information processed across its services and platforms.

2.1 Classification Categories

2.2 Handling Requirements by Classification

3. Data Lifecycle & Retention Procedures

3.1 Collection

• Only data strictly necessary for providing services is collected.
• All collection points include notice of purpose and consent where required.
• Sensitive documents (KYC) are collected only upon user confirmation.
• Automated data minimization rules remove unnecessary fields before storage.

3.2 Storage

• PII stored in PostgreSQL with encryption-at-rest enabled (AES-256).
• Highly sensitive data stored in encrypted object stores with bucket-level and object-level encryption.
• Access restricted via IAM roles with strict versioning and no public access.
• Database connections require TLS and IP allowlisting.
• Backups encrypted using separate encryption keys in KMS.

3.3 Processing

• All processing is logged and associated with an actor identity, whether human or service.
• Automated profiling such as fraud scoring requires risk assessment, user explanation, and opt-out where mandated.

3.4 Retention Periods

3.5 Deletion Procedures

• Soft-delete: record marked inactive and removed from user access.
• Hard-delete: irrevocable deletion after retention period.
• Deletion certification: a cryptographic hash of deleted items is stored as proof.
• DSR deletion is validated by identity verification, logged in the audit system, and completed within 30 days unless exceptions apply.

4. Access Control Framework

4.1 Principles

• Least privilege: access granted only as necessary for job function.
• Separation of duties: users cannot approve their own changes.
• Need-to-know: restricted data requires explicit justification.

4.2 Access Layers

4.3 Elevated Access (Just-In-Time Access)

• Engineers request time-limited elevated permissions.
• Requests require approval by the CTO or CISO.
• All sessions are recorded and archived.
• Privileged sessions are monitored in real time.

4.4 Authentication Controls

MFA is required for admin users, support personnel, DevOps, and finance or operations teams.

• Minimum password length of 12 characters
• Enforced staff password rotation every 180 days
• User credentials validated using modern hashing such as Argon2 or bcrypt

5. Encryption & Key Management

5.1 Encryption in Transit

All API and internal service communication uses TLS 1.2 or 1.3. Internal microservices may use mTLS for mutual authentication, and weak ciphers are explicitly disabled.

5.2 Encryption at Rest

• Database-level encryption (AES-256)
• Application-level encryption for restricted fields such as KYC images, bank credentials, and certain ledger fields
• Backups encrypted using KMS-managed keys

5.3 Key Management

• Keys generated, stored, and rotated via KMS
• Annual automatic rotation of customer-managed keys
• Immediate rotation on key compromise
• Keys never leave KMS or exist in plaintext form

6. Data Subject Rights & Procedures (DSR/SAR)

6.1 Supported Rights

Depending on applicable law, users may request access to their data, correction, deletion where legal, data export or portability, and objection to certain processing.

6.2 DSR Workflow

1. Submission via in-app form or customer support
2. Identity verification through a multi-step process requiring valid ID or biometric check
3. Assessment by the DPO to determine eligibility
4. Fulfillment by Engineering to extract, delete, or amend data
5. Quality review for completeness and compliance
6. Communication to the user with a completed report
7. Logging of all steps in an immutable DSR log

7. Third-Party Vendor & Integration Controls

7.1 Due Diligence

• Security questionnaire based on ISO 27001 and NIST CSF
• Annual penetration test report submission
• Confirmation of encryption, backup, and incident response processes
• Review of physical security for on-premise vendors where applicable

7.2 Data Processing Agreements (DPAs)

Every vendor must sign a DPA that includes data protection requirements, confidentiality obligations, breach-notification timelines, sub-processing restrictions, and termination plus secure deletion requirements.

7.3 Ongoing Monitoring

• Annual vendor review
• SLA monitoring for uptime, security incidents, and response times
• Automated alerting for webhook anomalies or provider downtime

8. Breach Notification & Incident Response Procedures

8.1 Detection

SIEM continuously monitors events from the API gateway, application logs, authentication failures, data access anomalies, and payment integration anomalies. Alerts are classified into severity tiers: Critical, High, Medium, and Low.

8.2 Triage

The Incident Response Team conducts scope assessment, vector identification, impact evaluation, and containment strategy selection.

8.3 Containment Measures

• Revoke compromised tokens
• Block malicious IP addresses
• Disable affected user accounts
• Isolate compromised servers or containers
• Lock databases or freeze ledger updates if integrity risk exists

8.4 Eradication & Recovery

• Patch vulnerabilities
• Restore from the last known-good backups if required
• Validate database and ledger integrity
• Perform regression testing before reactivation

8.5 Regulatory Notification

In alignment with central bank requirements, MySuSu notifies the regulator within the mandated SLA, such as 72 hours, and provides an incident summary, affected data, containment measures, remediation plan, and ongoing monitoring commitments.

8.6 User Notification

Affected users are informed if their PII or financial data was exposed. Notices include the nature of the breach, suggested protective steps, and support contact channels.

8.7 Post-Incident Review

• Root cause analysis (RCA)
• Updated documentation
• Additional controls implemented
• Executive report submitted to the board and regulator

9. Auditing, Monitoring & Compliance Reporting

9.1 Audit Logging

Logs are immutable, timestamped, and cryptographically hashed. They cover login attempts, data access events, administrative actions, elevated permission grants, and API usage patterns.

9.2 Monitoring Controls

• Real-time monitoring for excessive API calls
• Suspicious authentication patterns
• Unauthorized changes to user data
• Payment anomalies and fraud indicators

9.3 Internal & External Audits

• Internal audits conducted quarterly
• Independent third-party audit conducted annually
• Penetration testing at least once per year or after major system changes

9.4 Compliance Reporting

• System uptime
• Security events summary
• Redacted audit logs
• Data governance metrics
• Third-party oversight summary

10. Policy Review & Revisions

This policy is reviewed annually or upon major system changes, new regulatory directives, or significant security incidents.

Contact

For regulatory questions, privacy requests, or formal notices regarding this policy, please contact MySusu: