Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Security Testing: Scanning, Pen Testing and Tracking Remediation
Prove it, don’t assume it
Controls that look good on paper can fail in practice. Security testing gives evidence of how the organisation would fare against a real attacker, and it’s a key input to control testing and evaluation in Domain 3. The security manager plans a program of tests that matches the risk, gets them authorised, and makes sure findings are fixed.
Types of testing
| Test | What it does | Frequency |
|---|---|---|
| Vulnerability scanning | Automatically finds known weaknesses | Weekly to continuous |
| Configuration review | Compares settings with baselines | Continuous or periodic |
| Penetration test | Experts exploit weaknesses to show real impact | Yearly for critical systems and after major change |
| Red team | Simulates a real attacker over weeks; also tests detection and response | Periodically, for mature programs |
Scanning vs penetration testing
A scan finds known weaknesses; a penetration test proves which of them matter by chaining and exploiting them. A clean scan only means no known issues were found by that scan.
Authorisation and planning
- Written authorisation from the management that owns the systems. No signature, no test: unauthorised testing can be illegal and can disrupt operations.
- Scope: which systems are in and out, and permission from third parties such as cloud providers.
- Rules of engagement: timing, allowed techniques, stop conditions and emergency contacts.
- Risk-based frequency: critical applications tested yearly and after major change; scanning runs continuously.
Fixing what’s found
Testers report findings; they don’t fix them during the test. The organisation then:
- rates each finding by risk and assigns an owner
- agrees a plan (fix, compensate or accept) and a due date
- fixes it through change management
- verifies it by retesting
- reports overdue items and trends to management
Example. An annual pen test finds the same weak admin passwords three years running. The security manager stops treating findings as a report to file: each one now becomes a risk register item with an owner and a due date, and is retested within 30 days.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most important requirement before a pen test | Written management authorisation and an agreed scope |
| Test that also checks detection and response | A red team exercise |
| How to decide testing frequency | By risk, and after significant change |
| How to confirm a finding is fixed | Retest and verify |
| Main purpose of security testing | Evidence of control effectiveness |
In short
- A testing program combines vulnerability scanning (breadth), configuration review, penetration testing (depth) and red teaming (realism).
- Penetration testing exploits weaknesses to show real impact; red teaming also tests detection and response.
- Every test needs written authorisation from management with scope and rules of engagement.
- Testing is risk-based: higher-risk systems are tested more often and more deeply, and after major change.
- Findings are tracked like risks: owner, plan, due date, retest to verify.
- Test results feed control evaluation, metrics, the risk register and the roadmap.
Exam traps
- Testing without written authorisation can be illegal and disruptive.
- A clean scan doesn't mean the system is secure.
- Findings closed without retesting may not be fixed.
- Testers shouldn't fix what they find during the test; they report it.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Types of testing
Scanning vs penetration testing
Fixing what's found
ExampleAn annual pen test finds the same weak admin passwords three years running. The security manager stops treating findings as a report to file: each now becomes a risk register item with an owner and due date, retested within 30 days.
1 / 9