Continuous Security Retainer
Security review that keeps pace with the way you ship: new features, fixes, and infrastructure changes reviewed as they land, rather than once a year.
The problem a retainer solves
A point-in-time assessment describes the product as it was during a specific week. If you ship continuously, that description begins ageing immediately: a new endpoint, a new role, a changed cloud permission, or a new integration can each introduce exposure that no previous test could have covered.
A retainer replaces the annual cycle with something closer to how you actually work. Instead of one large review long after the decisions were made, security review happens near the change, while the reasoning is still fresh and a fix is still cheap.
How it works in practice
You tell us what has changed, we review it, and you get findings in a form your team can act on. Over time the reviews compound: we accumulate a working understanding of your architecture, your permission model, and your history of decisions, which makes each subsequent review faster and sharper than a cold engagement could be.
Because the relationship is ongoing, a retainer also gives you somewhere to put the questions that fall between assessments — whether a proposed design is sound, whether an advisory actually affects you, whether a customer\u2019s security requirement is reasonable.
The same guardrails apply as in any engagement. Work is authorized in writing, scoped, and documented; findings are evidenced rather than asserted.
What a retainer covers
The balance between these activities is set when the retainer is scoped, and reviewed as your product and team change.
- New feature review
- Features are reviewed as they reach a testable state, focusing on the surfaces that change: new endpoints, new permissions, new data flows, and anything touching authentication or tenancy.
- Fix verification
- Remediation is verified rather than assumed. When a fix is partial, or resolves the reported path while leaving an equivalent one open, we say so and reopen the item.
- Infrastructure and cloud change review
- Changes to identity and permissions, network exposure, storage configuration, and secret handling are reviewed as they happen, when the reasoning behind them is still fresh.
- Dependency and supply-chain review
- Attention to the dependencies and third-party services your product relies on, focusing on what is genuinely reachable in your deployment rather than on the length of an advisory list.
- Architecture and design input
- A security opinion while a design is still cheap to change. This is often the highest-value part of a retainer, because it prevents findings instead of documenting them.
- Running finding record
- A single, current record of what has been found, what has been fixed, what has been accepted as a risk, and what remains open — so the position is always known.
A retainer suits you if
- You ship weekly or faster, and an annual assessment is out of date within a month of delivery.
- You have no in-house security specialist and need a consistent second opinion rather than an occasional audit.
- Enterprise customers now ask what happens between assessments, not just when the last one was.
- You are moving from one large annual test towards continuous assurance.
A retainer is the wrong tool if
We would rather point you elsewhere than sell you the wrong engagement.
- You need a single point-in-time report for a specific deal or deadline. A one-off SaaS Security Assessment is the right instrument for that.
- You need incident response or forensic investigation of an active compromise. That is specialist work with different obligations, and we will tell you so rather than take it on.
- You need a monitoring, alerting, or managed detection service. A retainer is human review, not a monitored SOC.
Common questions
How is a retainer different from repeating an assessment?
An assessment answers what the security position of the product was on a particular set of dates. A retainer keeps answering that question as the product changes, which is a different rhythm: smaller reviews, closer to the change, with the context of everything reviewed before.
The practical difference is that findings arrive while the code is still fresh in your engineers’ minds, and design problems can be raised before they are expensive to fix.
What are the commercial terms?
The minimum term, the volume of work included, review cadence, and response expectations are agreed in the proposal and stated in the contract. We do not publish a standard package, because a retainer that fits a four-engineer team shipping weekly does not fit a thirty-engineer team shipping continuously.
We would rather agree a realistic commitment we can honour than advertise a service level and then qualify it in the small print.
Do you work inside our development process?
As far as is useful and no further. In practice that usually means a shared channel for questions, visibility of the changes you want reviewed, and an agreed way to raise findings that fits how your team already tracks work.
We do not need administrative access to your systems, and we will not ask for more access than the review requires.
Does a retainer include a formal report for customers?
Formal reporting can be included where you need it — for example, a periodic summary suitable for a customer’s security review. This is agreed when the retainer is scoped, because producing customer-facing documentation is a distinct piece of work from ongoing review.
Discuss an ongoing arrangement
Tell us how often you ship, what your stack looks like, and where you feel least covered. We will propose a retainer shape and terms in writing.