Risk Management Policy

1. Objectives and scope

This policy applies across GoFix operations, including the customer app, Crew app, admin portal, website, Firebase and cloud services, payment gateways, customer support, service delivery, crew management, finance, vendors, and business continuity. It establishes a practical risk framework proportionate to GoFix’s size and stage of development.

2. Risk governance

• Management is accountable for risk appetite, major risk acceptance, resourcing, incident escalation,

and policy approval.

• A designated risk owner maintains the risk register, follows up controls, and reports material issues

to management.

• Each operational owner is responsible for risks arising from their process, system, vendor, staff, or

service crew.

• Developers and administrators must document material changes, protect credentials, test releases,

and maintain rollback or recovery arrangements.

• No person may approve their own high-risk exception, bank-account change, refund, payout, or

access elevation without independent review.

3. Risk management cycle

1. Identify: record the event, asset/process affected, causes, existing controls, and potential

consequences.

1. Assess: rate likelihood and impact before and after controls using the approved matrix.
2. Treat: avoid, reduce, transfer, accept, or terminate the activity, with an owner and due date.
3. Monitor: track control performance, incidents, complaints, fraud, outages, chargebacks, and

overdue actions.

1. Report: escalate material risks and incidents promptly and review the risk register at least

quarterly.

4. Risk rating matrix

Impact / 1 Rare 2 Unlikely 3 Possible 4 Likely 5 Almost certain Likelihood

1 Minor 1 - Low 2 - Low 3 - Low 4 - Low 5 - Medium

2 Moderate 2 - Low 4 - Low 6 - Medium 8 - Medium 10 - High

3 Significant 3 - Low 6 - Medium 9 - Medium 12 - High 15 - High

4 Major 4 - Low 8 - Medium 12 - High 16 - High 20 - Critical

5 Severe 5 - Medium 10 - High 15 - High 20 - Critical 25 - Critical

High and Critical residual risks require management review. Critical risks require immediate action, suspension of the affected activity where necessary, and a documented decision before resumption.

5. Principal risk categories and minimum controls

5.1 Strategic and business risk

• Use approved business plans and budgets; monitor cash flow, merchant reserves, settlement delays,

customer adoption, and service coverage.

• Avoid commitments that exceed operational capacity or depend on a single unverified revenue

assumption.

• Document legal relationships and avoid public claims about ownership, subsidiaries, licences, or

regulatory status unless supported by records.

5.2 Operational and service-delivery risk

• Verify crew onboarding, skills/role information, availability, and service completion.
• Use booking controls, escalation paths, customer support, complaint tracking, and quality reviews.
• Maintain safety instructions and prohibit service assignments that crews are not authorised or

competent to perform.

5.3 Payment, fraud, and financial risk

• Use approved payment providers, transaction monitoring, limits, refund controls, reconciliation,

and separation of duties.

• Verify bank-account changes and protect merchant credentials and signing keys.
• Maintain sufficient liquidity for refunds, chargebacks, provider reserves, taxes, and operating costs.

5.4 Technology and cybersecurity risk

• Apply least privilege, multi-factor authentication where available, secure credential storage, prompt

access removal, and audit logging.

• Use controlled development, code review, dependency updates, testing, backups, monitoring, and

incident response.

• Protect signing keys, API keys, Firebase rules, cloud consoles, domain/DNS access, Apple/Google

developer accounts, and payment credentials.

• Restrict exposed API keys by application/package, certificate fingerprint, service, domain, and quota

where supported.

5.5 Privacy and data risk

• Collect the minimum personal data needed; publish clear privacy notices and define

retention/deletion practices.

• Restrict access to identity documents, addresses, location, chat, payment references, and

crew/customer records.

• Use secure transfer methods for sensitive documents and avoid sharing unredacted identity or

banking data through ordinary channels unless required and protected.

5.6 Third-party and concentration risk

• Perform proportionate due diligence before using payment, cloud, messaging, mapping, hosting,

development, or support vendors.

• Maintain contracts, ownership of accounts, admin access, recovery contacts, and exit/transition

plans.

• Avoid leaving essential accounts solely under an outsourced developer or a single unreachable

person.

5.7 Legal, compliance, and conduct risk

• Maintain accurate SSM, tax, merchant, website, app-store, customer-term, and privacy information.
• Follow provider agreements, respond to verification requests, preserve records, and escalate

suspicious or unlawful activity.

• Treat customers and crews fairly; prohibit misleading pricing, false documents, retaliation, bribery,

and conflicts of interest.

5.8 Reputation risk

• Monitor complaints, ratings, social channels, failed jobs, delayed refunds, data incidents, and

misleading public statements.

• Use authorised spokespersons and accurate, consistent communications during incidents.

6. Change and release risk

• Material app, payment, Firebase, domain, package/bundle identifier, authentication, pricing, or data

changes require documented testing and approval.

• Production releases should use unique version/build numbers, controlled signing credentials,

backup/rollback plans, and post-release monitoring.

• Package identifiers and signing keys must be verified before app-store submission. Credentials must

be backed up securely and not regenerated without understanding the effect on existing releases.

• New integrations require security, privacy, contractual, reconciliation, and failure-mode review

before launch.

7. Incident management

1. Detect and log the incident, time, systems, users, transactions, and initial impact.
2. Contain the incident by restricting access, pausing affected functions, or contacting the provider

where necessary.

1. Preserve evidence and avoid deleting logs, messages, builds, credentials, or transaction records

needed for investigation.

1. Assess notification duties to customers, Fiuu, banks, cloud providers, app stores, authorities,

insurers, or other affected parties.

1. Recover safely, validate the fix, monitor recurrence, and document lessons and corrective actions.
2. Business continuity and disaster recovery

• Maintain backups of critical configuration, source code, databases where supported, credentials

inventories, policies, contracts, and contact lists.

• Define recovery priorities for login, booking, customer support, payment status, crew dispatch, and

records.

• Maintain alternate authorised administrators and recovery contacts for Apple, Google, Firebase,

domain, email, payment, and banking accounts.

• Test restoration and account-recovery procedures periodically and after major changes.
• Communicate clearly during outages and avoid accepting transactions when service delivery or

payment status cannot be reliably confirmed.

9. Key risk indicators

• Payment failure, refund, chargeback, fraud-alert, and unmatched-settlement rates.
• App crashes, API failures, downtime, failed notifications, and unresolved security findings.
• Customer complaint volume, response times, repeat service failures, and cancellation rates.
• Crew verification gaps, payout-account changes, duplicate accounts, and disputed completion

evidence.

• Overdue risk actions, excessive privileged accounts, dormant accounts, and unsuccessful

backup/recovery tests.

10. Exceptions and policy review

Exceptions must identify the reason, risk, compensating controls, approver, owner, and expiry date. Permanent informal exceptions are prohibited. This policy is reviewed at least annually and after a material incident, new payment method, major platform change, regulatory change, or significant vendor change.

References

This policy is informed by the following sources. It should be read together with applicable laws, payment-provider agreements, and GoFix customer-facing terms.

• Bank Negara Malaysia publications on safe and efficient payment services and relevant risk,

technology, electronic-money, and merchant-acquiring expectations.

• Fiuu Malaysia Terms of Services and payment-channel schedules relating to fraud, security,

transaction limits, reserves, refunds, disputes, and chargebacks.

• Applicable Malaysian laws and contractual requirements concerning privacy, cybersecurity,

consumer protection, employment/contracting, tax, and anti-money laundering.