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.
4.9
Clutch