Asanya Information Security Policy

1.1 Policy statement

Asanya is a relationship-led growth platform operated by Urhere Solutions Ltd ("Urhere"). Asanya enables Businesses to manage Partners, attribute relationship-led activity and qualifying outcomes, and, where enabled, issue event-triggered settlement instructions to appropriately licensed payment providers. Trust in the platform depends on the confidentiality, integrity, availability and accountable use of information.

Urhere shall maintain a risk-based information security programme for Asanya. The programme shall use proportionate technical and organisational measures to prevent, detect, respond to and recover from security threats, whether accidental or deliberate, internal or external.

1.2 Purpose

This policy establishes the minimum principles and controls for protecting Asanya's information assets, supporting business continuity, meeting applicable legal and contractual obligations, and maintaining the confidence of Businesses, Partners, users, service providers and other stakeholders.

1.3 Scope

This policy applies to all Asanya personnel, directors, employees, contractors, consultants, developers, administrators, vendors and other persons who access or manage Asanya information or systems. It covers production, development, test and support environments; endpoints; networks; cloud services; source code; databases; APIs; logs; backups; physical records; and information processed on Asanya's behalf.

1.4 Security objectives

• Confidentiality: information is accessible only to authorised persons and systems.
• Integrity: information and instructions are accurate, complete, traceable and protected against unauthorised alteration.
• Availability: services and information are accessible when reasonably required, subject to planned maintenance and events outside reasonable control.
• Accountability: material access, actions, changes and settlement events can be attributed and reviewed.
• Resilience: Asanya can contain incidents, recover critical services and learn from disruptions.

2.1 Multi-tenant platform

Asanya is designed as a multi-tenant service. Each Business and its authorised users shall be logically segregated from other tenants. Partner information, commercial terms, activity records, outcomes and analytics shall be visible only in accordance with configured permissions, platform rules and applicable law.

2.2 Core information assets

• Business, Partner and authorised-user account information, identity and contact data.
• Partner codes, relationship records, campaign or opportunity information, qualifying-event and commission data.
• Business-configured rules, permissions, commercial terms and supporting evidence.
• Settlement instructions, provider references, authorised funding-source tokens or references, and success, failure, reversal and reconciliation records.
• Authentication data, access logs, audit trails, system configurations, source code, secrets, encryption keys and security telemetry.
• Support communications, incident records, backups, vendor records and business-continuity documentation.

2.3 Non-custodial settlement model

Asanya does not custody customer funds and shall not operate a pre-funded or post-funded Asanya settlement wallet. When a valid Business-configured qualifying outcome or commission trigger is achieved, Asanya may calculate the relevant amount and generate a settlement instruction. An appropriately licensed payment partner may then debit the Business's authorised funding account or payment source and credit the Partner through a provider-managed wallet, account or supported payout rail.

Security controls shall protect the creation, authorisation, transmission, status tracking and reconciliation of settlement instructions. Asanya shall record the commission basis, instruction, provider reference and relevant success, failure or reversal status without storing sensitive payment credentials unless strictly necessary, lawful and appropriately protected.

3.1 Governance

Urhere's governing authority and management shall provide oversight, resources and accountability for Asanya's information security programme. Material security risks, incidents, exceptions and remediation plans shall be escalated to the appropriate decision-maker.

3.2 Roles and responsibilities

• Management: approves security priorities, risk appetite, material exceptions and resourcing.
• Designated Information Security Lead: coordinates the security programme, risk register, monitoring, incident response, testing and reporting.
• Data Protection Function: advises on lawful processing, privacy risk, data-subject rights and breach obligations.
• Engineering & Operations: implements secure architecture, development, deployment, logging, backup and recovery controls.
• Data & System Owners: classify assets, approve access and confirm retention requirements.
• All Personnel: follow this policy, complete required training and promptly report suspected incidents or weaknesses.

3.3 Risk assessment and treatment

Asanya shall identify, assess, record and treat information security risks based on likelihood, impact and the sensitivity of affected assets. Assessments shall occur periodically and before material product changes, new integrations, high-risk processing, significant vendor engagements or entry into new regulated use cases. Risk treatment may include mitigation, avoidance, transfer or documented acceptance by authorised management.

4.1 Personnel security

• Security responsibilities shall be included in relevant contracts, role descriptions and onboarding.
• Screening may be conducted for sensitive roles where lawful, proportionate and appropriate.
• Personnel shall receive induction and periodic training on security, privacy, phishing, credential protection, secure development where applicable, and incident reporting.
• Confidentiality and security duties continue after a role or engagement ends where required by law or contract.
• Access and assets shall be withdrawn promptly upon termination or material role change.

4.2 Acceptable use

Asanya resources shall be used only for authorised purposes. Users shall not bypass security controls, access information without a legitimate need, share credentials, introduce malicious or unapproved software, disclose confidential information through unauthorised channels, infringe intellectual-property rights, or use systems for unlawful, abusive, discriminatory or disruptive activity.

5.1 Access principles

• Access shall be based on least privilege, need-to-know and role-based permissions.
• Unique user identities shall be used; shared administrative accounts shall be prohibited except where technically unavoidable and separately controlled.
• Privileged access shall be restricted, monitored and subject to stronger authentication.
• Critical duties, including sensitive configuration and settlement-related functions, shall be separated or subject to compensating review controls.
• Access shall be approved by an authorised owner and reviewed periodically and upon material role change.

5.2 Authentication

Asanya may use one-time-password verification for initial access and password-based authentication thereafter. Passwords shall be protected using industry-accepted cryptographic hashing and shall never be stored in plain text. Authentication controls shall include rate limiting, secure reset processes and protection against common automated attacks. Multi-factor authentication shall be required for privileged accounts and may be required for other high-risk access.

5.3 Tenant and Partner access

Business administrators shall manage authorised Business users and permissions within supported controls. Partner access shall be limited to information necessary for the Partner's relationship and activities. Partner discoverability within a Business dashboard shall not create access to another tenant's confidential information. Access Partners and independently registered Partners shall be governed by their applicable access path and permissions.

6.1 Encryption

Sensitive information shall be encrypted in transit using current secure protocols and encrypted at rest where proportionate to risk. Cryptographic algorithms, key lengths and configurations shall be reviewed and updated as risks and accepted practices evolve.

6.2 Secrets and key management

API keys, tokens, encryption keys and other secrets shall be stored in approved secret-management facilities, restricted by role and environment, rotated based on risk and revoked when compromised or no longer required. Secrets shall not be embedded in source code, public repositories, tickets or ordinary communications.

7.1 Data classification

Information shall be classified according to sensitivity and business impact. The default classes are Public, Internal, Confidential and Restricted. Authentication secrets, encryption keys, government identifiers, sensitive personal data, detailed security configurations and privileged access records shall receive the highest appropriate protection.

7.2 Privacy and lawful processing

• Personal data shall be processed lawfully, fairly and transparently for specified purposes.
• Only data reasonably necessary for the relevant purpose shall be collected, used or retained.
• Privacy and security shall be considered during product design and material change.
• Data-subject requests shall be handled through documented processes and within applicable timelines.
• Cross-border transfers shall use lawful safeguards and appropriate risk assessment.
• High-risk processing and material new use cases shall be assessed for privacy impact before deployment.

7.3 Data ownership and tenant control

Business-provided data remains subject to the rights and responsibilities stated in Asanya's applicable terms, privacy notices and contracts. Asanya shall not treat possession of platform data as authority to use it for unrelated purposes. Data ownership, stewardship, authorised use and correction responsibilities shall be documented where material.

7.4 Data quality and integrity

Reasonable measures shall support accuracy, completeness, consistency and timeliness. Business-configured triggers, commission calculations and supporting records shall be validated through documented rules and controls. Corrections, overrides and material status changes shall be attributable where feasible.

7.5 Retention, deletion and masking

Information shall be retained only for approved legal, regulatory, contractual and operational periods. At the end of the applicable period, it shall be securely deleted, anonymised or irreversibly de-identified unless preservation is required. Production personal data shall not be used in development or test environments unless necessary, authorised and protected through masking or equivalent controls.

8.1 Secure development lifecycle

• Security requirements shall be considered during design, development, testing and release.
• Code shall undergo appropriate peer review and automated or manual security testing based on risk.
• Input validation, output encoding, secure session handling and protection against common application vulnerabilities shall be implemented.
• Development, test and production environments shall be appropriately separated.
• Third-party libraries and components shall be inventoried and assessed for known vulnerabilities.
• Security defects shall be prioritised according to severity and exposure.

8.2 Change and release management

Material changes shall be requested, assessed, approved, tested and documented before production deployment. Emergency changes shall follow an expedited but auditable process. Rollback or recovery arrangements shall be defined where appropriate, and material releases shall be reviewed after deployment.

8.3 Configuration and patch management

Secure configuration baselines shall be established for critical systems. Unnecessary services and default credentials shall be removed or disabled. Security patches shall be evaluated and applied within risk-based timelines, with urgent vulnerabilities prioritised. Deviations shall be recorded and remediated or formally accepted.

9.1 Network security

Networks and services shall be designed to restrict unauthorised access and limit the effect of compromise. Controls may include segmentation, firewalls, web-application protection, secure administration paths, rate limiting, intrusion detection, vulnerability scanning and denial-of-service protections appropriate to risk.

9.2 Cloud services

• Cloud providers shall be assessed for security, reliability, privacy, location, contractual safeguards and relevant assurance reports.
• Cloud access shall be restricted, logged and reviewed; privileged actions shall be tightly controlled.
• Data shall be encrypted in transit and, where appropriate, at rest.
• Cloud configurations shall be monitored for material deviation and exposure.
• Exit, recovery and data-return or deletion arrangements shall be considered for critical providers.

9.3 Malware, email and web protection

Proportionate measures shall be used to protect endpoints and services from malicious code, phishing, unsafe websites and unauthorised downloads. Security tools and signatures shall be maintained, suspicious activity investigated and affected systems isolated where necessary.

10.1 Security logging

Security-relevant events shall be logged to support detection, investigation, accountability and compliance. Logs may include authentication attempts, privileged activity, permission changes, material configuration changes, API activity, data exports and settlement-instruction lifecycle events.

10.2 Monitoring and alerting

Logs and security telemetry shall be monitored on a risk basis for unauthorised access, abuse, anomalous activity, data leakage, service degradation and suspicious settlement behaviour. Alerts shall be triaged and escalated according to severity.

10.3 Log protection and time integrity

Logs shall be protected from unauthorised access and alteration, retained for approved periods, and time-synchronised where necessary to support reliable investigation. Access to logs containing personal or confidential information shall be restricted.

11.1 Due diligence

Vendors and integration partners that access, host, transmit or materially affect Asanya information or services shall be assessed before onboarding and periodically thereafter according to risk. Assessment may consider security controls, privacy posture, service resilience, incident history, subcontractors and regulatory status.

11.2 Contractual safeguards

Relevant agreements shall address confidentiality, permitted use, security measures, breach notification, audit or assurance, data location and transfers, subcontracting, availability, return or deletion, and termination assistance as appropriate.

11.3 Licensed payment partners

Payment execution shall be performed through appropriately licensed partners. Asanya shall verify relevant authorisations and allocate security and operational responsibilities contractually. Provider integration shall not be represented as transferring to Asanya the provider's regulated custody or payment-execution function.

12.1 Reporting

All personnel, Businesses and Partners should report suspected security events promptly through the designated channel. Reports should include available facts without delaying notification while an investigation is incomplete.

12.2 Response lifecycle

• Identify, record, classify and assign ownership of the event.
• Contain the threat and preserve relevant evidence.
• Investigate cause, scope, affected systems, information and stakeholders.
• Eradicate the cause and recover services securely.
• Assess legal, regulatory, contractual and notification duties.
• Communicate accurately and on a need-to-know basis.
• Conduct a post-incident review and track corrective actions.

12.3 Personal-data breaches

Actual or suspected personal-data breaches shall be escalated immediately to the responsible security and data-protection functions. Urhere shall assess risk to individuals and make notifications to the Nigeria Data Protection Commission (NDPC), affected individuals or other parties when and within the period required by applicable law.

13.1 Business impact and continuity

Asanya shall identify critical services, dependencies and recovery priorities through periodic business-impact and risk assessment. Continuity arrangements shall address personnel, technology, providers, communications and alternative operating procedures.

13.2 Backup

• Critical data and configurations shall be backed up at frequencies aligned with recovery objectives and risk.
• Backups shall be protected from unauthorised access, corruption and destructive compromise.
• Retention periods shall reflect operational, legal and contractual needs.
• Backup restoration shall be tested periodically and failures remediated.

13.3 Disaster recovery

Documented recovery procedures shall define responsibilities, priorities, communication and restoration steps for critical systems. Recovery arrangements shall be tested periodically and after material architectural changes. Lessons from tests and actual disruptions shall inform improvement.

14.1 Records

Asanya shall maintain records reasonably necessary to demonstrate implementation of this policy, including risk assessments, access reviews, training, incidents, changes, tests, vendor assessments, exceptions and corrective actions. Records shall be protected and retained according to approved schedules.

14.2 Compliance

All covered persons shall comply with this policy and supporting standards. Suspected violations shall be investigated fairly and proportionately. Confirmed violations may result in access restriction, contractual remedies, disciplinary action or referral to competent authorities, subject to applicable law.