Security · Topic 06 of 23 · Part I — Foundations

Client consent & ethics

Consent is the legal foundation of the engagement. Ethics is what guides the tester when the contract is silent — and the contract is always silent on something.

Syllabus: § Legal and Ethical Implications (1.4, 3) → Client consent (plus the ethical dimension across the syllabus)

Topic 06 · Consent & ethics

The two perennial questions

By the end of this topic you can:

Describe what valid, defensible client consent looks like and what minimum elements it must contain
Recognize invalid consent — informal, unwritten, wrong signer, or expired
Negotiate consent for engagements involving third-party systems or data
Apply ethical principles to operational decisions when the contract is silent
Identify common ethical dilemmas and articulate a defensible position on each

What valid consent looks like

Valid consent must satisfy all of these conditions simultaneously:

Written. Email or signed document — verbal authorization is not enough, even from a CEO.
Specific. Names the systems, activities, time window, tester, and explicit exclusions.
Authorized signer. The signer can legally bind the organization — junior staff cannot.
Informed. The signer understands what "exploitation" and "credential dump" mean; the tester must explain in plain language.

Time-bounded. Consent expires — a 2024 document does not authorize 2026 testing.
Revocable. The client can withdraw consent during the engagement; the tester must stop and document.
Documented bilaterally. Both parties must be able to produce it — not a lost email thread.

Hard rule Anything less is not consent in any legally or professionally useful sense.

What consent documents contain

The tester does not draft these alone — legal counsel does — but must read and push back on technical ambiguity.

Parties — client org, testing org, cleared sub-processors
Scope — in-scope, out-of-scope, off-limits systems; authorized techniques
Time window — start, end, permitted hours, blackout periods
Authorization clause — explicit named-tester, named-systems, named-period statement
Rules of engagement — communication protocol, escalation contacts (including out-of-band), data-handling rules

Confidentiality / NDA — mutual disclosure obligations
DPA — required by GDPR/FADP if personal data is in play
Liability and indemnity — who carries what risk
Deliverables and acceptance criteria
Termination clause — how the engagement ends and what happens to data and access
Signatures and dates

Third-party consent

The principle is simple: anyone whose systems will be affected must consent. The execution is often complex.

Cloud providers — hyperscaler testing policies apply (see next slide)
MSPs / MSSPs — third-party consent required for anything affecting what they manage
SaaS dependencies — check terms of service before testing integrations

Shared physical infrastructure — colocation and shared offices affect other tenants
Partners and suppliers — supply-chain simulations usually need formal involvement or explicit scope exclusion

Complication The client may not know the full set of third parties they depend on. Mapping this is the tester's responsibility.

Hyperscaler testing policies

A third consent layer applies when systems run in a major public cloud — the provider's own policy is a contractual obligation the client already accepted.

	AWS	Azure	GCP
Pre-approval required?	No (since 2019)	No (since 2017)	No
Written policy page?	Yes	Yes	Partial (AUP + ToS)
DoS / DDoS prohibited?	Yes	Yes	Yes
Cross-account / cross-tenant testing?	Prohibited	Prohibited	Prohibited
Testing provider-managed services?	Prohibited	Prohibited	Prohibited
Platform bug found — notify?	No policy	MSRC (expected)	VRP (bughunters.google.com)

Classroom lesson Do not memorize this table — policies change. Establish the habit: read the current policy of every hyperscaler in scope before every engagement.

Cloud engagement — pre-testing checklist

1Identify every cloud provider used by in-scope systems (AWS, Azure, GCP, or others such as OVH, Hetzner, DigitalOcean)

2Read the current pen-testing / acceptable-use policy for each provider

3Confirm all planned techniques are within permitted lists

4Confirm no out-of-scope account IDs, subscriptions, or projects are reachable from the test path

5Add a clause to the RoE document committing the tester to the provider's policy

6If any technique is prohibited, scope it out or obtain written permission from the provider before starting

Scope creep — an ethical problem, not just operational

In Topic 04, scope creep was an operational risk. Here, it is also an ethical one.

The pressure during execution is always toward expansion: the client wants a bit more, the tester finds something interesting, time pressure suggests "let's just check this quickly."

Each undocumented expansion is a small ethical failure even when no harm results. The discipline of saying "let's update the document first" is a professional habit — not paperwork pedantry.

Pattern to break "It's so obviously related — I'll just have a quick look."

Pattern to build Stop. Document the proposed expansion. Get written acknowledgment. Then proceed.

The ethical framework testers actually use

No single official code exists for security testers, but converging traditions share the same core themes:

Common codes: (ISC)² · ISSA · EC-Council · CREST · OWASP · OSSTMM

Operate within authorization at all times
Minimize harm — do not damage what you do not need to damage
Be honest — with clients, the public, and yourself about what the test did and did not show
Protect confidentiality — what you learn about the client is theirs

Be competent — do not accept work you are not qualified to perform
Disclose conflicts of interest before the engagement, not during
Advance the field — share knowledge where you ethically can

(ISC)² Canon 1 "Protect society and the common good" — a duty wider than the client.

Recurring dilemmas (1–5)

#	Situation	Right move
1	Out-of-scope system has the same — or worse — vulnerability	Observe passively; do not exploit; raise as candidate scope expansion or freebie tip
2	SQL injection demo returns 200,000 real customer records	Stop; notify client; secure or destroy per DPA; keep only minimum records for the finding
3	Vulnerability turns out to be a prior real compromise	Stop; do not continue exploring; notify client; defer to their incident response
4	Client asks to remove a finding from the report	Decline. Offer diplomatic phrasing, confidential addendum, or severity precision — not omission
5	Social engineering targets an employee who did not personally consent	Must be authorized by senior leadership; pretext must not cause lasting harm; debrief afterward

Recurring dilemmas (6–10)

#	Situation	Right move
6	Consultant works for both the client and the vendor being tested	Disclose the conflict; recuse where it is material
7	Tester crashes a production system mid-test	Notify immediately; help with recovery; document for post-mortem; take ownership
8	A friend finds a vulnerability and asks for advice	Direct them to a VDP, bug bounty, or CERT — pursuing it without one is legally risky
9	End of engagement — what happens to notes, screenshots, and exfiltrated data?	Secure destruction with a written certificate; do not accumulate sensitive client data
10	Critical finding affects the client's customers; client wants indefinite disclosure delay	Genuinely hard. Professional codes favor reasonable timelines; bring legal counsel

The "should I do this?" filter

A short habit for when the contract is silent:

1Would the client actively want me to do this? (Not just "would they object?")

2Would I be comfortable explaining this on a witness stand?

3Would I be comfortable seeing it in the news next year, attributed to me by name?

Decision rule If any answer is no — stop. The contract may technically allow it; ethics does not.

Develop a personal stance on the harder dilemmas — written down, even if private — before a contract arrives that puts you under pressure.

Check — consent under pressure

Reflection

A client's CTO says verbally: "Yes, go ahead — you don't need it in writing." How do you respond, and why?

Reveal answer

Do not begin work. Restate politely that the verbal authorization is appreciated; you will act on it as soon as the same words appear in an email or signed document with explicit named scope. Frame written authorization as protecting both sides — not as distrust. Verbal consent exposes both the tester (no legal cover) and the client (no documented authorization for actions taken).

What you take home

Valid consent is written, specific, authorized, informed, time-bounded, revocable, and bilaterally documented — all seven conditions, always.
The consent document must cover parties, scope, time window, RoE, NDA, DPA, liability, deliverables, and termination.
Anyone whose systems are affected must consent — the client, third parties, and cloud providers.
Hyperscaler testing policies override client consent for actions that affect provider infrastructure; read them before every cloud engagement.
Scope creep is an ethical failure even when no harm results — document first, then act.
Professional ethics codes converge on authorization, minimizing harm, honesty, confidentiality, competence, and conflict disclosure.
When the contract is silent, apply the three-question filter: actively wanted? Witness stand? Front page?

Next: Topic 07 — OSINT. Building a pre-engagement intelligence picture without touching in-scope systems.

END · TOPIC 06

Consent first. Then everything else.

Before the next session: draft the three-question filter in your own words and apply it to one dilemma from today that you found difficult.