1. Establish a baseline
Assess the agreed application boundary and record the coverage and limitations.
Penetration testing as a service (PTaaS) organizes security assessments around a recurring testing cadence. Balhence starts with a baseline assessment, then agrees change-based cycles for new features, roles, and integrations. Each cycle produces human-verified findings, an updated finding register, and re-tests within the agreed scope and schedule.
Our Release Assurance service follows the changes that matter after an initial assessment. We agree the timing, scope, access, reporting, and re-test allowance for each cycle. The finding register records the current status and the date each item was last checked.
PTaaS uses scheduled assessment windows. The agreement defines access, delivery dates, communication channels, and the work reserved for each cycle. Findings describe the version and scope tested during that window.
| Planning question | One-time pentest | PTaaS |
|---|---|---|
| Cadence | A defined assessment window | Baseline followed by agreed cycles |
| Best fit | A particular release, review, or audit | Products with frequent meaningful changes |
| Scope | Fixed boundary for the engagement | Priorities reviewed each cycle |
| Reporting | Report and agreed re-test record | Updated finding register and cycle summaries |
| Re-tests | A bounded window in the agreement | Agreed checks scheduled into the cadence |
Assess the agreed application boundary and record the coverage and limitations.
Prioritize new roles, workflows, APIs, and integrations, with regression checks for selected high-risk controls.
Keep evidence, remediation ownership, status, and the last verification date together.
Check agreed fixes and record unresolved or untested work for the next decision.
A person validates each reported issue and explains its impact. Automation can help with repeatable checks, while the assessment plan reserves attention for permissions and business rules. Changes outside a cycle remain untested until added to the written scope.
Choose the work from the next decision: understanding the application, reviewing a release, or checking fixes. Agree its boundary before reserving a testing window.
| Work type | Agreed coverage | Delivery record |
|---|---|---|
| Baseline assessment | The agreed application, roles, tenants, and integrations. Establishes the starting coverage. | Report with environment or release version, test dates, exclusions, and open findings. |
| Scoped change cycle | Selected new features, permissions, APIs, or integrations, plus named regression checks. | Cycle summary identifying changes tested, earlier coverage relied on, and areas left unassessed. |
| Re-test | Named fixes and related checks within the agreed allowance and window. | Finding status, evidence, verification date, tested version, and items not re-tested. |
Link each cycle to the relevant baseline and finding IDs. Preserve the earlier report when status changes so reviewers can follow the evidence over time.
Periodically compare accumulated coverage with the full system boundary. Schedule a broader assessment when a contract, review requirement, or material system change calls for it. Discuss the cadence in a PTaaS proposal.
If evidence supports an audit, coordinate reporting dates and scope with your SOC 2 testing plan.
No. Balhence provides scheduled testing and an agreed finding register. Access, delivery format, communication channels, and turnaround are set in the engagement agreement.
Yes. Start with a baseline, then decide whether a recurring cadence matches your release frequency and risk.
Not automatically. A limited change-based cycle may not cover the boundary required by an audit, contract, or regulation. Plan any required full-scope assessment separately within the schedule.
Tell us about the systems, roles, integrations, and deadline. We will confirm scope, availability, written authorization, and deliverables before testing.