Annex A People and Physical Controls Guide Template (ISO/IEC 27001 A.6, A.7)

Annex A People and Physical Controls Guide: [Organization name]

A study and working guide to the 8 people controls (A.6.1 to A.6.8) and the 14 physical controls (A.7.1 to A.7.14) in Annex A of ISO/IEC 27001:2022 + Amd 1:2024, with control guidance in ISO/IEC 27002:2022 as the companion reference. For each control it explains, in original wording, what the control is for, how organisations of different sizes typically implement it, which records an auditor usually samples, the most common pitfalls, and which template in this library puts it to work. Use it to train HR, facilities and IT owners, to prepare Statement of Applicability decisions (clause 6.1.3 d) and to get ready for internal and certification audits. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and how to use this guide
2. The people lifecycle and its controls
3. People controls (A.6.1 to A.6.8)
4. Deciding your physical boundary
5. Perimeters, entry, rooms and monitoring (A.7.1 to A.7.4)
6. Environmental threats, secure areas and clear desk (A.7.5 to A.7.7)
7. Equipment, off-site assets and media (A.7.8 to A.7.10)
8. Utilities, cabling and maintenance (A.7.11 to A.7.13)
9. Disposal and re-use of equipment (A.7.14)
10. Size tiers: how the themes scale
11. Self-check questions
12. Records and evidence
13. Study record
14. References

1. Purpose and how to use this guide

The people theme (8 controls) and the physical theme (14 controls) are the two smaller Annex A themes, but they reach parts of the organisation that the security team does not run day to day. HR runs screening, contracts, disciplinary matters and leavers. Facilities runs buildings, access badges, alarms and utilities. IT operations runs laptops, storage media and equipment disposal. This guide gives each of them a short, practical explanation of what their controls are for and what an auditor will ask to see.

Each control entry has the same six parts: intent (in this library's own words), typical implementation, how it differs by tier, evidence an auditor usually samples, common pitfalls, and the templates that put it to work. The labels next to each control number are short descriptive labels used across this library, not the official titles. The official wording is in ISO/IEC 27001:2022 Annex A, and the implementation guidance is in ISO/IEC 27002:2022.

Use the guide in three ways: as induction reading for owners, as a workshop pack when the team decides applicability in compliance/statement-of-applicability (DOC-ISMS-011), and as a pre-audit check against isms/control-evidence-matrix (DOC-ISMS-033).

2. The people lifecycle and its controls

The eight people controls follow a person through their working life with the organisation. They apply to employees and, where relevant, to contractors and other people doing work under the organisation's control.

The diagram is a simplification: training (A.6.3) repeats every year, reporting (A.6.8) applies at any time, and the disciplinary process (A.6.4) is used only when a breach occurs. The leaving stage connects to the organizational controls for return of assets (A.5.11) and removal of access (A.5.18), covered in isms/annex-a-organizational-controls-guide.

3. People controls (A.6.1 to A.6.8)

A.6.1 Pre-employment screening

• Intent: Hiring someone gives them trust and access. Checking that candidates are who they claim to be and have the background they describe reduces the chance of placing a dishonest or unsuitable person in a sensitive position, as far as local law and fairness allow.
• Typical implementation: A screening procedure with checks per role category (identity, right to work, references, qualifications, and criminal or credit checks only where lawful and justified), records of completion, and equivalent requirements for contractors through their employer.
• By tier: Small: identity, references and qualification checks for everyone. Medium: enhanced checks for privileged and finance roles. Large: a screening matrix per country that reflects each jurisdiction's limits.
• Evidence an auditor samples: Procedure, screening completion records for a sample of recent joiners (outcome only), contractor agreements with screening clauses.
• Common pitfalls: Starting people before checks finish with no recorded risk decision, and applying checks that local law does not permit.
• Templates: isms/personnel-screening-procedure (DOC-ISMS-050).

A.6.2 Security terms in employment contracts

• Intent: People should know from day one that protecting information is a condition of working for the organisation. Putting this into the contract gives both sides clarity and gives the organisation a basis to act if the commitment is broken.
• Typical implementation: Clauses in employment contracts and contractor agreements covering confidentiality, acceptable use, intellectual property, return of assets and duties after leaving, with references to the policies.
• By tier: Small: one standard clause set. Medium: clause set per contract type. Large: country contract templates reviewed by local legal counsel.
• Evidence an auditor samples: Contract templates, signed contracts for a sample of staff, contractor agreements.
• Common pitfalls: Old contracts signed before the ISMS with no security terms, and no addendum to fix them.
• Templates: isms/confidentiality-nda (DOC-ISMS-051), compliance/acceptable-use-policy (DOC-ISMS-040), isms/employee-security-handbook (DOC-ISMS-073).

A.6.3 Awareness, education and training

• Intent: Most incidents involve a human step: a click, a misdirected e-mail, a reused password. Building the knowledge and habits people need to recognise risks and to know what their role expects of them turns staff into a line of defence rather than a weak point.
• Typical implementation: Induction training, yearly refresher, phishing simulations, role-based training for developers, administrators and managers, and completion tracking.
• By tier: Small: an online course and quarterly phishing tests. Medium: role tracks and a security champions network. Large: a programme with local languages, plant floor briefings for OT staff and metrics per site.
• Evidence an auditor samples: Training plan, completion records, phishing results with follow-up, role training for privileged staff.
• Common pitfalls: Counting completions without checking whether behaviour changes, and forgetting contractors.
• Templates: security/security-awareness-program, isms/phishing-simulation-plan (DOC-ISMS-074), isms/isms-competence-training-matrix (DOC-ISMS-026), isms/employee-security-handbook (DOC-ISMS-073).

A.6.4 Disciplinary process

• Intent: Rules that carry no consequences are treated as suggestions. A known, fair way of handling deliberate or reckless breaches deters misconduct, while protecting people who make honest mistakes and report them.
• Typical implementation: A disciplinary process that covers security breaches, distinguishes honest mistakes from wilful misconduct, and links to incident handling and evidence rules.
• By tier: Small: security breaches named in the general HR disciplinary policy. Medium: a defined process agreed with HR and legal. Large: country processes reflecting labour law and works council agreements.
• Evidence an auditor samples: The process, proof it was communicated, anonymised case counts.
• Common pitfalls: Punishing people who report their own mistakes, which stops reporting under A.6.8.
• Templates: isms/security-disciplinary-process (DOC-ISMS-052).

A.6.5 Duties after leaving or changing role

• Intent: Knowledge does not leave the building when a person does. The aim is that people who leave or move on understand which obligations, such as confidentiality, still bind them, and that the organisation can rely on those obligations afterwards.
• Typical implementation: Exit reminders of continuing confidentiality, signed exit forms, access changes on role change, and contract clauses that survive termination.
• By tier: Small: exit checklist with a reminder letter. Medium: HR workflow for movers as well as leavers. Large: automated mover workflows across systems and sites.
• Evidence an auditor samples: Signed exit forms or reminders, mover tickets showing old access removed.
• Common pitfalls: Handling leavers but not movers, so people keep access from previous roles.
• Templates: isms/offboarding-security-checklist (DOC-ISMS-053), isms/confidentiality-nda (DOC-ISMS-051).

A.6.6 Confidentiality agreements

• Intent: Sensitive information often has to be shared with people outside the employment relationship, and sometimes within it. Signed agreements make the duty of confidentiality explicit and enforceable, and keeping their wording current ensures they still cover what needs protecting.
• Typical implementation: Standard agreements for staff, contractors, visitors with access to sensitive areas and business partners, with a register and a periodic review of the wording.
• By tier: Small: one mutual and one one-way template. Medium: a register of signed agreements. Large: templates per jurisdiction.
• Evidence an auditor samples: Templates, signed agreements for a sample, review record.
• Common pitfalls: Agreements never reviewed when the information or the law changes.
• Templates: isms/confidentiality-nda (DOC-ISMS-051).

A.6.7 Remote working

• Intent: Home offices, trains and hotel rooms lack the protections of a managed office. This control makes sure work done away from the premises does not become the easiest route to the organisation's information.
• Typical implementation: A remote working policy covering devices, home network, screen privacy, printing, travel and public spaces, supported by managed devices and secure access.
• By tier: Small: policy plus managed laptops with disk encryption. Medium: device compliance checks before access. Large: policy variants for country rules and for high-risk travel.
• Evidence an auditor samples: Policy acknowledgements, device compliance reports, access configuration.
• Common pitfalls: A policy written for occasional home working in an organisation that is now remote first.
• Templates: isms/remote-working-policy (DOC-ISMS-054), isms/endpoint-device-byod-policy (DOC-ISMS-058).

A.6.8 Reporting security events

• Intent: Staff often notice problems first: a strange e-mail, a lost laptop, an unlocked screen. The aim is that they know how to raise it, feel safe doing so, and that the report reaches someone who can act before the damage grows.
• Typical implementation: One reporting channel (form, mailbox, button in the mail client, phone number), clear examples of what to report, quick acknowledgement, and no blame for good-faith reports.
• By tier: Small: one mailbox and a chat channel. Medium: a reporting button and a service desk category. Large: channels per site and language, linked to the security operations centre.
• Evidence an auditor samples: Reports received, time to acknowledge, channel test results, awareness material.
• Common pitfalls: A channel that exists but nobody remembers, or reports that disappear without feedback.
• Templates: isms/security-event-reporting-procedure (DOC-ISMS-023), isms/phishing-simulation-plan (DOC-ISMS-074).

4. Deciding your physical boundary

Physical controls apply wherever information and equipment are, but who runs them differs. Before you decide applicability, list every place where in-scope information is handled and record who operates it:

A cloud-hosted organisation rarely excludes A.7 controls outright. It applies them to its offices and to home working, and treats data centre security as a supplier matter. Record this reasoning in the SoA justification column rather than marking controls "not applicable" without explanation.

5. Perimeters, entry, rooms and monitoring (A.7.1 to A.7.4)

A.7.1 Physical security perimeters

• Intent: Physical protection starts with knowing where the protected space begins. Drawing clear boundaries around areas that hold valuable information and equipment, and building them to a strength that fits the value inside, is what every other physical control relies on.
• Typical implementation: A site plan that marks public, general and secure zones, with walls, doors and windows of suitable strength and alarms on perimeter openings where needed.
• By tier: Small: the office suite door and a locked equipment cupboard. Medium: zoned offices and a separate secure room. Large: fenced plant perimeters, gatehouses and zoned buildings.
• Evidence an auditor samples: Site plan with zones, perimeter inspection record, site walk-through.
• Common pitfalls: No defined zones, so nobody can say where the secure area starts.
• Templates: isms/physical-security-policy (DOC-ISMS-055).

A.7.2 Physical entry controls

• Intent: A strong wall is useless if anyone can walk through the door. The purpose is that only people with a reason to be there can enter protected areas, and that visitors, deliveries and contractors are handled without opening a gap.
• Typical implementation: Badge or key access by zone, visitor registration and escort, delivery areas separated from secure areas, and periodic review of who holds access.
• By tier: Small: key or badge register and a visitor book. Medium: electronic badges with quarterly access list review. Large: central badge system across sites with gate controls.
• Evidence an auditor samples: Badge access lists and their reviews, visitor logs, key register.
• Common pitfalls: Badges of leavers still active, and delivery doors propped open.
• Templates: isms/physical-security-policy (DOC-ISMS-055), isms/offboarding-security-checklist (DOC-ISMS-053).

A.7.3 Securing offices, rooms and facilities

• Intent: Inside the perimeter, rooms differ in what they hold. This control matches the protection of each office, meeting room or equipment room to its contents, so a sensitive room is not left as open as the kitchen.
• Typical implementation: Locks on rooms holding sensitive equipment or records, no external signs that reveal sensitive functions, screens and whiteboards not visible from outside.
• By tier: Small: locked equipment cupboard and filing cabinets. Medium: a secure room for network equipment and HR records. Large: graded protection per room type at each site.
• Evidence an auditor samples: Room access design, lock and key register, observation on site.
• Common pitfalls: A server room also used as a store room with wide access.
• Templates: isms/physical-security-policy (DOC-ISMS-055).

A.7.4 Physical security monitoring (new in 2022)

• Intent: Locks and badges can be bypassed, propped open or tailgated. Monitoring gives the organisation a way to notice an intrusion while it happens or soon after, and to respond, rather than discovering it weeks later.
• Typical implementation: Intruder alarms, CCTV where lawful and proportionate, badge event alerts, guard patrols, all linked to a response and to incident handling, with a retention period for footage.
• By tier: Small: alarm with monitoring service, landlord CCTV in common areas. Medium: CCTV at entrances and the secure room with a set retention. Large: site security control room and central monitoring across sites.
• Evidence an auditor samples: Alarm test records, CCTV retention check, response to the last alarm.
• Common pitfalls: Cameras nobody reviews, or footage kept longer than its purpose needs, which creates a privacy issue.
• Templates: isms/physical-security-policy (DOC-ISMS-055), isms/data-centre-colocation-assessment (DOC-ISMS-079).

6. Environmental threats, secure areas and clear desk (A.7.5 to A.7.7)

A.7.5 Protection against physical and environmental threats

• Intent: Fire, flood, storms, accidents and deliberate damage can destroy facilities as surely as a cyberattack. The purpose is to understand which of these hazards are realistic for each site and to reduce their likelihood and impact before they occur.
• Typical implementation: A site threat assessment (fire, flood, storm, earthquake where relevant, civil unrest, vehicle impact), fire detection and suppression, water detection, and siting away from known hazards.
• By tier: Small: landlord fire systems and a short threat note. Medium: assessment per site plus provider assurance for the colocation suite. Large: engineering assessments per plant, aligned with safety and business continuity.
• Evidence an auditor samples: Threat assessment, fire system inspection records, provider reports.
• Common pitfalls: No assessment for a site in a known flood zone, or relying on the landlord without seeing any evidence.
• Templates: isms/physical-security-policy (DOC-ISMS-055), compliance/business-impact-analysis (DOC-ISMS-120).

A.7.6 Working in secure areas

• Intent: A secure room is only as secure as the behaviour of the people inside it. Rules for those who work in or visit such areas keep their protection from being undermined by convenience or carelessness.
• Typical implementation: Rules on who may enter, supervision of third parties, no unsupervised lone working where risky, no photography or recording devices unless allowed, and empty secure areas locked and checked.
• By tier: Small: rules posted at the equipment cupboard. Medium: secure room rules with an access log. Large: secure area rules per site, including OT control rooms.
• Evidence an auditor samples: Secure area rules, access log reviews, contractor supervision records.
• Common pitfalls: Maintenance contractors left alone in secure areas.
• Templates: isms/physical-security-policy (DOC-ISMS-055).

A.7.7 Clear desk and clear screen

• Intent: Papers left on a desk, a USB stick by a keyboard or an unlocked screen can be read by cleaners, visitors or passers-by. This control builds the habit of putting information away and locking screens whenever a workspace is left.
• Typical implementation: Clear desk and clear screen rules, automatic screen lock, lockable storage, secure printing, confidential waste bins, and periodic spot checks.
• By tier: Small: rules plus screen lock enforced through device management. Medium: quarterly spot checks. Large: spot checks per site with results reported to the site manager.
• Evidence an auditor samples: Spot-check results, screen lock settings, observation during the site walk.
• Common pitfalls: Rules applied in the office but not in home offices or meeting rooms with whiteboards.
• Templates: isms/clear-desk-clear-screen-policy (DOC-ISMS-056).

7. Equipment, off-site assets and media (A.7.8 to A.7.10)

A.7.8 Equipment siting and protection

• Intent: Where equipment is placed affects how easily it can be damaged, stolen or overlooked. Thoughtful placement, with extra protection where placement alone is not enough, keeps equipment safe from both hazards and prying eyes.
• Typical implementation: Racks and network equipment in locked rooms, screens positioned away from windows, equipment protected from heat, dust and water, and rules for eating and drinking near equipment.
• By tier: Small: locked cupboard for network gear. Medium: equipment room with environmental monitoring. Large: data centre and plant control rooms with environmental controls.
• Evidence an auditor samples: Equipment room inspection, rack inventory, environmental alerts.
• Common pitfalls: Network equipment in an open corridor or under a kitchen.
• Templates: isms/physical-security-policy (DOC-ISMS-055).

A.7.9 Assets used off-premises

• Intent: Laptops, phones and papers that leave the premises lose the building's protection and are lost or stolen far more often. The aim is that information on them stays safe wherever they travel.
• Typical implementation: Encrypted and managed laptops and phones, rules for travel and public places, approval for taking equipment off site where needed, and a process for reporting loss or theft.
• By tier: Small: full-disk encryption and remote wipe on all laptops. Medium: tracking of devices issued for off-site use. Large: rules for high-risk travel and for equipment shipped between sites.
• Evidence an auditor samples: Encryption and device management reports, loss reports and response.
• Common pitfalls: Personal devices used for work with no controls, outside any policy.
• Templates: isms/endpoint-device-byod-policy (DOC-ISMS-058), isms/remote-working-policy (DOC-ISMS-054).

A.7.10 Storage media

• Intent: Removable drives, tapes and paper copies are easy to lose and hard to track. Controlling them from purchase to destruction, with care matched to the sensitivity of what they hold, prevents quiet leaks through forgotten media.
• Typical implementation: Removable media blocked or restricted by default, encryption where allowed, a media register for approved devices, secure transport rules and secure destruction.
• By tier: Small: USB storage blocked on managed laptops. Medium: approved encrypted devices with a register. Large: media control per site, including media used for OT maintenance.
• Evidence an auditor samples: Device control settings, media register, destruction certificates.
• Common pitfalls: OT engineers using unmanaged USB sticks to move files to control systems.
• Templates: isms/information-labelling-handling-procedure (DOC-ISMS-042), isms/equipment-disposal-reuse-record (DOC-ISMS-057).

8. Utilities, cabling and maintenance (A.7.11 to A.7.13)

A.7.11 Supporting utilities

• Intent: Systems stop when power, cooling or connectivity fail, and some failures also corrupt data. The purpose is to keep equipment running, or to shut it down safely, when the services it depends on are disrupted.
• Typical implementation: Uninterruptible power supply, generator where justified, redundant network links, environmental monitoring, regular testing, and provider assurance for hosted sites.
• By tier: Small: small UPS for office network gear, cloud provider assurance for production. Medium: colocation provider reports plus office UPS. Large: generators and dual feeds at the data centre and plants, tested on a schedule.
• Evidence an auditor samples: UPS and generator test records, provider reports, utility failure incidents.
• Common pitfalls: A generator never tested under load.
• Templates: isms/physical-security-policy (DOC-ISMS-055), isms/data-centre-colocation-assessment (DOC-ISMS-079).

A.7.12 Cabling security

• Intent: Cables can be tapped, cut, damaged by building works or disturbed by electrical interference. Protecting and routing them carefully preserves both the confidentiality and the availability of what they carry.
• Typical implementation: Cables in conduits or ceilings, locked patch cabinets, labelled cabling, separation of power and data cables, and inspection of exposed runs.
• By tier: Small: landlord-managed cabling and a locked patch panel. Medium: inspection record for the secure room. Large: cabling standards per site, including plant floor and OT networks.
• Evidence an auditor samples: Cabling inspection record, cabinet lock check, observation.
• Common pitfalls: Network ports in public areas that are live and connected to the internal network.
• Templates: isms/physical-security-policy (DOC-ISMS-055), isms/network-security-standard (DOC-ISMS-063).

A.7.13 Equipment maintenance

• Intent: Neglected equipment fails, and careless servicing can expose the data on it. The aim is that equipment is looked after properly by trustworthy people, so it stays reliable and information is not exposed when hardware is repaired.
• Typical implementation: Maintenance per manufacturer guidance, authorised maintenance staff only, logs of faults and repairs, and rules for equipment sent off site for repair (remove or protect data first).
• By tier: Small: warranty and replacement for laptops. Medium: maintenance contracts for office and colocation equipment. Large: planned maintenance systems per site, including OT equipment.
• Evidence an auditor samples: Maintenance logs and contracts, records of data removed before repair.
• Common pitfalls: Laptops sent for repair with unencrypted disks still inside.
• Templates: isms/physical-security-policy (DOC-ISMS-055), isms/equipment-disposal-reuse-record (DOC-ISMS-057).

9. Disposal and re-use of equipment (A.7.14)

A.7.14 Secure disposal or re-use of equipment

• Intent: Discarded or reissued devices often still hold readable data and licensed software. The purpose is to make sure nothing sensitive leaves the organisation, or passes to the next user, on equipment that is sold, recycled, returned or reassigned.
• Typical implementation: A disposal and reuse procedure with approved wiping or destruction methods per media type, a record per device, certificates from disposal providers, and verification of a sample.
• By tier: Small: cryptographic erase of encrypted laptops and a provider certificate for destroyed items. Medium: a disposal record for every device. Large: disposal procedures per site with an approved provider list and audit of the provider.
• Evidence an auditor samples: Disposal and reuse records matched to the asset inventory, wipe reports, destruction certificates.
• Common pitfalls: Printers, copiers and network devices with internal storage disposed of without wiping.
• Templates: isms/equipment-disposal-reuse-record (DOC-ISMS-057), data/data-retention-deletion-standard.

10. Size tiers: how the themes scale

The controls are the same for every organisation. What changes with size is how many sites you run yourself, how formal HR processes are, and how much depends on providers. All rows are Example.

Practical advice per tier:

• Small. Spend physical effort on the office, laptops and home working, and document how provider assurance covers the data centres. Keep HR evidence light but complete: one joiner and one leaver must trace end to end.
• Medium. Visit the colocation suite, or review the provider's assurance report and your own cage controls, at least yearly. Make movers a formal HR event so A.6.5 works.
• Large or multi-site. Decide which physical controls are group standards and which are site procedures. Coordinate with safety and OT engineering, who often already run access and monitoring at plants.

11. Self-check questions

1. Which people controls would an auditor test by tracing one joiner and one leaver, and what record would they ask for at each stage?
2. Why can screening (A.6.1) differ between countries, and how do you record that difference?
3. How can a disciplinary process (A.6.4) harm event reporting (A.6.8), and how do you prevent that?
4. What is the difference between A.6.5 and the return of assets in A.5.11?
5. A company runs all production in public cloud. Which A.7 controls still apply to its own premises and people?
6. What does A.7.4 add that A.7.2 does not already cover?
7. Name three items with internal storage that are often forgotten under A.7.14.
8. How would you show an auditor that a colocation provider's utilities are protected (A.7.11)?
9. Why is a blanket "not applicable" for physical controls a common finding in cloud-first organisations?
10. What evidence shows that clear desk rules (A.7.7) work, not just exist?

12. Records and evidence

This guide produces learning records and local annotations. The records that prove each people or physical control operates are tracked in isms/control-evidence-matrix (DOC-ISMS-033); the most common ones are listed here so owners know what to keep.

13. Study record

Copy completed entries into isms/isms-competence-training-matrix (DOC-ISMS-026) so competence evidence sits in one place.

14. References

Related templates: isms/isms-learning-path, isms/isms-glossary, isms/annex-a-organizational-controls-guide, isms/annex-a-technological-controls-guide, isms/isms-self-test, compliance/statement-of-applicability, isms/control-evidence-matrix, isms/physical-security-policy, isms/personnel-screening-procedure, isms/remote-working-policy.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A (controls A.6.1 to A.6.8 and A.7.1 to A.7.14) and with the control guidance in ISO/IEC 27002:2022. The intents, implementation notes, tier advice, boundary decision, pitfalls and questions are original text written for this library. No ISO or IEC control text, guidance, official titles, tables or definitions are reproduced; the labels next to control numbers are short descriptive labels, and you need the official standards, sold by ISO, IEC and national standards bodies, to implement the controls. Editions change: check the current edition of each standard on iso.org before you rely on this guide. Screening, monitoring and disciplinary measures are subject to local law: this is a documentation format, not legal advice. This guide does not promise certification, which is decided by an accredited certification body. Template licence: MIT.