Services

We design the process.
Your engineers run it.

Four ways to work together, all at fixed scope and fixed price. We bring the knowledge your team would otherwise spend months assembling, and we step back once it holds.

Ongoing

Advisory retainer

The smallest decision in the range, and for most organisations the right one.

One day a month, and you set the agenda. The retainer does not assume a project has been done first, and it makes sense even when nothing has been built yet.

A typical session works through the last few weeks of numbers and asks why they moved. We clear exceptions that have aged past their deadline, bring new business units or acquisitions into scope, and look at planned changes to your tooling before they happen rather than afterwards. Between sessions we are reachable when one of your engineers wants a second opinion before committing to an approach.

The effort is capped in the contract and notice is three months on both sides. Both are deliberate. An uncapped retainer becomes an on-call arrangement over time, and that is a different business, one we do not run.

We come to you once a quarter and work remotely the rest of the time.

One week

Current-state assessment

A week to establish where you actually stand. The assessment stands on its own. It gives you a defensible picture of the current state, and if you do nothing further with us afterwards you still have something worth having.

Talk to the people who know

Your security engineers, whoever owns the asset register, the people who actually apply fixes, and the people who have to explain it when something is missed. The gap between those four accounts is usually informative on its own.

Test the coverage claim

We compare the scan configuration against the asset register, and both against reality. That difference is normally the finding that makes the rest of the conversation worth having.

Follow a finding end to end

We trace how a vulnerability travels today from detection to closure, and record where the chain breaks. It is rarely the technology. It is usually an ownership question nobody settled.

You get a written current-state report, a gap register, and a prioritised roadmap with effort estimates. Plus a working session with your technical people and, if you want one, a shorter version for management. Five to eight working days. If you commission a restart or a build within three months, half the fee is credited against it and the programme scope is reduced by the work already done.

Three to four months

Programme restart

When the platform is in place and nothing happens anyway.

This situation is far more common than anyone admits publicly. A platform was bought two years ago, the rollout stopped halfway, and the licence has renewed every year since while nobody works the findings.

We start with the diagnosis. What was configured, what was assumed, why coverage falls short of what was expected, and which of the original decisions have to be reversed rather than extended. This is the actual work, and it is harder than starting clean, because it means reconstructing someone else’s reasoning before changing anything.

From there the path is the same as a build, picking up at process design. In most cases the existing platform stays, because it can do considerably more than was ever configured. If it genuinely was the wrong choice, we will tell you that too.

A restart takes less time than a build. It is not proportionally cheaper, and there is a reason for that: the diagnosis is the difficult part, not the implementation.

Six to nine months

Programme build

From nothing to a process your own team runs.

When no programme exists, the real obstacle is rarely technical. It is not knowing what good looks like, how long the build takes, or what you will actually need at the end. That uncertainty is why these projects stall before they start.

We begin with requirements rather than products. Only once it is clear what the solution has to do do we evaluate candidates against it, and the alternatives we considered go into the recommendation in writing, with the reasoning.

Then the process itself: scanning strategy and cadence, how credentials are handled during scanning, how assets are scoped and owned, triage logic, and remediation deadlines your teams can meet with the capacity they actually have. Plus exception handling and risk acceptance, because that is the part whose absence quietly kills a programme eighteen months in.

After that we define the measures and take a baseline, so improvement can be demonstrated later rather than asserted. We review your engineers’ work at agreed checkpoints without taking it over. At the end you hold documentation you own and can put in front of an auditor.

A build runs over several months depending on the size of your IT department, at low weekly intensity rather than as a block. Invoiced monthly against a fixed total agreed at the start.

A build as a project is not the only route when you are starting from nothing. Many organisations get there more cheaply and more durably by beginning with an assessment and then building the process themselves over twelve to eighteen months under the retainer. The build is the right choice when you need a defined start and a defined end, because the work is budgeted internally as a project or because your procurement requires that shape.

Capability

What we can do, and what we will not claim.

Your engineers will work out inside twenty minutes whether someone knows this material. So we state the boundary first.

Programme design

Vulnerability management from first principles, including the organisational questions. Who owns remediation, what capacity exists to actually fix things, and how exceptions are handled. That is what determines whether a programme survives, not the choice of tool.

Coverage analysis

Credential scope during scanning, asset scoping and deduplication, and the gap between what was scanned and what is there. This is the detail that decides whether your coverage figure means anything.

Tooling evaluation

Vendor-neutral assessment of the major commercial platforms against your stated requirements. We sell none of them and hold no certification that would create a preference.

Measurement

Metrics that describe the programme rather than flatter it, with a clean baseline. We also tell you what each number hides, because most of them hide something.

Not: operating your tooling

We do not work in your consoles. We design and review; your engineers execute. That keeps engagements finite and leaves the knowledge with you.

Not: industrial environments

We work in IT environments today. Industrial control networks are a capability we are deliberately building and will not offer until it genuinely exists. Until then we refer that work on.

Boundaries

What we do not offer.

This list appears in every engagement scope, together with the referral. In Swiss procurement a clear boundary reads as competence rather than as a limitation.

No SOC, no round-the-clock monitoring, no managed detection
No penetration testing and no red-team work
No incident response, though we do take on the work afterwards
No certification and no attestation, but the evidence your auditor uses
No software or hardware resale, in any form
No engagement below the assessment, because the overhead stops being worth it for either side

Let's talk first.

One to two hours with your technical people, technical and with no sales portion. Afterwards both sides know whether working together makes sense.

Arrange a conversation

We design the process.Your engineers run it.