Annex A Technological Controls Guide Template (ISO/IEC 27001 A.8)

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.

Document control

Approvals

Revision history

Contents

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

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

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.

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

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

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)

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)

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)

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)

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)

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)

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)

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.

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)

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

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.

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

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

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.

Study record:

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

15. References

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.