Authorisation, the law, and when you are obliged to report

Objective 1.2 in this course covers legal and ethical compliance — CompTIA describes it as ensuring authorisation letters, mandatory reporting and adherence to regulations.

Why this matters

Everything else in this course is a technique. This is the objective that decides whether using those techniques makes you a professional or a defendant.

It is also examined more heavily than its size suggests, because CompTIA can write scenario questions here that have exactly one defensible answer. A question about privilege escalation may have two plausible routes; a question about what to do when you find evidence of a live intrusion does not.

The lesson

The authorisation letter, and testing nothing before it is signed

The authorisation letter — often called a permission to test or get out of jail free letter — is the document that makes your activity legal. It should name, at minimum:

• who is authorising, with the standing to do so
• what may be tested: addresses, domains, applications, accounts
• when: the testing window, including any blackout periods
• what techniques are permitted, particularly anything with an availability risk such as denial-of-service or brute-force
• emergency contacts, on both sides, reachable during the window

Two rules that scenario questions reward:

1. Nothing starts before it is signed. Not reconnaissance, not "just a quick port scan to plan the work". A verbal go-ahead from an enthusiastic client contact is not authorisation.
2. Carry it while you work. If you are testing on site, you want the letter on you. Being detained by a security guard who is doing their job correctly is an occupational hazard, and the letter is what ends it.

Who can actually grant permission for a given system

This is the part that catches people, and the exam knows it.

The client can only authorise testing of things the client controls. That sounds obvious until you meet the common cases:

• Cloud-hosted assets. The client owns the instance; the provider owns the infrastructure. Providers publish their own rules about what testing they permit against workloads on their platform, and those rules apply on top of the client's permission, not instead of it.
• Shared hosting. A test against a shared server touches other tenants.
• Third-party SaaS. The client's data is in it, but the client does not own the application and cannot authorise you to attack it.
• Managed service providers. The device in the client's rack may be contractually the MSP's.
• Staff-owned devices. A personal phone enrolled in a BYOD programme is not the client's to volunteer.

The instinct to build: ownership is a question you ask, not an assumption you make. When a scenario mentions a third party at all, the expected answer is almost always to stop and confirm authorisation before proceeding.

Computer-misuse law in outline, and why intent is not a defence

Jurisdictions vary and PT0-003 is an international exam, so it examines principles rather than statutes. The principle that matters nearly everywhere:

The offence is unauthorised access, not damage, and not motive. In most computer-misuse legislation, accessing a system without authorisation is the offence in itself. That you meant no harm, found a real vulnerability, or intended to report it is mitigation at best — it is not a defence to the access.

Two consequences for a working tester:

• Good intentions do not create authorisation. Finding a flaw in a system you were not asked to test and probing further "to confirm it" makes the position worse, not better.
• Scope creep can become an offence. The moment you move outside what was authorised, the authorisation stops covering you — even mid-engagement, even for the same client.

Mandatory reporting: what you must escalate immediately regardless of scope

Some findings cannot wait for the report. They stop the work.

The clearest case: evidence that someone else is already in the environment. If you find an active compromise — an attacker's tooling, live command and control, signs of exfiltration — you stop, preserve what you have, and notify your emergency contact immediately. Continuing to test contaminates an incident scene and may destroy the evidence their responders need.

Others that commonly carry an immediate obligation:

• Evidence of illegal content, where the obligation is often statutory and reporting is to law enforcement rather than to the client.
• Exposure of regulated personal data where breach-notification law imposes a clock, often measured in hours.
• A live safety risk, typically in industrial or medical contexts.
• A critical flaw you have just proven is exploitable from the internet, which most engagement agreements require you to raise at once rather than hold for the report.

Agree the escalation path before the engagement, in writing, including who to call outside business hours. Deciding who to phone while looking at someone else's malware is too late.

Evidence handling and the client's data you were never meant to read

Succeeding at this job means ending up holding the client's data: credentials, database extracts, documents, screenshots. That material is theirs, it is frequently regulated, and you are now a processor of it.

The working standard:

• Take the minimum that proves the finding. One record demonstrates database access as well as ten thousand, and carries a fraction of the risk.
• Redact in the report. Enough to prove it, never the live value. A password quoted in full in a report is a new vulnerability that you created.
• Encrypt at rest and in transit, including the report itself.
• Delete on the agreed schedule, and be able to say that you did.
• Never use it. Credentials recovered during a test are for demonstrating the finding within scope, and for nothing else.

The same principle appears again in lesson 29 on credential dumping: material you dump is client data first and evidence second.

What to take into the exam

• No signed authorisation, no activity — including reconnaissance.
• When a third party owns any part of the target, confirm authorisation before proceeding; that is nearly always the expected answer.
• Unauthorised access is the offence; intent does not cure it.
• Evidence of an existing compromise means stop and escalate immediately, not investigate further.
• Minimum necessary data, redacted in the report, deleted on schedule.