An illustrative situation · 4 chapters
You ship every week. Your last pentest is getting old.
A report describes the product that was tested. Compare its scope with today's service before deciding whether to retest fixes, assess new features, or keep scanning known targets.
Chapter 01
Put the report beside the release history.
Since the last assessment, you've added an admin role and changed the customer export API. Read the report's scope against those releases. The date matters, but the more useful question is which current behavior the testers never saw. Keep the original report intact as a record of the work performed then.
01 / History · compare assessed behavior with today's product
Chapter 02
Separate old fixes from new questions.
A retest asks whether identified issues were addressed within an agreed scope. New features may need new assessment coverage. List those separately when you speak with Sythe Labs so a follow-up engagement isn't mistaken for a review of everything added since the original test.
02 / Gaps · remediation verification and new coverage are different work
Chapter 03
Use each testing method for a stated purpose.
Agree assessment work around the changed application. Sythe Labs also supports monthly scans of operator-approved targets with saved scan definitions; check each run's outcome. Those scans can support recurring checks, but the schedule doesn't mean every weekly release receives an application pentest. Your engineering checks still belong in the release process.
03 / Plan · scoped assessments and recurring scans with clear limits
Chapter 04
Review the plan when the service changes.
Name someone to compare significant releases with the assessed scope and buyer requirements. Keep records of the decision and the tests performed. If the service hasn't materially changed and no requirement calls for new work, a new report may not be the immediate priority. Neither an old nor a fresh report guarantees the current product is free of vulnerabilities.
04 / Review · a reasoned testing decision for the current service
What you leave with
A testing plan based on product changes and the gaps in your previous assessment.
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.