Study Guide
Ethics, Authorisation and Responsible Disclosure
Why permission separates security work from harm: authorisation and scope, discovering without exploiting, reporting concerns and disclosing vulnerabilities responsibly.
Lesson 1.6 Cybersecurity Foundations
The knowledge that helps a defender find a weakness is the same knowledge an attacker uses to exploit it. This lesson explains when it is acceptable to look for weaknesses, what to do if you find one, and how to report it so that it gets fixed rather than abused.
Stage: Think
The same action, two meanings
Two people walk round the outside of a house one evening, trying each window to see whether any is unlocked. One is a security adviser the owner has asked to check the house. The other is a stranger.
Think it through
- Hint 1: Imagine the owner coming home and finding each of them.
Show the answer
Answer: B. The owner asked the adviser, for the owner’s benefit.
The action is identical. What differs is permission from the owner and the purpose of the check.
Think it through
The owner asked the adviser to check only the front of the house. From the front, the adviser can see that a back window looks open. What should the adviser do?
- Hint 1: What did the owner actually agree to?
- Hint 2: Who decides whether the back is checked too?
Show what happens
Tell the owner, and ask before going any further. Permission covers what was agreed, and only the owner can widen it. The rest of this lesson builds on these two ideas: permission, and its boundaries.
Where the comparison stops. A house has one owner, who can obviously give permission. Computer systems are often run by one organisation for another, so working out who is entitled to give permission is part of the job, as this lesson shows.
Stage: Explain
Why ethics comes first
Authorisation and intent are fundamental. Permission and the purpose of an activity help distinguish legitimate security testing from criminal activity. Trying a password, requesting a web page in an unusual way or connecting to a service can be routine security work or an offence. The action can look identical; what differs is whether the person had permission and why they were doing it.
Thinking like an attacker means following an attacker’s possible next steps to see where a control could interrupt them. That is reasoning about attacks in order to defend against them. It is not permission to carry any of those steps out.
Check your understanding
Show the answer
Answer: A. Yes: reasoning about an attack is not doing it.
Thinking like an attacker is reasoning in order to defend. Trying any of the steps against a real system would need permission first.
Stage: Predict
Permission and scope
The rule is clear: always obtain written permission before security testing. Clear authorisation defines what is allowed and protects both the tester and the organisation. A written agreement means everyone can check afterwards exactly what was approved.
Think it through
Show the answer
Answer: C. No: having access is not permission to test.
An account gives access; it does not give permission to test security. That needs agreement from someone entitled to give it.
This is a different use of the word from the access-control authorisation in Least Privilege, which decides what a signed-in user or process may access or do. The two are easily confused. Having an account on a system, even an administrator account, gives access to it; it does not give permission to test its security.
Think it through
Show the answer
Answer: B. No: the agreed time is part of the permission too.
Read on: permission covers a defined scope and timeframe, and anything outside either is unauthorised.
Permission is only half of it. A penetration test is an assessment performed within a defined scope and timeframe. The testing scope is the boundary of what the permission covers, and everything outside it is still unauthorised.
A supplementary illustration. Each boundary sits inside the one before it; only the innermost area is authorised testing.
Everything you could technically reach
Being able to connect to a system says nothing about whether you may test it.
Systems the person giving permission controls
Permission must come from someone entitled to give it. A customer cannot authorise testing of their provider’s shared infrastructure.
What they agreed in writing
Which systems and addresses, which dates and times, which techniques are allowed and which are excluded, and who to contact.
PermittedWhat the test actually does
Stays inside every boundary above. Anything unexpected is paused and raised with the contact, not explored.
A tester is authorised in writing to test a company’s booking website between 09:00 and 17:00 on two agreed days.
- In scope. They test the booking pages as agreed.
- Something unexpected. A page links to an administration server on a different domain that is not listed in the agreement.
- Stop. However interesting it looks, the server is outside the written scope. Testing it would be unauthorised, even though the tester is authorised for the booking site.
- Record and raise it. The tester notes what they saw and tells the company’s named contact that an unlisted server was found.
- Wait for written confirmation. Only if the company extends the scope in writing, and has authority over that server, can it be tested.
Why that is the right outcome: authorisation covers what was agreed, with someone entitled to agree it. A link from an in-scope page does not stretch the agreement to wherever the link leads.
There is an important limit: a penetration test cannot guarantee that every vulnerability will be discovered, because it works within agreed boundaries and time, and a malicious attacker may have far longer. A clean report shows what was tested, not that nothing is wrong.
Check your understanding
Show the answer
Answer: B. Disagree: it covers only what was tested, and when.
A test works within agreed boundaries and time. A clean report shows what was tested, not that nothing is wrong.
Stage: Predict
Discovering is not permission to exploit
An analogy helps: imagine discovering that a bank had accidentally left a door unsecured. Someone who notices could report it so it can be fixed, or could try to take advantage of it. The principle follows directly: discovering a weakness does not provide permission to exploit it, and authorisation and ethical conduct remain essential when investigating vulnerabilities.
A supplementary illustration of the bank-door principle. The discovery is the same; what happens next decides whether it helps or harms.
Starting pointYou notice something that looks like a security weakness in a system you are not authorised to test.
✓ Report it
- Stop. Do not probe further to “confirm” it.
- Write down what you saw, when and how, without collecting more data.
- Report it privately to someone who can fix it.
- Keep the details confidential until it is fixed.
OutcomeThe owner can fix the weakness before anyone else uses it.
✗ Exploit it
- Try it “just to see if it works”.
- Access data or functions you were never given.
- Share or publish what you found.
OutcomeHarm to the owner and to the people whose data is exposed, and potentially a criminal offence, whatever the intention.
The same applies to tools. Shodan, a search engine for devices and services that can be reached from the internet, and breached-data services, which list passwords and other details leaked in past incidents, can reveal exposed systems and leaked information, which raises the question of how such tools can be used ethically. Being able to find something does not make it appropriate to use it; Vulnerabilities and Exposure explains responsible use of those services.
Think it through
Show the answer
Answer: C. No: checking means opening another customer’s data.
Trying it would be deliberately accessing another customer’s data without permission. The example below shows what to do instead.
You buy something from an online shop. The order confirmation page address ends in order=1041. You notice that changing it to order=1040 might show someone else’s order.
- Do not try it. Changing the number to look would mean deliberately accessing another customer’s personal data without permission.
- If you already saw something by accident, stop there, do not repeat it and do not save or share what you saw.
- Find the right contact. Look for the shop’s security contact or vulnerability disclosure policy, or use its customer service as a last resort.
- Report privately and briefly. Describe the pattern you noticed and how you came across it. Do not include anyone else’s data.
- Let them fix it. Do not post about it publicly while it could still be used.
This scenario is fictional.
Stage: Predict
Responsible disclosure
Think it through
Show the answer
Answer: B. No: tell the maker privately first, so it can be fixed.
Publishing first would tell attackers before anyone could fix the flaw. The steps below report it privately and publish, if at all, after a fix.
The bank-door analogy points towards reporting a weakness so it can be corrected. The professional name for doing this carefully is responsible disclosure, also called coordinated vulnerability disclosure.
A simplified sequence, one stage at a time, saying who acts at each. Organisations publish their own rules, which take precedence.
You
Step 1 of 4: Find the right contact
Many organisations publish a vulnerability disclosure policy or a security contact. Follow its rules.
You
Step 2 of 4: Report privately
Give enough detail for the owner to understand and reproduce the issue, and no more data than necessary.
The owner
Step 3 of 4: Investigate and fix
The owner investigates and fixes the weakness. You keep the details confidential while systems are still exposed.
You and the owner
Step 4 of 4: Publish, if at all, after the fix
Details may be shared once a fix is available, ideally in agreement with the owner.
- Bug bounty programmes are a specific form of permission: an organisation invites testing of named systems under published rules, and pays for valid reports. Their rules define the scope, and testing outside them is still unauthorised.
- Never ask for payment in exchange for not publishing. Demanding money for a report that was not invited can look like extortion, however it is intended.
Check your understanding
Show the answer
Answer: C. No: only the systems named in the rules are in scope.
A bug bounty programme is a specific form of permission, and its rules define the scope. Testing outside them is still unauthorised.
Stage: Check
Reporting concerns inside an organisation
Most security concerns a beginner meets will be inside their own organisation, not in someone else’s systems. The same principles apply to the accounts, devices and services met in IT support, and People, Processes & Technology shows why reports only help when a process acts on them.
Think it through
Show the answer
Answer: A. No: note what you saw and report it; others investigate.
Report what you saw through the organisation’s route, and let those responsible investigate.
Suppose you notice that a shared folder containing payroll documents appears to be open to all staff. Do not open the files to check how bad it is. Note what you saw and where, then report it through your organisation’s route: your line manager, the IT or security team, or the incident process. Stick to the facts, keep the details to the people who need them, and let those responsible investigate. Raising a concern promptly is always appropriate; investigating beyond your role is not.
Stage: Explain
Legal and professional considerations
Permission is the line between legitimate testing and criminal activity. The same care applies to data: sensitive information should not be entered into an artificial intelligence (AI) system without first considering the organisation’s policies, its rules on how sensitive each kind of information is, and legal obligations, including the UK’s main data-protection law, UK GDPR.
- The law: in the UK, the Computer Misuse Act 1990 makes unauthorised access to computer material an offence. Permission from someone entitled to give it is what makes security testing lawful; good intentions do not.
- Data protection: information found through a weakness, or in breached data, is often personal data. Accessing, keeping or sharing it can create legal obligations and harm real people.
- Professional conduct: employers’ policies, contracts and professional codes of conduct set further expectations. When unsure, ask before acting.
This is general educational information, not legal advice.
Check your understanding
Show the answer
Answer: C. That nobody entitled to give it gave permission.
Under the Computer Misuse Act 1990, permission from someone entitled to give it is what makes access lawful; good intentions and the absence of damage do not.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
- Hint 1: Who has authority over the charity’s website, and has that person agreed in writing?
Show the answer
Answer: B. Get written permission from someone entitled to give it.
Permission must come, in writing, from someone entitled to give it. Working somewhere does not make a person entitled to authorise testing.
Apply it
- Hint 1: What decides whether it may be shared: how well known the tool is, or the information and the rules about it?
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: True
Testing requires written permission before it begins. Authorisation defines what is allowed.
Revision sources: Session 1: Cyber Fundamentals Part 1 (Classroom session record)
Show answer
Answer: Permission and purpose: the same technical activity can be legitimate security testing or criminal activity.
Authorisation and intent are fundamental: permission, and the purpose of an activity, are what separate legitimate security testing from criminal activity. The two actions here are technically identical, so the tool, the result and the person’s skill cannot be what separates them.
Revision sources: Session 1: Cyber Fundamentals Part 1 (Classroom session record)
Show answer
Answer: Do not explore it further: discovering a weakness gives no permission to exploit it, and it can be reported so that it can be fixed.
Discovering a weakness does not give permission to exploit it. Think of a bank that has accidentally left a door unsecured: someone who notices can report it so that it is corrected, or take advantage of it. Downloading a document or probing further to “prove” the problem goes beyond noticing it, and being able to reach something is not permission to access it.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record)
Show answer
Answer: Stop, record what was seen and raise it with the company’s contact; the server may only be tested if the scope is extended in writing by someone entitled to authorise it.
Permission distinguishes legitimate testing from criminal activity. An authorised test is limited to its agreed systems, times and techniques, so anything outside that scope is unauthorised, even for a tester with permission elsewhere. Being linked from an in-scope page, or owned by the same company, does not bring a system into scope.
Revision sources: Session 1: Cyber Fundamentals Part 1 (Classroom session record) · Ethics, Authorisation and Responsible Disclosure (Supplementary Study Guide explanation)
Show answer
Answer: Report it privately through the published contact with only the detail needed, and allow time for a fix.
Responsible disclosure reports a weakness privately to the organisation that can fix it and allows time for a fix before any details are published; following the organisation’s published policy and sharing no more data than necessary fit that approach. Publishing first exposes users while the weakness is still open. Probing further goes beyond noticing the flaw, and discovering a weakness gives no permission to exploit it. A payment demand in return for silence is not responsible disclosure.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record) · Ethics, Authorisation and Responsible Disclosure (Supplementary Study Guide explanation)
Show answer
Answer: The business’s permission alone does not cover the provider’s servers; they need separate authorisation.
Permission and purpose separate legitimate security testing from criminal activity. Good intentions do not replace permission, permission must come from someone entitled to give it, and in the UK the Computer Misuse Act 1990 makes unauthorised access to computer material an offence. The business’s permission does not by itself authorise testing the provider’s shared servers; separate authorisation from someone entitled to grant it would be required, whatever the tester intends. Being publicly reachable is not permission either. This is general educational information, not legal advice.
Revision sources: Session 1: Cyber Fundamentals Part 1 (Classroom session record) · Ethics, Authorisation and Responsible Disclosure (Supplementary Study Guide explanation)
Study and revision
Practise through the Security Assessment & Penetration Testing topic. Its questions cover written permission, permission and purpose, the bank-door principle, scope boundaries, responsible disclosure and who is entitled to give permission under the Computer Misuse Act. The last three draw on this lesson’s supplementary explanation, which is general educational information, not legal advice.
Stage: Consolidate
What to remember
- Permission and purpose, not the technique, separate security testing from harm.
- Permission must come in writing from someone entitled to give it, and covers only the agreed scope and time.
- Having access to a system is not permission to test it.
- Finding a weakness gives no permission to exploit it: stop, note it and report it privately.
- Inside an organisation, raise concerns promptly and leave the investigation to those responsible.
Key terms
- Security-testing authorisation
Permission from someone with appropriate authority to carry out specified security-testing activities against particular systems, within an agreed scope.
- Testing scope
The agreed boundaries of an authorised security test: which systems, times and techniques are allowed, and which are excluded.
- Penetration test
An authorised assessment that looks for weaknesses in systems and safely demonstrates them, within an agreed scope and timeframe.
- Responsible disclosure
Reporting a discovered vulnerability privately to the organisation that can fix it, and allowing time for a fix before any details are published.
Common misunderstandings
Being able to connect to a system gives no permission to test it. Permission comes from someone entitled to give it, in writing.
Intent is part of the picture, but good intentions do not replace permission. Unauthorised access can be an offence even when nothing is damaged.
Authorisation covers the agreed scope only. Anything outside it needs its own written permission.
Details are shared privately with the owner first, and made public, if at all, after a fix is available.
Further reading
Lesson sources and acknowledgements
Sources and scope
- Taught in Session 1 (see the Session 1 Learning Log): authorisation and intent as fundamental; permission and purpose distinguishing security testing from criminal activity; obtaining written permission before security testing; and thinking like an attacker as reasoning, not action.
- Taught in Session 2 (see the Session 2 Learning Log): the bank-door analogy and the principle that discovering a weakness does not give permission to exploit it; penetration testing within a defined scope and timeframe, and its limits; ethical use of tools such as Shodan; and considering policy, data classification and UK GDPR before entering information into AI systems.
- Supplementary explanation: the scope boundaries, the report-or-exploit paths, responsible disclosure and bug bounty programmes, the Computer Misuse Act 1990, and the data-protection and professional-conduct points. These are my explanations, not the instructor’s words.
- Fictional examples: the out-of-scope link, the online shop order and the payroll folder are invented for teaching.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the house opening question, every question asked in the lesson with its feedback and hints, the apprentice, administrator, after-hours, app, bug bounty, charity and chatbot examples and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. I have not carried out security testing or reported a vulnerability; Session 1’s log records that any future authorised practical work will be recorded separately.
The main UK law on computer crime. It makes unauthorised access to computer material, and related acts, criminal offences.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
Information becoming accessible to an unauthorised party. Disclosure threatens confidentiality, even if the original information is unchanged.
An authorised assessment that looks for weaknesses in systems and safely demonstrates them, within an agreed scope and timeframe.
Information relating to an identified or identifiable living individual.
A document that sets organisational rules and expectations, defining what is and is not permitted.
Reporting a discovered vulnerability privately to the organisation that can fix it, and allowing time for a fix before any details are published.
The agreed boundaries of an authorised security test: which systems, times and techniques are allowed, and which are excluded.
A search engine that indexes internet-connected devices and the services they expose, such as servers, networking equipment and webcams.
The UK’s general data-protection law, applied alongside the Data Protection Act 2018, governing how personal data is processed.
A weakness that a threat may exploit.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.