Application assessment Fixes and new check Also on software from other suppliers

Secure the software you already use.

Is a customer asking you for proof that your software is secure? Is a due diligence questionnaire holding up a deal? We analyse the application, fix the problems and demonstrate it with a new check. Everything documented, residual risks included.

Request an assessment See an example

ISO 27001 management system in the certification process

When you need it

They usually call us at one of these moments.

An important customer asks for evidence of your software's security before signing.
A security questionnaire or a due diligence raises questions your team can't answer.
The software was written by a supplier who no longer exists, or doesn't respond.
A prototype ended up in production without anyone checking it.
You need to understand what the Cyber Resilience Act, NIS2 or your customers require of your product.
Dependencies haven't been updated for months, or years.

The path

Find, fix, demonstrate.

Scope and assessment

We agree in writing what we analyse, with what access and in which environments. Then we check access and authorisations, data handling, dependencies, configurations and interfaces.

Written scope

Fixes

Reproducible problems, ordered by priority. The fixes are implemented by us, your team or your current supplier: you decide. For each fix, a test that stops the problem coming back.

Regression tests

New check and management

We repeat the checks and document what is resolved and what remains. Then, if you want, we follow the software over time: dependency updates and vulnerability management.

Residual risks documented

Demonstration example

What a finding looks like, from start to finish.

An example built for illustration, not referring to any customer. It shows the level of detail you will find in the final document.

Stage	What it contains
Finding	A user with the "operator" role can download other customers' invoices by changing the number in the page address.
Impact and priority	Exposure of third-party data. High priority.
Fix	Server-side authorisation check on every document request, tied to the user and the customer.
Regression test	Automated test that attempts cross-access and must fail.
New check	Request repeated with a different user: access denied. Finding closed.
Residual risk	Documents already downloaded in the past: assessment left to the customer, with an extract of the available logs.

Requirements

The acronyms, explained for what they are useful for.

Topic	What we do	What we don't do
Application security	Checks on access, data, dependencies, configurations and interfaces; fixes and a new check.	We don't declare software "100% secure": we document what we have verified.
Cyber Resilience Act	Analysis of the technical requirements for products with digital elements that fall within the regulation.	We don't replace your organisation's regulatory assessment.
NIS2	Technical contribution to secure development, maintenance and supply chain.	We don't "certify software as NIS2": no such certification exists.
AI Act	Assessment of the requirements according to the system and its use.	Using AI to write code does not by itself determine how the software is classified.

Why trust us

Used to working where standards are strict.

With Centro Ortopedico di Quadrante, the Italian hospital of the Ramsay Santé group, we are developing medical device software: requirements, risks and checks have to be documented one by one. That is why we are implementing a quality system under ISO 13485 and IEC 62304 and an information security management system under ISO 27001, both in the certification process.

We bring the same discipline to your software: written scope, reproducible evidence, no promises we can't demonstrate.

Do you need to show that your software is secure?

Tell us which application it is and who is asking. The first call is free. Access and code are shared later, under a confidentiality agreement and written authorisation.

Request an assessment

Frequently asked questions

Before we start, people usually ask us:

Is it a penetration test?

No, and we prefer to say so up front. Our assessment combines review of code and configurations, dependency analysis and targeted tests on the application, within the agreed scope. A penetration test is an activity with its own method and specific authorisations: if you need one, we say so and help you prepare it.

Do you issue a security certification?

No. We deliver checks, fixes and documentation you can show to customers and auditors. Our acceptance testing is not an external certification; if you need an independent check, we help you prepare for it.

Can you work on software written by another supplier?

Yes, if the contract with the supplier allows it and we have access to the source code. Without source code the analysis is more limited, and we state that in the scope. We don't promise fixes on software that cannot be modified.

Does our software fall under the Cyber Resilience Act or NIS2?

It depends on the product, how you distribute it and your organisation's role. We help you understand which technical requirements apply and what is needed to meet them; the final regulatory assessment remains with your organisation and its advisers.

What happens after the assessment?

You can have us implement the fixes, or do them with your own team or your current supplier. Either way, a new check confirms what has been resolved. Then we can follow the software over time: dependency updates and vulnerability management.

Is the software still a prototype?

See from prototype to production: security is part of the path.