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
Working with Legal, HR, IT, Audit and the Business
Delivered through others
The security team can’t hire, fire, sign contracts, patch every server or run every project. Most security controls live inside other functions’ processes. The program works when security requirements are built into those processes, and fails when security tries to act as a gatekeeper standing outside them.
Two CISM tasks capture this: align the program with the operational objectives of other business functions, and integrate information security requirements into organisational processes.
Key partners
| Function | Process | Security requirement |
|---|---|---|
| HR | Hiring, moving, leaving, discipline | Background checks; access changes on role moves; prompt removal on leaving |
| Procurement | Buying products and services | Supplier security assessment; security clauses |
| Legal and privacy | Contracts, regulatory duties, investigations | Data protection terms; breach notification; evidence handling |
| IT and operations | Change, projects, operations | Security review of changes; patching; logging |
| Internal audit and risk | Assurance, enterprise risk | Independent testing; one view of risk |
| Facilities | Sites and physical access | Badge control, visitor management, CCTV |
| Business units | New products and processes | Risk assessment; owners’ decisions |
Making partnerships work
- Learn each function’s goals and pressures.
- Make the secure way the easy way inside their process.
- Agree responsibilities explicitly, in RACI charts or service agreements.
- Share metrics that matter to both sides.
- Escalate through governance, not through blame.
Example. Procurement complains that security reviews delay purchases by weeks. The security manager creates a short risk-tiering questionnaire: low-risk purchases pass in a day, and only high-risk suppliers get a full review. Delays fall and nothing important is skipped.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Best way to embed security in the organisation | Integrate requirements into business processes |
| Who should trigger removal of a leaver’s access? | HR, through a defined process |
| When should security be involved in procurement? | Before the contract is signed |
| How to gain cooperation from another function | Show how security supports their objectives |
| Security slows a business process | Redesign the control to fit the process, e.g. risk tiers |
In short
- The program succeeds by integrating security requirements into other functions' processes, not by doing everything itself.
- Key partners: IT, HR, legal and privacy, procurement, internal audit and risk, facilities, and business units.
- Each partner has its own goals; show how security helps them meet theirs.
- Integration points include hiring and leaving (HR), contracts (procurement and legal), change and projects (IT), and assurance (audit).
- Agree responsibilities explicitly, for example in RACI charts or service agreements.
- Aligning the program with the operational objectives of other business functions is a CISM task in its own right.
Exam traps
- Security as a separate gatekeeper at the end of processes creates delays and workarounds.
- HR owns the people processes; security defines the security requirements within them.
- Procurement must involve security before contracts are signed, not after.
- Internal audit is a partner, but must stay independent.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Key partners
1 / 8