The Security Test Process covers the activities, tasks and responsibilities of security testing as a process, and then how tests are designed for each test level. Its inputs are the available threat models, the security risk analysis and the security requirements; those same three things drive prioritization. The chapter also describes what makes a security test environment effective, and works down the levels: fuzz testing an interface at component level, risk-driven tests at component integration level, and an end-to-end test at acceptance level that validates security requirements through real business processes.
The mistake that costs marks is answering from generic test-process knowledge. Ordering security tests is not the same as ordering functional tests: priority follows the threat model and the risk analysis, and a test that cannot be run in a representative environment produces a misleading result rather than a weak one. Access rights, delegation and privilege structures have to resemble production, or an authorization test proves nothing.
Learn it as a chain: risk and threat inputs → abstract test ideas → concrete test cases → procedures → execution in a credible environment. Keep the level-specific examples attached to their level.
Threat model vs risk analysis — one describes how an attack could happen, the other weighs likelihood and impact; both are inputs, and they are not interchangeable.
Test case vs test procedure — the abstract idea, its concrete data, and the executable sequence are three separate artifacts in this chapter.
Representative environment vs identical environment — what must match is the security-relevant configuration, especially permissions and delegation.
Component-level vs system-level intent — fuzzing one interface answers a different question from an end-to-end business-process test.
Acceptance-level security testing validates requirements — it is not "one more round of penetration testing at the end".
Prioritization source — driven by test approach, risks and threat models, not by requirement numbering or code churn.
Authorization is required before you probe — security testing without explicit approval is not a bold test strategy, it is out of process.
This chapter is covered most heavily (5 questions) in CT-STE — Mock Exam 1 (Zero Trust, Access Control & Threat Modelling), CT-STE — Mock Exam 2 (Attacker Profiling, DevOps Pipelines & Standards as Oracles), CT-STE — Mock Exam 3 (Reconnaissance Analysis, Standards & Regression)