The people controls are the smallest theme in Annex A — eight items, under a tenth of the 93. That smallness invites the judgement that they are easy, and they get deferred. The frequency of nonconformities here is not proportional to the count.
The reason is simple. What these controls require is not written procedure but surviving records: that training happened, that an undertaking was signed, that assets came back at exit. All of it should arise naturally from ordinary HR operations — but unless it is deliberately retained with the ISMS in mind, you arrive at audit doing the right thing and unable to prove it.
There is also one difficulty specific to small organisations: segregation of duties. When the same person owns finance, engineering, and IT, how do you explain the separation the standard expects? That is the second half of this article. 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 describe intent in our own words rather than quoting. Employment law takes precedence on labour matters. Design your actual practice on the standard and professional advice.
Five Clusters Cover the Eight
| Cluster | Roughly covers | What it is for | Main outputs |
|---|---|---|---|
| ① Entry | Screening, terms of employment | Admit people you can trust; put responsibility in the contract | Screening procedure and records, contract and undertaking clauses |
| ② During employment | Awareness, education, training; disciplinary process | Keep people knowing the rules you set | Annual training plan, attendance records, comprehension checks, disciplinary rules |
| ③ Exit | Responsibilities after termination or change | Ensure confidentiality survives departure | Exit checklist, asset return records, access revocation records |
| ④ Contractual promises | Confidentiality and NDAs | Make subject matter and duration explicit | NDA templates, confidentiality clauses in contractor agreements |
| ⑤ Where people work, and reporting | Remote working; reporting security events | Govern working away from the office; surface what people notice | Remote working policy, reporting routes and records |
Most of these outputs come from revising existing HR documents — employment rules, contracts, onboarding materials, exit checklists. You rarely need a new body of procedure; you need a security lens added to what exists.
Entry: Screening, and Putting It in the Contract
The requirement is screening proportionate to the sensitivity of the information the role will touch, and information security responsibilities stated as a condition of employment.
Many organisations over-engineer this. The standard does not demand uniform, intensive background investigation; it asks for what is reasonable given applicable law, ethics, and sensitivity. In most cases, the verification already customary in Japanese hiring — CV verification, document checks, references where appropriate — suffices.
What a healthcare company should reconsider is the treatment of roles with direct access to medical information: operations staff who enter customer production environments, engineers handling patient data during migration. Whether those roles deserve the same treatment as everyone else is worth deciding once, deliberately. If you differentiate, document the criterion so you can explain why.
Into the contract:
- Confidentiality of information learned through the role, and its scope
- Obligation to follow the company's security procedures
- Consequences of breach (linking to the disciplinary rules)
- Obligations that continue after employment ends, and for how long
Do not forget contractors, agency staff, and interns. A contractor touching medical information under an agreement with no confidentiality clause is a business risk before it is an audit finding.
During Employment: From "We Trained Them" to "We Can Prove It"
Two controls sit here — awareness/education/training, and the disciplinary process — and the weight is overwhelmingly on the first.
Staff must understand their security responsibilities, hold the competence their role requires, and maintain it. You plan training annually, deliver it, and keep records.
Auditors check three things:
| Checked | Insufficient | Sufficient |
|---|---|---|
| Did everyone take it? | "Delivered" with no attendance list | 100% status recorded against a named population |
| Does content match the role? | The same generic deck for everyone | Secure coding for engineers, privileged-operation cautions for operators |
| Did they understand it? | Material distributed | Test or comprehension-check results retained |
100% attendance is the hard part. Mid-year joiners, returns from long leave, contractors — one omission breaks it. Building training into the onboarding checklist so it runs with the HR joiner/leaver flow is the reliable design. See Designing Security Awareness Training.
On the disciplinary process, you usually do not need new rules. Confirm that the disciplinary provisions of your existing employment rules encompass security breaches and supplement them if not. What matters is that staff know discipline is possible. A track record is not required, and not desirable.
Exit: The Control That Pays Off Afterwards
Responsibilities that continue after employment ends or changes. Records here are easy to produce and easy to omit.
Build into the exit checklist:
- Return of issued assets (laptop, phone, keys, badge, removable media)
- Account deactivation — internal systems, cloud services, SaaS, shared external accounts
- Confirmation that privileged rights are removed
- Re-confirmation that confidentiality continues (exit undertaking)
- Records of rights transferred during handover
Item 2 is where it fails. In SaaS-heavy organisations, the accounts HR knows about and the accounts that exist diverge: GitHub, monitoring, BI, CRM, cloud consoles. Without a standing list of what to revoke, the next access review turns up accounts still alive six months later.
Internal moves fall under the same control, and moves leak more than departures: old rights stay, new rights are added, and someone quietly accumulates broad access. Run the same checklist on transfer.
See Reading the 34 Technological Controls and Access Rights Design and Privileged ID Management.
Remote Working and Event Reporting
Remote working
Positioned as its own control in the 2022 edition. For fully remote or hybrid organisations it functions as the substitute for much of the physical theme — a connection covered in Reading the 14 Physical Controls.
A workable policy covers:
- Conditions on where work happens (no screen visible to third parties; whether public spaces are permitted)
- Conditions on devices (company-issued only, or BYOD under conditions)
- Network conditions (requirements when using public Wi-Fi, VPN use)
- Printing and paper (whether home printing is allowed, and how disposal works)
- Preventing disclosure to family and housemates (screen lock, care with calls)
- Reporting procedure for lost or stolen devices
The decision a healthcare company must make explicitly is whether access to customer production environments containing medical information is permitted from home. If yes, state the device and connection conditions and make clear that operations are logged. If no, decide what happens in an emergency — otherwise the rule will be broken during the first serious incident.
Reporting information security events
The final control secures a route for staff to report what looks wrong. It pairs with incident management on the organizational side.
What works in practice is lowering the psychological barrier. If the only named destination is something like "the Information Security Committee," the person who just clicked a phishing link hesitates. Offer several routes — a dedicated Slack channel, a form, the line manager — and write down that reporting itself is never penalised. Early detection follows from that more than from process.
Keep the records. "Reports were made but nothing was recorded" becomes a finding alongside the incident management controls.
Explaining Segregation of Duties in a Small Team
Segregation of duties sits among the organizational controls but is effectively examined together with the people theme. Below about ten people, full separation is physically impossible. One engineer owning infrastructure and finance is unremarkable.
The right response is neither to claim separation you do not have, nor to dismiss the control as inapplicable. The answer the standard supports is explaining the compensating controls that mitigate it.
| Where separation fails | Example compensating control |
|---|---|
| Developers can reach production | A different person approves production operations; a third party reviews operation logs periodically |
| The same person issues and uses privileged IDs | Management reviews issuance records monthly; privileged operations are time-bounded |
| Internal auditors must audit their own area | Engage external internal auditors |
| The same person raises and approves payments | Executive approval mandatory above a threshold |
The principle is build a structure where someone else looks afterwards. If you cannot separate before the fact, substitute review after it — and record the review. With that in place, being small is not a nonconformity.
See ISMS in Small Organisations and Writing the Statement of Applicability.
Conclusion
- The people theme is the smallest at eight controls, yet fails most often on records
- Most outputs come from revising existing employment rules, contracts, and joiner/leaver flows
- Screening should be proportionate to sensitivity, not uniformly severe; consider separate treatment for roles touching medical data directly
- Training must prove everyone, role-appropriate content, and understanding — not merely delivery
- Revocation at exit and transfer fails on forgotten SaaS accounts; build the revocation list first
- Remote working policy must settle whether customer production access from home is permitted
- Where separation is impossible, explain after-the-fact review as a compensating control; small size is not a nonconformity
Pottech supports ISMS certification with a focus on healthcare. The people controls hinge on connecting to how HR already works. We supply training material and attendance tracking, exit and transfer checklists, and undertaking templates, and fit them into your existing flow.
See ISMS Certification Support for scope and pricing, or contact us.
See also What Is an ISMS? A Complete Guide for Healthcare Companies and Reading the 37 Organizational Controls.
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
- Telework Security Guidelines | MIC
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: labour law governs employment matters. Interpretation of controls can change with revisions to the standard and the practices of certification bodies.