Skip to main content
  • Enterprise IT & cloud

Security Team Incubation

Building a security function from nothing: a new venture, a carve-out, or a restructure.

Why we build a team this way

Hiring a security lead and letting them build the team works once there is a team. Before that, someone has to size and budget the roles, judge candidates for jobs nobody in the company has done, and run the security work in the meantime. We do that part, then hand it over and leave.

One bar per workstream, running left to right in months. Solid is the part we still run. Hatched is the part your team has taken.

Handover, one workstream at a time
  • Setup and tooling
  • Architecture
  • Process and policy
  • Day-to-day operations
  • Hiring and training

Solid: we run itHatched: your team runs it

Illustrative. The streams do not transfer on one date.

The work is sizing and budgeting the roles, steering the hiring, and running the security workstreams (setup, architecture, process) until the people you have hired can take them. Handover then happens one workstream at a time, deliberately, so responsibility transfers rather than drops. The interim lead is one of our own consultants, with the forensics team and the red team behind them, so a new venture gets senior judgement before it can hire for it.

We helped build the security team at Jio in India, a company bringing mobile internet to nearly half a billion people, and we have built teams and security awareness for a client in Japan.

Where engagements usually start

Team ramp-up

We work out what roles you need, what they cost, and we help you hire them.

  • Team shape and headcount sized against what you are actually building
  • Budget for it, before you commit to it
  • Role definitions, and screening we run with you
  • In the interviews, assessing candidates for roles you have not held yourself

Interim operations

Our people run the security work until yours are in place and up to speed.

  • Security architecture for what you are building now
  • The processes that have to exist before go-live
  • Day-to-day security decisions, made rather than queued
  • Everything documented as it is built

Training and handover

We train your team on the job and then transfer each workstream to them and step out.

  • Training on the systems they are inheriting, in place
  • Dedicated sessions where the subject needs them
  • Workstreams handed over one at a time, not all at once
  • A defined end date, agreed at the start

How we work

We start with what you are building and what would hurt if it went wrong, then work backwards to the team that prevents it. While we are operating we make decisions instead of escalating them, because a new venture cannot wait on a committee. And we plan the handover from the first week: every workstream we run has a named successor and a date, and we would rather leave early than become the reason your team never fully owns it.

Send us the problem

Tell us what you are building and what you need looked at. You will get an answer from the people who would run the engagement, and if another firm is the better fit for what you are asking, we will name one.

Get in touch

Security Research Labs is a member of the Allurity family. Learn more(opens in a new tab)