A Pentest That Didn't Disrupt the Business

The Challenge

A financial consulting firm with a decentralized workforce came to us with a specific complaint about previous pentest vendors: every prior engagement had tried to force their organization into a vendor’s cookie-cutter methodology. Those prior firms required visible agent installs on every employee laptop, disruptive access workflows that didn’t match how the business actually worked, and testing windows that created real friction for people trying to do their jobs. Coverage was partial anyway. Staff morale took a hit each cycle. Leadership had started to wonder whether pentesting was worth the cost, which is exactly the wrong conclusion for a regulated firm to reach.

The firm’s architecture reflected how the business actually operated. Consultants worked from home offices, client sites, and coworking spaces. Critical systems lived in cloud platforms the firm had deliberately chosen for their remote-work compatibility. Sensitive client data was concentrated in specific platforms and workflows, not spread across every laptop. A pentest that assumed a centralized corporate network was a pentest designed for a different company.

The prior vendors had also delivered reports that the firm’s team could not act on effectively. Findings arrived after testing ended, with no opportunity to verify remediation during the engagement. Any vulnerability surfaced in April sat in the queue until a retest months later, and retests cost extra. That created a pattern where reports sat unread while the team waited for bandwidth to handle them in batches.

The Approach

We scoped the engagement to the firm’s actual architecture rather than forcing them into our template. Our testing follows the Penetration Testing Execution Standard (PTES), and the first conversation was not about what we were going to test. It was about what attackers would actually target given how this business worked: the cloud platforms holding client data, the authentication boundaries separating consultants from production systems, the administrative workflows that could move sensitive information, the third-party integrations their clients depended on. That conversation shaped the scope.

Testing concentrated on those high-value targets. External and authenticated perimeter testing against the cloud platforms. Identity and access testing against their authentication stack. Targeted internal testing against the administrative workflows that, if compromised, would give an attacker the ability to exfiltrate client data or disrupt service delivery.

Endpoint posture was part of the scope too, but we did it without the visible footprint that had burned the firm on prior engagements. Rather than pushing a new agent onto every consultant’s laptop, we used the firm’s existing RMM tool to deploy a lightweight, silent telemetry agent across the endpoint fleet. The agent ran on scheduled intervals during system idle windows so it never competed with the consultants’ work, gathered endpoint configuration data mapped against CIS Benchmarks, collected vulnerability information, and swept for common Indicators of Compromise (IOCs). When the collection window closed, the agent was removed as silently as it had been deployed. No user-visible install prompt, no slowdown, no support ticket. The consultants never noticed, which was the point.

We coordinated with the firm’s internal IT lead throughout. Anything that could generate noise in their security tooling or flag in their logs was telegraphed in advance so their team could distinguish our activity from real threat behavior. When we found something, we reported it to the internal team immediately rather than holding it for the final report. That changed the engagement economics in a way that mattered.

The Outcomes

Low-criticality findings surfaced during the test were worked through with the internal team while testing was still in progress. Each one got remediated, and we verified the remediation against the same attack path that had produced the original finding. By the time the final report was written, the findings section reflected the verified post-remediation state rather than the initial snapshot.

The result was a genuinely clean final report. Not because testing was shallow, not because we papered over findings, but because the engagement actually fixed what it found while it was happening. That is a different deliverable than most pentest firms produce. It is also the deliverable the firm’s leadership and auditors actually want: evidence that testing occurred, evidence that findings were addressed, evidence that remediations work.

The positive observations section of the report documented the controls that had performed well under testing. Those are audit evidence. They are also morale for the team that built and maintains those controls. Every pentest report includes a findings section. Too few include the part that says, on paper, with specifics, what is working. We include it because it matters.

End users saw almost nothing. The endpoint posture assessment ran through their existing RMM during idle windows and removed itself when the collection window closed. No required install prompts, no mysterious pop-ups on their laptops, no scheduled downtime, no urgent emails from IT asking them to do something. The consultants kept consulting. The business kept running. Our testing found what it was meant to find without becoming a drag on the operation it was supposed to protect.

This engagement is why our first conversation with any pentest prospect is about their architecture and their business, not about our methodology. When we’ve been the people receiving bad pentest reports, we know what a bad pentest engagement feels like from the inside. We design our engagements to avoid being that.