Glossary

Offensive security glossary, in plain language

The terms that appear in our scopes, reports and retests, defined plainly. Each entry has its own anchor, so you can send a colleague straight to the definition they need.

Testing types

Penetration test

A time-boxed, authorised attempt to break into a system so the weaknesses are found before an attacker finds them.

A tester works through a defined scope using the same techniques an attacker would use, then proves impact rather than flagging possibilities. The value lies in the chaining: three low-risk issues that together expose customer data matter more than a long list of isolated findings. The output is a report with reproducible evidence, a severity for each issue and fixes an engineer can act on. Scope, timing and authorisation are agreed in writing before any testing starts.Read more →

Red team

A goal-driven simulation of a real attacker, run quietly to test whether your defenders notice and respond.

Instead of enumerating vulnerabilities, a red team picks objectives such as reaching a payment system or extracting a sample of sensitive data, then takes any in-scope route to get there. Stealth matters, so the team paces activity to avoid detection and records which actions did and did not raise an alert. Only a small control group inside the organisation knows the exercise is running. The result measures detection and response, not just exposure.Read more →

Purple team

An exercise where the attacking and defending teams work together in the open to improve detection.

Rather than hiding activity, the offensive side executes known techniques one at a time while the defenders watch their own tooling to see what fires, what is logged and what is missed. Each gap is tuned on the spot and the technique is replayed to confirm the new detection works. It is faster and cheaper than a covert red team for building coverage, but it does not test whether an unannounced intrusion would be caught.Read more →

Vulnerability assessment

A broad, largely automated sweep that identifies and prioritises known weaknesses across an estate.

Authenticated and unauthenticated scanners enumerate hosts, services, patch levels and configuration weaknesses, and a tester then removes false positives and ranks what remains by real exposure. It gives wide coverage cheaply and suits regular hygiene checks across large estates. It will not find business-logic flaws, chained attack paths or anything that needs human reasoning, so it complements rather than replaces a penetration test.Read more →

Threat-led penetration testing

A penetration test shaped by intelligence on the attackers who actually target your sector.

Threat intelligence is gathered first to establish who is likely to attack the organisation and how, and that picture drives the scenarios tested against live production systems. It is the model behind TIBER-EU and the DORA testing obligation for significant financial entities, where testing must cover critical functions in production. Because it runs against live systems it needs explicit authorisation, close risk management and a named control team on the client side.Read more →

Assumed breach

Testing that starts from a position an attacker already has, such as one ordinary user account or laptop.

Rather than spending the engagement on the perimeter, the tester is given a low-privilege foothold and asked how far it reaches. This reflects reality, because phishing and credential reuse mean initial access is the cheap part for an attacker. The useful output is a blast radius: what one compromised employee can read, change or escalate to, and which control would have stopped the next step.Read more →

Phishing simulation

A controlled phishing campaign sent to your own staff to measure click rates and reporting behaviour.

Messages are sent from infrastructure controlled by the testers, with tracked links or credential-capture pages, and the campaign records who opened, who clicked, who submitted data and who reported it. The reporting rate is the more useful figure, because it shows whether the organisation has a working path to raise an alarm. A simulation is narrower than full social engineering and does not test voice, physical or multi-step pretexts.Read more →

Segmentation testing

Testing that checks whether network boundaries really stop traffic between the zones they are meant to separate.

The tester places a host in one zone and attempts to reach services in another, enumerating what actually routes rather than what the rule base claims. Common results are forgotten management interfaces, overly broad permit-any rules and shared infrastructure that quietly bridges zones. PCI DSS requires this at defined intervals for entities that use segmentation to reduce the scope of their cardholder data environment, because a failed boundary pulls the adjacent zone back into scope.Read more →

Retest

A focused second round of testing that confirms whether the fixes actually closed the original findings.

Each finding is reproduced using the same steps as the original test, and the outcome is recorded as fixed, partially fixed or still present. Partial fixes are common, usually because a single input was patched while the underlying pattern remains in other endpoints. Without a retest a report records intent rather than outcome, and auditors generally want evidence that high-severity items were verified as closed.Read more →

Penetration testing as a service

A vendor term for subscription testing delivered through a portal, with findings appearing continuously rather than in one report.

The label is vendor-coined and has no agreed definition, so what it covers ranges from a scanner with a dashboard to genuine manual testing delivered on a rolling basis. The questions that resolve it are how many hours of human testing the subscription actually buys, who performs them, and whether the platform output would satisfy an auditor. Treat the portal as a delivery mechanism rather than as evidence of depth.Read more →

Attack techniques

Kerberoasting

Requesting a Kerberos ticket for a service account and cracking it offline to recover that account's password.

Any authenticated domain user can ask a domain controller for a service ticket for an account that carries a service principal name, and part of that ticket is encrypted with a key derived from the account's password. The attacker takes it away and cracks it offline, so there are no failed logons and no lockouts to alert anyone. Service accounts are the usual target because their passwords are often old, human-chosen and over-privileged. Defences are long random passwords or group managed service accounts, removing unnecessary service principal names, and alerting on unusual service-ticket requests.Read more →

AS-REP roasting

Harvesting crackable material for accounts that have Kerberos pre-authentication turned off, without needing any credentials.

When an account does not require pre-authentication, a domain controller returns an encrypted response to anyone who asks for it, and that response can be cracked offline to recover the password. Unlike Kerberoasting it needs no valid domain account, only a username, so it is reachable from an unauthenticated position on the network. The fix is to find and clear the do-not-require-pre-authentication flag wherever legacy compatibility no longer justifies it, and to give any account that must keep it a password that will not fall to cracking.Read more →

NTLM relay

Forwarding a captured Windows authentication attempt to another service so the attacker is authenticated as that user.

The attacker never learns the password; they coerce or capture an authentication handshake and relay it to a target that will accept it, commonly an LDAP interface, a file share or a certificate service. Relaying to Active Directory Certificate Services is particularly damaging, because it can yield a certificate that authenticates as a privileged account. Mitigations are signing and channel binding on LDAP and SMB, disabling NTLM where it is no longer needed, and hardening certificate enrolment endpoints.Read more →

Pass-the-hash

Authenticating to a Windows system using a stolen password hash instead of the password itself.

NTLM authentication accepts the hash as the secret, so an attacker who extracts it from memory or a credential store can log on without ever cracking it. This turns one compromised machine into access to every other machine that shares the same local administrator password or holds a privileged session. Defences are unique local administrator passwords, tiered administration so privileged credentials never touch ordinary workstations, and credential protections that keep secrets out of reachable memory.Read more →

Password spraying

Trying one or two likely passwords against many accounts, slowly enough to avoid triggering lockouts.

Because the attempts are spread across accounts rather than concentrated on one, per-account lockout thresholds are never reached and the activity looks like background noise. Predictable seasonal and company-themed passwords mean a single guess often succeeds somewhere in a large directory. Detection needs correlation across accounts rather than per-account counters, and the structural fixes are phishing-resistant multi-factor authentication, banned-password lists and conditional access on legacy protocols that bypass it.Read more →

Credential stuffing

Replaying username and password pairs leaked from other breaches against your login pages at scale.

The attacker relies on password reuse, so no guessing is involved and the success rate is low per attempt but meaningful across millions of attempts. Traffic typically arrives through residential proxy pools, which defeats simple rate limiting based on address. Useful controls are multi-factor authentication, checking credentials against known-breached lists at sign-in, device and behavioural signals, and monitoring for a rise in failed logons that use valid usernames.Read more →

IDOR, or broken object-level authorisation

Accessing or changing another user’s data by manipulating an object reference when the server fails to check the requested operation’s authorization.

IDOR occurs when the server accepts an object identifier without verifying that the caller may perform the requested operation on that object. Testers use accounts with different permissions and exchange object references to check reads, changes, deletion and exports. The fix is server-side authorization for every object access, often by restricting queries to the caller’s permitted dataset or using a shared authorization layer. Ownership is one possible policy; legitimate sharing and role-based access must also be considered. Unpredictable identifiers are an additional defence and do not replace access checks.Read more →

Server-side request forgery

Making a server fetch a URL of the attacker's choosing, so the requests come from inside your network.

Anywhere an application accepts a URL, a hostname or an XML reference and retrieves it, an attacker can point it at internal services that have no external exposure. In cloud environments the classic target is the instance metadata endpoint, which can return credentials for the workload's role. Blocklists of addresses are routinely bypassed with redirects and DNS tricks, so the durable fixes are an allowlist of permitted destinations, a fetch proxy with no onward network reachability, and requiring the hardened version of the metadata service.Read more →

Business-logic flaw

An abuse of the application's own rules, where every request is technically valid but the outcome is wrong.

Examples are completing a checkout after the payment step fails, applying one discount repeatedly, or moving an order backwards through a workflow to regain an editable state. Scanners cannot find these because nothing is malformed, so discovery requires understanding what the business expects to be true. The fixes belong in server-side state machines and invariant checks rather than in input validation, and the same flaw often reappears in a second channel such as a mobile API.Read more →

Privilege escalation

Moving from the access you have to more access, either as a higher-privileged user or at system level.

Vertical escalation gains more rights, horizontal escalation gains another account's data at the same level. In practice most escalation comes from configuration rather than memory-corruption exploits: writable service paths, over-permissive group membership, cached privileged credentials, permissive cloud role trust policies. Defences are least privilege reviewed regularly, separating administrative identities from day-to-day ones, and alerting on the act of granting privilege rather than only on its use.Read more →

Lateral movement

Spreading from the first compromised machine to others, usually with legitimate credentials and built-in tools.

Techniques include remote service creation, scheduled tasks, remote management interfaces and simply reusing a hash or ticket that already works elsewhere. It looks like normal administration, which is why detection depends on knowing which accounts should be logging on to which machines rather than on malware signatures. Segmentation, unique local administrator passwords and tiered administration limit how far a single foothold can reach.Read more →

Formula injection

Putting spreadsheet formulas into data fields so they execute when someone exports the data and opens it.

Also called CSV injection, it works because a value beginning with an equals sign, plus, minus or at symbol is treated as a formula by common spreadsheet applications. A field that is harmless inside the web application becomes code execution on the reviewer's workstation, which makes it an attack on the staff who handle exports rather than on the server. The fix is to escape or reject leading formula characters when generating exports, because the application that opens the file cannot be relied upon to refuse.

Prompt injection

Hiding instructions in content a language model reads, so the model follows the attacker instead of its operator.

Because models process instructions and data through the same channel, text in a web page, document, ticket or email can redirect behaviour, and the risk becomes concrete once the model holds tools, credentials or database access. The practical consequence is data exfiltration, or unintended actions taken with the application's own permissions. There is no reliable filter, so the controls are architectural: least privilege for the model's tools, human confirmation for actions with real effect, and treating all model output as untrusted input.Read more →

Infrastructure and identity

Active Directory

Microsoft's directory service, which holds the accounts, groups, computers and policies for a Windows network.

It is the authentication and authorisation backbone of most corporate networks, so the rights held inside it determine what any compromised account can reach. Risk accumulates through years of nested group membership, delegation, stale accounts and permissions granted for a project that ended long ago. Attack paths are rarely a single vulnerability; they are chains of individually reasonable permissions, which is why graph-based analysis is the standard way to review them.Read more →

Domain controller

A server that holds a copy of the directory database and answers authentication requests for the domain.

Because it stores password material for every account in the domain, administrative access to one is effectively administrative access to everything the domain protects. Attackers therefore aim at it directly, or at any path that grants directory replication rights, which allow secrets to be pulled without logging on to the server at all. Treating domain controllers as Tier 0, restricting who may administer them and monitoring replication requests are the baseline protections.Read more →

Tier 0

The set of systems and accounts that can take control of your identity infrastructure, and therefore of everything else.

It includes domain controllers, the accounts and groups that administer them, certificate authorities, identity synchronisation servers, backup systems that hold their data, and any management tooling that can deploy code to them. The point of naming the tier is to stop Tier 0 credentials ever being used on lower-tier machines, because one exposure there hands over the whole estate. Most engagements find at least one unexpected member, commonly a backup agent, a monitoring tool or a certificate template.Read more →

Active Directory Certificate Services

The Windows public key infrastructure role that issues certificates to users, computers and services inside a domain.

Certificates can be used to authenticate, so a template that lets a low-privileged user request a certificate specifying an arbitrary subject is a direct route to impersonating a privileged account. The recurring problems are weak enrolment permissions, templates that allow a requester-supplied subject name, and enrolment endpoints that accept relayed authentication. Reviews should cover every template's permissions and flags, and web enrolment endpoints should require channel binding and extended protection for authentication.Read more →

Service principal name

An identifier that links a service, such as a database or web application, to the account that runs it.

Kerberos uses it to work out which account's key should encrypt a service ticket, which is why any account carrying one can be asked for a crackable ticket by any authenticated user. Service principal names are frequently set on ordinary user accounts for convenience, then forgotten when the service is decommissioned. Inventorying them, removing those no longer in use and moving the rest to managed accounts removes most of the exposure.Read more →

Managed service account

A Windows account type whose password is generated and rotated automatically by the directory rather than by a person.

Group managed service accounts use a long random password that Active Directory changes on a schedule, which removes the human-chosen passwords that make service accounts worth cracking offline. Only hosts explicitly permitted to retrieve the password can run the service, so the account is tied to defined machines. The control that matters is who holds that retrieval permission, because holding it is equivalent to holding the account.

Delegation

A Windows feature that lets one service authenticate to another on a user's behalf.

Unconstrained delegation stores a usable ticket for every user who connects to the host, so compromising that single server can yield privileged tickets with no further attack. Constrained and resource-based constrained delegation narrow the permitted targets, but the rights to configure them are themselves a privilege-escalation path. Reviews should enumerate every delegated object, remove unconstrained delegation and mark sensitive accounts as not delegatable.

Jump host

A hardened intermediate server through which all administrative access to a sensitive zone must pass.

Also called a bastion or a privileged access workstation, its purpose is to concentrate administrative sessions somewhere monitored, patched and separated from email and web browsing. It only works if the protected zone refuses connections that do not come through it, and if the host itself is not administered from an ordinary laptop. A jump host that shares credentials with the general estate provides logging rather than security.

Segmentation

Dividing a network into zones so that a compromise in one does not reach the others.

Effective segmentation is enforced by default-deny rules between zones with explicit, documented exceptions, and it has to cover management interfaces, backup traffic and identity flows as well as application traffic. The usual failures are broad permit-any rules kept for convenience, shared services reachable from every zone, and virtual infrastructure that bridges zones below the layer the firewall sees. The only way to know it works is to test from inside each zone rather than read the rule base.Read more →

Endpoint detection and response

Agent software that records activity on a host, raises alerts on suspicious behaviour and can isolate the machine.

It goes beyond antivirus by keeping telemetry on process execution, command lines and network connections, which is what makes attacker techniques built on legitimate tools visible at all. Deployment is not the same as coverage: common gaps are agents left in audit-only mode, servers and build machines excluded, exclusion paths added to settle a performance complaint, and alerts arriving where nobody is on duty to act. A purple-team exercise is the practical way to confirm which techniques actually produce an alert someone sees.Read more →

Web and API

OWASP Top 10

A widely used awareness list of the ten most significant categories of web application security risk.

Published by the OWASP Foundation and revised every few years from vulnerability data and practitioner surveys, recent editions group issues by cause, such as broken access control or insecure design, rather than by individual bug type. It is valuable as shared vocabulary and as a sanity check on coverage. It is not a testing methodology and not a compliance standard, and an application can satisfy every category while still being compromised through logic flaws the list does not describe.Read more →

OWASP API Security Top 10

A companion list covering the risks specific to APIs rather than browser-rendered applications.

It exists because APIs fail differently: authorisation has to be checked per object and per property rather than per page, there is no user interface to hide fields behind, and resource consumption and inventory problems dominate. Broken object-level and object-property-level authorisation head the list, alongside unrestricted access to sensitive business flows and unmanaged old versions left running. Testing against it means enumerating every endpoint and version, then exercising each one with a second account's identifiers.Read more →

GraphQL introspection

A built-in GraphQL query that returns the full schema, including types, fields and available operations.

It is designed for developer tooling, but left enabled in production it hands an attacker a complete map of the API, including fields the user interface never calls. Disabling it reduces discovery convenience only, since schemas can still be recovered through field suggestions, error messages and client bundles. The real controls are authorisation on every resolver, query depth and complexity limits, and removing fields that should not be reachable rather than hiding their documentation.Read more →

Cross-origin resource sharing

A browser mechanism that lets a server declare which other origins may read its responses.

It relaxes the same-origin policy, and the dangerous combination is reflecting whatever origin asked while also allowing credentials, which lets any site read authenticated responses on behalf of a logged-in visitor. Wildcard origins, trusting any subdomain and regular expressions that match unintended hostnames are the common mistakes. Configuration should use a fixed allowlist, and it is worth remembering that this mechanism governs reading responses rather than sending requests, so it is not a defence against cross-site request forgery.Read more →

Content Security Policy

A response header that tells the browser which scripts, styles and other resources a page may load.

Its main purpose is to reduce the impact of cross-site scripting by refusing inline and unexpected scripts, typically using a per-response nonce or a hash. Policies weakened by unsafe-inline, broad wildcard sources or trusted content delivery networks that will host arbitrary scripts provide little real protection. It is a second layer of defence: output encoding and safe templating still have to fix the underlying injection.Read more →

Clickjacking

Tricking a user into clicking something in your application while they believe they are clicking elsewhere.

The attacker loads the target application in an invisible or disguised frame over their own page, so a genuine click lands on a genuine control such as a confirm or authorise button. Impact depends on what a single authenticated click can achieve, which makes approval and payment flows the usual concern. Prevention is refusing to be framed, through the frame-ancestors directive in Content Security Policy, plus an explicit in-page confirmation step for sensitive actions.Read more →

Cross-site request forgery

Making a logged-in user's browser send a state-changing request to your application without their intent.

It works because browsers attach cookies automatically, so a request issued from another site arrives fully authenticated. Defences are per-session anti-forgery tokens that the attacker's page cannot read, SameSite cookie attributes, and checking the origin of state-changing requests. An API that authenticates with a bearer token in a header rather than a cookie is not exposed in the same way, which is why the risk is often mis-assessed in mixed architectures.Read more →

OAuth 2.0 and OpenID Connect

OAuth delegates access to an application without sharing a password; OpenID Connect adds identity on top of it.

OAuth issues access tokens that say what an application may do, while OpenID Connect adds an identity token that says who the user is, and confusing the two is a frequent design error. The flaws found in practice are loose redirect URI matching, a missing state parameter, tokens accepted without audience or issuer validation, and implicit flows that place tokens in the browser address bar. Current guidance is the authorisation code flow with PKCE, exact redirect URI matching and strict validation of every token claim.Read more →

PKCE

An OAuth extension that stops a stolen authorisation code being exchanged for a token by anyone else.

Proof Key for Code Exchange has the client generate a random secret, send only its hash when starting the flow, then present the original value when redeeming the code, so a code intercepted on a mobile device or through a redirect is useless on its own. It was introduced for public clients that cannot keep a secret, such as mobile and single-page applications, and is now recommended for confidential clients too. The server has to verify the challenge and reject the plain challenge method for any of this to help.Read more →

JSON Web Token

A compact format for claims exchanged between parties, commonly protected with a signature or MAC and optionally encrypted.

JWT can use a JSON Web Signature (JWS) or JSON Web Encryption (JWE) structure. A signed but unencrypted JWT is readable by anyone holding it, so its payload should not contain secrets. Applications must validate the protection, permitted algorithms, issuer, audience and expiry before trusting the claims. Common failures include accepting unsigned tokens unexpectedly, trusting attacker-controlled algorithm or key locations, and treating tenant or role claims as sufficient authorization. Revocation requires an application mechanism, such as short lifetimes combined with a deny list or token versioning.Read more →

Multi-tenancy

One application instance serving many customers, with the boundary between their data enforced in software.

The tenant identifier has to be derived from the authenticated session on the server and applied to every query; wherever it is read from a header, a path segment or any other client-supplied field, swapping it tends to return another customer's records. Background jobs, exports, search indexes, caches, webhooks and administrative tooling are the parts that get missed, because the main request path is usually the only one reviewed. Testing it properly requires two real tenants and systematic cross-use of their identifiers.Read more →

Process and reporting

CVSS

A standard formula for scoring the technical severity of a vulnerability from zero to ten.

The Common Vulnerability Scoring System rates intrinsic characteristics such as how the issue is reached, how hard it is to exploit and what it affects, which makes scores comparable between vendors. It deliberately knows nothing about your environment, so an unauthenticated flaw in a system reachable only from one administrative subnet carries the same base score as the same flaw on the internet. Environmental and threat metrics exist to adjust for that but are often left unused, which is why a base score should inform priority rather than set it.Read more →

CVE

A unique public identifier for one specific, publicly disclosed vulnerability in a product.

Common Vulnerabilities and Exposures gives everyone a shared reference, so a patch note, a scanner result and an advisory can be matched reliably. An identifier describes the flaw, not your exposure: whether the vulnerable code path is reachable, whether the feature is enabled and whether a compensating control blocks it all change the answer. Confirming or ruling out a scanner's assumption about a given identifier is often worth more than the finding itself.Read more →

CWE

A catalogue of software weakness types, describing the underlying class of mistake rather than a specific product bug.

Common Weakness Enumeration names the pattern, for example improper neutralisation of input or missing authorisation, which is what makes it useful for spotting themes across a report. Where a CVE says which product is affected, a CWE says what went wrong, so mapping findings to it shows whether an organisation has one bad endpoint or a recurring development habit. It is the right level of abstraction for deciding what to change in training, shared libraries and code review.

EPSS

A score estimating the probability that a given vulnerability will be exploited in the wild in the next thirty days.

The Exploit Prediction Scoring System is a data-driven model maintained as a community effort, and it is intended to complement severity rather than replace it. Combining a high severity score with a low exploitation probability and knowledge of your own exposure usually produces a much shorter urgent list than severity alone. It is probabilistic and updated continuously, so it informs the sequence of patching rather than whether a weakness needs fixing at all.

Rules of engagement

The written agreement setting out what testers may do, when, from where, and with whom they communicate.

It covers in-scope targets and excluded systems, permitted techniques, testing windows, source addresses, data-handling rules, evidence retention and the escalation path if something breaks or a live intrusion is discovered. It is the document that separates authorised testing from an offence, and it protects both sides when a test has unexpected effects. Any change during the engagement, such as adding a host or allowing a riskier technique, belongs in writing rather than in a conversation.

Scope

The explicit list of systems, applications, accounts and techniques an engagement is authorised to cover.

Good scope is defined by the question that needs answering rather than by what is easy to list, and it records exclusions as precisely as inclusions, including third-party hosted components whose provider must also consent. Scope drawn too narrowly produces a clean report that proves little, because the real path runs through the system left out. It should be revisited once reconnaissance shows what is actually exposed, with any change agreed in writing.

Control team

The small group inside the client organisation that knows a covert exercise is running and manages it.

In red team and threat-led testing this team holds the authorisation, keeps the scenario from the defenders, tracks progress and can stop the exercise at any point. They also decide when to tell the security operations team that an alert came from the test rather than a real intrusion, which prevents wasted incident response. Under TIBER-EU and the DORA testing regime the role is formalised, with named individuals and defined responsibilities for risk management throughout.Read more →

Attack narrative

The part of a report that tells the story of how the tester got from the starting point to the impact.

Instead of listing findings separately, it sets out the chain in order, showing which low-severity issue enabled the next step and where a control would have broken the path. It is what makes a report usable by people who are not security specialists, because it shows consequence rather than category. It also tends to reveal which finding is worth fixing first, and that is often not the one with the highest individual score.Read more →

Remediation

The work of fixing what a test found, and the tracking that confirms it was actually done.

Useful remediation advice names the specific change rather than the principle, distinguishes the immediate fix from the systemic one, and says which other places share the same pattern. Fixes also decay: endpoints added later reintroduce the flaw, configuration drifts back, and a library pinned during remediation goes stale. Treating remediation as owned work with dates and a verifying retest is what separates a closed finding from a documented one.Read more →

Responsible disclosure

Reporting a vulnerability to the party that can fix it, and withholding details until a fix is available.

Also described as coordinated vulnerability disclosure, it normally involves a private report, an agreed timeline, a fix and then public detail so that others can protect themselves. Timelines are a judgement between giving a vendor time to work and leaving users exposed, and the conversation goes better when the vendor publishes a security contact and a policy stating that researchers acting in good faith will not be pursued. On client engagements, anything found in third-party software is reported through that vendor's process rather than published.Read more →

Closure letter

A short signed document stating that findings from a test were retested and confirmed as resolved.

It records which findings were verified, on what date, by whom and with what outcome, and it is usually what an auditor, a customer or an insurer wants to see rather than the full technical report. It only means something if it rests on an actual retest, and it should be explicit about anything that remains open or was formally accepted as a risk. Keeping it separate from the main report also allows it to be shared without disclosing exploitation detail.

Evidence

The recorded proof that a finding is real and can be reproduced by someone else.

Strong evidence is a minimal set of steps, the request and response or the command and its output, a timestamp, and enough context for an engineer to reproduce the result on their own system. It should demonstrate the issue without being a ready-made attack tool, and anything containing real personal or customer data needs redaction and controlled handling. Reproducibility is the dividing line between a finding and an assertion, and it is also what makes a later retest meaningful.

Compliance

DORA

The EU Digital Operational Resilience Act, which sets ICT risk rules for financial entities and their critical suppliers.

It has applied since January 2025 and covers ICT risk management, incident reporting, digital operational resilience testing, third-party risk and information sharing. Testing obligations are tiered: all in-scope entities must run a programme of resilience testing, while entities identified as significant must additionally undergo threat-led penetration testing at least every three years. Designation and supervision sit with national competent authorities, so the practical requirements depend on the regulator as well as on the regulation.Read more →

TLPT

Threat-led penetration testing: intelligence-driven testing of live production systems, required of significant financial entities under DORA.

The engagement opens with a threat intelligence phase that establishes realistic adversaries and scenarios, and those scenarios then drive a red team phase against production systems supporting critical or important functions. It must cover several such functions, involve the relevant third-party providers where those functions depend on them, and be run by testers meeting the requirements set out in the regulation. The authority reviews the documentation and issues an attestation, so the process and its records matter as much as the technical result.Read more →

TIBER-EU

The European framework for intelligence-led red team testing of financial institutions, and the model DORA's regime is built on.

Threat Intelligence-based Ethical Red Teaming sets out the phases of an exercise, the roles involved and the deliverables, running from preparation through threat intelligence and red teaming to closure, with the authority acting as an observer. Its purpose is controlled testing against live systems with consistent documentation across jurisdictions. Several national variants exist, and the DORA threat-led penetration testing requirements were designed to align with it rather than to replace it.Read more →

NIS2

The EU directive raising cybersecurity requirements across essential and important entities in many sectors.

It widened the sectors in scope compared with the original directive, introduced management accountability, set incident reporting deadlines including an early warning within twenty-four hours, and requires risk-management measures that explicitly include testing and vulnerability handling. Because it is a directive, the binding obligations come from each member state's implementing law, and transposition has been uneven, so the applicable detail depends on jurisdiction. It does not prescribe a testing frequency, which means entities have to justify the programme they choose.Read more →

PCI DSS

The payment card industry's security standard for organisations that store, process or transmit cardholder data.

Version 4.0 and its 4.0.1 revision are the current releases, structured around twelve requirements and allowing either a defined or a customised implementation of each control. It is unusually prescriptive about testing: external and internal penetration testing at least annually and after significant change, segmentation testing for entities that rely on segmentation to reduce scope, and quarterly vulnerability scanning. How compliance is validated depends on the merchant or service provider level, through a self-assessment questionnaire or a formal assessment.Read more →

ISO 27001

An international standard for an information security management system, certifiable by an accredited body.

The 2022 revision certifies the management system rather than a fixed control set: the organisation defines its scope, assesses risk and justifies which of the Annex A controls apply and which do not. Certification involves an initial two-stage audit followed by surveillance audits and recertification on a three-year cycle. Technical testing is not mandated by name, but the Annex A controls on technical vulnerability management and secure development mean most certified organisations use penetration testing as the evidence that those controls work.Read more →

SOC 2

An attestation report, produced by an accredited accounting firm, on a service organisation's controls.

It is a report rather than a certificate: Type 1 covers whether controls were suitably designed at a point in time, while Type 2 covers whether they operated effectively across a period, usually three to twelve months. Scope is set by the organisation's choice of Trust Services Criteria, and the substance lies in the auditor's opinion and the list of exceptions. Penetration testing is not named as a requirement, but auditors commonly accept it as evidence for the criteria on vulnerability identification and change management.Read more →

Trust Services Criteria

The five control categories a SOC 2 report can be scoped against, of which security is always included.

Security, formally the common criteria, is mandatory, while availability, processing integrity, confidentiality and privacy are optional additions chosen according to what the service promises its customers. Each criterion has points of focus that guide the auditor rather than mandate specific technology, which is why two reports with the same scope can rest on very different controls. Checking which criteria were in scope is the first thing to do with any SOC 2 report.Read more →

Qualified Security Assessor

A company and individual certified by the PCI Security Standards Council to assess compliance with PCI DSS.

Qualified Security Assessors perform formal assessments and sign the Report on Compliance that larger merchants and service providers require, and they may also review a self-assessment questionnaire. The council maintains the list of qualified companies and requires annual requalification. An assessor can accept penetration testing performed either by an independent internal team or by a third party, provided the tester is organisationally separate from the people who built and run the systems in scope.Read more →

Approved Scanning Vendor

An organisation authorised to run the external vulnerability scans that PCI DSS requires every quarter.

Approved Scanning Vendors are validated by the PCI Security Standards Council and must produce a passing scan report against the entity's external addresses at least quarterly and after significant change. The scan is automated and checks for known vulnerabilities and insecure configurations; it is explicitly not a penetration test and does not satisfy the separate annual testing requirement. Failing items have to be fixed and the scan rerun until it passes.Read more →

Want this explained against your own estate?

Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.

Request a proposal [email protected]

Confidential from the first conversation

We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.

How we protect your information · Privacy policy