Most Kenyan businesses discover a security problem the same way — a customer reports something strange, a payment fails oddly, or a partner's compliance team asks a question nobody can answer. By then the question is no longer "are we exposed?" but "how long have we been?"

An Authorized Web & API Security Assessment answers that question on your terms, under written permission, before someone else answers it for you.

Who this is for

SMEs, startups, NGOs, and established teams running a public web application, a customer portal, or an internal API that touches personal or financial data. It is particularly relevant if you are:

Handling personal data of Kenyan residents, and therefore in scope for the Kenya Data Protection Act (KDPA).
Being asked for a security attestation by an enterprise client, bank, or donor before contract signature.
Running a product built quickly under deadline pressure, where security review was deferred.
Integrating third-party services, webhooks, or AI agents that hold credentials to your systems.

What gets reviewed

The assessment uses the OWASP Top 10 and the OWASP API Security Top 10 as its structural baseline, verified by hand rather than by scanner output alone. Automated tooling finds candidates; a human confirms whether each one is actually exploitable in your context.

Review Area	What Is Examined
Authentication & Session	Login flows, session lifetime, token handling, password-reset abuse paths, multi-factor coverage.
Authorization	Broken object-level authorization (BOLA), privilege escalation between roles, tenant isolation.
Input Handling	Injection surfaces, unsafe deserialization, file-upload handling, server-side request forgery.
API Surface	Undocumented and legacy endpoints, rate limiting, mass assignment, excessive data exposure in responses.
Configuration	Security headers, TLS configuration, CORS policy, verbose error output, exposed admin paths.
Secrets & Credentials	Keys in client bundles, repository history, environment misconfiguration, third-party token scope.
Data Protection	PII at rest and in transit, logging leaks, retention behaviour, KDPA lawful-basis alignment.

The boundary — permission before testing

RULES OF ENGAGEMENT

No assessment begins without a signed scope defining exactly which hosts, applications, and endpoints are in scope, which are explicitly excluded, the testing window, and the escalation contact. Testing is non-destructive by default. Denial-of-service, social engineering of staff, and any activity against systems outside the agreed scope are excluded as a matter of policy, not negotiation.

What you receive

Findings register — each issue with severity, affected surface, reproduction steps, and evidence.
Plain-language risk summary — written so a non-technical director or board can act on it, not just an engineer.
Remediation guidance — specific fixes with implementation notes, ordered by risk against effort.
KDPA mapping — where a finding creates statutory exposure under the Act, it is flagged against the relevant obligation.
Retest pass — confirmation that closed findings are genuinely closed, not merely reported as closed.

Evidence and method

The methodology behind this service is documented publicly rather than asserted. See the SOC incident walkthrough for triage and investigation approach, and the KDPA Developer Checklist for how regulatory obligations are translated into code-level controls. Commercial delivery experience is recorded in the Munar security baseline and handover.

How engagements start

Most clients begin with the Secure Digital Workflow Assessment, a fixed-scope two-to-three-week discovery engagement that establishes the current-state map and identifies whether a deeper technical assessment is warranted. It is the cheapest way to find out what you actually need.

START HERE

Engagements begin with a fixed-scope scoping call. Clear decisions before code, and no obligation to proceed to follow-on build work.

Request a Scoping Call →