ISO 27001 technological controls: A.8.1–A.8.34
The 34 technological controls in Annex A section 8 address protection of information and systems across their lifecycle. They cover more than selecting products. Configuration, ownership, validation, operating processes and continuing review determine whether a technology actually supports the intended security outcome.
Start with the service and its dependencies
Identify the information, systems, interfaces and business consequences in scope. Use risk treatment to determine necessary controls and compare against Annex A. A control’s title does not prescribe a single product, configuration, testing interval or architecture. Technical choices must be suitable for the environment and any applicable obligations.
Consider who operates each arrangement and who validates it. Cloud or managed-service provision can change responsibilities, but does not remove the need to understand them. Check what the provider’s evidence covers and what remains for your organisation to configure, monitor or review.
Illustrative examples
A software provider introduces a new integration. Secure design, coding, testing, environment separation and change decisions may all be relevant. Passing one automated scan does not prove that business logic, access boundaries and deployment responsibilities are adequate. Evidence should address the actual risks and selected controls.
A manufacturer relies on specialised systems supporting production information. Patch and access decisions must consider system constraints and operational consequences. Where immediate changes are unsuitable, the organisation evaluates appropriate measures and accountable decisions rather than simply declaring the system exempt from security management.
Validate outcomes rather than purchase status
Useful evidence includes configuration review, representative tests, operating samples, resolved findings and evaluated exceptions. A backup job report may need a restoration exercise to support the intended recovery outcome. A logging setting may need evidence that relevant data is retained, examined and acted on.
Keep assessment activities authorised and scoped. Sterling’s agreed vulnerability scanning and findings review should not be assumed to include penetration testing. The individual guides explain practical control evidence without prescribing intrusive activity or promising that any scan proves a system has no weaknesses.
Individual controls in this theme
A.8.1 · Protect user endpoint devices
Endpoint protection covers information stored on a device and information the device can reach. This guide connects permitted use, configuration, updates, personal devices and loss response. BPO and construction examples show how a secure central application can still depend on an uncontrolled endpoint, and how to verify protection under real working conditions.
A.8.2 · Restrict and manage privileged access
Privileged access allows actions that ordinary users cannot perform, so approval alone is not enough. This guide follows need, allocation, use, expiry and review for people and service identities. Software and manufacturing examples explain temporary elevation and emergency access, with evidence that shows both authorised activity and the removal of unnecessary privileges.
A.8.3 · Restrict access to the information people need
Information access restriction turns an approved access policy into the permissions a system actually enforces. This guide distinguishes visibility, modification, deletion and sharing, including access beyond the organisation. BPO and construction examples show how broad groups and external links can defeat intended restrictions, and how authorised tests reveal the effective permission.
A.8.4 · Control access to source code and development tools
Source-code access affects intellectual property and the integrity of the software an organisation builds or maintains. This guide distinguishes reading, modifying and administering repositories and related tools. Software and manufacturing examples examine supplier permissions and automation credentials, showing why repository membership alone does not describe the full path by which code can change.
A.8.5 · Establish secure authentication
Secure authentication establishes confidence in an identity before access is granted, but its strength depends on the complete process. This guide covers method selection, enrolment, recovery, failed attempts and sessions. IT and BPO examples reveal how a strong login can be undermined by a weaker support route or inconsistent application coverage.
A.8.6 · Plan capacity before services suffer
Capacity management keeps information services within the resource limits needed for dependable operation. This guide connects demand forecasts, warning thresholds, resource decisions and testing. Software and BPO examples show how bottlenecks arise beyond processor utilisation, and how teams can demonstrate that an approved response will work before a predictable peak arrives.
A.8.7 · Make malware protection work in practice
Malware protection combines appropriate technical measures with people who know how to handle suspicious activity. This guide examines coverage, exceptions, alerts and recovery decisions. Manufacturing and construction examples show how unsupported equipment and temporary devices need deliberate treatment, while safe tests help establish whether protection works beyond a licence or installation record.
A.8.8 · Turn vulnerability findings into verified action
Vulnerability management connects reliable information about technical weaknesses with the systems actually in use and an accountable treatment decision. This guide covers prioritisation, updates, temporary measures and verification. Software and manufacturing examples explain why a scan report is only a starting point, and how teams can show that important findings received effective action.
A.8.9 · Keep configurations secure and consistent
Configuration management establishes the intended settings of systems and checks whether their actual state still matches. This guide explains secure baselines, controlled changes, exceptions and drift investigation. Software and BPO examples show why approved design alone is insufficient, and how teams can preserve useful evidence without exposing sensitive technical details unnecessarily.
A.8.10 · Delete information when its purpose ends
Information deletion reduces unnecessary exposure after information is no longer required. This guide connects retention decisions, system capabilities, copies and supplier responsibilities with evidence of the result. BPO and construction examples show how deletion can fail at handover or project closure, and why a disappearing file is not always proof of an appropriate deletion method.
A.8.11 · Use data masking for the intended task
Data masking limits the sensitive details exposed during a legitimate task. This guide explains how to choose a method, preserve useful information and test the remaining identification risk. Software and BPO examples distinguish a masked display from protected exports, and show why transformed data still needs appropriate access and handling controls.
A.8.12 · Prevent sensitive information leaving without authority
Data leakage prevention addresses unauthorised disclosure through the systems and channels people actually use. This guide connects information classification, transfer rules, response and proportionate monitoring. BPO and manufacturing examples show why detecting a sensitive pattern is only part of the decision, and how useful exceptions can avoid uncontrolled workarounds while preserving accountability.
A.8.13 · Prove that backups can restore useful service
Information backup is valuable when the organisation can recover the information and supporting systems it needs. This guide explains backup scope, protection, failure handling and restoration evidence. Software and construction examples distinguish successful copy jobs from usable recovery, including dependencies, provider responsibilities and the time needed to return information to authorised users.
A.8.14 · Design redundancy around real failure conditions
Redundancy provides an alternative processing capability when a component or facility fails. This guide connects availability needs, shared dependencies, activation and testing. IT and manufacturing examples show why two components can still share one point of failure, and why an alternative must maintain security and usable capacity when it takes over.
A.8.15 · Create logs that can support investigation
Logging creates the event records needed to understand activity, faults and security concerns. This guide covers purposeful collection, protection, analysis and retrieval. Software and manufacturing examples show how missing context or excessive administrator control can undermine evidence, and why a log source must be tested from event generation through usable review.
A.8.16 · Make monitoring lead to timely assessment
Monitoring activities look for unusual behaviour and turn relevant signals into an assessment of possible security incidents. This guide covers scope, expected behaviour, alert ownership and tuning. BPO and software examples show why collecting events is insufficient when nobody evaluates them, and how safe tests can reveal gaps in the complete response path.
A.8.17 · Align system clocks for reliable event analysis
Clock synchronisation makes records from different systems easier to relate and investigate. This guide explains approved time sources, accuracy needs, time representation and checks for drift. IT and construction examples show how apparently contradictory records can arise from clock differences, and how teams can preserve a reliable interpretation without altering original evidence.
A.8.18 · Control powerful utility programs
Privileged utility programs can change information or system behaviour outside normal application safeguards. This guide explains how to recognise those capabilities, authorise their use and preserve accountability. Software and manufacturing examples show why an approved administrator still needs a controlled purpose, and why emergency tools should not remain generally available after the task ends.
A.8.19 · Control software installed on operational systems
Software installation changes what an operational system can do and the risks it carries. This guide connects permitted software, trusted sources, deployment authority, testing and recovery choices. BPO and construction examples show how convenient local installations and supplier updates need controlled decisions, with evidence of the installed result and any remaining limitations.
A.8.20 · Secure the networks carrying business information
Networks security protects information and connected systems through deliberate management of network devices, connections and traffic. This guide examines ownership, secure administration, connection decisions and testing. Manufacturing and IT examples show how undocumented changes or virtual infrastructure can create exposure, and how teams can verify the intended network behaviour without disrupting operations.
A.8.21 · Specify security for network services
Security of network services connects business needs with the protection and service levels delivered by internal or external providers. This guide explains requirements, responsibilities and ongoing verification. Construction and BPO examples show why connectivity alone is insufficient, and how a clear service agreement can expose gaps in access control, incident handling or evidence.
A.8.22 · Separate networks around meaningful security boundaries
Network segregation separates groups of services, users and systems so communication across security boundaries can be controlled. This guide explains grouping decisions, permitted flows and verification. Manufacturing and office examples show why a labelled network segment is insufficient without effective restrictions, and why legitimate cross-boundary work needs a maintained, authorised route.
A.8.23 · Manage web access without encouraging bypasses
Web filtering manages access to external websites to reduce exposure to malicious content and inappropriate resources. This guide connects technical rules with safe use, practical exceptions and coverage checks. BPO and construction examples show how filtering can fail through unmanaged devices or broad exemptions, and how users can obtain legitimate access without bypassing protection.
A.8.24 · Govern cryptography and its keys
Cryptography can protect confidentiality, integrity and authenticity when the method and its keys are managed appropriately. This guide explains purpose, approved use and lifecycle responsibilities. Software and construction examples show why encryption status alone is insufficient, and how key loss, exposed recovery information or unclear provider responsibilities can undermine the intended protection.
A.8.25 · Build security into the development life cycle
A secure development life cycle embeds security decisions in the way software and systems are created and changed. This guide connects requirements, design, implementation, testing and release responsibilities. Software and BPO examples show how practical rules can fit different delivery methods, including internal automation, without turning security into a final checklist detached from development.
A.8.26 · Specify application security before acceptance
Application security requirements describe the protection a developed or acquired application must provide. This guide connects information, users, transactions and business obligations with testable expectations. Construction and software examples show how clear requirements improve supplier evaluation and release decisions, avoiding vague assurances that leave access, logging or data handling unresolved until implementation.
A.8.27 · Apply secure architecture and engineering principles
Secure architecture and engineering principles guide how protective measures work together across a system. This guide connects design choices with information risks, trust boundaries and operational capability. Software and manufacturing examples show why isolated security features are insufficient, and how reviewing failure behaviour and exceptions can improve decisions before costly implementation commitments.
A.8.28 · Make secure coding an everyday practice
Secure coding applies protective principles to the way software is written, reviewed and maintained. This guide connects relevant coding guidance, developer capability, reused components and defect learning. Software and BPO examples show how everyday implementation choices can introduce exposure, and how targeted review and testing can prevent the same weakness recurring across later changes.
A.8.29 · Test security before accepting a system
Security testing provides evidence for development and acceptance decisions by checking relevant requirements and failure conditions. This guide explains test scope, methods, environments and finding closure. Software and construction examples show why a successful functional demonstration or clean scan is insufficient when important access behaviour or production configuration remains outside the test.
A.8.30 · Retain security oversight of outsourced development
Outsourced development needs clear security direction and continuing oversight from the organisation receiving the work. This guide connects agreed requirements, supplier practices, review evidence and acceptance. Construction and software examples show why a completed deliverable does not settle questions about code ownership, test results, unresolved findings or the ability to maintain the system after handover.
A.8.31 · Separate development, test and production safely
Environment separation protects live services and information from inappropriate development or testing activity. This guide explains boundaries, access, deployment authority and non-production protection. Software and BPO examples show why separate labels are insufficient when credentials or data cross the boundary, and how small teams can maintain accountable review without inventing unnecessary organisational layers.
A.8.32 · Preserve security when systems change
Change management preserves information security as systems and processing facilities evolve. This guide follows a change from purpose and impact assessment through authorisation, implementation and review. Manufacturing and software examples show why a technically successful change can still leave access, recovery or operational documentation in an unsafe or misunderstood state.
A.8.33 · Select and protect useful test information
Test information must support meaningful verification while remaining appropriately protected. This guide connects selection, authorisation, access and deletion with reliable results. Software and BPO examples show why convenient production copies can create exposure, and why altered or incomplete test data can also produce misleading assurance about the system being tested.
A.8.34 · Protect systems during audit and assurance tests
Audit and assurance tests need their own safeguards when they involve operational systems. This guide explains agreed scope, access, timing, devices and evidence handling. BPO and manufacturing examples show how a well-intended test can create disruption or excessive disclosure, and how proportionate planning preserves useful assurance while protecting the service being assessed.
Why technological controls matter to the whole business
Technology is where most day-to-day information risk is created or contained. Customers expect their data to be protected by working systems, not by policy statements, and many tender questionnaires now probe technical arrangements directly. Section 8 of Annex A matters because it describes controls whose failure is usually visible to outsiders first: a leaked file, a compromised account, an outage with no recovery, a defect shipped to production. Treating the section as a shopping list of products wastes money and leaves gaps. Treating it as a set of decisions, each with an owner and a way of checking that it works, gives leadership a defensible position with clients, regulators and auditors, and keeps technical spending tied to the risks the business has actually identified.
Frequently asked questions
Does Annex A require a particular security product?
The control outcome and relevant requirements guide the decision. Select a suitable implementation rather than assuming one vendor or product is universally mandatory.
Can a cloud provider implement technological controls for us?
It can perform agreed activities, but responsibilities may be shared. Understand the service boundary, configuration duties, evidence and continuing oversight.
Does a successful scan prove all technological controls work?
No. A scan has a defined scope and limitations. Other controls may require design review, configuration checks, process evidence or different validation activities.
Connect technical protection with verified operation
Discuss your systems, development activities and technical control priorities with Sterling. Agree the boundaries of assessment, implementation assistance and evidence review before selecting tools. Vulnerability scanning and findings review can be scoped separately; they should not be confused with penetration testing or a guarantee against attack. Consider scoped use of Effivity ISO & GRC automation software to coordinate control actions and evidence alongside the teams operating your technical protections. Arrange a focused consultation.
Develop control-owner understanding through Sterling Academy’s 93 Annex A Controls training. Training and consulting support implementation; independent certification bodies decide certification outcomes.