What are the main types of security testing?

The main types are vulnerability scanning, penetration testing, red teaming, purple teaming, secure code review (with SAST, DAST and SCA), configuration and cloud posture review, social engineering testing, physical security testing, bug bounty or coordinated vulnerability disclosure, and continuous testing such as PTaaS and threat exposure management. They differ in goal, depth, frequency, who performs them and the evidence they produce.

What is the difference between security testing and penetration testing?

Security testing is the umbrella term for every controlled attempt to find weaknesses, from automated scans to covert red team operations. Penetration testing is one discipline within it: a scoped, manual, time-boxed exploitation of a defined target by qualified testers, producing evidence of what an attacker could achieve. Every penetration test is a security test; most security tests are not penetration tests.

Which type of security testing should an organisation start with?

Start with an asset inventory and authenticated vulnerability scanning, then a grey box penetration test of the systems holding the most sensitive data. Those two cover the known weaknesses and the attacker's view of your most important target. Add code review in the pipeline, social engineering testing and an internal test next, and red teaming only once those are routine.

How often should each type of security test be performed?

Vulnerability scanning weekly to continuously. Penetration testing annually and after significant changes, and per major release for critical applications. Phishing simulation monthly to quarterly. Configuration review continuously through posture tools, with an annual expert review. Purple teaming quarterly. Red teaming every one to two years for mature organisations, and every three years as TLPT for financial entities designated under DORA.

Is a vulnerability scan a security test for compliance purposes?

It is a required one under PCI DSS Requirement 11.3 and expected under ISO 27001 control A.8.8, but it does not satisfy penetration testing requirements such as PCI DSS 11.4, DORA Article 25, 23 NYCRR 500.5 or the GLBA Safeguards Rule, which call for exploitation by qualified testers. Auditors check the methodology and tester qualifications, not the label on the report.

What is the difference between red teaming and purple teaming?

Red teaming is a covert, objective-based simulation of a real adversary that tests whether your detection and response notice an intrusion. Purple teaming is an open, collaborative exercise in which attackers execute techniques while defenders tune detection in real time. Red teaming measures; purple teaming improves. Most mature organisations alternate them.

Does HackersHub offer every type of security testing?

HackersHub delivers penetration testing, red teaming, purple teaming, social engineering and physical testing, managed vulnerability scanning and threat exposure management, with code review as part of white box penetration tests. For bug bounty programmes we advise on scope and triage design rather than operating a platform. Every engagement is scoped in writing with named, certified testers.

1 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Types of security testing: the full landscape from vulnerability scan to red team, and which ones your organisation needs

Security testing is not one service. It is a set of ten disciplines that answer different questions at different depths and cadences. This guide defines each one, compares them side by side, and shows how they combine into a programme that grows with your maturity.

Scope a penetration test

What security testing is, and why one test is never the whole answer

Security testing is any deliberate, authorised attempt to find weaknesses in systems, software, people or processes before an adversary does, under controlled conditions. That definition covers a weekly automated scan and a six-week covert red team engagement alike, which is why the term causes confusion in procurement. A vendor's 'security test' may be a scanner report; a regulator's 'security testing' may mean a documented programme of several test types. ISO/IEC 27001:2022 asks for technical vulnerability management (control A.8.8) and security testing in development and acceptance (A.8.29). NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. DORA Article 25 lists the tests a financial entity's programme should include, from vulnerability scans and source code reviews to scenario-based tests and penetration testing.

The disciplines differ on five dimensions: what they try to find, how deep they go, how often they should run, who is qualified to perform them, and what evidence they produce. None of them replaces another. The mistake buyers make most often is to purchase one and describe it as another: a scan sold as a penetration test, or a red team ordered before the basics have ever been tested.

This guide covers the full landscape. For the sub-types of penetration testing itself (by target, position and knowledge level) see our separate guide to the types of penetration testing. For the pairwise comparison with scanning, see penetration test versus vulnerability scan.

The ten types of security testing

Each discipline, the question it answers and where it sits in the programme.

Vulnerability scanning

Automated identification of known weaknesses: missing patches, outdated components, default configurations, exposed services. Authenticated scans see far more than unauthenticated ones. Answers: which known issues exist across the estate right now? The output is a prioritised list that needs human triage; it does not prove exploitability.

Penetration testing

Manual, scoped exploitation of a defined target (network, web application, API, mobile, cloud) by qualified testers following PTES, OWASP WSTG and MASTG or NIST SP 800-115. Answers: what can a skilled attacker actually do here, and how far do findings chain? Output: evidence-backed, CVSS-scored findings with remediation and a retest.

Red teaming and adversary simulation

Objective-based, usually covert, multi-week simulation of a realistic adversary across people, process and technology, mapped to MITRE ATT&CK. Answers: would we detect and stop a real intrusion before it reached the objective? Output: an attack narrative, detection gaps and a response timeline rather than a vulnerability list. Threat-led variants (TIBER-EU, DORA TLPT) are coordinated with the regulator.

Purple teaming

Red and blue teams work together in the open, executing selected attack techniques while defenders tune detection in real time. Answers: do our logging, alerting and playbooks catch the techniques that matter to us? Output: a per-technique detection matrix and tuned rules.

Secure code review, SAST, DAST and SCA

Finding defects in software before and during release: manual code review and static analysis (SAST) on source, dynamic analysis (DAST) on the running build, software composition analysis (SCA) on dependencies. Answers: does our code introduce vulnerabilities, and do our libraries carry known ones? Runs in the pipeline on every build, with manual review reserved for critical modules.

Configuration and cloud posture review

Assessment of how systems are configured against a benchmark: CIS Benchmarks for operating systems and cloud accounts, vendor hardening guides, identity and access policy review. Cloud security posture management (CSPM) tools do this continuously for AWS, Azure and Google Cloud. Answers: are we running what we have securely?

Social engineering testing

Phishing simulation, vishing (voice), smishing, pretexting and USB drops that measure whether people and processes resist manipulation. Answers: how many people click, submit credentials or grant access, and does anyone report it? Output: rates per campaign and department, reporting behaviour, process gaps.

Physical security testing

Authorised attempts to reach restricted areas, devices or network ports: tailgating, badge and visitor process abuse, after-hours access, clean desk. Answers: can an outsider reach the inside, physically? Scoped under a letter of authorisation with legal review, and often combined with social engineering and red teaming.

Bug bounty and coordinated vulnerability disclosure

Inviting external researchers to report vulnerabilities, either under a public or private bounty programme with rewards or through a coordinated vulnerability disclosure (CVD) policy without them. Answers: what do many eyes find over time that a scoped test did not? Requires triage capacity and a fix process. NIS2 Article 12 and the Dutch NCSC CVD guideline frame the disclosure side.

Continuous testing: PTaaS and threat exposure management

Penetration testing as a service (PTaaS) delivers testing in shorter, recurring cycles through a platform with live findings. Threat exposure management (TEM, Gartner's CTEM) continuously discovers assets, validates exposures and prioritises what to fix. Answers: what changed since the last test, and what is exploitable today? Complements rather than replaces point-in-time depth.

Security testing types compared

Goal, depth, frequency, who performs it, what you receive and where it counts for compliance.

Type	Goal	Depth	Frequency	Who performs	Output	Compliance fit
Vulnerability scanning	Find known weaknesses across the estate	Broad and shallow; no exploitation	Weekly to continuous; after changes	Internal IT or security team, MSSP, scanning platform	Prioritised list with CVSS, needs triage	PCI DSS 11.3 (quarterly internal and external, ASV); ISO 27001 A.8.8; DORA Art. 25
Penetration testing	Prove what a skilled attacker can do in scope	Deep on the defined scope; manual exploitation and chaining	Annually and after significant change; per release for critical apps	Certified external testers (OSCP, OSWE, CREST)	Evidence-backed findings, attack narrative, retest	PCI DSS 11.4; DORA Art. 25; ISO 27001 A.8.8 and A.8.29; NIS2 Art. 21(2)(f); 23 NYCRR 500.5; GLBA 314.4(d)(2)
Red teaming	Test detection and response against a realistic adversary	Deep and narrow: objective-driven, covert	Every one to two years once pentesting is mature	Specialist external red team	Attack timeline, detection gaps, response assessment	DORA Art. 26 and 27 TLPT (TIBER-EU); CBEST in the UK; not mandated elsewhere
Purple teaming	Improve detection coverage per technique	Technique-level, collaborative	Quarterly, or after each red team	Red team plus your SOC or MDR provider	ATT&CK detection matrix, tuned rules	Supports NIS2 Art. 21(2)(b) incident handling; no direct mandate
Code review, SAST, DAST, SCA	Find defects in code and dependencies before release	Deep on code; automated plus manual for critical modules	Every build (automated); manual at major releases	Development and application security teams, external reviewers	Defect list per build, dependency inventory, SBOM	PCI DSS 6.2.3 and 6.3.2; DORA Art. 25 source code review; ISO 27001 A.8.28 and A.8.29; NIST SP 800-218 (SSDF)
Configuration and cloud posture review	Verify hardening against benchmarks	Broad across accounts and hosts; no exploitation	Continuous (CSPM) plus annual expert review	Cloud and platform teams, external reviewers	Deviations from CIS Benchmarks, IAM findings	ISO 27001 A.8.9; PCI DSS 2.2; CIS Controls v8
Social engineering testing	Measure human and process resistance	Behavioural; campaign-based	Monthly to quarterly phishing; annual multi-channel	External specialists with HR and legal sign-off	Click, submit and report rates; process gaps	NIS2 Art. 21(2)(g) cyber hygiene and training; PCI DSS 12.6; ISO 27001 A.6.3
Physical security testing	Test physical access controls and visitor processes	Site-specific; scenario-based	Annually, or per site change	Specialist red team under a letter of authorisation	Entry narrative, control failures, photographic evidence	ISO 27001 A.7 physical controls; DORA Art. 25 physical security reviews
Bug bounty and CVD	Harness external researchers over time	Unbounded in time, variable in depth	Always on	External researchers; your triage team	Reports, triage decisions, fix evidence	NIS2 Art. 12 CVD; ISO/IEC 29147 and 30111
Continuous testing (PTaaS, TEM)	Keep exposure current between deep tests	Medium; recurring validation	Continuous, with monthly or quarterly cycles	Testing provider plus platform	Live findings dashboard, exposure trend	Supports the DORA Art. 24 programme and NIS2 Art. 21(2)(f); evidence of ongoing assessment

The maturity ladder: which tests at which stage

Add disciplines in the order that makes each next one meaningful. Skipping rungs produces expensive reports about problems a simpler test would have found.

Stage 1, foundation: know what you have and fix the known

You need an asset inventory, authenticated vulnerability scanning across it, a patch cadence, and a configuration baseline (CIS Benchmarks) for servers, endpoints and cloud accounts. Add one penetration test per year on the systems that hold your most sensitive data: grey box, external and authenticated. The signal that this stage is complete: scan results stop surprising you and critical patches close within your own deadline.

Stage 2, assurance: test what you build and what you buy

Move testing into the development lifecycle: SCA and SAST on every build, DAST on the staging environment, manual code review for authentication, payment and cryptographic modules. Extend penetration testing to every internet-facing application and API at each major release, and run an internal assumed-breach test annually. Start social engineering testing with a baseline phishing campaign and a reporting channel. Continuous cloud posture monitoring replaces the annual configuration review.

Stage 3, resilience: test whether you would notice

With a SOC or MDR service in place, add purple teaming to tune detection for the techniques most relevant to your sector, then a red team engagement to test the whole chain covertly. Publish a coordinated vulnerability disclosure policy, and open a private bug bounty if you have the triage capacity. Move recurring application testing to a PTaaS model so findings arrive between annual cycles. Physical testing joins the programme for sites that house critical systems.

Stage 4, continuous validation: measure exposure as a metric

Threat exposure management ties asset discovery, validation and prioritisation into one loop that reports exposure over time to the board. Regulator-coordinated threat-led testing (TIBER-EU, DORA TLPT) applies to designated financial entities every three years. Red teaming becomes periodic, purple teaming routine, and penetration testing remains the depth instrument for every new system and major change.

An annual security testing programme: worked example

A mid-sized organisation with a customer-facing SaaS platform, a corporate network of around 800 users, two cloud accounts and a SOC provided by an MDR partner, moving from stage 2 into stage 3. What twelve months look like.

Continuous: authenticated vulnerability scanning of all hosts weekly, cloud posture monitoring daily, SCA and SAST on every build, DAST on every staging deployment, a published coordinated vulnerability disclosure policy with a monitored inbox
Monthly: phishing simulation rotating departments and pretexts, with report rates tracked alongside click rates
Q1: external perimeter penetration test plus a cloud configuration review of both accounts by an external tester; findings feed the Q1 remediation and retest window
Q2: grey box penetration test of the SaaS platform and its API per role, aligned with the spring major release; manual code review of the authentication and billing modules; verification retest within 90 days
Q3: internal assumed-breach penetration test from a standard workstation with Active Directory and segmentation focus; purple team exercise with the MDR partner on the ten techniques most seen in your sector's incident reports
Q4: multi-channel social engineering test (vishing and physical tailgating at the main site) under a letter of authorisation; tabletop exercise with management built on the Q3 findings; programme review and next year's plan
Every second year, in place of the Q3 purple team: a covert red team engagement with objectives set by the board, followed by a purple team debrief that converts its findings into detections
Evidence folder maintained for auditors: scope statements, reports, retest confirmations and remediation tickets mapped to ISO 27001 A.8.8 and A.8.29, NIS2 Article 21(2)(f) and the sector rules that apply

How the types combine, and where programmes go wrong

The disciplines are complementary because each covers the blind spot of another. Scanning is broad and continuous but blind to logic flaws and chained attacks. Penetration testing finds those, but only in scope and at a point in time. Red teaming shows whether the chain would be noticed but says little about the long tail of vulnerabilities. Code review finds defects before deployment but not configuration drift in production. Bug bounties find the unexpected over time but cannot be scheduled for an audit. A programme is the arrangement of these so that the gaps do not line up.

Four failure patterns recur. First, a vulnerability scan report presented as a penetration test: no exploitation, no chaining, no business-logic coverage, and an auditor who rejects it under PCI DSS Requirement 11.4 or asks for the tester's qualifications. Second, a red team ordered before any penetration testing has been done: the red team walks in through a flaw a grey box test would have found on day one, and the expensive lesson is about basics rather than detection. Third, code review treated as a substitute for testing the running system: the code may be clean while the load balancer, identity provider or cloud role is not. Fourth, a bug bounty launched without triage capacity: researchers submit, nobody responds, and the programme becomes a reputational liability rather than an asset.

The order matters less than the questions. If you cannot say what you have, scan. If you do not know what an attacker could do with it, test. If you do not know whether you would notice, simulate. If you want to know what changed since last quarter, test continuously.

Where penetration testing sits, and how HackersHub supports the programme

Penetration testing is the depth instrument of the programme: the discipline that converts a list of weaknesses into proof of impact, and the evidence most frameworks ask for by name. HackersHub delivers it across network, web application, API, mobile, cloud and hardware targets, in black, grey or white box, following PTES, OWASP WSTG and MASTG and NIST SP 800-115. Every report contains an executive summary, CVSS-scored findings with evidence, an attack narrative and prioritised remediation, and a verification retest of medium and higher findings within 90 days is included.

Around the penetration test we deliver the disciplines that need an offensive team: red teaming and adversary simulation, purple teaming with your SOC or MDR partner, social engineering testing (phishing, vishing, physical), and threat exposure management for organisations that want exposure measured continuously. Vulnerability scanning is delivered as a managed service. Every tester holds at least OSCP, and OSWE and CREST-certified testers lead application and red team work. Lead tester Michael van Mameren reviews every scope. HackersHub has delivered offensive security from Amsterdam for more than ten years and is rated 4.9/5 across 127 reviews.

Frequently asked questions

Related guides and services

Building a security testing programme?

A short scoping conversation establishes where you are on the ladder, which frameworks you report to and what to test first. You receive a written annual plan and a scoped proposal for the penetration testing within it. Talk to an expert.

Scope a penetration test Talk to an expert