Scope & coverage record
Workflow boundary, approved rules, tested roles and versions, selected cases and dependencies. Examined documents, interviews and executed tests remain distinguishable.
THE ENGAGEMENT
One workflow.
A defensible decision.
Patient-access penetration testing follows a request through your configured systems, checks who may act, and verifies the result against your organization’s rules.
Scope the workflow, not a prompt count.
The flagship assessment covers one agreed patient-access workflow and its named dependencies. For example: a patient or proxy cancels or reschedules through an IVA connected to a scheduler, including the resulting record, confirmation and assisted recovery path.
Your proposal identifies the included channels, integrations, environments, sites, roles and operations. A portal, second connector or additional workflow is included only when named. We establish price and schedule after reviewing these boundaries and the available evidence.
Three questions guide the work.
- Can an unauthorized requester cause a consequential action?
- Can a legitimate patient or proxy still complete the intended request?
- Can the team establish the actual outcome and recover when something fails?
Optional expansion
Add cross-channel continuation, voice identity, agent tool permissions, referral routing or change-triggered reassessment where the architecture requires them. Pharmacy intake, pickup and account workflows use separately agreed permission and clinical boundaries; scheduling logic does not establish prescription authority.
Before testing begins.
- Written authorization from relevant system owners, including vendor-controlled test surfaces.
- A named security sponsor, patient-access operational owner and integration or vendor owner.
- Customer-approved patient/proxy rules, confirmation requirements, escalation ownership and stop conditions.
- Synthetic test accounts and records in an agreed environment, with controlled notification recipients.
- Access to relevant connector events, authoritative records and configuration versions—or explicit observation limits.
- Agreed evidence storage, permitted processors, access, retention and deletion procedures.
A scoping conversation can begin before these are assembled. Submitting an inquiry does not authorize testing.
Evidence with an owner and a next step.
Findings & decision brief
Expected behavior, reproduction conditions, attempted versus committed effects, evidence references and contextual consequences. Pass, Fail, Blocked, Not assessed and Not applicable each carry a reason.
Remediation & bounded retest
Recommended corrections, customer-assigned owners and unresolved risk. One retest round for agreed findings is included; its window, eligible changes and environment are written into the proposal. Material scope changes require a new agreement.
The retest repeats the relevant failure condition and a legitimate-use counterpart. The customer owns implementation and risk acceptance. A finding is not closed merely because a patch was reported.
Inspect a synthetic finding ↗A clear engagement boundary.
This is a sampled, authorized assessment of the specified configuration. It does not certify a hospital, establish HIPAA compliance or guarantee that every vulnerability will be found.
Clinical diagnosis and triage validation, medical-device testing, denial-of-service activity, unrestricted social engineering, continuous monitoring and incident response are outside the flagship scope. Production testing requires separate explicit authorization and controls.
Assessments do not include unlimited remediation or around-the-clock technical response. Urgent customer communication helps establish the next step under the engagement; it does not itself create an incident-response retainer.
BEFORE THE NEXT ROLLOUT