Incident Response Procedure
Last updated: 10 October 2026
1. Purpose
This document describes how Alphastrive Company Limited (RC 7467693), trading as PaySphere, handles security incidents — from the moment something looks wrong to the point where the incident is closed and lessons are recorded. It applies to our team, our infrastructure, and our third-party processors.
2. What Counts as an Incident
An incident is any event that could harm the platform, user data, or the people using PaySphere. Examples: unauthorised access to a user account or the database; a data breach or suspected breach; loss or theft of a device with production access; a vulnerability discovered in the platform; a third-party processor disclosing or losing data; a successful injection or authentication bypass; unusual financial activity that suggests fraud or system compromise; and denial-of-service attacks that affect availability.
3. Severity Levels
We classify incidents into three levels. Critical: a confirmed or highly probable breach of personal data; active unauthorised access to the database or admin systems; a financial fraud event affecting user funds; or any incident likely to require NDPC notification. High: a suspected breach pending investigation; a single-user account compromise; a significant vulnerability discovered in a live endpoint; or unexpected data exposure in a third-party processor. Low: a failed attack that was blocked (e.g. rate-limited); a single misconfigurations caught before exploitation; or an anomalous event that investigation shows had no data impact.
4. Detection
Incidents can be detected from: Sentry error and performance alerts; Supabase authentication logs (unusual login patterns or access from unexpected locations); Upstash rate-limit breach alerts; Telegram operational alerts (unusual withdrawal or trade volume); user reports to [email protected]; third-party processor breach notifications; and our automated security test suite. All team members with production access are expected to report anything suspicious to the DPO immediately.
5. Immediate Steps (First 2 Hours)
When a possible incident is identified: (1) Do not ignore it — report it to the DPO (Abiodun Tolulope, [email protected]) and the technical lead. (2) Record the time, what was observed, and who first noticed it. (3) Do not delete or modify logs, even if they look embarrassing. (4) If there is active unauthorised access, revoke the relevant credentials or API keys immediately. (5) If a specific user account is compromised, disable it pending investigation. (6) Isolate the affected system or endpoint if doing so does not destroy evidence. (7) Assign an incident lead — one person is responsible until the incident is closed.
6. Assessment
Within 4 hours of detection, the incident lead should assess: what data was accessed, modified, or lost; how many users are affected; how the attacker or cause got in; whether the incident is ongoing or contained; and whether it meets the threshold for NDPC notification. The assessment should be documented, even briefly, in writing.
7. Containment
Containment means stopping the incident from getting worse. Actions depend on the type of incident, but typically include: revoking compromised credentials and API keys; disabling affected endpoints or features; patching the vulnerability if it is known and the fix is straightforward; blocking attacker IPs at the network or application layer; and alerting any affected third-party processors so they can take action on their end.
8. NDPC Notification (72-Hour Rule)
Under NDPA 2023, we must notify the Nigeria Data Protection Commission (NDPC) within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of data subjects. The notification must include: a description of the breach; the categories and approximate number of people affected; the categories and approximate volume of records involved; the name and contact details of our DPO; a description of the likely consequences; and the measures we have taken or plan to take. The notification is sent to: ndpc.gov.ng. Even if all the facts are not known within 72 hours, we notify with what we know and supplement it later.
9. User Notification
If the breach is likely to result in a high risk to affected users — for example, if financial data, identity documents, or credentials were exposed — we notify those users without undue delay. The notification is sent by email to the address on their account. It will explain: what happened, in plain language; what data was involved; what we have done to address it; and what the user can do to protect themselves (e.g. change password, watch for suspicious activity). We do not use vague language or minimise the incident in user notifications.
10. Recovery
Once the incident is contained, we restore normal service. This may include: restoring the database from a recent backup (Supabase point-in-time recovery is available); reissuing crypto addresses or eSIM records if provisioning data was affected; crediting wallets if funds were lost due to a system error rather than user action; and working with affected third-party processors to restore their services. We document every step taken during recovery.
11. Post-Incident Review
Within 14 days of an incident being closed, we hold a post-incident review. The review covers: a timeline of events; the root cause; what controls failed or were missing; what worked well; what we are changing to prevent recurrence; and any updates needed to this procedure or the security policy. The review is documented and kept for at least 3 years. For Critical incidents, the review is shared with the DPO and, where relevant, disclosed to the NDPC as part of the follow-up notification.
12. Third-Party Processor Incidents
If a processor (Flutterwave, Dojah, Bitnob, Sotel, Supabase, Vercel, or others) notifies us of a breach affecting PaySphere user data, we treat it as our own incident from the moment we are aware of it. We follow the same assessment, notification, and review process. We will ask the processor for a written incident report and retain it.
13. Financial Incident Handling
If an incident involves user funds — missing wallet balance, duplicate credits, fraudulent withdrawals — the financial team must be involved from the start. Any affected wallet balances are frozen (not zeroed) pending investigation. We do not process withdrawals for affected accounts until the incident is resolved. If user funds were lost through a platform error or breach, we will make those users whole where it is within our ability to do so.
14. Record Keeping
Every incident, regardless of severity, is logged. The log includes: date and time discovered; who discovered it; a description of what happened; the severity classification; actions taken; people notified (including the NDPC, if applicable); how it was resolved; and the date it was closed. Incident records are retained for 7 years.
15. Contact
To report a security concern: [email protected]. DPO (Abiodun Tolulope): [email protected]. NDPC: ndpc.gov.ng.