The problem

With cyber-attacks rising, customers are required to provide sufficient due care evidence in cyber security. It is both a legal requirement in number of regulated industries (government, financial, utilities etc.) and common sense.

Often, security requirements are included into software development contracts (due diligence). But just like builder should not be trusted to attest safety of public building, software must be tested by independent agency to check if cyber security requirements are indeed implemented (due care).

On top of it, industry uses multitude of terms to denote often overlapping cyber security testing services – vulnerability assessments, penetration testing, red-teaming, purple-teaming etc. Often, quoted prices are vastly different as they are based on non-compatible methodologies with low prices usually indicating heavy reliance on using automated tools with little human verification. Depending on specific customer risk profile, that may or may not be appropriate choice.


We provide full spectrum of cyber security testing services, independent from relevant software developers and can support customers choosing the most optimum for their needs without relying on marketing buzzwords.

Web based application penetration testing service is one of the possible services. Described in this document, is a service geared towards customers with medium level risk profiles. Please note that services both for lower and higher risk profiles are available.

We are testing:

  • Static web pages in black box format
  • Client access portals in grey box format
  • APIs for third party integrations in black and grey box formats
  • APIs for mobile app integrations in black and grey box formats
  • API based dynamic web pages in black and grey box formats
  • Internal portals (ERP, CRM, etc ) systems

Automated tools are used during pen tests, but all identified risks and vulnerabilities are reviewed manually by skilled pen testers. Our testers focus on business logic issues because we firmly believe that every application requires a unique approach that includes testing the integrity of the intended business logic.

During penetration testing we do:

  • Vulnerability assessment using professional tools (Nessus Professional, etc..)
  • Manual review of results to exclude false positives
  • Manual testing of found vulnerabilities to identify any exploitable
  • Manual review or OWASP Top 10 and other risks if applicable to system in scope

Penetration testing report is final deliverable, it includes results from all testing scenarios and:

– The management summary, which will summarize the findings for the non-technical audience,

– technical report, which will cover the technical findings of the audit in depth and in full detail:

  • Description of findings and risks.
  • Impact, calculated by using CVSSv3 methodology.
  • Related CVEs if applicable.
  • Screenshots and the description of the reconstruction of the vulnerability.
  • Recommendation for remediation.
  • internet links for detailed technical description of the risk to help with remediation.

Our report will give you a roadmap for improving security of the service and prioritized risk and remediation task list according to impact on company and customer data.

Our unique differentiators

Each of our tests is prepared by at least two experts and quality control of the results shall be ensured. Reports only include vulnerabilities that have been checked manually. As part of quality control, the risk levels, evidence, and completeness of the recommendations previously attributable to the vulnerabilities are assessed.

Pricing example

Web-based Line of Business systems (ERP, CRM, etc.)
The Black Box penetration testing

starts at 2’250 EUR

The GREY Box penetration testing

starts at 5’950 EUR

The price can vary if there are additional requirements.


How penetration testing is different from vulnerability assessment?

Vulnerability assessment is the process of using automated professional tools to detect, categorize, and score vulnerabilities existing in a system. Penetration testing refers to the active exploitation of vulnerabilities to determine their severity, applicability to system in scope, potential for causing damage to customer business. Manual penetration testers can ensure zero false positives. However, vulnerability scanning is an important part of penetration testing.

How penetration testing is different from red-teaming?

There is no single “correct” definition for “red-teaming”. Usually, the goal of a pen-test is to find as many vulnerabilities as possible, try to exploit them, and access each vulnerability’s risk level. A red-team testing goal is to find one way in, exploit it and then escalate laterally through your system to access the most valuable data. Often, “red-teaming” is also associated with longer, higher fidelity, stealthy engagements with only very few restrictions for methods and tactics. As such, red-teaming mimics very determined, focused attacker.

What graybox means and how is it different from blackbox?

In a black-box testing the penetration tester is placed in the role of the average hacker, with no internal knowledge of the target system and no accounts. A black-box penetration test determines the vulnerabilities in a system that are exploitable from outside the network.

Gray-box tester has the access and knowledge levels of a user, potentially with elevated privileges on a system. Gray-box pen testers typically have some knowledge of a network’s internals, potentially including design and architecture documentation and various types of accounts in the system.

What is static and dynamic web page?

Static websites appear the same for every user that accesses them and only change when a developer modifies the source files, whereas dynamic websites can present different information to different visitors. The web page will look the exact same to everyone who requests it. Static web pages does not have user profiles.

What is API?

An application programming interface (API) is a way for two or more computer programs to communicate with each other. API usually does not have human readable interface.

Is password brute-forcing included in tests?

We do some limited test on common passwords (no more than 1000) for privileged accounts if system logic allows automated attacks and tests are on production systems. We can test against large password data bases in various languages, use additional logic for password permutation, but such actions are negotiable and not included in standard test proposal.