Report an Incident Become a Partner Careers Contact
Book a Demo
Consultancy · professional services

We build it.
Then we run it.

Deployment, migration and integration across the Microsoft security stack, delivered by the engineers who operate this kind of environment every day rather than by a delivery team that hands over and disappears.

Engagement · SIEM migrationweek 6
MODELIngestion tiers costed before anything onagreed
CONNConnectors chosen against the threat profilebuilt
GAPTwo log sources nobody knew were darkfound
RULESDetections backtested against real datapassed
DOCSStructure another engineer can pick upwritten
RUNOperated by the team that built itlive
Why the build matters more than the design

The deployment decides
what it costs to run.

A security platform is not expensive because of its licence. It is expensive because of choices made in the fortnight it was deployed, by people who were not going to be the ones living with them.

Three examples, all of them common. What you ingest and at what tier sets your Sentinel bill for the next three years, and nobody revisits it. Which connectors go in decides what you are capable of detecting, and a gap there is invisible until an incident walks through it. Whether anything is named and structured consistently decides whether the next engineer can maintain it or quietly rebuilds it.

None of those are visible at handover. All of them are obvious within six months to whoever is operating the thing. We deploy what we then run, which is a constraint on us rather than a sales line: it rules out the configuration that demos well and costs a fortune, and it means the person choosing the ingestion tier has been on the receiving end of that choice before.

  • Ingestion and retention modelled against cost before anything is turned on.
  • Connector coverage chosen against your threat profile, not against a default list.
  • Detection content that is tuned and backtested rather than switched on wholesale.
  • Naming, structure and documentation an engineer who is not us can pick up.
  • A handover that includes what we would change next, and what we would not.
What we deliver

Mostly Microsoft,
and mostly hands-on.

Engagements with a defined scope and an end. Some are a fortnight, some are a quarter, and we will tell you which before you commit to either.

Microsoft Sentinel deployment

Workspace design, data connectors, ingestion and retention modelled against cost, analytical rules and the automation around them. Built to be operated, not to pass a demo.

SIEM migration

Off a legacy platform onto Sentinel, including the detection content nobody wants to rewrite by hand and the parallel-running period where both are live.

Defender rollout

Defender for Endpoint, Office 365, Identity and Cloud Apps deployed and tuned across the estate, with the policy decisions made deliberately rather than left at default.

Identity and Entra

Conditional Access, privileged access, identity protection and the risk policies underneath. The area where a small misconfiguration does the most damage.

Purview and data security

Data discovery, classification, DLP, insider risk and retention configured against the data you actually hold rather than a generic taxonomy. The single most requested piece of work on this list at the moment, largely because AI tooling has made people look properly at where their data sits.

Defender for Cloud and AI workloads

Cloud posture and workload protection across Azure, AWS and GCP, including protection for the AI services and models now running in those tenancies. Most estates have AI workloads switched on before anybody has decided how they should be secured.

AI agent governance

Bringing AI agents under the same identity, permission and audit discipline as everything else — what an agent can see, what it can act on, and what is recorded when it does. A new problem, and one arriving in most tenancies faster than the governance for it.

Data engineering

Custom connectors, parsers, analytical rules, playbooks and notebooks for the systems no vendor has built an integration for. Read the note below if you are buying the managed service.

Health checks and optimisation

An existing deployment assessed for coverage gaps, noisy rules, cost leaks and silent controls. Usually the cheapest engagement on this list and often the most useful.

Post-incident rebuild

After an incident, putting the estate back together properly and building the detections that would have caught it. Frequently the point at which somebody decides they want it monitored.

If what you need is not on this list, ask. Most of what we do that is unusual started as somebody asking whether we could.

Before you pay us for any of this

If you are buying the managed service,
a lot of this is already included.

Worth saying before the conversation rather than after the invoice, because it is the sort of thing that only ever surfaces at the wrong moment.

What the managed service covers

Custom data connectors, parsers, analytical rules, playbooks and notebooks built for your estate are part of our managed service and happen during onboarding. They are not a change request and not a professional-services line. Where something you run has no connector, writing it is covered too. Building a tool or a program specific to your organisation is a different job and is quoted as development.

So professional services here is for the work that genuinely sits outside that: organisations who are not buying the managed service, engagements with a defined scope of their own, and one-off pieces like a migration, a rollout or a health check. If you ask us to quote something that is already in your contract, we will tell you.

A customer who finds out later that they paid twice does not buy a third time.

How you buy it

By the project,
or by the retainer.

Most people start with a project because it has a scope and an end. The retainer exists because the second and third pieces of work are usually smaller than the procurement process needed to buy them.

A project is the straightforward version: a defined scope, a defined outcome and a date. A migration, a rollout, a health check, a rebuild after an incident. You know what you are getting before it starts and it finishes.

A retainer is an agreed amount of our time each month, drawn against whatever you need that month. It is deliberately not limited to one discipline — deployment, configuration, an assessment, a penetration test, or an engineer alongside your team for a fortnight all come out of the same arrangement. What it is really buying is the ability to start something in a week rather than a quarter.

Per project
A written scope, an outcome and an end date. Best where the work is known and self-contained, and the version most people buy first.
Retainer
Time each month against any work in the group. Deployment, configuration, assessment, penetration testing — you decide what it is spent on as the year goes.
No discipline boundary
The retainer is not ring-fenced to Microsoft work. If what you need this month is a penetration test, that is what it buys.
Nothing quoted without a scope
Under either model. A number with no scope behind it is guesswork on both sides, and it is the reason so much security work lands over budget.

If you are already buying the managed service, read the section above first — a good deal of this work is in your contract and we would rather tell you that now.

How an engagement runs

Scoped, built,
handed over properly.

Short enough to be predictable, and structured so nothing important is discovered in the last week.

  1. 01

    Scope

    What is being built, what is out, what has to be true before we start, and what done looks like. Written down, because half the problems in delivery work are scope problems wearing a technical disguise.

  2. 02

    Design

    The decisions that set cost and capability: ingestion, connectors, policy, structure. Made in the open with your team rather than presented as a finished diagram.

  3. 03

    Build

    The actual work, in your tenant, with agreed change windows. Progress visible as it happens rather than reported at a weekly call.

  4. 04

    Prove

    Detections backtested against real data, policies tested against real users, and coverage measured rather than asserted.

  5. 05

    Hand over

    Documentation somebody else can use, a walkthrough with the engineer who built it, and an honest list of what we would do next and what is not worth doing.

Questions

Professional services, answered.

What is the difference between this and your consultancy?

Consultancy decides what to do; professional services does it. Most engagements are some of both and are scoped together. If you want an architecture designed and someone else to build it, that is fine and fairly common.

Do we have to buy your managed service?

No. Plenty of this work is for organisations who run their own security operation or use another provider. What you get either way is a build from people who operate this kind of environment daily, which tends to produce fewer things that look elegant and run badly.

We are already a managed service customer. Do we pay for this?

Often not. Custom connectors, parsers, rules, playbooks and notebooks for your estate are included in the managed service and happen at onboarding. Professional services covers work outside that scope. If you ask us to quote something already in your contract, we will say so.

Can Microsoft pay for it?

Sometimes. Microsoft funds a structured security engagement for eligible organisations, and a good number of projects can start there rather than with an invoice from us. We check eligibility before anybody fills in a form.

How is it priced?

Per project against a written scope, or a monthly retainer you draw against. We will tell you which fits before you ask. Nothing is quoted before the scope exists, because a number without a scope behind it is guesswork on both sides.

What can a retainer be spent on?

Any work in the group. A deployment one month, a configuration piece the next, an assessment or a penetration test after that. It is not ring-fenced to Microsoft work, and it exists so the small jobs do not need their own procurement cycle.

Can you work alongside our incumbent?

Usually, and it is common on migrations where somebody else runs part of the estate. The boundary between who does what is agreed in writing at the start, which is the part that prevents the awkward conversation in week six.

What happens at handover?

Documentation your team can actually use, a walkthrough with the engineer who did the work rather than an account manager, and a written view of what we would change next and what is not worth the money.

Where to start

Tell us what needs building
and we will scope it honestly.

Including whether Microsoft will fund it, and whether it is already covered by a managed service contract you hold. Nothing is quoted before the scope is written down.