The organizational controls are the largest of Annex A's four themes, at 37 items — roughly 40% of the 93, and the centre of gravity of an ISMS project. They are also the set that can only be satisfied with documents and operating practice, never with a product. Leave them late and you will mass-produce procedures in the weeks before audit, ending up with a stack of paper that does not match how you work.
Equally, reading all 37 one by one and filling in a mapping table is not the way. The controls are not 37 independent tasks; they cluster, and each cluster has a fairly predictable output. Grouped, the 37 converge on about eight document sets.
This article groups A.5 into eight clusters: what each asks for, what you produce, and where it bites for a healthcare business. For the overall map see Annex A 2022: 93 Controls Across Four Themes.
Disclaimer: This article is general information. Control titles and requirement text live in the standard. We do not quote them; we describe the intent in our own words. Base decisions on ISO/IEC 27001 (JIS Q 27001) and the publications of the accreditation and certification bodies.
Eight Clusters Cover the 37
| Cluster | What it is for | Main outputs |
|---|---|---|
| ① Policy and governance | Fix who decides what, and who is accountable | Security policy, subordinate procedures, org chart, role assignments |
| ② Assets and classification | Identify what must be protected and how it is handled by sensitivity | Asset register, classification and labelling rules, acceptable use, return of assets |
| ③ Access policy | Define, at policy level, who may access what | Access control policy, identity lifecycle, provisioning and review records |
| ④ Suppliers and cloud | Secure the parts you have handed to others | Supplier management procedure, assessment sheets, contract clauses, supplier list |
| ⑤ Threat intelligence and external contacts | Keep taking in what is happening outside | Intelligence collection routine, contact list, memberships |
| ⑥ Incident management | Do not stop when something happens, and learn from it | Response plan, reporting flow, evidence handling, incident log |
| ⑦ Continuity | Keep the business running, seen from security | BCP, ICT continuity requirements and test records, recovery objectives |
| ⑧ Compliance and review | Identify external obligations and verify you meet them | Legal and contractual register, records protection, independent review records |
Get those eight document sets right and A.5 is substantially covered. Put differently: you do not need 37 documents for 37 controls. The relationship is many-to-many, and one procedure routinely satisfies five or six controls.
The Foundations: Policy, Assets, Access
① Policy and governance
What is required is that the organisation's security decisions exist as approved documents, and that responsibility for them is assigned. That runs through policy, the relationship to subordinate procedures, periodic review, role allocation, and segregation of duties.
In practice you build a top-level information security policy with a set of procedures beneath it. What matters is not how many documents there are but that they match reality. Take a template as-is and you end up asserting that you retain entry logs for an office you do not have.
Segregation of duties gets hard in small teams; that is covered in Reading the 8 People Controls.
② Assets and classification
This cluster converges on one artefact: the information asset register. You identify the information and facilities to protect, assign an owner to each, classify by sensitivity, and define handling rules for that classification — storage, transfer, removal, return.
For healthcare the leverage is in the classification design. Treating every patient-derived record as top secret paralyses test data use in development and over-restricts aggregated anonymised data. At minimum, separate:
- Identifiable medical information (including special-care-required personal information)
- Pseudonymised and anonymised medical information
- Customer (hospital) operational and configuration data
- Your own commercial and technical information
- Public information
See Building the Information Asset Register.
③ Access policy
The access-related controls in A.5 are policy level. Implementation — privileged IDs, MFA, endpoint control — lives in A.8. Here the standard wants the need-to-know principle, the identity lifecycle (issue, change, revoke), management of authentication information, and periodic review of rights.
Auditors press hardest on that last point. Provisioning records exist; review records do not. Leaver accounts still active, and rights retained after an internal move, are perennial nonconformities. Quarterly is enough — but the review must leave a record, and that should be built in from the start.
See Reading the 34 Technological Controls and Access Rights Design and Privileged ID Management.
External Relationships: Suppliers, Cloud, Threat Intelligence
④ Suppliers and cloud services
The 2022 edition makes use of cloud services an explicit control — a change that lands directly on healthcare SaaS. If you deliver on cloud, your IaaS/PaaS providers are suppliers, and their selection, contracting, monitoring, and exit all fall in scope.
The flow required is roughly:
- Set a policy for entrusting information to suppliers
- Write security requirements into contracts
- Extend visibility into the ICT supply chain — your suppliers' suppliers
- Monitor and review supplier service delivery over time
- Define procedures for change and termination
Step 3 is where healthcare companies struggle. To a hospital, you are the supplier and your cloud is a sub-processor. Hospitals working to the three-ministry guidelines will ask about that layer, so a single diagram showing who manages what pays for itself in sales conversations.
See Shared Responsibility in AI EMR Security Design, Cloud Security for Medical Institutions, and Supplier Security Management.
⑤ Threat intelligence and external contacts
Threat intelligence was added in 2022. It does not mean buying a feed. It means taking in threat information relevant to you, continuously, and using it in decisions.
For a small organisation, this is enough to operate:
- Subscribe to JPCERT/CC and IPA advisories; a named person reviews them weekly
- Subscribe to advisories for the cloud services and open-source components you use
- Record what was reviewed and whether action was required
The record is the point. "We keep an eye on it" does not survive audit. A one-page monthly "threats seen and action taken" note satisfies this control and feeds continuity and incident management at the same time.
For contact with authorities, a list of who you notify — regulator, JPCERT/CC, the Personal Information Protection Commission, your hospital customers — is sufficient. The intent is that you are not looking it up mid-incident.
When It Happens, and What You Must Comply With
⑥ Incident management
Five to six controls cluster here, making it the densest part of A.5. The required flow is plan → report → assess and classify → respond → learn → collect evidence. Assessment/classification and learning are the ones most often missing.
| Stage | Requirement | Output |
|---|---|---|
| Plan | Roles, escalation paths, decision criteria agreed in advance | Response plan, contact tree |
| Report | Staff have a route to report events | Reporting form and procedure |
| Assess and classify | Event or incident? How is severity set? | Classification criteria, triage sheet |
| Respond | Contain and recover by the agreed procedure | Response records, customer and regulator notifications |
| Learn | Feed back into prevention | Post-incident review, corrective action reports |
| Evidence | Preserve in a form that survives legal process | Evidence handling procedure and records |
For medical information, notification timing and content are usually fixed by contract with the hospital, so those terms belong in the plan. Committing to a first report within four hours while the internal contact tree does not function at night or on holidays is a design failure that genuinely happens.
See Building an Incident Response Procedure and Incident Response Plans for Hospitals.
⑦ Continuity
This covers business continuity seen through security, plus ICT continuity — recovery objectives, redundancy, testing. The key point: if you already have a BCP, reference it rather than writing a new one for the ISMS.
For healthcare SaaS, what gets tested is whether recovery objectives are real. Declaring a four-hour RTO while never having restored from backup is a nonconformity. Run a recovery test once a year and keep the record — it also doubles as sales evidence for hospitals. See Connecting BCP and ISMS.
⑧ Compliance and review
The final cluster: identifying legal, regulatory, and contractual requirements; intellectual property; protection of records; privacy; independent review of information security; and verifying conformance with your own policies and procedures.
A healthcare company's register of external obligations is longer than most: the personal information law and its special-care category, requirements around the Medical Care Act and Medical Practitioners Act, the Next-Generation Medical Infrastructure Act where relevant, the PMD Act for SaMD, and contractual commitments to the three-ministry guidelines. The practical work is a table mapping each obligation to the internal procedure that addresses it.
Independent review is largely satisfied by internal audit, provided auditors do not audit their own work — which is why external auditors are a realistic answer for small teams.
Conclusion
- The 37 controls group into eight clusters producing about eight document sets — not 37 documents
- The foundations are policy, asset register, access policy; everything above them wobbles if these do
- Do not classify all medical information as top secret — separating pseudonymised and anonymised data lightens operations
- The explicit cloud services control means producing a diagram that reaches your sub-processors
- Threat intelligence must leave a one-page monthly record, not a claim of vigilance
- Incident management loses "assess and classify" and "learn"; derive notification terms from your contracts
- Access review records, recovery test records, independent review records — a control with no record looks like a control you do not operate
Pottech supports ISMS certification with a focus on healthcare. Organizational controls carry the heaviest documentation load, but we supply templates for procedures, registers, and assessment sheets and tailor them to how your business actually works. We can also act as your internal audit manager and auditors, satisfying the independent review requirement.
See ISMS Certification Support for scope and pricing, or contact us.
See also What Is an ISMS? A Complete Guide for Healthcare Companies and Writing the Statement of Applicability.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- ISO/IEC 27002 Information security controls | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Security Alerts | JPCERT Coordination Center
- Personal Information Protection Commission
Note: interpretation of controls and the acceptability of exclusions can change with revisions to the standard and the practices of certification bodies.