Skip to content
devwallssecurity
Coiled wire resting on a scratched metal surface
approach

how an engagement actually runs

Every engagement follows the same six stages, whether it is a five-day web test or a ten-week red team. The stages do not change. The depth does.

stages
Six, scoping to retest
report turnaround
5 working days
retest window
90 days, included
how an engagement runs
  1. 01

    Scope

    1 week before start

    We argue about scope until it is narrow and written down. A vague scope produces a vague report. This is a call with the people who own the systems, not a form.

  2. 02

    Recon

    Days 1–3

    We build a picture of your attack surface from the outside, the way someone targeting you would. Frequently we find assets you had forgotten you owned. That list alone has ended engagements early.

  3. 03

    Test

    The bulk of the engagement

    Humans in your system, chaining findings rather than listing them. Anything critical is called the same day. You have a shared channel with the testers throughout.

  4. 04

    Report

    Within 5 days of test end

    One document, two audiences. Engineers get reproduction steps and remediation notes. The board gets a page in plain English. Neither is a template with your logo dropped in.

  5. 05

    Fix

    Your timeline

    We stay available while you fix. Most clients use us as a second pair of eyes on the patch. This is included, not billed.

  6. 06

    Retest

    Within 90 days

    We test every fix and update the report. A finding is only closed when we have failed to exploit it again. Included in the original price.

rules of engagement
signed before day one

the constraints we put on ourselves, in writing

One named contact on each side

You get a phone number that reaches a human who can stop the engagement in one message. We get the same from you.

Criticals are called, not filed

If we find something that could be exploited today, you hear about it the same day. It goes in the report afterwards.

No individual is named

If social engineering is in scope, results are reported by team and by control. We will not hand you a list of people who clicked.

Pretexts we will not use

Bereavement, medical emergency, immigration status, or anything targeting someone's family. This is not negotiable, including when a client asks.

Evidence is destroyed on schedule

All engagement data is deleted thirty days after report acceptance, and we send you the confirmation.

You can watch everything

A shared channel runs for the whole engagement. Many clients keep an engineer in it full time, and we think that is the best way to buy this.

the report
five sections

written so the people who have to fix it can fix it

executive summary

One page. What we did, what we found, what it means commercially. Written to be read by someone who will not read the rest.

attack narrative

The engagement in order, as prose. This is the section clients circulate internally, because it is the one that makes the risk feel real.

findings

One per issue. Reproduction steps, evidence, affected assets, severity with reasoning, and remediation written for whoever owns that code.

detection review

What your tooling saw against what we actually did, with the gaps written as detection rules you can deploy.

retest record

Reissued after we have tested your fixes. Findings only move to resolved when we have failed to exploit them a second time.

A dense city skyline at night, lit windows in red and amber

book a scoping call

Bring the person who owns the system. Twenty minutes is usually enough to agree what a useful engagement would look like.

Start scoping a test