RCF Security

Approach

Offensive engagements follow the Penetration Testing Execution Standard. The phases below are the same for a single application and for a multi-site network, and the depth of each one is set during scoping. Defensive work carries the same evidence standard: every recommendation traces to something observed, and configured is never reported as verified.

The seven phases

  1. Pre-engagement and scoping

    We agree on targets, address ranges, application roles, test windows, and the things that must not be touched. You sign a written authorization, and we confirm you have the right to authorize testing of every asset in scope, including anything hosted by a third party. Emergency contacts are exchanged before the first packet is sent.

  2. Intelligence gathering

    We map what an attacker can learn without your help: domains, subdomains, exposed services, technology in use, breached credentials tied to your people, and the footprint you did not know you had. Findings here often change the shape of the test.

  3. Threat modeling

    We decide what an attacker would actually want in your business, which is rarely everything. Payment data, the accounting system, the domain, the file server holding contracts, the backups. Test effort follows the assets that matter, not an even spread across the network.

  4. Vulnerability analysis

    Automated tooling covers ground quickly, then every candidate is verified by hand. Scanner output on its own is not a finding, and anything we cannot reproduce is either dropped or reported plainly as unconfirmed.

  5. Exploitation

    We prove the finding by using it, inside the rules of engagement. Where exploitation would risk availability or data integrity, we stop at proof of access and say exactly what was proven and what was not. Critical findings are reported the day they are confirmed, not held for the report.

  6. Post-exploitation

    Access is only interesting for what it reaches. We establish how far the compromise extends: what data is readable, which accounts and systems follow, and whether the path ends at the domain. Everything we touch is logged so your team can reconcile our activity against their alerts.

  7. Reporting and retest

    The report has an executive summary written for owners and a technical section written for engineers, with CVSS 3.1 scoring, CWE identifiers, OWASP mapping, evidence, and reproduction steps for each finding. We walk your team through it, then retest the fixes and issue a closure letter.

Rules we work under

Authorization first. No testing begins without a signed authorization naming the assets and the window. If an asset belongs to a hosting provider or a vendor, we confirm their permission too.

Your data stays yours. Evidence is kept only as long as the engagement and the retest require, stored encrypted, and destroyed on request. We do not use your findings as marketing material, and we do not name clients without written permission.

Proven, observed, and out of scope are three different words. Each finding says which one it is. You will never read that something was verified when it was only configured.

If testing risks disrupting production, we say so during scoping and agree on the limits then, rather than discovering them at two in the morning.