# 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*.

<!--
Guidance: How to use this template
- Use it when you onboard HR, facilities or IT staff who own people or
  physical controls, when you decide applicability for a remote-first or
  cloud-hosted organisation, and before an internal audit of these two
  themes.
- Fill the Document control table first, then section 4 (where your
  physical boundary actually is) because it decides how many A.7 controls
  you run yourself and how many you rely on providers for. Then add local
  notes per control and keep the study record in section 13.
- Main pitfall: excluding physical controls because "everything is in the
  cloud". Offices, home workplaces, laptops, paper and storage media remain
  in scope. For hosted facilities, the control is met through supplier
  assurance, not removed.
- This guide gives control numbers with short labels written for this
  library. It does not reproduce the control text or the ISO/IEC 27002
  guidance. Buy the official standards to implement the controls.
- Related templates: `isms/isms-learning-path`, `isms/annex-a-organizational-controls-guide`,
  `isms/annex-a-technological-controls-guide`, `isms/physical-security-policy`,
  `isms/personnel-screening-procedure`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Once the guide is used for briefings or as competence evidence (clause 7.2), keep it under document control (clause 7.5) so readers know which edition it reflects and who approved the local notes. -->

| Field | Value |
|---|---|
| Document ID | LRN-ISMS-05 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@hr-lead], [@facilities-lead], [@ciso] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 Annex A (A.6.1 to A.6.8, A.7.1 to A.7.14); ISO/IEC 27002:2022 |
| Controls covered | 22 (8 people, 14 physical) |
| Audience | [HR, facilities, IT operations, ISMS manager, internal auditors] |
| Sites in scope | [List of offices, data centres, plants, home working] |
| Linked SoA | DOC-ISMS-011, version [x.y] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| HR lead | [@hr-lead] | [Reviewed] | YYYY-MM-DD |
| CISO or security lead | [@ciso] | [Approved / Approved with changes] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-11-01 | [@isms-manager] | First guide, aligned with ISO/IEC 27001:2022 + Amd 1:2024 |
| 1.1 *(Example)* | YYYY-MM-DD | [@isms-manager] | Physical boundary updated after office move |

## Contents

<!-- Guidance: Sections 1 to 3 cover the people theme. Sections 4 to 9 cover the physical theme, starting with the boundary decision. Sections 10 to 13 turn the guide into a working and learning record. -->

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

<!-- Guidance: Say who reads the guide and when. People controls are mostly run by HR and physical controls by facilities, so the guide is often their first contact with the ISMS. Pitfall: writing it for security specialists only. -->

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

<!-- Guidance: Show how the people controls follow a person from hiring to leaving. Auditors often sample one joiner and one leaver and trace them through every stage, so the stages must connect. -->

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.

```mermaid
flowchart LR
    S["A.6.1 Screening before joining"] --> C["A.6.2 Contract terms and A.6.6 NDA"]
    C --> T["A.6.3 Awareness and training"]
    T --> W["A.6.7 Remote working"]
    W --> R["A.6.8 Reporting events"]
    R --> D["A.6.4 Disciplinary process if needed"]
    W --> L["A.6.5 Duties after leaving or changing role"]
    D --> L
```

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)

<!-- Guidance: People controls depend on HR records that contain personal data. Agree with HR what the ISMS may see: an auditor can usually confirm that screening happened without reading the result. Auditor check: one joiner and one leaver traced end to end. -->

### 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

<!-- Guidance: Before reading the A.7 entries, decide which facilities you run yourself and which a provider runs. This decides whether each A.7 control is met by your own measures, by supplier assurance, or both. Auditor check: the scope document and SoA say the same thing about sites. -->

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:

| Place | Who operates the physical controls | How the A.7 controls are met |
|---|---|---|
| Own offices | The organisation | Own measures |
| Shared or serviced office | Landlord plus the organisation | Landlord contract and assurance plus own measures inside the leased area |
| Colocation suite | Provider for the building, the organisation for its cage or racks | Provider assurance plus own rack and access controls |
| Public cloud data centres | Cloud provider | Provider assurance reports, reviewed under A.5.19 to A.5.23 |
| Home and remote workplaces | The worker, under policy | Remote working policy (A.6.7), off-site asset rules (A.7.9), clear desk (A.7.7) |
| Plants and OT areas | The organisation | Own measures, often shared with safety and site security |

```mermaid
flowchart TD
    Q1{"Does the organisation operate the facility?"} -->|"Yes"| OWN["Own A.7 measures, evidence from facilities records"]
    Q1 -->|"No"| Q2{"Is it a provider facility under contract?"}
    Q2 -->|"Yes"| SUP["Supplier assurance under A.5.19 to A.5.22 plus own measures for areas you control"]
    Q2 -->|"No, home or travel"| REM["Remote working and off-site asset rules: A.6.7, A.7.9"]
```

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)

<!-- Guidance: These controls work as layers: perimeter, entry, rooms and monitoring (the rules for working inside secure areas, A.7.6, follow in section 6). Questions to answer: where are the boundaries, who can pass them, how do you know when someone gets in who should not? Auditor check: a walk-through of the site and a badge list review. -->

### 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)

<!-- Guidance: A.7.5 needs a short assessment of physical and environmental threats per site. A.7.6 sets behaviour rules inside the secure areas defined in section 5. A.7.7 is a behaviour control and is often the first thing an auditor notices on a walk-through. -->

### 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)

<!-- Guidance: These controls protect hardware and media wherever they are. Questions to answer: where is equipment sited, what leaves the premises, and how is removable media controlled through its life? Auditor check: laptop encryption report and the media register. -->

### 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)

<!-- Guidance: These controls protect availability. For hosted facilities they are met through provider assurance. For own sites they need test and inspection records. Auditor check: the last UPS or generator test and the maintenance log. -->

### 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)

<!-- Guidance: A.7.14 is one of the most frequently sampled physical controls. Auditor check: pick a disposed device from the inventory and ask for its wipe or destruction record. -->

### 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

<!-- Guidance: Show how the same controls look at different sizes, using the library's three fictional settings. The tiers are this library's working tiers (small under 50 people, medium 50 to 500, large over 500 or several sites), not official definitions. -->

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*.

| Aspect | Quillmere Analytics Ltd (small) *(Example)* | Quillmere Health Systems (medium) *(Example)* | Quillmere Group (large) *(Example)* |
|---|---|---|---|
| Profile | 46 staff (38 employees, 8 contractors), one office plus remote staff, production on one public cloud provider in two regions | 320 staff, two offices and one colocation suite | 2,400 staff, 6 sites in 4 countries (HQ, 3 plants, 1 service centre, 1 data centre), OT and IT |
| People controls owner | HR generalist with the part-time ISMS manager (0.5 FTE) | HR team with the full-time ISMS manager | HR per country, coordinated by group HR and the CISO's office |
| Screening | Same checks for all 46, contractors screened by their agencies under contract | Enhanced checks for privileged and clinical-data roles | Screening matrix per country |
| Training | Online course and quarterly phishing tests | Role tracks and security champions | Local-language programme, plant floor briefings for OT staff |
| Physical boundary | One office and home working, data centres covered by cloud provider assurance | Two offices plus own racks in a colocation suite | Own data centre, 3 plants, HQ and service centre, all run by the group |
| A.7 controls met through suppliers | Data centre aspects of A.7.1 to A.7.6, A.7.8, A.7.11 to A.7.13 for production | Building aspects at the colocation suite | Few; most are own measures |
| Typical evidence volume | A few records per quarter | Quarterly reviews per site | Site security reports every month, consolidated by the group |

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

<!-- Guidance: Use these questions after a study session, in an SoA workshop or before an audit interview. Record answers in the study record in section 13. -->

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

<!-- Guidance: List the records that show the guide is used and the themes are understood. Control evidence itself belongs in the control evidence matrix. Remember that HR records contain personal data: keep only what the ISMS needs. -->

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.

| Record | Owner | Where kept | Retention |
|---|---|---|---|
| Study record (section 13) | ISMS manager | [Learning platform or ISMS folder] | [Duration of employment plus 1 year] |
| Screening completion (outcome only) | HR lead | [HR system] | [Per HR retention schedule and local law] |
| Signed contracts and NDAs | HR lead, legal lead | [HR system, contract repository] | [Duration of relationship plus contractual limitation period] |
| Training completions and phishing results | HR lead | [Learning platform] | [3 years or one certification cycle] |
| Badge access reviews and visitor logs | Facilities lead | [Badge system, reception] | [Visitor logs per privacy rules, for example 12 months] |
| Alarm tests and CCTV retention checks | Facilities lead | [Facilities folder] | [3 years] |
| Disposal and reuse records, certificates | IT operations lead | `isms/equipment-disposal-reuse-record` (DOC-ISMS-057) | [Asset life plus 3 years] |
| Provider assurance reviews for hosted sites | Procurement or ISMS manager | `isms/data-centre-colocation-assessment` (DOC-ISMS-079) | [3 years] |

## 13. Study record

<!-- Guidance: Record who studied which sections and the result of the self-check. This supports competence evidence for HR, facilities and IT owners under clause 7.2 and feeds the competence matrix. -->

| ID | Learner | Role | Sections studied | Date completed | Self-check result | Reviewed by |
|---|---|---|---|---|---|---|
| LRN-A67-001 *(Example)* | [@hr-lead] | HR lead | 2, 3, 12 | 2027-02-10 | 4 of 4 people questions answered correctly | [@isms-manager] |
| LRN-A67-002 *(Example)* | [@facilities-lead] | Facilities lead | 4 to 9 | 2027-02-17 | 6 of 6 physical questions, follow-up on A.7.11 provider evidence | [@isms-manager] |
| LRN-A67-003 | [@learner] | [role] | [sections] | YYYY-MM-DD | [result] | [@reviewer] |

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

## 14. References

<!-- Guidance: Cite standards by number and edition. Buy the official documents: this guide paraphrases only. Check each edition on iso.org before relying on it. -->

| Standard | Edition | Link |
|---|---|---|
| ISO/IEC 27001 | 2022 + Amd 1:2024 | https://www.iso.org/standard/82875.html ; Amd 1: https://www.iso.org/standard/88435.html |
| ISO/IEC 27002 | 2022 | https://www.iso.org/standard/75652.html |
| ISO/IEC 27040 (storage security) | 2024 | https://www.iso.org/standard/80194.html |
| ISO 22301 (business continuity) | 2019 + Amd 1:2024 | https://www.iso.org/standard/75106.html |

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.