Services
Penetration testing of applications and infrastructure
Manual work, not a scanner printout. We find out what an attacker would actually do with your application, your network and your people — and then explain how to fix it.
Scope
Web applications
Testing aligned with OWASP ASVS: access control, authentication, business logic, IDOR, injection.
Infrastructure
Network segmentation, lateral movement, service configuration, external exposure, privileged account hygiene.
Social engineering
Phishing and vishing campaigns run like a real attack — measured, with training material afterwards.
Red teaming
A targeted attack combining digital and physical techniques — including an attempt to enter the building and bypass access control.
Security architecture
Designing and implementing network and system architectures that are secure from the ground up.
What it costs
Starting prices for a typical scope. The final quote depends on complexity, the number of systems and the time the work needs — but we do not open the conversation by asking about your budget.
| Service | Scope | Effort | Net price |
|---|---|---|---|
| Web application — standard test | OWASP Top 10, the most common attack vectors and vulnerabilities. For regular verification. | min. 5 days | from 15,000 PLN |
| Web application — comprehensive test | Full business logic analysis, complex attack scenarios, third-party library vulnerabilities. | min. 8 days | from 25,000 PLN |
| External network | Service discovery, exposure assessment from the internet, a hardening plan. | min. 5 days | from 12,000 PLN |
| Internal network | The „attacker is already inside" scenario: segmentation, lateral movement, access control. | min. 5 days | from 18,000 PLN |
| Red teaming with physical entry | A targeted attack combining the digital and physical layers. Quoted individually after a risk analysis. | min. 10 person-days | from 50,000 PLN |
For red teaming, operational costs agreed in advance are added to the price.
Red teaming — how it runs
The most advanced service we offer. It simulates a real, targeted attack on the organisation aimed at physical access to protected areas or assets.
Reconnaissance (OSINT)
Gathering information about the target from open sources, identifying weak points in procedures, infrastructure and the organisational structure.
Field operation
Controlled attempts to bypass physical security, tests of access control systems and social engineering against staff.
Report and debrief
A timeline of the attack with evidence, plus recommendations to strengthen both procedures and technical controls.
See what our report looks like
We share the full template of a penetration test report — 42 pages covering the document structure, the classification of findings, reproduction evidence and the format of recommendations. Give us an address and we will send it straight away — it usually arrives within a minute.
Who runs the tests
We run the tests ourselves — no subcontractors, no passing the scope on. The offensive work is done by two practitioners with many years of experience on the offensive side and eight appearances between them at Locked Shields, the largest cyber defence exercise, organised annually by NATO CCDCOE.
The same experience feeds the scenarios for our social engineering campaigns and our assessment of network segmentation — hence the emphasis on lateral movement and realistic attack paths rather than a tool's list of vulnerabilities.
Methodology
We work to PTES and OWASP ASVS. Every finding gets a risk rating, reproduction evidence and a specific remediation recommendation — one a developer can act on without a translator.
- Reconnaissance and threat modelling for the specific business, not from a template.
- Manual verification of every finding — no false positives in the report.
- A retest after the fix included, to close the loop.
What you get
- A technical report with evidence and reproduction steps.
- An executive summary — business risk, not jargon.
- A remediation plan ordered by real impact.
- Training material based on the findings — if you use the platform, it goes straight into your team's path.
A pentest and an automated scan are not the same thing
The most common misunderstanding when ordering tests. A scanner finds what is in its signature database. A pentester finds what nobody has described yet — because they understand how your business works.
| Automated scan | Penetration test | |
|---|---|---|
| Business logic flaws | Not detected | The main focus |
| Access control, IDOR | Occasionally | Systematically |
| Chaining vulnerabilities | No | Yes — a realistic attack path |
| False positives | Many — you sift them yourself | Verified by hand |
| Real risk assessment | A generic score | In the context of your data |
| Cost | Low | Higher — but it finds what actually hurts |
A scan makes sense as part of continuous monitoring. A penetration test makes sense as periodic verification before a release, an audit, or after a significant change to the system.
What a project looks like, step by step
Scope and authorisation
We agree what we test, in which hours and what we absolutely do not touch. We sign the authorisation — without it we do not start, because without it the test is a crime.
Reconnaissance
Mapping the attack surface and threat modelling for the specific business — a shop has different risks from a medical system.
The testing itself
Manual work supported by tools. Every finding is verified and documented with reproduction steps, so it can be repeated.
Report and retest
A technical report plus an executive summary. After the fixes we verify them — the retest is included in the project.
When a test is worth ordering
- Before a production release — fixing a flaw before launch costs a fraction of fixing it after an incident.
- Before an audit or certification — ISO 27001, NIS2 requirements, investor due diligence.
- After a significant change — a new payment module, a cloud migration, a partner integration.
- At a customer's request — large companies increasingly require a test report from their suppliers.
- On a cycle — once a year for critical systems, because both the code and the attack techniques change.
What we need for a quote
- What we test — a web application, an API, infrastructure, people, or a combination.
- Scale — the number of applications, IP addresses, user roles and integrations.
- Test mode — black box, grey box, or with access to the source code.
- Timing — whether there is a fixed audit or release date.
Starting prices are in the table above. The final quote depends on scope, because scope drives effort — after a short conversation we can give you a concrete range.
Frequently asked questions
How long does a penetration test take?
A typical web application takes from several to a dozen or so working days of testing plus time for the report. Extensive infrastructure or several systems at once takes proportionally longer. The exact duration follows from the agreed scope.
Can a test harm a live system?
We work so as not to affect service availability — destructive tests are run only with explicit consent and usually in a test environment. Working hours and risky techniques are agreed before we start.
Do you test in production?
Yes, if the client requires it — carefully and within an agreed window. If there is an environment that mirrors production, that is usually the better choice.
What do I receive at the end?
A technical report with evidence and reproduction steps, an executive summary in the language of business risk, a remediation plan ordered by real impact, and a retest once the fixes are deployed.
Is the report enough for a NIS2 or ISO 27001 audit?
A test report is one piece of evidence of risk management, but it does not replace an entire security management system — including the documented staff training required by the Polish NIS2 act.
A test is a snapshot of one day. An awareness programme runs all year
Most often the two go together: the test shows where the gap is, the platform makes sure it does not come back.