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 · NIST SP 800-115
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.

We work to published methodology rather than a proprietary black box: the OWASP Web Security Testing Guide for web targets, the API Security Top 10 for APIs, the Mobile Application Security Testing Guide for mobile, and NIST SP 800-115 for the wider process. Findings are rated with CVSS, and every one carries the steps to reproduce it.

Two tests, 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.

Infrastructure VAPT

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, and it is short enough that a finding is still cheap when it is found.

Recommended cadence
Quarterly

Network, hosts, services, cloud configuration

Application and API VAPT

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.

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 we will tell you which.

  • A decision about depth

    Credentials 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.

Where we come in, and where we stop

This is the one service 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. 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 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
  • 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

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.

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.

Do you test cloud configuration?

Yes — identity and access policy, network exposure, storage permissions, logging and key management across the major providers. Cloud misconfiguration is where a large share of real findings sit.

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.

Related services

All services

Related insights

All insights