An illustrative situation · 4 chapters
Penetration testing or vulnerability scanning: which do you need?
Use vulnerability scanning for repeatable checks for known weaknesses. Use a scoped penetration test to investigate attack paths and application behavior. You may need both; start with the question the results must answer.
Chapter 01
What do you need the assessment to tell you?
Your buyer asks for an independent application pentest. Engineering has a recent infrastructure scan. Before sending it, check the buyer's requirement: the scan may cover different targets and a different testing method. Write down the application, environment, and reason for testing. A report is useful only if its scope answers the question being asked.
01 / Requirement · the decision the assessment must support
Chapter 02
Vulnerability scanning checks a repeatable set of targets.
A scanner can flag known vulnerable software and supported configuration issues across the targets it reaches. Coverage depends on the scanner, credentials, and scan configuration. Inspect failures as well as findings: an unreachable host hasn't passed a check. In Sythe Labs, the scheduled scanning workflow records completed, failed, and quota-blocked work. That record tells you what ran, not that every possible weakness was tested.
02 / Scan · target coverage and findings that need review
Chapter 03
A penetration test investigates how the application can be misused.
For an application test, suppose a customer can export an invoice. Can another customer retrieve it by changing an identifier? A scoped manual assessment can investigate authorization across agreed accounts and roles. Network and infrastructure pentests investigate different attack paths, so match the engagement to your targets. Supply written authorization and agree safety limits. Request tested scope, exclusions, reproducible findings, and remediation guidance in the report; confirm whether retesting is included. Testers can use scanners too, alongside investigation and validation.
03 / Pentest · agreed attack paths and evidence of affected behavior
Chapter 04
Plan remediation before scheduling the next test.
Assign findings to someone who can change the affected system. Record what was fixed and where it was deployed, then agree how to verify it. Recurring scans help check for supported weaknesses between assessments; targeted retesting checks the fixes in scope. Changes to roles, payment flows, or exposed APIs may call for fresh testing. Neither a clean scan nor a pentest report guarantees that an application is secure.
04 / Follow-up · remediation ownership and a verification plan
What you leave with
A testing brief with approved targets, the right assessment, and an owner for follow-up.
Have a similar task on your team's list? Book a call to discuss how this workflow would fit your systems and who would need to be involved.