We set the scope before we start. Sometimes one area is enough to answer your question.
We measure the level of your process against OWASP SAMM and NIST SSDF — so it is clear what specifically moves you up a level.
We review the architecture from a security angle: trust boundaries, data flows, authentication, authorization, component isolation.
We check what actually happens in the build and release process: configuration, secrets, permissions, dependencies, supply chain.
We map the technical requirements arising from regulations onto your actual state. We show the gap and point out what we close technically and what calls for organisational or legal decisions.
Assessing one product is different work than fifteen microservices in three teams. We choose the scope after a conversation — from a single system to a complex multi-team environment.
One system, one team. An answer to the question: where we stand and where to start.
Process, architecture, technical security and the regulatory gap in one.
A repeatable maturity assessment for companies that want to track progress over time.
A list ranked by what each risk can actually cost you and what removing it costs. Without that, prioritization is guesswork — and most reports end exactly there.
What to do first, what next, what can wait. Split into what you can do yourselves and where an implementation with us speeds up the result.
A report no one read is useless. We go through the findings with your team and your management — separately, because they have different questions and a different language.
A regulatory requirement translated into a concrete setting in your system — and into evidence that shows…
See the area →A scanner finds a thousand things. We set up a process that says which twenty need attention…
See the area →Security built into the way your team writes and ships software — not bolted…
See the area →A pentest is a snapshot from a specific day — it says what was vulnerable at the moment of the test. An assessment asks why that vulnerability arose at all and whether another one like it won't arise tomorrow. They are two different things and do not replace each other.
For the process and architecture assessment, documentation and a conversation with the team are usually enough. For the technical review we need access to the build pipeline configuration and organization settings. We agree the scope in writing before we start and apply the principle of least privilege to ourselves too.
Realistically from a few to a dozen or so hours in total — mostly interviews and follow-up questions. Your team keeps working as usual while the assessment runs alongside.
That is good news, even though it doesn't sound like it. Better to hear it from us than from a client's auditor or from an incident. The report always ends with a plan: the order of actions and what delivers the biggest effect fastest.
From a few business days for a focused assessment to two–four weeks for a full one. We set the boundary before we start, so nothing drags on endlessly.
The report is yours and you can act on it yourselves. If you implement with us, we start straight from the assessment plan and factor its cost into the implementation quote.