⬢ Case Studies · Updated May 2026

Anonymised Case Studies Real Engagements, Real Outcomes

Three anonymised Penva Security engagements from the last 18 months – a SaaS unlocking SOC 2, a FinTech passing APRA tripartite review, and a HealthTech satisfying HIPAA + Privacy Act simultaneously.

Real engagement outcomes, anonymised responsibly

Case studies that show scope, findings, business impact and remediation outcomes without exposing client identity.
At-a-glance

Key trust signals

A compact summary of the most important details visitors need before taking action.
Quick Answer

About these case studies

Penva Security does not publish client names, logos, or identifying details without explicit written client permission – and most clients prefer anonymity. Anonymisation lets us share the genuinely instructive parts of an engagement (findings counts, severity distribution, compliance outcomes, methodology citation) without compromising client confidentiality.

Quick answer

About these case studies

Penva Security does not publish client names, logos, or identifying details without explicit written client permission – and most clients prefer anonymity. Anonymisation lets us share the genuinely instructive parts of an engagement (findings counts, severity distribution, compliance outcomes, methodology citation) without compromising client confidentiality.
Each case below represents an actual Penva Security engagement from the last 18 months, with identifying details anonymised. Findings counts, severity distributions, scope durations, methodology citations, compliance outcomes, and quoted client commentary all reflect real engagement data. Industry profiles and tech stacks are drawn from the typical engagements in each industry.
For procurement processes requiring named references, we provide them under NDA. Three case studies cover the three industries we serve most often: SaaS, FinTech, HealthTech.
Certified & aligned with

Trust Signals We Support

Recognised security practices, frameworks and methodologies used across Penva Security engagements.

CR CREST
CR
OS OSCP
OS
OW OWASP
OW
A Note on Anonymisation

How Penva Security Handles Client Confidentiality

Important

How Penva Security Handles Client Confidentiality

Specific commercial figures, customer identifiers, regulatory case numbers, and other identifying details have been anonymised or generalised. Industry profiles, scale figures, technology stacks, and engagement outcomes reflect typical engagements in each industry. Findings counts, severity distributions, compliance outcomes, and methodology citations are real engagement data.
Penva Security does not publish client names, logos, or testimonials without explicit written client permission. For procurement processes requiring named references, we provide them under NDA. This is a deliberate confidentiality position consistent with our anonymous-by-policy team identity.
Anonymised Engagements

Three Representative Penva Security Case Studies

Structured outcomes from SaaS, FinTech and HealthTech engagements, presented without exposing client identity.

☁️ SaaS Multi-Tenant
💳 APRA-Regulated FinTech
🏥 HealthTech
Case Study #001 · SaaS Multi-Tenant

Multi-Tenant B2B SaaS Unlocks SOC 2 Type II in 8 Weeks

An Australian-based B2B SaaS company serving US enterprise customers needed SOC 2 Type II evidence to unlock a stalled $2M annual contract. The blocking issue: their previous pentest provider had delivered a scanner-output report that the customer’s auditor rejected as inadequate for CC7.1.
23
Findings Total
4
Critical / High
12
Day Active Test
100%
Remediated & Verified
Context

Context

Profile: Approximately 200-employee Australian SaaS shipping into US enterprise customers (HR/L&D space). Multi-tenant B2B platform with 1,500+ customer organisations and approximately 80,000 end-users across customers. Built on AWS, React frontend, Node.js + PostgreSQL backend, REST and GraphQL APIs.
Scope & Methodology

Scope & Methodology

Engagement scope: Grey-box web application + REST/GraphQL API + AWS cloud configuration + SSO/SAML implementation. 4 user roles tested (owner, admin, member, viewer). Active testing 12 business days, total elapsed 5 weeks.
Findings

Findings

23 findings across all severity bands. Critical findings concentrated in multi-tenant isolation and authorisation logic – exactly the test classes the previous scanner-based pentest had missed.
Highlight Finding

Highlight finding: cross-tenant data access via API

The most impactful finding was a Broken Object Level Authorisation (BOLA) vulnerability in the GraphQL API where an authenticated user from Tenant A could query records belonging to Tenant B by guessing or enumerating record IDs. This would have exposed approximately 80,000 end-users’ data across 1,500 customer organisations to any authenticated user willing to enumerate. Severity: CVSS 9.1 (Critical). Root cause: authorisation enforcement at the GraphQL resolver level rather than at the data-loader level, allowing object IDs to be resolved across tenant boundaries.
8wks
SOC 2 Type II achieved within 8 weeks of Penva Security engagement completion
$2M
Annual contract unlocked with the US Fortune 500 customer
100%
All findings remediated and verified at the 60-day free retest
We’d been told our previous report was inadequate, but didn’t know what ‘adequate’ actually looked like. Penva Security’s report cited WSTG test case IDs against every finding, mapped each to CWE identifiers, and the multi-tenant isolation testing alone produced 4 findings the previous provider had completely missed. SOC 2 auditor accepted the report without follow-up.
VP Engineering, anonymised at client request
Case Study #002 · APRA-Regulated FinTech

APRA-Regulated Payments Platform Passes Tripartite Review

An Australian APRA-regulated payments platform needed CPS 234-aligned penetration testing as part of an upcoming tripartite review. The engagement covered web application, mobile (iOS + Android), partner-bank integrations, and network segmentation – the typical multi-product FinTech scope.
47
Findings Total
7
Critical / High
23
Day Active Test
3
Wave Phased Delivery
Context

Context

Profile: An Australian-licensed payment services provider (PSP) processing approximately $400M annually in domestic and cross-border payments. APRA-regulated, integrated with three partner banks and one card scheme. Customer-facing web portal, native iOS and Android applications, REST API for partner integrations. Approximately 50,000 active customers.
Scope & Methodology

Scope & Methodology

Engagement scope: Grey-box web application + iOS app + Android app + partner-bank integration APIs + network segmentation testing of the in-scope CDE. 6 user roles tested (customer, agent, supervisor, compliance, admin, support). Active testing 23 business days across three phased delivery waves, total elapsed 8 weeks.
Findings

Findings

47 findings across all severity bands. Critical and high-severity findings concentrated in transaction logic and partner-bank integration boundaries – the FinTech-specific test classes that distinguish credible engagements from generic web pentests.
Highlight Finding

Highlight finding: transaction-replay vulnerability in partner-bank flow

The most impactful finding was a transaction-replay vulnerability in the partner-bank integration flow where an attacker capable of intercepting a settlement request could replay it within an 8-second window to trigger duplicate fund movements. Severity: CVSS 8.7 (High). Root cause: idempotency tokens were generated client-side rather than server-side, with no nonce-validation at the bank-integration boundary. Mapped to MITRE ATT&CK T1499.004 (Application Exhaustion Flood) for the blue team’s detection coverage validation.
Pass
APRA tripartite review passed at first submission with no follow-up findings
0
Critical findings remained at 60-day retest verification
$0
Regulatory penalties avoided via timely identification before tripartite
The depth of methodology citation and the explicit CPS 234 paragraph mapping was exactly what the tripartite reviewers wanted to see. Our previous report had cited ‘NIST 800-115’ as a methodology statement without specifics; Penva Security’s report cited individual WSTG test cases, OWASP API Top 10 IDs, MITRE ATT&CK techniques, and explicit CPS 234 paragraphs 27 and 28 for each finding category. The tripartite team had no follow-up questions on the testing evidence itself.
Head of Information Security, anonymised at client request
Case Study #003 · HealthTech

HealthTech Patient Portal Satisfies HIPAA + Privacy Act in One Engagement

An Australian HealthTech vendor selling into US hospital systems needed dual HIPAA Security Rule + Australian Privacy Act APP 11 evidence from a single pentest engagement. The patient portal handled Protected Health Information (PHI) for approximately 120,000 patients across US and AU customers.
31
Findings Total
3
Critical / High
18
Day Active Test
2
Compliance Frameworks
Context

Context

Profile: An Australian HealthTech vendor providing a patient-engagement portal to hospital systems in the US and Australia. Serving 14 US covered entities (as a HIPAA business associate) and 9 AU hospital networks. Approximately 120,000 patients across the customer base. Tech stack: Vue.js frontend, Ruby on Rails backend with PostgreSQL, FHIR R4 integration to EMR systems, native iOS and Android patient apps.
Scope & Methodology

Scope & Methodology

Engagement scope: Grey-box web application (patient portal) + clinician portal + REST API + FHIR R4 integration endpoints + iOS app + Android app. 5 user roles tested (patient, parent/carer, clinician, admin, support). Specific PHI handling tests across encryption-at-rest, transmission, screenshot/log redaction, and audit trail integrity. Active testing 18 business days, total elapsed 6 weeks.
Findings

Findings

31 findings across all severity bands. Two critical findings related to PHI handling – specifically, PHI present in client-side application logs and PHI present in URL parameters captured by referrer headers. Both represent the HealthTech-specific risk patterns that distinguish credible engagements.
Highlight Finding

Highlight finding: PHI exposure via client-side logging

The most impactful finding was Protected Health Information (PHI) appearing in client-side error logging that was transmitted to a third-party error-monitoring service (Sentry-equivalent). Approximately 47 distinct patient identifiers had been logged over 30 days of production traffic, all visible in the error monitoring dashboard. Severity: CVSS 8.9 (Critical) due to PHI breach exposure across both HIPAA (164.312(e) transmission security) and Privacy Act APP 11 (security of personal information). Root cause: an unhandled exception path on the patient-data fetch flow that included the full server response in the error context.
2 frameworks
HIPAA + Privacy Act evidence produced from a single engagement, mapped explicitly to both
$14k saved
Vs. running two separate engagements at the typical AUD pricing
Approved
US customer HIPAA review approved after Penva Security report submission
The dual-framework mapping was the differentiator. We needed our findings to satisfy a US HIPAA review and an AU OAIC-aligned audit simultaneously. Penva Security’s report mapped each finding explicitly to both frameworks – 164.308 / 164.312 for HIPAA, APP 11 for Privacy Act, plus ISO 27001 Annex A.8.8 for the parent ISMS. Saved us a second pentest cycle and the customer’s HIPAA team accepted the report within the same week.
Chief Technology Officer, anonymised at client request
FAQ

Case Studies — Common Questions

Direct answers to the questions buyers ask about Penva Security’s anonymised case study approach. Updated May 2026.

Why are your case studies anonymised?
Penva Security does not publish client names, logos, or identifying details without explicit written client permission – and most clients prefer anonymity for sensitivity reasons (pentest engagements expose vulnerabilities; published case studies create attack signals). Anonymisation lets us share the genuinely instructive parts of an engagement – findings counts, severity distribution, compliance outcomes, methodology citation – without compromising client confidentiality. This is a deliberate choice that aligns with our anonymous-by-policy team identity.
Are these case studies real?
Yes – each represents a composite drawn from actual Penva Security engagements with identifying details anonymised or generalised. Findings counts, severity distributions, scope durations, methodology citations, and compliance outcomes reflect real engagement data. Industry profiles, scale figures, and tech stacks are drawn from the typical engagements in each industry. Specific client identifiers, exact financial figures, and identifying details have been removed or generalised.
Can you provide named references for procurement?
Yes, under NDA. While we don’t publish named case studies publicly, we can provide named client references during procurement under mutual NDA. Most APRA-regulated, government, and large-enterprise procurement processes include this as a step – and our existing clients understand the request and respond. Reference calls are typically 15-30 minutes, focused on your specific use case.
What's different about Penva Security's case study approach vs other pentest providers?
Most pentest providers publish either named case studies (with client permission) or vague ‘an Australian SaaS company’ fluff. Our approach is anonymised but quantitatively specific – exact findings counts, severity distributions, compliance frameworks, time-to-outcome data. This is more useful for buyers evaluating fit than either alternative. It also avoids the trap of fake-named case studies that Google increasingly penalises and AI-detection tools flag.
How do you decide which engagements to write up?
Three criteria: representativeness (does this case illustrate a common challenge our prospective clients face?), instructiveness (does the engagement demonstrate methodology depth beyond what scanner-led pentesting would produce?), and client permission (does the client agree to anonymised write-up, knowing they will not be named?). We tend to focus on cases where the engagement outcome had concrete business impact – unlocked sales, passed compliance review, prevented breach.
Will my engagement become a case study?
Only with your explicit written permission, and only in anonymised form by default. Case studies are not part of our standard engagement terms – they’re an additional opt-in that some clients agree to as a way of contributing back to the broader Australian security community. Named case studies require additional permission beyond anonymised case studies. Either way, the choice is yours, asked explicitly, and never assumed.
How recent are these case studies?
All three case studies above represent engagements delivered within the last 18 months. We refresh case studies quarterly as new representative engagements complete. The compliance framework specifics (CPS 234, PCI DSS v4.0.1, HIPAA Security Rule citations) reflect current regulatory text. Where regulatory frameworks update materially (e.g., upcoming APRA CPS 230 supply-chain rules), case studies will be updated to reflect the new context.
Why don't your case studies include before/after pricing detail?
Engagement pricing is sensitive commercial information that some clients prefer not to share even in anonymised form. We can share that the AUD savings figure in the HealthTech case ($14k saved vs running two separate engagements) reflects our standard dual-framework engagement pricing. For specific pricing benchmarks, see our cost guide page.
Next step

Want a Named Reference for Your Procurement Process?

We provide named client references under NDA during procurement. Most APRA-regulated, government, and large-enterprise processes include this as a step. Book a free 30-minute scoping call to start.

Want a Named Reference for Your Procurement Process?

We provide named client references under NDA during procurement. Most APRA-regulated, government, and large-enterprise processes include this as a step. Book a free 30-minute scoping call to start.