Your auditor is asking for a pentest. We run it.
Human-led security testing for regulated platforms — patient portals and clinical APIs, payment flows and banking applications, and the AI features you shipped last quarter. Fixed price, framework-mapped report, retest included.
We test regulated platforms — and only regulated platforms
Healthcare and financial services share the same problem: an auditor, a regulator, or an enterprise customer demanding evidence you can't produce with a scanner. They don't share the same architecture, so we don't pretend they do. Based in Ontario, we work in the Canadian regulatory environment every day.
Clinical platforms and patient data
Health-tech has a specific shape: a patient-facing app, a clinician console, integrations you inherited, and multi-tenancy holding it all apart. We start there instead of learning it on your time.
- Patient portals and clinician consoles
- FHIR R4, HL7 v2, SMART on FHIR interfaces
- Cross-tenant and cross-patient authorization
- EMR and partner integrations
- Clinical AI: intake assistants, summarizers, scribes
Payment flows and banking applications
PCI DSS 11.4 isn't an annual checkbox. It requires a documented methodology, internal and external testing at least every twelve months and after any significant infrastructure or application change, plus retesting of what you fix — so for a team shipping frequently, a material change to a payment flow can reset the clock.
- Online banking and customer portals
- Payment gateways and cardholder data environments
- Financial APIs and open-banking integrations
- Segmentation testing to validate CDE scope reduction
- Financial AI: advisors, fraud and KYC automation
Fluent in the systems regulated platforms actually run on
Clinical interoperability on one side, payment rails on the other, and the same modern application stack underneath both.
Four engagement types
The same four engagement types across both industries — scoped to what you actually run.
Web applications
Patient portals, clinician consoles, banking front-ends, customer dashboards. The full OWASP Top 10, plus the authorization logic deciding which records a user can reach.
- Cross-tenant and cross-account access
- Session, auth, privilege escalation
- Business-logic abuse in clinical and payment flows
- Upload, export, and reporting paths
APIs & integrations
FHIR and HL7 interfaces, payment and open-banking APIs, partner integrations, and the endpoints behind your mobile client — where most real data exposure lives.
- Broken object-level authorization (BOLA)
- FHIR scope and compartment enforcement
- Payment flow and transaction-logic abuse
- Undocumented and legacy endpoints
- Token handling across integrations
AI features & agents
Clinical scribes and intake assistants, financial advisors, fraud and KYC automation — anything that can take an action on its own, tested for failure modes scanners were never built to find.
- Direct and indirect prompt injection
- PHI and account data leakage across sessions
- Excessive agency and unsafe tool calls
- RAG poisoning and retrieval abuse
Compliance readiness
Gap assessment against the standard you're held to — so the evidence you hand your QSA, auditor, or enterprise customer closes the question instead of opening three more.
- PCI DSS v4.0.1 Req 11.4 evidence readiness
- PHIPA and Ontario Health standards
- OSFI B-13 and FSRA expectations
- SOC 2 security criteria
- HIPAA Security Rule alignment
A report your engineers can work from and your auditor will accept
Most pentest reports are a scanner export with a logo on it. Yours is written for two readers: the executive who needs to know what it means, and the engineer who has to reproduce and fix it.
- Reproduction steps that actually work. Request, payload, preconditions — not "manipulate the parameter."
- Business impact in plain language. What an attacker gets, and what it means for your customers and obligations.
- Framework mapping per finding. OWASP, PHIPA, SOC 2 criteria — evidence that drops into your compliance workflow.
- Remediation guidance, not just diagnosis. Specific fix direction your team can ticket immediately.
- Retest verification. Written confirmation each finding is genuinely closed — the part auditors ask for.
No surprises, start to finish
You'll know the scope, the price, and the timeline before anything is touched.
Scope
A short call to map what you've built and what you're being asked to prove. You leave with a fixed quote and a rules-of-engagement document.
Authorize
Signed authorization-to-test, agreed testing windows, a named emergency contact, and a defined stop condition. Nothing is touched before this.
Test
Manual testing against the agreed scope, tooling-assisted but never tooling-only. Critical findings are reported the day they're found, not held back for the report.
Report & retest
Full report plus a walkthrough call with your engineers. Once fixes ship, the retest confirms each finding is properly closed.
Fixed scope, fixed price
Agreed before work starts. Every engagement includes a retest — you shouldn't pay twice to confirm a fix worked.
Focused
One application, portal, or API with a defined boundary.
- One web app, portal, or API
- OWASP Top 10, manually verified
- Findings mapped to your framework
- Report with reproduction steps
- One retest included
Application & Integration
A regulated product with real integrations. The usual starting point.
- Application, APIs, integration layer
- Cross-tenant and cross-account authorization
- FHIR / HL7 or payment and banking interfaces
- Business-logic and chained exploits
- Audit-ready report + engineer walkthrough
- Retest and remediation debrief
Continuous
For teams testing on a recurring cadence — such as PCI DSS 11.4 "after significant change".
- Testing on each significant change
- Annual internal and external assessment
- Segmentation testing on your applicable cadence
- Audit evidence maintained year-round
- Priority scheduling and a direct line
How your data and your uptime are handled
You're authorizing someone to probe the system your patients or customers depend on. That deserves stated commitments, not assumptions.
Canadian-based, data stays in Canada
Ontario-based and Canadian-owned. Testing is performed in Canada by one named practitioner — no offshore subcontracting — and engagement data and reports are stored in Canada.
Authorization before anything
No scanning, probing, or reconnaissance before a signed scope and authorization-to-test — including before we've spoken.
Staging over production
Testing runs against staging or synthetic data wherever the engagement allows, so real patient and customer records stay untouched by design.
Findings treated as sensitive
A findings report is a map of how to attack you. Encrypted at rest, shared over secure channels, destroyed on an agreed schedule.
Contracted and accountable
A signed MSA, mutual NDA, and one named person accountable for the engagement from scope through retest. Proof of insurance provided on request.
Questions worth asking
What health-tech and fintech teams ask before a first engagement.
We've never had a pentest. Where do we start?
With a conversation, not a purchase. A scoping call establishes what you've built, what's genuinely exposed, and what your customer or regulator is asking you to prove. Sometimes the answer is a focused test on one portal; sometimes it's a readiness gap assessment first. You'll get a straight recommendation either way — including if the honest answer is "not yet."
Will testing disrupt production, patient care, or live transactions?
It shouldn't, and preventing that is part of scoping. Testing targets staging or a dedicated environment wherever possible, windows are agreed in advance, and destructive techniques are excluded unless explicitly authorized. Payment and clinical workflows get particular care — no test transactions against live rails, no interference with care delivery. You get an emergency contact and a defined stop condition before testing begins.
Our customer or QSA sent a security questionnaire. Does a pentest answer it?
Most of it. Hospital and enterprise procurement — and a QSA reviewing PCI DSS 11.4 — typically asks whether you've had independent third-party testing, when it last happened, what methodology was followed, and how findings were remediated and retested. A framework-mapped report plus completed retest evidence answers all four. If the questionnaire extends into governance and policy, a readiness assessment covers that ground.
How is this different from the scanner our CI already runs?
Scanners find known patterns — vulnerable dependencies, missing headers, common misconfigurations. They can't reason about your business workflow, so they won't find that a user at clinic A can reach clinic B's records by changing an ID, that a transaction limit can be bypassed by reordering a payment flow, or that your assistant can be talked into repeating what a previous customer told it. PCI DSS is explicit that a vulnerability scan is not a penetration test — Requirement 11.4 asks for active exploitation, which needs a person who understands how the system is meant to behave.
What exactly do we receive?
A report written for two audiences — an executive summary for leadership and auditors, and technical detail your engineers can work from directly. Each finding carries severity, plain-language business impact, framework mapping, working reproduction steps, and specific remediation guidance. Plus a walkthrough call, and the retest verification afterwards.
Where are you based, and where does our data go?
Reiver Security is Canadian-owned and based in Ontario. Testing is performed in Canada by one named practitioner — nothing is subcontracted offshore — and engagement data, evidence, and reports are stored in Canada. For PHIPA-covered organizations and Canadian financial institutions, that usually matters: it keeps your assessment evidence inside Canadian jurisdiction rather than adding a cross-border data question to your next audit. Engagements are contracted in Canada.
Who is actually doing the testing?
One named CISSP-certified practitioner with a professional background in web application penetration testing — not a rotating bench and not an offshore subcontractor. You'll know who is testing your system, and that person is on the walkthrough call. For a small team that continuity is usually the point: the tester who found it is the one explaining it. PCI DSS is explicit that the tester does not need to be a QSA or ASV — what it requires is demonstrable competence and organisational independence, both of which are documented in the engagement record.
We're a small team. Are we too small for this?
Small teams are the core of this practice. Large vendors price and staff for enterprise portfolios, which leaves early-stage health-tech and fintech paying enterprise rates for attention they don't get. The Focused tier is deliberately sized for a company that has shipped a product but hasn't hired a security team yet.