Safety Norms: Penetration Testing Methods

1Purpose, Scope, and Safety Principles

Penetration testing methods are repeatable approaches for simulating attacker behavior against a defined target so the owner can find and fix exploitable weaknesses. Typical phases include planning, information gathering, vulnerability identification, controlled exploitation, post-exploitation validation, reporting, and retesting. These norms apply to internal and external network tests, web and mobile application tests, cloud configuration reviews, wireless assessments, social engineering exercises, and physical security tests where authorized.

Four principles guide every activity: written authorization comes first, impact must be as low as the objective allows, personal and confidential data are touched only when unavoidable, and any sign of harm triggers a stop.

• Mandatory: no active testing begins until a signed authorization names targets, permitted methods, testing windows, and emergency contacts.
• Mandatory: the tester stops activity and notifies the client contact when a service fails, data exposure occurs, or physical safety is at risk.
• Recommendation: validate in a non-production copy first whenever the objective can be met there.

2Roles, Competence, and Accountability

The client executive sponsor accepts residual risk and approves scope changes. The client technical owner confirms that each asset belongs to the organization, provides contacts, and approves testing windows. The engagement lead plans the work, supervises testers, and owns the rules of engagement. Testers carry out assigned tasks only. A legal or contract reviewer checks authority, liability, and third-party permissions, and a data protection lead advises on personal data handling.

Competence is demonstrated, not assumed. Each tester must have documented training in the methods assigned, supervised experience, and current knowledge of the tools they use. Formal certifications are an employer decision and may be jurisdiction-dependent in some contexts; treat them as evidence, not as permission to act.

• Mandatory: no one runs exploit code, brute-force attempts, or payloads against a system not listed in the signed scope.
• Mandatory: junior testers work under a named senior reviewer for high-impact methods such as exploitation of production systems.
• Recommendation: keep a responsibility matrix in the engagement file showing who approves each category of action.

3Course-Specific Hazards and Risk Assessment

Penetration testing hazards are mostly digital, operational, and legal, but physical hazards arise during onsite work such as data center access, wireless surveys, and social engineering in facilities. Common hazards include service disruption from aggressive scanning or unstable exploits, data corruption from write operations, exposure of credentials and personal records captured during testing, accidental access to third-party systems such as shared hosting or managed cloud services, malware spread from samples or tools, and fatigue-related errors during long engagements.

Assess each hazard by likelihood and impact using a matrix approved by the client, rating items as low, medium, or high. High-risk targets include production databases holding personal or financial records, medical systems, industrial control and operational technology, safety-critical infrastructure, and systems the client cannot restore quickly. These require specialist approval, a tested rollback plan, and often exclusion from active testing.

• Service disruption from scanning or exploitation: medium to high; control with rate limits, approved windows, and live monitoring.
• Data alteration by write actions: high; control with read-only proof and verified backups.
• Exposure of personal or secret data: high; control with minimization, redaction, and encrypted storage.
• Out-of-scope access, including third-party providers: high legal risk; control with asset verification before each phase.
• Tester workstation compromise: medium; control with hardened, dedicated hosts.
• Social engineering harm to staff: medium; control with approved pretexts and no coercion.
• Physical intrusion or injury on site: medium to high; control with written facility permission and escort rules.

4Preventive Controls and Safe Work Practices

Preparation controls most of the risk. Before testing, confirm asset ownership through contracts, cloud account records, or written client attestation, not guesses based on IP address lookups alone. Agree on testing windows that avoid peak business processing, change freezes, and known maintenance. Confirm that backups exist and have been restored successfully in a separate test environment. Establish a stop word and a named rollback owner. Brief every tester on the rules of engagement before any access is granted.

During execution, prefer the least intrusive method that proves the finding. Show access with a benign marker file in a designated location rather than reading large data sets. Avoid denial-of-service techniques unless the client explicitly authorizes them and accepts the outage risk. Do not install persistence mechanisms, backdoors, or lateral movement beyond what the scope permits. Record every significant action with a timestamp so the activity can be reconstructed. Remove artifacts at the end of testing and document anything that remains.

• Mandatory: rate-limit scanners and brute-force attempts to the thresholds stated in the signed scope.
• Mandatory: use read-only validation for production data unless a written exception names the data set and purpose.
• Mandatory: no destructive payloads, wiping, or ransomware-like behavior at any time.
• Mandatory: social engineering is limited to pretexts approved in advance, with no threats, no impersonation of emergency services, and no pressure on individuals.
• Recommendation: pair testers during exploitation of critical systems so one person watches monitoring and service health.
• Recommendation: hold a short status check with the client contact every two hours during active testing.

5Equipment, Environment, Information, and Protective Safeguards

Use a dedicated testing workstation or virtual machine with full disk encryption, current operating system patches, a host firewall, multi-factor authentication, and no personal browsing or email. Maintain an approved tool list with versions and verified checksums. Run untrusted samples, unknown binaries, or malware analysis only in an isolated sandbox with no route to production. Connect through the client-approved VPN or jump host, and keep session logs.

Information handling needs equal care. Collect only what the finding requires, redact personal data in screenshots and reports, store evidence in encrypted repositories limited to the engagement team, and delete working copies according to the agreed retention schedule. Transfer findings only through approved channels. Privacy obligations depend on jurisdiction and contract, so consult the data protection lead before collecting personal records. Personal protection for testers comes from hardware security keys, locked screens, a managed password vault, and separate credentials for testing accounts.

• Mandatory: client secrets and captured credentials are never reused, pasted into chat tools, or stored in personal notes.
• Mandatory: evidence containing personal data is encrypted at rest and in transit.
• Recommendation: use disposable test accounts with minimal rights and remove them at the end of testing.
• Recommendation: keep a register of sensitive data encountered, noting where it is stored and how it was destroyed.

6Responsible Use, Disclosure, and Secure Design

Testers must not use methods, findings, or tools for purposes outside the engagement. Exploit details and proof-of-concept code stay with the authorized team and the client. Publication of vulnerabilities, public demonstrations, or sharing with other clients require written consent and a coordinated disclosure plan. Responsible disclosure gives the owner time to fix issues before any public discussion, and the timeline must be agreed in advance and reviewed by counsel where applicable.

Secure design is part of testing practice. Findings should explain root cause, not only symptoms, and recommend controls such as least privilege, input validation, secure configuration baselines, network segmentation, and centralized logging. Test activity should not weaken production controls, and test accounts must not remain as permanent backdoors. Recommendations are advisory, and the owner decides how to remediate.

• Mandatory: exploit code and unpatched vulnerability details are never posted publicly or shared outside the authorized team.
• Mandatory: tools capable of causing damage are used only under the written rules of the engagement.
• Recommendation: include retest criteria with each finding so fixes can be verified objectively.

7Incident Response, Emergency Procedures, and Escalation

Incidents include service outages, unexpected data exposure, accidental access to out-of-scope assets, tester workstation compromise, malware detection, injury, and alarms triggered in a client security operations center. The tester who observes an incident stops the activity, preserves relevant logs and screenshots without copying more data than necessary, and notifies the engagement lead immediately. The lead notifies the client contact within the time frame stated in the engagement agreement, using the emergency channel rather than email alone.

Do not attempt to repair production systems unless the client asks for help within the agreed scope. If someone is injured, a fire starts, or there is an immediate threat to life, call local emergency services first. Isolate suspected malware and avoid spreading it to other hosts. Log every near miss, even when no harm occurs, because near misses reveal control gaps.

• Mandatory: accidental out-of-scope access stops immediately, is reported, and is not explored further.
• Mandatory: a designated engagement contact is reachable during every testing window.
• Mandatory: incidents are recorded in a timeline showing times, actions taken, and people notified.
• Recommendation: rehearse the escalation path with the client before live testing begins.

8Records, Training, Inspection, and Continuous Improvement

Keep a complete engagement file containing the signed authorization, scope, rules of engagement, risk assessment, asset verification, activity log, incident records, findings, evidence register, retention and destruction records, and client acceptance. Records support legal defense, quality review, and future testing. Retention periods are jurisdiction and contract dependent, so confirm them with a qualified professional.

Training should cover these norms, the tools in use, incident handling, and privacy basics before a tester works unsupervised. Peer review checks test plans before start and reports before delivery. After each engagement, the team holds a short review of safety events and updates these norms and checklists. Review this document at planned intervals and after any significant incident. This guidance is a starting point; adapt it into locally approved procedures under qualified supervision.

Implementation checklist

• Confirm written authorization, named targets, testing windows, and emergency contacts before any active step.
• Verify each asset's ownership and scope immediately before each testing phase.
• Confirm verified backups and a named rollback owner for every system that could change.
• Apply rate limits and avoid destructive or denial-of-service techniques unless explicitly approved.
• Minimize, redact, and encrypt any personal or secret data encountered during testing.
• Run tools only from an approved, patched, and isolated testing host.
• Stop immediately on out-of-scope access, service failure, or harm, then notify the designated contact.
• Record actions, incidents, and near misses in the engagement file.
• Limit disclosure to the authorized team and follow the agreed disclosure plan.
• Confirm jurisdiction-specific laws and contract terms with qualified counsel before testing.