Rules of Engagement: Penetration Testing and Security Assessment

Information Security Specialist

📅 2025-12-21

Overview

This document defines the Rules of Engagement (RoE) for conducting penetration testing and security assessments of information systems. The document establishes the framework for collaboration between the client and testing team, ensuring security, legality, and effectiveness of the process.

Document Objectives

Primary Goal — Ensure controlled and authorized testing with minimal risks to production systems The Rules of Engagement guarantee:
  • Security of production systems
  • Compliance with legal requirements
  • Transparent communication between all parties
  • Controlled and authorized testing

Contact Information

Client Organization

RoleContact Details
Primary Contact — Position_________________________
Primary Contact — Mobile Phone_________________________
Primary Contact — Email Address_________________________
Secondary Contact — Position_________________________
Secondary Contact — Mobile Phone_________________________
Secondary Contact — Email Address_________________________

Testing Team

RoleContact Details
Team Lead — Mobile Phone_________________________
Team Lead — Email Address_________________________
Backup Contact — Mobile Phone_________________________
Backup Contact — Email Address_________________________
24/7 Emergency Contact — Mobile Phone_________________________
24/7 Emergency Contact — Email Address_________________________

Scope of Testing

In-Scope Assets

Network Infrastructure:

Applications and Services:

Out-of-Scope Assets

⚠️ Critical Restrictions:
  • Systems not owned by the organization
  • Third-party services without written authorization
  • Production databases (unless explicitly permitted)
  • Social engineering (unless approved)
  • Critical infrastructure systems

Testing Rules and Procedures

Authorized Activities

✅ Approved Testing Methods:
  • Vulnerability scanning
  • Manual penetration testing
  • Web application testing
  • API interface testing
  • Cloud configuration analysis
  • Network security testing
  • Password policy verification

Prohibited Activities

❌ Strictly Forbidden Actions:
  • Denial of Service (DoS/DDoS) attacks
  • Physical intrusion
  • Social engineering without explicit authorization
  • Brute-force attacks without rate limiting
  • Actions that may cause data corruption
  • Unauthorized access to personal data

Load Limitations

Technical Constraints for Production Systems

⚡ Critical Load Limits:
ParameterLimitationNotes
Maximum Requests per Second_________________________To prevent system overload
Concurrent Connections_________________________Parallel connection limit
Payload Size_________________________Maximum data size
Connection Timeout_________________________Response wait time

Time Restrictions

🕐 Intensive Testing Schedule:
  • Mass Scanning: Off-hours only
  • Fuzzing Testing: _________________________ (specify time windows)
  • Load Testing: Prior notification required
  • Automated Scanners: Rate-limited during business hours

Load Monitoring

📊 System Impact Control:
  • CPU and memory monitoring of target systems
  • Application response time tracking
  • Network bandwidth control
  • Immediate halt if limits exceeded

Legal Basis

Legal Foundation for Testing

⚖️ Legal Justification: All penetration testing activities are performed exclusively based on written authorization from an authorized representative of the client organization.

Documentary Basis:

Limitation of Liability

🛡️ Liability Exemption — The testing team is exempt from liability for:
  • Temporary system unavailability resulting from authorized testing
  • Discovery of vulnerabilities existing prior to testing commencement
  • Actions performed strictly within the agreed testing scope
  • Indirect losses related to security issue identification

Legal Compliance

📋 Regulatory Compliance:
  • Adherence to personal data protection legislation
  • Compliance with industry security standards
  • Alignment with international penetration testing practices
  • Documentation of all actions for audit purposes

Vulnerability Criticality Matrix

🎯 Standardized Assessment System — Risk Level Classification:
LevelDescriptionVulnerability ExamplesRemediation Time
P0 - CriticalImmediate security threatRCE, SQL Injection, Authentication Bypass24–48 hours
P1 - HighSerious security breachXSS, LFI, Privilege Escalation1–2 weeks
P2 - MediumModerate riskSecurity Misconfiguration, CSRF1 month
P3 - LowMinimal riskInformation Disclosure, Weak Ciphers3 months
P4 - InformationalImprovement recommendationsBest Practices, HardeningAs possible

Assessment Criteria

📈 Criticality Determination Factors:
  • Impact: Potential damage from exploitation
  • Likelihood: Ease of vulnerability exploitation
  • Scope: Number of affected systems
  • Accessibility: Access requirements for exploitation

Escalation Procedure

⚡ Emergency Response for Critical Findings:
  1. P0–P1: Immediate notification by phone + email
  2. P2: Notification within business day
  3. P3–P4: Inclusion in regular reports

Authorized Testing Tools

🔧 Core Toolset:
CategoryToolPurposeVersion
Vulnerability ScannersNessusAutomated scanning_________
OpenVASNetwork and application scanning_________
Qualys VMDRCloud scanning_________
Web TestingBurp Suite ProfessionalWeb application testing_________
OWASP ZAPWeb application security analysis_________
NiktoWeb server scanning_________
Network TestingNmapPort and service scanning_________
MasscanHigh-speed scanning_________
ExploitationMetasploit FrameworkExploit testing_________
Cobalt StrikeAttack simulation (with agreement)_________
🛠️ Additional Tools — Specialized Software (by agreement):
  • Social Engineering: SET, Gophish (explicit permission only)
  • Wireless Networks: Aircrack-ng, Kismet
  • Mobile Applications: MobSF, Frida
  • Cloud Security: ScoutSuite, Prowler
⚠️ Prohibited or Restricted Tools:
  • DDoS attack tools
  • Unauthorized scanners with aggressive settings
  • Password cracking tools without rate limits
  • Any software not agreed upon with the client

Testing Team Identification

🔍 Whitelists for Defensive Systems — Critical for preventing authorized testing blockage:
Identification ParameterValuePurpose
Source IP Addresses_________________________Static IPs for WAF/IPS whitelisting
Subnet Ranges_________________________Additional team network segments
User-Agent Strings_________________________Specific identifiers for web scanners
SSH Keys_________________________Public keys for authorized access
🏷️ Special Identifiers — Markers for logging and monitoring:
  • Test Request Prefix: _________________________
  • Special HTTP Headers: _________________________
  • Session Identifiers: _________________________
  • Payload Markers: _________________________
📞 Blue Team Coordination — Interaction with defense team:
  • Pre-testing notification of commencement
  • SOC (Security Operations Center) contact list
  • Procedure for confirming activity legitimacy
  • Emergency testing halt protocol

High-Risk Test Definition

⚠️ Risky Operation Classification — High-risk tests requiring special attention:
Test CategoryDescriptionExecution WindowAdditional Measures
Brute-force AttacksPassword/PIN guessingOff-hours onlyRate limiting, lockout monitoring
Application FuzzingInvalid data submission_________________________System stability control
Vulnerability ExploitationProof-of-concept executionBy agreementImmediate notification on success
DoS TestingLoad resistance verificationTest environment onlyPrior agreement required
🕐 Critical Test Service Windows — Special time intervals:
  • Primary risky test window: _________________________
  • Backup window: _________________________
  • Emergency window (by agreement): _________________________
  • Prohibited periods: _________________________
👥 Client-Side Testing — End-user protection:
  • Phishing Simulations: Written HR consent only
  • Browser Testing: Isolated test machines
  • Social Engineering: Strictly limited scope
  • Personal Data Protection: Avoid access to personal information

Technical Methodology

📊 Standards and Classifications — International standards used:
StandardVersionApplication
CVSSv3.1/4.0Vulnerability criticality assessment
OWASP Top 102021Web applications
NIST Cybersecurity Frameworkv1.1General methodology
OSSTMMv3Testing methodology
PTESv1.0Penetration testing standard
🔍 Testing Model — Information access level:
  • ☐ Black Box — No prior system knowledge
  • ☐ Gray Box — Partial access to documentation/architecture
  • ☐ White Box — Full access to code and architecture

Selected Model: _________________________

📈 CVSS Assessment — Vulnerability assessment criteria:
  • Base Metrics: Attack vector, complexity, privileges, user interaction
  • Temporal Metrics: Exploit availability, remediation level
  • Environmental Metrics: Impact on client's specific environment
  • Threshold Values: P0 (9.0–10.0), P1 (7.0–8.9), P2 (4.0–6.9), P3 (0.1–3.9)

Additional Legal Aspects

🌍 Cross-Border Data Transfer — International compliance: When working with international testing teams, compliance with GDPR, CCPA, and other applicable data protection regulations is ensured.
  • Team base country: _________________________
  • Applicable legislation: _________________________
  • Data transfer mechanisms: Standard Contractual Clauses (SCC) / Adequacy Decision
  • Data localization: _________________________

International Standards Compliance

Standard / RegulationCompliance StatusNotes
GDPR (EU)_________________________Personal data protection
ISO 27001_________________________Information security management system
SOC 2 Type II_________________________Security controls
PCI DSS_________________________Payment systems
🔍 Audit Rights — The client has the right to:
  • Verify data deletion procedures after project completion
  • Request confirmation of confidential information destruction
  • Audit testing team security measures
  • Obtain compliance certificates for applicable standards

Critical Situation Response Process

🚨 Emergency Response Algorithm — Step-by-step procedure for critical incidents:
  1. CRITICAL SITUATION DETECTION
  2. IMMEDIATE TESTING HALT
  3. CLIENT NOTIFICATION (within 15 minutes)
  4. IMPACT AND DAMAGE ASSESSMENT
  5. CONTINUATION DECISION
  6. INCIDENT DOCUMENTATION
  7. ROOT CAUSE ANALYSIS AND CORRECTIVE MEASURES

Escalation Matrix

LevelResponse TimeCommunication MethodResponsible
P0 - Critical15 minutesPhone + SMS + Email_________________________
P1 - High1 hourPhone + Email_________________________
P2 - Medium4 hoursEmail + Slack/Teams_________________________
P3 - Low24 hoursEmail_________________________
🛑 Testing Halt Criteria — Automatic work cessation triggers:
  • Critical service unavailability for more than 5 minutes
  • Discovery of active vulnerability exploitation by third parties
  • Exceeding agreed load limits
  • Halt request from any authorized representative

Evidence Handling and Cleanup

🔒 Evidence Handling Protocol — strict security requirements:
StageRequirementsResponsible
CollectionEncryption, hashing, timestampsTester
StorageIsolated storage, access controlProject Manager
TransferSecure channels, receipt confirmationBoth parties
DestructionIrreversible deletion, destruction certificateTesting team
🧹 Post-Test Cleanup Plan — mandatory procedures:

Created Object Removal:

  • Test user accounts
  • Uploaded files and scripts
  • Temporary configurations
  • Test databases and tables

Original State Restoration:

  • Configuration change rollback
  • Test certificate removal
  • Testing log cleanup (by agreement)
  • Backup restoration (if necessary)
📜 Data Destruction Certification — Upon project completion, the testing team provides:
  • Certificate of irreversible deletion of all client data
  • Report on performed cleanup procedures
  • Confirmation of compliance with data destruction standards (DoD 5220.22-M or equivalent)

Testing Schedule

ParameterValue
Start Date_________________________
End Date_________________________
Testing Window_________________________
Time Zone_________________________
Daily Briefing_________________________
💡 Communication Protocol — Regular Updates:
  • Daily status reports
  • Weekly progress summaries
  • Emergency notifications for critical findings

Incident Handling

Incident Response Procedure

In case of system instability during testing:

  1. Immediate halt of testing by team
  2. Notification of client organization
  3. Decision making by emergency contact regarding continuation
  4. Incident documentation
🔍 Testing Halt Criteria — Conditions for work cessation:
  • Discovery of critical vulnerabilities
  • Production system instability
  • Exceeding agreed testing scope
  • Client request

Data Handling and Confidentiality

Confidentiality — priority number one when processing any information

Testing Team Obligations:

  • Sensitive data not stored unless necessary
  • All collected data encrypted
  • Data deleted after report delivery
  • Avoidance of personal data access
Non-Disclosure Agreement — All testing participants commit to:
  • Maintain confidentiality of obtained information
  • Not disclose results to third parties
  • Use data exclusively for testing purposes

Reporting Requirements

Interim Reports:
  • Daily or weekly updates
  • Task completion status
  • Preliminary findings
Final Reporting:
  • Technical Report — detailed vulnerability description
  • Management Report — recommendations for leadership
  • Executive Summary — brief overview for top management
📊 Results Presentation Format — Standardized structure:
  • Vulnerability classification by criticality
  • Remediation recommendations
  • Remediation timeframes
  • Security metrics

Risk Acceptance

Client Organization Confirmation — The client organization confirms understanding that:
  • Testing may reveal critical vulnerabilities
  • Some tests may cause temporary performance degradation
  • All actions are authorized and agreed upon
  • Results will be used to improve security

Testing Readiness Checklist

Preparatory Activities

  • Testing scope defined
  • Responsible contacts assigned
  • Work schedule agreed
  • All necessary documents signed
  • Communication channels established
  • Test environment prepared (if necessary)
  • Testing team briefing conducted

Control Points During Testing

  • Daily status meetings
  • Production system monitoring
  • All actions documented
  • Timeline compliance
  • Regular client communication

Signatures and Approvals

Client Organization Representative

Name and Position_________________________
Signature_________________________
Date_________________________

Testing Team Lead

Name and Position_________________________
Signature_________________________
Date_________________________

Emergency Contact Form

Rapid Response Information:
ParameterContact Details
Primary Client Contact_________________________
Secondary Client Contact_________________________
Testing Lead_________________________
24/7 Emergency Line_________________________

Emergency Contact Procedure

  1. Primary contact — main client representative
  2. If unavailable — secondary contact
  3. Critical situations — 24/7 emergency line
  4. Documentation of all communications