Security Testing Guide

1. Purpose of This Guide

This guide helps you show that your software and systems have been tested for security weaknesses — before going live and on a regular basis.

Security testing (like vulnerability assessments or penetration testing) is how you prove:

• You actively look for weaknesses

• You don’t wait for attackers to find them first

• High-risk issues are identified and addressed

This artefact demonstrates that security testing is intentional, documented, and repeatable — not a one-off panic exercise.

2. What You Will Submit

You will submit evidence that security testing has been performed, such as:

• A Vulnerability Assessment (VA) report

• A Penetration Testing (PT) report

• A combined VA/PT report

• Executive summaries or extracts from testing reports

The report does not need to expose sensitive exploit details to be valid.

3. How to Collect / Obtain / Generate This Evidence

Option A: External Security Testing Provider (Most Common)

1. Engage a third-party security firm to conduct:

   • Vulnerability Assessment (VA), and/or

   • Penetration Testing (PT)

2. Ensure the report includes:

   • Scope of testing (application, environment, URLs, IPs)

   • Date of testing

   • Summary of findings and risk ratings

3. Export the final report (PDF preferred)

You may redact exploit steps or sensitive IP details.

Option B: Internal or Platform-Based Security Testing

If testing is done internally or via a platform:

1. Run the security scan or test

2. Export:

   • Test summary

   • Risk ratings (e.g. Low / Medium / High)

   • Evidence that testing completed successfully

3. Save as PDF or screenshot key summary pages

This is acceptable as long as testing is documented and recent.

Option C: Pre-Commissioning Testing Evidence

If your system was tested before going live:

1. Use the most recent pre-production or go-live security testing report

2. Ensure the report clearly shows:

   • Testing occurred before production use

   • Issues were identified and assessed

This is especially useful for newer systems.

4. Evidence Format

Accepted file types

• PDF

• DOCX

Suggested naming format
YourCompanyName_SecurityTesting_Date

Example
AcmePteLtd_SecurityTesting_2025-07-01.pdf

5. What “Good” Looks Like

Your evidence is strong if it shows:

• Visible element: Clear testing scope and date
  Why it matters: Confirms relevance and recency

• Visible element: Identified vulnerabilities with risk ratings
  Why it matters: Shows structured security assessment

• Visible element: Coverage of production or pre-production systems
  Why it matters: Confirms real-world relevance

• Visible element: Summary or conclusion section
  Why it matters: Helps auditors quickly understand outcomes

You do not need to show every exploit detail to pass.

6. Tips from Sir Stonk 🛡️

• Redact responsibly. Keep risk ratings and findings, remove step-by-step exploit instructions.

• Repeat testing after major changes — new features deserve fresh scrutiny.

Security testing isn’t about proving perfection.
It’s about proving you’re brave enough to look for cracks — and fix them.