Most organizations treat a VAPT engagement as a box ticking exercise, get the report, file it, and move on. But the real value of security testing is never in the findings document itself. It lives in what happens after: the prioritization decisions, the remediation sprints, the cross team friction, and the measurable reduction in actual risk.
This case study walks through a real world vulnerability assessment and penetration testing engagement with a mid market healthcare technology company operating in the United States. The organization managed web and mobile applications handling electronic health records, appointment scheduling, and telehealth services in a high value, compliance-sensitive environment with real consequences for a breach.
The goal here is not to celebrate the testing phase. The goal is to show exactly how remediation unfolded, what got fixed, what got deferred, what the team got wrong the first time, and what the security posture looked like six weeks after the engagement closed.
What This Case Study Covers and Why It Matters?
Security teams rarely struggle to find vulnerabilities. They struggle to fix them fast enough, completely enough, and with enough organizational support to make it stick.
The client in this engagement had undergone a basic vulnerability scan twelve months prior. The scan report sat unresolved. Forty three findings were flagged; eleven were addressed. The rest were classified as "low priority" based on CVSS scores and quietly deprioritized.
When a new CISO joined, the first decision was to run a proper engagement through a team offering full comprehensive security testing and assessment services covering network, application, and cloud layers in a single scoped engagement. The difference in findings was significant. More importantly, the difference in remediation outcomes was dramatic, because this time a structured process was built before the report was even delivered.
Readers who benefit most from this walkthrough are security engineers, IT managers, and CISOs who already understand what VAPT is and want to see how a real remediation program operates under organizational constraints.
Case Study Background — The Organization, Scope, and Threat Context
Organization Profile and Security Maturity Baseline
The client was a 200 person healthcare SaaS company serving hospital networks and independent clinics across seven U.S. states. Their core platform processed over 50,000 patient records monthly. Regulatory obligations included HIPAA, and they were working toward SOC 2 Type II certification.
Before the engagement, the security team consisted of two engineers and a part time compliance consultant. They used a commercial vulnerability scanner on a quarterly schedule, had no formal patch management process, and had never conducted a proper penetration test against their production APIs.
Their security maturity, assessed informally at the start of the engagement, sat at level two of five on a standard maturity model, reactive, with some documented policies but inconsistent enforcement. The attack surface was larger than anyone internally realized.
Defining the Scope — What Was and Wasn't Tested
The team selected grey box testing, testers were given limited application documentation and one standard user account, but no source code or infrastructure diagrams. The scope covered:
The primary patient-facing web application
A mobile API backend serving iOS and Android clients
Four internal admin interfaces accessible via VPN
Three AWS environments (production, staging, and a partially decommissioned dev environment)
The decommissioned dev environment nearly got excluded. The security team assumed it had no live data. During reconnaissance, the testing team found it had been left connected to the production database via a misconfigured IAM role. That discovery alone justified the entire engagement cost.
Rules of engagement specified testing windows between 10 PM and 6 AM local time to minimize disruption, with a direct escalation contact in case any test triggered application instability.
The VAPT Execution — Methodology and Real World Findings
Reconnaissance and Attack Surface Discovery
Before a single payload was sent, the team spent three days on passive and active reconnaissance. DNS enumeration surfaced eleven subdomains the client had never formally documented, including two that pointed to deprecated marketing tools still running on outdated CMS installations.
Port scanning revealed an administrative interface exposed on a non-standard port, protected only by HTTP basic authentication. The application team had forgotten it existed. Certificate transparency logs showed a staging environment with a publicly signed certificate, making it discoverable by anyone who knew where to look.
The reconnaissance phase alone reshaped the entire testing strategy. The client's security team had been mentally managing an attack surface of roughly ten assets. The real number was closer to thirty-one.
Vulnerability Identification — Scanners vs. Manual Testing
Automated scanners ran first and returned 217 findings across all environments. After deduplication and false positive removal, 94 remained. Of those, 61 were configuration level issues, missing headers, outdated library versions, default credentials on secondary services.
Manual testing found what the scanners missed entirely:
A broken object level authorization (BOLA) flaw in the patient record API that allowed any authenticated user to retrieve records belonging to other patients by manipulating a numeric ID parameter
A multi-step business logic vulnerability in the appointment rescheduling flow that could be exploited to access provider calendar data without authorization
An insecure direct object reference in the admin panel that exposed internal user IDs and account metadata
None of these carried exploits in public databases. None would have appeared in a standard scanner report. All three had direct HIPAA implications. Think of automated scanning like a metal detector at an airport, it finds the knives, but it won't find the social engineering attack that walks someone through the exit door unchecked.
Organizations relying exclusively on automated scanning tools instead of full penetration testing miss this class of finding consistently. The distinction is critical, and it shapes the entire remediation conversation.
Exploitation Phase — Proving Real World Impact
The testing team exploited the BOLA vulnerability to demonstrate that a standard patient account could retrieve records for any other patient in the system. A proof of concept export of 500 synthetic test records was produced and shared with the CISO, not to alarm, but to make the business risk concrete.
Post exploitation work on the misconfigured dev environment showed a viable lateral movement path from dev into production read access via the overprivileged IAM role. The attack chain involved four steps, none of which individually carried a CVSS score above 6.5. Together, they represented a critical-severity breach path.
This is precisely what separates real penetration testing from scanning. The MITRE ATT&CK framework maps this type of chained attack clearly, privilege escalation through misconfiguration, followed by lateral movement to sensitive data. Understanding the chain is what makes prioritization possible.
Vulnerability Prioritization — The Decision Layer Between Findings and Fixes
Why CVSS Scores Alone Are Insufficient for Remediation Planning?
The first draft remediation roadmap, produced by an internal team member before the formal prioritization session, sorted everything by CVSS score. Seventeen findings were marked "Critical" or "High." The BOLA vulnerability, one of the most dangerous findings in the report, was listed as a medium-severity issue with a base score of 6.1.
That is not an edge case. In Q1 2025, 28% of vulnerabilities actively exploited in real attacks carried only medium CVSS base scores. A CVSS score measures worst case technical severity under ideal attacker conditions. It does not tell you whether a vulnerability is reachable from the internet, whether an exploit exists in the wild, or whether it sits next to your most sensitive data.
Organizations that patch by CVSS score first are systematically working on the wrong things. The average enterprise can realistically remediate 10–15% of its vulnerability backlog per month. Spending that capacity on theoretical criticals while ignoring exploitable mediums is a common and costly mistake.
The Modern Prioritization Framework — CVSS + EPSS + KEV + Business Context
The engagement team introduced a four-signal prioritization model:
CVSS set the baseline severity floor. Anything below 4.0 required special justification to escalate.
EPSS (Exploit Prediction Scoring System) added exploitation likelihood. EPSS v4, updated in March 2025, processes over 250,000 threat intelligence data points daily to estimate whether a given CVE will be exploited in the wild within 30 days. The BOLA finding didn't have a CVE, but the underlying vulnerability class (OWASP API3:2023) had high EPSS-equivalent signals from threat intelligence feeds.
CISA KEV flagged three infrastructure-level findings as confirmed exploited in the wild. These jumped to immediate remediation regardless of their CVSS score.
Business context was the fourth layer. The admin panel findings affected a system storing provider financial data. The mobile API flaws affected the highest-traffic, most publicly exposed surface. Asset criticality scaled every other score.
Combining these signals reduced 94 findings to a working priority list of 22 items requiring immediate action, a 77% reduction in cognitive load for the remediation team, without losing coverage of the threats that actually mattered.
Building the Remediation Roadmap — From Priority Matrix to Ticket Queue
Every finding was translated from CVE notation and technical description into a business-readable statement. "CVE-2024-XXXX TLS 1.0 enabled on port 443" became: "Outdated encryption on the patient login page can be intercepted by an attacker on the same network, affects all users on public Wi-Fi." That language gets the budget approved. Technical jargon does not.
Findings were pushed directly into Jira as structured tickets with severity labels, assigned owners from either the DevOps, AppSec, or cloud infrastructure team, and attached to a four-week remediation sprint. Each ticket included specific remediation steps, not just a CVE description and a link to the NVD.
Tier 0 (critical, exploitable, in scope for HIPAA) had a 72-hour SLA. Tier 1 (high severity or high EPSS signal) had a 14-day SLA. Tier 2 (medium, low EPSS, no KEV flag) had a 45-day SLA.
Proper security assessment documentation and reporting, structured, business-friendly, and actionable, are what make this translation possible. Reports that list CVEs without context do not drive remediation. They cause confusion.
The Remediation Phase — What Was Fixed, How, and What Got Pushed Back?
Critical and High Severity Remediation — The First 30 Days
Week one focused on three Tier 0 items:
The misconfigured IAM role in the dev environment was corrected within 48 hours, access to production databases was revoked, the dev environment was formally decommissioned, and a policy requiring quarterly access reviews was documented.
The BOLA vulnerability in the patient record API required an application level fix: object-level authorization checks were added to every API endpoint that accepted a patient ID parameter. The fix took four developer days and was validated by a targeted retest before the sprint closed.
The outdated OS on a legacy reporting server, an end of life Windows Server instance that hadn't been in the formal asset inventory, was isolated immediately and scheduled for decommissioning within 90 days. A compensating control (network isolation via security group rules) was applied the same day.
By day 30, all eleven Tier 0 findings were closed. The mean time to remediate for critical tier items came in at 8.3 days, a meaningful benchmark for future sprints.
A web application firewall was deployed in front of the primary patient portal, MFA was enforced for all administrative accounts, and end to end encryption was updated across all data transmission paths. These weren't just point fixes, they addressed entire classes of future vulnerabilities.
For organizations building web application security testing programs, this phased approach, isolate, fix, compensate, retest, is more sustainable than trying to close everything at once.
Medium and Low Severity Findings — Triage, Deferral, and Risk Acceptance
Of the 51 Tier 2 findings, 29 were resolved within the 45 day window. The remaining 22 were formally risk-accepted or deferred, with documented rationale.
Three findings were deferred because the remediation required a major library upgrade that would break a third party integration used by fourteen hospital clients. The business impact of the upgrade outweighed the security risk at that moment. That is a legitimate risk acceptance decision, as long as it is documented, reviewed quarterly, and not forgotten.
Five low severity findings were accepted as residual risk with compensating controls in place. A missing X-Frame-Options header, for instance, was partially mitigated by a CSP policy already deployed in Tier 0. Treating it as a separate open item would have inflated the backlog without reducing real risk.
The lesson: not every finding needs to be fixed. Every finding needs to be decided on closed, deferred with a date, or accepted with a control. A clean risk register beats an ignored vulnerability list every time.
Configuration Hardening and Systemic Fixes Beyond Individual CVEs
Roughly 40% of the findings weren't CVEs at all, they were misconfigurations. Missing HTTP security headers across six subdomains. An overly permissive S3 bucket policy. Admin interfaces without brute-force rate limiting. Role assignments that violated least privilege.
These don't show up in CVE databases. They don't have CVSS scores. But they are the findings attackers love most, because defenders tend to underestimate them.
The remediation team worked through CIS Benchmark recommendations for AWS and applied DISA STIG-aligned hardening to all Linux servers. Security headers CSP, HSTS, Referrer Policy, and Permissions Policy were added to every web property in scope. RBAC policies were audited and tightened across all three AWS environments.
The practical value of structured network security assessment methodology is that it surfaces these systemic gaps that point-in-time patching never catches. Organizations running network layer penetration testing programs find that configuration hardening often delivers more risk reduction per hour of effort than patching individual CVEs.
Retesting and Verification — Closing the Loop
The Retest Process — How to Verify Fixes Actually Work?
Three weeks after the remediation sprint closed, the testing team returned for a focused retest. Retesting is not a rescan. A scanner will tell you that TLS 1.0 is no longer advertised. It will not tell you whether the BOLA fix actually prevents patient A from accessing patient B's records under authenticated conditions.
Every Tier 0 and Tier 1 finding was retested manually using the same techniques from the original engagement. Four findings that had been marked "fixed" in the Jira queue were not actually remediated:
The BOLA fix had been applied to the web application endpoints but not to the equivalent mobile API endpoints. The vulnerability remained fully exploitable via the mobile client.
A rate-limiting fix on the login page had been implemented, but only for the primary domain, not for an alias domain that resolved to the same backend.
An outdated jQuery library had been updated in the production build, but was still present in the staging environment, which shared infrastructure with production.
These are not unusual outcomes. Partial fixes are common under time pressure. The retest is the mechanism that catches them before an attacker does.
Remediation Rate and What the Metrics Showed
At the 60-day mark, the engagement produced the following measurable outcomes:
100% of Tier 0 (critical) findings closed
87% of Tier 1 (high priority) findings closed within SLA
57% of Tier 2 (medium/low) findings closed, with the remainder formally risk-accepted or deferred
MTTR for critical findings: 8.3 days (industry benchmark is often cited at 60+ days for organizations without a formal remediation program)
Attack surface reduction: 31 previously unmanaged assets brought into the formal inventory, 8 decommissioned
These numbers were reported to the board in a single page risk summary, not a technical report, but a before/after comparison framed in terms of patient data exposure, regulatory risk reduction, and operational resilience.
The CISO made a point that is worth repeating: a patch compliance rate of 90% tells you nothing about security. A Tier 0 remediation rate of 100% within 72 hours tells you something real.
Key Lessons — What Engagement Revealed About Real World Remediation?
The Organizational Challenges Are Harder Than the Technical Ones
The hardest week of the engagement wasn't the exploitation phase. It was week two of remediation, when the development team pushed back on fixing the BOLA vulnerability because it required refactoring API endpoints that were already scheduled for a Q4 rebuild.
The CISO had to make a judgment call: force the fix now and absorb the cost of duplicated work, or accept the risk for three months. The decision was to fix it now, with a streamlined approach that minimized rework. That decision required executive authority.
Without leadership sponsorship, most remediation programs stall at exactly this point. Security teams can identify risks. Only organizational authority can force the prioritization trade-offs needed to fix them.
The security team also had to develop a shared ownership model with DevOps and cloud infrastructure. Many of the configuration findings had no clear owner, the IAM role misconfiguration existed because no single team was responsible for cross-environment access reviews. Remediation forced the creation of a documented ownership matrix that outlasted the engagement.
The Danger of Treating VAPT as a Compliance Checkbox
The client's previous vendor had run an annual scan and issued a clean-ish report. Auditors were satisfied. The actual security posture had not improved.
There is a meaningful difference between compliance oriented vulnerability scanning and full adversarial penetration testing. Scanning tells you what software versions you're running. Penetration testing tells you whether an attacker can take your patient data.
Frameworks like ISO 27001 and PCI DSS Requirement 11.3 mandate regular security assessments, but they don't mandate that those assessments actually find anything difficult. Organizations that treat testing as an audit artifact tend to select vendors who produce clean reports, not vendors who find real problems.
The shift in mindset this client made, from "we need a report for our auditors" to "we need to know where we're actually exposed", is the single biggest predictor of remediation success.
For teams building a security operations center function or managing security for a SaaS based product environment, this distinction determines whether testing produces genuine risk reduction or just documentation. Organizations supporting SaaS platforms with continuous deployment especially benefit from security testing that integrates with their release cycle rather than replacing it.
Integrating Remediation into the DevSecOps Pipeline
After the engagement closed, the client made one structural change that mattered more than any individual fix: they added SAST scanning to their CI/CD pipeline and required security sign-off on any API endpoint change.
The BOLA vulnerability existed partly because there was no automated check for authorization logic during code review. Adding a rule that flagged missing authorization decorators in the application framework caught three similar issues in the six weeks following the engagement — before they reached production.
DAST tooling was integrated into staging environment testing. Dependency scanning was added to the build pipeline. These are not substitutes for a proper penetration test, but they compress the window between vulnerability introduction and detection from months to days.
For teams exploring different security testing approaches and methodologies, the post-engagement integration phase is where the long-term value is built. The penetration test finds the debt. The pipeline changes prevent future debt from accumulating.
How to Apply These Lessons to Your Own VAPT Engagement?
Before the Test — Preparing for Maximum Remediation Value
Organizations that get the most value from security testing do three things before the testers arrive:
Build an asset inventory. The biggest finding in this engagement, the misconfigured dev environment, which existed because it wasn't in anyone's asset register. Know what you have before someone else discovers it.
Assign remediation owners by category. Before the report lands, decide who owns infrastructure findings, who owns application findings, and who owns cloud configuration findings. The moment of report delivery is the wrong time to start that conversation.
Set internal SLAs by risk tier. Decide in advance what "critical" means to your organization and how fast you will respond. A policy that pre authorizes emergency sprints for Tier 0 findings removes the approval bottleneck that kills remediation velocity.
After the Report — Running an Effective Remediation Program
Read the VAPT report as a risk roadmap, not a findings list. The question is never "how many vulnerabilities were found?" The question is "which of these, if exploited, would cause the most damage, and how fast can we close them?"
Translate findings into business language before presenting to leadership. Budget decisions are made by people who think in terms of patient trust, regulatory fines, and operational continuity, not CVSS scores.
Schedule the retest before the remediation sprint starts. Knowing a verification date is coming creates accountability in the development team. Fixes that can't be verified by a specific date don't count.
Track remediation rate by tier, not by total count. A team that closes 90% of low-severity findings while leaving three Tier 0 issues open has a worse security posture than a team with a lower overall closure rate but 100% Tier 0 completion.
Conclusion
Real-world vulnerability remediation is less about tools and more about decisions, what to fix first, who owns it, how to verify it, and how to stop the same class of issue from reappearing.
This engagement succeeded not because the penetration test was unusually thorough, but because the organization built a remediation process before the report arrived, maintained executive sponsorship through the hard trade off conversations, and verified fixes rather than trusting developer attestation alone.
Three principles separated this outcome from the typical VAPT report that sits unread: composite risk prioritization instead of CVSS first sorting, cross-team ownership with documented accountability, and a retest that caught four incomplete fixes before an attacker could find them.
Security testing is the starting point. Remediation is the work. The organizations that treat penetration testing as continuous, not annual, not compliance-driven, but genuinely integrated into how software is built and infrastructure is managed, are the ones that measurably reduce risk over time.
The question for any security leader reading this is not whether to run a VAPT. It is whether your organization has the structure to do something useful with what it finds.
