Penetration Testing Services

A penetration test delivers an executive summary, technical findings with severity, reproduction steps and named owners, MITRE ATT&CK mapping, a prioritised remediation order, and a retest report once your fixes are in. Each finding also carries a plain-language statement of what it lets someone do in your environment, alongside its CVSS score.

The report is written for two readers. The executive summary tells the board and the regulator what was tested, what was found and what it means. The technical section tells the engineer who owns each finding exactly how to reproduce it and what to change.

You also receive an attestation letter stating what was tested, when, by whom and to what standard. It is an attestation rather than a certificate, because no penetration test can certify a system as secure. It states what was examined and what was found on those dates.

Black box, grey box and white box penetration testing differ in how much we are told before the test starts. Black box buys realism and costs coverage, white box buys coverage and costs realism, and grey box is the honest default for most estates.

Black box

We start with no more than an attacker would have: a company name, a domain, an address. This is the right choice for external network and wireless testing, because that is the attacker's position. Against a web application or an API it misses most of the logic, because the window is spent finding the doors rather than testing them.

Grey box

We start with normal credentials and a short briefing, typically a standard user account for an internal test or one login per role for an application. This is the standard choice for internal networks, web applications and APIs. It puts the tester where a phished employee or a malicious insider would already be.

White box

We start with everything: source code, architecture diagrams, cloud configuration and administrative access. It is the standard choice for cloud, because misconfiguration is the finding, and the deepest option for applications and APIs. A provider who recommends black box for everything is selling difficulty rather than findings.

A penetration testing method is chosen by reading the surface under test against the question you need answered, and it is agreed in writing at scoping before anything is touched. The matrix above is the starting point. The choice is then adjusted for what you already know and for what a regulator will ask to see.

External network and wireless

Black box, because the attacker's position is the honest one. Grey box is used where you need faster coverage of a large estate than the window allows.

Internal network, web applications and APIs

Grey box, from a normal user account inside, or with credentials for each application role and the API specification and tokens. Most serious findings are about who is allowed to do what, and a tester without an account cannot reach them.

Cloud

White box, with read access to the configuration, because over-broad roles, exposed storage and trust between accounts are the findings and they are invisible from outside.

A scoped penetration test typically runs two to four weeks including reporting, against six to ten weeks for a full Red Team engagement. The testing window itself is fixed in the rules of engagement, and the report follows it.

What moves the figure is the size of the in-scope estate, the number of application roles to cover and how much reconnaissance the knowledge level requires. A black box external test spends more of its window on mapping than a grey box application test does.

The retest is quoted and scheduled at the start rather than sold to you after the report lands, but it runs separately, once your fixes have landed. It starts when you tell us the fixes are in.

The cost of penetration testing in the UAE is driven by the size of the in-scope estate, the type of test and the depth agreed, and every engagement is quoted individually against those. There is no per-asset price list, because two applications of the same size can need very different amounts of manual work.

Within those three drivers, the details that move the number are the number of hosts or endpoints, the number of application roles that need testing, whether the API has a specification, the knowledge level, and whether people or physical access are in scope alongside the technology.

The retest is included in the scope and priced at the start, so it does not appear as a surprise later. Tell us roughly what is in scope and we can put a number and a timeline against it.

Four UAE regimes expect penetration testing of in-scope systems: CBUAE for licensed financial institutions, the ISR standard published by the Dubai Electronic Security Center for Dubai government entities, ADHICS for healthcare entities under the Department of Health Abu Dhabi, and the UAE IAS for critical infrastructure. PCI DSS applies wherever card data is handled.

CBUAE

Independent periodic testing is what the regulator asks for, and a scoped penetration test is the usual way institutions evidence it. What a test cannot evidence is detection and response, because your Blue Team is told it is happening. Institutions carrying systemic importance are expected to run adversarial exercises as well.

ISR, ADHICS and the UAE IAS

Each expects evidence that in-scope systems are tested independently and that findings are fixed. The IAS is published by NESA, now the SIA, and a tender that says NESA means the IAS. What all three examine is the chain: scope rationale, authorisation, findings, remediation record and retest.

PCI DSS

Card data environments need penetration testing at least annually and after significant change, covering the segmentation that keeps the rest of the estate out of scope.

Penetration testing is a person attempting to break in, and a vulnerability scan is a program matching your systems against a database of known conditions. The scan reports what it recognises. The test finds what no database lists: authorisation flaws, business logic flaws and chains of individually minor issues that together reach something that matters.

A scanner cannot tell whether an authorisation check is missing on the one endpoint that moves money, or that two medium findings together reach cardholder data. Those are the findings that decide whether a breach happens, and every one of them needs a person to reason about it.

We use automated tooling for coverage and never for conclusions. Every finding in a report has been reproduced by hand, which is the difference between a list of possible conditions and a list of proven ones.

Our penetration testing follows the phases described in PTES and NIST SP 800-115: scoping and authorisation, reconnaissance and mapping, manual testing, chaining and proof, reporting, and retest. Web applications and APIs are tested against the OWASP Web Security Testing Guide and scored against ASVS where you need a verification level.

Every technique used is mapped to MITRE ATT&CK, so this year's report is comparable with last year's and with the next provider's. Severity is CVSS plus a plain-language statement of what the finding lets someone do in your environment, which is what a risk owner can defend.

We do not claim CREST accreditation. Testers meet a published operator standard that is CREST-equivalent in its screening, experience and certification requirements, and the company holds ISO 27001 and ISO 9001.

Penetration testing should not take your systems down, because denial of service techniques are excluded by default and no production change is made without written agreement. The rules of engagement name the hours, the excluded techniques and the deconfliction route before work begins.

Some findings can only be proven by touching something live, such as writing a test record through a flaw in an approval path. In those cases we ask first, agree the exact action, and record it, rather than proving the point and explaining afterwards.

You have a deconfliction channel that reaches the testers within minutes if something needs stopping. If a system behaves unexpectedly during the window, we stop, tell you, and agree how to continue.

A penetration test should run in production wherever it is safe to do so, because staging environments routinely differ from production in exactly the configuration that turns out to matter. A finding on a staging copy proves the copy is vulnerable, and a clean result on the copy proves only that.

Where production genuinely cannot be touched, we say so in scoping rather than quietly testing a copy and reporting on it as though it were live. The report then names the environment tested, so a regulator reading it knows what the evidence covers.

The safe middle ground is often a grey box test against production with a separate set of test accounts and test data, with denial of service excluded and the hours agreed. That keeps the configuration real without putting real customer records in the path.

Named testers who have cleared the published operator standard carry out every penetration test, and you get their names before the engagement starts. The people named are the people who do the work.

That standard is four conditions: a certificate of good conduct with repeat screening, a bachelor's degree in an IT field, at least four years of hands-on offensive work, and at least two certifications drawn from OSCP, OSWE, OSEP, OSED, OSCE3, CRTO and CRTL. It is published so you can hold us to it.

During the engagement you have direct access to the people doing the testing, not an account manager relaying answers. Most findings resolve faster in one call with the tester than in three emails.

Penetration testing should be repeated at least once a year and after any significant change to the system under test, such as a new release, a migration to cloud, or a change to authentication. That is the interval PCI DSS names, and the UAE regimes above expect periodic testing tied to your own risk assessment.

Between full tests, a retest closes the findings from the last one. Until that exists, a finding marked resolved is an assertion rather than evidence, so the retest belongs in the same year as the test rather than the next.

Estates that change continuously are better served by testing each major release than by one large annual exercise, because the annual test arrives after the flaw has been live for months. We scope either way.