Penetration testing: find the weaknesses before attackers do
Gjethe runs authorised penetration tests on websites, web applications, APIs, mobile apps and networks. We agree the scope in writing, test by hand using recognised methods, and deliver a report that ranks every finding by risk, explains how to fix it and confirms the fixes in a retest.
- Free first consultation
- Written quote for your project
- Flexible payment milestones
At a glance
- Targets
- Web apps, APIs, mobile apps, networks, cloud
- Approach
- Black, grey or white box, agreed with you
- Method
- OWASP, PTES and NIST SP 800-115
- Output
- Risk-ranked report, fixes and a retest
Definition
What is penetration testing?
A penetration test is an authorised, simulated attack on a system to find security weaknesses, measure their real impact and recommend how to fix them, carried out with the owner's written permission and inside an agreed scope.
Automated scanners find known patterns. Real attackers combine small weaknesses, probe business logic and keep going when the first idea fails. A penetration test does the same, with your permission and inside agreed limits, so you learn what matters: whether someone could reach customer data, admin access, payment flows or internal systems. The result is a prioritised list of real problems you can act on, not a pile of scanner noise, plus the confidence that comes from having checked.
Who is it for?
SaaS and web app teams
Before a launch, a major release or a client's security review, you need evidence that the product holds up.
Companies answering security questionnaires
Enterprise clients and partners increasingly ask for a recent penetration test report before they sign.
Businesses handling sensitive data
Health, finance, legal and personal data raise the stakes; regular testing shows where protection is thin.
Startups preparing to scale
Fixing structural security problems early is far cheaper than fixing them after customers depend on the product.
What's included, and what you keep
What's included
- Scoping call and written rules of engagement
- Signed authorisation before any testing starts
- Attack surface mapping of the agreed targets
- Automated scanning to cover the known basics
- Manual testing of authentication and sessions
- Access control and permission testing
- Input handling and injection testing
- Business logic and workflow abuse testing
- Careful verification to confirm real impact
- Executive summary for management
- Technical findings with evidence and fixes
- Retest of fixed findings and an updated report
What you receive
Handed over at the end. Yours to keep.
- Penetration test report with risk ratings
- Executive summary in plain language
- Clear write-up of each confirmed finding
- Fix recommendation for every finding
- Retest results and final report
Black box, grey box or white box?
| Approach | What we start with | Best for |
|---|---|---|
| Black box | Only the target address, like an outside attacker | Seeing what is exposed to the internet |
| Grey box | User accounts for each role and basic documentation | Most web apps and APIs: realistic and efficient |
| White box | Accounts, documentation and source code access | Deep coverage of critical systems |
How a penetration test runs
- 01
Scope
We agree targets, test accounts, allowed techniques, testing windows and emergency contacts.
- 02
Authorise
You sign written permission; for hosted systems we check the provider's testing policy too.
- 03
Map
We map the application, endpoints, roles and anything exposed that you may not know about.
- 04
Test
Manual testing guided by OWASP and PTES, with automation used only where it adds coverage.
- 05
Report
Findings ranked by risk, with evidence, business impact and clear instructions to fix them.
- 06
Retest
Once you have fixed the issues, we confirm each fix and update the report.
What makes a penetration test useful
A useful test is scoped around what matters to the business. Checking every forgotten subdomain while skipping the payment flow produces a long report and little safety. We start by asking which data and actions would hurt most if an attacker reached them, then make sure those paths get the most attention.
A useful report is also readable. Each finding explains what was possible, what an attacker could gain, how likely it is and exactly how to fix it, with references your developers can follow. Management gets a short summary of overall risk and the decisions it needs to make.
Finally, a test is only worth something when the findings are fixed. That is why a retest is part of every engagement, and why, as a development team, we can also help your people fix the issues rather than leaving you with a list.
How penetration testing works, step by step
Every step has a clear output you can review. Timing is agreed in your quote.
- 1
Scoping call
Targets, goals, constraints and the right testing approach agreed together.
- 2
Rules of engagement
Scope, windows, accounts and emergency contacts written down and signed.
- 3
Testing
Mapping, scanning and manual testing against the agreed targets only.
- 4
Reporting
Findings ranked by risk, with evidence and fix guidance.
- 5
Debrief
A call to walk your team through the findings and the priorities.
- 6
Retest
Fixes verified and the final report issued.
Tools, and what shapes your quote
Pricing is based on your project and agreed in your quote. These are the things that move it.
| Factor | Why it matters |
|---|---|
| Number and size of targets | A single marketing site is quicker to test than several applications, APIs and networks. |
| Number of user roles | Each role must be tested for what it can see and do, so more roles mean more test cases. |
| Testing approach | White box testing with source code goes deeper and takes more effort than black box testing. |
| Complexity of business logic | Payments, approvals and multi-step workflows need careful manual testing. |
| Constraints and windows | Out-of-hours testing or fragile production systems need more coordination. |
| Area | Tools |
|---|---|
| Web and API | Burp Suite, OWASP ZAP, Postman, custom scripts |
| Network | Nmap, vulnerability scanners, traffic analysis |
| Mobile | MobSF, device and emulator testing |
| Frameworks | OWASP Top 10, OWASP ASVS, PTES, NIST SP 800-115, CVSS |
Common mistakes to avoid
What we see go wrong most often, and how a good project avoids it.
Treating a scan as a penetration test
Automated scans miss logic flaws and access control problems, which are often the most serious findings.
Scoping out the important parts
Excluding the login, payments or admin area to avoid risk leaves the most valuable targets untested.
Testing once and never again
Every release changes the attack surface. Test after major changes and at regular intervals.
Filing the report away
A report with unfixed critical findings is a record of known risk, not protection.
Frequently asked questions
Is penetration testing legal?
Yes, when the owner of the system gives written permission and the scope is agreed. We never start testing without signed authorisation, and we only test what is in scope.
Will testing break our live system?
We test carefully, avoid destructive actions unless specifically agreed, and can work against a staging environment that mirrors production. We agree emergency contacts in case anything unexpected happens.
What is the difference between a vulnerability scan and a penetration test?
A scan is automated and lists known issues. A penetration test adds manual work by a tester who verifies findings, combines weaknesses and checks business logic that scanners cannot understand.
How often should we test?
At least once a year and after major changes, such as a new product, a large release, a new hosting setup or the merging of systems.
Do you include a retest?
Yes. After you fix the findings we retest them and issue an updated report showing what is resolved.
Can you help us fix what you find?
Yes. Our developers can implement the fixes in your code and configuration, or support your own team with guidance and review.
Will the report satisfy our clients' security questionnaires?
The report documents scope, method, findings and fixes, which is what clients usually ask for. If a client requires a tester with a specific accreditation, confirm that requirement with them before we start.
Do you sign an NDA?
Yes. Findings are confidential, the report is shared only with the contacts you name, and test data is removed at the end of the engagement.
Can you test our cloud setup too?
Yes, within the cloud provider's rules. Our cloud security assessment reviews AWS, Azure and Google Cloud configuration.
What do you need from us to start?
The targets, test accounts for each role, any documentation you have, preferred testing windows and a named contact during testing.
Can you test a mobile app as well as its backend?
Yes. We look at how the app stores data on the device, how it talks to its backend and whether that backend defends itself against requests the app would never send normally.
Related services
Web App Penetration Testing
Manual OWASP testing of logins, access control and logic.
API Security Testing
REST and GraphQL tests against the OWASP API Top 10.
Vulnerability Assessment
Find, rank and plan fixes for known weaknesses.
Secure Code Review
Review your codebase for security flaws before release.
Cloud Security Assessment
Review AWS, Azure and Google Cloud for misconfigurations.
Website Security
Hardening, malware clean-up and security reviews.
Penetration Testing by industry
Test your security before attackers do.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project