Security · Topic 05 of 23 · Part I — Foundations

Legal Implications

Every technique in this course is a criminal act without authorization — the single element that separates a professional tester from a criminal is explicit, written consent.

Syllabus: § Legal and Ethical Implications (1.4, 3) → Penal implications
Topic 05 · Law & liability

Where does professional work end and crime begin?

By the end of this topic you can:
  • Name the categories of computer-crime statutes that apply to security testing in Switzerland and the EU.
  • Explain why authorization is the single legal element that distinguishes a tester from a criminal.
  • Identify situations where a tester risks criminal liability even when acting in good faith.
  • Describe the data-protection rules (FADP, GDPR) that affect data encountered during a test.
  • Recognize when to stop testing and consult legal counsel.

Why authorization is everything

Consider three people at three keyboards, all running the same tool against the same target:

Person A Running Nmap against example.com for fun.

Committing a crime in most jurisdictions.

Person B Running Nmap against example.com under a signed contract with the CISO.

Doing professional work.

Person C Running Nmap because their manager said to — but they have not read the contract and the CISO has never heard of this scope.

Legally indistinguishable from Person A.

The law's view Intent and organizational chain of command are irrelevant. The law asks only: did the person operating the system have specific, documented authorization for what they did?

The Swiss legal framework

Relevant statutes for testers working in Switzerland sit in the Strafgesetzbuch (StGB / CP).

ArticleOffenceMaximum sentence
Art. 144bisDatenbeschädigung — altering, deleting, or rendering data unusable without authorization3 years (5 for aggravated cases)
Art. 147Fraudulent misuse of a data-processing system — manipulating data for financial benefit; relevant when tests touch financial systems5 years
Art. 150Obtaining a service by deception — bypassing access controls on paid services3 years
Art. 179noviesUnauthorized acquisition of personal data — when testing scoops up personal data3 years
Key rule A tester who exceeds the agreed scope can face charges under any of these articles. The contract does not protect them outside its terms.

The EU legal framework

Directive 2013/40/EU

  • Requires EU states to criminalize unauthorized access, system and data interference, illegal interception, and purpose-built attack tools.
  • Each state implements in national law (e.g., Germany: §§ 202a–202d, 303a, 303b StGB).

Art. 6 — Tools for offences

  • Criminalizes producing, selling, or possessing tools designed primarily for illegal use.
  • German "Hackerparagraph" (§ 202c StGB) is notoriously broad — a tester without a clear mandate is at risk.
Positive obligations EU Cyber Resilience Act, NIS2, and DORA create testing obligations on certain sectors — they shape demand for legal testing but do not themselves criminalize anything.
Cross-border reality OSINT and scanning may touch infrastructure in multiple jurisdictions. The law of each jurisdiction applies simultaneously.

Data-protection law: FADP and GDPR

Computer-crime and data-protection regimes are independent — authorization under StGB does not grant a free pass under data-protection law.

Swiss FADP (revised 2023)

  • Personal data must be processed lawfully, in good faith, and proportionately.
  • Accessing personal data without lawful basis violates FADP even with a signed pentest contract.

EU GDPR

  • Applies whenever personal data of EU residents is processed.
  • Tester is typically a processor; client is the controller.
  • Requires a written Data Processing Agreement (DPA) before the test begins.
  • DPA must cover: purpose, retention, security, sub-processors, breach notification.

Both regimes require proportionality — access only the data necessary to demonstrate the finding.

Handling personal data during a test

1 Minimize extraction
Demonstrate a finding with one or two synthetic records, or with field names rather than values — not all data the vulnerability allows.
2 Treat as temporary artifact
Any personal data produced is secured, encrypted at rest, and destroyed at engagement end with a written certificate of destruction.
3 Redact from reports
Real personal data must not appear in the report. Replace with synthetic placeholders.
4 Notify immediately
If testing reveals a personal-data breach (e.g., unauthenticated endpoint exposing customer data), notify the client without delay.

Where good-faith testers go wrong

  • Scope drift — an asset believed in scope; the client disagrees. Without a written record, the tester's word is insufficient.
  • Shared infrastructure — a server "of the client" is shared with another tenant who did not consent.
  • Reused infrastructure — a cloud server or attack tool from a prior engagement, potentially in a hostile jurisdiction.
  • "Helpful" pivoting — pivoting beyond scope to demonstrate impact. Without written authorization, this is a crime.
  • Wrong disclosure recipient — a finding containing personal data emailed to a developer not on the authorization list.
  • Personal data in screenshots — a screenshot capturing another customer's PII circulates in report drafts, internal chat, and the tester's laptop.
Pattern Each failure starts with a small, well-intentioned decision made without checking the written scope and DPA.

Discovering a prior intrusion

During testing the tester finds evidence that the system was already compromised before testing began — attacker logs, foreign tools on disk, unexpected accounts.

1 Stop immediately
Cease all further testing on that system.
2 Notify urgently
Contact the client's primary contact without delay.
3 Preserve, don't modify
Leave evidence of the prior intrusion intact for forensic use.
4 Hand over
Defer to the client's incident response process.
Why it matters Continuing to test risks contaminating evidence. Failing to notify quickly may itself be illegal under FADP, GDPR Art. 33–34, NIS2, or FINMA sector rules.

When to stop and get legal help

The cost of one hour of legal consultation is trivial compared to the cost of a wrong move.

Stop and consult a lawyer when any of these arise:

  • A scope dispute that written documents cannot resolve within minutes.
  • A likely prior intrusion or active attack is discovered.
  • Testing reaches third-party infrastructure whose owner has not consented.
  • Personal data appears in volumes or sensitivity not anticipated in the DPA.
  • The client requests something that feels outside the contract.
  • Cross-border data flow not planned in the DPA.
  • Law enforcement contacts the tester during or after an engagement.

The gap: vulnerability research outside a contract

Security researchers who discover vulnerabilities outside any contract and attempt responsible disclosure occupy a legal grey zone in Switzerland and the EU.

  • Both legal systems treat such researchers as suspects at first glance.
  • Protection depends on prosecutorial discretion or a formal Vulnerability Disclosure Program (VDP).
  • Limited "research exceptions" exist in some jurisdictions but are narrow and unreliable.
Safest position The safest place to be a security researcher is inside a contract — a paid engagement, a bug-bounty program, or a published VDP.
Practical advice Treat research exceptions as a flag to raise with legal counsel, not as a licence to test without authorization.

Check — Authorization in practice

Reflection

A junior developer at the client emails you: "Go ahead and test our staging environment." Is this authorization? What do you do?

Reveal answer

No — do not begin work. Authorization requires a signed document from someone with authority to bind the organization, with explicit named scope. Politely acknowledge the email and request that the same instruction be captured in the formal engagement document. Written authorization protects both the tester and the client.

What you take home

  • Authorization is the single element that converts a criminal act into professional work — intent is no substitute.
  • Swiss StGB articles 144bis, 147, 150, and 179novies all apply to actions testers routinely perform.
  • EU Directive 2013/40/EU and national implementations (e.g., German § 202c) can criminalize tool possession itself.
  • Computer-crime authorization and data-protection compliance are independent requirements — both must be satisfied before a test begins.
  • A Data Processing Agreement is mandatory whenever personal data of EU residents may be encountered.
  • When in doubt — scope dispute, prior intrusion, third-party infrastructure, law enforcement contact — stop and consult a lawyer.
  • The safest place to do security research is inside a contract, bug-bounty, or published VDP.

Next: Topic 06 — Client Consent and Ethics. The legal foundation becomes the practical engagement document.

END · TOPIC 05

Authorization first. Always.

Before the next session: re-read the scope document from Topic 04 and identify every point where lack of written authorization could expose a tester to liability.