Skip to main content

Hire ethical hackers

A clever exploit outside scope is still outside scope.

Ethical hackers test security within a written scope and produce reproducible findings that teams can fix and retest. A useful engagement defines permitted techniques, data handling, stop conditions and what remains untested. Werkon should assess a tester against one bounded target and real rules of engagement, while asset owners retain authorization, production, disclosure and risk decisions.

Responsibility contract

Grant enough authority to test without surrendering control of the system.

A tester can challenge an approved target and report what the evidence supports. They cannot infer permission from reachability, accept business risk, authorize production disruption or decide public disclosure alone. Put the authority chain, safety controls and response path in writing before technical work begins.

01

Client authorization, production, and risk authority

Named owners define what may be touched, what harm is unacceptable and who decides the response.

  • Asset owners, legal and privacy counsel, security leadership, production operators and relevant suppliers confirm ownership, lawful authority, third-party and cloud terms, jurisdictions, engagement dates, targets, identities, test source addresses, permitted methods, prohibited actions, evidence retention and disclosure conditions in signed rules of engagement.
  • Product, platform, data and service owners identify current builds, architecture, dependencies, shared tenancy, critical workflows, test accounts and data, backups, restoration capability, maintenance windows, monitoring expectations, rate limits, safety constraints and known failure modes before testing begins.
  • Incident and risk owners define live contacts, material-finding escalation, pause and stop authority, business impact and remediation decisions, exceptions, external notification and publication authority. They can approve a scope change or record its exclusion; the tester cannot extend permission by discovery.
02

Authorized security tester contribution

The tester converts approved questions into bounded attempts and reproducible evidence.

  • Validate that authorization is current and unambiguous for every target and technique; translate the objective into threat-informed hypotheses and a test plan; choose manual and automated methods appropriate to web, API, mobile, network, cloud, code, configuration or scenario scope; and refuse work where ownership, permission or safety limits cannot be established.
  • Confirm target identity and state before each action, prefer the least invasive proof, obey time and rate limits, avoid unnecessary access to personal or confidential data, never create persistence or exfiltrate real data without explicit need and permission, and pause on instability, unexpected privilege, another tenant, third-party infrastructure or any out-of-scope path.
  • Validate tool output, preserve requests, responses, logs, screenshots and timestamps with prerequisites and limits, communicate critical findings immediately, distinguish technical severity from client priority, propose options without owning the risk decision, support retest, remove test access and artifacts, and hand over a client-controlled record.
03

Shared safety, remediation, and disclosure system

Testing creates value only when findings reach owners safely and correction can be verified.

  • Security coordinates the engagement; engineering and operations help identify versions, reproduce effects and implement fixes; incident response monitors for unintended impact; privacy and legal owners govern sensitive evidence and disclosure; suppliers address inherited defects; risk owners place findings in the actual business context.
  • Tools may enumerate targets, generate candidate tests, replay requests or classify evidence, but an accountable person confirms authorization before each consequential action and validates every reported finding. No agent or scanner receives open-ended permission to exploit, persist, disrupt, pivot or disclose.
  • The client maintains the scope, action log, finding register, evidence, remediation decisions, accepted exceptions, retest results, residual risk and cleanup record. Hiring owners verify relevant experience, safe judgment, reporting clarity, engagement terms and current availability before access is issued.

Capability evidence

Assess one target from written permission to verified correction.

A capture-the-flag score or tool list does not show production judgment. Give the person a bounded application or service, incomplete rules of engagement, a realistic threat question and a finding that crosses technical and business ownership.

01

Authorization, target ownership, rules of engagement, and safety

Provide several domains, cloud resources and supplier dependencies, plus a vague request to test everything. Ask the person to establish what can actually be authorized and what must remain untouched.

Confirm: The person verifies the legal entity, asset owner and authority chain rather than treating credentials or public reachability as consent; identifies third-party infrastructure, shared tenancy, managed services and platform terms; names exact FQDNs, IP ranges, applications, APIs, accounts, environments, builds and excluded assets; records start, end, timezone and test source identities; distinguishes vulnerability scanning, penetration testing, code review, adversary simulation, social engineering, physical, wireless, denial-of-service and disclosure activity; requires explicit inclusion for techniques with different harm or consent; defines production approval, maintenance window, backups, restoration, monitoring coordination, data limits, rate limits, prohibited actions, emergency contacts, critical escalation, stop triggers and scope-change authority; rejects ambiguous or expired authorization; and records an out-of-scope dependency as a limitation or requests approval without touching it.

02

Threat-informed hypotheses, safe execution, and target-state evidence

Provide a web application, API or infrastructure target with a stated security objective, a test account and a mix of scanner alerts. Ask for a test plan and the smallest useful proof.

Confirm: The person maps the target architecture, trust boundaries, identities, entry points, data flows and exposed versions; chooses a relevant threat or security property rather than exhausting a checklist blindly; combines current requirements, weakness classes and adversary techniques without claiming they define complete coverage; records hypothesis, prerequisite, test data, expected secure behavior and abort condition; confirms target identity and build immediately before action; uses controlled accounts and synthetic data where possible; sets safe concurrency and payload bounds; recognizes state-changing, destructive, costly and availability-sensitive operations; does not pivot, persist, alter logs or collect unrelated data; captures request, response, command, log, trace, screenshot or state delta with time and tester identity; repeats only enough to establish reproducibility; and labels an unavailable, blocked, inconclusive or false-positive test honestly.

03

Finding validation, severity, client risk, reporting, and escalation

Provide a high scanner score with weak evidence, a low-scored authorization flaw on a critical workflow, duplicates across assets and a live critical condition. Ask what becomes a reportable finding and how it reaches owners.

Confirm: The person independently validates automated output; identifies the affected asset, build, endpoint, role and configuration; states prerequisite, technique, observed security effect and evidence; separates the weakness, vulnerability instance, attack path and business consequence; distinguishes confirmed, suspected, duplicate, accepted, invalid and untested states; records confidence and limitation; maps to a versioned weakness or verification reference where useful; supplies safe reproduction steps and redacted evidence; calculates technical severity with a disclosed vector and inputs when CVSS is requested; does not present technical severity as client risk; adds exposure, exploit evidence, data, safety, customer, regulatory, operational and compensating-control context for an accountable risk owner; escalates critical findings through the agreed live channel; avoids sensational language and exploit publication; and states exactly which systems, identities, methods and time period the conclusion covers.

04

Remediation options, retest, disclosure, cleanup, and continuity

Provide a confirmed finding, a proposed patch, an interim control, a supplier dependency, a later build and copied test evidence. Ask how the engagement closes without turning a report into shelfware.

Confirm: The person explains root cause and affected variants without prescribing one unreviewed fix; works with owners on removal, update, configuration, validation, authorization, isolation, monitoring or other controls; records owner, priority, target, dependency, interim protection and accepted exception; preserves the original finding while linking remediation evidence; retests the same prerequisite and security effect on an identified changed build; checks for regression and relevant variants without silently expanding scope; reports fixed, partially fixed, mitigated, not fixed, cannot retest or risk accepted distinctly; returns disclosure and notification decisions to authorized owners and coordinated processes; retains embargo and sensitive details as agreed; revokes accounts and keys, removes payloads and persistence, restores modified state, accounts for copied data and evidence deletion, and records residual artifacts; leaves the client with versioned scope, action, finding, decision, retest and cleanup records another authorized tester can follow.

Assessment sequence

Move from explicit authority to a finding the owning team can close.

The useful sequence is deliberately conservative. Permission and safety come before coverage, evidence comes before severity, and remediation is not complete until the relevant condition has been checked again.

  1. 01

    Authorize the exact engagement

    Confirm owner and signing authority, targets, exclusions, time, tester identities, third-party terms, permitted and prohibited techniques, production safeguards, data handling, reporting, escalation, stop conditions and scope-change decisions in current rules of engagement.

  2. 02

    Model the target and choose hypotheses

    Record architecture, trust boundaries, versions, identities, data and dependencies, connect the objective to plausible threats and security requirements, select proportionate manual and automated tests, and define expected behavior and the least invasive proof.

  3. 03

    Test safely and preserve the observed effect

    Reconfirm target state and permission, use controlled accounts and data, obey rate and action limits, capture the exact attempt and result, stop on instability or unexpected boundaries, and make false positives, blocked tests and limitations visible.

  4. 04

    Validate, escalate, and route the finding

    Confirm reproducibility and affected scope, redact sensitive evidence, state prerequisite effect confidence and limits, calculate technical severity transparently, add business context without claiming risk authority, and deliver material findings through the agreed channel.

  5. 05

    Remediate, retest, clean up, and hand over

    Track the owner's chosen correction and interim protection, retest the same condition on an identified build, record residual risk and disclosure decisions, remove tester access artifacts and copied data, and leave complete client-held evidence.

Authorized testing loops

Keep every technical action attached to permission, safety, evidence, and an owner.

Security testing becomes dangerous or decorative when permission is assumed, tools define the scope, severity replaces risk or reports stop before verified correction. These loops preserve the chain that matters.

  1. 01

    Authorization and pre-action loop

    Can the tester prove this exact target, identity, technique and time are authorized before the next action runs?

    Working evidence: Engagement and rules version, signer and authority, asset owner, target identifier, environment, build, third-party approval, tester identity, source address, allowed window, approved technique, prohibition, rate and data limit, contact, stop trigger, scope decision and authorization check time.

  2. 02

    Hypothesis, attempt, and finding loop

    Does the evidence show the stated security effect on the identified target without unnecessary harm?

    Working evidence: Security question, threat and requirement reference, prerequisite, account and test data, expected secure result, tool and version, command or request, timestamp, response, log, trace, screenshot, state before and after, reproduction count, observed effect, redaction, confidence, duplicate, false positive, blocked action and limitation.

  3. 03

    Severity, risk, and remediation loop

    Has a validated technical finding reached the person who owns its business context and correction?

    Working evidence: Finding identity, asset and version, weakness class, attack path, technical severity vector and rationale, exploit and exposure evidence, affected data and workflow, safety and operational context, compensating control, risk owner, decision, remediation owner, action, target date, interim protection, exception and escalation record.

  4. 04

    Retest, closure, and disclosure loop

    Was the relevant condition checked again and the engagement closed without leaving access, artifacts or hidden uncertainty?

    Working evidence: Original finding, fix commit or configuration, changed build and environment, retest scope and method, regression and variant checks, result, unresolved condition, residual risk owner, disclosure authority and status, account and key revocation, payload removal, restored state, copied-data disposition, retained evidence, deletion confirmation and receiving owner.

Continuity controls

Recover without one tester, one scanner account, or an unexplained exploit archive.

Security evidence belongs to the client and should outlast the engagement without preserving unnecessary access or dangerous material. Another authorized owner must be able to understand what happened and what remains open.

Signed scope and action ledger
Rules versions, authorities, targets, exclusions, third-party permissions, identities, windows, techniques, safety limits, approvals, scope changes, stop events and timestamped actions remain linked and reviewable.
Redacted finding and evidence register
Target state, hypotheses, prerequisites, attempts, observed effects, evidence locations, weakness references, confidence, severity inputs, duplicates, false positives, blocked tests, untested surfaces and limitations survive without unnecessary secrets or personal data.
Owned remediation and retest trail
Business context, risk decisions, interim protections, owners, fixes, exceptions, supplier actions, changed builds, retest procedures, regression results, residual conditions and disclosure decisions preserve history rather than overwriting the original finding.
Demonstrated cleanup and controlled handoff
Accounts, keys, allowlists, payloads, test records, copied data, modified state and retained evidence are accounted for; access is revoked; necessary artifacts move to approved client custody; and another authorized tester can reproduce the conclusion within a new approved window.

Fit check

Use an authorized security tester when a bounded system question needs adversarial evidence.

Good reason to begin

  • The client can identify target owners and grant written permission, define exact environments and techniques, coordinate production safety, provide current architecture and builds, and keep an accountable response contact available.
  • There is a specific assurance question, release, attack path, change or vulnerability-management process to challenge, and engineering risk legal privacy incident and supplier owners can act on findings.
  • The organization wants reproducible evidence, explicit coverage limits, transparent severity, owned remediation, retesting, cleanup and client-held records rather than a badge, tool dump or theatrical compromise.

Resolve before beginning

  • No person can prove ownership or authority for the targets, supplier or cloud terms are unresolved, authorization is verbal or expired, or the request includes systems belonging to another party without written permission.
  • Production safety, restoration, monitoring, emergency contacts and stop authority are absent, or denial of service, social engineering, physical access, wireless testing, persistence, real-data access or destructive techniques are expected without explicit controls.
  • Leadership wants a guarantee that the system is secure, a compliance certificate, covert monitoring of people, uncontrolled exploit development, public disclosure, or a high score that supports a predetermined business decision.
  • There is no owner or capacity to triage and remediate findings, no safe evidence repository, no path to protect sensitive details, or the engagement ends at report delivery with no retest and cleanup authority.

Source basis

Sources behind the control model.

  • 01

    UK National Cyber Security Centre

    Penetration testing

    The guidance treats penetration testing as a bounded assurance activity, describes engagement, scoping, testing, reporting and follow-up, requires risk-owner involvement, warns that unexpected impact cannot be eliminated, and leaves scope changes and business risk decisions with accountable owners.

  • 02

    National Institute of Standards and Technology

    Technical Guide to Information Security Testing and Assessment, SP 800-115

    The final guide covers planning and conducting technical tests, analyzing findings and developing mitigation, while emphasizing the benefits and limitations of different assessment techniques rather than presenting one exhaustive method.

  • 03

    National Institute of Standards and Technology

    Recommendations for Federal Vulnerability Disclosure Guidelines, SP 800-216

    The 2023 framework formalizes how organizations accept, assess, manage and communicate vulnerability reports. Its federal scope is explicit, but the intake, ownership, coordination and remediation chain is broadly useful.

  • 04

    Cybersecurity and Infrastructure Security Agency

    Binding Operational Directive 20-01 vulnerability disclosure policy

    CISA explains that a disclosure policy should state authorized systems and test types, reporting expectations and communication commitments. The directive applies to US federal civilian agencies and does not grant permission for unrelated targets.

  • 05

    U.S. Department of Justice

    Justice Manual 9-48.000, Computer Fraud and Abuse Act

    The current charging policy makes authorization and the limits of authorized access legally consequential in its US federal context. It is prosecutor guidance, not legal advice or a safe harbor for a private engagement.

  • 06

    OWASP Foundation

    Web Security Testing Guide, latest contributions

    The living guide organizes a testing framework, web-application test areas and reporting. Because the latest branch can change, engagement records should preserve the exact version and selected tests rather than claim timeless coverage.

  • 07

    OWASP Foundation

    Application Security Verification Standard

    ASVS 5.0.0 provides versioned requirements for verifying web-application technical security controls and for specifying assurance in contracts. It is a requirements basis, not proof that every relevant path was tested successfully.

  • 08

    OWASP Foundation

    API Security Project

    The project identifies API-specific risks including object and function authorization, authentication, resource consumption, business flows, inventory and unsafe supplier consumption. Its Top 10 is an awareness model, not a complete test plan.

  • 09

    OWASP Foundation

    Mobile Application Security Verification Standard

    MASVS supplies mobile application security requirements across storage, cryptography, authentication, network, platform, code, resilience and privacy. Mobile scope still needs identified builds, devices, backends and test evidence.

  • 10

    Forum of Incident Response and Security Teams

    CVSS version 4.0 specification

    The specification defines transparent Base, Threat, Environmental and Supplemental metrics and requires a vector with a published score. It explicitly places customer, monetary, regulatory and reputational factors outside CVSS itself.

  • 11

    Forum of Incident Response and Security Teams

    CVSS version 4.0 consumer implementation guide

    The consumer guide helps organizations add current threat and local environmental context to technical severity. It supports, but does not replace, an accountable business-risk and remediation decision.

  • 12

    Cybersecurity and Infrastructure Security Agency

    Known Exploited Vulnerabilities Catalog

    The living catalog records vulnerabilities with evidence of active exploitation and is an input to remediation prioritization. Presence in or absence from the catalog does not establish the client's exposure, complete risk or test scope.

  • 13

    National Institute of Standards and Technology

    Secure Software Development Framework version 1.1, SP 800-218

    SSDF connects vulnerability response with secure development practices that reduce recurrence and impact. Findings should therefore reach engineering causes and development controls, not remain isolated report entries.

  • 14

    National Institute of Standards and Technology

    Assessing Security and Privacy Controls, SP 800-53A Revision 5

    Release 5.2.0 provides customizable assessment procedures and guidance for assessment plans and results. A procedure must be tailored to scope and risk tolerance, and an assessment result remains bounded by its objectives and evidence.

  • 15

    MITRE

    2025 CWE Top 25 Most Dangerous Software Weaknesses

    The current archived ranking connects prevalent weakness classes with observed vulnerability data. It helps discuss root cause and coverage, but a ranked weakness list does not show that a particular target is vulnerable.

  • 16

    MITRE

    Common Weakness Enumeration

    CWE provides a shared taxonomy for software and hardware weakness classes. Mapping a validated finding can improve remediation communication, but the identifier should not substitute for target-specific evidence.

  • 17

    MITRE

    ATT&CK knowledge base

    ATT&CK organizes adversary tactics and techniques based on real-world observations and can inform scenario coverage. It does not authorize use of a technique or prove that every relevant behavior was tested.

  • 18

    UK National Cyber Security Centre

    CHECK penetration testing scheme

    The scheme describes qualified companies and testers for authorized assessments of UK government and critical national infrastructure systems. Its eligibility and assurance context are specific and should not be implied for a general role.

  • 19

    UK National Cyber Security Centre

    Vulnerability Reporting

    The reporting guidance directs researchers to contact the affected owner, limits sharing without express consent and keeps resolution responsibility with that owner. It demonstrates why discovery does not confer publication authority.

  • 20

    UK National Cyber Security Centre

    Vulnerability management

    The current collection frames vulnerability work as a continuing process of asset identification, triage, prioritization, remediation and verification, with organizational ownership of risks that are not addressed.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Browse the hire map

Compare authorized testing with compliance, security architecture, defensive operations, quality assurance and engineering roles before fixing the title.

Open path02

Review how Werkon works

Use the delivery model to inspect how authority, evidence, review, controlled change, handoff and client ownership fit together.

Open path03

Review cloud security

Start with cloud security when the central outcome is an owned cloud security architecture and operating model rather than a bounded adversarial test.

Open path04

Review systems audit

Use systems audit when the immediate need is a broad current-state evidence baseline before choosing a narrower security test.

Open path