DHA Certification: Penetration Test and Vulnerability Assessment Reports
DHA certification requires a penetration test report and a vulnerability assessment report dated within 12 months. We produce both, with remediation evidence, for Kenyan HMIS vendors.
Kenya's Digital Health Agency marks both security reports Required, and both must be dated within the last 12 months. We produce them, evidence the remediation, and keep them current every year.
The DHA certification portal lists two security reports under its Compliance category and marks both Required: a Penetration Testing Report covering testing from within the last 12 months, and a Vulnerability Assessment Report carrying evidence that the findings were actually remediated. They are two separate uploads. An application cannot be completed without both.
The twelve-month rule is the part most vendors miss. Because the portal asks for recent testing, this is not a document you produce once and file away. Every year the reports age out, and a system whose evidence has expired is exposed at the next review. We run it as an annual cycle rather than a one-off engagement: test, remediate, retest, re-evidence, so the reports sitting in your portal are always current when a reviewer opens them.
Testing a health system is not the same as testing a normal commercial application. The findings that matter are the ones that reach patient data: whether an anonymous caller can read protected health information, whether one facility can see another facility's records, and whether the authorisation model holds when it is attacked rather than merely reviewed. That is what we test for, and it is what the reports evidence.
What's included
- Penetration Testing Report — A manual, human-led penetration test written up for the DHA Compliance upload: scope, authorisation, rules of engagement, findings with proof of impact, and a dated report that satisfies the within-12-months requirement.
- Vulnerability Assessment Report with remediation evidence — The portal asks for assessment results and remediation evidence, not a scanner export. We assess, hand your developers a prioritised fix list, then retest and document each closure so the report proves the gaps were shut rather than merely found.
- Application and API testing — The clinical web application, the REST API and the FHIR endpoints tested for broken object-level authorisation, injection, session and authentication flaws, and the business-logic abuse that scanners never construct.
- Multi-tenant isolation testing — The test that matters most in a shared HMIS: proving a user at one facility cannot reach another facility's patients, through the API, through database views, or through privilege escalation in the authorisation model.
- Remediation support and verification retest — We advise your developers while they fix, then retest every finding at no extra cost and record the closure. This is the step that turns an assessment into the remediation evidence the portal actually asks for.
- Annual recertification testing — A yearly cycle that keeps both reports inside the twelve-month window and re-tests after material releases, so your evidence is refreshed before it expires rather than after a reviewer notices.
How it works
- Scoping and rules of engagement — Targets, testing windows, patient-data handling constraints and escalation contacts agreed in writing before anything is touched. Health systems carry live clinical data, so the rules here are stricter than a commercial pentest and we scope accordingly.
- Vulnerability assessment — Broad automated and credentialed coverage across the application, APIs, dependencies, database authorisation model and cloud configuration, producing the ranked baseline the assessment report is built on.
- Reconnaissance and attack surface mapping — We enumerate what is actually exposed: subdomains, endpoints, integration paths and public functions. This routinely surfaces surface area teams had forgotten was reachable.
- Manual penetration testing — Human-led exploitation focused on patient-data impact: anonymous access to clinical records, cross-facility isolation, privilege escalation through database functions, and broken authorisation on the API.
- Remediation and verification retest — We work alongside your developers as they fix, then retest every finding and record the evidence of closure that the Vulnerability Assessment Report has to carry.
- Reporting and upload-ready delivery — Both reports delivered in a form built for the portal upload, plus a live debrief with your engineering team and help answering any clarification request that follows.
What you walk away with
- Penetration Testing Report, dated and formatted for the DHA Compliance document upload
- Vulnerability Assessment Report with per-finding remediation evidence
- Executive summary written for your board and for DHA reviewers
- Prioritised, developer-ready remediation plan ranked by patient-data impact
- Free verification retest of every remediated finding, with closure evidence
- Attestation letter you can share with facilities and enterprise customers
- Annual refresh so both reports stay inside the twelve-month window
Frequently asked questions
Is a penetration test mandatory for DHA certification?
Yes. The DHA certification portal lists a Penetration Testing Report under the Compliance category and marks it Required, described as recent penetration testing results from within the last 12 months. A Vulnerability Assessment Report is listed separately, also under Compliance, also marked Required, described as recent vulnerability assessment and remediation evidence. Both are distinct uploads and both must be present for the application to be complete.
How recent does the penetration test report have to be?
The portal asks for results from within the last 12 months. In practice that makes DHA certification an annual security testing commitment rather than a one-time submission: a report dated more than a year before a review is stale, and a system whose evidence has expired is exposed at recertification or whenever the application is re-examined. We run the testing annually, and additionally after any material release, so the uploaded evidence is never what holds up an application.
What is the difference between the Penetration Testing Report and the Vulnerability Assessment Report?
They are two separate Required uploads, and a reviewer will notice if the same document has been submitted twice. The vulnerability assessment is broad and largely automated: it enumerates weaknesses across the whole system and, critically for DHA, must be accompanied by evidence that those weaknesses were remediated. The penetration test is narrow and human-led: a tester exploits the weaknesses to prove what an attacker could actually reach, including the authorisation and business-logic flaws no scanner finds.
Can we run the penetration test ourselves?
You can, and internal testing is genuinely useful between cycles, but be careful about what it proves. A test run by the vendor against its own system is not independent, and DHA files the Penetration Testing Report under Compliance rather than Technical, which is where independence normally matters. The safer position is a report from an external assessor, with your own internal testing running alongside it rather than in place of it.
What does the vulnerability assessment have to include?
More than a scan. The portal describes the upload as recent vulnerability assessment and remediation evidence, so the report has to show the findings and then show they were closed. In practice that means an assessment, a prioritised remediation list your developers actually work through, and a verification retest that records each closure. A raw scanner export with a hundred unresolved findings evidences the opposite of what the reviewer is looking for.
What should the testing actually cover in a health system?
The controls whose failure would expose patient data. That means anonymous and unauthenticated access paths to clinical records, cross-facility isolation in a multi-tenant deployment, the authorisation model in the database rather than only in the application, the REST and FHIR APIs, and privilege escalation routes. Generic OWASP Top 10 coverage is necessary but not sufficient: the flaws that matter in an HMIS are usually authorisation flaws, and they are found by testing the tenancy model directly.
How long does the testing take?
Typical engagements run one to three weeks of active testing depending on scope, with the reports delivered within about a week of testing ending. The remediation and verification retest cycle then depends on your developers, and it is usually the longer part. If you are working to a deadline, start with a scoping call so we can tell you plainly what is reachable in the time you have. Call +254 725 722 965 or request a scoping call.