Why Security Cannot Be Bolted On
Security is not a feature you add at the end of a project. It is an architectural property that must be designed in from the beginning. Systems that "add security later" are inevitably more expensive to secure, more difficult to audit, and more likely to have vulnerabilities that were simply not considered.
Every system we build for government and enterprise clients begins with a threat model.
Our Security Stack
Authentication and Authorisation
We implement OAuth 2.0 with PKCE for public-facing applications and short-lived JWTs (15-minute expiry) with refresh token rotation. RBAC is stored as configuration data, not application logic, so permission changes don't require deployments.
Multi-factor authentication is mandatory for all administrative roles. We support TOTP apps (Authy, Google Authenticator) and hardware tokens (YubiKey) for high-security roles.
Data at Rest
Sensitive fields — national identity numbers, BVN, financial records — are encrypted at the application layer using AES-256 before storage. Database-level encryption is a second layer, not the only layer.
We implement data minimisation: we collect and store only what is needed for the system's function. Every field in a schema has a documented justification.
Data in Transit
TLS 1.3 minimum, with HSTS pre-loading. Certificate pinning for mobile clients accessing sensitive APIs. We reject TLS 1.0 and 1.1.
Injection Defence
Parameterised queries everywhere. No string concatenation in SQL. Input validation at the API boundary, not just the UI. Content Security Policy headers to prevent XSS.
Dependency Management
We run automated dependency audits on every commit. Critical vulnerabilities block deployment. We maintain a software bill of materials (SBOM) for all production systems and subscribe to security advisories for every major dependency.
Penetration Testing
Every new system undergoes penetration testing before go-live by an independent security firm. We do not test our own security with our own tools.
Annual penetration tests are included in our maintenance contracts for government clients. Findings are remediated within SLA — critical issues within 24 hours, high within 7 days.
Incident Response
We maintain documented incident response playbooks for every client system. If a breach occurs, the playbook defines: who is notified (and in what order), what evidence is preserved, how the breach is contained, and what public/regulatory disclosure obligations apply.
We test these playbooks with tabletop exercises, not just documentation reviews.
The Human Element
Technology alone does not create secure systems. The most sophisticated application security can be bypassed by a phishing attack on an administrator.
For every client, we provide security awareness training for administrative users, documented secure development guidelines for any developers who will maintain the system, and phishing simulation exercises for high-risk roles.
Conclusion
Security is a responsibility, not a product feature. Institutions that handle citizen data have an obligation — ethical and often legal — to protect it. We take that obligation seriously and build systems that reflect it.
