Penetration testing

Cybersecurity for complex IT and OT environments

Senior specialists, strengthened by AI

Introduction

Intake and objective

Rules of engagement

Scope and planning

Preparation

Setup and briefing

Testing

On site or remote

Reporting

Executive and technical findings

Retest

Validation of remediation

What is a penetration test?

A pentest, or penetration test in full, is a controlled security assessment in which specialists carry out realistic attack techniques within an agreed scope and predefined rules of engagement. A good pentest shows which vulnerabilities can actually be exploited, which attack paths follow from them and how far an attacker can progress within the scope. The result is a substantiated picture of where security controls fall short and which risks are demonstrably present.

Make vulnerabilities visible

Our penetration tests start with automated tooling, which identifies and maps known vulnerabilities, internet-facing services, and configuration errors. The real work then begins, as we manually verify, as a real attacker would, whether those findings can be exploited or combined to breach security boundaries. Systems, identities, permissions, configurations, and business logic are assessed as one cohesive environment. We support each finding with technical evidence of feasibility, impact, and likelihood. This is supplemented with a technical description of how the finding can best be mitigated. Findings are classified according to the CVSS standard, from critical to informational. This allows measures to be focused on the attack paths that pose the greatest risk.

DeepBlue is CCV Pentest certified

Validate security under realistic attack conditions

A penetration test must establish what can actually be exploited. Applications, APIs, cloud platforms, internal networks, external infrastructure, identity environments, OT systems and mobile applications are assessed from the perspective of a capable attacker. Testing remains controlled through predefined rules of engagement, escalation procedures and technical boundaries.

The assessment shows which weaknesses can be used to gain access, escalate privileges, cross trust boundaries or reach sensitive systems and data. It also shows how individual findings can be combined into a viable attack path. This provides evidence of the potential impact on operational continuity, information security and critical business processes.

The increasing use of AI in software development, cloud engineering and automation adds another layer of risk. AI can accelerate delivery, but it does not understand security architecture, operational dependencies or business context unless these are explicitly defined. This can lead to insecure design decisions, excessive permissions, missing validation and security controls that are weakened or bypassed.

Executive stakeholders receive a clear assessment of impact, likelihood and remediation priority. Technical teams receive reproducible findings, evidence of exploitability and concrete remediation guidance. Findings are scored using the CVSS method and interpreted within the technical and operational context of the environment.

Periodic penetration testing supports assurance under frameworks such as NIS2, DORA, ISO 27001 and sector-specific standards. It does not demonstrate compliance by itself. It provides independent technical evidence that security controls remain effective under realistic attack conditions.

DeepBlue Azure pentest

Attack surfaces we test

Every environment presents a different attack surface, trust model and operational risk. The scope and test approach are therefore based on the technologies in use, the relevant threat scenarios and the security controls that must be validated. Testing is led manually and supported by specialist tooling where this improves discovery, coverage or technical analysis. The objective is not to complete a standard checklist. It is to identify vulnerabilities, logic flaws and connected attack paths that could provide access to systems, identities, sensitive data or critical processes.

OWASP · REST · GraphQL

Web applications & APIs

Web applications and APIs often provide the shortest route to business data and critical functionality. Testing covers authentication, authorisation, session management, input handling, file processing, API security and business logic. Specific attention is given to weaknesses that cross user roles, tenants, workflows or trust boundaries.

Attack method

Account takeover, broken access control, Object Level Authorizations, IDOR, SSRF, injection or abuse of application logic to access restricted data and functionality.

Tools, techniques and procedures

Burp Suite Pro

Caido

Postman

GraphQL Voyager

jwt_tool

Custom scripting

Microsoft Entra · AWS · Google Cloud

Cloud environments

Cloud attack paths commonly originate from excessive permissions, exposed services, leaked secrets and unintended trust relationships. Testing covers IAM, storage, workloads, service principals, roles, network controls and hybrid integrations. Permissions are analysed as connected paths rather than isolated configuration settings.

Attack method

Credential or token compromise, resource enumeration, role chaining, privilege escalation and unauthorised access to cloud workloads or sensitive data.

Tools, techniques and procedures

ScoutSuite

Custom Tooling

CloudFox

Prowler

Trufflehog

Steampipe

Active Directory · Kerberos · AD CS

Internal networks

Internal network testing establishes how far an attacker can progress from a workstation, user account, server or assumed foothold. Active Directory, administrative interfaces, network segmentation, certificate services, trust relationships and backup infrastructure receive specific attention.

Attack method

Credential interception, password reuse, SMB relay, Kerberos abuse, AD CS exploitation, lateral movement and escalation towards domain-level control.

Tools, techniques and procedures

BloodHound

Impacket

Certipy

NetExec

Responder

Rubeus

Recon · Edge

External infrastructure

Internet-facing infrastructure changes as domains, systems, cloud services and third-party platforms are introduced or retired. Testing maps exposed assets, services, subdomains, edge devices and remote-access interfaces. Potential weaknesses are manually validated before they are reported.

Attack method

OSINT and attack-surface discovery identify forgotten assets, vulnerable edge systems or exposed administration services that provide an initial foothold.

Tools, techniques and procedures

Amass

Subfinder

Nuclei

Nmap

Shodan

Censys

Microsoft Entra ID · Active Directory · Okta

Identity & Access

Identity platforms form a primary security boundary in modern environments. Testing covers authentication, federation, MFA enforcement, Conditional Access, device trust, application consent, privileged roles and administrative workflows. The assessment traces how identities, tokens and permissions can be combined into broader attack paths.

Attack method

Credential theft, token replay, device-code phishing, OAuth consent abuse, Conditional Access bypass and privilege escalation towards tenant or domain admin.

Tools, techniques and procedures

ROADTools

Bloodhound

Custom Tooling

IEC 62443 · ICS · SCADA

OT environments

OT environments require a controlled test approach that accounts for process availability, equipment behaviour and physical safety. Assessments focus on the IT-to-OT boundary, zones and conduits, remote access, engineering workstations, industrial protocols and communication between Purdue levels.

Attack method

Compromise of corporate IT, movement through shared services or remote-access infrastructure and unauthorised communication with engineering stations, HMIs, PLCs or SCADA systems.

Tools, techniques and procedures

Wireshark

Zeek

OT NSE-scripts

OPC UA-tooling

Modbus-tooling

Passive asset discovery

iOS · Android · Thick Client

Mobile & Client Applications

Mobile and desktop applications can expose sensitive logic, credentials, tokens and direct interfaces to backend services. Testing covers local storage, authentication, transport security, inter-process communication, reverse engineering, client-side controls and server-side integrations.

Attack method

Reverse engineering, token extraction, certificate-pinning bypass, hardcoded secrets or abuse of backend interfaces leading to account or data compromise.

Tools, techniques and procedures

Frida

MobSF

jadx

Ghidra

dnSpy

Sectors we test

Every sector has its own threat model, operational dependencies and regulatory context. A penetration test must therefore reflect the systems that matter, the attack paths that are realistic and the consequences of compromise within that environment. The scope, test method and rules of engagement are adapted to the sector. This ensures that testing remains technically relevant, operationally controlled and aligned with the security requirements that apply.

NEN 7510 · NIS2 · NEN 7512

Healthcare

Healthcare environments combine electronic health records, medical devices, diagnostic systems, identity platforms and external care integrations. Testing focuses on attack paths that could affect patient safety, confidentiality or continuity of care. Access control, segmentation, medical IoT, privileged access and system integrations receive specific attention.

Attack method

Phishing healthcare staff, accessing healthcare systems, moving laterally through the environment and gaining unauthorised access to patient data or medical devices.

View sector →

DORA · TLPT / TIBER-EU · SWIFT CSP · PCI DSS

Financial Services

Financial institutions depend on the integrity and availability of payment systems, customer portals, APIs, identity services and third-party connections. Testing focuses on fraud scenarios, account takeover, transaction manipulation, privileged access and compromise of critical financial processes.

Attack method

Targeted credential compromise, account takeover, privilege escalation and access to transaction systems, followed by manipulation of financial processes or data.

View sector →

BIO2 · ABDO · NIS2 · ISO 27001

Defence & Government

Government and defence environments contain sensitive information, public services, mission systems and complex supply-chain dependencies. Testing is performed within formal rules of engagement and with strict control over access, evidence handling and operational risk. Scopes may include public-facing platforms, internal networks, secure environments and critical IT or OT systems.

Attack method

Compromise of a public-facing system or external identity, followed by lateral movement and access to sensitive information, administrative systems or mission-supporting infrastructure.

View sector →

IEC 62443 · NIS2 · ISO 27001 · Cyber Resilience Act

Manufacturing

Manufacturing environments combine industrial automation, corporate IT, intellectual property and time-critical production. Testing focuses on IT-to-OT attack paths, remote access, engineering workstations, industrial networks and production management systems. Non-disruptive methods are applied where process availability and safety impose strict limits.

Attack method

Compromise of the corporate environment, movement through shared services or remote-access infrastructure and unauthorised interaction with engineering systems, HMIs, PLCs or production platforms.

View sector →

IEC 62443 · NIS2 · ISO 27019 · CER Directive

Energy & Critical Infrastructure

Energy and critical infrastructure rely on distributed operational systems, remote sites and continuous process control. Testing focuses on segmentation, remote access, industrial communication, management environments and the interfaces between IT and OT. The rules of engagement account for high availability requirements and possible physical consequences.

Attack method

Access through a supplier, remote location or corporate environment, followed by movement towards operational systems and manipulation of monitoring, control or safety-related processes.

View sector →

NIS2 · ISO 27001

Logistics & Transport

Logistics and transport depend on planning systems, warehouse automation, fleet technology, tracking platforms and integrations with external partners. Testing focuses on identities, customer and partner portals, operational data, segmentation and supply-chain access. Integrity and availability receive the same attention as confidentiality.

Attack method

Compromise through a portal, supplier or partner account, followed by manipulation of scheduling, tracking or cargo information and disruption of operational processes.

View sector →

ISO 27001 · SOC 2 · NIS2 · OWASP ASVS

IT & Technology

Technology providers operate multi-tenant platforms, cloud infrastructure, APIs, CI/CD pipelines and privileged management systems. A single compromise may affect multiple customers or downstream organisations. Testing focuses on tenant isolation, privilege boundaries, software supply-chain risk, administrative access and platform resilience.

Attack method

Compromise of an administrative interface, CI/CD identity or tenant boundary, followed by access to customer data, production infrastructure or shared platform services.

View sector →

Penetration test models and depth

The assessment methodology determines the starting position of a penetration test and reflects the attack scenario that is being simulated. The amount of information available to the testers influences the realism, technical depth and coverage of the assessment. Selecting the appropriate methodology ensures the assessment aligns with the objectives of the engagement and the systems being assessed.

Different assessment objectives require different levels of access and technical context. Some engagements focus on identifying opportunities available to an external attacker, while others validate security controls, authenticated functionality or the resilience of critical systems after initial access has been obtained. The chosen methodology should support those objectives rather than follow a fixed approach.

For most enterprise environments, a Grey Box assessment provides the best balance between realistic attack simulation, technical validation and assessment efficiency. It allows greater focus on authenticated attack paths, privilege boundaries and security controls while preserving a realistic attacker perspective. As a result, it is the methodology we recommend for most penetration tests.

The following assessment models are available depending on the objectives, scope and required level of assurance.

Black box

Testing begins without credentials, documentation or architectural context. The assessment establishes what an unknown external attacker can discover and exploit from publicly accessible systems. It provides insight into external exposure, initial-access routes and weaknesses visible from outside the environment.

View black box penetration test →

Grey box

Testing is performed with limited context, such as user accounts, defined roles, network access or selected architecture information. This allows deeper testing of authenticated functionality, privilege boundaries and internal attack paths while retaining a realistic attacker perspective. Grey box is generally the most effective model for web applications, cloud platforms, identity environments and internal networks.

View grey box penetration test →

White box

Testing is performed with extensive technical context, including source code, configurations, architecture documentation and privileged accounts where relevant. This model provides the greatest technical coverage and supports detailed analysis of design decisions, trust boundaries, implementation flaws and security controls.

View White box penetration test →

TLPT

Testing is based on realistic threat scenarios derived from the sector, critical assets and relevant adversary techniques. The operation can include people, processes, technology, detection and response. Threat-led penetration testing is intended for organisations with advanced resilience requirements and can align with frameworks such as TLPT and TIBER-EU.

View TLPT penetration test →

Frequently asked questions about penetration testing

What is a penetration test?

A penetration test is a controlled security assessment in which specialists carry out realistic attack techniques within an agreed scope. The test establishes which vulnerabilities can actually be exploited and which attack paths follow from them. A penetration test shows what is exploitable at the time of testing.

What is the difference between a penetration test and a vulnerability scan?

A vulnerability scan uses automated tooling to identify known vulnerabilities and configuration weaknesses. A penetration test adds manual analysis, exploitation and attack-path validation. It determines whether a weakness can be used in practice, how separate findings can be chained and what level of access or impact an attacker could achieve.

When does an organisation need a penetration test?

A penetration test is appropriate when new systems go live, after a significant change to the environment and when clients, insurers or supply chain partners require one. Obligations arising from NIS2, DORA, ISO 27001 and BIO2 also lead to periodic technical testing. A penetration test provides independent technical evidence, but does not demonstrate compliance by itself.

How often should a penetration test be carried out?

For most organisations an annual penetration test is the starting point, supplemented by a test after every significant change. New applications, migrations to cloud or identity platforms, changes to network segmentation and acquisitions alter the attack surface immediately. A fixed interval alone is therefore insufficient, because risk moves with the environment.

Which systems can be included in a penetration test?

The scope can include web applications, APIs, mobile applications, external infrastructure, internal networks, Active Directory, Microsoft Entra ID, cloud environments, wireless networks, endpoints and OT environments. Combined scopes can be used to examine attack paths across applications, identities, infrastructure and network boundaries.

What is the difference between black box, grey box and white box testing?

A black box test starts without credentials or internal documentation. A grey box test uses limited access or technical context to test authenticated functionality and internal attack paths in greater depth. A white box test includes extensive information such as source code, architecture and configurations. Grey box testing provides the strongest balance between realistic attacker behaviour and technical coverage for most assessments.

Can a penetration test be performed safely in production?

Yes, provided that the scope, rules of engagement, stop conditions and escalation procedures are defined in advance. Techniques that could affect availability are restricted or coordinated separately. OT, healthcare and other safety-critical environments require additional controls and may rely on passive analysis or carefully selected active tests.

How long does a penetration test take?

Duration depends on the size, complexity and required depth of the scope. A limited application or infrastructure assessment may require one or a few test days. Complex environments with multiple roles, networks, cloud platforms or OT systems may require several days up to one or more weeks. The required effort is established during technical scoping during the intake call.

What does a penetration test report contain?

The report contains the agreed scope, methodology, validated findings, affected assets, technical evidence, attack paths, impact analysis and remediation guidance. Findings are scored using CVSS and interpreted within the operational context of the environment. Critical findings are communicated during the test rather than held until final reporting.

Direct access to senior cybersecurity expertise

Discuss a security requirement, active risk or complex IT or OT environment with one of our senior specialists. The initial conversation focuses on the technical context, operational constraints and the most appropriate course of action.