A cloud security assessment, by the provider’s own rules

Not for an ordinary test of your own resources. AWS publishes a list of services you may assess without advance permission. Microsoft has not required pre-approval for Azure since 15 June 2017, though the Microsoft Cloud Unified Penetration Testing Rules of Engagement remain binding. Google requires no notification, provided you comply with the Acceptable Use Policy and Terms of Service and your tests only affect your own projects.

Approval is needed for AWS simulated events, which cover command-and-control red teaming, DDoS simulation, iPerf network testing, simulated phishing and malware testing. Those must be submitted at least two weeks before the start date.

Denial of service in any form. AWS prohibits DoS and DDoS along with port, protocol and request flooding; Microsoft prohibits DoS testing of any kind and states that DDoS is prohibited under all circumstances. All three also prohibit reaching anything you do not own. AWS additionally prohibits Route 53 DNS zone walking and hijacking, S3 bucket takeover and subdomain takeover, and Microsoft prohibits using credentials that are not your own, including publicly leaked ones.

Yes, with the account owner’s authorization. Microsoft is explicit: third parties may test if they hold explicit written authorization from the resource owner, Microsoft does not grant that authorization on the customer’s behalf, and it should be documented in the service agreement before testing begins. Treat that as the standard for all three providers and keep the document accessible during the test.

Because of where the responsibility line falls. The provider secures the infrastructure, so hosts, hypervisors and physical facilities are both out of your control and out of bounds. What remains yours is identity, configuration, data and the application, and that is where the findings are. Google states the position directly: most cloud security breaches are the direct result of misconfiguration.

A sequence of individually legitimate permissions that together reach something the starting identity was never meant to reach. A pipeline role that may pass a stronger role to a function it creates, a Google Cloud principal holding Service Account Token Creator on a privileged service account, or a Kubernetes role that may create workloads and therefore run as any service account in the namespace. Nothing in the chain is a vulnerability, which is exactly why scanners miss it.

The parts you own: RBAC, workload configuration, Pod Security Standards enforcement, network policy, secrets handling and whether pods can reach the cloud metadata API. That last item is the cluster-to-cloud pivot, item K08 in the OWASP Kubernetes Top Ten. Managed control planes are provider-operated, so you test your configuration of them, not their implementation, and on AWS note that EKS is not named on the permitted-service list.

A read-only audit role for the configuration and identity pass: SecurityAudit and ViewOnlyAccess on AWS, assumable with an ExternalId condition; Reader plus Security Reader on Azure; Viewer plus Security Reviewer on Google Cloud. Then one credentialed low-privilege principal per persona you want tested, because escalation paths cannot be proven from a read-only role, and cluster credentials where Kubernetes is in scope.

Yes, and for cloud configuration it is usually the only environment that answers the question. It needs an agreed window, rate limits, a named escalation contact and a documented stop condition, and no destructive action at any point. Note that providers run automated abuse detection and may interrupt activity in progress even when the test is entirely within the rules, so the authorization document has to be at hand.

Not in those words. NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, and point (d) covers supply chain security including relationships with service providers. For cloud computing service providers themselves, Commission Implementing Regulation (EU) 2024/2690 is concrete: its Annex requires a security testing policy, tests to a documented methodology, documented results and mitigating action on critical findings.

Article 25(1) lists penetration testing among the tests a financial entity’s resilience programme must provide for, and Article 24(6) requires appropriate tests at least yearly on systems supporting critical or important functions. For threat-led penetration testing, Article 26(3) requires the entity to secure the participation of in-scope ICT third-party providers while retaining full responsibility, and Article 26(4) allows a provider to contract an external tester directly for a pooled test covering several financial entities.