How it works
What an engagement looks like from the first call to handover, and what happens to your systems and your data along the way.
The engagement
- 1
Scope
Book a scoping call. ZuluSec confirms your environment and what is driving the work. The audit and the compliance gap assessment are scoped and priced on that call. Design and build work is quoted after a short discovery phase, or from the results of an assessment already in hand.
- 2
Agree
You sign the engagement agreement and access authorization. Work starts once that is in place.
- 3
Work
Work happens only with the access you authorized. Assessments are read-only, hardening changes only what is in scope, and build work arrives as pull requests with tests.
- 4
Hand over
You receive the deliverable for your engagement: a prioritized report saying what to fix first, hardened systems with the evidence behind them, or working code and its pipeline.
Platform and automation engagements can continue past handover. If you have nobody to hand the work to, ZuluSec keeps running it for a monthly fee, cancellable with notice, with everything still in your repository.
How access is handled
You are giving a stranger access to your systems. ZuluSec treats that seriously.
Under NDA
A mutual NDA is signed before ZuluSec sees anything in your environment.
Written authorization
ZuluSec accesses only what you authorize in writing, for the window you set, and nothing else.
Least privilege
The minimum access the work needs, no more. Assessments are read-only: no agents installed, no changes to your systems.
What happens to your data
Findings stay confidential and credentials are destroyed when the engagement ends. What ZuluSec keeps after that is set out in the data handling terms you sign.
How the work is built
ZuluSec writes purpose-built tooling because a general-purpose product cannot answer the specific questions your environment raises. A practitioner decides what to check, what the results mean, and what goes in your report. AI is used in one specific place: writing the tooling that collects the evidence.
That tooling is specified by an engineer, written with AI assistance, reviewed against what it was meant to do, and shipped with its tests and an automated test run (CI). What runs against your environment is deterministic: the same input produces the same findings, and a run that could not read something reports that gap instead of coming back clean. That is why a finding can be reproduced rather than taken on trust. The code is yours to keep, and there is a public reference implementation you can read before hiring anyone.
By default no AI model sees your data. The tooling reads your environment, and its output goes to the practitioner who judges it and writes your report. Nothing from your environment goes to a model: not what the tooling reads, not its output, not your logs or configuration, and never a credential. That boundary is yours to set, and whichever setting applies is written into the data handling terms you sign. The restrictive setting is the default and is what regulated environments get unless you ask for something else.