04 Context of the Organization

The Context of the Organization is the foundation of an ISO/IEC 27001 Information Security Management System.

Before an organization decides:

Which risks matter.
Which controls should be implemented.
Which policies are required.
Which systems are in scope.
Which security objectives should be established.

it must first understand the business environment in which the ISMS operates.

This is the purpose of Clause 4.

A well-defined organizational context allows the ISMS to answer:

What does the organization do?
        ↓
What internal and external factors matter?
        ↓
Who has security expectations?
        ↓
What requirements apply?
        ↓
Which services and assets matter?
        ↓
What dependencies exist?
        ↓
What should the ISMS cover?

Poor context leads to poor scope.

Poor scope leads to incomplete risk assessment.

Incomplete risk assessment leads to weak controls.

For this reason, Clause 4 should not be treated as introductory paperwork. It directly shapes the entire ISMS.

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose of Clause 4.
Identify internal organizational issues.
Identify external organizational issues.
Evaluate how contextual issues affect information security.
Identify interested parties.
Determine relevant interested-party requirements.
Build an interested-party register.
Identify applicable legal, regulatory, contractual, and business requirements.
Understand critical business services.
Map business and technology dependencies.
Identify interfaces between in-scope and out-of-scope environments.
Establish defensible ISMS boundaries.
Develop a formal ISMS scope statement.
Maintain context information over time.
Recognize common Clause 4 implementation failures.

1. Clause 4 Overview

Clause 4 can be understood through four main areas:

4.1
Understand the organization and its context

        ↓

4.2
Understand interested parties and their requirements

        ↓

4.3
Determine the ISMS scope

        ↓

4.4
Establish and maintain the ISMS

These activities are tightly connected.

For example:

Customer Requirement
        ↓
Interested Party
        ↓
Critical SaaS Service
        ↓
Supporting Cloud Infrastructure
        ↓
Included in ISMS Scope

2. Why Organizational Context Matters

Information-security risk does not exist independently of the business.

Consider two organizations using the same cloud storage technology.

Organization A

Uses it to store:

Public marketing images

Organization B

Uses it to store:

Customer identity information
Financial records
Confidential contracts

The technology may be identical.

The business context is not.

Therefore:

Technology
    +
Business Context
    =
Meaningful Security Risk

3. Start With the Business

Before discussing controls, understand:

What products are sold?
What services are provided?
Who are the customers?
Which services generate revenue?
Which processes are business critical?
Which information is sensitive?
Which technologies enable the business?
Which external parties are relied upon?

Example:

Organization:
NorthStar Digital Services

Primary Service:
Enterprise SaaS Platform

Customers:
Global businesses

Critical Dependency:
Cloud infrastructure

Sensitive Information:
Customer records
Authentication data
Business documents

This immediately provides security context.

4. Clause 4.1 — Internal and External Issues

Clause 4.1 requires organizations to understand issues relevant to their purpose and that may affect intended ISMS outcomes.

These issues may be:

Internal
or
External

The objective is not to create the longest possible list.

The objective is to identify factors that materially influence the ISMS.

5. Internal Issues

Internal issues arise within the organization.

Examples include:

Organizational structure.
Business strategy.
Technology architecture.
Security maturity.
Staffing.
Budget.
Legacy systems.
Corporate culture.
Mergers.
Rapid growth.
Remote workforce.
Cloud adoption.
Existing processes.

6. Internal Issue Example — Rapid Growth

Suppose the organization grows from:

500 Employees
      ↓
3,000 Employees

within two years.

Potential security implications:

More Identities

More Endpoints

More SaaS

More Vendors

More Access Requests

Greater Governance Complexity

Relevant ISMS actions may include:

Stronger identity governance.
Formal joiner/mover/leaver processes.
Improved asset management.
Expanded third-party risk management.

7. Internal Issue Example — Legacy Technology

Issue:

Legacy ERP cannot support modern MFA.

Potential ISMS impact:

Increased identity risk.
Need for compensating controls.
Risk acceptance.
Modernization planning.
Exception governance.

Context therefore influences risk treatment.

8. Internal Issue Example — Remote Workforce

A highly distributed workforce may increase:

Endpoint risk.
Remote-access risk.
SaaS dependency.
Data-handling risk.
Identity risk.

The ISMS may need stronger:

Endpoint Security

Conditional Access

Remote Access

Security Awareness

DLP

9. External Issues

External issues originate outside the organization.

Examples include:

Cyber threat environment.
Legal changes.
Regulations.
Customer expectations.
Economic conditions.
Technology shifts.
Industry requirements.
Supply-chain disruptions.
Geopolitical events.
Competitor pressure.
Emerging AI adoption.

10. External Issue Example — Ransomware

External issue:

Increasing ransomware attacks targeting the industry

Potential ISMS response:

Improve Backups

Test Recovery

Strengthen Privileged Access

Increase EDR Coverage

Perform IR Exercises

This demonstrates how external context affects security planning.

11. External Issue Example — Regulatory Change

Suppose a new applicable regulation introduces stronger incident-notification requirements.

Potential impact:

Incident Response Procedure Update

Contract Update

Escalation Change

Communication Workflow

Staff Training

Context must therefore be periodically reviewed.

12. External Issue Example — Customer Expectations

Enterprise customers increasingly require:

SOC 2.
ISO/IEC 27001.
Penetration testing.
Security questionnaires.
Encryption.
Incident notification.
Supplier governance.

Customer expectations may become business drivers for the ISMS.

13. Context Register

A practical context register may contain:

ID	Issue	Type	Security Impact	Owner	Review
CTX-001	Rapid cloud adoption	Internal	Cloud governance risk	CIO	Quarterly
CTX-002	Ransomware growth	External	Availability risk	CISO	Quarterly
CTX-003	New customer requirements	External	Assurance requirements	Sales/GRC	Quarterly
CTX-004	Legacy IAM systems	Internal	Access-control risk	IAM	Quarterly

This creates a structured record.

14. Writing Good Context Statements

Weak:

Cybersecurity threats exist.

Better:

Ransomware attacks targeting organizations in the technology sector have increased, creating additional risk to service availability and recovery objectives.

Strong context statements explain:

What is changing?

Why does it matter?

What aspect of the ISMS is affected?

15. Context Assessment Questions

For each issue, ask:

What changed?
Why is it relevant?
Which business service is affected?
Which information-security objective is affected?
Does it create new risk?
Do existing controls remain sufficient?
Does the ISMS scope need adjustment?
Does management need to act?

16. Context Review Frequency

Organizational context should not be static.

Possible review triggers include:

Annual ISMS Review

Major Business Change

Acquisition

New Technology

New Regulation

Security Incident

New Major Customer

New Geography

The organization should define an appropriate review process.

17. Clause 4.2 — Interested Parties

Interested parties are individuals or organizations relevant to the ISMS because they have requirements or expectations concerning information security.

Common interested parties include:

Customers

Employees

Regulators

Government Authorities

Suppliers

Partners

Shareholders

Executive Management

Certification Bodies

18. Interested Parties Are Not Just Stakeholders

A list of names is not enough.

The organization must understand:

What requirements from these parties are relevant to information security?

Example:

Interested Party:
Customer

Requirement:
Protect confidential customer data

Another:

Interested Party:
Regulator

Requirement:
Meet applicable privacy obligations

19. Interested-Party Register

Create a register such as:

Party	Requirement	Source	ISMS Impact	Owner
Customers	Protect confidential information	Contracts	Security controls	GRC
Employees	Protect employee data	Law/Policy	Privacy controls	HR
Regulator	Required reporting	Regulation	Incident process	Legal
Cloud Provider	Shared-responsibility obligations	Agreement	Cloud controls	Cloud Team

20. Customer Requirements

Customer requirements may include:

Confidentiality.
Availability.
Encryption.
Authentication.
Logging.
Audit rights.
Incident notification.
Data deletion.
Geographic restrictions.

These requirements may come from contracts.

21. Employee Requirements

Employees may expect:

Protection of personal information.
Secure systems.
Clear policies.
Appropriate access.
Security awareness.

Relevant requirements may arise from:

Law.
HR policy.
Employment agreements.

22. Regulatory Requirements

Regulators may require:

Data protection.
Security governance.
Incident reporting.
Records retention.
Access controls.
Risk management.

These requirements may influence multiple ISMS processes.

23. Supplier Requirements

Suppliers can also introduce requirements.

For example:

Cloud Provider
      ↓
Shared Responsibility Model
      ↓
Customer Security Obligations

These responsibilities should be understood.

24. Certification Bodies

A certification body becomes relevant when the organization pursues ISO certification.

Relevant expectations include:

Defined ISMS scope.
Effective implementation.
Internal audit.
Management review.
Corrective action.
Evidence.

25. Determining Relevant Requirements

Not every expectation automatically becomes an ISMS requirement.

The organization should determine which requirements are relevant.

For each one ask:

Is it mandatory?

Is it contractual?

Does it relate to the ISMS?

Which part of the organization does it affect?

What control or process addresses it?

26. Requirements Register

A dedicated requirements register may contain:

ID	Requirement	Source	Applicable	Control/Process
REQ-001	Encrypt customer data	Contract	Yes	Encryption Standard
REQ-002	Incident notification	Regulation	Yes	Incident Response
REQ-003	Annual vendor review	Policy	Yes	TPRM Process

This supports traceability.

27. From Interested Party to Control

Example:

Customer
   ↓
Requires Confidential Data Protection
   ↓
Information Security Policy
   ↓
Encryption Standard
   ↓
Encryption Control
   ↓
Evidence

This is how Clause 4 connects to operational governance.

28. Understanding Critical Business Services

Before defining ISMS scope, identify critical services.

Examples:

Customer SaaS Platform

Payment Processing

Identity Platform

Customer Support

Cloud Infrastructure

Security Operations

Security scope should reflect what is important to the business.

29. Business Service Mapping

For each critical service, identify:

Business Service
      ↓
Applications
      ↓
Infrastructure
      ↓
Data
      ↓
People
      ↓
Third Parties

Example:

Customer SaaS Platform
      │
      ├── AWS
      ├── Customer Database
      ├── Entra ID
      ├── CI/CD Platform
      ├── Engineering Team
      └── Cloud Vendors

30. Why Dependency Mapping Matters

An ISMS may scope one application but overlook a critical dependency.

Example:

SaaS Platform
      ↓
Depends on Corporate Identity

If identity is compromised:

SaaS Security
      ↓
Also Compromised

Dependencies therefore influence scope and risk.

31. Types of Dependencies

Dependencies may include:

Technology

Cloud.
Network.
Identity.
DNS.
Databases.
CI/CD.

People

Administrators.
Developers.
SOC staff.

Process

Change management.
Incident response.
Procurement.

Third Parties

SaaS.
Cloud providers.
MSPs.

32. Upstream Dependencies

An upstream service enables another service.

Example:

Identity Platform
      ↓
Customer Application

If the identity service fails, application access may fail.

33. Downstream Dependencies

An application may feed information to other processes.

Example:

Customer Platform
      ↓
Billing System
      ↓
Reporting System

Changes or failure may affect downstream services.

34. Shared Services

Shared enterprise services may support many in-scope environments.

Examples:

Identity

Logging

DNS

Email

Backup

Security Operations

Even if managed centrally, they may need inclusion or documented interfaces.

35. Third-Party Dependencies

Example:

Customer Platform
      ↓
Cloud Provider
      ↓
Managed Database
      ↓
Email Service

Supplier dependencies can materially influence ISMS risk.

36. Dependency Register

A practical register might include:

Service	Dependency	Type	Criticality	Owner
SaaS Platform	Entra ID	Identity	Critical	IAM
SaaS Platform	AWS	Cloud	Critical	Cloud
SaaS Platform	CI/CD	DevOps	High	Engineering
SaaS Platform	Support SaaS	Third Party	High	Support

37. Interfaces

An interface is a point where the ISMS interacts with something outside its defined boundary.

Examples:

In-Scope SaaS
      ↕
Out-of-Scope Corporate Network

or:

In-Scope Application
      ↕
External Payment Processor

Interfaces should be understood.

38. Why Interfaces Matter

Risks often cross boundaries.

For example:

Out-of-Scope Identity System
       ↓
Authentication
       ↓
In-Scope Application

The dependency cannot simply be ignored because it is outside formal scope.

39. Clause 4.3 — Determining ISMS Scope

After understanding:

Context.
Interested parties.
Requirements.
Dependencies.

the organization can define the ISMS scope.

The scope establishes:

What is included?

Where?

Which services?

Which processes?

Which teams?

Which dependencies?

40. Scope Design Principles

A good scope should be:

Clear.
Specific.
Defensible.
Relevant.
Understandable.
Consistent with business reality.

Avoid artificial boundaries designed only to reduce audit effort.

41. Example Weak Scope

Information systems used by NorthStar.

Problems:

Which systems?
Which locations?
Which products?
Which services?
Which teams?

It is too vague.

42. Example Strong Scope

The Information Security Management System covers the design, development, operation, maintenance, and customer support of NorthStar Digital Services’ production SaaS platform, including supporting AWS production infrastructure, security operations, engineering processes, and associated personnel located in India and the United Kingdom.

This provides clearer boundaries.

43. Scope Components

A scope statement may include:

Organization

Product / Service

Processes

Locations

Infrastructure

Supporting Functions

Not every scope needs identical wording.

44. Physical Locations

Where relevant, document:

Offices.
Data centers.
Cloud-hosting arrangements.
Remote workers.
Support centers.

Example:

Primary Office:
Bangalore

Remote Workforce:
India + UK

Hosting:
AWS

45. Logical Boundaries

Modern cloud organizations may be better scoped logically than physically.

Example:

Production AWS Organization

SaaS Application

Security Operations

Engineering CI/CD

Physical boundaries may be less meaningful in cloud-native environments.

46. Organizational Boundaries

Determine whether scope includes:

Whole organization.
Division.
Subsidiary.
Product team.
Business function.

This should match the intended certification objective.

47. Scope Exclusions

Exclusions should be clearly understood.

Example:

Excluded:
Independent consulting subsidiary

Ask:

Does the excluded entity provide any service or infrastructure used by the ISMS?

If yes, interfaces must be documented.

48. Scope and Certification

Certification applies only to the approved scope.

A certificate should not be interpreted as:

Entire Company Secure

unless the entire company is genuinely within scope.

49. Scope Creep

ISMS scope may grow over time.

Examples:

New Product

New Office

Acquisition

New Data Center

New Cloud Provider

Scope should be periodically reviewed.

50. Scope Change Example

Original:

One SaaS Product

Later:

Second SaaS Product Introduced

GRC should determine:

Is it covered?
Should it be added?
Does risk assessment need updating?
Are new controls needed?

51. Scope Approval

Scope should be formally approved by appropriate leadership.

Possible evidence:

ISMS Scope Document

Approval Record

Version History

This demonstrates governance.

52. Clause 4.4 — Establish the ISMS

Once scope is defined, the organization establishes the management system.

The ISMS should include:

Processes

Roles

Policies

Risk Management

Controls

Monitoring

Assurance

Improvement

Clause 4.4 is therefore the transition from context into actual ISMS operation.

53. ISMS Process Map

A practical process map might show:

Context
   ↓
Risk Management
   ↓
Policy Management
   ↓
Control Management
   ↓
Compliance
   ↓
Monitoring
   ↓
Internal Audit
   ↓
Management Review
   ↓
Corrective Action

This demonstrates how the ISMS operates.

54. Clause 4 Evidence Package

Typical evidence may include:

Organizational Context Register

Interested-Party Register

Applicable Requirements Register

Business Service Inventory

Dependency Register

ISMS Scope Statement

ISMS Process Map

Scope Approval

These artifacts provide a strong Clause 4 foundation.

55. Context-to-Risk Traceability

Context should influence risk assessment.

Example:

External Issue:
Ransomware increase

      ↓

Risk:
Ransomware service disruption

      ↓

Treatment:
Recovery testing + EDR + PAM

If context never affects risk, the context analysis may be superficial.

56. Interested-Party-to-Control Traceability

Example:

Customer Contract
      ↓
24-Hour Incident Notification
      ↓
Incident Response Standard
      ↓
Notification Workflow
      ↓
Testing

This demonstrates actual use of interested-party requirements.

57. Context and Security Objectives

Context can also influence objectives.

Example:

Internal Issue:
Rapid cloud adoption

      ↓

Security Objective:
Achieve 100% centralized cloud logging coverage by Q2 2027.

This connects business change to measurable security improvement.

58. Context and Management Review

Management review should revisit significant contextual changes.

For example:

New Regulation

New Threat

Major Vendor

Acquisition

Market Expansion

These may require ISMS changes.

59. Example Organizational Context Analysis

Suppose NorthStar identifies:

Internal

Rapid cloud growth

Limited GRC staffing

Remote workforce

Legacy IAM

External

Ransomware increase

Customer demand for ISO certification

New privacy requirements

Increasing SaaS dependency

These factors should influence risk and priorities.

60. Example Context Register

Issue	Security Effect	Action
Cloud growth	Misconfiguration risk	Cloud baseline
Legacy IAM	Authentication risk	IAM modernization
Customer ISO demand	Assurance requirement	Certification project
New privacy rules	Compliance exposure	Privacy-control review

This is much more useful than a generic SWOT-style document with no security connection.

61. Interested-Party Scenario

NorthStar has a major enterprise customer.

Contract requires:

MFA

Annual Penetration Testing

24-Hour Incident Notification

Secure Data Deletion

The customer should appear within the interested-party and requirements analysis.

These requirements should influence:

Policies.
Controls.
Audit evidence.
Vendor contracts where necessary.

62. Regulatory Scenario

NorthStar begins serving customers in a new jurisdiction.

GRC identifies new data-protection obligations.

Potential actions:

Update Requirements Register

Review Data Flows

Review Retention

Update Incident Process

Update Risk Assessment

This is Clause 4 in practice.

63. Acquisition Scenario

NorthStar acquires a smaller SaaS company.

Immediate Clause 4 questions:

Is the new company in scope?

What services does it operate?

Which information does it process?

Which controls exist?

What dependencies exist?

Which requirements apply?

Scope may need updating.

64. New AI Service Scenario

The organization introduces enterprise generative AI.

Context change:

New Technology

Possible implications:

Data Leakage Risk

AI Vendor Risk

Privacy Risk

Intellectual Property Risk

Access Governance

The ISMS should adapt.

65. Remote Workforce Scenario

Suppose 80% of employees move to remote work.

Context change may require:

Endpoint Security

Secure Remote Access

Device Compliance

Data Protection

Security Awareness

Clause 4 drives broader ISMS adaptation.

66. Maintaining Context Records

For each major contextual artifact, define:

Owner

Review Frequency

Version

Approval

Change History

Example:

Context Register

Owner:
GRC

Review:
Quarterly

Approver:
CISO

67. Auditor Expectations

An auditor may expect employees and management to demonstrate awareness of:

What the organization does.
What the ISMS covers.
Major security risks.
Important interested parties.
Relevant security requirements.

Clause 4 should not be understood only by one GRC analyst.

68. Typical Auditor Questions — Context

Auditor may ask:

What major internal issues affect information security?
What external changes have you identified?
How are these reviewed?
Can you show how they influenced the ISMS?

Strong answers should point to actual risk or control decisions.

69. Typical Auditor Questions — Interested Parties

Auditor may ask:

Who are the key interested parties?
What security requirements do they have?
Where are those requirements recorded?
How are contract requirements incorporated?
How do you identify regulatory changes?

70. Typical Auditor Questions — Scope

Auditor may ask:

What exactly is included in the ISMS?
Why?
Which systems support it?
What is excluded?
Which interfaces cross the boundary?
How is scope updated when the business changes?

71. Typical Auditor Questions — Clause 4.4

Auditor may ask:

How is your ISMS structured?
What are the main processes?
Who coordinates the ISMS?
How are these processes maintained and improved?

The organization should be able to explain its management system coherently.

72. Common Clause 4 Mistakes

Mistake 1 — Generic Context

Example:

Cybersecurity is important.

This does not identify meaningful internal or external issues.

Mistake 2 — Interested Parties Without Requirements

Listing:

Customers
Regulators
Employees

without identifying what they require is incomplete.

Mistake 3 — Scope Designed Only for Certification Convenience

Artificial scope boundaries may miss critical dependencies.

Mistake 4 — Missing Interfaces

Out-of-scope services can still affect in-scope operations.

Mistake 5 — Static Context

Context is created once and never reviewed.

Mistake 6 — No Traceability

Context issues never influence risk, objectives, or controls.

73. Weak vs Strong Context Analysis

Weak

Issue:
Cyberattacks

Strong

Issue:
Increased ransomware attacks targeting SaaS providers.

Business Relevance:
Customer platform availability is contractually important.

Security Impact:
Recovery and privileged-access controls require increased assurance.

Action:
Increase recovery-test frequency and PAM coverage.

74. Weak vs Strong Interested-Party Analysis

Weak

Party:
Customers

Strong

Party:
Enterprise Customers

Requirement:
Protect confidential customer information and notify material incidents according to contractual timelines.

ISMS Impact:
Encryption, IAM, incident response, logging, contractual monitoring.

75. Weak vs Strong Scope

Weak

NorthStar systems.

Strong

The ISMS covers the development, operation, maintenance, and customer support of NorthStar’s enterprise SaaS service, including its AWS production environment, CI/CD services, security operations, and personnel supporting production services.

Specific scope supports effective risk assessment.

76. Practical Activity — Build a Context Register

Create:

01 Organizational Context Register

Suggested columns:

ID	Issue	Internal/External	Business Impact	Security Impact	Owner	Action

Create at least:

5 Internal Issues
+
5 External Issues

77. Practical Activity — Build Interested-Party Register

Create:

02 Interested-Party Register

Use:

Party	Requirement	Source	Relevant?	ISMS Response

Include:

Customers.
Employees.
Regulators.
Vendors.
Executive leadership.

78. Practical Activity — Build Requirements Register

Create:

03 Applicable Requirements Register

Fields:

Requirement ID

Requirement

Source

Business Area

System / Service

Owner

Mapped Policy

Mapped Control

Status

This creates direct compliance traceability.

79. Practical Activity — Build Business Service Map

Create:

04 Business Service & Dependency Map

For each critical service identify:

Application

Cloud

Identity

Network

Data

People

Third Parties

This will support the scope exercise.

80. Practical Activity — Write the Scope

Create:

05 ISMS Scope Statement

Use this template:

The Information Security Management System covers [products/services], including [business processes/functions], supported by [technology/infrastructure], operated from [locations], and managed by [relevant organizational functions].

Review dependencies and exclusions before finalizing.

81. Scope Validation Questions

Before approving scope, confirm:

Does it cover the intended business service?

Are critical dependencies understood?

Are relevant teams included?

Are significant third parties considered?

Are interfaces documented?

Are exclusions defensible?

Would management understand the boundary?

Would an auditor understand it?

82. Context Review Checklist

Periodically ask:

Have business objectives changed?
Have new products launched?
Have new geographies been entered?
Have regulatory requirements changed?
Have customer requirements changed?
Has technology materially changed?
Have new threats emerged?
Have acquisitions occurred?
Have new vendors become critical?

If yes, determine ISMS impact.

83. Clause 4 Evidence Checklist

Before an audit, confirm:

Internal issues identified.
External issues identified.
Issues linked to security relevance.
Interested parties identified.
Relevant requirements documented.
Applicable requirements register maintained.
Critical services identified.
Dependencies identified.
Interfaces understood.
Scope documented.
Scope approved.
Scope reviewed after significant changes.
ISMS processes established.

84. GRC Analyst Responsibilities

A GRC professional supporting Clause 4 may:

Facilitate organizational context workshops.
Maintain the context register.
Identify interested parties.
Capture applicable requirements.
Coordinate with Legal and Compliance.
Maintain the requirements register.
Map business services.
Document dependencies.
Draft the ISMS scope.
Coordinate scope approval.
Review contextual changes.
Update risk assessment when context changes.

These activities form the foundation of ISO implementation.

85. Clause 4 Governance Model

A practical ownership model could be:

Executive Leadership
      ↓
Approves ISMS Scope

CISO
      ↓
Owns Security Direction

GRC
      ↓
Maintains Context & Requirements

Business Owners
      ↓
Validate Business Services

Legal / Privacy
      ↓
Validate Obligations

Technology Teams
      ↓
Validate Dependencies

Clause 4 should be collaborative.

86. Context and Risk Assessment

Once Clause 4 is established, risk assessment becomes more meaningful.

Instead of asking:

What cybersecurity risks exist?

you can ask:

What risks could affect the business services,
requirements,
stakeholders,
and assets
identified in Clause 4?

This produces business-aligned risks.

87. Context and Annex A

Clause 4 may also influence control applicability.

Example:

Critical SaaS Business
      +
Large Supplier Dependency
      ↓
Strong Supplier Security Controls Required

Another:

Remote Workforce
      ↓
Endpoint and Remote Working Controls Become Important

Control selection should reflect organizational reality.

88. Context and Statement of Applicability

The SoA should ultimately reflect:

Context

Requirements

Risks

Treatment Decisions

Control Applicability

Clause 4 therefore indirectly shapes the SoA.

89. Context and Certification

A certification auditor will assess the ISMS within the defined context and scope.

If the scope is unclear:

Risk assessment may be incomplete.
Control applicability may be unclear.
Evidence population may be incorrect.
Certification boundaries may be misunderstood.

Strong Clause 4 work reduces many later problems.

90. Practical Scenario — NorthStar

NorthStar wants ISO/IEC 27001 certification for its enterprise SaaS business.

GRC identifies:

Internal Issues

Rapid cloud expansion

Remote workforce

Legacy identity services

High vendor dependency

Rapid product releases

External Issues

Ransomware activity

Enterprise customer security requirements

New privacy obligations

Increasing supply-chain attacks

AI adoption

91. Interested Parties

NorthStar identifies:

Enterprise Customers

Employees

Regulators

Cloud Providers

Business Partners

Executive Leadership

Relevant requirements are captured.

92. Critical Service

Enterprise SaaS Platform

Dependencies:

AWS

Entra ID

CI/CD Platform

Customer Database

SOC

Support SaaS

These inform the ISMS boundary.

93. Draft Scope

NorthStar drafts:

The ISMS covers the design, development, operation, maintenance, and customer support of NorthStar Digital Services’ enterprise SaaS platform, including supporting production cloud infrastructure, security operations, identity services, engineering processes, and personnel supporting the service.

This scope now reflects actual dependencies.

94. Traceability Example

Customer Requirement
      ↓
High Availability
      ↓
Critical SaaS Service
      ↓
AWS Dependency
      ↓
Availability Risk
      ↓
Recovery Controls

This is what useful organizational context looks like.

95. Context Management Mindset

When reviewing Clause 4, continuously ask:

What business are we protecting?

Who depends on it?

What do they require?

What has changed?

Which services matter?

What does each service depend on?

Where are the ISMS boundaries?

What risks arise from this context?

If these questions are answered clearly, the rest of the ISMS becomes easier to design.

Key Takeaways

Clause 4 establishes the business foundation of the ISMS.
Internal and external issues should be relevant to information security and ISMS outcomes.
Organizational context should influence risk, controls, objectives, and improvement activities.
Interested parties should be identified along with their relevant requirements.
Requirements may arise from customers, regulators, employees, vendors, contracts, and other sources.
Critical business services and supporting dependencies should be understood before defining scope.
Interfaces between in-scope and out-of-scope services can create important risks.
ISMS scope should be specific, defensible, and consistent with business reality.
Certification applies only to the defined scope.
Scope should be reviewed when business, technology, regulation, or organizational structure changes.
Clause 4 artifacts should support traceability into risk assessment and control selection.
GRC plays a central role in maintaining context, requirements, dependencies, and scope.

Knowledge Check

Before continuing, make sure you can answer:

What is the purpose of Clause 4?
What is an internal organizational issue?
What is an external organizational issue?
Why should context issues be security relevant?
Who are interested parties?
Why is listing interested parties alone insufficient?
What is an interested-party requirement?
What is an applicable requirements register?
Why should critical business services be identified?
What is a dependency?
What is an interface?
Why can out-of-scope systems still matter?
What should an ISMS scope describe?
Why are vague scope statements problematic?
How can scope change over time?
Why should scope exclusions be justified?
How does Clause 4 influence risk assessment?
How does Clause 4 influence control selection?
What evidence might an auditor request for Clause 4?
What role does GRC play in organizational context management?

What’s Next?

➡️ Next: 05 — Leadership & Governance

In the next lesson, you will move from defining the organizational foundation of the ISMS into establishing leadership accountability and governance under Clause 5.

You will learn how to:

Establish Executive Sponsorship
        ↓
Define Information Security Policy
        ↓
Assign ISMS Responsibilities
        ↓
Create Governance Committees
        ↓
Define Risk Authorities
        ↓
Establish Control Ownership
        ↓
Provide Resources
        ↓
Demonstrate Management Commitment

You will also learn how to build practical governance artifacts including an ISMS governance structure, RACI matrix, leadership responsibilities, policy approval model, risk-acceptance authority matrix, and management oversight process.