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. Not to hand out a grade — to know 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 say plainly where our role ends.
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 what needs our help. Sometimes it turns out you don't need us at all.
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…
Zobacz obszar →A scanner finds a thousand things. We set up a process that says which twenty need attention…
Zobacz obszar →Security built into the way your team writes and ships software — not bolted…
Zobacz obszar →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. We don't pull the team off work for weeks. That an assessment must not paralyze the company is a condition for us, not a declaration.
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 — we don't leave you with a list of problems and no idea what to do with them.
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.
No. The report is yours and you can act on it yourselves or with anyone else. If you have the skills and the time — that will be cheaper, and that is what we will advise.