Pentest client onboarding
from first call to first finding
Stand up a new pentest client without losing a week to email threads, separate intake forms, and credential rummaging. Capture intake, scope, rules of engagement, contacts, credentials, and portal access on the same record the engagement runs on. The client is operational before the test starts, not the day after it ends.
No credit card required. Free plan available forever.
Pentest client onboarding without the email archaeology
The first week of a pentest engagement is usually the most chaotic. Intake is split across an email questionnaire, a scoping spreadsheet, a kickoff call agenda, and a credentials chat message that nobody can find on day three. The client answers the same question three times, the asset inventory shows up after the test plan is already drafted, the rules of engagement sit unsigned in someone's inbox, and the portal invite goes out the day the report is delivered. By the time the first finding lands, the team has already lost time that should have gone into testing.
SecPortal models pentest client onboarding as a structured workflow on the client and engagement records. The client record carries billing, contacts, asset inventory, technology stack, and prior testing history. The first engagement is built directly on the client record with scope, methodology, target list, timeline, and the assigned team. Rules of engagement, encrypted credentials, and branded portal access live alongside the engagement. The result is a client who is operational before testing starts and a team that opens the first finding on day one rather than day five.
Six pillars of a clean pentest client onboarding
Client record as the system of record
Open the client once and use the same record for billing, contacts, asset inventory, prior engagements, and ongoing work. Onboarding stops being a sequence of disconnected forms and starts being a single record the team and the client both edit.
Intake aligned to scoping
Capture the asset inventory, in-scope environments, exclusions, technology stack, and prior testing history at intake so the scoping conversation works from real data. The same fields that drive a defensible scope drive the engagement plan.
Engagement built from the client record
Create the first engagement against the client record so the scope, target list, methodology, and timeline live where the work happens. The engagement is not a separate Word document that ages out of date the day after kickoff.
Rules of engagement as a signed artefact
Store the signed rules of engagement against the engagement so authorisation, testing window, allowed techniques, communications SLA, and stop-test conditions sit on the same record the team works against.
Encrypted credential capture
Store cookie, bearer, basic, and form-login credentials encrypted at rest with AES-256-GCM. The credentials needed for authenticated DAST are part of the engagement record, not buried in a tester password manager that the next person on the project cannot read.
Branded portal handover
Invite the client contacts to a branded portal on your custom subdomain. They get a professional view of their engagement, findings, reports, and invoices from day one rather than waiting until report week to see anything.
Where pentest client onboarding usually breaks
The same five failure modes show up across most pentest practices that have not yet put onboarding on a single record. Each one is a structural problem with a structural fix.
Intake lives in three forms and a Slack thread
When intake is split across an email questionnaire, a separate scoping spreadsheet, and a kickoff call agenda, fields get duplicated, fields get missed, and the client answers the same question three times. Capturing intake on the client record itself means every fact has one home and one owner.
Scoping happens before the asset inventory exists
Scoping calls without an asset inventory turn into negotiation by guesswork. Capturing in-scope environments, technology stack, and exclusions at intake means the scoping conversation starts from a defensible position rather than ending in a verbal commitment that drifts.
Rules of engagement sit in someone's inbox
A signed ROE that lives in email is invisible to the tester three weeks into the engagement. Storing the ROE against the engagement means the team can answer authorisation questions, communications questions, and stop-test questions from the same record the work is logged against.
Credentials arrive on the morning of kickoff
Authenticated testing depends on credentials that often appear hours before the test starts and live in a chat message that is hard to find a week later. Capturing credentials during onboarding, encrypted at rest, means the authenticated scan is not blocked by a missing password and the next tester on the project does not have to chase the original handover.
Portal access is set up after the report is delivered
Provisioning the client portal at the end of the engagement misses the entire point of having one. Inviting client contacts during onboarding lets them see status, ask questions, and review findings as the work happens, which usually halves the email volume on the project.
A pentest client onboarding checklist that survives contact with reality
Use the ten items below as a working onboarding checklist. Every item maps to a record SecPortal stores so the checklist is not a separate document the team forgets after the third client.
- Open the client record with billing entity, primary contact, and time zone so invoicing and scheduling work from the same data
- Capture the asset inventory, in-scope environments, and out-of-scope items so the scoping conversation starts from facts rather than guesswork
- Record the technology stack, frameworks, and prior testing history so testers know what to expect on day one
- Identify the compliance drivers behind the engagement (ISO 27001, SOC 2, PCI DSS, Cyber Essentials) so the report shape is agreed before testing starts
- Build the first engagement on the client record with scope, methodology, target list, timeline, and assigned team
- Run the scoping calculator to convert in-scope assets into a defensible tester-day range and retest budget
- Sign the rules of engagement covering authorisation, testing window, allowed techniques, communications SLA, evidence handling, and stop-test conditions
- Capture authentication credentials in encrypted storage so authenticated DAST is not blocked when testing starts
- Provision portal access for client contacts so they have a branded view of the engagement before kickoff
- Schedule the kickoff against the engagement record so the agenda is the engagement and the engagement is the agenda
One onboarding workflow, five different views
Pentest onboarding is multi-stakeholder by default. The client primary contact, the client security lead, the engagement lead, the tester, and the practice manager each need a different view of the same intake. SecPortal serves all five from the same client and engagement records so the data stays consistent and the views stay role-appropriate.
| Role | What they see |
|---|---|
| Client primary contact | Receives a branded portal invite, sees their own engagements with scope, agreed dates, contacts, and deliverables, and starts the project with one place to ask questions, view status, and download artefacts. |
| Client security lead | Approves the in-scope asset inventory, signs the rules of engagement, and supplies the authenticated testing credentials. Sees who on the testing team is assigned, what the methodology looks like, and what the deliverables include. |
| Engagement lead | Owns the client record from intake through kickoff. Builds the engagement, runs the scoping calculator, drafts the ROE, captures credentials, assigns the team, and schedules the kickoff against the same record the work runs on. |
| Tester | Sees the engagement assigned to them on day one with scope, ROE, credentials, target list, methodology, and contacts already in place. Logs the first finding without asking the engagement lead for the missing context. |
| Practice manager | Sees new clients land, intake completion status, ROE signoff status, kickoff scheduling, and the time-to-first-finding metric across the portfolio. Onboarding stops being invisible work that quietly slows delivery. |
Built for pentest firms, MSSPs, and independent consultants
The shape of the onboarding problem changes with the size of the practice, but the underlying workflow is the same. The platform is built to serve all three of the common shapes from the same workspace.
Pentest firms
Multi-tester practice landing several clients per quarter. Standardise the intake, scope, and ROE across every new client so junior leads can run onboarding without tribal knowledge and the practice manager has a portfolio view of pipeline conversion.
MSSPs
Service delivery onboarding at scale across many clients with recurring engagement schedules. Reuse intake templates, ROE clauses, and portal provisioning patterns so the tenth client onboards in the same shape as the first.
Independent consultants
Solo or small team practice that needs to look enterprise-grade from the first client call. Run onboarding through the branded portal so the new client sees a professional front door before the first finding lands.
How onboarding connects to the rest of the engagement
Onboarding is not a separate module bolted onto the platform. It sits on top of engagement management for the engagement record, uses team management for assignment and role control, ships through the client portal for the client view, captures credentials through authenticated scanning for testing behind the login screen with credential handover as the lifecycle workflow, and feeds findings management once testing starts. When a new client arrives with a backlog of prior pentest reports or vendor findings, bulk finding import consolidates the catalogue onto a baseline engagement record before kickoff. After kickoff, the engagement flows into the pentest project management workflow so the same record covers delivery, retest, and closure. For the structured retest deliverable view, the pentest retesting use case covers retest scope, pricing, and verification status.
Scope and ROE primitives
Pair the workflow with the pentest scoping calculator, the rules of engagement template, the scope of work template, and the kickoff meeting agenda so onboarding produces a defensible scope, a signed ROE, and a kickoff that actually starts on day one rather than a verbal agreement.
Methodology and pricing context
Anchor the conversation with the Penetration Testing Execution Standard for methodology and the research on pentest pricing models and pentest scope creep so the kickoff is grounded in real numbers rather than optimistic memory.
Pentest client onboarding is one of those workflows that looks small from the outside and turns into the single biggest source of operating leverage once it is in place. The first finding lands faster, the client stops asking the same intake question three times, and the team stops paying the recurring tax of reconstructing context every Monday. Treating onboarding as a structured workflow, not as a kickoff call agenda, is what makes that difference real.
Frequently asked questions about pentest client onboarding
What is pentest client onboarding?
Pentest client onboarding is the structured workflow that turns a new client conversation into a live engagement: intake, asset inventory, scoping, rules of engagement signoff, credential capture, team assignment, and portal handover. Done well, the client is operational before testing starts. Done badly, the engagement loses the first week to chasing missing context. SecPortal models this as a single workflow on the client and engagement records so the operational artefacts the team needs all live in one place.
How is this different from generic CRM onboarding?
Generic CRM onboarding has no native concept of an asset inventory, a rules of engagement document, an authenticated testing credential, or a finding. SecPortal models those entities directly. The client record carries asset inventory, primary contacts, billing entity, and prior testing history. The engagement carries scope, ROE, methodology, target list, and the team. Encrypted credential storage carries authentication material for authenticated DAST. A pentest team that runs onboarding in a generic CRM ends up rebuilding these fields by hand and still has nowhere to deliver the report.
What should a pentest client onboarding checklist include?
At minimum, the checklist should cover the client record (billing, contacts, time zone), the asset inventory and exclusions, the technology stack and prior testing history, the compliance drivers behind the engagement, the engagement record (scope, methodology, target list, timeline, team), a defensible scoping estimate from the scoping calculator, a signed rules of engagement document covering authorisation and stop-test conditions, encrypted credentials for authenticated testing, branded portal access for client contacts, and a scheduled kickoff against the engagement. The full checklist is in the section above and ships ten items deep.
When should the rules of engagement be signed?
Before any active testing starts. The ROE is the legal authorisation for the work. SecPortal stores the signed ROE on the engagement record so the tester, the engagement lead, the client security lead, and the practice manager all see the same document, the same testing window, and the same stop-test conditions. The platform pairs cleanly with the rules of engagement template so the team is not drafting the document from scratch every time a new client lands.
How are authentication credentials handled during onboarding?
Authentication credentials for authenticated DAST are captured during onboarding and stored encrypted at rest with AES-256-GCM. The platform supports cookie, bearer, basic, and form-login credential modes so most authenticated testing setups are covered without bespoke scripting. Capturing credentials during onboarding rather than the morning of the kickoff means the first authenticated scan is not blocked by a missing password and the engagement does not lose the first day to credential rummaging.
When should the client portal be provisioned?
During onboarding, before kickoff. Inviting client contacts to the branded portal at the start of the engagement gives them a single place to see scope, agreed dates, contacts, and deliverables. As findings start landing, they appear in the same portal the client already has access to. Provisioning the portal at the end of the engagement, which is what most ad-hoc workflows end up doing, misses the entire point of having one.
How it works in SecPortal
A streamlined workflow from start to finish.
Capture intake before scoping
Open the client record, add billing details and primary contacts, and capture the basics that drive scope: asset inventory, in-scope environments, exclusions, prior testing history, and the compliance frameworks the engagement needs to support.
Scope the first engagement
Build the engagement against the client record using the pentest scoping calculator for tester-day estimates and the scope of work template for the deliverables checklist. Targets, methodology, and timeline live on the engagement, not in a separate Word document.
Sign rules of engagement
Use the rules of engagement template to capture authorisation, testing window, allowed and prohibited techniques, communications SLA, evidence handling, and stop-test conditions. Store the signed ROE with the engagement so the legal artefact and the operational record never drift apart.
Capture credentials and provision portal access
Store authentication credentials with AES-256-GCM encryption so authenticated DAST runs against pages behind the login screen. Invite the client contacts to the branded portal subdomain so they have a professional view of the engagement before kickoff.
Run the kickoff and start logging findings
The kickoff call is grounded in a single source of truth: the engagement record holds scope, ROE, credentials, contacts, and portal access. Testers log findings against the engagement from day one. The client sees status in their portal instead of asking for an update by email.
Onboard the next client without the email archaeology
Intake, scoping, ROE, credentials, and portal access on one engagement record. Start free.
No credit card required. Free plan available forever.