Service
Penetration testing
We attack a defined system the way a motivated attacker would, within agreed limits. The result is a list of weaknesses that actually work, with evidence, in priority order.
What we test
| Target | What we look at |
| Web applications | Authentication, session handling, access control, input handling, business logic, file handling, third-party integrations |
| APIs | Authorisation on every endpoint, object-level access, rate limits, input validation, token handling, documentation against actual behaviour |
| Mobile apps | Local data storage, transport security, certificate handling, API use, reverse engineering of the app binary, platform permissions |
| Infrastructure | Exposed services, patch level, network segmentation, credentials, Active Directory, lateral movement from a foothold |
| Cloud | Identity and access management, storage permissions, network rules, secrets handling, Kubernetes configuration, logging coverage |
How we test
Manual first. We test authentication, session handling, access control and business logic by hand, because scanners do not understand what your application is for. Tools support the work: they map the surface and catch known issues, so our time goes to the parts a tool cannot judge.
We follow the OWASP Web Security Testing Guide and the OWASP Application Security Verification Standard for applications, and PTES and NIST SP 800-115 for infrastructure. You can read these standards yourself; we are happy to walk you through how they apply to your scope.
What you receive
- A management summary on one page
- Findings with severity, impact, reproduction steps and a fix
- A walkthrough call with the tester who did the work
- One retest of all findings, within three months
- A letter of attestation for your customers or auditors, on request
Typical duration
A single web application or API usually takes five to ten working days of testing. Infrastructure and cloud environments depend on size; most take between five and fifteen days. We give you the exact number in the quote.
Pricing
We charge a fixed price per engagement, based on the number of testing days. You receive the quote after the scoping call, and it does not change unless you change the scope. The retest and the walkthrough are included.
What a penetration test does not cover
A penetration test is a snapshot, not a guarantee. It covers the systems in scope, during the testing window, with the time agreed. It does not find every weakness, and it does not cover changes you make afterwards. It is also not a substitute for monitoring, backups or an incident plan.
Service
Security audits
An audit reviews how a system is designed, configured and operated, without attacking it. It answers a different question from a penetration test: not “can this be broken?” but “is this built and run the way it should be?”
What we assess
| Audit type | What we review | What you receive |
| Configuration review | Servers, cloud accounts, Kubernetes clusters, identity providers and network devices, against CIS Benchmarks and vendor guidance | A list of deviations with the setting, the risk and the recommended value |
| Architecture review | Design documents, data flows, trust boundaries, authentication design and dependencies, through document review and interviews | A threat model and a set of design changes, in priority order |
| Compliance readiness | Your controls, policies and evidence against the framework you are preparing for | A gap analysis per requirement, with the work needed to close each gap |
Frameworks we assess against
| Framework | Who it applies to |
| NIS2 | Essential and important entities in the EU |
| ISO/IEC 27001:2022 | Any organisation seeking certification of its security management |
| DORA | EU financial entities and their ICT providers |
| SOC 2 | Service providers whose customers ask for an attestation |
| CIS Controls v8 | Any organisation wanting a prioritised baseline |
We prepare you for the audit. We do not certify; certification is done by an accredited body, and we can recommend one.
How we work
We read your documentation first, then interview the people who run the systems, then verify what we were told against the actual configuration. Every gap in the report points to the evidence we saw, or did not see.
Typical duration
A configuration review of one environment takes three to five working days. A compliance readiness assessment takes two to four weeks, depending on the framework and the size of your organisation.
Pricing
Fixed price, quoted after the scoping call. For readiness assessments we also offer a day rate if you want us to help close the gaps afterwards.
What an audit does not cover
An audit checks design and configuration. It does not prove that a system cannot be attacked; a penetration test does that for the parts of the system that are exposed. Many clients do both, in that order.
Methodology
How we work
The process is the same for every engagement. You know what happens at each step, who does it, and what you receive.
-
Scoping
A 30-minute call to define the targets, the testing window, the accounts we need and the rules of engagement. We write this down and both sides sign it. You receive a fixed-price quote within two working days.
-
Testing
Manual first, tools as support. We keep a daily log of what we tested. If we find a critical issue, we tell your named contact the same day, with enough detail to mitigate it before the report.
-
Report
Delivered within five working days of the last testing day. One-page summary, findings in priority order, reproduction steps, and a list of what we tested and found no issue with.
-
Walkthrough
A call with the tester to go through each finding, answer questions and agree on priorities. Developers are welcome; the call is for them as much as for management.
-
Retest
Within three months, we verify each fix and mark it in the report as fixed, partly fixed or not fixed. One retest is included in every penetration test.
Standards
OWASP Web Security Testing Guide and ASVS for applications. OWASP MASTG for mobile. PTES and NIST SP 800-115 for infrastructure. OSSTMM for test planning. CIS Benchmarks for configuration reviews. We cite the relevant section in each finding.
How findings are rated
Each finding gets a CVSS 3.1 base score. We then adjust the severity for your context, for example lowering it if the affected system is internal only, and we state why. Severities are Critical, High, Medium, Low and Informational.
Confidentiality and data
We sign your NDA or provide ours. Evidence is stored encrypted on systems in the EU, shared only with the people you name, and deleted 90 days after the retest unless you ask us to keep it. We never name clients without written permission.
About
Who we are
Ber-Sec is a small team of security testers. Each of us has worked in offensive security for at least five years, in consultancies and in-house teams, and holds hands-on certifications such as OSCP, OSWE and CRTO. The people on the scoping call are the people who test and write the report.
We work this way because the reports we received as in-house engineers were often long, vague and hard to act on. A finding is only useful if the person who has to fix it understands it, can reproduce it, and knows what to do. That is the standard we write to.
We take on a limited number of engagements at a time so that each one gets a named tester for its full duration.