01 — From the inside
Your configuration
With a narrow, read-only role you deploy, we read your configuration and your own scan results: where data lives, how it is protected, and who can reach it.
BATech ProbePre-ship security & PHI review
Find it before you ship.
Before your system goes live, BATech Probe reviews it from the inside and the way an outsider would see it, then checks the security you promise against what the system actually does. One review, both angles.
We scope a Probe to your system and come back with what it would cover and an indicative estimate. A Probe replaces no penetration test and makes no certification.
Probe — readiness · illustration
HOLDMeridian Copay Services · pre-launch review
- 1
- Critical
- 2
- High
- 4
- Medium
- 1
- Low
Blocker. An endpoint answers with member records and no sign-in — fix before launch.
What happens next
- Both anglesWe read your configuration from the inside and your attack surface from the outside.Reviewed
- A ship / hold callOne verdict, with the blockers named first.
- Findings and fixesEach ranked, with the evidence and a fix an engineer can paste.
- A re-checkAfter you fix, we check again and close each finding.Closed
Illustration: a fictional client on fictional data, not a real engagement. It has the shape of one real case — a system a day from launch, answering with records that no one was meant to reach without a sign-in.See what a Probe delivers
The gap is between what you say and what you run.
Your security page, your questionnaire answers and your BAA all make promises. Your system is whatever actually runs in production. Almost nobody checks one against the other before launch — and the day you go live is the worst day to learn they drifted apart.
- You write the promises.A security page, a vendor questionnaire, a BAA: the protection you tell customers you have.
- You build the system.Config, services and endpoints, changed by many hands and under a deadline.
- They drift apart.A default left on, a route left open, a log that keeps what it shouldn't. Quietly, and nobody meant it.
- Launch day exposes it.The first person to find the gap is rarely you, and rarely friendly.
The only way to know is to check the system itself.
One review, both angles.
A scanner sees one side. An attacker sees another. A Probe looks from both, because a gap is only closed when it is shut from the inside and invisible from the outside.
02 — From the outside
Your attack surface
With your written permission, we look at the hosts you name the way an attacker would: what is reachable, which endpoints answer without a sign-in, and what is exposed.
Both angles land on one list. A setting that looks safe from the inside but answers to anyone outside is the same finding seen twice — and seeing it twice is how we know it is real.
Your words, checked against your system.
You have already written down what your security does. A Probe takes each claim and holds it against what the system actually shows — and marks the ones it cannot back.
All patient data is encrypted at rest.Not backed
No patient data is written to logs.Not backed
Access follows least privilege.Partly
Traffic is encrypted in transit.Backed
Illustrative claims and verdicts on fictional data. Each verdict carries the evidence that decided it: a backed claim says where we saw it hold; a claim we cannot back says exactly where it fails.
You are shown what we could not back, too.
A review that only confirms what you hoped is not a review. Every claim we cannot stand behind is named, with the evidence that decided it, so you fix the wording or fix the system — your choice, made on fact rather than on a feeling.
What a Probe delivers.
One verdict, the findings underneath it, and a re-check once you have fixed them. Everything is evidence an engineer can act on, not a score you have to trust.
A ship / hold call.
One verdict, with the blockers named first — the things that would expose data the day you go live.
Findings and fixes.
Each one ranked, with the exact evidence that proves it and a fix an engineer can paste.
A re-check.
After you fix, we check again and close each finding with new evidence — this release, and the next.
One finding, in full.
- Where
GET /api/v1/members/{id}on api.example.com- Evidence
- 200 OK returned a full member record with no
Authorizationheader — one request, captured and dated. - Fix
- Require an authenticated session on the members route; return
401when the token is absent. - Both angles
- Read-only config shows the route behind the gateway; the outside view reaches it anyway.
In the report
- A single ship-or-hold verdict, dated, with the blockers first.
- Every finding ranked, each with its evidence and a fix to paste.
- Where protected health information could travel, mapped from your configuration, not from the data itself.
- A re-check that closes each finding with fresh evidence, or says plainly why it is still open.
Built for the team about to ship.
A Probe is for whoever has to put their name on “it’s safe to launch” — and the sensitive data that makes that call matter.
- Software teams at health and pharma companiesThe system that touches patient data, reviewed before it carries any.
- Patient-access and copay programsThe portals and endpoints members reach, checked before members do.
- Founders shipping a system that handles PHIAn outside read before launch, and before a customer’s security questionnaire asks for one.
What a Probe covers
A point-in-time review of one system, scoped with you and set down in writing before we start.
- Bothangles: your configuration from the inside, your attack surface from the outside.
- Read‑onlya narrow role you deploy and revoke; a Probe changes nothing it reviews.
- 1re-check after you fix, closing each finding with fresh evidence.
- BAAin place before any real patient data reaches us.
Over the line. A Probe is a review of the scope you name at the moment we run it — not continuous monitoring, and not a promise that nothing will ever go wrong. So the scope is written down, what we could not reach is written down with it, and the price is set to that scope and no more.
What a Probe is — and what it is not.
The whole point of a Probe is to be honest about a system before launch. That starts with being honest about the Probe.
A Probe is
- A pre-ship review from both angles — your configuration from the inside, your attack surface from the outside.
- Findings about exposure and configuration, each with the evidence that proves it.
- A ship-or-hold verdict you can act on, and a re-check that closes what you fix.
A Probe is not
- Not a penetration test, and no replacement for one.
- Not a certification or an attestation, and not continuous monitoring.
- Not a reading of your patients’ data — findings are about exposure and configuration, and where PHI could travel is read from your configuration, not from the data itself.
The honest version, in full. A Probe replaces no penetration test and makes no certification. Findings are about exposure and configuration — a Probe never reads patient data to produce them, and a map of where protected health information could travel is read from your configuration, not from the data itself. A Business Associate Agreement is in place before any real patient data reaches us. Every price we give is an indicative estimate, not a quote.
Tell us the system and the scope.
Send what you are about to ship and where it lives. We come back with what a Probe would cover for your scope and an indicative estimate. Then, with a BAA in place and a read-only role you deploy, we review it from both angles and give you a ship-or-hold call you can act on.
- Pre-ship review
- [email protected]
- What a Probe covers
- One review, both angles What a Probe delivers
- The honest version
- What a Probe is, and is not