Security Controls Overview

1. Purpose

This document describes ArosaPay's control environment aligned to SOC 2 Trust Services Criteria as defined by the American Institute of Certified Public Accountants (AICPA).

It outlines the technical and organizational safeguards used to protect:

• Transaction data throughout the payment lifecycle
• Personal data of buyers, merchants, and platform users
• Secured funds logic and conditional release mechanisms
• Ledger integrity and reconciliation processes
• System availability and operational continuity

This document does not represent a SOC 2 certification. It reflects alignment with SOC 2 principles and describes the controls ArosaPay has implemented to meet the expectations of enterprise procurement teams, banking partners, payment service providers, and regulatory bodies.

2. Trust Services Criteria Coverage

ArosaPay's controls are structured to align with the five Trust Services Criteria categories:

• Security (Common Criteria) — Protection of information and systems against unauthorized access, unauthorized disclosure, and damage
• Availability — Accessibility of information and systems as committed or agreed
• Processing Integrity — Completeness, validity, accuracy, timeliness, and authorization of system processing
• Confidentiality — Protection of information designated as confidential
• Privacy — Collection, use, retention, disclosure, and disposal of personal information in conformity with commitments and applicable criteria

3. Security Controls

3.1 Access Controls

ArosaPay enforces strict access governance across all systems:

• Role-Based Access Control (RBAC) with principle of least privilege
• Mandatory Multi-Factor Authentication (MFA) for all administrative access
• IP-based access restrictions for internal systems and production environments
• Comprehensive access logging for all administrative actions
• Unique named accounts — no shared credentials permitted
• Enforced password policies aligned with industry best practices
• Privileged access restricted to authorized engineering and compliance personnel

3.2 Infrastructure Security

ArosaPay infrastructure is deployed within secure cloud environments providing:

• Network isolation between production, staging, and development environments
• Virtual private networking for internal service communication
• Firewall policies restricting inbound and outbound traffic to authorized endpoints
• DDoS protection at the network and application layers
• Redundant availability zones for fault tolerance
• No production database is publicly accessible

3.3 Encryption

ArosaPay enforces encryption at every layer:

• TLS 1.2+ encryption for all data in transit
• AES-256 encryption for all data at rest
• Secure key management with defined rotation policies
• Sensitive credentials stored in encrypted secrets management systems

3.4 Secure Development Lifecycle (SDLC)

ArosaPay implements a controlled development and deployment pipeline:

• Version-controlled code repositories with branch protection
• Peer-reviewed pull requests required before merge
• Automated testing pipelines including unit, integration, and regression tests
• Static code analysis for vulnerability detection
• Production deployment approval workflows — no direct production changes permitted without logging and approval

3.5 Audit Logging

All critical system events are logged, including:

• Transaction state transitions within the payment lifecycle
• Ledger entries and fund movement events
• Administrative actions including configuration changes
• Role and permission changes for all user accounts
• Payout execution events and batch processing records

Logs are immutable, time-stamped, stored securely, and monitored for anomalies. Detailed logging practices are described in the Security & Funds Safeguarding documentation.

4. Availability Controls

4.1 Uptime Architecture

ArosaPay is architected for high availability:

• Multi-zone redundancy across geographically distributed infrastructure
• Stateless service layers enabling horizontal scaling
• Database replication with automated failover
• Load balancing across application and API tiers
• System uptime target: 99.9% monthly availability

4.2 Monitoring and Alerting

ArosaPay uses real-time monitoring across all critical systems:

• API latency and response time tracking
• Transaction success rate monitoring
• Error rate thresholds with automatic alerting
• Database health and connection pool monitoring
• Payout processing status and batch completion tracking

Critical alerts trigger immediate engineering escalation and incident classification per the severity matrix defined in the Incident Response framework.

4.3 Backup and Recovery

ArosaPay maintains comprehensive backup and recovery procedures:

• Automated daily backups of all critical data stores
• Encrypted backup storage in geographically separate locations
• Defined recovery procedures documented and accessible to operations teams
• Periodic recovery testing to validate backup integrity

Recovery objectives: RPO (Recovery Point Objective) less than 15 minutes. RTO (Recovery Time Objective) less than 4 hours.

5. Processing Integrity Controls

Processing integrity is central to ArosaPay's transaction engine. All funds movement is governed by deterministic state logic. Details are documented in the Funds Flow Overview.

5.1 State Machine Enforcement

Transactions follow strict states:

• INITIATED — transaction created, awaiting payment
• FUNDS_SECURED — payment confirmed, funds safeguarded
• DELIVERED — seller confirms delivery
• APPROVED — buyer confirms satisfaction
• DISPUTED — dispute raised by either party
• REFUNDED — funds returned to buyer
• PAID_OUT — funds released to seller
• CLOSED — transaction completed

Funds movement is permitted only when state conditions are met. No manual override allows bypassing release conditions.

5.2 Ledger Integrity Model

ArosaPay uses an immutable ledger architecture:

• Immutable ledger entries — once recorded, entries cannot be edited
• Double-entry logic for all fund transitions
• Transaction-bound fund isolation preventing cross-contamination
• Reconciliation checks against PSP payment confirmations
• Corrections require reversal entries — original records preserved

5.3 Reconciliation Controls

Reconciliation occurs between:

• PSP payment confirmations and internal ledger entries
• Ledger entries and payout batch files
• Automated discrepancy detection with investigation triggers
• Release pause mechanisms when reconciliation discrepancies are identified

6. Confidentiality Controls

ArosaPay enforces confidentiality through:

• Data minimization principles — only data necessary for service provision is collected and retained
• Access limitation to need-to-know basis with RBAC enforcement
• Confidentiality agreements for all personnel with access to sensitive data
• Secure handling of dispute documentation and evidence submissions
• Encryption and access restriction for all sensitive documentation

Confidentiality controls are reviewed as part of the periodic security control governance process described in Section 13.

7. Privacy Controls

ArosaPay's privacy controls are aligned with GDPR requirements:

• Personal Data processed only for defined, documented purposes
• GDPR-aligned Data Processing Agreement maintained with all data controllers
• Data subject rights honored — access, rectification, erasure, restriction, portability, and objection
• Defined retention policies with automated enforcement
• Risk assessments conducted on new processing activities
• Personal Data is not sold, rented, or commercially exploited

Full privacy practices are documented in the Privacy Policy and the Data Processing Agreement.

8. Fraud & Risk Controls

ArosaPay implements layered fraud and risk management:

• Transaction velocity monitoring for anomalous payment patterns
• Dispute rate monitoring per merchant with threshold-based alerting
• Merchant tier risk classification determining reserve rates and payout terms
• Reserve logic for risk mitigation — percentage-based holds on merchant funds
• Automated anomaly detection across transaction, dispute, and payout data

High-risk activity may trigger:

• Account restriction pending investigation
• Payout pause until risk assessment is completed
• Manual review by compliance and risk operations teams

Merchant risk classification and reserve policies are detailed in the Merchant Risk & Tier Policy.

9. Incident Response

ArosaPay maintains a documented Incident Response Plan. Full documentation is available in the Incident Response & Security Commitment documentation.

Incident handling includes:

• Classification by severity (Severity 1 through Severity 4)
• Internal escalation to engineering, compliance, and leadership as required
• Impact assessment covering data, systems, and affected parties
• Containment procedures to limit further exposure
• Communication protocols for internal teams and affected parties
• Post-incident review with root cause analysis and remediation tracking

Personal Data Breaches are reported in accordance with GDPR timelines — notification to supervisory authorities within 72 hours where feasible, and to affected Data Subjects without undue delay where required.

10. Business Continuity

ArosaPay maintains business continuity capabilities including:

• Redundant infrastructure across multiple availability zones
• Data backups with defined RPO and RTO targets
• Incident playbooks for common failure scenarios
• Operational fallback procedures for critical services

Security overrides may temporarily pause payout or release logic to protect funds during active incidents. These overrides are documented, authorized, and reversed once the incident is resolved.

11. Third-Party Risk Management

ArosaPay conducts due diligence on all critical third-party providers:

• Cloud infrastructure providers
• Payment processors and PSP partners
• Identity verification and KYC vendors
• Monitoring and security service providers

Contracts with third parties require:

• Data protection obligations aligned with applicable law
• Security safeguards appropriate to the nature of data processed
• Confidentiality commitments covering all data shared
• Notification obligations for security incidents

12. Change Management

All production changes require:

• Pull request review by qualified engineering personnel
• Automated testing including unit, integration, and regression suites
• Approval workflow prior to deployment
• Logged deployment events with attribution and timestamp

Emergency changes are permitted under defined conditions but are documented and reviewed post-deployment to ensure compliance with standard change management procedures.

13. Control Governance

Security controls are reviewed periodically by:

• Engineering leadership responsible for technical control implementation
• Compliance function responsible for regulatory alignment
• External advisors engaged where applicable for independent assessment

Policy updates are version-controlled, dated, and communicated to relevant stakeholders. Control governance includes tracking remediation of identified gaps and continuous improvement of the control environment.

14. Control Limitations

This document describes ArosaPay's current control framework as of the effective date. It is provided for informational and procurement review purposes.

• This document does not constitute a SOC 2 certification or attestation
• Controls described herein do not guarantee the prevention of all security incidents or data breaches
• ArosaPay is committed to continuous improvement of its control environment
• Controls are subject to periodic review and update as described in Section 13

Questions regarding this document or ArosaPay's security controls may be directed to the compliance team through the appropriate contact channels.