2.3 Shared Responsibility, Legal Authorization, and Ethics
Key Takeaways
- Cloud shared responsibility splits hosting-provider, customer, penetration-tester, and third-party duties; the provider's hypervisor and other tenants are not in a customer's SoW.
- Customer-configured IAM, storage buckets, security groups, and application code are the usual cloud pentest surface; check the provider's testing terms of service first.
- A written authorization letter naming testers, targets, and the window is the get-out-of-jail document; verbal OK, an NDA, or an MSA is not enough.
- Mandatory reporting can require stopping and escalating (for example child exploitation material or imminent harm) per law and RoE — not finishing the exploit chain for a prettier report.
- Risk to the tester includes physical on-site work, laws in the target jurisdiction, and CFAA-style unauthorized-access exposure if the tester exceeds scope or the window.
Even a perfect CIDR list can still be illegal if you aim it at the wrong owner. Objective 1.1 closes pre-engagement with the shared responsibility model, legal and ethical considerations (authorization letters and mandatory reporting), and risk to the penetration tester. Domain 1 is only 13 percent of PT0-003, but these items are pass/fail in real life: they decide whether you are a contracted tester or an uninvited attacker.
Shared responsibility: four buckets
Cloud and managed hosting split ownership. PT0-003 wants four buckets: hosting provider, customer, penetration tester, and third-party.
Hosting provider responsibilities (cloud service provider or colocation operator) cover facilities, hardware, hypervisor, and often the managed control plane of a service — for example, the software the provider uses to implement object storage as a service. You do not get to pentest the hypervisor because the VM is in scope. Provider terms of service typically require advance notification or prohibit tests that could affect other tenants. Physical break-in at a hyperscale data center is never in a customer's SoW.
Customer responsibilities cover what the customer configures and builds: IAM policies, security groups, bucket ACLs, application code, guest OS patching in IaaS, identity, data classification, and which accounts they give you. Misconfigured public buckets, over-broad IAM roles, and forgotten admin URLs are classic customer-scope findings. A subsidiary, acquired company, or shadow account that is not named in the SoW is not automatically customer scope just because it bills to the same parent.
Penetration tester responsibilities are to stay in scope and in window, protect credentials and evidence, follow RoE escalation, refuse to pivot into provider or third-party systems, document authorization before testing, and avoid reckless techniques the SoW forbade. If a scan would hit a shared control plane, stop and ask. Testers also handle collected data as confidential under the NDA and purge it when the contract says to.
Third-party responsibilities sit with payment processors, DNS and CDN vendors, identity providers, managed EDR, and ISPs. The customer's contract with them is not your authorization. Many processors will treat an unannounced scan as an attack. RoE exclusions exist largely for this bucket.
| Role | Usually in a customer pentest | Usually out unless separately authorized |
|---|---|---|
| Hosting provider | Not the client | Hypervisor, data-center physical security, other tenants, managed-service internals |
| Customer | IAM, buckets, apps, guest OS in IaaS, their VPCs or projects, their URLs | A subsidiary or acquired company not named in the SoW |
| Penetration tester | Methods allowed in RoE against in-scope assets | Extra CIDRs, after-hours overruns, dumping production PII contrary to RoE |
| Third party | Only if they signed or issued written permission | Payment processor, IdP, CDN origin they operate, ISP equipment |
Move from IaaS (lots of customer OS and network) to PaaS to SaaS (mostly customer data and configuration, little OS) and the tester's legitimate surface shrinks toward identity, tenancy isolation, and the application the customer actually controls. Do not assume a SaaS tenant SoW includes the provider's login service just because users authenticate there.
Authorization letters
The authorization letter — often called a get-out-of-jail document — is written permission from someone with authority to allow the test. It names the tester organization, the people or call signs on the wire, the targets, the window, and a client contact who can confirm the work. Keep it with on-site testers and with the SOC during the window. If a defender, ISP, or law-enforcement officer sees exploit traffic, this letter is how you demonstrate you are not a random attacker.
Verbal OK is not enough. A Slack thumbs-up is not enough. An NDA is not enough. An MSA is not enough. You need written authorization that matches the SoW and RoE. If a developer added an extra hostname in chat, you still wait for a written amendment before you scan it.
If the target jurisdiction criminalizes unauthorized access — in the United States, Computer Fraud and Abuse Act-style statutes plus state laws; elsewhere, local computer-misuse acts — exceeding scope can look like a crime even if you started with a contract. This is exam and professional framing, not legal advice. When jurisdiction is messy (extraterritorial users, multi-national cloud regions, testers traveling with attack laptops), the client's counsel and your firm's counsel belong in pre-engagement, not after a complaint.
Mandatory reporting requirements
Some discoveries are not findings for the PDF. Mandatory reporting requirements may require you to stop, preserve evidence as directed, and notify named parties rather than quietly finishing the exploit chain.
Teach the concept; do not invent a fake statute number. Examples include child sexual exploitation material on a host, an imminent threat to life or safety, certain regulated-industry incidents that counsel says must go to a regulator or payment brand, and evidence of an ongoing third-party intrusion where hiding your presence could increase harm. Handle the last case per RoE, not freelancer instinct.
RoE should pre-negotiate who decides, which lawyer is on call, whether testing pauses, and that testers do not investigate a crime beyond what the authorization and law require. If RoE is silent and you hit illegal content or imminent harm, stop the offensive technique, do not copy the material around as a souvenir, escalate immediately to the named client contact and your firm's leadership, and follow their lawful instruction.
Risk to the penetration tester
Objective 1.1 explicitly includes risk to the penetration tester. That is not melodrama.
Physical on-site work. Badge cloning, tailgating, and facility tests can become trespass, a use-of-force incident if a guard intervenes, or ordinary industrial injury on roofs, plants, and warehouses. RoE must define sites, hours, whether you carry the authorization letter, clothing or contractor badges, and when you abort if challenged. Walking away from a hostile confrontation is a professional outcome, not a failed PBQ.
Laws in the target jurisdiction. A test legal in one country may not be in another. Export-controlled tools, radio-frequency rules for wireless work, drone restrictions, and computer-misuse statutes attach to where the packets and the people are. Do not assume your home country's contract language travels with your laptop.
Exceeding scope. Continuing at 05:30, scanning the excluded processor, or just checking a neighboring CIDR can convert a contracted test into unauthorized access. The client's after-the-fact forgiveness is not something you should count on. Professionally you stop, escalate, and get a written amendment. The Saturday SaaS story is the same legal story: Nessus onto the payment processor is third-party plus possible unauthorized access; staying live at 05:30 is tester legal risk even against app.example.com.
Operational blowback. You may be blocked, named in an incident ticket, or reported to an ISP if the SOC was not informed on a covert test. Covert testing is only defensible when authorization and a trusted client contact exist.
Ethics after the window: do not keep leftover credentials, do not reuse client data in personal labs, do not hide in-scope damage, and do not threaten to disclose findings to coerce payment. PenTest+ is testing whether you will still be employable and out of jail after the engagement, not whether you can launch every module in a framework.
Tie the whole pre-engagement objective together before you start reconnaissance. Authorization letter in the tester's bag. SoW and RoE in the ticket. Provider pentest policy checked if 10.4.0.0/16 is a VPC. Processor excluded. Window 01:00–05:00 local Saturday. Customer IAM and buckets are likely in scope; the hypervisor is not. If you find imminent harm or illegal content, you leave the exploit path and enter the reporting path.
A customer authorizes a penetration test of an application they host on AWS. Which target is usually in the customer's and tester's scope rather than the provider's?
A SOC analyst challenges late-night exploit traffic and asks the tester to prove the activity is authorized. Which document is the get-out-of-jail written permission defenders and law enforcement can check during the window?
During a web test a tester finds what appears to be child sexual exploitation material on an in-scope host. What is the professional response taught for PT0-003-style mandatory reporting and tester ethics?