Vulnerability Assessment & Penetration Testing (VAPT)
Finding and testing vulnerabilities in a defined system or service
We find vulnerabilities in the systems and services we agree on, and confirm whether they can really be exploited and what they would mean for your business.
Vulnerability assessment (VA) looks across the whole target for vulnerabilities and misconfigurations; penetration testing (PT) chains weaknesses the way an attacker would, to see how far they really lead. Our experts confirm every finding by hand.
Can the vulnerabilities in this system actually be exploited? Reviewed
We set out the findings, their real impact, the evidence and how to improve.
When it fits
- You know what needs testing
You have a specific product, service or system in mind and want to know its vulnerabilities and their real impact.
- A release or major change is coming, or just done
You want to check the security of a new service or a significant change before or after it goes live.
- Someone has asked for an independent test
A customer or partner's security checklist, a tender, or preparation for a certification audit calls for an independent, third-party technical test. The results do not replace the audit itself or legal advice.
- You need to show something was fixed
You want issues flagged in an audit, or weaknesses fixed after an incident, checked again the same way within an agreed scope.
How assessment and penetration testing differ
They differ in purpose and depth. By default the two run together, and penetration testing can also be commissioned on its own.
| Aspect | Vulnerability assessment (VA) | Penetration testing (PT) |
|---|---|---|
| What it checks | Known kinds of vulnerabilities and misconfigurations, looked for widely across the whole target. | How far an attacker could really get, by chaining the weaknesses found. |
| How | Checklists, tools and AI agents cover the ground; experts review the results and weed out false positives. | Experts learn how the target and its business flows work, then verify attack paths that link several weaknesses, by hand and under controlled conditions. |
| What you get | A list of vulnerabilities, with severity and how to fix them | Attack paths, their real business impact, and reproducible evidence |
| When | Regular checks, a baseline before a release, or a wide scope to cover at once | An important service, an independent result someone has asked for, or the real risk behind assessment results |
What we test
For each kind of target we also test the wider areas around it, from settings and configuration down to the equipment and software themselves. Targets not shown here can be scoped with you.
Web, APIs and mobile
- The target
- The web services and mobile apps your customers use, and behind them the APIs, admin screens and connected outside services, looked at as one service.
- What we can test
- Login, sessions and account management
- Permissions and data access for each user
- Input handling and server-side vulnerabilities
- Business logic such as ordering and payment
- Storage, communication and code protection in mobile apps
- Admin screens and internal APIs
- File handling and outside integrations
- Server and framework configuration
Authentication and permissions (AD, LDAP, SSO)
- The target
- The directory that manages staff accounts and rights, SSO and authentication servers, and the systems that rights flow through.
- What we can test
- AD and LDAP structure and policies
- SSO and federation settings
- Paths to higher privileges
- Service accounts and delegation
- Authentication servers and multi-factor authentication
- The account lifecycle: joining, moving, leaving
- Permission structures in payment and approval flows
Servers, networks and cloud
- The target
- On-premises servers and networks, clouds such as AWS, GCP and Azure, and container and Kubernetes environments.
- What we can test
- Services and admin consoles exposed to the internet
- Vulnerabilities in servers, operating systems and middleware
- Network design and segmentation
- Cloud permissions (IAM) and configuration
- Storage, keys and secrets management
- Containers and Kubernetes
- Logging and monitoring settings
AI agents
- The target
- AI agents that work through email, calendars, internal systems and outside tools, together with the environment they run in.
- What we can test
- The reach of tool and API permissions
- Where actions need a person's approval
- How outside input (documents, web pages, email) affects behavior
- Data leaving through the agent
- The execution environment and its isolation
- Action records and traceability
- Authentication to connected systems
LLM services
- The target
- Services built on language models, such as chatbots, retrieval-augmented answers and summaries, with their models, data and integrations.
- What we can test
- Prompt injection, direct and indirect
- Exposure of sensitive data and system instructions
- Permissions on the documents it retrieves
- Output handling and its effect on connected systems
- Whether safety policies work as intended
- Misuse of usage and cost
- The model and data supply chain
OT and control systems
- The target
- The control networks of plants, factories and buildings, control equipment such as PLCs, HMIs and SCADA, and where they connect to business networks.
- What we can test
- The boundary and separation between control and business networks
- Remote access routes
- HMI, SCADA and engineering workstations
- Industrial communication protocols
- Vulnerabilities in PLCs and other control equipment and their firmware, including previously unknown (zero-day) ones
- Equipment management accounts and settings
To avoid affecting equipment in operation, we agree the test environment and methods first.
IoT, embedded devices and firmware
- The target
- Connected devices in shops, homes and industrial sites, their firmware, and the apps and cloud that manage them.
- What we can test
- Firmware analysis
- Hardware interfaces
- Communication between device, app and cloud
- Management screens and default accounts
- Integrity of the update process
- Vulnerabilities in the device itself, including previously unknown ones
- The mobile app that manages the device
GPU and HPC
- The target
- GPU clusters and HPC environments used for training and inference, with their schedulers and shared storage.
- What we can test
- Job schedulers and management interfaces
- Isolation between users and teams
- Permissions on shared storage and training data
- Access to model files
- The software stack, such as drivers and runtimes
- Networking between nodes
- Inference service APIs
The areas are examples; the actual scope is agreed with you.
What we start from
What a tester can see, and the effort it takes, depends on how much they know about the target at the start. We choose it with you, to fit the goal.
Black box
We start with no inside information, as an outside attacker would. It shows exactly what is visible from outside, but reaches less of the inside.
Grey box
With test accounts and basic architecture details, we also test what sits behind the login. A good balance between real attack conditions and coverage.
White box
With source code, designs and configuration, we look from the inside, and can find problems that never show from outside.
Before and after loginWe scope what sits before the login (open to anyone) and after it (features by account role) separately. Accounts with different roles, such as an administrator and an ordinary user, make authorization problems easier to find.
How a project runs
Agree goals, scope and conditions
We agree in writing the targets and goals, the level of information you provide (black, grey or white box), the scope before and after login, permitted and prohibited actions, and stop conditions.
Prepare
We prepare test accounts and environment details at the agreed level, and learn how the target is built.
Test and verify
Tools and AI agents cover the ground; our experts analyze by hand and safely confirm what can really be exploited.
Report and explain
We explain a summary of your security state, the findings and their real impact, the evidence and how to improve, to decision-makers and technical staff.
Recheck after fixes
Where agreed, we check your fixes again using the same method.
What we'll ask you forThe targets and scope, test accounts for each role, a contact for the testing period, and, for live systems, when testing may run.
Keeping it safeTests that could affect a service run only if agreed in advance; if something looks wrong, we stop under the agreed stop conditions and tell your contact. How data and evidence handled during testing are kept and destroyed is agreed up front too.