Engagement process

Every engagement is scoped individually, but the shape is consistent. It exists to keep scope honest and progress visible.

Phases

1. 01

   Discovery

   A short conversation and, where useful, a review of existing systems. The objective is to understand the problem, the constraints and the decision that needs making.

2. 02

   Written scope

   A document covering deliverables, exclusions, assumptions, access requirements, timing and the criteria for completion. This is the reference for the rest of the work.

3. 03

   Delivery

   Work proceeds in reviewable increments. For builds, that means working software and a running environment early. For assessments, it means interim findings before the final report.

4. 04

   Review

   Each increment is reviewed against the agreed criteria. Findings or defects are handled before the next increment, not accumulated at the end.

5. 05

   Handover

   Documentation, a walkthrough session and an agreed support period so your team can own the result.

Change control

Scope changes are normal. They are handled explicitly:

1. The change is described in writing — what is added, removed or adjusted.
2. The effect on timing and cost is stated.
3. Work continues on the agreed scope until the change is accepted.

Nothing is quietly absorbed into the schedule. If an addition would compromise the delivery date, we will say so before it happens.

What completion means

An engagement is complete when the agreed deliverables exist, have been reviewed against the scope, and have been handed over with documentation. For security assessments, that includes the findings register and the remediation walkthrough. For builds, it includes the repository, environment configuration and handover notes.

Timing

Timelines are agreed per engagement after scoping. Estimates are based on the defined scope; where a delivery date depends on a third party (a vendor, an approval, an infrastructure provider), that dependency is stated in the scope document rather than assumed.

Documentation as part of delivery

Written output is produced during the work, not reconstructed at the end. Architecture decisions, assessment findings and operating procedures are recorded as they are made, which is also why the handover is a conversation about documents that already exist.