Shujaa Pay — Information Security Policy

[LEGAL REVIEW REQUIRED: This Policy has been revised to address findings of an internal legal audit. It must be reviewed and certified by qualified counsel before reliance. Items requiring verification are marked inline.]

1. Purpose and Scope

This Information Security Policy (“Policy”) defines how Shujaa Pay (“we”, “us”, “our”, “the Platform”) protects information assets across our entire ecosystem, including:

• Public website (www.shujaapay.com)
• Seller dashboard (web application)
• Admin operations panel (Flutter Web)
• REST API (api.shujaapay.com)
• Payment, escrow, payout, KYC, and dispute services
• Production servers, databases, caches, and third-party integrations

This Policy applies to all employees, contractors, administrators, sellers, buyers (as data subjects), and technology partners who interact with Shujaa Pay systems or data.

Our objective is to maintain confidentiality, integrity, and availability of customer and business data in line with industry best practices and applicable laws of the United Republic of Tanzania.

2. Security Governance

2.1 Roles and Responsibilities

2.2 Policy Review

This Policy is reviewed at least annually and after any significant security incident, major architecture change, or regulatory update. Changes are version-controlled and communicated to relevant stakeholders.

2.3 Risk Management

We identify, assess, and treat security risks across application, infrastructure, and third-party layers. High-risk items (payment flows, escrow release, admin actions, KYC data) receive priority controls and monitoring.

3. Platform Architecture Security

3.1 System Components

3.2 Network and Server Security

Production infrastructure is hosted on secured virtual private servers with the following controls:

• HTTPS/TLS enforced on all public endpoints (website, API, admin panel)
• Firewall rules restricting inbound traffic to required ports (typically 80/443); SSH restricted to authorised IPs where practicable
• Environment separation between development, staging, and production
• Secrets management — credentials, API keys, database passwords, and SMTP passwords stored in environment variables (.env), never committed to source control
• Regular OS and dependency updates applied during scheduled maintenance windows
• Automated database backups before production deployments; backup retention per operational runbooks
• Outbound SMTP (port 587/TLS) used for transactional email; monitored for delivery failures

3.3 Deployment Security

Production deployments follow a controlled process including:

• Pre-deploy database backup (pg_dump)
• Migration integrity checks
• Static asset collection and service restarts via documented scripts
• Post-deploy health verification (manage.py check, smoke tests)
• Rollback procedures documented for critical failures

4. Identity and Access Management

4.1 Authentication

Additional authentication controls:

• JWT (JSON Web Tokens) with short-lived access tokens and refresh token rotation
• Password hashing using Django’s industry-standard PBKDF2/bcrypt mechanisms
• Account lockout after repeated failed login attempts (temporary 30-minute lock)
• Session tracking — device info, IP address, user agent, and expiry recorded per session
• Admin login rate limiting — maximum attempts per IP within defined windows

4.2 Authorisation (Role-Based Access Control)

Principle of least privilege applies: users receive only the permissions required for their role. Object-level permissions prevent sellers from accessing other sellers’ data.

4.3 Administrative Security

High-impact admin actions are protected by multiple controls:

• Email 2FA on every admin login
• OTP verification for sensitive dispute resolution actions
• Mandatory reason fields and audit logs for financial and account-status changes
• Segregation of duties between standard admin, senior admin, and super admin where applicable

4.4 Access Revocation

Upon employee or contractor departure, or upon role change:

• Admin credentials are disabled immediately
• Active sessions and refresh tokens are invalidated
• Access to servers, repositories, and third-party dashboards is revoked

5. Data Protection

5.1 Data Classification

5.2 Encryption

• In transit: TLS 1.2+ for all client-server and server-PSP communications
• At rest: Database and file storage protected using:
  • PostgreSQL data files on encrypted server volumes (hosting-provider disk encryption)
  • Passwords and secrets: irreversibly hashed (PBKDF2/bcrypt) or stored in environment variables — never in source code
  • KYC documents: stored on the application media server at [LEGAL REVIEW REQUIRED: confirm storage location — e.g., VPS local /media/ path or cloud object storage provider and region]; access restricted to authorised KYC review personnel via authenticated, role-based URLs; not publicly enumerable
  • Backups: encrypted at rest in access-controlled storage locations

[LEGAL REVIEW REQUIRED: Confirm the encryption-at-rest technology, key management approach, and KYC storage location. Cross-reference with the Privacy Policy international transfers section.]

5.3 Data Minimisation and Retention

We collect only data necessary to operate escrow payments, comply with KYC requirements, resolve disputes, and meet legal obligations. Retention schedules align with our Privacy Policy and applicable Tanzanian law.

5.4 Backup and Recovery

• Automated PostgreSQL backups before production changes
• Backup files stored in secure, access-controlled locations
• Recovery procedures tested periodically

[ACTION REQUIRED: Set and document actual RTO/RPO targets aligned to business continuity requirements and test recovery against them.]

6. Application Security

6.1 Secure Development Practices

• Input validation on all API endpoints (serializers, model constraints)
• Protection against SQL injection via Django ORM parameterised queries
• Protection against XSS via template auto-escaping and Content Security Policy where deployed
• CSRF protection on state-changing web forms
• CORS restricted to approved origins (production website, admin panel domains)
• Dependency vulnerability monitoring and timely patching
• Code review for security-sensitive changes (auth, payments, escrow, payouts, KYC)

6.2 API Security

• Standardised API response envelope for consistent error handling
• Rate limiting on authentication and sensitive endpoints
• Request ID tracing for audit and incident investigation
• No sensitive data in URL query parameters where avoidable

6.3 Payment and Escrow Security

Shujaa Pay operates an escrow model: buyer funds are held until delivery is confirmed or released per platform rules.

6.4 KYC and Identity Verification

Seller KYC includes:

• Full legal name (matching National ID — NIDA)
• NIDA number and card images (front and back)
• Selfie for liveness verification
• Mobile money number with registered name matching NIDA identity

KYC data is accessible only to authorised verification staff and is never disclosed to buyers or unrelated sellers.

7. Third-Party and Vendor Security

We assess third-party providers before integration and monitor ongoing compliance:

Third-party access is limited to the minimum data required for the service. Contracts and data processing terms are maintained where applicable.

8. Monitoring, Logging, and Audit

8.1 Logging

We maintain logs for:

• Authentication events (login, logout, failed attempts, 2FA challenges)
• Payment and escrow state changes
• Payout requests and admin approvals
• Dispute lifecycle events
• KYC submission and review actions
• Admin audit trail (who did what, when, and why)

8.2 Monitoring

• Application error logging and alerting
• Celery task monitoring for failed payout/notification jobs
• SLA monitoring for dispute and KYC review queues
• Server resource monitoring (CPU, memory, disk, database connections)

8.3 Audit

Admin actions that affect funds, accounts, or disputes are recorded in immutable audit logs with administrator identity, timestamp, action type, and reason.

9. Incident Response

9.1 Incident Classification

9.2 Response Procedure

1. Detect — via monitoring, user reports, or internal discovery
2. Contain — isolate affected systems, revoke compromised credentials, place holds on suspicious transactions
3. Investigate — determine scope, root cause, and affected users
4. Remediate — patch vulnerabilities, restore from clean backups if needed
5. Notify — inform affected users and regulators as required by law
6. Review — post-incident report and control improvements

9.3 Reporting

Security incidents can be reported to:

• Email: security@shujaapay.com (subject: Security Incident)
• Support: support@shujaapay.com
• Phone: +255 746 259 442

We aim to acknowledge reports within 24 business hours.

9.4 Vulnerability Disclosure

Security researchers and users who discover a potential vulnerability may report it responsibly to security@shujaapay.com (subject: Vulnerability Report). We ask that you:

• Provide sufficient detail to reproduce the issue
• Allow reasonable time for us to investigate and remediate before public disclosure
• Not access, modify, or delete data belonging to other users

We do not currently operate a formal bug bounty programme. [LEGAL REVIEW REQUIRED: Consider establishing a bug bounty or coordinated disclosure programme as the platform scales.]

9.5 Penetration Testing and Security Audits

Shujaa Pay conducts or commissions security testing on a defined schedule:

[ACTION REQUIRED: Commission an external penetration test before investor due diligence or regulatory review and document the outcome (date, scope, remediated findings).]

10. Business Continuity

• Redundant backups and documented recovery procedures
• Celery-based async processing ensures payment notifications and releases can be retried after transient failures
• Escrow state machine prevents inconsistent fund states during partial outages
• Communication plan for extended outages via website and email status updates

11. Physical and Environmental Security

Production servers reside in professionally managed data centres with:

• Controlled physical access
• Power and cooling redundancy
• Network perimeter protection

No production database or secrets are stored on unsecured personal devices.

12. Employee and Personnel Security

• Background checks are required for all personnel with access to production systems, KYC data, or financial operations before access is granted (not merely "where practicable")
• Confidentiality obligations for all team members, documented in employment or contractor agreements
• Security awareness training delivered at onboarding and refreshed at least annually, covering phishing, credential hygiene, social engineering, and incident reporting
• Prohibition on sharing admin credentials or using personal email for platform operations
• Mandatory use of strong, unique passwords and 2FA on all admin accounts
• Mobile device policy: Production secrets and KYC data must not be stored on unsecured personal devices; admin access is via controlled web applications only

[LEGAL REVIEW REQUIRED: Confirm background-check scope and whether MDM (Mobile Device Management) is required for any personnel with production access.]

13. Compliance

Shujaa Pay aligns its security programme with:

• Personal Data Protection Act, 2022 (Tanzania)
• Electronic and Postal Communications Act (Tanzania) — where applicable to electronic transactions
• Bank of Tanzania guidance on payment services (via licensed PSP partnership)
• Industry best practices (OWASP, CIS benchmarks)

This Policy supports but does not replace legal obligations under our Terms and Conditions, Privacy Policy, and AML Policy.

14. User Security Responsibilities

Sellers

• Use a strong, unique password and never share login credentials
• Complete KYC accurately with genuine documents
• Report suspicious account activity immediately
• Verify payout destination mobile money numbers before submission

Buyers

• Pay only through official Shujaa Pay payment links
• Protect OTP codes — never share verification codes with third parties
• Confirm receipt only after receiving the actual product or service
• Report disputes promptly with accurate information

Administrators

• Complete 2FA on every login
• Never approve payouts or resolve disputes without required verification
• Document reasons for all high-impact actions
• Report security anomalies immediately

15. Policy Enforcement

Violations of this Policy may result in:

• Immediate account suspension or termination
• Revocation of administrative access
• Legal action where applicable
• Reporting to relevant authorities for criminal activity

16. Document Control

Shujaa Pay
Zanzibar, United Republic of Tanzania
www.shujaapay.com · support@shujaapay.com

This document is provided for transparency and operational governance. It does not constitute legal advice. For legal questions, consult qualified counsel in Tanzania.