Blog › ICP guides

Penetration tester on retainer: web application testing, network penetration, Active Directory exploitation, and security assessment advisory on monthly retainer

August 7, 2026 · ~19 min read

A 150-person financial services software company processes $2 billion in annual payment volume across its platform. The CISO has received board-level direction to establish a proactive security testing program following a payment card industry compliance audit that identified inadequate penetration testing frequency as a finding. The company has completed one annual penetration test from a large consulting firm, but the CISO wants to move to a continuous assessment model that tests different parts of the attack surface each month rather than a single annual engagement that becomes stale within weeks of the report delivery. The CISO engages a fractional penetration tester on monthly retainer to conduct rolling security assessments — web applications in month one, internal network and Active Directory in month two, cloud infrastructure and API security in month three, and remediation validation plus social engineering assessment in month four — providing continuous visibility into the security posture of the most critical systems.

In month one: a web application penetration test of the customer-facing payment portal, the internal admin dashboard, and the REST API endpoints that process payment transactions. The test discovers a critical JWT algorithm confusion vulnerability in the admin portal (the RS256-signed JWT token is accepted when the algorithm header is modified to HS256 and signed with the RSA public key obtained from the public JWKS endpoint, allowing unauthenticated access to the admin portal), a high-severity IDOR vulnerability on the payment transaction history API (authenticated users can read transaction records for other user accounts by modifying the transaction ID parameter), and six medium and low severity findings. The CISO is alarmed by the critical finding and wants to understand how the 7 hours billed for the authentication testing session produced a critical finding while the prior annual engagement missed it entirely. The penetration tester explains that the annual engagement used automated scanning tools against a broader scope with less time per application, and the JWT algorithm confusion vulnerability requires manual testing of the token validation logic with a specific HS256/RS256 confusion exploit that automated scanners do not detect. The critical finding is visible. The 7 hours of manual authentication testing methodology and the deep JWT exploitation knowledge behind it are not visible in the Jira ticket that documents the finding.

Penetration testers and ethical hackers on monthly retainer — independent security researchers, fractional red team operators, and boutique penetration testing consultants — perform their highest-value work in the reconnaissance, manual exploitation research, Active Directory attack path analysis, and remediation validation that precedes and validates every visible finding: the OSINT research behind the scope intelligence report, the manual authentication testing methodology behind the critical JWT finding, the BloodHound analysis behind the Active Directory attack path, and the retest exercise behind the remediation validation report. This guide covers web application penetration testing (OWASP Top 10, authentication, business logic), network penetration testing (external and internal), Active Directory and identity security testing (BloodHound, Kerberoasting, AS-REP Roasting), API and cloud security assessment, and remediation advisory — and how to structure a penetration testing retainer that makes the hours behind each assessment function visible.

Scope definition, rules of engagement, and reconnaissance

The most important document in a penetration testing engagement is the scope definition and rules of engagement (ROE) signed before any testing begins. Without a signed ROE, the penetration tester has no legal authorization to conduct testing, and any vulnerability discovery or system access — even with good intentions — exposes the penetration tester to criminal liability under the Computer Fraud and Abuse Act (18 U.S.C. §1030) in the United States, the Computer Misuse Act 1990 in the United Kingdom, or equivalent computer crime statutes in the relevant jurisdiction.

Rules of engagement and scope documentation

The rules of engagement document specifies: Systems in scope (IP ranges, CIDR blocks, hostnames, URLs, and application names explicitly authorized for testing); systems out of scope (third-party services, shared hosting environments, production databases containing customer PII that must not be written to, and any systems the client organization does not have authority to authorize for testing); testing techniques authorized (passive reconnaissance only; active vulnerability scanning; authenticated web application testing as a named test user account; internal network testing from a VPN-connected Kali Linux VM; Active Directory testing using a standard domain user account; or social engineering simulation against the phishing awareness training group — each technique must be explicitly authorized in writing before execution); testing windows (the hours during which disruptive testing techniques are authorized, typically outside peak business hours for techniques that risk service disruption, such as aggressive vulnerability scanning or denial-of-service condition testing); and immediate escalation conditions (the named CISO and engineering contact who must be notified within 30 minutes if the penetration tester discovers evidence of an active breach, ransomware activity, or a critical vulnerability that is likely being actively exploited in the wild at the time of discovery).

Passive reconnaissance and OSINT research

Passive reconnaissance — gathering information about the target organization using publicly available sources without generating network traffic that the target could detect — is the first phase of every penetration testing engagement. The penetration tester conducts OSINT (Open Source Intelligence) research across multiple sources: Shodan and Censys for internet-exposed services (identifying internet-facing hosts in the target IP ranges that are exposing services such as RDP (TCP 3389), SMB (TCP 445), database ports (TCP 5432, 3306, 1433), or administrative interfaces); Certificate Transparency logs (using crt.sh or the Censys certificate search to enumerate subdomains of the target domain that appear in TLS certificate SANs, revealing test environments, internal applications, and shadow IT applications that are not in the initial scope document but may be owned by the target organization); GitHub and GitLab dorking (searching GitHub for the target organization’s name and domain using search operators to identify repositories containing accidentally committed credentials, API keys, configuration files, or internal architecture documentation); LinkedIn and job posting intelligence (reviewing the target organization’s LinkedIn employee list for roles that indicate technology stack (DevOps engineers listing “Kubernetes, Terraform, AWS”; database administrators listing “PostgreSQL, MongoDB”) and reviewing current job postings that disclose specific technologies the organization is using or hiring for); and DNS enumeration and WHOIS (enumerating subdomains using passive DNS databases such as SecurityTrails and VirusTotal, and reviewing WHOIS records for registrant contact information and registration history).

The OSINT reconnaissance phase — querying each data source, analyzing and correlating the results, identifying the most interesting leads for active testing, and compiling the reconnaissance findings into a scope intelligence report — typically requires 8 to 20 hours before any active testing begins. The client sees the scope intelligence report; the hours of OSINT research and correlation behind it are not visible in the document.

Web application penetration testing: OWASP Top 10 and beyond

Web application penetration testing is the most common retainer function for penetration testers working with software companies, because web applications represent the primary external attack surface for most organizations and require manual testing expertise to identify the business logic and application-specific vulnerabilities that automated scanners cannot discover.

Authentication and session management testing

Authentication and session management testing addresses OWASP A07 (Identification and Authentication Failures) — the class of vulnerabilities arising from weaknesses in how the application authenticates users and manages authenticated sessions. The penetration tester tests: JWT implementation security (decoding the JWT token to inspect the algorithm header, testing the algorithm confusion attack (switching from RS256 to HS256 and signing with the RSA public key to bypass signature validation on systems that accept multiple algorithms), testing the none algorithm attack (setting alg: none and removing the signature), and testing for JWT token expiry, revocation, and rotation deficiencies); OAuth 2.0 implementation security (testing for authorization code interception via open redirect in the redirect_uri parameter, testing for state parameter absence or weakness enabling CSRF attacks, and testing for token leakage in Referer headers or browser history); Multi-factor authentication bypass (testing whether the MFA step can be bypassed by direct navigation to post-authentication endpoints, testing whether backup code entropy is sufficient, and testing for MFA fatigue attack susceptibility where repeated push notifications can lead users to approve fraudulent authentication requests); and Session token analysis (using Burp Suite’s Sequencer tool to analyze session token entropy and predictability, and testing session fixation vulnerabilities where the session token is not regenerated on authentication).

Broken access control and IDOR testing

Broken access control — OWASP A01 in the 2021 ranking — is the most prevalent category of web application vulnerability, encompassing all cases where the application fails to enforce that authenticated users can only access resources and perform actions they are authorized for. The penetration tester tests for Insecure Direct Object Reference (IDOR) vulnerabilities by systematically modifying resource identifier parameters (user IDs, account IDs, order IDs, document IDs, and any other identifier in URL paths, query parameters, or request body fields) to identify cases where the application returns resources belonging to other users without an authorization check; horizontal privilege escalation (accessing resources belonging to users at the same privilege level by parameter manipulation); vertical privilege escalation (accessing resources or performing actions reserved for higher-privileged roles by parameter manipulation, function-level access control bypass, or forced browsing to restricted URLs); and missing function-level access control (accessing administrative functions by direct URL navigation that the application makes accessible based on UI visibility rather than server-side authorization).

Business logic vulnerability testing

Business logic vulnerabilities are application-specific security flaws arising from incorrect assumptions in the application’s workflow design that cannot be discovered by automated scanners because they require understanding the intended behavior of the application to identify deviations from it. The penetration tester identifies business logic vulnerabilities by mapping the application’s state machine — the sequence of steps required to complete each significant workflow (payment processing, order fulfillment, subscription management, user invitation) — and then testing each transition for: Workflow bypass (skipping required steps in a multi-step process, such as proceeding from checkout directly to order confirmation without payment authorization); Negative price manipulation (testing whether the application accepts negative quantities or coupon codes that result in negative order totals, triggering refunds or credits); Race condition exploitation (submitting concurrent requests for operations that should be atomic, such as simultaneously redeeming a one-time-use promo code from multiple sessions, or simultaneously initiating a funds transfer from an account with insufficient balance across two sessions before either transaction completes the balance check); and Quantity and limit bypass (testing whether per-user, per-session, or per-IP rate limits and quantity limits can be bypassed through parameter manipulation, session switching, or distributed request patterns). Business logic testing for a complex application workflow typically requires 10 to 20 hours of manual testing per workflow category.

Network penetration testing: external and internal assessments

Network penetration testing assesses the security of the organization’s network infrastructure — the internet-facing perimeter, internal network segmentation, and host-level vulnerability exposure — by conducting structured reconnaissance and exploitation against the in-scope network ranges.

External network assessment

The external network assessment evaluates the organization’s internet-facing attack surface. The penetration tester conducts: Port scanning and service enumeration using Nmap with TCP SYN scanning (-sS), service version detection (-sV), OS fingerprinting (-O), and the NSE (Nmap Scripting Engine) vulnerability detection scripts (--script vuln) against all 65,535 TCP ports and common UDP ports across the in-scope IP ranges; Vulnerability scanning using Nessus or OpenVAS against the services identified in the port scan, with authenticated scanning for hosts where the client provides scanning credentials to identify a broader set of vulnerabilities than unauthenticated scanning can discover; SSL/TLS configuration assessment using testssl.sh or SSLyze to identify weak cipher suites (RC4, DES, 3DES), deprecated protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1), self-signed or expired certificates, BEAST and POODLE attack susceptibility, and weak DH parameter sizes (<2048 bits); and Manual exploitation of identified high and critical vulnerabilities using Metasploit Framework modules or published proof-of-concept exploit code for confirmed vulnerabilities (with explicit authorization in the rules of engagement for techniques that could disrupt service, such as denial-of-service condition testing or exploitation of memory corruption vulnerabilities that may crash services).

Internal network assessment and lateral movement testing

The internal network assessment simulates the attacker’s perspective after gaining an initial foothold inside the corporate network — either through a compromised endpoint (simulated by connecting from a VPN-connected Kali Linux VM with an internal IP address) or through an assumed-breach scenario (starting the assessment with the credentials of a standard domain user account, simulating a phishing attack that has successfully compromised a standard employee). The penetration tester tests: Network segmentation (whether network segments that should be isolated — development, production, finance, healthcare — are correctly separated, and whether network controls prevent lateral movement between segments); Internal service exposure (identifying internal services exposed across the internal network that should be restricted to specific hosts or segments, such as database ports, administrative interfaces, backup systems, and internal API endpoints); and Credential relay attacks (testing whether the internal network is vulnerable to NTLM relay attacks, where an attacker on the network can capture NTLM authentication hashes and relay them to authenticate to other network services, using Responder to capture authentication attempts and ntlmrelayx to relay them).

Active Directory and identity security testing

Active Directory security testing is one of the highest-value penetration testing functions for organizations running Windows domain environments, because Active Directory attack paths from low-privileged users to Domain Administrator are both prevalent and extremely dangerous — a compromised domain administrator account gives an attacker complete control over every Windows workstation and server in the domain, the ability to decrypt all domain-authenticated traffic, and the persistence to survive operating system reinstallation on individual hosts through Group Policy Object (GPO) modification and domain trust abuse.

BloodHound attack path analysis

BloodHound (developed by SpecterOps and Andy Robbins, Rohan Vazarkar, and Will Schroeder) is the primary tool for Active Directory attack path discovery. BloodHound builds a graph database of Active Directory objects (users, computers, groups, GPOs, OUs, domains, and trusts) and the relationships between them (group memberships, ACL permissions, session data, and local administrator relationships), and then queries the graph to identify attack paths from a given starting node (a standard domain user account) to a given target node (Domain Admins group membership or KRBTGT account access). The SharpHound data collector runs on a domain-joined Windows host and collects the Active Directory data required to populate the BloodHound graph using LDAP queries and SMB-based session enumeration.

The penetration tester analyzes the BloodHound graph to identify the attack paths most likely to be exploited by a real attacker: the shortest paths from owned accounts (the standard domain user credentials provided for the assumed-breach scenario) to Domain Admins; paths involving misconfigured ACLs (GenericAll, WriteDACL, or GenericWrite permissions on high-value targets that allow privilege escalation without exploiting a software vulnerability); paths involving constrained or unconstrained delegation (computer accounts with unconstrained delegation configured that can be abused to capture the TGT of any user who authenticates to a service on that computer); and paths involving trust relationships to other domains or forests that could be abused for cross-trust privilege escalation. The BloodHound analysis phase — running SharpHound, importing the collected data into BloodHound, querying the attack path graph for significant paths, researching each identified path step to verify exploitability in the target domain’s specific configuration, and documenting the finding with reproduction steps — typically requires 8 to 16 hours of analysis work before the attack path findings can be documented.

Kerberoasting and AS-REP Roasting

Kerberoasting is an Active Directory attack that exploits the Kerberos ticket-granting service to extract crackable password hashes for service accounts that have Service Principal Names (SPNs) registered. Any authenticated domain user can request a Kerberos service ticket (TGS) for any SPN in the domain; the TGS is encrypted with the service account’s NTLM password hash. The penetration tester requests TGS tickets for all SPN-registered accounts using GetUserSPNs.py (Impacket) or Invoke-Kerberoast (PowerSploit), exports the ticket hashes in Hashcat format, and attempts to crack the hashes offline using a GPU-accelerated dictionary attack with Hashcat and the rockyou.txt wordlist combined with custom rules. Service accounts with weak passwords (dictionary words, company name + year patterns) are typically cracked within hours, providing the penetration tester with the service account’s cleartext password and the privileges associated with that account.

AS-REP Roasting is an analogous attack against user accounts that have Kerberos pre-authentication disabled (the DONT_REQ_PREAUTH flag set in the Active Directory User Account Control attribute). When pre-authentication is disabled, the Kerberos Authentication Server returns an AS-REP (Authentication Service Response) containing the user’s TGT encrypted with a key derived from the user’s password, without requiring the requester to prove knowledge of the user’s password first. The penetration tester uses GetNPUsers.py (Impacket) to enumerate accounts with pre-authentication disabled and request their AS-REP hashes, then attempts to crack the hashes offline using Hashcat. The finding is particularly significant because pre-authentication is typically disabled by mistake or for legacy compatibility, and the affected accounts often include service accounts with elevated privileges.

API security testing and cloud misconfiguration assessment

API security testing and cloud misconfiguration assessment are the two most rapidly growing penetration testing service areas, reflecting the shift in attack surface from traditional web applications and internal networks toward REST and GraphQL APIs and cloud infrastructure.

API penetration testing: OWASP API Security Top 10

The OWASP API Security Top 10 (2023 edition) provides the testing taxonomy for REST and GraphQL API security assessments: API1:2023 Broken Object Level Authorization (BOLA, the API-specific equivalent of IDOR — testing whether the API enforces object-level authorization on every API endpoint that accepts an object identifier); API2:2023 Broken Authentication (testing JWT implementation, OAuth 2.0 configuration, and API key entropy and rotation practices); API3:2023 Broken Object Property Level Authorization (testing whether the API filters response object properties based on the caller’s authorization level, or whether standard user API responses include fields reserved for admin callers); API4:2023 Unrestricted Resource Consumption (testing whether the API enforces rate limits, request size limits, and resource quotas to prevent abuse of computationally expensive endpoints); API5:2023 Broken Function Level Authorization (testing whether administrative API endpoints are accessible to standard user credentials); API6:2023 Unrestricted Access to Sensitive Business Flows (testing whether the API’s business flows can be abused by automated clients without the rate limiting and human-interaction controls that protect the web interface); API8:2023 Security Misconfiguration (testing CORS configuration, unnecessary HTTP methods, verbose error messages disclosing stack traces or internal paths, and security header configuration); and API9:2023 Improper Inventory Management (testing whether undocumented or deprecated API versions are accessible and have weaker security controls than the documented current version).

The penetration tester begins the API assessment by importing the API’s OpenAPI (Swagger) specification into Burp Suite or Postman to map all available endpoints, then systematically tests each endpoint for the OWASP API Security Top 10 categories using a combination of automated scanning (Burp Suite’s active scanner configured against the API endpoint list) and manual testing (crafting specific test payloads for BOLA, broken function level authorization, and mass assignment vulnerabilities that automated scanners cannot reliably discover). For GraphQL APIs, the assessment includes introspection query testing (whether introspection is enabled in production, disclosing the complete API schema to unauthenticated requesters), batch query abuse testing (whether the API enforces limits on the number of operations in a single batch request, preventing denial of service via deeply nested or highly multiplied batch queries), and field suggestion testing (whether the API returns error messages that suggest valid field names when invalid field names are queried, enabling schema enumeration when introspection is disabled).

Cloud infrastructure misconfiguration assessment

Cloud misconfiguration assessment evaluates the organization’s AWS, Google Cloud, or Azure environment for configuration errors that expose resources to unauthorized access or privilege escalation. The penetration tester uses cloud security assessment tools — Prowler (open-source, AWS and GCP; maps findings to CIS Benchmarks and NIST CSF), ScoutSuite (open-source, multi-cloud; provides HTML reports of misconfiguration findings by service category), and CloudSplaining (AWS IAM policy analysis that identifies overpermissioned IAM policies, privilege escalation paths via IAM, and excessive use of wildcard actions and resources) — to enumerate misconfigurations across the cloud environment, and then manually investigates the most significant findings to verify exploitability and assess impact. Common high-severity cloud misconfiguration findings include: S3 buckets with public read or public write access enabled; EC2 instance metadata service (IMDS) v1 enabled without requiring IMDSv2 (v1 allows any process running on the instance to retrieve the instance’s IAM role credentials by calling http://169.254.169.254/latest/meta-data/iam/security-credentials/ without any authentication token, enabling server-side request forgery attacks against the metadata endpoint to steal cloud credentials); and overpermissioned IAM roles attached to EC2 instances or Lambda functions that provide far broader AWS API access than the workload requires.

Report writing and remediation advisory

The penetration testing report is the primary deliverable of each assessment cycle: the document that the CISO presents to executive leadership to justify security investment, that the engineering team uses to implement remediations, and that compliance auditors review to verify that penetration testing is being conducted. A well-structured penetration testing report consists of three sections.

The executive summary (2 to 4 pages) provides a non-technical overview of the assessment scope, the overall risk rating of the findings, the most significant findings with a plain-language description of the business impact, and the penetration tester’s overall assessment of the organization’s security posture relative to the prior assessment cycle or industry baseline. The executive summary is the section the CISO presents to the board; it communicates business risk, not technical detail.

The technical findings section documents each finding with: a title, severity rating (Critical, High, Medium, Low, or Informational), CVSS v3.1 base score and vector string, affected system or endpoint, description of the vulnerability and how it was discovered, step-by-step reproduction procedure (sufficient for the engineering team to reproduce the finding without the penetration tester present), business impact statement (what an attacker could do if they exploited this vulnerability, in business terms), and a recommended remediation approach. Each finding is assigned a remediation priority based on the CVSS score and exploitability (whether a working exploit exists, whether it requires authentication, and whether the vulnerability is known to be actively exploited in the wild).

The remediation advisory is the ongoing retainer function that distinguishes a penetration testing retainer from a point-in-time engagement: the penetration tester provides advisory support to the engineering team as they implement remediations, answering questions about whether a proposed fix actually addresses the root cause of the vulnerability or only its surface manifestation, and conducts retest validation in the subsequent assessment cycle to verify that each remediated finding is no longer exploitable. Remediation advisory — reviewing proposed fixes via pull request or system design review, answering engineering team questions, and retesting remediated findings — typically requires 4 to 10 hours per monthly retainer cycle, providing the CISO with documented retest results that demonstrate continuous security improvement.

Tracking penetration tester retainer hours with a shared dashboard

Penetration testers and ethical hackers on monthly retainer perform their highest-value work in the OSINT reconnaissance that precedes active testing, the manual authentication and business logic testing that discovers vulnerabilities automated scanners miss, the Active Directory attack path analysis that maps the domain’s privilege escalation risks, and the remediation advisory that ensures findings are actually fixed rather than documented and forgotten. None of these activities produces an artifact that communicates the hours behind it.

A penetration testing report is a PDF. A Jira finding ticket is a paragraph. A BloodHound attack path diagram is a graph. A retest validation is a status table. None of these artifacts communicates whether the underlying reconnaissance, testing, and analysis took 5 hours or 50 hours. The CISO who approved a $10,000/month penetration testing retainer and sees a 20-page PDF at the end of month one may struggle to explain to the CFO why the engagement cost $10,000 when the prior annual penetration test from a large firm cost $25,000 and produced a 60-page report. The work log showing the 15 hours of OSINT reconnaissance that discovered the shadow IT subdomain with an unpatched Confluence instance, the 7 hours of manual JWT testing that found the critical algorithm confusion vulnerability the automated scanner missed, and the 8 hours of BloodHound analysis that mapped the three-hop attack path from a standard domain user to Domain Administrator — transforms the engagement from a monthly security PDF into a documented continuous assessment record that the CISO can use to demonstrate the ROI of the retainer relative to annual point-in-time testing.

HourTab provides a public, no-login retainer dashboard URL that the penetration tester sends to the CISO once, and the CISO bookmarks for the duration of the engagement. The dashboard shows the current retainer burn-down (hours used versus hours remaining in the monthly cycle), a chronological work log of entries from the consultant, and the reset date for the next billing cycle — giving the CISO a self-serve view of the penetration testing work that connects each hour to a specific assessment phase, finding, or remediation advisory function.

Frequently asked questions

What does a penetration tester on retainer typically do?

A penetration tester or ethical hacker on monthly retainer provides ongoing security assessment and advisory across four service areas: web application penetration testing (conducting structured assessments against the OWASP Top 10, testing authentication and session management for JWT algorithm confusion, OAuth misconfiguration, and MFA bypass, testing for IDOR and broken access control, and testing for business logic vulnerabilities specific to the application's workflows); network penetration testing (conducting external port scanning and vulnerability scanning, testing internal network segmentation, and attempting lateral movement from a foothold inside the network perimeter); Active Directory and identity security testing (mapping attack paths from standard domain user to Domain Administrator using BloodHound, testing for Kerberoasting and AS-REP Roasting vulnerabilities, and assessing privileged account hygiene and ACL misconfigurations); and API security and cloud misconfiguration assessment (testing REST and GraphQL APIs against the OWASP API Security Top 10, and assessing AWS, GCP, or Azure environments for IAM misconfigurations, exposed storage, and metadata service exploitation risks). The retainer provides a rolling assessment cycle covering a different attack surface domain each month, combined with remediation advisory and retest validation of prior findings.

What penetration testing work is most commonly underlogged?

The most systematically underlogged categories in penetration tester retainers are: OSINT reconnaissance (querying Shodan, Censys, certificate transparency logs, GitHub, LinkedIn, and job postings to build scope intelligence before active testing — typically 8 to 20 hours invisible in the resulting scope intelligence report); manual business logic testing (mapping the application's state machine and testing workflow bypass, race conditions, and quantity manipulation — typically 10 to 20 hours per workflow category invisible in the resulting finding entries, since the finding entry only documents the vulnerability, not the application mapping work that identified it); Active Directory attack path analysis (running BloodHound, analyzing the attack path graph, researching each path step for exploitability, and documenting findings with reproduction steps — typically 8 to 16 hours invisible in the resulting attack path diagram and finding entries); and remediation validation (retesting each remediated finding from the prior month to verify effectiveness and absence of new vulnerabilities introduced by the fix — typically 4 to 10 hours invisible in the resulting retest status table).

What should a penetration testing retainer agreement include?

Penetration testing retainer agreements must include a signed scope definition and rules of engagement (ROE) document specifying: systems and applications explicitly in scope (IP ranges, URLs, API endpoints, Active Directory domains authorized for testing); systems explicitly out of scope; testing techniques authorized for each assessment cycle; testing windows during which disruptive techniques are authorized; the immediate escalation contact and procedure if a critical vulnerability or active breach is discovered during testing; and data handling requirements for testing artifacts, discovered credentials, and draft report findings. Monthly retainer amounts typically range from $5,000 to $30,000 depending on assessment scope and time commitment, and the ROE must be updated whenever the authorized scope changes.

What are typical retainer rates for penetration testers?

Independent penetration testers with 3 to 6 years of experience and OSCP or CEH certification typically bill at $125 to $225 per hour. Senior penetration testers with 6 to 12 years of experience and advanced certifications (OSED, OSEP, OSWE, or GREM) typically bill at $200 to $375 per hour. Penetration testers at boutique security consulting firms typically bill at $175 to $350 per hour. Monthly retainer amounts range from $5,000 to $15,000 per month for part-time engagements (20 to 60 hours per month), increasing to $10,000 to $30,000 per month for comprehensive assessment retainers covering web applications, internal network, Active Directory, and cloud infrastructure on a rolling quarterly cycle.

How should penetration tester retainer hours be logged?

Penetration tester retainer work log entries should capture: the assessment area (OSINT reconnaissance, web application testing, API security testing, network testing, Active Directory testing, cloud misconfiguration assessment, or remediation validation); the specific task performed; the tool or technique used; and the output or finding produced. A useful format is: [Assessment Area] + [Specific task] + [Tool/technique] + [Output or finding] + [Hours]. Example: “Web Application Testing — authentication and session management assessment on the admin portal. Techniques: JWT algorithm confusion attack (modified alg header from RS256 to HS256, signed with RSA public key from /api/.well-known/jwks.json — JWT accepted, CRITICAL vulnerability confirmed); IDOR testing on /api/v1/users/{userId} (modified userId to another user's ID — received full profile, HIGH severity); password reset token analysis (24-hour expiry with no rate limiting on guessing endpoint — MEDIUM severity). Output: 3 findings added to Jira security board with full reproduction steps and CVSS scores; CISO notified via encrypted email for CRITICAL finding immediately per ROE. 7 hours.” Entries that document the specific test cases, tools, techniques, and findings transform the testing hours from invisible background work into a documented assessment record that distinguishes manual security expertise from automated scanner output.

HourTab gives penetration testers and ethical hackers a public retainer dashboard URL their clients can bookmark — no client login, no portal, just a URL that shows hours used, hours remaining, and the work log connecting each hour to a specific assessment phase, vulnerability finding, or remediation advisory function. Learn more at hourtab.com.