Skip to content
SecuriFii

Technical testing

Vulnerability Assessment and Penetration Testing (VAPT)

A vulnerability scan tells you what is exposed. A penetration test tells you what someone could do with it. Both have a place, and buying the first while believing you bought the second is one of the more expensive mistakes in security.

Discuss this
Standard
OWASP WSTG · NIST SP 800-115
Web methodology
OWASP WSTG v4.2
Severity scale
CVSS
Retest
Included
Minimum cadence
Annual

The distinction that matters

A vulnerability assessment is broad and largely automated: enumerate hosts, services and software, identify known weaknesses, rank them. It answers "what is exposed" across a wide estate and is worth running frequently.

A penetration test is narrow, manual and goal-directed. A tester chains weaknesses together the way an attacker would — a low-severity information disclosure plus a weak access control becomes account takeover — and demonstrates real impact. Chaining is precisely what a scanner cannot do, which is why a clean scan and a failed pentest routinely coexist.

This page is the overview of our testing, and the home of web application testing, which we carry out to the OWASP Web Security Testing Guide, version 4.2. Its twelve categories run from information gathering through authentication, authorisation, session management, input validation and business logic to client-side and API testing, and a report from us says which test cases were run and which did not apply.

Each other kind of testing has its own page, because each works to its own methodology. Network penetration testing, external, internal and segmentation, follows NIST SP 800-115. API security testing is prioritised by the OWASP API Security Top 10. Mobile application testing follows the OWASP Mobile Application Security Testing Guide. Cloud security assessment reviews configuration against the CIS Foundations Benchmarks. Secure code review reads the source rather than probing the running application. Whatever the target, findings are rated with CVSS and every one carries the steps to reproduce it.

Two clocks, not one

Infrastructure and application testing look for different things, and they are not on the same clock. Buying a single annual "VAPT" quietly means one of the two is being tested far less often than it should be.

Network and cloud

The exposed estate changes constantly and largely without a release: a firewall rule, a new instance, a storage bucket, an expired certificate, a newly published CVE against something you already run. Quarterly matches the rate at which the answer actually changes. Network penetration testing and cloud security assessment each have their own page, with the cadence for the internal and segmentation tests that sit alongside it.

Recommended cadence
Quarterly

External and internal networks, segmentation, cloud configuration

Applications and APIs

Application risk moves with your code rather than with the calendar, so the cadence that matters is the release one: a major release is the event that can introduce an access-control flaw or a broken authorisation boundary. The periodic test is the floor beneath that, half-yearly where the application handles payments, health data or personal data at scale. API security testing, mobile application testing and secure code review each have their own page.

Recommended cadence
Annually, or half-yearly — and on every major release

Web and mobile applications, APIs, authentication, business logic

What it will ask of you

A test is only as useful as the access and the authority behind it. These are the four things that decide whether a report is worth reading.

  • Written authorisation

    Named targets, a test window, escalation contacts and what is explicitly out of bounds. We do not test an asset you cannot demonstrate authority over, and where a cloud provider requires notification or approval we will tell you which.

  • A decision about depth

    Credentials for each role and some documentation turn reconnaissance budget into findings budget. Pure black box is realistic and pays for rediscovering an architecture you could have handed over.

  • Somebody who owns remediation

    A report with no owner becomes a backlog item that ages. The findings are ranked so that the first week of work is obvious.

  • A window for the retest

    The retest letter — not the original report — is what demonstrates to an auditor or a customer that the findings were closed.

What it is used for

  • Evidence for ISO/IEC 27001 and SOC 2, both of which expect technical testing on a defined cycle.
  • Customer and regulator obligations that name an independent test at a stated frequency.
  • Pre-release assurance for a major feature, a new integration or a cloud migration.
  • A ranked, costed remediation backlog engineering can act on instead of a scanner dump.

Not sure this is the standard you need?

Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.

Ask a practitioner

Where we come in, and where we stop

Security testing is where we are the assessor, and the difference is worth stating plainly. The impartiality rule that keeps us out of ISO and SOC 2 assessment applies to certifying a management system — it does not apply to technical testing, which is why the same firm may both test and advise. That holds for every kind of testing on our specialist pages too. What we will not do is test a control we designed and then present that test as independent assurance of our own work.

Ours

  • Scope, rules of engagement and the authorisation
  • Reconnaissance, mapping and the testing itself
  • Demonstrating findings to real impact, safely
  • The report, the remediation guidance and the retest

Yours

  • Authorising the test, and confirming you hold that authority
  • Owning remediation, with our support
  • Deciding what a finding is worth fixing first, on your risk appetite

How an engagement runs

Testing proceeds only under written authorisation naming the in-scope targets, the window and the rules of engagement. We do not test an asset you cannot demonstrate authority over.

  1. 01Scope and authorisationWe agree targets, environments, test window, escalation contacts, and what is explicitly out of bounds. You sign an authorisation, and where a cloud provider requires notification or approval we tell you which.
  2. 02Reconnaissance and mappingEnumerate the attack surface as an outsider sees it, then map application logic, roles and trust boundaries.
  3. 03TestingAutomated coverage for breadth, manual testing for depth — authentication and session handling, access control and privilege boundaries, injection, business logic, configuration and secrets exposure.
  4. 04Exploitation and chainingConfirmed findings are demonstrated to real impact, safely and within the agreed rules. Nothing destructive, and no data is exfiltrated beyond what proves the finding.
  5. 05ReportingAn executive summary that a board can read, and technical findings your engineers can act on: severity, reproduction steps, evidence and specific remediation guidance.
  6. 06Remediation support and retestWe work through the backlog with your engineers and retest the fixes, then issue a retest letter you can hand to a customer or an auditor.

What you get from us

  • Executive summary written for a non-technical reader
  • Findings with CVSS severity, evidence and reproduction steps
  • The methodology and version named, with what was and was not tested
  • Remediation guidance specific to your stack, not generic advice
  • A prioritised backlog your engineers can pick up directly
  • Retest of remediated findings and a retest letter for third parties

Common questions

Which kind of test do we need?

Start from what a customer or an auditor will ask about, and from where your data actually lives. A web product usually needs web application and API testing first; an organisation with offices, servers and a corporate network needs network testing; most now need a cloud review as well. Tell us what you run and what triggered the question, and we will say which combination fits, including when one test is enough.

How often should we test?

Annually as a floor, and after any significant change to an in-scope system. Organisations shipping continuously usually pair an annual deep test with lighter testing at each major release, and test their network and cloud exposure more often than their applications.

Black box, grey box or white box?

Grey box gives the best return for most engagements — the tester gets credentials and some documentation, and spends the budget finding flaws rather than rediscovering your architecture. Pure black box is realistic but pays for reconnaissance you could have supplied.

Will testing take our systems down?

Testing is designed to avoid disruption and destructive techniques are excluded by the rules of engagement. Some classes of test carry real risk on fragile systems; where that applies we say so at scoping and test against a staging environment instead.

Is the report enough for our auditor?

Yes. The report identifies scope, methodology, dates, tester and findings, which is what an ISO 27001 or SOC 2 auditor is looking for. The retest letter is what demonstrates the findings were closed.

Ready to scope it?

Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.

Start the conversation

Related services

  • Network Penetration Testing

    Test your network the way an outsider would, then the way someone already inside would — and prove that the boundaries you rely on to keep systems apart actually hold.

  • API Security Testing

    Find the request that returns somebody else’s data — the flaw that leads the OWASP API Security Top 10 and the one an automated scanner cannot recognise.

  • Mobile Application Security Testing

    Your app tested on a device an attacker controls, against the OWASP mobile standard — and the API behind it tested as well, because that is where the data is.

  • Cloud Security Assessment

    Review the part of the cloud that is yours to secure — identities, network exposure, storage, logging and keys — against a published baseline and against how an attacker would actually move through it.

  • Secure Code Review

    A reviewer reading your code for the flaws a scanner cannot see — with the scanner’s output triaged rather than forwarded.

  • ISO/IEC 27001 — Information Security Management

    Build an information security management system that survives Stage 2 — and the three years of surveillance that follow.

  • SOC 2 Type 2 Readiness

    Evidence that your controls ran for months, not that they existed on a date — the report enterprise procurement usually means.

All services

Related insights

All insights