Ethical Hacking Foundations, Law, and Governance

Introduction

Penetration testing is an authorized, controlled assessment of information systems, applications, networks, devices, or human processes. Its purpose is to identify weaknesses, demonstrate their practical significance, and provide evidence that helps an organization reduce risk. Ethical hacking uses many of the same techniques as malicious hacking, but differs fundamentally in authorization, purpose, scope, accountability, and handling of information.

A penetration test is therefore not simply an attempt to “break into” a system. It is a professional engagement governed by objectives, contractual permissions, technical constraints, safety controls, legal duties, and reporting requirements. Poorly governed testing can cause outages, expose personal data, violate computer-misuse laws, or create liability for both the tester and the client.

This chapter establishes the foundation required before technical testing begins. It explains terminology, security principles, attacker and defender perspectives, assessment types, rules of engagement, authorization, responsible disclosure, privacy, evidence handling, professional ethics, cybercrime law, and governance obligations.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish penetration testing from vulnerability assessment, security auditing, red teaming, and ethical hacking.
2. Apply confidentiality, integrity, availability, authenticity, and accountability principles to testing decisions.
3. Compare attacker and defender perspectives and explain how they influence assessment design.
4. Classify penetration tests by knowledge, visibility, timing, and purpose.
5. Explain the contents and importance of authorization documents and rules of engagement.
6. Apply responsible-disclosure, privacy, evidence-handling, and professional-ethics principles.
7. Identify major legal and governance obligations relevant to authorized testing.
8. Evaluate a proposed engagement and identify unsafe, unauthorized, or poorly governed activities.

1. The Meaning and Purpose of Ethical Hacking

1.1 Hacking, ethical hacking, and penetration testing

“Hacking” describes the creative use of technical knowledge to understand, modify, or influence systems, often in ways not anticipated by their designers. The word is not inherently synonymous with crime. However, unauthorized access, damage, interception, fraud, or misuse may constitute criminal or civil wrongdoing.

Ethical hacking is hacking performed with legitimate authorization and a defensive or assurance objective. A penetration test is a structured form of ethical hacking with a defined scope, methodology, evidence standard, risk-management process, and report. An ethical hacker may also perform secure configuration reviews, threat modelling, malware analysis, or social-engineering simulations that are not full penetration tests.

The central professional question is not “Can this action be performed?” but “Is this action necessary, authorized, proportionate, safe, and appropriately documented?”

1.2 Important terminology

1.3 Penetration testing compared with related activities

A vulnerability assessment usually identifies and ranks weaknesses using scanners, configuration analysis, and review. It may not attempt exploitation. A penetration test validates selected weaknesses through controlled exploitation and examines how far an attacker could progress. Exploitation is not automatically required for every finding; safety and evidence requirements determine whether a proof is appropriate.

A security audit evaluates conformity with a policy, standard, regulation, or control framework. An audit may examine documentation and operating effectiveness without attempting intrusion. A red-team exercise is generally broader and more realistic: it tests whether an organization can prevent, detect, respond to, and recover from a simulated adversary. A red team may use stealth, deception, physical access, or social engineering under carefully defined conditions.

A vulnerability scan is an automated technical activity. It can be useful, but it is not equivalent to a penetration test because scanning may produce false positives, miss business-logic flaws, and provide little evidence about attack paths or organizational response.

2. Security Principles and Risk Thinking

2.1 The CIA triad

The classic CIA triad comprises confidentiality, integrity, and availability.

• Confidentiality means preventing unauthorized disclosure. A test must avoid unnecessary access to personal, financial, health, or proprietary information.
• Integrity means protecting information and systems from unauthorized alteration or destruction. Testers should not modify production data merely to prove access.
• Availability means ensuring that authorized users can access systems when needed. High-volume scans, denial-of-service techniques, or fragile exploits can disrupt operations.

Security decisions often involve tension among these objectives. For example, collecting a full database dump may prove confidentiality impact but create substantial privacy and storage risk. A safer alternative may be to retrieve a small, synthetic, or redacted sample and record metadata rather than content.

Additional principles are important in professional testing. Authenticity concerns confidence that an identity, message, or system is genuine. Accountability links actions to responsible identities through logging and records. Non-repudiation supports confidence that an action or communication cannot credibly be denied, although technical logs rarely establish this alone.

2.2 Threat, vulnerability, impact, and risk

A vulnerability is not automatically a high-risk issue. Risk depends on the likelihood of harmful exploitation and the consequences if harm occurs. A publicly exposed administrative interface with weak authentication may be more urgent than an equally severe weakness in an isolated laboratory system.

A simple conceptual model is:

This is a planning model rather than a universal measurement law. “Likelihood” and “impact” must be defined by the organization’s chosen risk method. They may be ordinal categories rather than precise probabilities, so multiplying category numbers does not create a scientifically exact risk value. The model is useful for prioritization, not for pretending that uncertainty has disappeared.

Threat modelling adds context by asking who may attack, what they want, which assets they target, what trust boundaries exist, and what controls could interrupt the attack path. Penetration testing should be driven by meaningful risk questions rather than by a random collection of tools.

2.3 Defence in depth and least privilege

Defence in depth uses multiple, independent or partially independent controls. If a web application contains an input-validation defect, network segmentation, strong identity controls, monitoring, backups, and incident response may still limit harm.

Least privilege requires users, processes, and testers to receive only the access needed for a legitimate task. Test accounts should be labelled, time-limited where possible, monitored, and disabled after the engagement. A tester should not request domain-administrator access when a lower-privileged account can answer the assessment question.

3. Attacker and Defender Perspectives

3.1 The attacker perspective

An attacker typically seeks an objective, not merely a vulnerability. Objectives may include financial gain, espionage, disruption, coercion, ideological influence, or unauthorized access to valuable information. Attackers may combine reconnaissance, initial access, execution, persistence, privilege escalation, lateral movement, collection, and exfiltration.

This perspective encourages testers to examine attack paths and business consequences. A low-severity weakness can become significant when combined with a stolen credential, poor segmentation, or excessive permissions. Testers should therefore document relationships among findings rather than treating every weakness as isolated.

3.2 The defender perspective

Defenders operate under continuous uncertainty. They must maintain services, apply patches, manage identities, monitor events, investigate alerts, preserve evidence, and respond to incidents. A test is valuable when it improves these capabilities, not merely when it produces an impressive exploit demonstration.

A mature assessment asks:

• Would existing controls prevent the action?
• If prevention failed, would monitoring detect it?
• Could analysts distinguish the activity from normal operations?
• Are response procedures, contacts, and decision rights clear?
• Can the organization recover without unacceptable data loss or downtime?

The attacker and defender perspectives should be combined. Offensive findings should be translated into defensive recommendations, detection opportunities, control owners, and practical remediation priorities.

4. Types and Designs of Penetration Tests

4.1 Knowledge and visibility

A black-box test gives the tester little internal information and approximates an external attacker. It tests reconnaissance, exposed services, and the organization’s external attack surface, but may spend significant time rediscovering basic information.

A white-box test provides extensive information such as architecture diagrams, source code, credentials, and configuration details. It supports deeper coverage and is efficient for complex systems, but may not represent an uninformed attacker.

A grey-box test provides limited internal knowledge or user-level access. It often balances realism with coverage and can model a compromised account or ordinary user.

These labels describe information available to the tester, not whether the test is authorized. Every type still requires explicit permission.

4.2 Origin and target

External testing begins from outside the organization’s trusted environment. Internal testing begins from an internal network, workstation, cloud tenant, or assumed-compromised account. Application testing examines authentication, authorization, input handling, session management, business logic, and data protection. Wireless, mobile, cloud, physical-security, and social-engineering assessments require specialized scope and safety controls.

4.3 Timing and collaboration

A covert or blind exercise limits the number of personnel who know the test is occurring. A covert design can assess detection and response, but raises operational and ethical concerns. A collaborative or announced test allows defenders to coordinate and may be safer for production systems. The choice depends on objectives, risk tolerance, regulatory requirements, and the maturity of the security-operation function.

A test should not be made covert merely to appear realistic. Realism is subordinate to authorization, safety, and the client’s legitimate objectives.

5. Authorization and Rules of Engagement

5.1 Authorization as the foundation

Authorization should be written, specific, current, and issued by a person or entity with authority over the systems concerned. A verbal request such as “see whether you can get into the server” is inadequate. Authorization must cover the actual asset owner, service provider, cloud platform, data controller, and relevant third parties where applicable.

A professional authorization package commonly identifies:

1. legal entities and authorized signatories;
2. systems, domains, IP ranges, applications, facilities, and accounts in scope;
3. objectives and success criteria;
4. permitted and prohibited techniques;
5. testing windows and blackout periods;
6. source locations and tester identities;
7. rate limits and availability safeguards;
8. data-access and evidence-handling rules;
9. emergency contacts and stop conditions;
10. incident-escalation procedures;
11. reporting recipients, deadlines, and classification;
12. retention, deletion, and ownership of test materials; and
13. permission to use subcontractors, tools, or third-party services.

Authorization to test one customer’s environment does not automatically authorize testing a shared hosting provider, cloud control plane, neighboring tenant, employee’s personal device, or external supplier.

5.2 Rules of engagement

Rules of engagement convert legal permission into operational boundaries. They should state what the tester may do and what must not be done. Prohibited activities may include denial-of-service testing, destructive payloads, persistence, physical entry, phishing, malware deployment, password spraying, access to real personal records, or exploitation of third-party systems.

Rules should define stop conditions. Examples include service instability, unexpected access to sensitive data, evidence of a real attacker, contact from law enforcement, safety concerns, or deviation from the approved source address. The tester must stop, preserve relevant information, notify the designated contact, and await instructions.

A test plan should also include a communication matrix. It should identify the technical lead, business owner, incident manager, legal contact, cloud provider contact, and emergency telephone route. Email alone may be ineffective during an outage or suspected compromise.

6. Responsible Disclosure and Communication

When a tester discovers a weakness outside the agreed scope, the correct response is not to investigate it freely. The tester should minimize interaction, record the minimum evidence needed, and notify the client or designated coordinator. If no contact exists, the tester should follow a recognized vulnerability-disclosure process and seek legal advice where necessary.

A responsible disclosure usually contains a clear description, affected product or service, impact, reproduction steps that avoid unnecessary harm, evidence, suggested mitigations, and a proposed coordination timeline. Sensitive details should not be published before the owner has a reasonable opportunity to respond, unless law, public safety, or an established disclosure policy requires otherwise.

Public disclosure is not a threat or bargaining mechanism. Testers should never demand payment, publicity, employment, or other benefit in exchange for withholding information. Bug-bounty programs may define different authorization and disclosure rules, but researchers must remain within their published scope and conditions.

7. Privacy and Evidence Handling

7.1 Data minimization

Penetration testing can expose credentials, personal information, communications, medical information, financial records, or confidential business material. The tester should follow data minimization: access, copy, retain, and report only what is necessary for the assessment objective.

Preferred practices include using synthetic data, redacting screenshots, hashing identifiers when content is unnecessary, limiting evidence access, encrypting storage and transfer, separating client data from other engagements, and deleting material according to the agreed schedule. Test reports should not reproduce secrets in full. Passwords, tokens, private keys, and session cookies should be revoked or rotated immediately when exposed.

Privacy duties depend on jurisdiction and role. In many legal systems, organizations may be data controllers or custodians while testers act as processors or service providers. Contracts should define permitted processing, security measures, breach notification, subcontracting, cross-border transfer, retention, and deletion.

7.2 Evidence integrity and chain of custody

Evidence should be reliable, attributable, and sufficient to support a finding. Record the date and time with time zone, tester, source system, target, tool or method, command or request, result, and relevant conditions. Preserve original files where appropriate and work from copies.

Cryptographic hashes can help demonstrate that a file has not changed. For a file F, a cryptographic hash function produces a digest h = H(F). A hash is an integrity aid, not proof that the file is truthful, lawfully obtained, or complete. The algorithm, tool version, acquisition method, and storage controls should be recorded.

Chain-of-custody records should document who collected evidence, when it was collected, how it was transferred, where it was stored, who accessed it, and when it was disposed of. In ordinary consulting work, evidence may support remediation rather than court proceedings; nevertheless, disciplined handling increases credibility and reduces accidental disclosure.

8. Professional Ethics

A competent tester should act with honesty, competence, independence, fairness, confidentiality, and accountability. Professional codes from security associations commonly express these principles, although a code does not replace law or a contract.

Ethical practice requires refusing work that cannot be authorized or performed safely. It also requires declaring conflicts of interest, maintaining technical competence, supervising junior personnel, protecting client information, and communicating limitations honestly. A tester must not exaggerate impact, conceal uncertainty, claim tools performed work they did not perform, or present an unverified scanner result as a confirmed compromise.

Independence is especially important when a tester is asked to assess a system they designed or configured. Such work may be possible with safeguards, but the conflict should be disclosed and the assurance limitation stated.

9. Law and Governance

9.1 Computer-misuse and cybercrime law

Most jurisdictions criminalize some combination of unauthorized access, unauthorized alteration, interception, impairment of systems, distribution of malicious tools for criminal purposes, fraud, identity misuse, and unlawful handling of personal data. Legal terminology and exceptions differ substantially. “I intended to help” is not a universal defence to unauthorized access.

A tester must consider not only the client’s permission but also the authority of the person giving it, the location of systems and data, third-party terms of service, cross-border activity, and the methods used. Sending exploit traffic through a third-party platform, scanning a shared provider, or accessing another tenant can create legal exposure even when the client requested a test.

This chapter provides educational guidance, not legal advice. Before testing production systems, students and professionals should consult applicable national law, organizational counsel, contractual terms, and sector-specific requirements.

9.2 Privacy and breach obligations

Privacy laws may regulate collection, access, use, disclosure, retention, and transfer of personal information. Security testing is not a blanket exemption. A tester who discovers personal data must follow the engagement’s instructions and escalate promptly. If the data was exposed to an unauthorized party, the organization may have breach-assessment and notification duties.

Sector-specific governance may apply to healthcare, finance, education, telecommunications, government, and critical infrastructure. Requirements can include access logging, segregation of duties, retention periods, independent assessment, incident reporting, and evidence of remediation.

9.3 Governance frameworks and standards

Organizations may use governance frameworks and standards to structure security responsibilities. Examples include ISO/IEC 27001 for information-security management systems, ISO/IEC 27002 for control guidance, the NIST Cybersecurity Framework, NIST guidance on security testing, and the OWASP Testing Guide for web-application testing. These resources support consistency but do not themselves grant permission to test.

Governance assigns ownership and accountability. A useful assessment report maps findings to affected assets, business risks, control owners, remediation actions, target dates, residual risk, and acceptance authority. Risk acceptance should be a deliberate decision by an authorized owner, not an informal assumption by the tester.

10. A Governed Testing Lifecycle

A sound lifecycle contains six connected stages:

1. Initiation: define objectives, stakeholders, legal authority, and business context.
2. Planning: establish scope, methods, schedule, contacts, safety controls, and evidence rules.
3. Discovery and validation: collect information and validate weaknesses within approved limits.
4. Controlled demonstration: prove material impact using the least harmful method sufficient to support the conclusion.
5. Reporting: explain findings, evidence, likelihood, impact, limitations, and remediation priorities.
6. Remediation and retest: verify corrective action and document residual risk.

The lifecycle is iterative. A serious finding may require immediate escalation rather than waiting for the final report. Conversely, a suspected vulnerability may be downgraded after safe validation reveals that a compensating control prevents exploitation.

11. Illustrative Case Study: An E-Commerce Assessment

Background

A fictional online retailer, Northstar Retail, asked an external consultancy to assess its customer portal before a seasonal sales campaign. The portal was hosted in a cloud environment and connected to payment, inventory, and customer-support services.

Problem

The business wanted assurance that attackers could not access customer accounts or payment-related data. Operations required uninterrupted service, and the cloud provider prohibited unapproved testing of shared infrastructure.

Analysis

The consultancy first identified the retailer as the authorized client, confirmed that the cloud provider’s testing policy was satisfied, and excluded payment-provider infrastructure and denial-of-service activity. The test used a grey-box design: the team received test accounts, architecture information, and a list of synthetic customer records.

The rules of engagement required rate limits, prohibited persistence and destructive actions, and named an emergency contact. Evidence was to be stored in encrypted form and deleted after the agreed retention period.

During testing, the team found an authorization flaw that allowed one test user to request another test user’s order information. Rather than access real customer records, the testers demonstrated the issue with two synthetic accounts, recorded the request and response, and stopped further enumeration. They immediately notified the technical contact because the flaw affected confidentiality.

Approach and solution

The retailer disabled the affected endpoint, reviewed logs, corrected server-side authorization checks, invalidated relevant sessions, and added automated tests for object-level authorization. The testers performed a retest using the same controlled accounts. They also recommended monitoring for unusual sequences of order requests and a review of similar endpoints.

Outcome

The retest found that the original access path was blocked. The final report distinguished the confirmed weakness from untested areas, documented the evidence-handling process, and assigned remediation ownership. No real customer data was copied, and production availability was maintained.

Learning points

The case demonstrates that a successful engagement depends on governance as much as technical skill. Clear authorization prevented cloud-provider conflict; synthetic data reduced privacy exposure; least-harm validation established impact; immediate escalation supported containment; and retesting connected the assessment to measurable improvement.

12. Challenges, Limitations, and Contemporary Developments

No penetration test proves that a system is secure. Testing is time-limited, dependent on available access and knowledge, and vulnerable to false negatives. A test may miss unknown vulnerabilities, configuration changes, third-party dependencies, insider threats, or business-logic paths not selected for review. A clean report means only that no material issue was identified within the stated scope and method.

Automation and artificial intelligence can assist reconnaissance, code review, log analysis, report drafting, and prioritization. They can also generate false positives, expose client data to external services, produce unsafe requests, or obscure how a conclusion was reached. Organizations should define whether client data may be processed by AI tools, require approved environments, review outputs by qualified personnel, and retain human responsibility for authorization and decisions.

Contemporary cloud, container, software-supply-chain, and continuous-delivery environments make scope dynamic. Asset inventories, identity relationships, infrastructure-as-code, and third-party services may change during an engagement. Contracts should define how newly discovered assets are handled, and testers should not assume that technical reach equals legal permission.

Best-Practice Checklist

Before testing, confirm written authority, asset ownership, scope, prohibited actions, contacts, schedules, privacy terms, evidence procedures, and stop conditions. During testing, use the least harmful technique, maintain accurate records, protect credentials, monitor impact, and escalate unexpected access. After testing, report limitations honestly, separate facts from assumptions, prioritize remediation, delete data as agreed, and conduct a meaningful retest.

Chapter Summary

Ethical hacking is authorized security work conducted for a legitimate defensive or assurance purpose. Penetration testing is a structured form of ethical hacking that validates selected weaknesses and communicates their business significance. Its foundation is not a tool but a combination of authorization, scope, safety, competence, evidence, privacy, and accountability.

The CIA triad frames confidentiality, integrity, and availability, while threat modelling and risk thinking connect vulnerabilities to realistic harm. Black-box, grey-box, and white-box designs differ in the information given to testers; external, internal, application, cloud, wireless, physical, and social-engineering tests differ in target and method. Rules of engagement translate permission into operational boundaries and must include stop conditions, communication routes, and evidence requirements.

Responsible disclosure, data minimization, secure evidence handling, professional independence, and honest reporting protect both the client and the tester. Computer-misuse, privacy, breach, contractual, and sector-specific laws may apply across multiple jurisdictions. Frameworks such as ISO/IEC 27001, NIST guidance, and OWASP resources support governance but do not replace legal authorization. Finally, a penetration test provides bounded assurance, not proof of perfect security; its value is realized when findings lead to remediation, improved detection, and reduced residual risk.

Key Terms

Authorization: Written permission from an entitled authority to perform specified testing.

Attack surface: The set of reachable interfaces and components that may be attacked.

Availability: The property that authorized users can access systems and information when needed.

Chain of custody: A record of evidence collection, handling, transfer, access, and disposal.

Confidentiality: Protection against unauthorized disclosure.

Defence in depth: Use of multiple layers of security controls.

Ethical hacking: Authorized hacking performed for legitimate defensive or assurance purposes.

Exploit: A method or code sequence that takes advantage of a vulnerability.

Grey-box test: A test in which the tester receives limited internal knowledge or access.

Integrity: Protection against unauthorized alteration or destruction.

Least privilege: Providing only the access necessary for an authorized task.

Penetration test: A governed assessment that validates security weaknesses through controlled testing.

Proof of concept: A limited demonstration that a suspected weakness is real.

Responsible disclosure: Coordinated reporting intended to enable correction and reduce harm.

Residual risk: Risk remaining after controls or remediation.

Rules of engagement: Operational instructions and limits for an assessment.

Scope: The assets, activities, methods, people, and times included in a test.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited or otherwise cause harm.

White-box test: A test in which the tester receives extensive internal information.

Review Questions

Short Answer Questions

1. Define penetration testing and distinguish it from vulnerability scanning.
2. What are confidentiality, integrity, and availability?
3. Why is written authorization necessary before testing?
4. State two principles for protecting evidence and personal data.
5. What is responsible disclosure?

Long Answer Questions

1. Compare black-box, grey-box, and white-box penetration tests, including their advantages and limitations.
2. Explain how attacker and defender perspectives should be combined when designing an assessment.
3. Describe the main contents of a professional rules-of-engagement document.
4. Discuss how privacy, least privilege, and data minimization should influence test execution.
5. Explain why a penetration test cannot prove that an organization is completely secure.

Analytical / Application Questions

1. A manager asks a student to scan a competitor’s public website “for practice.” Analyze the authorization, legal, ethical, and professional problems and propose a lawful alternative.
2. During an authorized test, a tester unexpectedly obtains access to real medical records. What immediate actions should be taken, and how should evidence and disclosure be managed?
3. An organization wants a covert denial-of-service exercise against its production payment platform. Evaluate the proposal and design a safer assessment that addresses availability and incident response without creating unacceptable harm.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a penetration test from a vulnerability scan?

A. A penetration test never uses automated tools.

B. A penetration test validates selected weaknesses through controlled testing and impact analysis.

C. A vulnerability scan always requires written legal authorization, but a penetration test does not.

D. A vulnerability scan is performed only against wireless networks.

Correct Answer: B. A penetration test validates selected weaknesses through controlled testing and impact analysis.

Question 2

Which security property is most directly threatened when an unauthorized user alters an examination record?

A. Confidentiality

B. Availability

C. Integrity

D. Authenticity of the network cable

Correct Answer: C. Integrity

Question 3

Which item is most essential before testing a production server?

A. A publicly available exploit only

B. Written authorization defining the permitted scope and activities

C. A promise that the tester will not write a report

D. An assumption that public systems are always available for testing

Correct Answer: B. Written authorization defining the permitted scope and activities

Question 4

A grey-box assessment normally provides the tester with:

A. No information at all

B. Limited internal knowledge or user-level access

C. Unlimited authority over every connected system

D. Only physical access to the building

Correct Answer: B. Limited internal knowledge or user-level access

Question 5

What is the safest response when a tester unexpectedly encounters real personal data?

A. Copy the entire dataset for later analysis

B. Publish a sample immediately

C. Minimize access, stop unnecessary activity, preserve limited evidence, and escalate

D. Ignore the discovery and continue normally

Correct Answer: C. Minimize access, stop unnecessary activity, preserve limited evidence, and escalate

Question 6

What is the primary purpose of rules of engagement?

A. To replace all applicable laws

B. To define operational boundaries, permitted methods, contacts, and stop conditions

C. To guarantee that no vulnerability will be found

D. To allow testing of third-party systems without permission

Correct Answer: B. To define operational boundaries, permitted methods, contacts, and stop conditions

Question 7

Which practice best demonstrates least privilege during a penetration test?

A. Giving every tester permanent domain-administrator access

B. Using only the accounts and permissions necessary for the approved objective

C. Sharing one unrestricted account among all consultants

D. Avoiding logs so that testing remains secret

Correct Answer: B. Using only the accounts and permissions necessary for the approved objective

Question 8

What does a cryptographic hash primarily help demonstrate about an evidence file?

A. That the file is legally admissible in every jurisdiction

B. That the file has not changed since the recorded hash was created

C. That the file contains no personal data

D. That the original event definitely occurred as described

Correct Answer: B. That the file has not changed since the recorded hash was created

Question 9

Which statement about risk is most accurate?

A. Every vulnerability has the same risk regardless of context.

B. Risk depends on factors such as likelihood, impact, exposure, and existing controls.

C. A scanner’s severity label is always a complete risk decision.

D. Risk disappears whenever a system is connected to the internet.

Correct Answer: B. Risk depends on factors such as likelihood, impact, exposure, and existing controls.

Question 10

Which action is most consistent with professional ethics?

A. Exaggerating impact to ensure remediation funding

B. Disclosing confidential findings publicly before contacting the owner

C. Reporting limitations and separating confirmed evidence from assumptions

D. Testing excluded systems when they appear technically reachable

Correct Answer: C. Reporting limitations and separating confirmed evidence from assumptions