Incident Response Policy
1. Purpose
Define how we detect, contain, investigate, and learn from security incidents affecting AgileFlex / FANMS or customer data.
2. What counts as an incident
- Unauthorized access to an admin or company account
- Suspected credential theft or session hijacking
- Malware on an operator machine with production access
- Accidental exposure of secrets, dumps, or customer exports
- Ransomware / destructive change to production
- Confirmed abuse of privileged APIs or approval bypass
- Personal-data breach under NDPA
Suspicious fuel transactions flagged by product rules are business fraud alerts. They become security incidents when they involve system compromise or unauthorized access.
3. Severity
| Level | Meaning | Response target |
|---|---|---|
| P1 — Critical | Active breach, data exfiltration, or production down due to attack | Immediate; all-hands |
| P2 — High | Likely compromise or sensitive secret exposure | Same business day |
| P3 — Medium | Contained abuse, failed attack with lasting risk | Within 2 business days |
| P4 — Low | Policy violation or hardening gap without evidence of exploit | Planned fix |
4. Response steps
- Detect & report — Anyone can report to fuelingagilenigeria@gmail.com. Include time, what happened, systems involved, and whether customer data may be affected.
- Triage — David Owolabi (or delegate) assigns severity and an incident owner.
- Contain — Revoke sessions; disable accounts; rotate exposed secrets; block abusive IPs at the edge if needed.
- Eradicate — Remove the cause (patch, revoke keys, fix misconfiguration).
- Recover — Restore service from known-good deploys/backups; verify auth and audit trails.
- Notify — Inform affected customers and, where legally required, authorities. Do not speculate publicly.
- Learn — Write a short post-incident note: timeline, root cause, what we change, owner, due date.
5. Evidence we can use
- Application and reverse-proxy logs
- Admin activity / audit records
- Login and session history
- CI/CD and deploy history
Preserve logs before rotating or deleting during an investigation.
6. Communication rules
- Internal: facts only during containment
- Customers: clear, timely, accurate
- Public: leadership-approved statements only
- Never share raw credentials, full card numbers, or unnecessary personal data in tickets or chat
7. Enforcement and drills
- Ignoring a known P1/P2 incident is a policy violation
- Run a lightweight tabletop exercise at least once per year
- After any P1/P2, update this policy or the deploy SOP if gaps appear