How an engagement runs

Four stages, with one thread running through them, from the first call to the retest.

1234
1

Agree on the target

You describe your environment, who uses it and what would hurt most if it failed. We come back with a scope, a timeline and a price. If a smaller test would answer your question, we say so.

2

Find the way in

Manual work inside agreed windows, with a named contact on your side and an agreed way to pause the test at any moment. A critical finding is reported as soon as it is confirmed, with a workaround if there is one, rather than held for the report.

3

Write it down

One document, two readers. The first page is for the people who decide: what was found, what it means, what to do first. The rest is for the people who fix: the path in, the proof, the remediation. We present it to both.

4

Check the fix

Once the fixes are in, we go back over every finding and update the report with what held and what did not. The retest is part of the engagement.

Keeping up with the attackers

The ground moves fast. AI has pushed up both the number of vulnerabilities being found and the speed at which they are exploited, and testing has to keep the same pace. These are the numbers from the industry’s own reports that we plan engagements around.

We keep up with the attackers so that your test reflects the attackers of today, not of five years ago.

What we map to

Attackers do not follow a checklist, but the people who fix things need one. Findings map to the references your engineers and auditors already know. The set below is the usual starting point; the engagement decides which apply.

Questions from the first call

Answered here so the call can go further.

Why Gectiv?
Two reasons, both of which you can verify before committing to anything. First, we advise against engagements you do not need: if a narrower test, or no test at all, would answer your question, we say so during scoping, and the scoping notes are yours to keep either way. Second, the standard applied to every engagement was formed in environments with mature, well-resourced defence teams, where only careful and thorough work produces results. That standard does not change with the size of your organisation.
Penetration test or red team?
If you want to know what is wrong with a system, a penetration test. If you want to know whether your organisation would notice and stop an attacker, a red team. Most first engagements should be a penetration test; a red team is most useful once the obvious has been fixed.
What drives the cost?
Scope and depth: the number of applications, roles and environments; whether testing is authenticated; whether the cloud environment and the people are included. A clear scope gives you a price up front rather than an open-ended day rate.
Will testing disrupt the business?
Testing is coordinated with you: time windows, systems to leave alone, and a way to pause at any moment. Destructive actions are never taken without explicit agreement. Red teams are designed to be quiet; that is the point of them.
What do we need to prepare?
For a penetration test: test accounts, a decision on staging versus production, and a contact who can answer questions quickly. For a red team: a small trusted group who know, and everyone else who does not.
Can the engagement be run remotely, and in which languages?
Engagements are run remotely by default, in English or French. On-site work, where it is needed, is agreed during scoping.