Managed Security

On-Demand Risk Reduction

A retained block of engineering time you draw down as security work comes up: a launch, a customer questionnaire, a fix to verify, a design that needs a second opinion.

Security work rarely arrives in project-sized pieces. A feature is about to ship and nobody has looked at its authorisation model. An enterprise prospect sends a questionnaire with a deadline. A fix from the last penetration test lands and someone needs to confirm it holds. Each is too small for its own statement of work, and too important to wait for one.

We agree the size of the block, the types of work it covers and its dates once, when we scope the work. After that you send requests to a shared channel and we pick them up without a new contract. The engineers working your requests learn your architecture once and keep that context, so each request starts from what we already know, not from a kickoff.

Usually, one of these is true

An enterprise deal is waiting on a security questionnaire and a call with the customer's security team, and nobody in-house can defend the answers.
A feature touching payments, authentication or tenant isolation is about to ship without a security review.
Fixes from your last penetration test have landed and you need each one verified before the customer asks.
You have no security hire yet and keep needing an opinion on a design, a vendor, or an alert that may or may not be an incident.

What the block covers

The types of request the block can be spent on are agreed at the start. Anything that grows beyond a request, such as a full application test, is flagged and scoped separately before any time is spent on it.

Pre-launch review. A single feature, endpoint or release checked before it ships: authorisation, input handling, secrets, and the abuse cases specific to what it does.
Fix verification. Remediated findings from our reports or another firm's, retested against the original reproduction and against the obvious variants that a narrow fix leaves open.
Questionnaires and customer calls. Security questionnaires such as SIG and CAIQ answered from how your systems actually work, and an engineer on the call when a customer's security team wants to test the answers.
Design and threat modelling. A threat model of a proposed design, integration or new data flow, written while changing the design is still cheap.
Vendor and dependency review. A look at a SaaS vendor, SDK or open-source dependency before you adopt it: the access it asks for, the data it sees, and what happens if it is compromised.
Second opinions. An odd log entry, a researcher's email or a suspicious login, looked at by an engineer who can tell you whether it is an incident and what to do next.

How the retainer runs

Scoping sets the block and the rules for spending it. After that, work runs request by request, with a record of the time each one draws.

Scope the block. When we scope the work we agree the size of the block, the dates it runs between, the request types it covers and a fixed price, all in writing.
Learn the system. We walk through your architecture, repositories, cloud accounts and past reports once, so later requests start with context instead of a kickoff.
Request and estimate. You raise a request in the shared channel. We confirm what it covers, when it will be done and how much of the block it should use before starting.
Do the work. The engineer does the review, retest or write-up and reports in the channel. Security findings carry a reproduction, CWE and CVSS v4.0, and criticals arrive within the hour of confirmation.
Account and review. Every request is logged against the block with what was done and what it found. At each review we look at where the time went and whether a full engagement would serve you better.

What you get

Request log. A running record of each request, the time drawn from the block and the outcome, for whoever signs off the spend.
Review notes. A short written result for each pre-launch or design review: what was checked, what was found, and what was deliberately left out.
Verified findings. Each security issue with a working reproduction, a CWE mapping and a CVSS v4.0 rating, held to the same standard as a full engagement.
Retest records. Confirmation that each remediated finding is closed, with the evidence, ready to hand to a customer or an auditor.
Questionnaire answer set. Completed questionnaires plus a reusable set of answers drawn from how your systems actually work, for your sales and security teams to use on the next one.

What we need from you

A shared channel, such as Slack, Teams or email, and one person on your side who raises and prioritises requests.
Read access to the repositories, architecture documents and cloud accounts the likely requests will touch.
Staging access and test accounts for anything we review before launch.
Past penetration test reports and open findings, from us or anyone else, so fix verification starts from the original evidence.
For questionnaires, your existing policies and previous answers, and a contact who can confirm anything we cannot see for ourselves.

What we can show you

Context that carries over. Requests go straight to engineers who already know your system, with no account-manager layer in between. A small request does not pay for a fresh onboarding.
The same evidence standard. A pre-launch review drawn from the block is held to the same bar as a full test: a working reproduction, a CWE and a CVSS v4.0 rating for every finding.
Answers you can defend. The engineer who drafts your questionnaire answers can join the customer's security call and explain them, because they have seen the systems the answers describe.
A fix without a hand-over. One team runs testing, hardening and engineering. If a request turns up something that needs building or reconfiguring, the people who found it can do it.

Standards we work to

Reviews are rated on the same public scales as a full engagement, and questionnaire work uses the standard formats enterprise buyers send.

CVSS v4.0
CWE
OWASP ASVS
OWASP Top 10
CSA CAIQ
Shared Assessments SIG

Common questions

What happens to time we do not use?

That is agreed in writing when we scope the work, along with the dates the block runs between. We would rather size the block to what you are likely to need than sell time that goes unused, and each review checks whether the size still fits.

How quickly can you pick up a request?

It depends on the request and what else is in flight, so we confirm a start and a finish for each one when you raise it rather than promising a blanket response time. Anything critical we find while working on it reaches you within the hour of being confirmed.

Can you verify fixes for findings another firm reported?

Yes. Send the original report and reproduction. We retest the finding as written and check the obvious variants, since a fix that blocks one payload often leaves the underlying flaw in place. If we cannot reproduce the original issue, we say so rather than mark it closed.

When does a request become a full engagement?

When it would take more of the block than it is worth, or when it needs its own rules of engagement, such as a full application test or anything run against production. We flag it before spending time, and scope it separately with its own fixed price and dates.

Will you fill in our security questionnaire for us?

We draft answers from what we can verify in your systems and policies, and mark anything we cannot confirm for your team to answer. We will not write that a control exists when it does not. Where a gap could cost the deal, we tell you what closing it would take.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.