vaayaa Inclusive Education
Technical risk assessment

Penetration Testing Methods Risk Assessment: Scope, Malware and Data Controls

A worked example of how a team that runs authorized penetration tests finds, scores and controls the risks its own methods create, from out of scope activity and malware escape to captured data, service disruption and weak logging.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: High to Medium
See the Penetration Testing Methods course

Executive summary

This assessment shows how a penetration testing team can find, rate and control the risks that its own methods create. Penetration tests are deliberately intrusive, so the team can cause the harm it is paid to prevent, such as leaving a test payload on a live system, exposing sensitive data it collects or disrupting a service under load. Eight hazards were chosen because they are plausible in ordinary testing work. Data exposure and malware escape carry the highest inherent scores, and both fall to Medium or Low once evidence handling, isolation and recovery controls are in place. Service disruption and scope drift stay likely enough to need steady attention even after controls. The first actions are a written scope check before each test, encrypted evidence storage, isolated tooling with checked cleanup and a logging standard that lets a responder reconstruct every action. The scores illustrate method, not a real team.

Focus area
Penetration testing and offensive security assessment
Setting
Internal or contracted security testing team working on client networks, web applications and cloud services
Method
Five by five likelihood and impact risk register

Scope

This assessment covers the planning, execution, reporting and cleanup of authorized penetration tests against networks, web applications and cloud accounts. It includes tester workstations, attack tooling, test data, evidence stores and client communications. It does not cover unauthorized access, real attacks or any named organization. Jurisdiction, contract terms, client systems and tooling are assumptions made for teaching and must be confirmed by specialist review before any real use.

Context

A small team of testers works under a signed letter of authorization and agreed rules of engagement. Testers use a mix of commercial and open source tools on managed laptops, a shared evidence store and a reporting platform. Targets include a customer web application, an internal network segment and a cloud tenancy. Each hazard is scored before controls to show its natural level, then again after the existing controls and the additional controls proposed here. The aim is to show how the test method itself can cause harm, not only how it finds weaknesses.

Objectives, assets and stakeholders

The objective is to run authorized tests that improve security without causing harm, keep client data confidential, protect the testing team and its tools, and meet the duties agreed in each contract. The assets in scope are tester workstations and attack tooling, evidence and report stores, client credentials and captured data, the client systems under test, backup and recovery copies, and the reputation of the team. Stakeholders include the testing lead, the engagement manager, client system owners, the client security contact, data protection and legal advisers, the incident response team and the clients whose information may be touched. Each risk has one owner role, and the testing lead keeps the register current and reviews it with the engagement manager after every test cycle.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 3, score 12, high: H08 Likelihood 4, impact 4, score 16, high: H05
3 Possible Likelihood 3, impact 4, score 12, high: H01 H04 H07 Likelihood 3, impact 5, score 15, high: H02
2 Unlikely Likelihood 2, impact 3, score 6, medium: H03 Likelihood 2, impact 5, score 10, high: H06
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible Likelihood 3, impact 2, score 6, medium: H07
2 Unlikely Likelihood 2, impact 2, score 4, low: H03 Likelihood 2, impact 3, score 6, medium: H01 H04 H05 H08 Likelihood 2, impact 4, score 8, medium: H02 H06
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Testing outside agreed scope or authorization 12 High 6 Medium Engagement manager
H02 Malware or test payload escaping the lab 15 High 8 Medium Security operations lead
H03 Phishing simulation causing staff harm 6 Medium 4 Low Compliance officer
H04 Service disruption from scanning or exploitation 12 High 6 Medium Testing lead
H05 Capture and exposure of sensitive client data 16 High 6 Medium IT manager
H06 Insider misuse of tester access or findings 10 High 8 Medium Human resources manager
H07 Third-party and supplier exposure in the test chain 12 High 6 Medium Procurement lead
H08 Weak logging and slow incident response during testing 12 High 6 Medium Security operations lead
H01

Testing outside agreed scope or authorization

Legal and compliance Before 12 After 6

A tester strays onto an address, account or system that was never authorized, or uses a technique the rules of engagement forbid, creating unlawful access and a breach of contract.

Who or what is affected: Client system owners, third parties hosting the system and the testing team

Causes

Wide address ranges, shared scan configurations and pressure to finish within a test window.

Consequences

Unlawful access claims, contract breach, notification duties and loss of client trust.

Existing controls

  • Scope is written into a signed authorization letter before testing starts.
  • Target lists are checked by a second tester before each session.

Control gaps

Target lists are checked by hand once and not again during long scans.

Additional controls

  • Prevent: Load only approved targets into tools and block all other addresses at the network edge.
  • Detect: Compare live traffic destinations against the target list every hour during testing.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Engagement manager Target: Within 30 days Early warning: Traffic leaving the approved target list during a test session.
H02

Malware or test payload escaping the lab

Technology and data Before 15 After 8

A payload, backdoor or exploit used in a test is copied to a live system or a tester workstation, or is left running after the engagement, infecting systems the test did not intend to touch.

Who or what is affected: Client systems, testers and other users of shared networks

Causes

Payloads reused between engagements, removable media and weak network separation.

Consequences

Infection of client systems, data loss, unplanned outage and damage to the team's standing.

Existing controls

  • Test payloads are built and stored only in a segregated lab.
  • Tester workstations run endpoint protection and are patched monthly.

Control gaps

Cleanup is confirmed from memory rather than a checked list.

Additional controls

  • Prevent: Use isolated virtual machines with no route to production and block outbound transfers by default.
  • Respond: Keep a removal runbook that wipes test artefacts and reimages affected hosts.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Security operations lead Target: Within 45 days Early warning: Unknown binaries or test tool signatures found on a host outside the lab.
H03

Phishing simulation causing staff harm

People Before 6 After 4

A phishing exercise used to test staff awareness causes distress, unfair blame or real credential loss when the lure is too convincing or staff are not told how to report it.

Who or what is affected: Staff, staff representatives and the client security team

Causes

Lures that mimic personal stress, unclear rules and no review of how results are used.

Consequences

Staff distrust, grievances, reduced reporting and harm to wellbeing.

Existing controls

  • Simulations are approved by the client in writing before launch.
  • Staff who click are sent a short learning message.

Control gaps

Results are published by name in some teams, which discourages honest reporting.

Additional controls

  • Prevent: Agree lure themes with human resources and keep them clear of pay, health and personal matters.
  • Detect: Track reports made to the security team so that staff who report are recognized.
Likelihood 2 x impact 3 before; 2 x 2 after Owner: Compliance officer Target: Within 60 days Early warning: Repeated complaints from staff about a simulation or its timing.
H04

Service disruption from scanning or exploitation

Operational Before 12 After 6

Scans, brute force attempts or exploit attempts overload a fragile service, trigger lockouts or crash a production system during peak use, causing downtime for real users.

Who or what is affected: Service users, system owners and support teams

Causes

Fragile legacy systems, aggressive scan settings and unclear peak periods.

Consequences

Lost business, service credits, emergency change and client complaints.

Existing controls

  • Test windows are agreed with system owners and avoid peak hours.
  • Scan rates are capped in tool settings.

Control gaps

Rate caps are set once and not rechecked when load changes.

Additional controls

  • Prevent: Run load-sensitive checks against a staging copy first and stop on any slowdown.
  • Recover: Keep a rollback plan and a named contact to restore the service quickly.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Testing lead Target: Within 30 days Early warning: Response times rising above the agreed limit during a test window.
H05

Capture and exposure of sensitive client data

Technology and data Before 16 After 6

Testers capture real customer records, credentials or personal data while proving impact, then store, copy or share them insecurely, so the confidentiality of client data is lost.

Who or what is affected: Client customers, data subjects, client staff and the testing team

Causes

Proof of impact that needs real records, shared folders and laptops taken off site.

Consequences

Privacy breach, notification duties, contract loss and fines in some jurisdictions.

Existing controls

  • Evidence is stored on an encrypted drive with access logs.
  • Testers are told to redact screenshots before sharing them.

Control gaps

Deletion deadlines are not tracked after the report is delivered.

Additional controls

  • Prevent: Use synthetic or masked data for proof of impact wherever the contract allows.
  • Respond: Delete captured data at the agreed deadline and record the deletion in the engagement file.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: IT manager Target: Within 30 days Early warning: Client data found in shared folders, chat tools or personal storage.
H06

Insider misuse of tester access or findings

People Before 10 After 8

A tester or contractor with privileged access uses it for personal gain, sells findings or keeps credentials after the engagement, turning trusted testing access into an attack path.

Who or what is affected: Clients, other testers and the team's reputation

Causes

Privileged access held for long periods and weak review of session activity.

Consequences

Theft of client data, loss of contracts, legal action and lasting reputational harm.

Existing controls

  • Background checks and signed confidentiality agreements are in place.
  • Privileged accounts are issued per engagement and expire at its end.

Control gaps

Session logs are kept but seldom reviewed against the signed plan.

Additional controls

  • Prevent: Use just in time access that needs approval for each target and each test window.
  • Detect: Review privileged session logs against the signed plan after every engagement.
Likelihood 2 x impact 5 before; 2 x 4 after Owner: Human resources manager Target: Within 60 days Early warning: Credentials or tokens still active after the engagement end date.
H07

Third-party and supplier exposure in the test chain

Supplier Before 12 After 6

Tools, cloud providers, reporting platforms or subcontracted testers hold client data or access and have weak security, so a failure in their service exposes the engagement to loss.

Who or what is affected: Clients, the testing team and subcontractors

Causes

Shared tools with unknown hosting, subcontractors and fast onboarding under deadline pressure.

Consequences

Data exposure through a supplier, delayed notice to clients and contract disputes.

Existing controls

  • Suppliers are listed with a named contact and a data handling note.
  • Subcontracted testers sign the same confidentiality terms as employees.

Control gaps

Supplier reviews are done once and not repeated after tool updates.

Additional controls

  • Prevent: Check supplier security evidence before onboarding and again before each renewal.
  • Respond: Keep a contract clause that requires prompt notice of any supplier breach.
Likelihood 3 x impact 4 before; 3 x 2 after Owner: Procurement lead Target: Within 90 days Early warning: A supplier reports a breach or changes where it hosts client data.
H08

Weak logging and slow incident response during testing

Operational Before 12 After 6

Testers do not log every action with accurate timestamps, or responders cannot tell test activity from a real attack, so a real incident is missed or a test is wrongly blamed for damage.

Who or what is affected: Incident responders, client security staff and the testing team

Causes

Unsynchronized clocks, untagged tools and no shared test calendar.

Consequences

Missed real attacks, false alarms, wasted responder time and disputes about who caused damage.

Existing controls

  • Tools write logs to a central store during engagements.
  • Engagement start and end times are sent to the client security contact.

Control gaps

Logs are kept but not checked against the test calendar after the window closes.

Additional controls

  • Prevent: Tag all test traffic with a unique source label that the client can allow and recognize.
  • Detect: Alert when test traffic appears outside the agreed windows or from unknown hosts.
Likelihood 4 x impact 3 before; 2 x 3 after Owner: Security operations lead Target: Within 45 days Early warning: Unexplained alerts that match the test source but fall outside the window.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Catastrophic. Multiplying the two gives a score from 1 to 25, which falls into four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. Inherent risk is the score before any controls, judged as if the test ran with no safeguards. Residual risk is the score after existing and additional controls are in place, and it must never be higher than inherent. Impact is judged on harm to clients, data subjects, systems, contracts and the team's standing, and a risk is never rated down only because it has not happened yet. Low risks are accepted and watched. Medium risks need routine controls with a named owner. High risks need senior attention and a dated plan. Critical risks stop the related activity until a responsible manager signs off. Ratings are challenged by a peer who did not write them and by the client contact on each engagement, and any rating is reviewed whenever an indicator reaches its threshold or a test changes scope.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Tests started without a signed authorization or scope check on file.Escalate to the engagement manager at once, and stop the activity until the authorization is on file.
Test evidence stored outside the encrypted repository or shared by unapproved channels.Escalate to the IT manager within one day, and to the compliance officer if personal data is involved.
Unexplained service slowdowns or errors during a test window.Escalate to the testing lead and client system owner immediately, and pause the test until the cause is known.
Test artefacts or tools still present on a client system after the engagement closes.Escalate to the testing lead within 24 hours, and to the client security contact the same day.
Log gaps or missing timestamps for any tester action in a test window.Escalate to the security operations lead, and to the engagement manager if the gap is not closed within 3 days.

Contingency arrangements

If a test causes a live outage, leaks captured data or leaves a payload running, the engagement lead stops all activity against the target and informs the client security contact at once. The incident response team preserves logs, isolates the affected tooling and removes any test artefacts under a written checklist. The IT manager restores services from the latest tested backup and confirms the state with the system owner. Legal and privacy advisers are contacted through the engagement manager as the contract and the relevant jurisdiction require. Work resumes only after the root cause is recorded and the scope and rules are updated.

Prioritized action plan

  1. Enforce a written scope and authorization check before every test, owner engagement manager, within 30 days.
  2. Encrypt evidence stores and restrict access to named testers, owner IT manager, within 30 days.
  3. Run tooling in isolated lab images and check cleanup before each engagement closes, owner testing lead, within 45 days.
  4. Set a logging standard that records every tester action with a synchronized timestamp, owner security operations lead, within 45 days.
  5. Agree phishing simulation rules with human resources and staff representatives, owner compliance officer, within 60 days.

Conclusion

Good penetration testing depends on disciplined habits: written scope checks, isolated tooling, encrypted evidence, careful timing, complete logs and tested cleanup. The highest scores sit with data capture and malware escape, and each has controls that bring the residual score down. Keep the register as a living record, review it every six months or after any change in tools, clients or scope, and seek qualified legal, privacy and security advice for any real engagement or regulated system.

Assumptions and limitations

Assumptions

  • Testing is performed only under a signed authorization that names targets, dates and permitted techniques.
  • Client systems include production services with real customer data, and backups exist but are not tested often.
  • Jurisdiction is not specified, so legal and privacy duties are described in general terms only.
  • Testers hold recognized professional training and use managed, patched equipment.

Limitations

  • The scores are examples for learning and do not describe any real client, test or tool.
  • Legal, privacy and contractual duties vary by place and contract, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed security advice.

Related frameworks to study

  • Rules of engagement and authorization letter practice
  • Threat modelling for test planning
  • Hierarchy of controls
  • Three lines model of risk ownership

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

Penetration Testing Methods course Read the best practices for this course

More Technical risk assessments

Hourly Active: 45,552 Learners