Topics in this domain
- Exam Technique: Thinking Like a Security Manager
- Security Governance vs Security Management
- Organisational Culture and Tone at the Top
- Ethics, Codes of Conduct and Accountability
- Integrating Security into Corporate Governance
- Legal, Regulatory and Contractual Requirements
- Due Diligence, Due Care and Legal Liability
- Privacy and Data Protection Governance
- Governance Roles, the CISO and Reporting Lines
- The Security Steering Committee
- The Three Lines Model and Independent Assurance
- Aligning Security Strategy with Business Objectives
- Developing a Security Strategy and Roadmap
- Gaining and Keeping Executive Commitment
- Governing AI and Emerging Technology
- Security Frameworks Compared: NIST CSF, ISO 27001 and COBIT
- Selecting and Implementing a Framework
- Governance Models: BMIS and the Security Balanced Scorecard
- Resource Planning and Security Budgets
- Building a Business Case for Security Investment
- Demonstrating Value and Return on Security Investment
Legal, Regulatory and Contractual Requirements
Where obligations come from
An organisation’s security obligations come from many directions:
- Laws: privacy and data protection, breach notification, computer misuse, electronic records.
- Sector regulation: rules for banks, healthcare, energy, telecoms and other critical sectors.
- Contracts: security clauses in customer and supplier agreements, card-brand rules (PCI DSS), SLAs.
- Listing and disclosure rules: for example, SOX controls over financial reporting and SEC rules requiring US-listed companies to disclose material cyber incidents.
- Certifications and attestations the organisation has committed to customers, such as ISO 27001 or SOC 2.
- Internal policy: the organisation’s own rules.
Examples you should recognise
| Requirement | Type | Security impact |
|---|---|---|
| GDPR and other privacy laws | Law | Lawful processing, security of personal data, breach notice to the authority within 72 hours, data subject rights |
| NIS2 (EU) | Regulation | Risk management measures and incident reporting for essential and important entities; management accountability |
| DORA (EU financial sector) | Regulation | ICT risk management, incident reporting, resilience testing, oversight of ICT third parties |
| HIPAA (US) | Law | Safeguards for protected health information |
| SOX (US listed companies) | Law | Internal control over financial reporting, including IT general controls |
| PCI DSS | Contract | Protecting cardholder data, required by agreements with card brands and banks |
You don’t need the detail of every law for CISM. You do need to know how the security manager handles them.
The compliance process
- Identify which laws, regulations and contracts apply, in which locations and to which data.
- Interpret them with legal counsel. The security manager isn’t the organisation’s lawyer.
- Map each requirement to controls, identify gaps and assign owners.
- Implement missing controls and keep evidence that controls operate.
- Monitor compliance and watch for new or changing requirements.
A compliance obligations register (requirement, source, owner, controls, evidence, status) keeps this manageable.
Jurisdiction and data location
One organisation can be subject to several legal systems at once: where it’s incorporated, where it trades, where its data is stored and processed, and where its customers live.
Example. A US company stores EU customers’ data in a cloud region in Singapore. GDPR applies because of the customers, local law may apply because of the data centre, and US law applies to the company. The security manager flags the transfer question to legal before the migration, not after.
Compliance is a floor, not a ceiling
- An organisation can be compliant but insecure: passing an annual assessment while unassessed systems are vulnerable.
- It can be secure but unable to prove it: good controls with no documentation for the regulator.
- Compliance requirements are inputs to a risk-based strategy, alongside business risk; they aren’t the strategy.
- Occasionally management may accept non-compliance, for example when a requirement is ambiguous or temporarily impractical. That’s a documented, senior decision made with legal advice and an understanding of the penalties.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| First step when a new regulation is announced | Determine whether and how it applies, with legal counsel |
| Who interprets legal requirements? | Legal counsel |
| Is PCI DSS a law? | No; a contractual obligation |
| How compliance relates to security | Compliance is a minimum input to a risk-based program |
| Who decides to accept non-compliance? | Senior management, informed of the risk and penalties |
In short
- Security obligations come from laws, sector regulations, contracts, listing rules, certifications the organisation commits to, and its own policies.
- Identifying which requirements apply is the first step; legal counsel interprets them, the security manager turns them into controls.
- Jurisdiction matters: where the organisation operates, where data is stored and where customers live can all bring in different laws.
- Contractual obligations such as PCI DSS or customer security clauses are as binding as laws for the organisation.
- Compliance is a minimum, not the goal: a compliant organisation can still be insecure.
- Regulatory change must be monitored so the strategy and controls stay current.
Exam traps
- The security manager doesn't interpret the law alone; consult legal counsel.
- When a new regulation appears, the first step is to assess what it requires and the gap, not to buy tools.
- Non-compliance is a business risk decision: management may accept some, knowingly, if the impact is understood.
- Being compliant doesn't mean being secure, and being secure doesn't automatically prove compliance.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Where obligations come from
The compliance process
1 / 9