Fib.Code
A vulnerability scan will tell you that something is out of date. A penetration test will show what follows from it: whether that one unpatched service opens a route into the internal network, on to the HR records, and back out unnoticed. The difference is fundamental, and it is increasingly required outright - the Polish NCS Act expects verification of the effectiveness of risk management measures, the DORA Regulation introduces advanced TLPT testing for significant financial entities, and ISO/IEC 27001 requires technical vulnerability management and the testing of security controls. Every test we run is based solely on a written scope and rules of engagement agreed before work begins. That is not a formality - it is the condition that distinguishes a security test from an incident.
Before the production release of a new application, system or integration
On a recurring basis, where required by the NCS Act, DORA, ISO 27001 or a client contract
After a significant change of architecture, a migration to the cloud or an acquisition
When a corporate client or an insurer demands proof that the systems are resilient
After an incident - to check that the cause was fixed, not merely the symptom
We match the scope to the actual risk rather than to a price list - sometimes a single application is enough, sometimes a full attack simulation is needed.
Scope and rules of engagement - We agree in writing what falls within scope, what must not be touched, the hours we work, who is the point of contact on your side and how the test is halted should anything go wrong. Without that document we do not begin.
Reconnaissance - We gather information on the attack surface from the perspective of an adversary with no access to your documentation. This stage regularly uncovers assets the organisation had forgotten: old test environments, abandoned subdomains, services exposed by mistake.
Testing - We work to PTES, NIST SP 800-115 and the OWASP guidance, combining automated tooling with manual work. Automation finds known vulnerabilities; a person finds business logic flaws - and it is those that tend to prove the most costly.
Verification and escalation - We confirm every finding in practice to rule out false positives, and we establish how far it can be taken. A vulnerability that allows a domain administrator account to be taken over is an entirely different matter from the same vulnerability in an isolated system.
Report - you receive two documents: an executive section for the board - free of jargon, with an assessment of business risk - and a technical section for the team, with reproduction steps, evidence and a specific remediation recommendation. Findings are mapped to CVSS, CWE and the MITRE ATT&CK matrix.
Retest - once the fixes are in place we return and check that the vulnerabilities have genuinely gone. A retest of the core scope forms part of the service - a report without confirmation of remediation is only a list of problems, not their resolution.
A scan is an automated comparison of software versions against a database of known vulnerabilities - it runs in hours and produces a long list on which a fair number of entries turn out to be false positives. A penetration test is the work of a person who verifies that list, links individual weaknesses into an attack chain and establishes where it actually leads. A scan answers the question of what is out of date; a test answers the question of what can be done with it. Both are needed, but only the second shows the real risk.
The risk exists and we will not conceal it - which is why we manage it rather than pretend otherwise. The rules of engagement set out the time window, the list of systems excluded from testing and the prohibited actions, such as denial-of-service attacks. With OT environments and medical systems we take a conservative approach, often confining ourselves to passive testing or working on an environment that mirrors production. We stay in continuous contact with your team and halt work immediately on request.
A single web application is usually five to ten working days, a medium-sized infrastructure ten to fifteen, and a full red team operation four to six weeks. We deliver the report within a week of the testing concluding, and we report critical findings immediately once they are confirmed, without waiting for the work to finish. There is no reason for you to learn of a critical vulnerability only from a document.
Written consent from the owner of the systems - and that is not a matter of courtesy but the legal basis for the entire engagement. Where the infrastructure sits with a cloud or hosting provider, some activities require that provider's consent or notification; we help you through the procedure. We also agree how any data we may come across during the test is to be handled and how it will be securely deleted once the work is complete. All of this is recorded in the contract and in the rules of engagement before we begin.
It is an important piece of evidence, but on its own it is not sufficient. The Polish NCS Act expects a risk management system, and verifying its effectiveness - testing included - is one component of that. ISO/IEC 27001 requires technical vulnerability management and the testing of security controls, and the auditor asks not only for the report but also for what became of its findings. That is why every report closes with a prioritised remediation plan, and why at retest we document the closure of each finding.