DHA Certification in Kenya: The Penetration Test and Vulnerability Assessment Requirement

Two reports, two separate uploads

The most common mistake is treating this as one requirement. It is two, and they are not interchangeable. The portal creates a distinct upload slot for each, and submitting the same document against both is the fastest way to draw a clarification request.

A vulnerability assessment is broad and largely automated. It enumerates known weaknesses across the whole system: dependencies, configuration, exposed services, transport security, and the authorisation surface. Its job is coverage. A penetration test is narrow and human-led. A tester takes those weaknesses and tries to reach something that matters, chaining flaws into an actual exploit path. Its job is certainty.

Scanners find what is known. Testers find what is specific to your system, which in a health information system is almost always an authorisation flaw: a record reachable by someone who should not reach it. That class of flaw is invisible to automation because nothing about the request is malformed. It is simply the wrong person asking.

• Penetration Testing Report: Required, Compliance category, results from within the last 12 months
• Vulnerability Assessment Report: Required, Compliance category, must carry remediation evidence
• Two distinct uploads, not one document filed twice
• ISO 27001 appears alongside them but is marked Optional

The twelve-month rule makes this annual

The portal asks for recent penetration testing results, within the last 12 months. That single phrase changes the shape of the obligation. Certification is not a submission you complete once: it is an evidence set that has to stay current.

A report dated more than a year before a review is stale on its face. Any vendor treating the test as a one-off will, within twelve months, be holding a certification supported by expired evidence, and the exposure surfaces at recertification or at any point DHA re-examines the application.

The practical consequence is that security testing belongs in your annual operating budget rather than in the one-time cost of getting certified. Vendors who plan it that way also test after material releases, so the report reflects the system as it actually is rather than as it was at certification.

Remediation evidence is the part people underestimate

The portal does not ask for a vulnerability assessment. It asks for a vulnerability assessment and remediation evidence. Those are different deliverables, and the second one is where most submissions are weak.

A raw scanner export listing a hundred open findings evidences the opposite of what a reviewer wants to see. It demonstrates that you looked and did nothing. What satisfies the requirement is an assessment, followed by a prioritised remediation cycle your developers actually work through, followed by a verification retest that records each closure.

That sequence takes time, and it depends on your engineering team rather than on the assessor. If you are working to a deadline, the retest is the long pole, not the scan. Plan backwards from it.

• Assessment: enumerate and rank the findings
• Remediation: your developers close them, prioritised by real impact
• Verification retest: the assessor confirms and records each closure
• The report submitted should show the cycle, not just the first step

What the testing should actually cover in a health system

Generic OWASP Top 10 coverage is necessary but not sufficient. In a system holding patient records, the findings that matter are the ones that reach protected health information, and they are usually authorisation failures rather than injection or misconfiguration.

The tests worth insisting on are the ones that prove isolation holds under attack rather than merely being present in the design. In a multi-tenant HMIS serving several facilities, the question a reviewer implicitly cares about is whether one facility can see another's patients. That should be tested directly, against real multi-facility data, not inferred from the presence of a tenancy column.

Equally, an authorisation model enforced only in the application layer is one API call away from being bypassed. Where the database itself enforces access, that enforcement should be exercised by an unauthenticated caller and by an ordinary user, not assumed from the fact that policies exist.

• Anonymous and unauthenticated access paths to clinical records
• Cross-facility isolation in a multi-tenant deployment, tested against real multi-facility data
• The authorisation model at the database layer, not only in the application
• REST and FHIR API endpoints, including object-level authorisation
• Privilege escalation routes, including database functions that run with elevated rights
• Any endpoint intentionally exposed without authentication, and whether it enforces its own gate

Internal testing versus an independent assessor

Nothing stops you performing your own testing, and doing so between annual cycles is good practice. But a test run by the vendor against its own system is not independent, and it is worth being deliberate about that rather than discovering the objection at review.

DHA files the Penetration Testing Report under Compliance rather than Technical. Compliance is ordinarily where independence matters, and a reviewer assessing whether a system is safe to hold patient data has an obvious reason to prefer a report from someone who did not build the thing being tested.

The defensible position is an external assessor's report as the submitted evidence, with internal testing running alongside it to catch regressions between cycles. If you do submit internal testing, say plainly on the face of the report that it is internal. A report that quietly presents itself as more than it is will damage your credibility with a reviewer far more than the limitation itself would have.

Why the published manual does not mention either report

The official DHA Applicant User Manual, version 1.0 dated February 2026, contains a required documents checklist. Neither the Penetration Testing Report nor the Vulnerability Assessment Report appears anywhere in it. Both are marked Required in the live portal.

This is not the only place the manual has fallen behind, but it is the most consequential, because these two documents carry the longest lead time of anything in the pack. A vendor who plans from the manual discovers a mandatory testing requirement at the point of upload, with no time to run an assessment, remediate and retest.

The rule to work by: the live portal is the authority, not the manual and not articles written from it. Log into your own application, open the document upload screen, and plan from the list the portal shows you.

Key takeaways

• A Penetration Testing Report and a Vulnerability Assessment Report are two separate uploads, both marked Required in the DHA portal under Compliance.
• The penetration test must cover results from within the last 12 months, which makes security testing an annual obligation rather than a one-off.
• The vulnerability assessment must carry remediation evidence, so a scanner export with open findings does not satisfy it.
• The remediation and verification retest cycle depends on your developers and is usually the longest part of the work. Plan backwards from it.
• In a health system the findings that matter are authorisation failures, especially cross-facility isolation in a multi-tenant deployment.
• A test run by the vendor against its own system is not independent, and DHA files these reports under Compliance where independence normally matters.
• The February 2026 applicant manual does not mention either report. Plan from the live portal, not from the manual.

Frequently asked questions