1. Purpose

The Security Testing Checklist is used to verify that security controls, applications, infrastructure, cloud environments, APIs, and other project components have been appropriately tested before production deployment and during significant changes.

Security testing should provide evidence that:

• Security requirements have been implemented.
• Security controls operate as intended.
• Vulnerabilities have been identified.
• Security weaknesses are assessed and remediated.
• Significant findings are retested.
• Residual risks are understood and accepted where required.

The depth and type of testing should be based on the project’s risk, technology, data, exposure, and business requirements.

---

2. Testing Information

Field	Details
Project Name	[Project Name]
Project ID	[Project ID]
Application/System	[Name]
Version/Release	[Version]
Testing ID	ST-XXXX
Testing Scope	[Application / API / Cloud / Infrastructure]
Environment	[Test / Staging / Production]
Tester	[Name/Team]
Security Reviewer	[Name]
Testing Date	[Date]
Retest Date	[Date]
Status	[Open / In Progress / Complete]

---

3. Testing Scope

Clearly define what is being tested.

In Scope

• Application
• APIs
• Authentication
• Authorization
• Cloud infrastructure
• Network controls
• Databases
• Storage
• CI/CD pipeline
• Dependencies
• Containers
• Infrastructure-as-Code
• Security configurations
• Logging and monitoring

Out of Scope

Component	Reason
[Component]	[Reason]

Any important exclusion should be documented and approved where necessary.

---

4. Security Testing Strategy

Security testing should follow the project lifecycle:

Security Requirements → Design Review → Automated Testing → Manual Testing → Vulnerability Assessment → Penetration Testing → Remediation → Retesting → Security Approval

Not every project requires every testing technique.

The organization should determine applicability based on risk and project requirements.

---

5. Security Requirements Verification

Verify that identified security requirements can be tested.

Requirement ID	Security Requirement	Test Method	Expected Result	Result	Evidence
SR-001	Privileged users require MFA	Configuration/Test	MFA enforced	Pass	Screenshot/Config
SR-002	Customer data encrypted	Configuration review	Encryption enabled	Pass	AWS evidence
SR-003	Production access restricted	Access test	Unauthorized access denied	Pass	Test record

The objective is to establish:

Requirement → Test → Result → Evidence

---

6. Test Environment

Before testing:

• ☐ Test scope approved
• ☐ Test environment identified
• ☐ Test data prepared
• ☐ Sensitive production data protected
• ☐ Test accounts created
• ☐ Test credentials securely managed
• ☐ Test tools approved
• ☐ Testing permissions obtained
• ☐ Testing window agreed
• ☐ Production impact considered
• ☐ Backup/recovery considered
• ☐ Testing authorization documented

---

7. Security Testing Types

Determine which testing activities apply.

Testing Type	Applicable	Completed	Result
Security Requirements Testing	☐	☐
Security Configuration Review	☐	☐
SAST	☐	☐
DAST	☐	☐
SCA/Dependency Scanning	☐	☐
Secret Scanning	☐	☐
Infrastructure Scanning	☐	☐
Container Scanning	☐	☐
API Security Testing	☐	☐
Cloud Security Review	☐	☐
Vulnerability Assessment	☐	☐
Penetration Testing	☐	☐
Configuration Testing	☐	☐
Access Control Testing	☐	☐
Backup/Recovery Testing	☐	☐
Logging/Monitoring Testing	☐	☐

---

8. Authentication Testing

Verify that authentication mechanisms work as intended.

Checklist

• ☐ Valid credentials accepted
• ☐ Invalid credentials rejected
• ☐ Brute-force protection tested
• ☐ Rate limiting tested where applicable
• ☐ MFA tested
• ☐ MFA bypass scenarios tested
• ☐ Password reset tested
• ☐ Session timeout tested
• ☐ Session invalidation tested
• ☐ Logout tested
• ☐ Authentication tokens protected
• ☐ Expired tokens rejected
• ☐ Disabled accounts cannot authenticate
• ☐ Privileged authentication tested

---

9. Authorization Testing

Verify that users cannot access functions or data beyond their permissions.

Checklist

• ☐ Role-based access tested
• ☐ Least privilege tested
• ☐ Unauthorized functions rejected
• ☐ Unauthorized API endpoints rejected
• ☐ Object-level authorization tested
• ☐ Administrative functions restricted
• ☐ Privileged functions tested
• ☐ Horizontal access control tested
• ☐ Vertical access control tested
• ☐ Tenant isolation tested where applicable
• ☐ Direct URL/API access tested
• ☐ Access-control failures logged where appropriate

SaaS Example

A user from Customer A must not be able to retrieve Customer B’s data by changing an object ID in an API request.

---

10. Input Validation Testing

Test how the application handles unexpected or malicious input.

• ☐ Invalid input rejected
• ☐ Unexpected data types tested
• ☐ Boundary values tested
• ☐ Special characters tested
• ☐ Oversized input tested
• ☐ Malformed requests tested
• ☐ File upload validation tested
• ☐ URL/input validation tested
• ☐ API parameter validation tested

---

11. Application Security Testing

Test applicable application security controls.

• ☐ Authentication
• ☐ Authorization
• ☐ Session management
• ☐ Input validation
• ☐ Output encoding
• ☐ Error handling
• ☐ File handling
• ☐ Data access
• ☐ Security headers
• ☐ CSRF protections where applicable
• ☐ Security configuration
• ☐ Business logic
• ☐ Sensitive functionality

Testing should reflect the application’s actual architecture and technology.

---

12. API Security Testing

Checklist

• ☐ API authentication tested
• ☐ API authorization tested
• ☐ Invalid tokens rejected
• ☐ Expired tokens rejected
• ☐ Object-level authorization tested
• ☐ Input validation tested
• ☐ Rate limiting tested
• ☐ Request size limits tested
• ☐ Sensitive information exposure tested
• ☐ Error handling tested
• ☐ API version security reviewed
• ☐ API keys protected
• ☐ Third-party API security reviewed
• ☐ API logging tested

---

13. Web Application Security Testing

For web applications:

• ☐ Authentication testing
• ☐ Authorization testing
• ☐ Session testing
• ☐ Input validation
• ☐ Injection testing
• ☐ Cross-site scripting testing
• ☐ Access-control testing
• ☐ File upload testing
• ☐ Security headers reviewed
• ☐ TLS configuration reviewed
• ☐ Error handling reviewed
• ☐ Sensitive information exposure tested
• ☐ Business logic tested

Where appropriate, testing can be aligned with recognized application-security testing methodologies such as OWASP guidance.

---

14. SAST – Static Application Security Testing

Where applicable:

• ☐ SAST tool configured
• ☐ Source code scanned
• ☐ Scan completed
• ☐ Findings reviewed
• ☐ False positives assessed
• ☐ Critical findings addressed
• ☐ High-risk findings addressed
• ☐ Exceptions documented
• ☐ Retest completed
• ☐ Report retained

Evidence

• SAST report
• Scan date
• Repository/version
• Findings
• Remediation records
• Retest results

---

15. DAST – Dynamic Application Security Testing

Where applicable:

• ☐ Application scanned while running
• ☐ Authentication tested
• ☐ Authorization tested
• ☐ APIs tested
• ☐ Input handling tested
• ☐ Security headers reviewed
• ☐ Findings reviewed
• ☐ Critical/high findings addressed
• ☐ Retest completed
• ☐ Report retained

---

16. Dependency / SCA Testing

Software Composition Analysis should identify vulnerable third-party components.

• ☐ Dependency inventory available
• ☐ Dependencies scanned
• ☐ Direct dependencies reviewed
• ☐ Transitive dependencies reviewed
• ☐ Known vulnerabilities identified
• ☐ Critical/high vulnerabilities assessed
• ☐ Unsupported components identified
• ☐ Remediation completed where required
• ☐ Exceptions documented
• ☐ Scan evidence retained

---

17. Secret Scanning

Test source repositories and build environments for exposed secrets.

• ☐ Source code scanned
• ☐ Git history considered where appropriate
• ☐ API keys checked
• ☐ Passwords checked
• ☐ Private keys checked
• ☐ Cloud credentials checked
• ☐ CI/CD variables reviewed
• ☐ Findings removed
• ☐ Exposed credentials rotated
• ☐ Retest completed

---

18. Infrastructure Security Testing

Review infrastructure and operating-system security.

• ☐ Vulnerability scanning performed
• ☐ Unnecessary services identified
• ☐ Unnecessary ports reviewed
• ☐ Firewall rules tested
• ☐ Security groups tested
• ☐ Administrative access restricted
• ☐ OS hardening reviewed
• ☐ Patch status reviewed
• ☐ Secure protocols used
• ☐ Insecure protocols disabled where appropriate
• ☐ Configuration weaknesses addressed

---

19. Cloud Security Testing

For AWS/Azure/GCP environments:

AWS Example

• ☐ IAM permissions reviewed
• ☐ Privileged access tested
• ☐ MFA verified
• ☐ S3 access tested
• ☐ Public exposure reviewed
• ☐ Security Groups reviewed
• ☐ VPC configuration reviewed
• ☐ RDS access tested
• ☐ Encryption verified
• ☐ KMS configuration reviewed
• ☐ Secrets Manager configuration reviewed
• ☐ CloudTrail verified
• ☐ CloudWatch monitoring verified
• ☐ WAF configuration tested where applicable
• ☐ Backup configuration verified
• ☐ Cloud security findings reviewed

---

20. Container Security Testing

Where containers are used:

• ☐ Container images scanned
• ☐ Base image vulnerabilities assessed
• ☐ Packages reviewed
• ☐ Containers tested for unnecessary privileges
• ☐ Secrets exposure tested
• ☐ Registry access tested
• ☐ Image integrity considered
• ☐ Runtime configuration reviewed
• ☐ Kubernetes configuration tested where applicable

---

21. Infrastructure-as-Code Testing

For Terraform, CloudFormation, Kubernetes manifests, etc.:

• ☐ IaC scanned
• ☐ Security misconfigurations identified
• ☐ Public exposure checked
• ☐ Excessive permissions checked
• ☐ Encryption configuration checked
• ☐ Secrets checked
• ☐ Network rules checked
• ☐ Code review completed
• ☐ Findings remediated
• ☐ Approved version deployed

---

22. Vulnerability Assessment

Checklist

• ☐ Scope defined
• ☐ Assets identified
• ☐ Scan performed
• ☐ Findings validated
• ☐ False positives reviewed
• ☐ Risk assessed
• ☐ Critical vulnerabilities addressed
• ☐ High-risk vulnerabilities addressed
• ☐ Medium/low findings evaluated
• ☐ Exceptions documented
• ☐ Retesting completed where required

Vulnerability Record

ID	Asset	Vulnerability	Severity	Risk	Owner	Action	Status
V-001	Web Server	Outdated component	High	High	IT	Patch	Closed
V-002	API	Access control issue	Critical	Critical	Engineering	Fix	Closed

---

23. Penetration Testing

Where penetration testing is required:

Planning

• ☐ Scope defined
• ☐ Rules of engagement defined
• ☐ Testing authorization obtained
• ☐ Test environment identified
• ☐ Critical systems identified
• ☐ Testing window agreed

Testing

• ☐ External testing
• ☐ Internal testing where applicable
• ☐ Web application testing
• ☐ API testing
• ☐ Authentication testing
• ☐ Authorization testing
• ☐ Business logic testing
• ☐ Cloud exposure testing
• ☐ Configuration testing

Closure

• ☐ Report received
• ☐ Findings reviewed
• ☐ Critical/high findings addressed
• ☐ Risk acceptance documented where required
• ☐ Retesting completed
• ☐ Final report retained

---

24. Security Configuration Testing

Verify security configurations.

Examples:

• ☐ MFA
• ☐ Password configuration
• ☐ IAM
• ☐ Firewall
• ☐ Security Groups
• ☐ Encryption
• ☐ TLS
• ☐ Storage permissions
• ☐ Database permissions
• ☐ Logging
• ☐ Monitoring
• ☐ Backup
• ☐ Endpoint security
• ☐ Cloud configuration

---

25. Access Control Testing

Test the complete access lifecycle.

User Access

• ☐ New user provisioning tested
• ☐ Role assignment tested
• ☐ Access modification tested
• ☐ Access review tested
• ☐ Termination/deprovisioning tested
• ☐ Privileged access tested
• ☐ Temporary access tested
• ☐ Third-party access tested

Evidence

• Access request
• Approval
• Provisioning record
• Access review
• Removal record

---

26. Logging and Monitoring Testing

Confirm that important security events are recorded and detectable.

• ☐ Login events generated
• ☐ Failed login events generated
• ☐ Privileged actions logged
• ☐ Administrative changes logged
• ☐ Access-control failures logged
• ☐ Security events monitored
• ☐ Alerts generated where required
• ☐ Logs protected
• ☐ Log retention verified
• ☐ Alert escalation tested
• ☐ Monitoring ownership confirmed

---

27. Backup and Recovery Testing

Where applicable:

• ☐ Backup configuration verified
• ☐ Backup completion verified
• ☐ Backup access restricted
• ☐ Backup encryption verified
• ☐ Restoration tested
• ☐ Recovery procedure tested
• ☐ RTO considered
• ☐ RPO considered
• ☐ Recovery evidence retained

A backup should not be considered effective merely because a backup job shows “successful.” Restoration should be tested where appropriate.

---

28. Security Incident Testing

Test whether security events can be detected and handled.

Examples:

• Failed authentication attack
• Privileged access anomaly
• Malware detection
• Suspicious API activity
• Data access anomaly
• Cloud security alert

Verify:

• ☐ Event detected
• ☐ Alert generated
• ☐ Responsible person notified
• ☐ Incident record created
• ☐ Escalation performed
• ☐ Evidence preserved
• ☐ Response procedure followed
• ☐ Lessons learned captured where appropriate

---

29. Security Defect Management

All significant security findings should be tracked.

Finding ID	Test Source	Finding	Severity	Risk	Owner	Target Date	Status	Retest
ST-001	DAST	Authorization weakness	Critical	Critical	Engineering	[Date]	Fixed	Passed
ST-002	SCA	Vulnerable dependency	High	High	Engineering	[Date]	Fixed	Passed
ST-003	Cloud Review	Public storage	High	High	Cloud	[Date]	Open	Pending

Lifecycle

Identify → Validate → Assess → Assign → Remediate → Retest → Close

---

30. Test Results

Test ID	Test Case	Expected Result	Actual Result	Pass/Fail	Evidence
T-001	Invalid login	Access denied	Access denied	Pass	Screenshot
T-002	Unauthorized API access	Request denied	Request denied	Pass	API log
T-003	Privileged MFA	MFA required	MFA required	Pass	Configuration
T-004	Customer tenant isolation	Other tenant inaccessible	Inaccessible	Pass	Test record

---

31. Failed Tests

A failed security test should not simply be marked “Fail” and forgotten.

Test ID	Failure	Security Impact	Risk ID	Corrective Action	Owner	Due Date	Status
T-005	Unauthorized API access succeeded	High	PR-003	Fix authorization	Engineering	[Date]	Open

---

32. Retesting

After remediation:

• ☐ Original finding reviewed
• ☐ Corrective action implemented
• ☐ Same test repeated
• ☐ Result confirmed
• ☐ No regression identified
• ☐ Evidence retained
• ☐ Finding closed

Retest Record

Finding	Original Result	Remediation	Retest Result	Date	Tester
ST-001	Fail	Authorization fixed	Pass	[Date]	[Name]

---

33. Regression Security Testing

Security fixes should not introduce new problems.

Where appropriate:

• ☐ Authentication regression tested
• ☐ Authorization regression tested
• ☐ API regression tested
• ☐ Data protection regression tested
• ☐ Logging regression tested
• ☐ Security configuration regression tested
• ☐ Previously fixed vulnerabilities retested

---

34. Pre-Production Security Testing

Before production:

• ☐ Required security tests completed
• ☐ Critical findings closed
• ☐ High-risk findings addressed or accepted
• ☐ Vulnerability assessment completed
• ☐ Required penetration testing completed
• ☐ Security requirements verified
• ☐ Security architecture findings closed
• ☐ Residual risks reviewed
• ☐ Exceptions approved
• ☐ Security sign-off obtained

---

35. Production Validation

After deployment:

• ☐ Security configuration verified
• ☐ Authentication verified
• ☐ Authorization verified
• ☐ Logging verified
• ☐ Monitoring verified
• ☐ External exposure verified
• ☐ Encryption verified
• ☐ Backup verified
• ☐ Security alerts verified
• ☐ No unexpected security changes identified

---

36. Test Evidence

Retain appropriate evidence such as:

• Test plans
• Test cases
• Test results
• Screenshots
• Tool reports
• SAST reports
• DAST reports
• Dependency scan reports
• Vulnerability reports
• VAPT reports
• Penetration testing reports
• Cloud configuration evidence
• Access-control testing
• Security defect records
• Retest evidence
• Risk acceptance
• Security approval

Evidence should be sufficient to demonstrate what was tested, when it was tested, by whom, what the result was, and what happened to identified findings.

---

37. Security Testing Summary

Testing Area	Planned	Completed	Findings	Open Critical/High	Status
SAST	☐	☐	[#]	[#]
DAST	☐	☐	[#]	[#]
SCA	☐	☐	[#]	[#]
API Testing	☐	☐	[#]	[#]
Vulnerability Assessment	☐	☐	[#]	[#]
Penetration Testing	☐	☐	[#]	[#]
Cloud Security	☐	☐	[#]	[#]
Configuration Testing	☐	☐	[#]	[#]

---

38. Security Testing Sign-Off

Tester

Name: ______________________

Role: ______________________

Approval: ______________________

Date: ______________________

Security Reviewer

Name: ______________________

Role: ______________________

Approval: ______________________

Date: ______________________

Project/Technical Owner

Name: ______________________

Role: ______________________

Approval: ______________________

Date: ______________________

Risk Owner / Management

Name: ______________________

Role: ______________________

Approval: ______________________

Date: ______________________

---

39. Startup-Friendly Security Testing Approach

A startup does not need every possible security test for every release.

A practical approach is:

Small/Low-Risk Change

Code Review → Dependency Scan → Secret Scan → Automated Tests → Security Verification

New SaaS Application

Security Requirements → Architecture Review → Threat Assessment → SAST → SCA → DAST → API Testing → Vulnerability Assessment → VAPT/Penetration Testing Where Appropriate → Remediation → Retest → Approval

High-Risk Application

Add deeper testing based on:

• Sensitive information
• Internet exposure
• Critical business functions
• Customer requirements
• Regulatory requirements
• Complex APIs
• Third-party integrations
• Cloud infrastructure
• Threat environment

The objective is risk-based testing, not performing tests simply to generate reports.

---

40. Relationship With Other ISMS Documents

The Security Testing Checklist should connect with:

• Project Security Requirements Template
• Project Risk Assessment
• Security Architecture Review
• Secure Development Checklist
• Threat Model
• Vulnerability Management Procedure
• Threat Intelligence Procedure
• Incident Response Plan
• Change Management Procedure
• Access Control Policy
• Backup and Recovery Procedure
• Risk Register
• Statement of Applicability

The overall flow is:

Requirement → Risk → Architecture → Development → Test → Finding → Remediation → Retest → Evidence → Approval → Monitoring

---

41. Final Principle

Security testing should answer five questions:

What security requirement are we testing?

How did we test it?

What did we find?

What was done about the finding?

How did we verify the fix?

The practical lifecycle is:

Plan → Test → Identify → Assess → Remediate → Retest → Verify → Approve → Monitor → Improve