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 Team Structure, Roles and Staffing
People are the hardest resource
Tools can be bought in weeks; experienced security people take months to hire and years to develop. “Information security program resources (e.g. people, tools, technologies)” is a named CISM topic, and the security manager plans the team as carefully as the budget, matching skills to the roadmap.
Security functions
| Function | Responsibilities |
|---|---|
| Governance, risk and compliance | Policy, risk assessments, audits, regulators, metrics |
| Security architecture | Designing secure systems; reviewing projects |
| Security operations | Monitoring, the SOC, incident response, threat intelligence |
| Identity and access management | Accounts, roles, privileged access |
| Application and cloud security | Secure development, cloud posture, DevSecOps |
| Awareness and culture | Training, phishing simulations, champions network |
Not every organisation needs all of these in-house. Smaller organisations combine roles, share them with IT or use services.
How to organise
- Centralised: one team sets and runs security. Consistent, but can feel remote from the business.
- Decentralised: each business unit has its own security staff. Close to the business, but inconsistent.
- Hybrid: central policy, architecture and oversight, with local champions and delivery. Most common; needs a clear RACI.
Filling skills gaps
Start with a skills assessment: what the roadmap needs compared with what the team has. Then choose:
| Option | Best for | Watch out for |
|---|---|---|
| Hire | Core, long-term capabilities | Time to hire; salary competition |
| Train and develop | Growing existing staff; retention | Time away from work; trained staff may leave |
| Contractors and consultants | Projects, peaks, specialist skills | Knowledge leaves with them |
| Managed services | 24x7 monitoring, scarce skills | Contract oversight; accountability stays in-house |
Even with outsourcing, keep enough in-house expertise to manage the supplier and challenge their work.
Keeping the team resilient
- Document procedures and decisions.
- Cross-train so every critical task has a backup person.
- Plan succession for key roles.
- Offer career paths and training to retain people.
- Separate incompatible duties within security: whoever administers access shouldn’t also approve or audit it.
Example. Only one engineer knows how the firewall rules and SIEM are configured. When she resigns, nobody can safely change either for a month. The security manager now requires runbooks and a named deputy for every critical system.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| First step in planning security staffing | Assess the skills the strategy needs against those available |
| Best way to reduce key-person risk | Cross-training, documentation and succession plans |
| Main benefit of a managed security service | Access to scarce skills and 24x7 coverage |
| Common team model | Hybrid: central standards with local delivery |
| A security administrator also approves access | A segregation-of-duties conflict |
In short
- Program resources include people, tools and technologies; people are usually the hardest to find and keep.
- Common security functions: governance, risk and compliance; architecture; operations and incident response; identity and access; application and cloud security; awareness.
- Team models are centralised, decentralised or hybrid; most organisations use a hybrid with central standards and local delivery.
- A skills assessment against the roadmap shows gaps, filled by hiring, training, contractors or managed services.
- Avoid key-person dependency with documentation, cross-training and succession plans.
- Segregation of duties applies inside security too: the people who administer access shouldn't also approve or audit it.
Exam traps
- Buying tools without the people to run them is a common failure.
- Outsourcing a function doesn't remove the need for in-house people who can manage the supplier.
- One person who knows everything is a single point of failure.
- Security administration combined with approving or auditing access is a segregation-of-duties conflict.
Slides
Click the slide and use the arrow keys. F toggles full screen.