Vulnerability Assessment & Penetration Testing (VAPT)
Vulnerability assessment and penetration testing of a defined system or service
We find the vulnerabilities in your systems and services, and confirm which can really be exploited and what that would mean for the business.
Assessment and penetration testing normally run together; assessment alone suits regular checks, and penetration testing alone an important service, and either can be commissioned on its own.
Can the vulnerabilities in this system actually be exploited?
So you can fix the dangerous things first, each finding comes with its real impact, evidence you can check again, and how to fix it.
Expert reviewed
When it fits
- You know what needs testing
You have taken over a system built by a contractor, or moved servers to the cloud: the target is clear, and you want to know its vulnerabilities and their real impact.
- A release or major change is coming, or just done
If a new service is about to open and you are not sure it is ready, check it once before launch, and again after any major change.
- Someone has asked for an independent test
A contract with a large customer, a partner's security checklist, a tender or an upcoming certification audit asks for an independent penetration test report.
- You need to show something was fixed
Issues flagged in an audit, or weaknesses closed after an incident, are checked again the same way as the first time, so the fix is on record.
The SAFE SQUARE approach
Wide coverage, checked by people
Checklists, tools and AI agents cover the whole target; experts then confirm each result by hand and weed out the false positives.
Knowing how the business works
We learn how orders, payments and permissions really work, then chain weaknesses together to follow the paths that only open when several of them line up.
Results you can check again
Every finding comes with the conditions and evidence we used, so your developers and operators can confirm it themselves and the same check can be run again after the fix.
How assessment and penetration testing differ
They differ in purpose and depth.
| 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 | A set list of checks applied across the whole target. | Weaknesses chained and verified by hand, 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 areas around it, from settings and configuration down to the equipment and software themselves. The areas below are examples; 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
- Access control in basic business flows 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 (Active Directory, LDAP), the single sign-on (SSO) and authentication servers, and the systems that rights flow through.
- What we can test
- AD and LDAP structure and policies
- SSO and federation (authentication shared between organisations) 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 identity and access management (IAM) and configuration
- Storage, keys and secrets management
- Containers and Kubernetes
- Logging and monitoring settings
AI agents, LLM services and AI infrastructure are covered by AI System Security Assessment & Penetration Testing; control systems and IoT, embedded devices and firmware by Industrial Control & Hardware Security Validation.
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, and see exactly what is visible from outside. Grey or white box goes further 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.
How it runs
Agree goals, scope and conditions
We agree with you the targets and goals, the scope, and how much information we start with.
Prepare
We prepare test accounts and environment details, and learn how the target is built.
Test and verify
We confirm each finding from the assessment, then the penetration test establishes, within the set conditions, which can really be exploited and what that would mean for the business.
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
If you wish, we test the fixed parts again the same way and update the results.
Keeping it safeTests that could affect a service run only if agreed beforehand, and test accounts and scope are set so that real users' data is left untouched. The principles every engagement follows, safe conduct and stop conditions, facts kept apart from assumptions, and how material is kept and destroyed, are set out under How we work.
What you receive
Security summary
For decision-makers, at a glance: what was checked, the main risks, and what to fix first.
Findings and real impact
For each vulnerability, its severity, whether it can really be exploited and what it would mean for the business.
Reproducible evidence
The steps, conditions and evidence needed to confirm each result again, including the attack paths followed in penetration testing.
What to fix first
What to fix first and how, by how exploitable each issue is and what it would affect.
A signed-in member can see other members’ orders and delivery addresses
High- Target
- A commerce app's order lookup API · grey box, two ordinary member test accounts
- Real impact
- Members' names, phone numbers and delivery addresses could be exposed to other members. We confirmed this between test accounts only.
- Evidence kept
- The conditions (sign-in state and account role), request and response records, and screenshots
- How to fix
- When an order is requested, have the server check that it belongs to the member asking. Check the other lookup APIs built the same way too.
- Re-check
- After the fix, the same accounts and conditions are used again, and the finding is marked ‘fix confirmed’.
Finding which of your assets and information attackers can see from outside is covered by Exposure Intelligence. Whether gaps in business rules such as payments and benefits could lead to real losses is examined in Business Logic & Service Abuse Validation.