Your First Penetration Test: What to Expect and How to Prepare

Your first pen test is coming. Either an enterprise customer is requiring it, or you are about to attempt SOC 2 with a serious auditor, or your CISO advisor told you it is time. The test itself takes a week. Your preparation determines whether it produces a useful report or an embarrassing one.

What a pen test actually is (and is not)

A penetration test is a time-boxed adversarial assessment of your application and infrastructure by a qualified third party. Typically 5 to 10 business days of testing, against a defined scope, producing a written report of findings ranked by severity.

It is not a substitute for: a security program, continuous vulnerability scanning, secure SDLC practices, employee security training, or SOC 2. Pen tests find specific exploitable weaknesses. They do not certify that you are "secure."

The kinds of pen tests, and which you need

Web application pen test. Tests your customer-facing application for OWASP Top 10 vulnerabilities, business logic flaws, authentication and authorization issues. This is what most enterprise customers actually want when they ask "have you had a pen test?"

External infrastructure pen test. Tests your internet-facing infrastructure: public IPs, exposed services, misconfigurations. Smaller in scope than a web app test for most SaaS startups.

Internal pen test. Tests what an attacker could do once inside your network. More relevant for traditional enterprises than for cloud-native SaaS.

Red team engagement. Open-ended adversarial simulation, including social engineering, attempting to achieve specific objectives. Much more expensive, much longer, much more revealing. Inappropriate for a first engagement.

For your first pen test, focus on the web application test. Add external infrastructure if your scope warrants it. If a SOC 2 or an enterprise security review is what is driving the test, scope it so one engagement serves both, which is what compliance penetration testing is built for.

How to pick a vendor

The market splits into three tiers.

Boutique specialists ($15K-$40K per engagement). Small firms or solo consultants. Often more skilled than the big firms; the principal does the work. Best for first-time engagements where you want depth and good communication.

Mid-tier ($25K-$60K). Firms like NCC Group, Bishop Fox, Doyensec. Strong reputations, larger teams, more structured process. Good if you need a recognizable name on the report.

Large consulting firms ($60K+). Deloitte, EY, PwC. Expensive, variable quality, name-brand acceptance with the largest enterprise buyers. Often overkill for startups but sometimes required by a specific customer.

For most early-stage startups, a strong boutique is the right answer. Get three quotes. Ask each for sample reports (sanitized). Talk to past clients.

How to prepare

The four weeks before the test are when most value is created or lost.

Run your own scans first. ZAP, Burp Suite Community, Nuclei. Find and fix the easy stuff before the testers do. Their time is better spent on hard issues than re-reporting things a free scanner would have caught.

Provide good documentation. Architecture diagram, list of endpoints, authentication flows, user roles. Testers who do not have documentation spend half their time on discovery instead of on actual testing.

Provision test accounts at every role level. User, admin, super-admin, third-party API integration. Without these, the test can only cover unauthenticated paths.

Notify your team and your monitoring. Pen testing will trigger alerts. Make sure your team knows so they do not respond as if it is a real incident. Also tell your cloud provider (AWS, GCP) so they do not block the test traffic.

Define scope tightly. Specific environments, specific applications, specific accounts. Out-of-scope work is wasted hours.

What to expect from the report

A good report has:

• Executive summary suitable for showing customers.
• Detailed technical findings with reproduction steps, evidence, and severity.
• Recommended remediation for each finding.
• Methodology and scope documentation.

Findings are ranked: Critical, High, Medium, Low, Informational. A first pen test typically produces 0 to 2 Criticals, 3 to 8 Highs, 10 to 20 Mediums. If the report has zero findings, either the test was bad or your scope was wrong.

What to do after

Fix Critical and High findings immediately. Document Medium and Low findings, prioritize, and plan a fix. Some Informational findings will not be worth fixing; document the decision.

Retest the Critical and High findings. Either the same vendor (cheaper) or in-house verification. Get a "remediation verified" memo for your records and for customers.

Add the fixed issues to your secure coding standards and CI checks so they do not regress.

Plan the next pen test. Annual is the standard cadence. More often if you make major architecture changes or have a security incident.

The rules of engagement document, and why it saves you money

Before anyone touches your application there should be a signed rules of engagement document, and it should be boring. It names the testing window down to the hour, the source IP addresses the testers will work from, the environments and hostnames in scope, the accounts they have been issued, the actions they are forbidden from taking, and the phone number they call if they think they have caused an outage or found something that looks like an active compromise by someone else.

That last clause matters more than people expect. Testers occasionally find evidence that somebody got there first. Without a pre-agreed path, that discovery sits in a draft report for a week while the tester wonders who to tell. Write the escalation into the document: critical findings and any indication of prior compromise get reported inside four hours by phone, not at the end of the engagement.

The forbidden-actions list is where cost leaks. If you have not said that destructive testing, denial of service, and password spraying against real user accounts are out, you will spend part of your window arguing about it. If you have not said that production data cannot be exfiltrated to the tester environment, you have a privacy problem to explain to your own customers later. Ten minutes of drafting removes a day of friction.

Black box, grey box, white box

Vendors will offer you a choice and most first-time buyers pick wrong. A black box test gives the testers no credentials and no documentation, which sounds like the most honest simulation and is usually the worst value. You are paying a skilled person a day rate to spend the first two days rediscovering things you could have handed them in a spreadsheet.

Grey box is the default worth buying: credentials at every role level, an architecture diagram, an endpoint inventory, and no source code. It reflects the realistic threat of a hostile authenticated user, which for multi-tenant SaaS is the threat that actually costs you customers.

White box adds source code and, done properly, a walkthrough call with the engineer who wrote the authorization layer. It finds deeper logic flaws and it costs more per day because reading code is slow. It is the right choice on a second or third engagement, or on a first engagement where the application handles money, health records or credentials for other systems.

If a vendor tells you black box is more rigorous, they are describing a marketing position rather than a testing methodology. Attackers have unlimited time. Your tester has forty hours.

What drives the price

Quotes vary wildly for the same application because vendors are estimating days, and days come from a small number of countable things. The number of distinct user roles, because every role pair has to be tested against every other for horizontal and vertical access control. The number of API endpoints, particularly if the API is public and versioned. Whether there is a mobile client, which adds binary analysis and certificate handling. The number of external hosts and network ranges. Whether single sign-on, SAML or OIDC is in scope, since federation flaws are slow to test and expensive to find. Whether payment flows are involved.

Our own testing starts from $1,000 for a tightly scoped assessment, which is genuinely appropriate for a small external footprint or a single well-defined application, and rises with the countable items above. When you collect quotes, ask each vendor how many tester days they have priced and what they assumed about role count and endpoint count. Two quotes that differ by a factor of three usually differ because one vendor priced six days and the other priced eighteen, not because one is dishonest.

Timing the test against your audit

People book the pen test too late and then discover the report is the thing standing between them and a signed opinion. If a SOC 2 Type II observation window is running, the test needs to happen inside that window and the remediation needs to happen inside it too, because the auditor is sampling the period. A critical finding fixed three weeks after the window closes is a control that was not operating effectively for the period under review.

The workable pattern is to run the test in the first third of the window. That gives you time to remediate, retest, and produce a remediation memo that lands inside the same period. If you are running a readiness track like SOC 2 in 75 Days, book the test at kickoff rather than at the end, because the scheduling lead time at good boutiques is four to eight weeks and that alone can slip a report by a quarter.

What buyers actually ask for after the test

The report is not the deliverable your customers want. Almost no enterprise security team will accept a full technical report from a vendor, because handing over reproduction steps for your own vulnerabilities to a hundred customers is a bad idea and their own policy usually forbids receiving it.

What they ask for is a letter of attestation: one or two pages on the testing firm letterhead confirming that a test was performed, naming the methodology and the scope, giving the date range, stating the count of findings by severity, and confirming which severities have been remediated and verified. Ask for this in your statement of work before signing. Some vendors charge extra for it after the fact, and some produce a weak version that a picky buyer will reject because it omits the scope or the remediation status.

The other common request is the executive summary section under NDA. Decide in advance which you will share, keep both versions in your evidence store, and put a date-stamped copy in your Workspace so the sales team is not emailing the security lead every time a questionnaire arrives.

Findings you should expect to see, and what they mean

First tests against multi-tenant SaaS produce a recognizable set. Insecure direct object references on at least one endpoint that was added in a hurry and skipped the tenant check. A role that can call an administrative endpoint the interface never shows it. Mass assignment on a profile update route. JSON Web Tokens with an over-long expiry, or a refresh flow that does not invalidate the old token. Rate limiting on the login form but not on the password reset or the token endpoint. Verbose error messages that disclose stack traces and library versions. Missing or permissive cross-origin resource sharing configuration on the API. Server-side request forgery through a webhook or an image import feature.

Two of these deserve extra attention because they are the ones that turn into breach notifications rather than report entries. Broken object level authorization is the flaw that lets one customer read another customer's data, which in Canada triggers a real-risk-of-significant-harm assessment under PIPEDA and a notification decision you do not want to be making. Server-side request forgery in a cloud environment is the flaw that reaches the instance metadata service and turns into credentials. If your report contains either, treat the fix as an incident-grade priority rather than a sprint item.

When the test goes sideways

The WAF eats the engagement. Your web application firewall blocks the tester after ninety minutes and the remaining days produce nothing. Decide in advance: either allowlist the tester source IPs so they are testing the application, or leave the firewall on and accept that you are testing the firewall. Most buyers want the former, because the firewall is a control you can validate separately.

Staging is not production. Testing against a staging environment is fine and often safer, but only if the environment is a genuine mirror. If staging runs different authentication, older code, or a seeded database with no realistic tenant separation, the findings do not transfer and the auditor will notice the environment name in the report.

The environment falls over. Automated tooling occasionally knocks something down. This is why the test happens during a window your engineers are awake for, and why you do not schedule it against the week of a major release.

The report arrives thin. If the deliverable is a scanner export with a cover page, push back before you pay the final invoice. Ask for the manual testing evidence: the business logic paths tried, the role matrix tested, the requests captured. A real engagement leaves a trail beyond tool output.

Retesting, and the cost of proving the fix

The finding is not closed when the pull request merges. It is closed when somebody re-runs the original attack against the patched code and cannot reproduce it. Negotiate the retest into the original contract, because bought separately it is priced as a new small engagement and bought upfront it is usually a fixed number of days at the end of a remediation window.

Set the window realistically. Thirty days from report delivery is common and often too short for a team of six who also have a product roadmap. Forty-five to sixty days with a named owner per finding works better, and the retest should cover every Critical and High plus a sample of Mediums that touched the same code path.

Keep the remediation record itself: the finding identifier, the commit or ticket that fixed it, the date, the person who verified, and the retest confirmation. That record is what makes vulnerability management auditable rather than anecdotal, and it is the artifact that supports the control in your next audit cycle. Continuous handling of that loop is what our retainer work is for, though plenty of teams run it themselves once the register exists.

When you should not buy a pen test yet

If you already know your answer, spend the money on the answer instead. A team that has never run a dependency scan, has no multi-factor authentication on the cloud console, stores secrets in environment files committed to the repository, and has no logging worth the name does not need a stranger to tell them that for fifteen thousand dollars. Fix the known list first, then buy the test, and you will get a report about your business logic rather than a report about your hygiene.

If nobody is asking, and no framework requires it, and your application handles nothing sensitive, an annual test may be premature. Automated scanning in the build pipeline plus a serious code review habit will find more per dollar at that stage.

If you have no capacity to remediate, do not test. A report full of unfixed Highs sitting in a shared drive is worse than no report, because you now have documented knowledge of exploitable defects and no record of acting on it, which is exactly the position a plaintiff or a regulator finds interesting after an incident. Book the test when you have engineering time reserved on the other side of it.

And if what the customer actually asked for was a SOC 2 report, buy the readiness work and let the pen test be one input to it rather than a substitute. The two are frequently confused in procurement email, and confirming which one is written in the contract clause takes one question. Our offensive security work and our compliance work are separate motions on purpose, and we will tell you which one your deal actually needs before you commit to either.