This post covers Clause 4.1 specifically — what the standard requires, what to document, and what an auditor will check. We’ll use a small healthcare practice as the working example.
What 4.1 Actually Requires
The standard text is straightforward: “The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.”
That’s it. Two categories — internal and external — documented in a way that connects to your ISMS. The issues you identify here should visibly influence your risk assessment and control decisions downstream. If they don’t connect to anything else in the ISMS, they exist on paper only.
Internal Issues
Structure and staffing. Document who handles sensitive information and how the organization is structured. How many people are involved in processing client data? Is there a dedicated IT or security function, or is technology managed by someone with broader responsibilities? This is factual context — roles and accountability get formally assigned in Clause 5.
Technology environment. What systems process or store sensitive data? This includes cloud services. If your organization uses Microsoft 365, or any SaaS application that touches client data, those systems belong here. A common gap: organizations document on-premise infrastructure and omit the cloud services where most of their data actually lives.
Resource constraints. Small organizations have limited budgets and limited time. Documenting this honestly is the foundation for a realistic risk treatment plan.
External Issues
Regulatory obligations. This is where most organizations underestimate their exposure. Know your regulatory environment specifically, not generically. A healthcare practice has HIPAA. An organization handling EU resident data has GDPR. A publicly traded company or its suppliers may have SOX obligations. A company processing payment cards has PCI DSS. Identify what applies to your organization. A vague statement about complying with applicable laws satisfies nothing.
Market and client environment. Are clients asking about your security posture before signing contracts? Are competitors promoting their security credentials? These are external pressures that shape what your ISMS needs to address.
Threat environment. What threats are realistic for your sector? Document threats that are actually relevant to your organization. Healthcare organizations are consistent ransomware targets. Professional services firms face phishing and business email compromise. Retailers face payment card skimming. The threat landscape is sector-specific and should be documented as such.
A dated document with evidence of review. Your context document needs to reflect your actual environment: your systems, your staff structure, your specific regulatory obligations.
Regulatory obligations have to be named. “We comply with all applicable laws” satisfies nothing. HIPAA, GDPR, state breach notification — name what applies and why.
They’ll also check that what you documented here connects to your risk assessment. Ransomware listed as a threat with no ransomware risk in your register is a finding.
Most common gap: Internal issues documented, external ones skipped — or a regulatory section with one vague sentence and no law named.
What the Document Looks Like
Below is an example of a Clause 4.1 context document for a small healthcare practice — Meridian Health Partners, 22 employees, one primary location, serving patients across the region.
Internal Issues
Structure and staffing: 14 employees across three practice areas — primary care, specialist referrals, and administrative operations. Technology is managed by the practice manager, with support from an external IT contractor. Information security responsibilities will be formally defined as part of the ISMS implementation.
Technology environment: Microsoft 365 (email, SharePoint, OneDrive, Teams), Electronic Health Records platform (EHR — cloud-hosted), local file server holding legacy patient records predating the EHR migration. Staff use a mix of firm-managed and personal devices. Remote access via Microsoft 365 and VPN. No mobile device management solution in place.
Resource constraints: No dedicated security budget. Security investments must compete with operational priorities. Implementation relies on the office administrator and external GRC consultant engagement.
External Issues
Regulatory obligations:
- HIPAA (Health Insurance Portability and Accountability Act) — Meridian Health Partners is a covered entity. Requires administrative, physical, and technical safeguards to protect PHI. Breach notification obligations apply within 60 days of discovery.
- GDPR (General Data Protection Regulation) — Applies to any patient data belonging to EU residents. Requires lawful basis for processing, data subject rights, and breach notification within 72 hours.
- State breach notification laws — Vary by jurisdiction. Require notification to affected individuals and regulators within defined timeframes following a confirmed breach of personal information.
Market environment: Prospective patients and referral partners increasingly ask about data security practices before engaging a healthcare practice. A breach affecting patient records is a reputational event, not just a compliance one.
Threat environment: Phishing targeting healthcare organisations. Ransomware targeting practices with critical patient data and limited recovery capability. Insider risk from staff accessing patient records outside their clinical role. Unintentional PHI disclosure via unsecured email or personal devices.
Next in this series: Clause 4.2 — Interested Parties. Who needs to care about your security posture, what do they specifically require, and how does your ISMS address those requirements.
