# Annex A Technological Controls Guide: [Organization name]

> A study and working guide to the 34 technological controls in Annex A
> of ISO/IEC 27001:2022 + Amd 1:2024 (A.8.1 to A.8.34), 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 IT, cloud, security and
> engineering 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 engineers, administrators or security analysts
  who own technological controls, when you design tooling for the ISMS,
  and before an internal audit of the technological theme.
- Fill the Document control table first, then section 2 (the tool that
  produces evidence for each control group) because most technological
  evidence comes from tools. Then add local notes per control and keep
  the study record in section 14.
- Main pitfall: showing an auditor a live dashboard instead of dated
  records. A dashboard shows today, while the audit covers months of
  operation. Export and keep evidence for the whole audit period.
- 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-people-physical-controls-guide`, `isms/secure-development-policy`,
  `isms/secure-configuration-baseline`, `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). Record which tools you rely on, because tool changes affect where evidence comes from. -->

| Field | Value |
|---|---|
| Document ID | LRN-ISMS-06 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ciso], [@engineering-lead], [@it-operations-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 Annex A (A.8.1 to A.8.34); ISO/IEC 27002:2022 |
| Controls covered | 34 technological controls (A.8 theme), 7 of them new in 2022 |
| Audience | [IT operations, cloud and platform engineers, developers, security operations, internal auditors] |
| Main evidence tools | [Identity provider, device management, cloud posture tool, SIEM, vulnerability scanner, code repository, ticketing] |
| 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 |
| Engineering lead | [@engineering-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] | Evidence tools updated after SIEM replacement |

## Contents

<!-- Guidance: Sections 1 and 2 explain how technological controls produce evidence. Sections 3 to 11 walk through the controls in Annex A order, grouped by topic. Sections 12 to 15 turn the guide into a working and learning record. -->

1. Purpose and how to use this guide
2. How technological controls produce evidence
3. Endpoints, privileged access and authentication (A.8.1 to A.8.5)
4. Capacity, malware, vulnerabilities and configuration (A.8.6 to A.8.9)
5. Data deletion, masking, leakage, backup and redundancy (A.8.10 to A.8.14)
6. Logging, monitoring and time (A.8.15 to A.8.17)
7. Operational software and utilities (A.8.18, A.8.19)
8. Networks and web filtering (A.8.20 to A.8.23)
9. Cryptography (A.8.24)
10. Secure development (A.8.25 to A.8.31)
11. Change, test information and audit testing (A.8.32 to A.8.34)
12. Size tiers: how the theme scales
13. Self-check questions
14. Records, evidence and study record
15. References

## 1. Purpose and how to use this guide

<!-- Guidance: Say who reads the guide and when. Technological owners are often expert in tools but new to management system language, so the guide translates control intent into what they already run. Pitfall: owners who assume the tool alone meets the control, without the process around it. -->

The technological theme holds 34 of the 93 Annex A controls. Seven of
the 11 controls added in the 2022 edition sit here: configuration
management (A.8.9), information deletion (A.8.10), data masking (A.8.11),
data leakage prevention (A.8.12), monitoring activities (A.8.16), web
filtering (A.8.23) and secure coding (A.8.28). Auditors often focus on
these because organisations moving from the 2013 edition had to add them.

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. How technological controls produce evidence

<!-- Guidance: List the tools that produce evidence for each group, with the report name and how often you export it. Auditor check: a dated export covering the audit period, plus proof that someone reviewed it and acted. -->

A technological control is not a tool. It is a rule (written in a policy
or standard), a configuration that enforces the rule, a review that
checks it still works, and a record of each step. An auditor typically
asks three questions per control: what is the rule, show me it is
enforced, and show me who checks it and what happened when it failed.

```mermaid
flowchart LR
    P["Rule in policy or standard"] --> C["Configuration in the tool"]
    C --> M["Monitoring and periodic review"]
    M --> X{"Deviation found?"}
    X -->|"Yes"| A["Ticket, fix or approved exception"]
    X -->|"No"| R["Dated record kept"]
    A --> R
```

Typical evidence sources per group (adapt to your tools):

| Group | Typical tool | Example evidence export | Typical frequency |
|---|---|---|---|
| Endpoints and access (A.8.1 to A.8.5) | Device management, identity provider | Compliance report, multi-factor coverage, privileged account list | Monthly |
| Malware, vulnerabilities and configuration (A.8.7 to A.8.9) | Endpoint protection, scanner, posture tool | Coverage report, scan results, drift report | Monthly |
| Data and backup (A.8.10 to A.8.14) | Backup platform, data leakage prevention tool | Job reports, restore test log, alert reviews | Monthly, quarterly |
| Logging and monitoring (A.8.15 to A.8.17) | SIEM, log platform | Source coverage list, alert handling records | Monthly |
| Networks (A.8.20 to A.8.23) | Firewall manager, web filter | Rule review, segmentation diagram, block report | Half-yearly, quarterly |
| Development and change (A.8.25 to A.8.33) | Code repository, pipeline, ticketing | Branch protection settings, scan results, change tickets | Per change |

## 3. Endpoints, privileged access and authentication (A.8.1 to A.8.5)

<!-- Guidance: These controls protect the front door: devices and identities. Questions to answer: are all devices managed, are privileged rights limited and reviewed, is access restricted per role, is source code protected, is authentication strong? Auditor check: device compliance report and privileged account review. -->

### A.8.1 User endpoint devices

- **Intent:** Laptops and phones carry data everywhere and are easy to
  lose, steal or infect. This control makes sure each device that
  reaches company information is configured and managed so that losing
  or compromising it does not mean losing the data.
- **Typical implementation:** Managed devices with full-disk encryption,
  screen lock, current operating system, endpoint protection, remote
  wipe, and rules for personal devices (allowed, restricted or banned).
- **By tier:** Small: device management on all laptops, phones through
  app-level controls. Medium: compliance checks before access to
  corporate services. Large: device tiers by risk, including shared
  devices on plant floors.
- **Evidence an auditor samples:** Device compliance export, list of
  non-compliant devices with actions, personal device rules.
- **Common pitfalls:** Unmanaged contractor laptops connected to
  corporate services.
- **Templates:** `isms/endpoint-device-byod-policy` (DOC-ISMS-058),
  `isms/remote-working-policy` (DOC-ISMS-054).

### A.8.2 Privileged access rights

- **Intent:** Administrator rights let a person, or an attacker who
  takes over their account, change or destroy almost anything. The aim
  is to keep such power rare, temporary where possible, closely watched
  and justified.
- **Typical implementation:** Separate administrator accounts, approval
  for privileged rights, just-in-time elevation where possible, strong
  authentication, logging of privileged activity, and frequent review.
- **By tier:** Small: a short list of administrators with separate
  accounts and quarterly review. Medium: a privileged access tool for
  production. Large: privileged access management across IT and OT.
- **Evidence an auditor samples:** Privileged account list, approval
  tickets, review records, privileged session logs.
- **Common pitfalls:** Everyday accounts with permanent administrator
  rights, and break-glass accounts nobody monitors.
- **Templates:** `security/privileged-access-standard`,
  `isms/access-control-policy` (DOC-ISMS-041).

### A.8.3 Restricting access to information

- **Intent:** Access rules are only promises until systems enforce them.
  This control is about the technical settings in applications, file
  stores and databases that actually limit each user to the data and
  functions their role allows.
- **Typical implementation:** Role-based permissions in applications and
  data stores, no anonymous access to non-public data, restricted
  sharing defaults, and dynamic access rules where needed.
- **By tier:** Small: roles in the main SaaS and cloud console. Medium:
  role design per application. Large: attribute-based rules for
  sensitive data sets.
- **Evidence an auditor samples:** Permission configuration exports,
  sharing settings, review results.
- **Common pitfalls:** Storage buckets or shared folders open to anyone
  with the link.
- **Templates:** `isms/access-control-policy` (DOC-ISMS-041),
  `isms/saas-productivity-security-baseline` (DOC-ISMS-075).

### A.8.4 Access to source code

- **Intent:** Source code is both valuable intellectual property and a
  route for inserting backdoors. Limiting who can see and change it, and
  the build tools and libraries around it, protects the integrity of
  what you ship.
- **Typical implementation:** Repository access by team, branch
  protection, mandatory review before merge, signed commits where
  justified, and removal of access on leaving.
- **By tier:** Small: one organisation in the code platform with
  single sign-on. Medium: team-based permissions and protected branches.
  Large: separate repositories for OT and safety-related code with
  stricter rules.
- **Evidence an auditor samples:** Repository access list review, branch
  protection settings, merge records.
- **Common pitfalls:** Former contractors with write access to
  repositories, and secrets kept in code.
- **Templates:** `isms/secure-development-policy` (DOC-ISMS-065),
  `isms/outsourced-development-security` (DOC-ISMS-077).

### A.8.5 Secure authentication

- **Intent:** Stolen or guessed credentials are the most common way in.
  The purpose is to make logging in hard to fake, with stronger proof of
  identity for more sensitive systems and riskier access routes.
- **Typical implementation:** Single sign-on, multi-factor
  authentication for remote and privileged access, phishing-resistant
  methods (FIDO2 security keys or passkeys) for high-risk roles, and rate
  limiting of failed attempts with alerting rather than permanent lockout
  alone, which attackers can abuse to lock users out.
- **By tier:** Small: multi-factor on every account through single
  sign-on. Medium: conditional access by device and location. Large:
  phishing-resistant authentication for administrators across sites.
- **Evidence an auditor samples:** Multi-factor and single sign-on
  coverage report, exceptions list, authentication policy settings.
- **Common pitfalls:** Legacy applications outside single sign-on that
  still accept passwords only.
- **Templates:** `isms/access-control-policy` (DOC-ISMS-041),
  `isms/saas-productivity-security-baseline` (DOC-ISMS-075).

## 4. Capacity, malware, vulnerabilities and configuration (A.8.6 to A.8.9)

<!-- Guidance: These controls keep systems healthy. Questions to answer: do you know capacity limits, is malware protection everywhere, are vulnerabilities found and fixed on time, is there a defined secure configuration and do you detect drift? Auditor check: the vulnerability tracker with remediation times. -->

### A.8.6 Capacity management

- **Intent:** Systems that run out of storage, memory or bandwidth fail,
  and security functions such as logging are often the first to break.
  This control watches resource use and plans ahead so demand never
  silently exceeds supply.
- **Typical implementation:** Monitoring of compute, storage and network
  use, alerts at thresholds, auto-scaling where available, and a
  capacity review feeding budget and architecture.
- **By tier:** Small: cloud alerts and auto-scaling. Medium: quarterly
  capacity review per service. Large: capacity planning across the data
  centre and cloud.
- **Evidence an auditor samples:** Capacity alerts, review records,
  capacity plan.
- **Common pitfalls:** Log storage that fills up silently, so security
  logging stops.
- **Templates:** `ops/capacity-plan`.

### A.8.7 Protection against malware

- **Intent:** Malicious software arrives through e-mail, downloads,
  removable media and compromised websites. The aim is layered defence:
  technology that blocks or detects it, and people who recognise how it
  gets in.
- **Typical implementation:** Endpoint protection or detection and
  response on all supported systems, e-mail and web filtering,
  application control where useful, and awareness of how malware
  arrives.
- **By tier:** Small: endpoint detection and response on all laptops and
  servers. Medium: managed detection service. Large: coverage including
  OT, with compensating controls where agents cannot run.
- **Evidence an auditor samples:** Coverage report against the asset
  inventory, alert handling records, exceptions.
- **Common pitfalls:** Servers and build agents left out of coverage.
- **Templates:** `isms/malware-protection-standard` (DOC-ISMS-059).

### A.8.8 Technical vulnerability management

- **Intent:** New weaknesses are published every day, and attackers
  exploit some within hours. The purpose is to learn quickly which ones
  affect your systems, judge how exposed you are, and close the gap
  before it is used.
- **Typical implementation:** Asset-based scanning, dependency and
  container scanning, remediation times by severity, exception handling,
  and periodic penetration tests.
- **By tier:** Small: cloud and dependency scanning with a tracker.
  Medium: authenticated scanning and yearly penetration test. Large:
  risk-based prioritisation across IT and OT, with OT patch windows.
- **Evidence an auditor samples:** Scan reports, remediation tracker with
  dates, penetration test report and fixes.
- **Common pitfalls:** Scanning without fixing, and remediation targets
  that are missed with no recorded decision.
- **Templates:** `security/vulnerability-management-policy`,
  `isms/vulnerability-remediation-tracker` (DOC-ISMS-072),
  `security/pentest-report`.

### A.8.9 Configuration management (new in 2022)

- **Intent:** Default and inconsistent settings are a leading cause of
  breaches, especially in cloud services. This control means each type
  of system has an agreed secure setup, systems are built to it, and
  departures from it are noticed and corrected.
- **Typical implementation:** Baselines per platform, configuration as
  code where possible, drift detection, and change control for baseline
  changes.
- **By tier:** Small: cloud posture tool against a benchmark and baseline
  scripts for laptops. Medium: baselines per platform with monthly drift
  review. Large: configuration management across sites, including OT
  baselines.
- **Evidence an auditor samples:** Baseline documents, drift reports,
  remediation tickets.
- **Common pitfalls:** Baselines written once and never compared with
  what is actually running.
- **Templates:** `isms/secure-configuration-baseline` (DOC-ISMS-060),
  `security/cloud-security-posture-review`.

## 5. Data deletion, masking, leakage, backup and redundancy (A.8.10 to A.8.14)

<!-- Guidance: Three of these five controls are new in 2022. Questions to answer: is data deleted when no longer needed, is sensitive data masked outside production, is leakage detected, are backups tested and is there redundancy for critical services? Auditor check: a customer deletion confirmation and the latest restore test. -->

### A.8.10 Information deletion (new in 2022)

- **Intent:** Data kept longer than needed is a liability: it can be
  breached, demanded in litigation or held in breach of privacy law. The
  aim is that information is actually removed, in every place it lives,
  once its purpose and retention period are over.
- **Typical implementation:** Retention rules turned into deletion jobs,
  customer data deletion at contract end, deletion confirmations from
  suppliers, secure deletion methods per media.
- **By tier:** Small: automated deletion of customer data after contract
  end, with confirmation. Medium: retention settings per system. Large:
  deletion programme across legacy systems and sites.
- **Evidence an auditor samples:** Deletion job logs, deletion
  confirmations, retention schedule.
- **Common pitfalls:** Data deleted from production but kept forever in
  backups, logs and test copies.
- **Templates:** `data/data-retention-deletion-standard`,
  `isms/equipment-disposal-reuse-record` (DOC-ISMS-057).

### A.8.11 Data masking (new in 2022)

- **Intent:** Many people and processes need to work with data without
  seeing every value: testers, analysts, support staff. Hiding or
  replacing sensitive fields reduces exposure while keeping the data
  useful, and helps meet privacy obligations.
- **Typical implementation:** Masking, pseudonymisation or
  anonymisation for test data, analytics and support views, with rules
  for who may see unmasked data.
- **By tier:** Small: synthetic test data and masked support views.
  Medium: masking in data pipelines. Large: masking standards across
  data platforms.
- **Evidence an auditor samples:** Masking rules, test data generation
  records, access to unmasked data.
- **Common pitfalls:** Production copies used for testing without
  masking.
- **Templates:** `isms/data-masking-dlp-standard` (DOC-ISMS-062).

### A.8.12 Data leakage prevention (new in 2022)

- **Intent:** Sensitive information can leave through e-mail, uploads,
  removable media or a misconfigured share, by accident or on purpose.
  This control adds technical checks that spot and stop such outflows
  where the risk justifies them.
- **Typical implementation:** Leakage prevention rules in e-mail, cloud
  storage and endpoints for the most sensitive data types, monitoring of
  uploads and sharing, and a review of alerts.
- **By tier:** Small: sharing restrictions and built-in leakage rules in
  the productivity suite. Medium: rules for customer data in mail and
  storage. Large: integrated leakage prevention with labelling and SIEM.
- **Evidence an auditor samples:** Rule configuration, alert review
  records, actions taken.
- **Common pitfalls:** Rules in monitor mode for months with nobody
  reviewing alerts.
- **Templates:** `isms/data-masking-dlp-standard` (DOC-ISMS-062),
  `isms/information-labelling-handling-procedure` (DOC-ISMS-042).

### A.8.13 Information backup

- **Intent:** Ransomware, mistakes and hardware failure can all wipe
  data. A copy only helps if it exists, is out of an attacker's reach
  and actually restores, so the aim is copies you have proven you can
  recover from within the time the business needs.
- **Typical implementation:** Backup scope and frequency per system,
  copies isolated from production (immutable or offline), encryption,
  monitoring of jobs, and regular restore tests.
- **By tier:** Small: provider backups plus a copy in another region,
  quarterly restore tests. Medium: backup platform with immutable copies.
  Large: backup tiers per application across sites.
- **Evidence an auditor samples:** Backup job reports, restore test log
  with results, backup scope list.
- **Common pitfalls:** Backups never restored, and SaaS data assumed to
  be backed up by the provider.
- **Templates:** `isms/backup-policy` (DOC-ISMS-061),
  `isms/backup-restore-test-log` (DOC-ISMS-071),
  `ops/backup-restore-procedure`.

### A.8.14 Redundancy of processing facilities

- **Intent:** A single failed component should not stop a critical
  service. The purpose is to duplicate what matters so that losing one
  server, link, zone or site leaves enough capacity to keep running at
  the level the business requires.
- **Typical implementation:** Redundant components, multiple zones or
  regions, failover design, and failover tests.
- **By tier:** Small: multi-zone production and a recovery region.
  Medium: redundancy for critical services across the colocation suite
  and cloud. Large: redundant data centre and network paths per site.
- **Evidence an auditor samples:** Architecture diagrams, failover test
  reports.
- **Common pitfalls:** Redundant servers that share one single point of
  failure such as a network link or a key management service.
- **Templates:** `isms/ict-readiness-business-continuity-plan`
  (DOC-ISMS-047), `ops/disaster-recovery-plan`.

## 6. Logging, monitoring and time (A.8.15 to A.8.17)

<!-- Guidance: Logging without monitoring is storage; monitoring without accurate time cannot be correlated. Questions to answer: which events are logged, how long are logs kept and protected, who reviews alerts, are clocks synchronised? Auditor check: log source coverage and the handling of a recent alert. -->

### A.8.15 Logging

- **Intent:** When something goes wrong, a trail of who did what and
  when is often the only way to understand it. This control ensures the
  right events are recorded, kept safe from tampering and available for
  investigation and review.
- **Typical implementation:** A logging standard listing events per
  system type, central collection, protection against tampering,
  retention periods, and access control for logs.
- **By tier:** Small: cloud and identity logs in one platform with 12
  months retention. Medium: SIEM with defined sources. Large: central
  logging across IT and OT with legal retention per country.
- **Evidence an auditor samples:** Log source coverage list, retention
  settings, access to logs.
- **Common pitfalls:** Logging enabled but not centralised, so logs
  disappear when systems are rebuilt.
- **Templates:** `security/security-logging-standard`,
  `isms/security-monitoring-procedure` (DOC-ISMS-064).

### A.8.16 Monitoring activities (new in 2022)

- **Intent:** Logs nobody looks at do not stop attacks. The aim is
  active watching for signs that something unusual is happening, with
  someone ready to look into it and decide whether it is an incident.
- **Typical implementation:** Detection rules, a baseline of normal
  activity, alert triage with defined response times, and a review of
  detection coverage.
- **By tier:** Small: alerts from cloud and identity tools reviewed by
  the ISMS manager or a managed service. Medium: SIEM with a small
  in-house team. Large: security operations centre covering IT and OT.
- **Evidence an auditor samples:** Alert handling records, monthly
  monitoring review, detection rule list.
- **Common pitfalls:** Alerts that nobody reviews outside office hours.
- **Templates:** `isms/security-monitoring-procedure` (DOC-ISMS-064),
  `security/detection-rule-spec`.

### A.8.17 Clock synchronization

- **Intent:** If system clocks disagree, events cannot be placed in
  order and an investigation timeline falls apart. Common, trusted time
  across systems keeps logs comparable and evidence credible.
- **Typical implementation:** Approved time sources, configuration in
  baselines, monitoring of drift.
- **By tier:** Small: cloud provider and operating system defaults
  documented. Medium: internal time servers. Large: time architecture
  across sites, including OT.
- **Evidence an auditor samples:** Time source configuration export.
- **Common pitfalls:** OT and network devices with clocks hours off,
  which ruins incident timelines.
- **Templates:** `isms/secure-configuration-baseline` (DOC-ISMS-060),
  `security/security-logging-standard`.

## 7. Operational software and utilities (A.8.18, A.8.19)

<!-- Guidance: These controls stop powerful tools and unapproved software from undermining other controls. Auditor check: the restricted utilities list and change tickets for software installed on production. -->

### A.8.18 Use of privileged utility programs

- **Intent:** Some tools can bypass the very controls you rely on, for
  example by editing databases directly or changing system settings.
  Keeping such tools scarce, limited to the right people and logged
  stops them becoming an easy shortcut for insiders or attackers.
- **Typical implementation:** A list of restricted utilities, access
  limited to named administrators, logging of use, and removal of
  unnecessary tools from production.
- **By tier:** Small: production access through a controlled console
  only. Medium: restricted tool list per platform. Large: privileged
  tools only through the privileged access tool.
- **Evidence an auditor samples:** Restricted utility list, usage logs.
- **Common pitfalls:** Database administration tools installed on every
  developer laptop with production credentials.
- **Templates:** `security/privileged-access-standard`,
  `isms/secure-configuration-baseline` (DOC-ISMS-060).

### A.8.19 Software installation on operational systems

- **Intent:** Every piece of software added to a live system can bring
  weaknesses, conflicts or malicious code. The purpose is that only
  approved, tested software reaches operational systems, and only by a
  controlled route.
- **Typical implementation:** Installation through change management and
  pipelines only, allowed software lists for endpoints, no local
  administrator rights for users.
- **By tier:** Small: immutable deployments through the pipeline.
  Medium: allowed software list for endpoints. Large: software control
  for servers and OT, with vendor approval for OT changes.
- **Evidence an auditor samples:** Allowed software list, change tickets
  for installations, local administrator report.
- **Common pitfalls:** Engineers installing tools directly on production
  servers.
- **Templates:** `isms/secure-configuration-baseline` (DOC-ISMS-060),
  `ops/change-enablement-policy`.

## 8. Networks and web filtering (A.8.20 to A.8.23)

<!-- Guidance: Network controls are layered: secure the network, secure services bought from providers, separate zones, filter web access. Auditor check: the segmentation diagram matched to firewall rules and the last rule review. -->

### A.8.20 Network security

- **Intent:** The network connects everything, so a weakness in it
  exposes everything. This control keeps network infrastructure
  hardened, administered and watched, so that traffic flows only where
  it should.
- **Typical implementation:** A network security standard, hardened
  network devices, managed firewall rules, secure remote access, and
  network monitoring.
- **By tier:** Small: cloud security groups and an office firewall.
  Medium: managed firewalls with half-yearly rule review. Large:
  network operations across sites with IT and OT zones.
- **Evidence an auditor samples:** Network standard, firewall rule
  review, network diagrams.
- **Common pitfalls:** "Any to any" rules left from troubleshooting.
- **Templates:** `isms/network-security-standard` (DOC-ISMS-063),
  `security/firewall-rule-review`.

### A.8.21 Security of network services

- **Intent:** Internet links, DNS, content delivery and managed network
  services are often bought in. The aim is to know what protection each
  service gives you, write it into the agreement and check that it is
  delivered.
- **Typical implementation:** Requirements for internet links, managed
  network services, content delivery and DNS services in contracts,
  with provider reviews.
- **By tier:** Small: provider defaults recorded with a risk decision.
  Medium: requirements in contracts for links and managed services.
  Large: network service agreements per country.
- **Evidence an auditor samples:** Network service agreements, provider
  reviews.
- **Common pitfalls:** Treating network services as utilities with no
  security terms.
- **Templates:** `isms/network-security-standard` (DOC-ISMS-063),
  `isms/supplier-security-agreement-27036` (DOC-ISMS-068).

### A.8.22 Network segregation

- **Intent:** In a flat network, one compromised device can reach
  everything. Dividing the network into zones by trust level and
  function limits how far an attacker or a fault can spread.
- **Typical implementation:** Separate networks or virtual networks for
  production, development, corporate, guest and management traffic, and
  strict separation of OT from IT.
- **By tier:** Small: separate cloud accounts or projects for production
  and development, guest Wi-Fi isolated. Medium: segmented colocation
  network. Large: zone model across sites with controlled IT and OT
  boundaries.
- **Evidence an auditor samples:** Segmentation diagram, rule review
  results, test of separation.
- **Common pitfalls:** Flat networks where a compromised laptop can reach
  production or plant systems.
- **Templates:** `isms/network-security-standard` (DOC-ISMS-063),
  `security/zero-trust-architecture`.

### A.8.23 Web filtering (new in 2022)

- **Intent:** Many attacks begin with a visit to a harmful website.
  Filtering where users can browse cuts off known malicious and high-
  risk destinations, wherever the user is working.
- **Typical implementation:** Filtering of known malicious and high-risk
  categories, through DNS, a secure web gateway or endpoint agents that
  work off network as well.
- **By tier:** Small: DNS filtering on managed laptops. Medium: secure
  web gateway with category rules. Large: filtering per site, with
  stricter rules for OT engineering workstations.
- **Evidence an auditor samples:** Filtering policy settings, block
  reports, exceptions.
- **Common pitfalls:** Filtering only in the office, while most staff
  work remotely.
- **Templates:** `isms/network-security-standard` (DOC-ISMS-063),
  `isms/malware-protection-standard` (DOC-ISMS-059).

## 9. Cryptography (A.8.24)

<!-- Guidance: Cryptography needs rules and key management, not just encryption switched on. Auditor check: the key and certificate register and evidence of rotation and expiry monitoring. -->

### A.8.24 Use of cryptography

- **Intent:** Encryption protects data only if the algorithms are sound,
  it is applied in the right places and the keys stay secret and
  available. This control sets those rules and looks after keys from
  creation to destruction.
- **Typical implementation:** A cryptography standard listing approved
  algorithms and protocols, encryption at rest and in transit, key
  management with defined lifecycles, certificate expiry monitoring, and
  crypto-agility: an inventory of where each algorithm is used and a plan
  for migrating to post-quantum algorithms as standards and products
  mature.
- **By tier:** Small: provider-managed keys and automated certificates,
  documented in a short standard. Medium: customer-managed keys for
  sensitive data and a key register. Large: hardware security modules
  and a group key management service.
- **Evidence an auditor samples:** Cryptography standard, key and
  certificate register, rotation tickets, configuration showing
  protocols in use.
- **Common pitfalls:** Expired certificates causing outages, and keys
  with no named owner.
- **Templates:** `security/cryptography-standard`,
  `isms/cryptographic-key-register` (DOC-ISMS-070).

## 10. Secure development (A.8.25 to A.8.31)

<!-- Guidance: These seven controls describe one development lifecycle. Organisations that build no software may exclude some of them, but only with a clear reason; most organisations configure, script or integrate software and need at least part of this group. Auditor check: trace one release from requirement to production. -->

The development controls follow the life of a change. The diagram shows
where each control applies; A.8.30 applies the same expectations to
outsourced work, and A.8.31 keeps the environments apart throughout.

```mermaid
flowchart LR
    L["A.8.25 Secure life cycle rules"] --> Q["A.8.26 Security requirements"]
    Q --> D["A.8.27 Secure architecture and design"]
    D --> C["A.8.28 Secure coding"]
    C --> T["A.8.29 Security testing and acceptance"]
    T --> G["A.8.32 Change approval"]
    G --> P["Production"]
    O["A.8.30 Outsourced development"] --> C
    S["A.8.31 Separate dev, test and production"] -.-> T
```

### A.8.25 Secure development life cycle

- **Intent:** Security bolted on after development is expensive and
  patchy. The purpose is an agreed way of building software and systems
  in which security activities are part of every stage, from planning to
  retirement.
- **Typical implementation:** A secure development policy covering
  environments, requirements, design review, coding standards, testing,
  release and maintenance.
- **By tier:** Small: secure development rules in the engineering
  handbook. Medium: a policy with gates in the pipeline. Large: group
  policy with variants for product, internal IT and OT software.
- **Evidence an auditor samples:** Policy, release checklists, pipeline
  configuration.
- **Common pitfalls:** A policy that describes a waterfall process while
  teams release many times a day.
- **Templates:** `isms/secure-development-policy` (DOC-ISMS-065).

### A.8.26 Application security requirements

- **Intent:** If nobody states what security an application must
  provide, it rarely provides it. The aim is that security needs are
  written down and agreed before building or buying, so they can be
  designed in and checked.
- **Typical implementation:** Security requirements in user stories or
  design records, standard requirements for authentication, logging and
  data protection, and security criteria in purchasing.
- **By tier:** Small: a security checklist in the story template.
  Medium: requirement catalogue per application type. Large: security
  requirements in procurement for all software, including OT.
- **Evidence an auditor samples:** Requirements in tickets or design
  records, purchase evaluations.
- **Common pitfalls:** Buying SaaS without checking its security
  features.
- **Templates:** `isms/secure-development-policy` (DOC-ISMS-065),
  `isms/project-information-security-checklist` (DOC-ISMS-046).

### A.8.27 Secure architecture and engineering principles

- **Intent:** Good security depends on design choices made long before
  code is written. Agreed principles for engineering systems give
  architects a consistent basis for those choices and remove whole
  classes of weakness at the design stage.
- **Typical implementation:** Principles such as least privilege,
  defence in depth, secure defaults and zero trust, design reviews and
  threat modelling for significant changes.
- **By tier:** Small: a page of principles and threat models for major
  features. Medium: architecture review board with security. Large:
  reference architectures for IT, cloud and OT.
- **Evidence an auditor samples:** Principles document, design review
  records, threat models.
- **Common pitfalls:** Principles written but never referenced in design
  reviews.
- **Templates:** `security/threat-model`, `security/zero-trust-architecture`,
  `isms/secure-development-policy` (DOC-ISMS-065).

### A.8.28 Secure coding (new in 2022)

- **Intent:** Many vulnerabilities come from common coding mistakes such
  as unchecked input or hard-coded secrets. The purpose is that
  developers write code in ways that avoid known weakness patterns, with
  tooling and review to catch what slips through.
- **Typical implementation:** A secure coding standard, peer review,
  static analysis and secret scanning in the pipeline, dependency
  management, and developer training.
- **By tier:** Small: static analysis and secret scanning on every pull
  request. Medium: coding standard per language and security champions.
  Large: secure coding programme across product teams and suppliers.
- **Evidence an auditor samples:** Coding standard, code review records,
  scan results in the pipeline.
- **Common pitfalls:** Scan findings suppressed in bulk without review.
- **Templates:** `security/secure-coding-standard`,
  `isms/secure-development-policy` (DOC-ISMS-065).

### A.8.29 Security testing in development and acceptance

- **Intent:** Security requirements mean little unless someone checks
  they were met. This control makes sure software is tested for security
  while it is built and again before it is accepted for use.
- **Typical implementation:** Automated security tests in the pipeline,
  dynamic testing before major releases, penetration tests on a schedule
  or after significant change, and acceptance criteria that include
  security.
- **By tier:** Small: automated tests and a yearly penetration test.
  Medium: dynamic testing per release. Large: testing programme with
  independent testers.
- **Evidence an auditor samples:** Test results, acceptance sign-off,
  penetration test report and remediation.
- **Common pitfalls:** Penetration test findings left open from one year
  to the next.
- **Templates:** `isms/secure-development-policy` (DOC-ISMS-065),
  `security/pentest-report`.

### A.8.30 Outsourced development

- **Intent:** Handing development to an external party does not hand
  over the risk. The aim is that the organisation stays in charge of
  security in work it buys in: setting expectations, overseeing delivery
  and checking the result.
- **Typical implementation:** Security requirements in contracts,
  ownership of code, access rules, review of deliverables, and the right
  to audit.
- **By tier:** Small: often not applicable when all development is
  in-house, with the reason recorded in the SoA. Medium: requirements
  for agencies building integrations. Large: supplier development
  standards and acceptance testing.
- **Evidence an auditor samples:** Contracts, acceptance test results,
  supplier access records, or the recorded exclusion.
- **Common pitfalls:** Freelancers with production access and no
  contract terms on security.
- **Templates:** `isms/outsourced-development-security` (DOC-ISMS-077).

### A.8.31 Separation of development, test and production

- **Intent:** Developers need freedom to experiment, and production
  needs stability and protection. Keeping the environments apart stops
  untested changes, test tools and broad developer access from reaching
  live systems and real data.
- **Typical implementation:** Separate accounts or projects per
  environment, different access rights, no production data in lower
  environments unless protected, and promotion only through the
  pipeline.
- **By tier:** Small: separate cloud accounts with restricted production
  access. Medium: separate environments per service. Large: separation
  across IT and OT engineering environments.
- **Evidence an auditor samples:** Environment diagram, access lists per
  environment.
- **Common pitfalls:** Developers with standing write access to
  production.
- **Templates:** `isms/secure-development-policy` (DOC-ISMS-065).

## 11. Change, test information and audit testing (A.8.32 to A.8.34)

<!-- Guidance: These controls protect production from the changes and tests made to it. Auditor check: a sample of changes with approvals, including emergency changes, and the approved plan for the last penetration test. -->

### A.8.32 Change management

- **Intent:** Unplanned or poorly tested changes cause a large share of
  outages and security gaps. The purpose is that changes to systems are
  assessed, approved, tested and recorded, so their effect is understood
  before they reach production.
- **Typical implementation:** Change types (standard, normal,
  emergency), risk-based approval, testing, rollback plans, and review of
  emergency changes after the event.
- **By tier:** Small: pull request approval and pipeline as the change
  record. Medium: change advisory process for infrastructure. Large:
  change management across sites with OT change windows.
- **Evidence an auditor samples:** Change tickets, approvals, emergency
  change reviews.
- **Common pitfalls:** Emergency changes used to bypass approval and
  never reviewed.
- **Templates:** `ops/change-enablement-policy`, `ops/change-request`,
  `isms/secure-development-policy` (DOC-ISMS-065).

### A.8.33 Test information

- **Intent:** Test environments are usually less protected than
  production, so real data copied into them is easily exposed. This
  control ensures that data used for testing is chosen with care,
  protected while in use and removed when no longer needed.
- **Typical implementation:** Synthetic or masked test data by default,
  approval for any use of production data in tests, and deletion after
  use.
- **By tier:** Small: synthetic data sets. Medium: masking pipeline for
  test data. Large: test data management service.
- **Evidence an auditor samples:** Test data approvals, masking
  evidence, deletion records.
- **Common pitfalls:** Full production database copies in shared test
  environments.
- **Templates:** `isms/data-masking-dlp-standard` (DOC-ISMS-062),
  `isms/secure-development-policy` (DOC-ISMS-065).

### A.8.34 Protecting systems during audit testing

- **Intent:** Audits and security tests touch live systems and can slow
  or break them, or leave access behind. The aim is that such activities
  are scoped, timed and authorised with the system owners so assurance
  does not itself cause an incident.
- **Typical implementation:** Approved test plans, read-only access for
  auditors where possible, agreed windows, monitoring during tests, and
  removal of test access afterwards.
- **By tier:** Small: written approval for each penetration test.
  Medium: rules of engagement template. Large: coordination of tests
  across sites, with special care for OT.
- **Evidence an auditor samples:** Approved test plans, rules of
  engagement, access removal records.
- **Common pitfalls:** Scans run against production at peak time without
  warning operations.
- **Templates:** `isms/independent-security-review-checklist`
  (DOC-ISMS-048), `security/pentest-report`.

## 12. Size tiers: how the theme scales

<!-- 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 the number of platforms, how much is automated, and whether OT is in
scope. All rows are *Example*.

| Aspect | Quillmere Analytics Ltd (small) *(Example)* | Quillmere Health Systems (medium) *(Example)* | Quillmere Group (large) *(Example)* |
|---|---|---|---|
| Profile | 46 staff, production on one public cloud provider in two regions (primary and DR) | 320 staff, two offices, one colocation suite, managed service for hospitals | 2,400 staff, 6 sites in 4 countries, own data centre, OT and IT |
| Who runs the theme | Head of Engineering Operations as part-time ISMS manager (0.5 FTE) with the engineering team | Full-time ISMS manager, 3-person security team, IT operations | CISO and 14-person security office, site IT and OT engineering |
| Evidence approach | Mostly automated exports from cloud, identity and code platforms | Mix of tool exports and quarterly reviews | Central dashboards plus monthly dated exports per site |
| Monitoring | Managed detection service plus cloud alerts | SIEM run in-house in office hours, managed service out of hours | Group security operations centre covering IT and OT |
| Development controls | All in-house, A.8.30 excluded with reason | In-house product plus agencies for integrations | Product, internal IT and OT software, suppliers in several countries |
| Networks | Cloud networking and office firewall | Colocation network, two office networks | Zone model across sites with IT and OT boundaries |
| Hardest controls | A.8.16 out-of-hours coverage, A.8.10 deletion in backups | A.8.11 masking of clinical data, A.8.12 leakage rules | A.8.7, A.8.8 and A.8.9 on OT systems that cannot run agents or take patches quickly |

Practical advice per tier:

- **Small.** Lean on automation: posture tools, pipeline scans and
  identity reports produce most evidence with little effort. Record why
  any control is excluded.
- **Medium.** Name one owner per control and schedule monthly exports.
  The new 2022 data controls (A.8.10 to A.8.12) usually need the most new
  work, especially for regulated customer data.
- **Large or multi-site.** Agree a group standard for each control and
  site procedures for local technology. Treat OT as its own platform with
  compensating controls where IT methods cannot apply.

## 13. 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 14. -->

1. Name the seven technological controls that are new in the 2022
   edition.
2. Why is a live dashboard weak evidence, and what should you keep
   instead?
3. What is the difference between A.8.2 and A.8.18?
4. How would you show an auditor that A.8.9 operates, not just exists?
5. Where can deleted data survive, and how does A.8.10 deal with it?
6. What makes A.8.15 different from A.8.16?
7. Why does A.8.17 matter for incident investigation?
8. A company builds no software itself. Which development controls might
   it exclude, and which still apply?
9. What evidence would you show for an emergency change under A.8.32?
10. What must be agreed before a penetration test under A.8.34?

## 14. Records, evidence and study record

<!-- Guidance: List the records that show the guide is used and the theme is understood. Control evidence itself belongs in the control evidence matrix; keep dated exports for the whole audit period. -->

This guide produces learning records and local annotations. The records
that prove each technological 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 (below) | ISMS manager | [Learning platform or ISMS folder] | [Duration of employment plus 1 year] |
| Device compliance and multi-factor coverage exports | Endpoint lead, IAM lead | [Evidence folder] | [3 years or one certification cycle] |
| Vulnerability scans and remediation tracker | Vulnerability lead | `isms/vulnerability-remediation-tracker` (DOC-ISMS-072) | [3 years] |
| Configuration drift reports | Cloud lead | [Evidence folder] | [3 years] |
| Backup reports and restore tests | IT operations lead | `isms/backup-restore-test-log` (DOC-ISMS-071) | [3 years] |
| Alert handling and monitoring reviews | Security operations lead | [SIEM, ticketing] | [Per logging standard, at least one certification cycle for review records] |
| Key and certificate register | Platform lead | `isms/cryptographic-key-register` (DOC-ISMS-070) | [Key life plus 3 years] |
| Change tickets and pipeline records | Engineering lead | [Ticketing, code repository] | [3 years] |

Study record:

| ID | Learner | Role | Sections studied | Date completed | Self-check result | Reviewed by |
|---|---|---|---|---|---|---|
| LRN-A8-001 *(Example)* | [@cloud-lead] | Cloud lead | 2, 4, 5, 8 | 2027-03-03 | 9 of 10 answered correctly, follow-up on A.8.17 | [@isms-manager] |
| LRN-A8-002 *(Example)* | [@engineering-lead] | Engineering lead | 10, 11 | 2027-03-10 | 10 of 10 | [@isms-manager] |
| LRN-A8-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.

## 15. 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 27033-1 (network security) | 2015 | https://www.iso.org/standard/63461.html |
| ISO/IEC 27034-1 (application security) | 2011 | https://www.iso.org/standard/44378.html |
| ISO/IEC 27040 (storage security) | 2024 | https://www.iso.org/standard/80194.html |
| ISO/IEC 27031 (ICT readiness) | 2025 | https://www.iso.org/standard/80975.html |
| ISO/IEC 27017 (cloud services) | 2026 | https://www.iso.org/standard/82878.html |

Related templates: `isms/isms-learning-path`, `isms/isms-glossary`,
`isms/annex-a-organizational-controls-guide`,
`isms/annex-a-people-physical-controls-guide`, `isms/isms-self-test`,
`compliance/statement-of-applicability`, `isms/control-evidence-matrix`,
`isms/secure-development-policy`, `isms/secure-configuration-baseline`,
`isms/network-security-standard`, `isms/security-monitoring-procedure`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A (controls
A.8.1 to A.8.34) and with the control guidance in ISO/IEC 27002:2022. The
intents, implementation notes, tier advice, evidence sources, 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. This guide does not promise certification, which is decided
by an accredited certification body. Template licence: MIT.