Definition

Cloud penetration test scoping defines the boundary between customer-owned attack surface (IAM policies, workloads, S3/Blob configs, network ACLs) and provider-managed infrastructure that is off-limits under AWS, Azure, and OCI Acceptable Use Policies and penetration testing terms. The scope document must specify account IDs, regions, resource ARNs, permitted techniques, and require written pre-authorisation from the CSP for any activity that could be mistaken for a real attack (e.g. network scanning, credential testing).

Why it matters

The pressure on VAPT programmes is shifting in specific, observable ways:

• AWS Penetration Testing Policy, Azure Penetration Testing Rules of Engagement, and OCI Security Testing Policy all require pre-notification or formal approval for specific test types; violating these can trigger account suspension and regulatory notification obligations.
• SAMA CSF 3.3.5 and NCA ECC-1 2-3-1 do not exempt cloud-hosted systems from annual pentest requirements; many Gulf financial entities incorrectly assume CSP responsibility covers their workload security posture.
• Misconfigured IAM roles (AWS) and over-privileged service principals (Azure) are the top cloud pentest finding in 68% of Gulf enterprise engagements, directly impacting NDMO PDPL Article 29 data-processor security obligations.
• OCI is the dominant cloud in Saudi government and NEOM projects; OCI's security testing terms differ from AWS/Azure and must be reviewed separately to avoid violating CITC cloud-computing regulations.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• CSP pre-authorisation email or portal submission confirmation — account ID, test dates, approved techniques
• AWS Config/Azure Resource Graph export — resource inventory (EC2, RDS, Lambda, Storage Accounts) with tags, region, VPC
• IAM policy JSON exports — attached policies, inline policies, role trust relationships for all test-target accounts
• CloudTrail / Azure Activity Log — tester source IP activity log used to reconstruct test timeline for chain-of-custody
• Network diagram showing shared-responsibility boundary — what the tester controls vs. CSP hypervisor layer
• Signed scope document listing account IDs, resource ARNs, permitted tool list (e.g. Pacu, ScoutSuite, CloudMapper)

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: Cloud Architect produces resource inventory using AWS Config or Azure Resource Graph; tags all Tier-1 workloads; Security Manager submits CSP pre-authorisation requests (AWS via console, Azure via Microsoft form).
• Day 31–60: Legal reviews CSP AUP against proposed test techniques; remove any prohibited activities (e.g. DoS simulation, physical data-centre tests); finalise scope document with account IDs and ARNs.
• Day 61–90: Tester executes cloud-specific assessment using Pacu (AWS), ROADtools (Azure Entra ID), and ScoutSuite for configuration review; documents IAM privilege-escalation paths and exposed storage objects.
• Day 90+: Cloud team remediates Critical findings (e.g. public S3 buckets with PII, over-privileged IAM roles); Security Manager archives CloudTrail evidence as chain-of-custody record for regulatory audit.
• Ongoing: Enable AWS Security Hub / Microsoft Defender for Cloud continuous posture monitoring; re-run ScoutSuite after every major infrastructure deployment to catch regression.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Publicly exposed storage buckets/blobs containing sensitive data: target 0 at close of engagement
• Over-privileged IAM roles (AdministratorAccess attached to non-admin principals): target 0 in production accounts
• CSP pre-authorisation lead time: plan for 3–10 business days depending on provider and technique
• Cloud pentest finding remediation rate within 30 days (Critical/High): target ≥90%
• ScoutSuite CIS benchmark pass rate: target ≥80% of applicable checks post-remediation

How it played out

The engagement began the way these always do — a specific trigger (what's in scope, what's the provider's problem, and what your contract needs to allow.) and an executive sponsor with limited patience for theoretical answers.

The first instinct on the client side was to add tooling. The first instinct on our side was to fix the raw findings with reproduction steps so that whatever tooling was added would have somewhere defensible to land.

What surprised the team — and worth noting for anyone running similar VAPT work — is how much of the value came from re-sequencing existing activities rather than introducing new ones.

• Trigger. The work was sponsored after a near-miss the executive team could no longer rationalise.
• First week. Stabilise the executive report and remediation tracker; pause anything that risked making it worse.
• Weeks 2–6. Rebuild the working evidence cadence; the regulator-facing story followed naturally once the internal cadence was honest.
• What we'd do differently. Engage the CISO on day one, not after the diagnostic.

Pitfalls we keep seeing

Across MAST Consulting Group's VAPT portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: scope written so loosely it invites scope creep mid-test. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: findings without business impact, only CVSS scores. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: missing chain-of-attack narrative for critical findings. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: no retest budget agreed up front. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on VAPT engagements because the integrations are cheap and the evidence is defensible:

• Nuclei — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• MobSF and Frida (mobile) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• Postman / OpenAPI fuzzers (APIs) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs VAPT programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this field note is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for VAPT programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.