Information Security Policy

1. Purpose

This Information Security Policy establishes the governance framework for protecting ArosaPay's information assets, including:

• Customer funds logic and conditional release mechanisms
• Transaction integrity across the payment lifecycle
• Personal data of buyers, merchants, and platform users
• Operational systems and infrastructure
• Regulatory standing and compliance obligations

The objective is to ensure confidentiality, integrity, and availability of ArosaPay systems consistent with its role as a payments infrastructure platform. This policy is approved by the Board of Directors and applies to all personnel, systems, and operations.

2. Scope

This policy applies to:

• All employees, contractors, and officers of ArosaPay
• All systems, data, and infrastructure operated or managed by ArosaPay
• All third-party integrations processing data on behalf of ArosaPay
• Both production and internal environments

No system, individual, or process is exempt from this policy. Where local regulations impose additional requirements, those requirements are applied in addition to this policy.

3. Governance Structure

3.1 Board Oversight

The Board of Directors:

• Maintains ultimate oversight of information security risk
• Reviews the security posture at least annually
• Reviews major security incidents and their remediation
• Approves material changes to this policy and the security governance framework

3.2 Executive Accountability

The Chief Executive Officer is accountable for:

• Ensuring implementation of this policy across the organization
• Allocating adequate resources for information security
• Escalating material security risks to the Board of Directors

3.3 Operational Responsibility

Engineering Leadership is responsible for:

• Implementing and maintaining technical safeguards
• Enforcing secure development lifecycle practices
• Maintaining ledger and transaction integrity
• Managing vulnerability identification and remediation

Compliance Function is responsible for:

• Regulatory alignment and monitoring of applicable requirements
• Data protection governance and privacy compliance
• Incident reporting coordination with regulatory authorities

4. Security Principles

ArosaPay operates under the following core security principles:

• Least Privilege — access is limited to the minimum necessary for each role
• Segregation of Duties — critical functions are divided to prevent single points of control
• Defense in Depth — multiple layers of security controls protect against failure of any single control
• Immutable Ledger Integrity — financial records are append-only and cannot be retroactively modified
• Secure-by-Design Architecture — security is embedded in system design, not added retroactively
• Zero Tolerance for Unauthorized Release of Funds — funds release logic may never be overridden for convenience

These principles govern all technical and organizational decisions affecting the security of ArosaPay systems. Detailed technical controls aligned to these principles are documented in the Security Controls Overview.

5. Risk Management Framework

ArosaPay maintains a structured risk management approach:

• Identification of security threats across infrastructure, applications, and processes
• Assessment of likelihood and impact for each identified threat
• Implementation of mitigation controls proportionate to risk severity
• Periodic review of the risk posture to account for new threats and changes in the environment

Material risks are escalated to executive leadership. Risks that may affect customer funds, regulatory standing, or platform integrity are escalated to the Board of Directors. Risk classification for merchant operations is detailed in the Merchant Risk & Tier Policy.

6. Access Control Policy

Access to production systems and sensitive data requires:

• Named accounts — no shared or generic credentials permitted
• Multi-Factor Authentication (MFA) for all administrative and production access
• Role-Based Access Control (RBAC) limiting permissions to operational requirements
• Formal approval for privilege elevation beyond standard role assignments
• Logging of all administrative actions with attribution and timestamp

Access rights are reviewed periodically. Unused accounts are disabled promptly. Access control procedures are aligned with the technical controls described in the Security Controls Overview.

7. Data Classification

ArosaPay classifies data into the following categories:

• Public — information intended for unrestricted distribution
• Internal — information for internal use that is not sensitive but not intended for public release
• Confidential — information requiring protection due to contractual, legal, or business sensitivity
• Restricted — information requiring the highest level of protection

Restricted data includes:

• Personal Data of users, merchants, and buyers
• Payment references and transaction identifiers
• Ledger data and fund movement records
• Reserve balances and settlement data
• Dispute documentation and evidence submissions

Handling procedures, access controls, and retention requirements vary by classification. Data protection obligations are further defined in the Data Processing Agreement.

8. Secure Development Governance

All production code changes require:

• Peer review by qualified engineering personnel
• Version control with branch protection and audit trail
• Deployment logging with attribution and timestamp
• Testing validation including unit, integration, and regression testing

Direct modification of production databases is prohibited. Emergency changes are permitted under defined conditions but require post-change review and documentation. Detailed SDLC controls are described in the Security Controls Overview.

9. Funds Protection Controls

Given ArosaPay's role in securing funds during transactions, the following controls are enforced without exception:

• Secured funds must remain isolated until all approval conditions are met
• Ledger entries must be immutable — corrections require reversal entries
• State machine transitions must be enforced — no state may be skipped or overridden
• Manual override of release logic is prohibited under all circumstances

In case of uncertainty regarding the legitimacy of a transaction or the satisfaction of release conditions, release mechanisms must default to "hold." Funds protection architecture is documented in the Funds Flow Overview and the Security & Funds Safeguarding documentation.

10. Incident Response Governance

ArosaPay maintains a documented incident response framework including:

• Incident severity classification (Severity 1 through Severity 4)
• Internal escalation protocol with defined response timeframes
• Executive notification threshold for material incidents
• Regulatory notification procedures aligned with GDPR and applicable law
• Post-incident review with root cause analysis and remediation tracking

Material incidents are reported to the Board of Directors. Full incident response procedures are documented in the Incident Response & Security Commitment.

11. Third-Party Risk Management

All critical third-party vendors must:

• Undergo due diligence review prior to engagement
• Maintain security controls appropriate to the nature of data processed
• Contractually agree to data protection obligations aligned with applicable law
• Notify ArosaPay of material security breaches without undue delay

High-risk vendors — including payment processors, cloud infrastructure providers, and identity verification services — are periodically reassessed. Vendor risk management is coordinated between engineering leadership and the compliance function.

12. Business Continuity

ArosaPay maintains business continuity capabilities including:

• Redundant infrastructure across multiple availability zones
• Backup systems with defined recovery procedures
• Defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
• Incident playbooks and operational fallback procedures

Funds integrity takes precedence over rapid restoration. Security overrides may temporarily pause payout or release logic to protect customer funds during active incidents.

13. Training & Awareness

All personnel must:

• Complete security onboarding training upon joining the organization
• Adhere to confidentiality agreements covering all sensitive information
• Report suspected security incidents immediately through defined channels
• Avoid unauthorized access to systems, data, or environments outside their role

Security awareness is reinforced periodically through training updates and communication of emerging threats relevant to the payments industry.

14. Monitoring & Review

Security posture is reviewed through:

• Log monitoring for anomalous activity across all production systems
• Risk assessment reviews aligned with the risk management framework
• Control effectiveness analysis to validate that safeguards perform as intended
• Incident trend analysis identifying recurring patterns and emerging threats
• Dispute anomaly tracking to identify potential fraud or abuse patterns

Policy updates are version-controlled, dated, and communicated to relevant stakeholders. Monitoring practices are aligned with the controls described in the Security Controls Overview.

15. Policy Violations

Violation of this policy may result in:

• Immediate access revocation pending investigation
• Disciplinary action proportionate to the severity of the violation
• Termination of engagement for material or repeated violations
• Legal action where applicable, including reporting to relevant authorities

All violations are documented and reviewed. Patterns of non-compliance are escalated to executive leadership and, where warranted, to the Board of Directors.

16. Continuous Improvement

Security controls evolve based on:

• Incident learnings and post-incident review findings
• Regulatory developments and changes in applicable law
• Threat landscape changes including emerging attack vectors
• Infrastructure growth and changes in system architecture

Security maturity is expected to increase as ArosaPay scales. The control environment is treated as a continuously improving system, not a static compliance artifact.

17. Policy Review

This policy shall be reviewed:

• Annually, at minimum
• Following material security incidents
• Following major system architecture changes

Board approval is required for material revisions to this policy. Minor updates — including clarifications and formatting changes — may be approved by executive leadership and reported to the Board at the next scheduled review.