Penetration testing (läbistustestimine) for web applications and authentication

What a penetration test shows

A scanner looks for known patterns and reports what might be wrong. Manual testing proves what can actually be exploited, shows how findings chain into an attack, and finds logic and authorization flaws that have no signature. Most of the time goes into authentication, session handling, access control and business logic.

How it maps to KüTS, E-ITS and NIS2

This table is our own mapping. RIA’s only official cross-walk is between E-ITS 2024 and ISO/IEC 27001:2022. KüTS itself does not name penetration testing. An E-ITS measure may be replaced by an equivalent one or left out if the protection need is met otherwise or the organisation has accepted the risk (JDM Regulation No 30 § 7 lg 6). For small service providers, see the baseline security measures page.

We test, we do not audit

ProksiAbel does not do E-ITS audits. An E-ITS auditor must not have taken part in designing or implementing the auditee’s information security management system, including as a consultant, in the three years before the audit (JDM Regulation No 30, annex 2 p 4.6). We check technically whether the measures work. Someone else does the audit, and the report is evidence you can show them or RIA.

How an engagement runs

1. Scope. We agree targets, test accounts, time windows and rules of engagement in writing. We never go beyond the agreed scope.
2. Testing. We test manually to the OWASP Web Security Testing Guide. Tools support the work, they do not replace it.
3. Report. Every finding comes with reproduction steps, evidence, a CVSS score and a concrete fix for your stack. Critical findings are reported as soon as they are confirmed.
4. Retest. After the fixes we re-check every finding with the same steps and record its status in the report.

The price depends on the scope. We send a quote once the scope is agreed.

Who it is for

• A service provider under KüTS that wants to show its web application and authentication controls work.
• An IT supplier whose customer is in scope. The customer stays responsible when it outsources system management and must make sure the supplier applies the security measures (KüTS § 7 lg 3). That is why questionnaires and audit rights end up in contracts. The report shows what was tested, what was found and what was fixed.

Whether the act applies to you: see the NIS2 section.

Examples of our technical work

Each guide shows how to find or verify the problem and how to fix it:

• IDOR: reaching another user’s data
• SSRF: into the internal network through the server
• Security headers checklist

Frequently asked questions

Is penetration testing mandatory under KüTS?

KüTS requires appropriate security measures (§ 7), not a penetration test by name. The E-ITS 2026 catalogue has a DER.3 Security testing module, but a measure may be replaced or left out if the protection need is met or the risk accepted (JDM Regulation No 30 § 7 lg 6).

Do you do E-ITS audits?

No. An auditor must not have taken part in designing or implementing the auditee’s information security management system, including as a consultant, in the three years before the audit (JDM Regulation No 30, annex 2 p 4.6). We do technical testing.

How is a penetration test different from a vulnerability scan?

A scanner reports what might be wrong. Manual testing proves what can be exploited and finds logic and authorization flaws that have no signature.

Do you test production?

Only if agreed in writing. We prefer a test environment that mirrors production. If production is in scope, we agree time windows, request limits and a contact who can stop the test beforehand.

Can the report answer a customer’s supplier questionnaire?

The report shows what was tested, what was found and what was fixed. Whether that satisfies the customer is the customer’s call, since it is responsible for its suppliers’ security measures (KüTS § 7 lg 3).