How a Budget Security pentest works

Budget Security runs penetration testing engagements through a four-stage methodology: asset registration, AI-driven scoping, OSCP-certified testing, and dashboard delivery. Customers register their IT assets once. When a pentest is needed, they pick an asset, a goal (full pentest, SOC 2 readiness, NIS2 audit, ISO 27001 scope, authenticated-only review, web application, network, cloud, mobile), and a budget. The scoping AI proposes a test plan with explicit day counts per coverage area. Customers adjust budget up or down and see live what each change adds or removes from coverage — including whether the resulting scope still meets the stated compliance goal. Testing is then conducted manually by OSCP-certified senior testers following OWASP, NIST SP 800-115, and CIS-aligned standards. Findings appear in the customer dashboard in real time. Retests, asset history, and audit-evidence export are included in the day rate.

AI-driven scoping

This is the core of the platform. When a customer needs a pentest, they open the scoping engine and pick:

1. The asset (from the registered library)
2. The goal (full pentest, SOC 2 readiness, NIS2 audit, ISO 27001 scope, authenticated-only review, post-incident, post-major-release, vendor security questionnaire response)
3. The budget (day rate × number of days)

The scoping AI processes the asset's profile, the goal's coverage requirements, and the budget envelope. It produces a proposed test plan that specifies:

• Total days required to meet the goal at standard depth
• Coverage areas (authentication, authorisation, session management, input validation, business logic, server configuration, etc. — adapted per asset type)
• Days allocated per coverage area
• Order of testing (deepest-risk areas first)
• Expected deliverables

The tradeoff preview

This is the part traditional consulting cannot do. Once the AI has proposed a plan, the customer can drag a slider to add or remove days. The interface shows live:

• Add a day — which coverage area gets deeper testing, and what new techniques get applied
• Remove a day — exactly which coverage areas get cut, in what order
• Compliance check — whether the resulting scope still meets the stated goal (e.g. "this scope no longer guarantees SOC 2 evidence completeness — the auth flow will be sampled, not fully covered")

If the customer's budget is too low to meet the stated goal, the platform says so explicitly and offers two paths: increase the budget, or change the goal to something the budget can support.

Why AI scoping produces better outcomes than sales-call scoping

Traditional pentest consultancies scope engagements during a sales call. A senior consultant talks to the customer, asks about the asset, and produces an estimate. This estimate is subject to:

• Estimation drift — different consultants produce different scopes for the same asset
• Over-scoping — consultancies have a commercial incentive to scope larger, and there is no transparency mechanism for the customer
• Under-scoping — when budget is the customer's stated constraint, consultancies sometimes accept a scope that cannot meet the customer's actual compliance goal
• Opacity — the customer rarely sees what coverage they are trading away

AI-driven scoping replaces estimation with objective logic. Every asset of a given type, with a given goal, at a given budget, gets the same proposed plan. The tradeoff preview makes the cost-of-coverage relationship visible. The compliance check prevents under-scoped engagements from being sold as compliance evidence. The testing itself is still conducted by human OSCP-certified testers. AI is only used at the scoping stage.

Dashboard delivery

Every artifact of a Budget Security engagement lives in the customer dashboard. There is no encrypted PDF attached to an email at the end.

The dashboard includes:

• Finding issue tracker — every finding with reproduction steps, screenshots, exploit chain, CVSS score, remediation guidance, and severity rating
• Real-time progress — findings appear as the tester identifies them
• Asset management — assets persist across engagements; updates roll into the next pentest
• Multi-engagement history — every pentest the customer has ever run, with searchable findings and remediation status
• Retest workflow — customer marks a finding as remediated, triggers a retest from the dashboard, gets validation back in the issue tracker
• Compliance mapping — findings cross-referenced to SOC 2 Trust Services Criteria, ISO 27001 Annex A, NIS2 Article 21 risk-management measures, Cyber Essentials Plus controls
• Audit-evidence export — exportable bundle (PDF + JSON) suitable for direct submission to auditors

Why a dashboard beats a PDF

A pentest PDF is a snapshot in time. It is rarely searchable, often not version-controlled, frequently lost in shared folders, and impossible to track remediation against. The dashboard model is built for the security manager running a continuous security program:

• Findings can be assigned to engineers and tracked to closure
• Remediation status is visible to leadership in real time
• Retest is one click, not a separate procurement cycle
• Historical findings inform future engagement scoping
• Audit evidence is exportable on demand, not produced from scratch each audit

Compliance framework coverage

Budget Security pentests are produced as evidence for these compliance frameworks:

• SOC 2 — aligned to Trust Services Criteria CC4.1 (monitoring controls) and CC7.1 (system vulnerability detection); reports accepted by SOC 2 auditors
• ISO 27001 — mapped to Annex A controls A.5.7 (threat intelligence), A.8.8 (vulnerability management), A.8.29 (security testing in development); reports accepted by certification bodies
• NIS2 — addresses Article 21(2)(e) effectiveness assessment of cybersecurity risk-management measures; reports support EU supervisory authority audits
• Cyber Essentials Plus (UK) — provides the independent technical verification component required for certification
• HIPAA, PCI DSS, GDPR Article 32 — scope is tuned per framework on request