April 21, 2026 · 7 min read

How to Prepare for a Penetration Test in UAE - Engagement Checklist

Q: "How far in advance should I start preparing for a penetration test?"

"Start access provisioning 2 weeks before engagement begins - this is the single most common cause of engagement delay. Scope documentation and internal alignment should start 4 weeks ahead for first-time engagements or 2 weeks ahead for follow-on engagements. Technical documentation (architecture diagrams, API docs, release notes) should be provided pre-engagement. Regulator coordination, if required, should happen before kickoff - some UAE regulators expect notification."

Q: "What access do I need to provide for a penetration test?"

"Typical access requirements: test accounts at every privilege level in scope (user, admin, role-based tiers), VPN or network access for internal testing, cloud read-only or test-environment access for cloud engagements, jump host credentials if engineering intrusion is necessary, mobile app test builds if not public app-store versions, and test data representing realistic production content without being actual PII. Provision 2 weeks pre-engagement and test the credentials before kickoff."

Q: "Should I notify my SOC team about the penetration test?"

"Depends on engagement type. For standard penetration testing, notify SOC and IT operations to avoid the first finding being 'SOC noticed suspicious activity.' For red team exercises, notify only the Control Team (CISO, Head of Security, designated executives) with safe-word protocol - broader organization should be blind to authentically test detection and response. For regulated entities, compliance and legal teams should have engagement-wide awareness regardless of type."

Q: "What should a pentest scope document include?"

"Specific lists of: URLs, domains, subdomains of applications to be tested. API endpoints including version. Cloud account IDs (AWS, Azure, GCP) and regions. Network CIDR ranges for infrastructure testing. Mobile apps with App Store/Play Store listings. User roles to test with test accounts provided. Explicitly excluded scope: production systems that cannot tolerate testing, third-party SaaS not owned by your organization, systems managed by other business units, social engineering (unless scoped), physical intrusion (unless scoped), denial of service, specific test users/data you want protected."

Q: "How should I handle critical findings discovered mid-engagement?"

"Acknowledge receipt immediately and make remediation decision quickly - fix now, fix after engagement, or accept risk. Inform regulators if applicable (some frameworks require timely reporting). Do not delay engagement to investigate - let the researcher continue; investigate in parallel. Pre-engagement, name the decision authority (and backup) for critical finding response. Establish the escalation path and out-of-hours contact in writing before testing starts."

Q: "What's the biggest preparation mistake UAE buyers make?"

"Access credentials not provisioned before Day 1 of engagement. We routinely lose 2-3 testing days to credential issues on engagements where preparation was inadequate. Equally common: scope ambiguity where customer says 'test anything you think is important' and the testing firm spends week 1 on scoping rather than testing. Both preventable with a 2-week pre-engagement preparation window and a specific written scope document."

Complete checklist for preparing for a penetration test in UAE. Pre-engagement scoping, internal alignment, access provisioning, regulator coordination, and common preparation mistakes that add cost and delay.

Preparing for a penetration test in the UAE is the difference between an engagement that delivers maximum value and one that burns half the timeline on logistics. Most first-time buyers under-invest in preparation, then spend the first week of a 3-week engagement sorting out access, scope ambiguity, and internal alignment that should have been resolved pre-engagement.

This guide is the preparation checklist we wish every UAE buyer used before the engagement starts.

Before You Engage a Vendor

Define your primary objective

Penetration testing serves multiple possible outcomes. Be clear which you want:

Regulator evidence - NESA, DFSA, VARA, CBUAE, ADSIC, PCI DSS compliance
Customer security questionnaire response - enterprise sales blocker
Board or audit committee assurance - cyber risk reporting
Pre-launch security validation - new product or major release
Post-incident security review - after a breach or near-miss
Mergers and acquisitions - target company due diligence

Different objectives drive different scope decisions. Tell the vendor explicitly.

Identify stakeholders

Engagement sponsor - typically CISO or senior IT leader
Technical lead - who owns the systems being tested
Compliance/audit point of contact - where regulator-mapped findings will be submitted
Legal and procurement - for contracting, NDAs, data handling agreements
Communications - who gets notified of critical findings discovered mid-engagement

Budget and timeline reality

Map your budget and timeline to realistic scope. See penetration testing cost guide for UAE-specific ranges. A rushed two-week engagement on a complex scope produces thin results. A three-week engagement on narrow scope produces better value than a two-week engagement on broad scope.

Scope Definition

What is in scope

Be specific. List:

URLs, domains, subdomains of applications to be tested
API endpoints including version if relevant
Cloud account IDs (AWS, Azure, GCP) and regions
Network CIDR ranges for internal or external infrastructure testing
Mobile apps - iOS and Android, specific App Store and Play Store listings
User roles to test - provide test accounts for each privilege level

What is out of scope

Be equally specific. Common exclusions:

Production systems that cannot tolerate even passive testing
Third-party services not owned by your organization (SaaS tools, payment processors)
Systems managed by other business units not part of this engagement
Social engineering (unless explicitly scoped)
Physical intrusion (unless explicitly scoped)
Denial of service or destructive testing
Specific test users or data you want protected

Rules of engagement

Agreed in writing before any testing begins:

Testing time windows - when can active testing occur?
Escalation path for critical findings discovered mid-engagement
Safe-word or emergency-stop protocol
Contact person for immediate issues
Evidence handling requirements (screenshots, packet captures)
Data residency - where can findings data be stored?
Report distribution list

Pre-Engagement Technical Preparation

Access provisioning

The single most common cause of engagement delay. Start provisioning two weeks before engagement begins:

Test accounts at every privilege level in scope (user, admin, role-based tiers)
VPN or network access if internal testing
Cloud read-only or test-environment access for cloud engagements
Jump host credentials if engineering intrusion is necessary
Mobile app test builds if not public app-store versions
Test data that represents realistic production content without being actual PII

Test the credentials before the engagement starts. “The account I was given doesn’t work” is a first-day failure mode we see routinely.

Technical documentation

Provide pre-engagement:

Architecture diagrams showing in-scope systems and their connections
Authentication flow documentation for applications under test
API documentation including endpoint catalogs and authentication requirements
Third-party integration inventory for applications with significant external dependencies
Recent release notes showing what has changed since last testing

Good documentation cuts reconnaissance time by 2-3 days on typical engagements.

Backup and rollback readiness

Full backup of systems being tested before engagement starts
Documented rollback procedure if testing inadvertently causes issues
Clear ownership of rollback decision authority
Out-of-hours contact path to whoever has rollback authority

Notification

Internal teams that may see unusual activity during testing:

SOC / MDR team - should be notified or deliberately blinded depending on engagement type
IT operations - to avoid the first finding being “IT ops noticed suspicious activity”
Compliance team - if findings may trigger reporting obligations
Legal - for engagement-wide awareness

For red team exercises, notification is limited to the Control Team only. For penetration testing, broader awareness is typical.

UAE-Specific Preparation

Regulator coordination

For regulated entities, some regulators expect notification of scheduled penetration testing:

CBUAE - some banks notify supervisor of testing windows
DFSA - no explicit notification requirement, but significant findings must be reported via routine supervisory channels
VARA - engagement dates typically internal but findings feed into supervisory reports
NESA / NCA - no pre-engagement notification; findings may be in scope for CII reporting

Coordinate with your compliance function to determine any specific obligations.

Data residency and confidentiality

UAE Personal Data Protection Law (PDPL) affects where findings data can be stored:

Findings involving personal data should be handled under PDPL-compliant data handling
Data residency preferences - some regulators expect UAE-resident testing data
Access controls on findings data during and after engagement

Specify data handling requirements in the engagement contract.

UAE PASS and Emirates ID integration

If your application integrates with UAE PASS or processes Emirates ID:

Specify in scope whether identity integration can be tested
Provide test credentials for UAE PASS staging if available
Clarify any restrictions on testing identity-integrated flows

Arabic language applications

Applications with Arabic-language interfaces benefit from:

Pre-engagement note that application has Arabic content
Test accounts configured for Arabic-language flow validation
Specifying whether Arabic-language content should be explicitly tested (text injection, RTL handling)

During the Engagement

Responsiveness

First day of engagement - be available for access verification issues
Daily during engagement - respond to clarification questions within hours, not days
Critical finding notification - defined response path with named decision authority
Out-of-hours issues - who to contact if testing causes production impact

Trust the methodology

Good penetration testing firms follow methodology. Do not:

Tell them how to find things (that is their job)
Provide findings in advance (“we already know about this”)
Bias their reconnaissance by steering attention
Pre-disclose recent changes that affect testing approach

Do:

Answer clarification questions factually
Provide additional context when asked
Authorize scope expansion if discovered issues warrant
Validate assumptions about business logic when asked

Critical finding response

When a critical finding is discovered mid-engagement:

Acknowledge receipt immediately
Make remediation decision quickly - fix now, fix after engagement, or accept risk
Inform regulators if applicable (some frameworks require timely reporting)
Do not delay engagement to investigate - let the researcher continue; investigate in parallel

After the Engagement

Report review

Timeline expectations:

Draft report - typically within 5 business days of engagement end
Final report - within 10 business days after your review
Readout session - schedule at or shortly after final delivery
Regulator submission - typically within 30-60 days depending on framework

Remediation tracking

For each finding:

Assigned owner
Target remediation date based on severity
Remediation approach (fix, compensating control, risk acceptance)
Verification - who confirms remediation is complete

Retest cycle

Our engagements include one retest cycle for critical and high findings. Schedule retest:

Within 30 days for critical findings in production
Within 60 days for high findings
Within 90 days for medium findings (if included in retest scope)

Programme evolution

After the engagement:

What was in scope that should be expanded next cycle?
What findings suggest areas needing deeper testing?
What process improvements would make next cycle more efficient?
Does the next engagement need specialty scope (mobile, IoT, AI, red team)?

Common Preparation Mistakes

Mistake	Impact	Prevention
Access credentials not provisioned before Day 1	Lost 2-3 testing days	Provision 2 weeks pre-engagement; test credentials before kickoff
Scope ambiguity - “anything you think is important”	Vendor spends first week on scoping, not testing	Write specific scope document pre-engagement
SOC not notified (penetration test, not red team)	First finding is “SOC noticed suspicious traffic”	Decide notification strategy pre-engagement
Rollback capability not verified	Testing incident becomes production incident	Verify backup and rollback before engagement
No decision authority for critical findings	Critical finding sits unaddressed until engagement end	Name decision authority and backup pre-engagement
Engagement scheduled during major release	Testing interferes with release, or release hides test findings	Schedule to avoid known major changes

How pentest.ae Supports Pre-Engagement Preparation

We provide a detailed pre-engagement preparation checklist tailored to your scope. Kickoff calls focus on scope and logistics rather than on introducing methodology. Access and documentation requirements are specified in the statement of work rather than requested ad-hoc during engagement. UAE regulator coordination is built into scoping conversation.

Penetration Testing UAE - service overview
Best Penetration Testing Companies in UAE - evaluation framework
Penetration Testing Cost UAE - budget reality
Penetration Testing vs Vulnerability Assessment - choosing the right service
Security Testing Services UAE - programme approach

Common Questions

Frequently Asked Questions

How far in advance should I start preparing for a penetration test?

Start access provisioning 2 weeks before engagement begins - this is the single most common cause of engagement delay. Scope documentation and internal alignment should start 4 weeks ahead for first-time engagements or 2 weeks ahead for follow-on engagements. Technical documentation (architecture diagrams, API docs, release notes) should be provided pre-engagement. Regulator coordination, if required, should happen before kickoff - some UAE regulators expect notification.

What access do I need to provide for a penetration test?

Typical access requirements: test accounts at every privilege level in scope (user, admin, role-based tiers), VPN or network access for internal testing, cloud read-only or test-environment access for cloud engagements, jump host credentials if engineering intrusion is necessary, mobile app test builds if not public app-store versions, and test data representing realistic production content without being actual PII. Provision 2 weeks pre-engagement and test the credentials before kickoff.

Should I notify my SOC team about the penetration test?

Depends on engagement type. For standard penetration testing, notify SOC and IT operations to avoid the first finding being 'SOC noticed suspicious activity.' For red team exercises, notify only the Control Team (CISO, Head of Security, designated executives) with safe-word protocol - broader organization should be blind to authentically test detection and response. For regulated entities, compliance and legal teams should have engagement-wide awareness regardless of type.

What should a pentest scope document include?

Specific lists of: URLs, domains, subdomains of applications to be tested. API endpoints including version. Cloud account IDs (AWS, Azure, GCP) and regions. Network CIDR ranges for infrastructure testing. Mobile apps with App Store/Play Store listings. User roles to test with test accounts provided. Explicitly excluded scope: production systems that cannot tolerate testing, third-party SaaS not owned by your organization, systems managed by other business units, social engineering (unless scoped), physical intrusion (unless scoped), denial of service, specific test users/data you want protected.

How should I handle critical findings discovered mid-engagement?

Acknowledge receipt immediately and make remediation decision quickly - fix now, fix after engagement, or accept risk. Inform regulators if applicable (some frameworks require timely reporting). Do not delay engagement to investigate - let the researcher continue; investigate in parallel. Pre-engagement, name the decision authority (and backup) for critical finding response. Establish the escalation path and out-of-hours contact in writing before testing starts.

What's the biggest preparation mistake UAE buyers make?

Access credentials not provisioned before Day 1 of engagement. We routinely lose 2-3 testing days to credential issues on engagements where preparation was inadequate. Equally common: scope ambiguity where customer says 'test anything you think is important' and the testing firm spends week 1 on scoping rather than testing. Both preventable with a 2-week pre-engagement preparation window and a specific written scope document.

Find It Before They Do

Book a free 30-minute security discovery call with our AI Security experts in Dubai, UAE. We identify your highest-risk AI attack vectors - actionable findings in days.

Talk to an Expert