Appearance
← CC syllabus chapters

Domain 5 · Objective reference 5.5 · Chapter 19 of 19

Security testing methods and authorized assessment

About 5 minutes · ISC2 CC outline effective 1 September 2026

Session only. Enable saving or download a backup from this course’s hub.

Completion is self-reported and does not certify understanding.

See it · Try it · Recall it

Picture the topic

Remember this: Choose a test to answer a security question.

CC · 5.5Branching concept mind map
Branching concept mind mapBranches identify related ideas. They show neither a ranking nor a chronological sequence. Static analysis: Inspect code without executing it. Dynamic testing: Observe a running application. Authorized assessment: Test only agreed scope and methodsConnectthe ideasStatic analysisADynamic testingBAuthorized assessmentC
Branches identify related ideas. They show neither a ranking nor a chronological sequence.
Visual preferences

Reduced-motion preferences are respected. Highlights guide attention; they do not represent measured traffic or elapsed time.

Explore the anchors

Inspect code without executing it.

Concept matching activity

Match this task or description to its concept:

Observe a running application.

Choose a concept before checking the explanation.

A quick way to study this topic
  1. Hide the explanation and redraw these three anchors from memory.
  2. Explain the difference between the anchors in your own words.
  3. Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
  4. Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.

Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.

What this chapter explains

Choose the method for the question

A vulnerability scan identifies potential weaknesses and needs validation; a version match is not always proof of exploitability. Static application analysis examines source or artifacts without executing the target application. Dynamic testing observes a running application. Threat modeling explores assets, trust boundaries and possible failures in a design. Code review can evaluate logic and context that an automated scan misses. These methods complement one another rather than establish one universal passing score.

A penetration test explores approved attack paths within a defined scope. A blue team focuses on defense, monitoring and response. A red-team exercise evaluates selected adversarial objectives under explicit rules, while purple-team collaboration helps defenders and testers improve detection and response together. A purple-team session is not simply a different name for scanning.

Set permission, safety and evidence boundaries

Define targets, accounts, times, permitted techniques, data handling, contacts and stop conditions. Reachability does not grant permission. Physical and human assessments can include authorized tailgating, impersonation or phishing scenarios, but must account for privacy, wellbeing, safety and third parties. Do not test production disruption under a contract that permits only non-disruptive scanning.

Use the least intrusive evidence that establishes the condition, preferably synthetic accounts and data. Report the observation, consequence, confidence, limitation and correction. Retesting checks that the underlying condition and relevant alternate paths were corrected. AI-generated findings and scanner labels remain hypotheses until supported by appropriate authorized evidence.

Compare the mechanisms
MethodExaminesImportant limit
Vulnerability scanPotential known weaknessesFindings need validation and deployment context
Static analysisCode or artifacts without target executionDoes not prove all runtime behavior
Dynamic testingRunning service behaviorLimited to exercised paths and conditions
Threat modelingDesign and plausible failure pathsA model is not implementation evidence
Red/blue/purple exercisesDefined adversarial/defensive capabilitiesScope, safety and objectives determine the claim

Worked example

Two staging accounts own different synthetic invoices. An approved tester checks that each can retrieve its own invoice and is denied access to the other. After a correction, the tester repeats both allowed and denied cases rather than merely checking the patch ticket.

Check your understanding

Which method would examine authorization source code without running the application, and what other evidence would strengthen the conclusion?

Show explanation

Static analysis or code review examines the implementation. Authorized dynamic tests with separate identities can then check whether the running service actually enforces the intended permissions.

Source and study boundary

Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.