01 / Evidence
Inspect the finding, not just the score.
Review what was observed, which target was involved and what the evidence establishes. Ask whether a developer can reproduce the issue and understand its limits.
Explore findings and evidence
Compare approaches
Choose the test that answers your question.
Start with the decision you need to make. Scanning, AI-led investigation and scoped pentests can serve different needs.
Look at the work, not just the label.
| Consideration | Vulnerability scanning | Nebula investigation | Scoped pentest |
|---|---|---|---|
| Primary job | Repeat a configured set of checks for known weaknesses and exposed services. | Investigate an authorised target or question using context and available tools. | Have a testing team assess an agreed scope and explain the results. |
| A useful fit | Routine vulnerability management and a repeatable baseline. | Application questions, investigation between releases and follow-up after fixes. | A defined assessment, complex business context or a specific assurance requirement. |
| What you prepare | An asset list, scanning configuration and any supported credentials. | An objective, targets, exclusions, useful documents and working test access. | A scoping brief, test window, rules of engagement, access and contacts. |
| How work progresses | Scheduled or requested checks. Triage the results and tune the configuration. | Follow the engineer conversation, supply missing context and review requested decisions. | Agree the method and communication cadence with the delivery team. |
| Scope and limits | Coverage depends on the checks, configuration and accessible systems. | Coverage depends on the approved brief, available tools, access and tested conditions. | Coverage depends on the agreed systems, method, time and tester expertise. |
| Evidence to inspect | Check what each detection establishes and which results still need validation. | Review the finding narrative, proof, reproduction details and verification status where recorded. | Review the evidence, impact, limitations and remediation agreed in the deliverables. |
| Reporting | Exports, dashboards and reports depend on the selected product. | Edit the security report, choose evidence and review the saved PDF before sharing. | Agree the executive summary, technical report and walkthrough in the proposal. |
| Work after the result | Triage findings, assign remediation and rerun relevant checks. | Discuss findings, organise follow-up work and ask the engineer to retest the original condition. | Resolve findings with your team and arrange the agreed follow-up with the testers. |
| Retests and cost | Check how scans, targets, licenses and any assisted validation are charged. | Testing and retesting consume plan credits. Check current plans and the expected workload. | Retest scope, timing and price depend on the engagement proposal. |
| Human involvement | Someone still reviews detections, prioritises work and manages remediation. | Your team sets the brief, reviews evidence and makes decisions; human sign-off can be requested. | People lead the engagement. Their method and expertise are part of the selection decision. |
| Formal requirements | Check the exact contract or accreditation requirement before choosing a method. | ||
Match the approach to the decision.
These approaches can complement each other. The right mix depends on what your team needs to establish.
Maintain a known baseline
Use repeatable checks to keep track of known weaknesses. Plan who will review the alerts and investigate results that need more context.
Investigate a change or question
Give Nebula a specific objective, such as reviewing an access boundary after a release. Supply the relevant test accounts and inspect the evidence before acting.
Deliver a defined assessment
Use a scoped engagement when you need a testing team, a fixed delivery brief or a particular report. Confirm any named accreditation requirement with the party requesting it.
Ask to see the work before you decide.
A useful evaluation should leave your security, engineering and business teams with answers they can inspect.
02 / Reporting
Read the deliverable before you commit.
Ask for the report format and the detail your audience needs. In Nebula, review the saved report, select the evidence and inspect the PDF before sharing it.
For a scoped pentest, agree the executive summary, technical detail and walkthrough in the proposal.
Illustrative report outline
Application security review
- Summary
What was tested and what needs attention.
- Scope and method
The targets, access and tested conditions.
- Findings and evidence
Impact, reproduction and remediation.
03 / Follow-up
Make room for the work after the test.
Turn the result into a clear next step. Organise follow-up work, identify the condition to retest and review the new evidence after a fix.
Testing and retesting use plan credits. Confirm the workload and follow-up terms as part of the evaluation.
See the follow-up workflow
Make the evaluation concrete.
Agree the brief
Write down the systems, accounts, exclusions and question. Set a realistic time window and identify who can answer context questions.
Inspect the result together
Review what was tested, what could not be reached and what each finding proves. Include the people who will make the fixes.
Check the next step
Confirm how remediation, retesting and reporting work. Compare the complete workflow, including your team's effort, rather than a headline price.
Go deeper into the differences.
Bring the requirement to the conversation.
We can explain where Nebula fits and when a separately scoped engagement is appropriate.