Română
Português
EspañolWeb applications
Sign-in, sessions, access control, injection and business logic, tested against the OWASP Top 10 and the OWASP Web Security Testing Guide.
Tested by people • Inside the windows you authorise • Nothing installed
Penetration Testing. Your applications, APIs, networks and mobile apps, tested by people.
Ask for a test, agree the scope and the window, and follow it to the last finding. Every request, hour, finding and validation round is kept in one place, beside your security monitoring.
SCOPE
What we test
Black box with no credentials, grey box with a user account, or white box with full access, for each kind of target.
APIs
REST and GraphQL endpoints, tokens and keys, rate limits and what each role can reach, tested against the OWASP API Security Top 10.
Infrastructure
External and internal networks: exposed services, weak configuration, missing patches and the paths from one machine to the next.
Mobile apps
iOS and Android apps from their store packages, analysed statically and dynamically against OWASP MASVS. No source code needed.
HOW IT WORKS
From request to closed finding
Every step is recorded with who did it, when and why, and you see it as it happens in the Security portal.
1
Request
Send it from the Security portal or from your own platform through the API: the targets, the type of test, black, grey or white box, the hours and the window.
2
Approval
The operator checks the scope and that you may have it tested, reserves the hours and agrees the window. Nothing is tested before that.
3
Testing
Only inside the window. Scanners make the wide sweep; testers confirm what is real and go where scanners cannot.
4
Review
Every finding is checked by a second person before you see it: its severity with the CVSS vector, the evidence, how to reproduce it and how to fix it.
5
Remediation
Your team marks each finding as being fixed, fixed or an accepted risk, and the reason is recorded.
6
Validation round
We test again and close what is really fixed. Findings are followed between rounds: new, persistent, fixed or reopened.
HOURS YOU CAN SEE
An hour bank, not an open-ended bill
You agree the hours when you subscribe, and you see every one of them spent.
Reserved, used, available
Hours are reserved when a request is approved, logged as testing happens and released if they are not used. Alerts reach you at 50, 75, 90 and 100%.
No silent overrun
When the bank is spent, nothing more is approved or logged unless you agree to it, and who agreed and why is recorded.
Reports never use hours
Reports are produced from the findings themselves, so every hour you pay for is spent on testing.
INTEGRATION
Built into the way you already work
Requests can start in your own platform, and results go back to it.
API and webhooks
A versioned REST API described in OpenAPI, with scoped keys and idempotent requests, and signed webhooks on every change.
Reports and exports
Findings in JSON and CSV; an executive and a technical report for each asset, and one report for the whole programme.
Ticketing
Each finding becomes a ticket in Jira, and its state comes back as your team works on it.
On-site connectors
Internal networks are reached through a connector that makes outbound encrypted connections only. No inbound port is opened.
ONE PLATFORM
What attackers could do, beside what they try
Penetration testing is a service of its own, run from the same Security portal as your monitoring.
Monitoring shows the attempts
Cyber Security Compliance watches your servers, cloud accounts and services every day and scans them for known weaknesses.
View Compliance CapabilitiesTesting shows what would succeed
The tests, their findings and the fixes are kept with their dates: evidence of regular security testing, the kind NIS2 Article 21 and DORA ask organisations to show.
Before you ask
Penetration testing questions
Straight answers about scope, windows, credentials and hours.
Is a penetration test the same as vulnerability scanning?
No. Scanning finds known weaknesses automatically, and Security already does that on every machine it monitors. A penetration test adds people: they confirm which weaknesses an attacker could really use, chain them together and test what scanners cannot see, such as access control and business logic.
Do you install anything on our systems?
No. Nothing is installed on the systems tested. Internal networks are reached through an on-site connector that only makes outbound connections.
Who decides when testing happens?
You do. Testing runs only inside the windows you authorise, after the operator has approved the request, and the contacts you name are told before it starts.
What do you need for a grey or white box test?
Accounts, roles or keys for the systems in scope. They are sealed as soon as they arrive and never shown again, not even in your own portal.
How are hours counted?
Against an hour bank agreed when you subscribe. Hours are reserved when a request is approved, logged as testing happens and released if they are not used. Reports never use hours.
Can our own platform send test requests?
Yes. Your risk-management or ticketing platform can send requests and read the results through the API, and is told of every change by signed webhooks.
How does it relate to Cyber Security Compliance?
It is a service of its own, run from the same Security portal. Monitoring shows what attackers try every day; a penetration test shows what they could achieve. Both feed the evidence your auditor reads.
TESTED BY PEOPLE
Find what an attacker would find, first
Tell us what you want tested, and we will propose the scope, the hours and the window.