Laws, Regulations and Contractual Obligations

Laws, Regulations and Contractual Obligations in ISO/IEC 27001: A Lead Auditor Guide

Introduction
Every Information Security Management System (ISMS) operates within legal, regulatory and contractual obligations. ISO/IEC 27001 does not ask an organization to become a law firm. It does require the organization to identify, understand, document, implement and maintain the requirements that apply to its information and its processing. For an ISO 27001 Lead Auditor, this topic matters because auditors must judge whether the organization has a systematic, effective process for managing these obligations, without stepping into the role of a legal adviser.

1. Why It Is Important
Legal exposure is a core information security risk. Breaches of data protection, privacy, financial reporting or sector-specific laws can lead to:
- fines and other regulatory sanctions,
- criminal liability,
- loss of operating licences,
- civil lawsuits,
- reputational damage.

Contracts create binding security obligations. Customers, partners and suppliers often impose requirements through contracts. Examples include:
- encryption standards,
- breach notification timeframes,
- right-to-audit clauses,
- data location restrictions,
- PCI DSS compliance for card processing.

Obligations are an input to the ISMS itself. They shape the scope, the risk assessment, the risk criteria, control selection and the Statement of Applicability (SoA). If they are missed, the ISMS is built on an incomplete foundation.

Stakeholder trust depends on it. Certification signals to interested parties that the organization takes its obligations seriously. ISO certification is not a guarantee of legal compliance. However, an ISMS that ignores legal requirements cannot be considered effective.

Requirements constantly change. New laws (for example GDPR, NIS2, DORA, state privacy laws and AI regulations), amendments and new contracts mean the organization needs an ongoing monitoring process, not a one-time exercise.

2. What It Is
Obligations relevant to the ISMS fall into three broad categories.

a) Laws (Statutory Requirements)
These are passed by legislative bodies and are mandatory within a jurisdiction. Examples:
- data protection laws (GDPR, UK DPA 2018, CCPA/CPRA, LGPD, PIPEDA),
- computer misuse and cybercrime laws,
- intellectual property and copyright law,
- export control and cryptography import/export laws,
- employment law affecting monitoring of staff,
- evidence and record retention laws.

b) Regulations (Regulatory Requirements)
These are rules issued by regulators or government agencies, often sector-specific. Examples:
- HIPAA (healthcare, US),
- SOX (financial reporting),
- NIS2 (essential and important entities, EU),
- DORA (financial sector ICT resilience, EU),
- banking regulator guidance,
- telecom regulations.

c) Contractual Obligations
These are binding agreements with customers, suppliers, partners and outsourcers. Examples:
- service level agreements,
- non-disclosure agreements (NDAs),
- data processing agreements (DPAs),
- PCI DSS (an industry standard enforced contractually through card brands and acquirers, not a law),
- cloud service terms,
- software licence agreements,
- insurance policy conditions.

Related term: ISO 27001:2022 also speaks of requirements of interested parties. These can include voluntary commitments the organization chooses to adopt, such as industry codes of practice. Once adopted, they become obligations to be managed.

3. Where It Appears in ISO/IEC 27001:2022
Clause 4.1 (Context of the organization): Legal and regulatory factors are external issues relevant to the ISMS.

Clause 4.2 (Needs and expectations of interested parties): The organization must determine:
- the relevant interested parties,
- their relevant requirements,
- which of these requirements will be addressed through the ISMS (an explicit addition in the 2022 edition).
A note states that interested parties' requirements can include legal and regulatory requirements and contractual obligations.

Clause 4.3 (Scope): The scope must consider the requirements identified in 4.2.

Clause 5.1 and 5.2 (Leadership and policy): The information security policy must include a commitment to satisfy applicable requirements related to information security.

Clause 6.1 (Risk assessment and treatment): Legal and contractual obligations influence:
- risk criteria,
- impact ratings (for example, a regulatory fine increases impact),
- control selection.

Clause 6.1.3 (Statement of Applicability): Controls may be included because of a legal or contractual obligation. Justifications for inclusion often cite these drivers.

Clause 6.2 (Objectives): Objectives must take applicable information security requirements into account.

Clause 7.5 (Documented information): Documented information of external origin must be identified and controlled. Examples include copies of laws, regulator guidance and customer contracts.

Clause 9.1, 9.2 and 9.3 (Performance evaluation): Compliance is monitored and audited. Management review considers changes in external issues and in the needs and expectations of interested parties.

Annex A controls (2022), organizational controls:
- 5.31 Legal, statutory, regulatory and contractual requirements: identify, document and keep up to date the requirements and the organization's approach to meeting them.
- 5.32 Intellectual property rights: procedures to protect IP rights, including software licensing.
- 5.33 Protection of records: protect records from loss, destruction, falsification and unauthorized access or release.
- 5.34 Privacy and protection of PII: meet privacy requirements per applicable laws, regulations and contracts.
- 5.35 Independent review of information security: periodic independent review of the approach to information security.
- 5.36 Compliance with policies, rules and standards for information security: regular review of compliance.
- Related controls: 5.19 to 5.23 (supplier relationships, agreements and cloud services), 5.24 to 5.26 (incident management, including notification duties), 5.28 (collection of evidence) and 8.24 (use of cryptography, including legal restrictions).

Mapping to ISO 27001:2013: These controls were mostly in A.18.1:
- A.18.1.1 Identification of applicable legislation and contractual requirements,
- A.18.1.2 Intellectual property rights,
- A.18.1.3 Protection of records,
- A.18.1.4 Privacy and protection of PII,
- A.18.1.5 Regulation of cryptographic controls.
A.18.2 covered information security reviews. Exam questions may reference either edition, so know both.

4. How It Works in Practice
Step 1: Identify obligations.
- The organization determines its jurisdictions of operation, the data it processes (for example PII, health data or payment card data), its sectors and its contractual relationships.
- Inputs include legal counsel, compliance teams, regulator publications, contract management systems and industry bodies.

Step 2: Record them in a register.
A typical legal and contractual requirements register (sometimes called a compliance obligations register) lists:
- the requirement and its source,
- the applicable clause or section,
- the affected processes and assets,
- the responsible owner,
- the controls that address it,
- the review date,
- the compliance status.

Step 3: Interpret and assign responsibility.
- Competent people, often legal or compliance staff, translate obligations into actionable security requirements.
- Owners are assigned for each requirement.

Step 4: Integrate into risk management.
- Non-compliance becomes a risk consequence.
- Obligations drive control selection and appear in SoA justifications.

Step 5: Implement controls.
Examples:
- GDPR leads to records of processing, DPIAs, breach notification within 72 hours and data subject rights procedures.
- PCI DSS leads to network segmentation, encryption and access logging.
- A customer contract leads to a 24-hour incident notification procedure and an annual penetration test.

Step 6: Monitor changes.
- Subscriptions to legal update services, periodic reviews and contract change processes keep the register current.
- Changes feed into management review (clause 9.3).

Step 7: Evaluate compliance.
Compliance is checked through:
- internal audits,
- compliance checks (control 5.36),
- independent reviews (5.35),
- regulator inspections,
- customer audits.

Step 8: Correct and improve. Non-compliances are handled through corrective action under clause 10.2.

5. The Auditor's Role and Its Limits
This distinction is heavily tested.

The auditor DOES:
- verify that a process exists to identify and update applicable requirements,
- check that the register is reasonable for the organization's context (for example, a hospital that omits health data law is a red flag),
- sample requirements and trace them to controls, the SoA, risks and evidence of implementation,
- verify that responsibilities are assigned,
- check that changes are monitored and reviewed,
- confirm that compliance is evaluated and that non-compliances are corrected.

The auditor DOES NOT:
- provide legal advice or a legal opinion,
- declare the organization legally compliant,
- interpret the law on the organization's behalf,
- act as a regulator.
Certification audits (under ISO/IEC 17021-1 and guided by ISO 19011) assess the management system, not legal compliance itself.

When the auditor finds evidence of possible legal non-compliance:
- The auditor records it as an audit finding against the relevant ISMS requirement (for example clause 4.2, control 5.31 or 5.34).
- The auditor raises it with the auditee and the audit team leader.
- Following the certification body's procedures, the auditor may need to consider whether it affects certification.
- Severe, unaddressed illegal activity may prevent certification.
- Confidentiality obligations still apply, but any legal reporting duties imposed by the jurisdiction must be respected.

Typical audit evidence:
- the legal and contractual register,
- minutes showing review of legal updates,
- DPAs and supplier contracts containing security clauses,
- software licence inventories,
- records retention schedules,
- breach notification procedures and records,
- privacy notices,
- DPIAs,
- management review inputs,
- compliance check reports,
- interview responses from legal, HR, procurement and IT staff.

Typical nonconformities:
- No register exists, or it is outdated (for example, it still references repealed laws or omits new ones).
- The register exists, but its requirements are not linked to risks or controls.
- Contractual security obligations are unknown to the teams who must fulfil them.
- Unlicensed software is in use (5.32).
- Records are retained beyond legal limits, or destroyed before mandatory retention periods end (5.33).
- Personal data is transferred across borders without a legal basis (5.34).
- Customer contracts specify incident notification timelines that the incident procedure cannot meet.

Grading:
- A major nonconformity is typically raised when there is a total absence or systemic failure. Examples: no process at all for identifying legal requirements, or widespread breaches indicating the ISMS cannot achieve its intended outcomes.
- A minor nonconformity is an isolated lapse. Examples: one contract missing from the register, or a review date missed once.

6. Exam Tips: Answering Questions on Laws, Regulations and Contractual Obligations
Tip 1: Remember the auditor is not a lawyer. Reject options where the auditor gives legal advice, certifies legal compliance or tells the auditee how to interpret a law. The correct answer usually involves verifying the process and the evidence.

Tip 2: Know the key clause and control numbers.
- Clause 4.2: interested parties' requirements.
- Control 5.31: identification of legal, statutory, regulatory and contractual requirements.
- 5.32: intellectual property rights.
- 5.33: records.
- 5.34: privacy and PII.
- 5.35 and 5.36: reviews and compliance.
- For 2013-based questions: A.18.1.1 to A.18.1.5.

Tip 3: Distinguish law from contract. PCI DSS is a contractual and industry requirement, not legislation. GDPR is law (an EU regulation). NIS2 is an EU directive transposed into national law. Questions may test whether you can classify a requirement correctly.

Tip 4: Look for the 'identify, document, keep up to date' trio. Control 5.31 is about identification, documentation and maintenance. Scenarios showing an outdated register or no review mechanism point to a nonconformity against 5.31 and/or clause 4.2.

Tip 5: Follow the audit trail. In scenario questions, the best audit approach is usually to trace an obligation from the register to the risk assessment, then to the SoA and controls, and finally to evidence of operation. Sampling a specific requirement and verifying implementation is stronger than simply reviewing the register.

Tip 6: Choose the most specific clause or control for findings.
- Unlicensed software: 5.32.
- Mishandled personal data: 5.34.
- Records destroyed early: 5.33.
- Requirements never identified: 4.2 / 5.31.
- Supplier contracts lacking security clauses: 5.20.
Select the best fit, not merely a possible fit.

Tip 7: Grade findings by impact and pervasiveness. Ask whether the failure is systemic or isolated, and whether it undermines the ISMS's ability to achieve its intended outcomes. A missing compliance process is a major nonconformity. One overlooked clause in one contract is minor.

Tip 8: Certification does not equal legal compliance. If an option claims that ISO 27001 certification proves compliance with GDPR or another law, it is wrong.

Tip 9: Recognise the context link. Questions may ask how legal requirements influence the ISMS. Good answers mention:
- external issues (4.1),
- interested parties (4.2),
- scope (4.3),
- the policy commitment (5.2),
- risk criteria and control selection (6.1),
- objectives (6.2),
- management review inputs (9.3).

Tip 10: For essay or open questions, use a structure.
- What the requirement is.
- Why it matters (risk, sanctions, trust).
- Where it sits in the standard.
- How the organization meets it (register, owners, controls, monitoring).
- How the auditor verifies it (evidence, interviews, sampling).
- What a finding would look like and how it would be graded.

Tip 11: Watch for jurisdiction traps. Organizations operating in several countries must address all applicable jurisdictions, including those of their customers and data subjects (for example GDPR's extraterritorial reach). Cloud and outsourcing scenarios often hide cross-border data transfer issues.

Tip 12: Handle suspected illegal activity correctly. The correct response is to record objective evidence, inform the audit team leader and the auditee's management, and follow certification body procedures. Calling the police yourself, ignoring the issue or advising on legal remedies is incorrect, unless a specific legal duty to report exists.

7. Sample Exam-Style Questions
Q1: During an audit, you find that the legal register was last updated three years ago and does not include a data protection law that came into force last year. What is the most appropriate finding?
Answer approach: This is a nonconformity against control 5.31 (and clause 4.2), because requirements are not kept up to date. Grade it by impact. If personal data processing is central to the scope and no other mechanism compensates, it may be major. Otherwise it is minor. Do not advise how to comply with the law.

Q2: The auditee asks you whether their privacy notice meets legal requirements. What should you do?
Answer approach: Explain that the auditor cannot provide a legal opinion. You can verify that the organization has a process for ensuring privacy requirements are identified and met, for example through legal review records. Recommend that they consult qualified legal counsel.

Q3: A software inventory reveals 40 installations of a product but licences for only 25. Which control is most relevant?
Answer approach: Control 5.32, Intellectual property rights (A.18.1.2 in 2013).

Q4: A customer contract requires breach notification within 24 hours, but the incident procedure states 72 hours. What does this indicate?
Answer approach: Contractual requirements have not been properly identified and integrated into ISMS processes. This relates to 5.31, 4.2 and incident management controls (5.24 to 5.26). Raise a nonconformity supported by objective evidence.

8. Key Takeaways
- Legal, regulatory and contractual obligations are mandatory inputs to the ISMS context, risk assessment and control selection.
- ISO 27001:2022 addresses them through clause 4.2 and Annex A controls 5.31 to 5.36, plus related supplier, incident, cryptography and evidence controls.
- Organizations must identify, document, assign, implement, monitor and review their obligations.
- Auditors verify the effectiveness of the process and the implementation evidence. They never act as legal advisers or certify legal compliance.
- In exams, choose answers that focus on process, objective evidence and the most specific clause or control, with appropriate grading of findings.