Security Policy

4.1 Commitment

Hirfa treats the security of user data and platform integrity as a foundational, non-negotiable priority. We apply a "Security by Design" methodology across every layer of the product — from database schema to mobile client.

4.2 Organizational Security

• A designated security point of contact (initially the CTO/technical co-founder) owns Hirfa's security posture and coordinates with the Incident Response team.
• All personnel with access to production systems undergo a baseline security awareness review and sign the Employee/NDA Policy (Section 6).
• Security responsibilities are reviewed quarterly as the team scales.

4.3 Data Protection Controls

• Encryption in transit: All client-server communication is encrypted via TLS 1.2 or higher.
• Encryption at rest: Sensitive database fields (national IDs, payment tokens) are encrypted at rest.
• Database-level isolation: Row-Level Security (RLS) policies restrict data access at the database layer, not just the application layer, so a compromised application key cannot expose the full dataset.
• No raw card storage: Full payment card data is never stored on Hirfa's own infrastructure; all card processing is delegated to a PCI-DSS-compliant licensed payment gateway.

4.4 Authentication and Session Security

• Mandatory OTP-based verification for account registration, login, and any change to sensitive account data (phone number, payout bank details, password).
• Rate limiting and anomaly detection on authentication endpoints to prevent brute-force and OTP-spam abuse.
• Session tokens expire after a defined inactivity period and are invalidated on password change or suspected compromise.

4.5 Application Security

• Peer code review is required before merging any change to production-facing code.
• Dependency and library vulnerabilities are monitored and patched on a regular cadence.
• Penetration testing (internal or third-party) is conducted before major platform releases and at least annually thereafter.
• Centralized logging and monitoring flags anomalous activity per the Audit Logs Policy (Section 12).

4.6 Infrastructure Security

• Production infrastructure is segregated from development/staging environments.
• Access to cloud infrastructure consoles requires 2FA and is governed by the Access Control Policy (Section 8).
• Regular automated backups with tested restoration procedures.

4.7 Incident Handling

Any suspected or confirmed security incident is handled per the Incident Response Policy (Section 9), including timely notification of affected Users where required by the PDPL.

4.8 User Responsibilities & Reporting

Users are responsible for safeguarding their own account credentials and OTP codes, never sharing them with any third party (including anyone claiming to represent Hirfa — Hirfa staff will never ask you for your OTP code), and reporting suspected account compromise immediately to security@gethirfa.com or via our Reporting System (Section 13). Security researchers should follow our Vulnerability Disclosure Policy (Section 5) and review our security.txt Declaration (Section 11).