CISSP Testing Cheat Sheet: Software Testing, Security Testing & BC/DR Testing
Preparing for the CISSP exam can be challenging because the word "testing" appears across multiple domains.
The challenge is not simply memorizing definitions. CISSP questions often give you a scenario and ask you to identify the purpose of the test.
For example:
Smoke testing → Is the build basically working?
Regression testing → Did my change break something?
Mutation testing → Are my tests good enough to catch defects?
Vulnerability assessment → Where are the weaknesses?
Penetration testing → Can I exploit the weakness?
SAST → What's wrong in the source code?
DAST → What's wrong with the running application?
SCA → What's wrong with my dependencies?
Parallel DR testing → Can I activate DR while production continues?
Full interruption testing → Can I actually switch operations to DR?
This article brings the major CISSP testing concepts together into one revision-friendly cheat sheet, with simple explanations, examples, and memory tricks.
The current ISC2 CISSP outline places Security Assessment and Testing at 12%, and explicitly includes vulnerability assessment, penetration testing, code review/testing, misuse-case testing, coverage analysis, interface testing, breach attack simulations, and compliance checks. It also includes DRP testing under Security Operations and SAST, DAST, SCA, and IAST under Software Development Security. (ISC2)
1. Software Testing Types
Let's start with the fundamental software testing concepts.
| Testing Type | What Does It Mean? | Simple Example | 🧠 Memory Trick |
|---|---|---|---|
| Unit Testing | Tests a single function, module, or component in isolation. | Test a calculateTax() function independently. |
One unit → One test |
| Integration Testing | Tests whether multiple components work correctly together. | Test Login + Database + MFA service. | Do they work together? |
| System Testing | Tests the complete integrated system against requirements. | Test the entire banking application. | Test the whole system |
| Acceptance / UAT | Determines whether the system meets business/user requirements and is acceptable for use. | Business users verify that money transfers work correctly. | Does the customer accept it? |
| Functional Testing | Verifies that the system performs the functions defined in the requirements. | Verify that "Reset Password" actually resets the password. | What should it do? |
| Non-functional Testing | Tests characteristics such as performance, scalability, reliability, usability, and security. | Verify that the application supports 10,000 concurrent users. | How well does it work? |
| Smoke Testing | Quick, high-level testing to determine whether a build is stable enough for further testing. | Application starts, login works, and a basic transaction succeeds. | Is it alive? |
| Regression Testing | Ensures a change, patch, or fix has not broken existing functionality or introduced unintended problems. | An MFA patch fixes login but accidentally breaks password reset. | Did my change break something? |
| Nonregression Testing | Verifies that the intended change works and expected behavior has been achieved. | Verify that a newly implemented MFA requirement works correctly. | Did my change work? |
| Mutation Testing | Intentionally introduces small changes into code to determine whether existing tests detect them. | Change >= to > and see whether the test suite fails. |
Test the tests |
2. Regression Testing
This is an important CISSP concept.
If a question says:
Testing performed after a patch, modification, upgrade, or configuration change to determine whether the change introduced new problems.
Think:
Regression Testing
Imagine an application has:
Before Patch
Login ✓
Search ✓
Upload ✓
Download ✓
A security patch is installed:
After Patch
Login ✓
Search ✓
Upload ✗
Download ✓
The patch fixed one problem but unintentionally broke the Upload functionality.
That's exactly the type of problem regression testing is intended to uncover.
🧠 Memory Trick
Regression = Did my change break something?
3. Smoke Testing
Smoke testing is a quick, high-level test performed to determine whether a build is stable enough for more detailed testing.
For example:
Application starts ✓
Login works ✓
Main page loads ✓
Basic transaction works ✓
If these basic tests fail, there may be little value in immediately running thousands of detailed test cases.
🧠 Memory Trick
Smoke testing = Is the build alive?
Think of it as a quick health check.
4. Mutation Testing
Mutation testing is a particularly useful concept to understand because it doesn't primarily ask whether the application works.
Instead, it asks:
Are my tests good enough to detect defects?
The technique intentionally introduces small changes, called mutations, into the code and then runs the existing test suite.
Example
Original code:
if age >= 18:
allow_access()
A mutation changes it to:
if age > 18:
allow_access()
Now run the existing tests.
If the tests detect the change:
Mutation
↓
Test fails
↓
Mutant killed ✓
That's good. The test suite detected the injected defect.
If the tests still pass:
Mutation
↓
Tests pass
↓
Mutant survives ✗
That indicates a potential weakness in the test suite.
Important terminology
Mutant
The modified version of the program.
Killed mutant
A mutation detected by the test suite.
Surviving mutant
A mutation that was not detected by the test suite.
Mutation Score
A common metric is:
Mutation Score =
Killed Mutants / Total Detectable Mutants × 100
Example:
100 mutants
80 killed
Mutation Score = 80%
🧠 Memory Trick
Mutation Testing = Test the tests
5. Code Coverage vs. Mutation Testing
This is an excellent distinction to remember.
Code Coverage
Asks:
How much of my code did my tests execute?
Mutation Testing
Asks:
How effective are my tests at detecting defects?
Think:
CODE COVERAGE
↓
"Did my tests execute this code?"
MUTATION TESTING
↓
"Did my tests detect a defect
introduced into this code?"
A test suite can have high code coverage but still have weak assertions and fail to detect important defects.
🧠 Memory Trick
Coverage = How much did I test?
Mutation = How well did my tests test it?
6. Functional vs. Non-functional Testing
This distinction is useful beyond CISSP as well.
Functional Testing
Question:
What should the system do?
Example:
Requirement:
User must be able to reset their password.
Test:
Does password reset actually work?
Non-functional Testing
Question:
How well should the system perform?
Examples include:
Performance
Scalability
Reliability
Availability
Usability
Security
Example:
Requirement:
Application must support 10,000 concurrent users.
Test:
Can the application handle 10,000 concurrent users?
🧠 Memory Trick
Functional = What does it do?
Non-functional = How well does it do it?
7. Unit → Integration → System → Acceptance
A useful way to remember the progression is:
Unit
↓
Integration
↓
System
↓
Acceptance
Unit Testing
Test one component.
calculateTax()
Integration Testing
Test components working together.
Login
+
MFA
+
Database
System Testing
Test the complete application.
Complete Banking Application
Acceptance Testing / UAT
The business/user validates whether the system meets its requirements and is acceptable for use.
Business User
↓
"Does this system meet our requirements?"
🧠 Memory Trick
Unit → One thing
Integration → Things together
System → Everything
Acceptance → Business says acceptable
8. Security Assessment & Testing
Security assessment and testing is an important CISSP topic.
The key is understanding what the security activity is trying to accomplish.
| Security Testing Type | What Does It Mean? | Simple Example | 🧠 Memory Trick |
|---|---|---|---|
| Vulnerability Assessment | Identifies and evaluates vulnerabilities. | Scanner identifies an outdated OpenSSL version. | Find the weakness |
| Penetration Testing | Attempts to exploit vulnerabilities to demonstrate exploitability and impact. | Exploit SQL injection to demonstrate database access. | Prove the weakness |
| Red Team | Simulates realistic adversary behavior against an organization or environment. | Simulated attacker performs phishing → initial access → lateral movement. | Think like the attacker |
| Blue Team | Focuses on defensive detection, prevention, and response. | SOC detects and responds to a simulated attack. | Defend |
| Purple Team | Combines offensive and defensive activities to improve security controls. | Red Team attacks while Blue Team improves detection rules. | Red + Blue = Purple |
| Code Review | Examines source code for defects and security weaknesses. | Review code for hardcoded secrets or SQL injection. | Read the code |
| Misuse-Case Testing | Tests how the system behaves when someone uses it maliciously or improperly. | Attempt to access another user's account by manipulating an ID. | Normal use → Misuse |
| Coverage Analysis | Determines how much code, functionality, or requirements have actually been tested. | 85% of application code is covered by automated tests. | How much did we test? |
| Interface Testing | Tests interactions between systems, components, or interfaces. | Verify API Gateway correctly enforces authentication before calling a backend API. | Test the boundaries |
| Breach Attack Simulation (BAS) | Simulates attack techniques to evaluate whether security controls detect or prevent them. | Simulate credential theft and verify EDR detects it. | Simulate → Detect/Block |
| Compliance Testing | Verifies that systems or controls satisfy policies, standards, regulations, or requirements. | Check whether systems comply with the organization's password policy. | Are we meeting the requirement? |
These topics are explicitly represented in the current ISC2 Domain 6 outline. (ISC2)
9. Vulnerability Assessment vs. Penetration Testing
This is one of the most important distinctions to understand.
Vulnerability Assessment
The primary objective is:
Find and identify weaknesses.
Example:
Scanner
↓
Find vulnerable server
↓
Identify vulnerability
↓
Report
For example:
"This server is running a vulnerable version of OpenSSL."
The assessment has identified the weakness.
Penetration Testing
Penetration testing goes further:
Attempt to exploit the weakness and demonstrate impact.
Find vulnerability
↓
Attempt exploitation
↓
Demonstrate impact
↓
Report
Example:
"I exploited the SQL injection and demonstrated unauthorized database access."
🧠 Memory Trick
VA = Find it
Pentest = Prove it
10. Red Team, Blue Team and Purple Team
These three terms are easy to remember.
Red Team
The Red Team represents the offensive side.
They simulate an attacker.
Recon
↓
Initial Access
↓
Privilege Escalation
↓
Lateral Movement
↓
Objective
🧠 Memory Trick
Red = Attack
Blue Team
The Blue Team represents the defensive side.
They focus on:
Prevention
Detection
Monitoring
Investigation
Incident response
Containment
🧠 Memory Trick
Blue = Defend
Purple Team
Purple Team activities bring offensive and defensive teams together.
For example:
Red Team
↓
Performs attack
↓
Blue Team
↓
Detects attack
↓
Improve security controls
🧠 Memory Trick
Purple = Red + Blue collaboration
11. SAST, DAST, IAST and SCA
These are particularly important application security testing concepts. The current ISC2 outline explicitly lists SAST, DAST, SCA, and IAST under application security testing. (ISC2)
| Technology | Full Form | What Does It Test? | Example | 🧠 Memory Trick |
|---|---|---|---|---|
| SAST | Static Application Security Testing | Source code/binaries without executing the application. | Finds possible SQL injection in source code. | Static = Source |
| DAST | Dynamic Application Security Testing | Running application from the outside. | Sends malicious HTTP requests to a running application. | Dynamic = Deployed |
| IAST | Interactive Application Security Testing | Running application with instrumentation/agent. | Detects a vulnerable database query while the application executes. | Interactive = In the running app |
| SCA | Software Composition Analysis | Third-party/open-source dependencies. | Finds a vulnerable Log4j version. | Dependencies = SCA |
12. SAST
SAST analyzes application code without requiring the application to be running.
Source Code
↓
SAST
↓
Potential vulnerabilities
Example:
String query = "SELECT * FROM users WHERE id=" + userInput;
A SAST tool may identify a potential SQL injection issue.
🧠 Memory Trick
SAST → Static → Source
13. DAST
DAST tests a running application from the outside.
Running Application
↑
|
DAST
|
Malicious Requests
For example, a DAST scanner may send malicious input to web application parameters and analyze the response.
🧠 Memory Trick
DAST → Dynamic → Deployed application
14. IAST
IAST analyzes an application while it is running, typically using instrumentation or an agent.
Application Running
↓
Instrumentation
↓
Observe execution
↓
Identify security issues
🧠 Memory Trick
IAST → Interactive → In the running application
15. SCA
SCA focuses primarily on third-party and open-source components.
Imagine:
Banking Application
|
+-- My source code
+-- React
+-- Spring
+-- Log4j
+-- PostgreSQL driver
SCA can identify risks associated with those dependencies, including known vulnerabilities and licensing information.
🧠 Memory Trick
SCA → Software Components → Dependencies
16. Misuse-Case Testing
A use case describes legitimate behavior.
For example:
User
↓
Login
↓
Transfer Money
A misuse case asks:
What happens if someone intentionally tries to misuse the functionality?
Example:
Attacker
↓
Manipulate Account ID
↓
Access Another User's Account
The objective is to consider behavior from an attacker's perspective.
🧠 Memory Trick
Use case = What should happen?
Misuse case = What could an attacker try?
17. Coverage Analysis
Coverage analysis asks:
How much of the system have we actually tested?
For example:
Application
1000 lines of code
Tested:
850 lines
Coverage:
85%
Coverage can refer to:
Code coverage
Branch coverage
Requirement coverage
Functional coverage
Test-case coverage
Important Point
High coverage does not automatically mean high security or high quality.
It tells you how much of the relevant target was exercised by the tests.
🧠 Memory Trick
Coverage = How much did we test?
18. Interface Testing
Modern applications contain many interfaces:
Browser
↓
API Gateway
↓
REST API
↓
Microservice
↓
Database
Interface testing verifies that interactions between components work correctly.
Security-related checks may include:
Authentication
Authorization
Input validation
Error handling
Session management
API security
Data validation
🧠 Memory Trick
Interface Testing = Test the boundaries between components
19. Breach Attack Simulation (BAS)
Breach Attack Simulation, or BAS, simulates attack techniques in a controlled environment to evaluate security controls.
Example:
Simulated Credential Attack
↓
Security Controls
↓
+----+----+
| |
↓ ↓
Block? Detect?
The organization can determine whether its security controls actually behave as expected.
🧠 Memory Trick
BAS = Simulate the attack → Test the defenses
20. Compliance Testing
Compliance testing asks:
Are we meeting the required security requirements?
Suppose an organization has a policy:
Passwords must be at least 14 characters.
A compliance test can examine systems and accounts to determine whether that requirement is being followed.
Requirement
↓
Security Control
↓
Test
↓
Compliant / Non-Compliant
🧠 Memory Trick
Compliance = Are we following the requirement?
21. Business Continuity and Disaster Recovery Testing
Testing is not limited to applications and security controls.
CISSP also covers testing of Disaster Recovery Plans (DRP) and participation in Business Continuity (BC) planning and exercises. The current ISC2 outline specifically lists read-through/tabletop, walkthrough, simulation, parallel, and full interruption for DRP testing. (ISC2)
The important concepts to remember are:
Read-through
Walkthrough
Simulation
Parallel Test
Full Interruption Test
The wording of Read-through and Walkthrough is particularly important because they can sound very similar.
22. Read-through
A read-through asks each team member to review their role in the disaster recovery process and provide feedback.
The emphasis is on individual roles and responsibilities.
For example:
DR Team Member
↓
Reviews assigned role
↓
"Do I know what I am responsible for?"
↓
Provides feedback
A team member might identify:
"My contact information is outdated."
or:
"This recovery step requires access to a system I don't currently have access to."
🧠 Memory Trick
Read-through = Read YOUR role
Think:
"What is MY responsibility?"
23. Walkthrough
A walkthrough brings the team together for a formal review of the disaster recovery plan.
The focus is on reviewing the plan as a team and ensuring that the procedures, responsibilities, and recovery activities work together.
Example:
DR Team
↓
Gather together
↓
Review DR Plan
↓
Discuss procedures
↓
Identify gaps
↓
Provide feedback
🧠 Memory Trick
Walkthrough = Walk THROUGH the plan together
24. Read-through vs. Walkthrough
This is an excellent distinction to remember for CISSP.
| Read-through | Walkthrough | |
|---|---|---|
| Focus | Individual role/responsibility | Entire DR plan |
| Participants | Team members review their own roles | Team gathers together |
| Activity | Review role and provide feedback | Formal review of the plan |
| Question to remember | "What is MY role?" | "How does the PLAN work?" |
| Memory Trick | Read YOUR role | Walk THROUGH the plan |
🔥 CISSP Shortcut
If the question says:
"Each team member reviews their role in the disaster recovery process and provides feedback."
Think:
READ-THROUGH
If the question says:
"The team gathers together for a formal review of the disaster recovery plan."
Think:
WALKTHROUGH
25. Simulation
A simulation uses a practice disaster scenario to test the disaster recovery plan.
The goal is to practice how the organization would respond without necessarily causing an actual production outage.
Example:
The organization simulates a ransomware incident affecting the production environment and asks the recovery team to execute the DR procedures.
Practice Disaster Scenario
↓
Recovery Team
↓
Execute DR Procedures
↓
Identify Gaps
🧠 Memory Trick
Simulation = Practice the disaster
26. Parallel Test
This is one of the most important CISSP distinctions.
In a parallel test, the disaster recovery environment is activated, but operations do not switch to the DR environment.
Production continues operating.
PRIMARY
Production
|
| ← Operations continue
↓
Users
DR ENVIRONMENT
↑
|
Activated
and Tested
The DR environment is running alongside the primary environment.
🧠 Memory Trick
Parallel = DR runs beside production
Important
Parallel test does NOT mean that business operations are switched to DR.
The DR environment is activated and tested, but the primary environment remains responsible for normal operations.
27. Full Interruption Test
A full interruption test actually interrupts primary operations and switches operations to the alternate/DR environment.
PRIMARY
Production
X
|
↓
Operations
|
↓
DR SITE
|
↓
Business Runs
Example:
Shut down production and operate from the DR site.
This can be very disruptive to the business, because normal primary operations are actually interrupted.
🧠 Memory Trick
Full Interruption = Actually switch
28. Simulation vs. Parallel vs. Full Interruption
This is an important CISSP comparison.
| Simulation | Parallel | Full Interruption | |
|---|---|---|---|
| Purpose | Practice a disaster scenario | Test DR while production continues | Test actual operational switch |
| DR environment activated? | Not necessarily | Yes | Yes |
| Primary operations continue? | Yes | Yes | No |
| Operations move to DR? | No | No | Yes |
| Business disruption | Low | Low/controlled | Potentially high |
| Memory Trick | Practice | Run beside | Switch |
The Most Important Distinction
Parallel = Activate DR, but DON'T switch operations.
Full Interruption = Stop primary operations and switch to DR.
29. Complete BC/DR Testing Cheat Sheet
Now we can put all five methods together:
| BC/DR Test | What Happens? | Example | 🧠 Memory Trick |
|---|---|---|---|
| Read-through | Each team member reviews their role in the recovery process and provides feedback. | DBA reviews their database recovery responsibilities. | Read YOUR role |
| Walkthrough | The team gathers for a formal review of the disaster recovery plan. | Recovery team reviews the complete DR process together. | Walk THROUGH the plan |
| Simulation | A practice disaster scenario is used to test the DR plan. | Simulate ransomware and execute recovery procedures. | Practice the disaster |
| Parallel | DR environment is activated while primary operations continue. | Production remains active while DR is started and tested. | DR runs beside production |
| Full Interruption | Primary operations are interrupted and switched to the alternate environment. | Shut down production and operate from the DR site. | Actually switch |
30. BC/DR Testing Progression
A simple way to remember the progression:
READ-THROUGH
↓
"What is MY role?"
WALKTHROUGH
↓
"Let's review the PLAN together."
SIMULATION
↓
"Let's PRACTICE the disaster."
PARALLEL
↓
"Let's ACTIVATE DR,
but keep production running."
FULL INTERRUPTION
↓
"Let's STOP primary
and SWITCH to DR."
One-line memory trick
READ → MY ROLE
WALK → OUR PLAN
SIMULATE → PRACTICE
PARALLEL → ACTIVATE, DON'T SWITCH
FULL → SWITCH
31. Audit vs. Assessment vs. Testing
These terms can appear together in CISSP questions.
| Term | Main Question | Example |
|---|---|---|
| Audit | Are we complying with the required criteria? | Does the organization follow its security policy? |
| Assessment | How effective is the security/control environment? | Is the firewall appropriately configured? |
| Testing | Does the control actually work? | Send unauthorized traffic and verify that the firewall blocks it. |
Example: Firewall
Suppose the requirement is:
"The firewall must block unauthorized traffic."
Audit:
Is there a documented firewall policy?
Assessment:
Is the firewall properly designed and configured?
Testing:
Send unauthorized traffic and verify that it is blocked.
🧠 Memory Trick
Audit → Are we compliant?
Assessment → How effective is the control?
Testing → Does it actually work?
32. CISSP Testing — 30-Second Revision
If you have only a few seconds before the exam, remember this:
UNIT
→ One component
INTEGRATION
→ Components together
SYSTEM
→ Entire system
ACCEPTANCE
→ Business/user accepts it
FUNCTIONAL
→ What should it do?
NON-FUNCTIONAL
→ How well does it work?
SMOKE
→ Is the build alive?
REGRESSION
→ Did my change break something?
NONREGRESSION
→ Did my intended change work?
MUTATION
→ Are my tests good enough?
VA
→ Find vulnerabilities
PENTEST
→ Exploit/prove vulnerabilities
SAST
→ Source code
DAST
→ Running application
IAST
→ Running + instrumented application
SCA
→ Third-party dependencies
MISUSE CASE
→ Test malicious/unauthorized use
COVERAGE
→ How much did we test?
INTERFACE
→ Test component boundaries
BAS
→ Simulated attacks against controls
COMPLIANCE
→ Are we meeting requirements?
RED
→ Attack
BLUE
→ Defend
PURPLE
→ Red + Blue collaboration
READ-THROUGH
→ Review MY role
WALKTHROUGH
→ Review OUR plan
SIMULATION
→ Practice the disaster
PARALLEL
→ Activate DR, DON'T switch
FULL INTERRUPTION
→ Actually switch to DR
33. Final CISSP Testing Memory Map
When you see the word "testing" in a CISSP question, first identify what is being tested and why.
TESTING
|
+-------------------+-------------------+
| | |
↓ ↓ ↓
SOFTWARE SECURITY BC/DR
| | |
+----+----+ +----+-----+ +----+---------+
| | | | | | | | | |
Unit Integration VA Pentest BAS Read Walk Sim
System Acceptance Red/Blue Through Through ulation
Smoke Regression Purple
Mutation Parallel
Full
The Most Important CISSP Memory Lines
Smoke asks: "Is it alive?"
Regression asks: "Did my change break anything?"
Mutation asks: "Are my tests good enough?"
VA asks: "Where is the weakness?"
Pentest asks: "Can I exploit it?"
SAST asks: "What's wrong in the code?"
DAST asks: "What's wrong in the running application?"
SCA asks: "What's wrong in my dependencies?"
BAS asks: "Will my defenses detect or block an attack?"
Coverage asks: "How much did we test?"
Read-through asks: "What is MY role?"
Walkthrough asks: "How does OUR plan work?"
Simulation asks: "Can we practice the disaster?"
Parallel asks: "Can we activate DR while production continues?"
Full interruption asks: "Can we actually switch operations to DR?"
CISSP Exam Strategy
Don't memorize these terms as isolated definitions.
When you see a scenario, identify the intent of the activity.
Find a weakness?
↓
Vulnerability Assessment
Prove/exploit the weakness?
↓
Penetration Testing
Check source code?
↓
SAST
Check the running application?
↓
DAST
Check third-party dependencies?
↓
SCA
Check whether a patch broke existing functionality?
↓
Regression Testing
Check whether the basic build works?
↓
Smoke Testing
Intentionally introduce a defect
to see whether tests detect it?
↓
Mutation Testing
Measure how much was tested?
↓
Coverage Analysis
Simulate an attack against defenses?
↓
Breach Attack Simulation
Ask each team member to review their individual
DR role and provide feedback?
↓
Read-through
Bring the team together for a formal review
of the DR plan?
↓
Walkthrough
Practice a disaster scenario?
↓
Simulation
Activate DR but keep production running?
↓
Parallel Test
Actually interrupt primary operations
and switch to DR?
↓
Full Interruption Test
Conclusion
The key to answering CISSP testing questions is to focus on purpose rather than terminology alone.
A useful mental model is:
WHAT ARE YOU TRYING TO DO?
|
+-----------------+------------------+
| | |
↓ ↓ ↓
Test Software Test Security Test BC/DR
| | |
Regression Vulnerability Read-through
Smoke Assessment Walkthrough
Unit Pentest Simulation
Integration SAST Parallel
System DAST Full Interruption
Acceptance IAST
Mutation SCA
If you remember just these lines before the exam:
Smoke → Is it alive?
Regression → Did I break anything?
Mutation → Are my tests good enough?
VA → Find the weakness.
Pentest → Prove the weakness.
SAST → Source code.
DAST → Running application.
SCA → Dependencies.
Read-through → Review my role.
Walkthrough → Review our plan.
Simulation → Practice the disaster.
Parallel → Activate DR, don't switch.
Full interruption → Actually switch to DR.
These simple associations make scenario-based CISSP testing questions much easier to decode.