Cybersecurity · Security Testing
The HIPAA Security Rule is deliberately technology-neutral: it requires an accurate and thorough risk analysis and a periodic technical and nontechnical evaluation of your safeguards — and never once names a penetration test. How you make those requirements credible is left to you. A pentest is how the technical half of that evaluation gets real evidence behind it.
Independent quality engineering & cybersecurity since 2020 — 100+ security & quality engineers, delivering on platforms we build and run ourselves.
ePHI incidents carry regulatory scrutiny, notification duties, and the loss of patient and partner trust — and a risk analysis that never tested whether its own assumptions hold is the first thing that scrutiny lands on after an incident.
See a redacted sample report
The structure, depth, and remediation detail your team will receive — client identity and evidence removed.
45 CFR §164.308(a)(1)(ii)(A) requires an 'accurate and thorough assessment of the potential risks and vulnerabilities' to ePHI. A penetration test replaces assumption with demonstration: which vulnerabilities are actually reachable, actually exploitable, and what data they expose.
§164.308(a)(8) requires a periodic technical and nontechnical evaluation of how your security measures meet the Rule — repeated in response to environmental and operational changes. Recurring testing cycles give the technical side of that evaluation current, documented evidence.
The Security Rule mandates no specific test, frequency, or tool — it is deliberately flexible. That cuts both ways: nothing forces you to run a pentest, and nothing specific shields you if you never did. We tell you what the Rule says and scope to your actual risk, not to fear.
Testing shaped to where electronic protected health information lives and moves — patient-facing applications, APIs, integrations, and the infrastructure behind them — so findings map to the data your compliance program answers for.
01
A scoping call with the testers themselves — targets, rules of engagement, and what evidence you need out.
02
Manual assessment aligned to OWASP, PTES, and NIST SP 800-115, with daily contact for critical findings.
03
Findings ranked by exploitability and impact, each with reproduction and remediation guidance.
04
Verification of fixes and an updated report — the cycle then repeats on your release cadence.
Engagement
Buy it as a scoped project, embed it in your team, or run it as a managed service — same engineers, same governance, whichever shape fits.
A scoped, one-time assessment with a full report and one retest — for a release gate, a customer or audit requirement, or an annual baseline.
Recurring assessment cycles aligned to your release cadence, with retesting each cycle so the evidence stays current across surveillance audits.
Add an application, API, or environment to an existing program without re-contracting — scoped and started in days, not procurement cycles.
No — the words 'penetration test' appear nowhere in the Security Rule, and anyone citing a specific HIPAA pentest mandate is misquoting it. What 45 CFR §164.308 does require is an accurate and thorough risk analysis and a periodic technical and nontechnical evaluation of your safeguards. Penetration testing is a recognized way to put real evidence behind the technical side of that evaluation — that's the honest case for it, and the only one we make.
The Rule sets no frequency — it requires evaluation periodically and in response to environmental or operational changes. In practice that maps to a cadence tied to your release and infrastructure change rate; we scope to how fast your environment actually changes rather than a boilerplate calendar.
Yes. Remediation of reported findings is verified and the report updated to 'remediated and retested' — the wording auditors expect. Retest scope and window are set in the engagement agreement.
Senior engineers from our own bench — 63% hold industry certifications (CISSP, CEH, eCPPT, ISTQB, AWS). The people who scope your engagement are the people who run it; there is no rotating offshore bench behind the proposal.
Engagements run under NDA, and engineers who handle client data undergo background checks. Findings and reports are shared through channels agreed at scoping and are not retained beyond the period needed to deliver and support the engagement. Data-handling specifics — storage, encryption, retention, and destruction — are documented in your service agreement; see the Trust page for our posture.
This is one stage of a single assurance loop: findings become regression tests, and their indicators become live detections — so a problem, once fixed, can’t quietly come back. That’s what you get from one integrated partner that a stack of separate vendors can’t. See how the loop connects →
A 30-minute call with the engineers who will do the testing — not a sales gate.