
Infrastructure Pentest
Your corporate IT estate and the segmentation meant to keep it away from the control network, tested from the foothold an attacker gains inside.
Oil, Gas & Energy
We test the systems that run the plant: corporate IT, the OT networks behind SCADA and DCS, the PLCs and RTUs on remote sites, and the boundary between them. We prove every weakness, and we test around uptime and safety.

Organizations we secured




An energy operator's attack surface is not the corporate website. It is the segmentation between corporate IT and the control network, the SCADA and DCS platforms that run the plant, the PLCs and RTUs on remote and unmanned sites, and the safety-instrumented systems that bring a process to a safe state. An attacker who reaches those seams reaches the plant.
In this region the finding we report most often in energy is a weak boundary between corporate IT and operational technology: a flat path, a dual-homed host or a forgotten jump server that lets a foothold in the office network reach a control segment it should never touch. No scanner maps that path, and a test that stops at the perimeter never sees it. We trace it by hand, from corporate IT through the IT/OT boundary to the plant, and we prove each step.
OT is tested around uptime and safety. Denial-of-service techniques are excluded by default, and where a test case could affect a live plant it runs against a production-equivalent environment instead. A NESA or sector assessor does not read a score. They read the scope, the authorisation, the findings with owners, the remediation order and the retest, mapped to NESA CIIP guidance, the UAE IAS and IEC 62443, and every engagement here produces that.

The services a UAE energy operator, utility or EPC contractor usually buys, and the question each one answers. Scoped with you, never sold as a fixed bundle.

Your corporate IT estate and the segmentation meant to keep it away from the control network, tested from the foothold an attacker gains inside.

SCADA, DCS and the PLCs behind them, assessed around uptime and safety against IEC 62443, with denial-of-service excluded and live plant off limits.

An objective-based test against a named crown jewel that measures whether your SOC detects and responds across IT and OT.

Your operational dashboards and customer portals, tested for the authorisation and business-logic flaws that a scanner cannot reason about.

The telemetry, metering and integration APIs between systems, checked per role and per object so one service cannot reach another's data.

Phishing, pretext calls and physical entry against staff and remote sites, run only under rules agreed in writing beforehand.
Three kinds of company sell security testing to energy operators in the UAE. This is where we sit, criterion by criterion, against the regional average.
| Criterion | RedTeam Security | UAE market average |
|---|---|---|
Named, vetted operators against a published bar | Often unnamed or quietly subcontracted | |
Hands-on, authorisation and logic first | Scanner output lightly reviewed | |
NESA CIIP, the UAE IAS and IEC 62443 | One regime, named in passing | |
Measured as a primary deliverable | Defenders usually told in advance | |
Priced at scoping, evidence on closure | Sold separately after the report | |
Retention and destruction stated in writing | Rarely published | |
A direct line to who found it | Routed through an account manager |
The comparison is a positioning statement, not a league table. Where you need high-volume routine scanning at the lowest price, a regional VAPT firm is the better answer, and we would rather say so now than at the third meeting.
The same operators and the same evidence chain, scoped to the systems and the regulators each industry answers to.
In the UAE a critical energy operator is expected to run independent security testing aligned with the NESA Critical Information Infrastructure Protection (CIIP) guidance and the UAE Information Assurance Standards, and to assess its operational technology against IEC 62443. Testing is mapped to these, never presented as certification against them.
The Critical Information Infrastructure Protection guidance covers the systems whose disruption would affect an essential service. An engagement produces the scope rationale, findings, owners and retest evidence an assessor reads.
The UAE Information Assurance Standards set the controls an entity is expected to meet. The engagement evidences the technical controls directly and shows where a control is enforced and where it is not.
The standard for industrial automation and control systems frames how operational technology is tested: zones and conduits, the IT/OT boundary and the segmentation between them. We scope the control network explicitly rather than folding it into the corporate test.
Operational technology is tested around uptime and safety. Denial-of-service and stress techniques are excluded by default, the rules of engagement fix the testing window and a deconfliction contact before any work starts, and where a test case could affect live plant it runs against a production-equivalent environment instead.
Where that environment differs materially from production, the report says so, because a test of a different configuration is a test of a different system.
A named contact on both sides handles the case where a tester finds an active compromise rather than a weakness. That path is settled before day one, not during the incident.
An OT and ICS pentest covers the IT/OT boundary, the segmentation between corporate IT and the control network, the SCADA and DCS platforms, and the PLCs and RTUs on remote and unmanned sites. Safety-instrumented systems are treated as off limits for active testing and reviewed by configuration instead.
The most common serious finding we report in energy is a weak boundary between corporate IT and operational technology: a flat path or a dual-homed host that lets a foothold in the office network reach a control segment it should never touch. It is traced by hand, from corporate IT through the boundary to the plant.
We scope the corporate network, the IT/OT boundary and the control network separately, because a control enforced at the boundary is not the same as one enforced inside the plant, and an attacker reaches the plant.
The boundary is tested from a realistic foothold inside corporate IT, then by following every path that reaches operational technology: firewalls and their rules, jump servers, dual-homed hosts, remote-access routes into unmanned sites and any shared service that straddles both sides.
Each path that works is proven with evidence and mapped to the segmentation it defeats, so the fix is a change to a rule or to the architecture rather than a line in a report.
A UAE energy operator should test at least annually for anything internet-facing or spanning the IT/OT boundary, before a significant change reaches a control environment, and after any material change to remote access, segmentation or the plant network. Where a regulator names an interval, treat it as a floor rather than a schedule.
A new remote-access route, a new integration between corporate IT and OT, or a migration of a control system are the changes most likely to introduce the flaws that matter, and each is a reason to test the affected area rather than wait for the annual cycle.
We run the same phases on every engagement so two reports a year apart are comparable, and you can see what changed rather than reading two unrelated documents.
Most energy operators start with an infrastructure pentest of corporate IT and the segmentation to OT, add an OT and ICS pentest across SCADA, DCS and the PLCs behind them, and test the operational and customer web applications and the integration APIs. An objective-based Red Team and a social engineering test follow once the basics are covered.
The right mix depends on what you are protecting and what a regulator has asked for. We scope it with you rather than selling a fixed bundle, and we say where something is not worth buying yet.
Retest is priced at scoping, not sold as an extra once the report lands. When you have fixed the findings, we re-run the affected test cases and close each one on evidence that the fix holds, rather than on your word that it was applied.
Every finding carries a severity and a named owner, maps to MITRE ATT&CK, and is traced from the foothold to the impact, so the fix lands on a firewall rule or the architecture instead of a line in a report. You get the full technical report and the proof behind each finding.
At the end you also get an attestation of testing you can hand to a regulator or to a customer's procurement team. It states what was in scope and that the work was done, without exposing the technical detail that belongs in the report.
Before the incident, not after it
The institutions that come out of an incident well are the ones that tested before it happened. Scope a conversation now, under NDA, and find the weaknesses before someone else does.