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
Vendor Contracts, SLAs and Right to Audit
Write it in, before signing
Once a contract is signed, the organisation’s leverage drops sharply. Security requirements, audit rights and breach notification duties have to be agreed before signature, which is why security must be part of procurement from the start. Integrating information security requirements into contracts and activities of external parties is a CISM task.
Key security clauses
| Clause | Covers |
|---|---|
| Security requirements | Controls and standards to meet; certifications to maintain |
| Right to audit | Audits by the organisation, its auditors or regulators, or independent reports instead |
| Breach notification | Notify within a set time (e.g. 24–72 hours) and cooperate with the investigation |
| Data handling | Data location, permitted use, subcontractors, return and deletion |
| SLAs and penalties | Measurable service levels with consequences |
| Liability and exit | Insurance, indemnity, transition assistance, termination rights |
Security writes the requirements; legal makes them binding.
Measurable service levels
| SLA | Example target |
|---|---|
| Availability | 99.9% per month, measured by the customer’s own monitoring |
| Security incident notification | Within 24 hours of detection |
| Critical vulnerability remediation | Within 14 days |
| Access removal for the supplier’s leavers | Within 1 business day |
| Evidence | An annual SOC 2 Type II report |
An SLA that can’t be measured can’t be enforced. And penalties compensate for failures; they don’t remove the risk.
Right to audit, in practice
- Direct audit: the organisation or its auditors assess the supplier.
- Independent reports: large providers often offer SOC 2 reports and ISO 27001 certificates instead of individual audits.
- Regulator access: some sectors, such as financial services, require regulators to be able to audit suppliers.
- Fourth parties: requirements flow down to the supplier’s subcontractors.
Example. A bank’s contract with a payment processor includes a right to audit, 24-hour breach notification and approval of subcontractors. When the processor plans to move data to a new cloud region, the bank is told in advance and can assess the change.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most important clause for verifying a supplier’s controls | Right to audit |
| When to agree security requirements | Before the contract is signed |
| A large cloud provider won’t allow audits | Rely on independent reports, checked for scope |
| Key requirement of an SLA | It’s measurable and monitored |
| Clause that protects data at the end of the relationship | Exit: return or destruction of data |
In short
- Security requirements must be written into the contract before signing; they're hard to add later.
- Key clauses: security requirements and certifications, right to audit, breach notification, data handling and location, subcontractor approval, SLAs, liability and exit.
- A right-to-audit clause lets the organisation, its auditors and regulators verify controls; large providers may offer independent reports instead.
- SLAs must be measurable, monitored and backed by consequences; security-related SLAs include incident response and patch times.
- Exit clauses cover return or destruction of data, transition assistance and access removal.
- Monitoring external parties' adherence to these requirements is a CISM task; contracts are only as good as their enforcement.
Exam traps
- Without a right-to-audit clause, you only see what the supplier chooses to show.
- An SLA that can't be measured can't be enforced.
- Penalties compensate for failures; they don't fix the security risk.
- Missing exit terms leave data with the supplier after the relationship ends.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Key security clauses
1 / 8