Information Security Policy
1. Purpose
This policy states how Fueling Agile protects customer, company, and system data for our fleet fuel-management platforms. It is the top-level security policy. More detailed rules live in Access Control, Data Protection, Encryption, Incident Response, Acceptable Use, and Vulnerability Disclosure.
2. Scope
- All Fueling Agile staff, contractors, and administrators with access to production or customer data
- Systems that run AgileFlex / FANMS (application servers, databases, CI/CD, and supporting services)
- Company (fleet customer) and platform-admin use of the product
3. Principles
- Least privilege — people and systems get only the access they need.
- Defence in depth — multiple controls (edge TLS, auth, roles, audit, approvals).
- Honesty — we only claim controls that exist in production.
- Accountability — sensitive actions are logged and, where required, approved.
- Continuous improvement — we review this policy at least every six months, or after a material incident or architecture change.
4. Security objectives
| Objective | How we pursue it today |
|---|---|
| Confidentiality | HTTPS at the edge; secrets kept out of source control; role-based access; company-scoped customer data |
| Integrity | Authenticated APIs; approval workflow for high-risk admin changes; audit trails |
| Availability | Controlled deploys via CI; production API not exposed directly to the public internet |
| Accountability | Session tracking, admin activity logs, correlation IDs |
5. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Leadership | Approve this policy; fund security work; accept residual risk |
| David Owolabi (Security owner) | Maintain policies; run reviews; coordinate incidents |
| Developers & operators | Follow secure coding and deploy practices; never commit secrets |
| Platform admins | Use assigned roles only; treat customer data as confidential |
| Customers | Protect login credentials; report suspected misuse promptly |
6. Baseline technical controls
These controls are implemented today and are mandatory for production:
- Transport security: Public traffic terminates TLS at the reverse proxy (Caddy). The API is not published on a public host port.
- Authentication: Email/password with BCrypt hashing; JWT access tokens; refresh tokens bound to revocable server-side sessions.
- Login abuse controls: Per-IP rate limiting; account lockout after repeated failed attempts.
- Authorization: Role-based admin policies; company (and optional subsidiary) scoping for customer data.
- Change control: High-risk admin changes go through an approval request workflow.
- Audit: Admin activity logging; HTTP audit logging for mutating admin API calls.
- Secrets: Production secrets live in deployment configuration, not in git.
- Production hardening: Swagger disabled in production; job dashboard remote access restricted.
- Separation of environments: Test and production stacks are separate.
7. What we do not claim yet
Staff must not state these as current product guarantees until implemented and verified:
- Multi-factor authentication (MFA) or SSO
- Formal SOC 2 / ISO 27001 certification
- PCI DSS certification
- Application-level field encryption for all PII/card fields at rest
- Centralized SIEM / 24×7 security operations centre
8. Policy enforcement
Violations may result in access revocation, disciplinary action, and/or contract remedies. Technical enforcement is preferred: authentication, roles, session revocation, approvals, and audit logs.
9. Related policies
Access Control · Data Protection · Encryption · Incident Response · Acceptable Use · Vulnerability Disclosure
10. Review
Version 1.0 — 1 January 2026. Initial public security policy pack aligned to FANMS production controls.