ISO 27002:2022 Clause 8 Technological Controls Guide
ISO/IEC 27002:2022 Clause 8 (ISO/IEC 27001:2022 Annex A.8) encompasses the technological security controls in an Information Security Management System (ISMS).
This clause groups 34 technical controls aimed at protecting an organization’s networks, systems, applications, and data.These controls cover everything from endpoint device security and access management to malware protection, network security, cryptography, and secure software development.
Navigate
ISO/IEC 27001
Templates & Tools
Clause 8 – Technological Controls list
Each control in Clause 8 serves to safeguard the confidentiality, integrity, and availability of information – the core objectives of ISO 27001.
Below, we provide a list with explanation of each control’s purpose and importance, and best practices for implementation. For complete, control‑specific guidance open the dedicated page for each control from the list below.
Endpoint and Access Security Controls (Controls 8.1–8.5)
This first set of Clause 8 controls ensures that only authorized people and devices can access information.
With securing user endpoints and enforcing strict access controls, organizations protect sensitive data from unauthorized access or alteration.
Control 8.1 User Endpoint Devices
Ensure laptops, desktops, mobile devices, and other endpoints are securely configured and managed. The organization should maintain an inventory of authorized user devices and enforce policies for device security (e.g. strong passwords, encryption, auto-lock, and regular patching). A BYOD (bring your own device) policy is often needed to address personal devices. The purpose is to prevent compromised or unmanaged devices from introducing security risks.
Implementation Best Practices
- Register and track all endpoint devices in use.
- Use Mobile Device Management (MDM) or endpoint management tools to enforce security configurations (disk encryption, screen lock, etc.).
- Regularly update OS and software, and restrict installation of unauthorized applications.
- Educate staff on secure use of devices and safe practices (e.g. not leaving devices unattended, avoiding public Wi-Fi without VPN).
Control 8.1 – User Endpoint Devices: If you want to know more about this control, check out our dedicated User Endpoint Devices page, where we explore it in greater depth.
Control 8.2 Privileged Access Rights
Control and limit the use of administrative (“root” or “admin”) privileges on systems and applications. Privileged accounts should be granted only to authorized personnel on a need-to-use basis and reviewed regularly. The importance of this control is to enforce the principle of least privilege, reducing the risk of accidental or malicious misuse of powerful accounts. Administrators should use their elevated access only for specific tasks and use normal user accounts for day-to-day work.
Implementation Best Practices
- Maintain a privileged access policy that defines who can receive admin rights and under what conditions they expire or are revoked.
- Use dedicated admin accounts separate from standard user accounts. Enable multi-factor authentication (MFA) for all privileged logins.
- Keep a log of all privileged access activities for audit and periodically review these logs.
- Regularly review user accounts and promptly remove or adjust privileges when staff change roles or leave.
Control 8.2 – Privileged Access Rights: To learn more about how to manage privileged access effectively, visit our Privileged Access Rights page for an in-depth guide.
Control 8.3 Information Access Restriction
Ensure that access to information and other assets (e.g. databases, files, network shares) is restricted based on business needs. Only authorized users with a legitimate need should be able to view or modify a given information asset. By preventing anonymous or broad access, this control protects confidentiality and makes user actions traceable.
Implementation Best Practices
- Implement role-based access control (RBAC) or attribute-based access rules so that each user only accesses information relevant to their role.
- Remove “guest” or anonymous access options on systems; require all users to be authenticated.
- Use access control lists and permissions on files, databases, and cloud resources to enforce least privilege.
- Review access rights regularly, especially for sensitive information, to ensure appropriateness.
Control 8.3 – Information Access Restriction: For further details on limiting access to sensitive information, see our detailed Information Access Restriction page where this control is discussed extensively.
Control 8.4 Access to Source Code
Protect your organization’s application and software source code from unauthorized access or tampering. The integrity of source code is crucial – malicious changes could introduce vulnerabilities or backdoors. Most staff should have read-only access to code, with write access limited to developers based on their role and project needs.
Implementation Best Practices
- Use a version control system (e.g. Git) with access controls: only grant commit (write) rights to authorized developers; others can have read or no access as appropriate.
- Implement code review processes and require peer approval for changes (pull request reviews) to catch unauthorized modifications.
- Protect code repositories with MFA and strict authentication; monitor access logs for suspicious activity.
- If using third-party developers or outsourcing, ensure contracts include source code security requirements (this ties into control 8.30 as well).
Control 8.4 – Access to Source Code: If you’re looking for more information on protecting source code, our Access to Source Code page provides a deeper exploration of this control.
Control 8.5 Secure Authentication
Use strong authentication mechanisms to verify user identities. Secure authentication ensures a user is who they claim to be before granting access to systems or data. Depending on information sensitivity, authentication strength should vary. Basic logins (username/password) can be fortified with MFA (e.g. one-time tokens or biometric factors).
Implementation Best Practices
- Enforce password policy for complexity and regular changes, or better, use password managers and unique passwords.
- Implement multi-factor authentication for critical systems and remote access (something the user knows + has + is).
- Limit the information shown on login screens or error messages to avoid helping attackers (e.g. do not reveal if username is valid, generic failure messages).
- Log all login attempts (successful and failed) and configure alerts for multiple failures (possible brute-force attack).
Control 8.5 – Secure Authentication: To explore secure authentication further, head over to our Secure Authentication page for comprehensive insights.
Why Controls 8.1 – 8.5 strengthen your ISMS
Endpoint and access security controls fortify the confidentiality of information by preventing unauthorized devices or individuals from entry.
They also uphold integrity, as restricting privileged actions and securing authentication reduces the risk of illicit changes.
System Planning and Hardening (Controls 8.6–8.9)
Clause 8 also includes controls that ensure your IT resources are well-managed and protected against technical weaknesses. This covers planning capacity for reliable operations and proactively addressing misconfigurations, malware, and vulnerabilities – all critical for a resilient and secure IT environment.
Control 8.6 Capacity Management
Plan and monitor the capacity of information processing resources (such as server performance, bandwidth, storage) to meet business requirements. The goal is to avoid security or availability issues caused by overloaded systems or resource exhaustion. Adequate capacity planning also supports future growth without compromising security.
Implementation Best Practices
– Regularly assess current usage of CPU, memory, network, and storage; forecast future needs based on business growth or seasonality.
– Use scalable infrastructure (such as cloud services) that can adjust capacity on-demand, or have upgrade plans in place for on-premise systems.
– Implement alerts for when utilization nears critical thresholds, so you can take action (e.g. add servers or optimize applications) before failure occurs.
– Incorporate capacity considerations into change management – e.g. before deploying a new system, ensure the infrastructure can handle it.
Control 8.6 – Capacity Management: Interested in learning more about maintaining system capacity? Check out our Capacity Management page, which delves deeper into this control.
Control 8.7 Protection Against Malware
Establish defenses to detect and prevent malicious software (viruses, ransomware, spyware, etc.) from infecting systems. This control is vital for maintaining system integrity – malware can corrupt data or give attackers control of your systems. Anti-malware isn’t just software; it includes user awareness and safe practices as well.
Implementation Best Practices
– Deploy reputable anti-malware tools on all endpoints, email gateways, and servers; ensure they automatically update their virus definitions.
– Configure anti-malware for real-time scanning and regular full system scans.
– Restrict software installation: only authorized software should be allowed (use application whitelisting or admin approval for new installs – ties to control 8.19). This reduces the chance of users inadvertently installing malware.
– Educate employees on malware risks: e.g. don’t open suspicious email attachments or links, and avoid untrusted USB devices.
– Prepare for incidents: have an incident response plan for malware outbreaks, and consider isolating critical systems or backups to prevent malware spread.
Control 8.7 – Protection Against Malware: For a deeper dive into anti-malware measures, visit our Protection Against Malware page to learn more about this control.
Control 8.8 Management of Technical Vulnerabilities
Implement a process to identify, evaluate, and remediate vulnerabilities in your IT systems and software. New vulnerabilities (e.g. software bugs or missing patches) are disclosed frequently, and attackers exploit these weaknesses. This control’s purpose is to reduce risk by keeping systems up-to-date and hardened against known threats.
Implementation Best Practices
– Maintain an asset inventory (hardware, software, versions, owners) so you know what could be affected by new vulnerabilities.
– Stay informed of newly disclosed vulnerabilities (subscribe to vendor security bulletins, threat intelligence feeds, or use vulnerability databases).
– Use automated vulnerability scanning tools to regularly scan your network, servers, and applications for known flaws. Conduct penetration testing periodically for a deeper assessment.
– Establish a patch management process: evaluate patches or remediation steps, test them if needed, and apply them promptly based on the risk (critical vulnerabilities should be patched fast, whereas low-risk can follow normal schedule).
– Keep a log of vulnerabilities and track their remediation status. Unpatched high-risk vulnerabilities should be escalated to management to ensure timely action.
Control 8.8 – Management of Technical Vulnerabilities: Curious about handling technical vulnerabilities? Our Management of Technical Vulnerabilities page offers a thorough exploration of this control.
Control 8.9 Configuration Management:
Ensure that all systems (servers, network devices, applications) are securely configured and that configurations are documented and controlled. Misconfigured systems are a major source of breaches – in fact, misconfigurations rank among the top three avenues attackers use to gain unauthorized access. The purpose of this control is to apply baseline security settings and prevent accidental or intentional insecure setups.
Implementation Best Practices
– Develop secure configuration baselines for operating systems, databases, network appliances, etc. (for example, disable default passwords, unnecessary services, open ports; enforce strong encryption protocols).
– Use configuration management tools or scripts to deploy consistent settings and to detect deviations from approved configurations.
– Implement a change control process (linked with control 8.32) for any configuration changes – changes should be reviewed, tested, and approved to avoid introducing vulnerabilities.
– Regularly audit configurations and monitor for drift. Leverage system management solutions that flag when a system’s setup differs from the baseline (indicating a potential unauthorized change or error).
Control 8.9 – Configuration Management: You can find a detailed discussion on establishing secure configurations on our Configuration Management page.
Why Controls 8.6 – 8.9 strengthen your ISMS
Proper capacity management, malware defenses, vulnerability remediation, and secure configurations all contribute to a robust and resilient IT infrastructure.
They uphold availability (through capacity planning and avoiding outages) and integrity (by eliminating known weaknesses and unapproved changes).
Data Security and Cryptography (Controls 8.10–8.12, 8.24)
These controls focus on protecting sensitive data throughout its lifecycle – from limiting how long it’s kept, to masking and encrypting it, to preventing data leaks. They help organizations comply with privacy regulations and prevent unauthorized data exposure.
Control 8.10 Information Deletion
Retain data only for as long as it’s needed and delete information securely once it’s no longer required. By not keeping sensitive information longer than necessary, you minimize the risk of unauthorized disclosure or breach.
Implementation Best Practices
– Establish a data retention policy that defines retention periods for various categories of data (e.g. business records, personal data, log files) in compliance with laws and business needs.
– Implement processes to routinely delete or archive data that has exceeded its retention period. Deletion should use secure methods (like cryptographic wipe or physical destruction for hardware) appropriate to the data’s sensitivity.
– Document and log all deletion actions for audit purposes. For highly sensitive data, consider using tools that can verify and certify deletion.
– Ensure backups and archives are also included in the deletion policy – data should be removed from all locations (production systems, backups, cloud storage) as required.
Control 8.10 – Information Deletion: Looking for more insight into secure data deletion practices? See our Information Deletion page for further details on this control.
Control 8.11 Data Masking
Apply techniques to mask or anonymize sensitive data so that only the necessary information is revealed for a given task. This control protects personal identifiable information (PII) and other confidential data, especially in non-production environments or reports, without impeding necessary use.
Implementation Best Practices
– Use data masking tools to replace or scramble sensitive fields (e.g. replacing real customer names or credit card numbers with fictitious or obscured values) in development, testing, or analytics datasets.
– Implement pseudonymization or anonymization for personal data whenever possible. For example, remove direct identifiers and use reference codes, or aggregate data to high levels.
– Limit search results and user interface displays to show only the minimum data needed. For instance, mask all but last 4 digits of an ID or account number unless full detail is required by an authorized process.
– Clearly classify data so you know which fields/columns require masking or special protection.
Control 8.11 – Data Masking: For more on how data masking protects sensitive information, check out our Data Masking page for an in-depth guide.
Control 8.12 Data Leakage Prevention
Implement measures to detect and prevent unauthorized disclosure or extraction of sensitive information. Data Leakage Prevention (DLP) typically involves technology that monitors data in transit (network traffic, emails), data at rest (file storage), and data in use (endpoints) to stop leaks. The control’s importance is in averting breaches where confidential data could be exfiltrated.
Implementation Best Practices
– Classify sensitive information (confidential, internal, public, etc.) so that DLP systems know what to watch for (e.g. credit card numbers, customer data, intellectual property).
– Deploy DLP tools on critical channels: email DLP to block or flag emails with sensitive attachments or content leaving the company, web gateway DLP to monitor uploads, endpoint DLP to control file transfers to USB or cloud drives.
– Monitor data flows: Identify where your data travels (cloud services, messaging, etc.) and apply DLP policies to those channels. For example, restrict uploads of files to unapproved cloud storage or prevent printing of sensitive documents.
– When a potential leak is detected, have procedures to take action – e.g. automatically block the transfer, quarantine the email, alert security staff, and train users involved. A three-step approach of classify → monitor → respond is effective.
Control 8.12 – Data Leakage Prevention: We cover data leakage prevention in detail on its dedicated page—visit our Data Leakage Prevention article to learn more about this control.
Control 8.24 Use of Cryptography
Ensure proper and effective use of cryptography to protect information based on risk. This broad control mandates that organizations have a cryptography policy covering encryption of data at rest and in transit, appropriate cryptographic algorithms, and management of keys. Encryption is a cornerstone of protecting confidentiality – even if data is intercepted or stolen, strong encryption renders it unreadable without the keys.
Implementation Best Practices
– Identify sensitive data that requires encryption (files, databases, backups, communications) and apply industry-standard encryption algorithms (e.g. AES-256 for data at rest, TLS 1.2+ for data in transit).
– Manage encryption keys securely: use centralized key management systems or Hardware Security Modules (HSMs) to store keys, rotate keys periodically, and ensure proper backup of keys. Limit access to keys strictly.
– Encrypt laptops and portable drives (full-disk encryption) to protect data if a device is lost. Similarly, enable encryption for databases or cloud storage containing confidential information.
– Establish guidelines on cryptographic use, including approved cipher suites, key lengths, digital signature requirements, and when to use hashing or tokenization. Regularly review and update these to align with current best practices and emerging threats (for example, migrating away from outdated algorithms).
Control 8.24 – Use of Cryptography: To learn all about cryptographic controls, head over to our Use of Cryptography page, which covers this control in detail.
Why Controls 8.10 – 8.12 & 8.24 strengthen your ISMS
Data deletion, masking, DLP, and cryptography directly bolster confidentiality and privacy. They ensure that even if other defenses fail, your critical data remains protected and exposure is limited. They also help meet regulatory requirements (GDPR, HIPAA, etc.) by safeguarding personal and sensitive information.
Backup and Availability Controls (Controls 8.13–8.14)
Even with strong prevention, incidents can happen. Controls 8.13 and 8.14 focus on preserving data and system availability through robust backup and redundancy strategies. This ensures business continuity – a key objective of any ISMS.
Control 8.13 Information Backup
Regularly perform and test backups of essential data and systems. A solid backup program guarantees that information can be restored in case of data loss, ransomware, or other incidents, thereby supporting both availability and integrity of data.
Implementation Best Practices
– Define a backup policy covering what data is backed up (systems, databases, user files, configurations), backup frequency (e.g. daily, weekly), and retention (how long backups are kept).
– Use the 3-2-1 backup rule as a guideline: keep 3 copies of data, on 2 different media, with 1 copy offsite (or offline). For example, maintain on-site backups for quick restore and offsite/cloud backups for disaster recovery.
– Automate backups and monitor them – use backup software that reports success/failure. Address any failed backup immediately to ensure no gaps.
– Test restore procedures regularly (at least annually or whenever significant changes occur): perform trial restorations of backups to verify data integrity and that restore time meets requirements. Testing ensures you can rely on backups during a real crisis.
Control 8.13 – Information Backup: To fully understand best practices for backups, head to our Information Backup page for an extensive look at this control.
Control 8.14 Redundancy of Information Processing Facilities
Design your IT infrastructure with redundancy to eliminate single points of failure. Redundancy means having spare or duplicate components that can take over if a primary component fails, thus ensuring continuous availability of systems as required by the business.
Implementation Best Practices
– Identify critical systems and infrastructure (servers, network links, power supplies, etc.) that require high availability. Implement redundant components for these: e.g. clustering of servers, RAID storage, dual network providers, backup power generators.
– Geographical redundancy for disaster recovery: maintain secondary sites or cloud failover environments that can run essential services if the primary site becomes unavailable (due to natural disaster, major outage, etc.).
– Implement automatic failover where possible – for instance, if one server in a cluster goes down, others should seamlessly handle the load. Regularly test failover mechanisms to ensure they work as designed.
– Keep documentation and diagrams of redundant setups and ensure your team knows how to invoke failover procedures. Also, monitor the health of redundant components (a standby server is only useful if it’s operational and in sync when needed).
Control 8.14 – Redundancy of Information Processing Facilities: There’s a lot more to ensuring redundancy. Visit our Redundancy of Information Processing Facilities page for an in-depth overview of this control.
Why Controls 8.13 – 8.14 strengthen your ISMS
Backup and redundancy controls underpin availability, ensuring that even if incidents occur, the business can recover data and continue operations with minimal disruption.
These measures also support integrity (by allowing restoration of uncorrupted data) and give stakeholders confidence in the organization’s resilience.
Logging and Monitoring (Controls 8.15–8.17)
Proactive monitoring and record-keeping are key to detecting security incidents and analyzing them. Clause 8 includes controls for maintaining logs, continuous monitoring, and time synchronization – all of which contribute to rapid threat detection and effective incident response.
Control 8.15 Logging
Generate and retain log records of events, especially security-relevant activities, across systems and applications. Logging provides an audit trail that can be used to detect suspicious actions and investigate incidents. It’s important not only to log events, but to protect log integrity (so attackers can’t tamper or erase their tracks).
Implementation Best Practices
– Identify key events to log: login attempts (successful and failed), admin actions, changes to critical settings, access to sensitive data, etc. Configure systems to record these in detail (who, what, when, success/fail).
– Centralize your logs in a secure log management or SIEM (Security Information and Event Management) system. Centralization prevents logs from being lost or altered on individual hosts and makes analysis easier.
– Protect logs with proper access controls – only authorized personnel (e.g. security team) should be able to view or manage logs. Enable write-once or append-only settings where possible, to prevent modification of past entries.
– Set log retention periods based on your forensic needs and compliance requirements (often logs are kept 6-12 months or longer). Ensure sufficient storage for logs and archive older logs securely.
Control 8.15 – Logging: For an extensive look at logging practices and requirements, read our dedicated Logging page, which explores this control thoroughly.
Control 8.16 Monitoring Activities
Establish continuous monitoring of systems, networks, and user activities to detect anomalies or signs of security incidents. Simply collecting logs isn’t enough – active monitoring (automated and human) is crucial for early threat detection. This control greatly enhances an organization’s ability to respond to incidents before they escalate.
Implementation Best Practices
– Deploy intrusion detection/prevention systems (IDS/IPS) on network perimeters to catch suspicious traffic or attacks (e.g. port scans, malware communication).
– Use a SIEM or security analytics platform to correlate events from different sources and raise alerts on indicators of compromise (e.g. multiple failed logins followed by a success, unusual after-hours access, system performance spikes that could indicate an attack).
– Set up a Security Operations Center (SOC) function – whether in-house or via a managed service – to continuously watch alerts and investigate them. Define procedures for triage and incident response when monitoring finds something (linking to control 8.22 and A.5 incident response controls).
– Monitor not just technical events but also use Data Leakage Prevention (DLP) monitoring (from control 8.12) and user behavior analytics to spot insider threats or policy violations.
Control 8.16 – Monitoring Activities: Find more information on effective monitoring by visiting our Monitoring Activities page, where we dive into the specifics of this control.
Control 8.17 Clock Synchronization
Synchronize the clocks of all relevant IT systems to a trusted time source. Accurate and consistent timestamps are critical for correlating log events across multiple systems and for establishing a reliable sequence of events during investigations. If system clocks differ, it becomes difficult to trace incidents or prove an event timeline.
Implementation Best Practices
- Use protocols like NTP (Network Time Protocol) or modern time services to sync servers, network devices, security appliances, and endpoints to the same accurate time (for example, syncing to an official time server or GPS time).
- Ensure your logging and monitoring infrastructure is also time-synced. The SIEM or centralized log server should ideally be the reference point for time.
- Protect NTP traffic – use authentication for NTP if available, and restrict which time servers are used, to prevent malicious manipulation of time.
- Regularly verify that critical systems are indeed synchronized (some monitoring tools can alert if a system’s clock drifts beyond a few seconds from the standard).
Control 8.17 – Clock Synchronization: Our Clock Synchronization page offers a deeper exploration of keeping systems in sync, so check it out for more insights into this control.
Why Controls 8.15 – 8.17 strengthen your ISMS
Logging and monitoring are detective controls that enable the organization to catch issues that preventive controls might have missed. They provide visibility into your environment, a cornerstone of any strong ISMS. Timely detection (with 8.15 and 8.16) means you can respond to security events before they cause major damage. Consistent clock synchronization (8.17) ensures the integrity and usefulness of your log data.
Secure Operations and Change Management (Controls 8.18–8.19, 8.32)
Operating IT systems securely day-to-day is just as important as designing them securely.
These controls address how administrative tools and software changes are handled in operation to prevent inadvertent security weaknesses.
(Note: We include control 8.32 here due to its close relation to operational changes.)
Control 8.18 Use of Privileged Utility Programs
Control the use of system utility programs that can override normal security controls. Examples include command-line shells, registry editors, debugging tools, or maintenance utilities that often come with operating systems and can be misused. Such tools should be tightly restricted because they can bypass or alter system security if abused.
Implementation Best Practices
- Inventory the privileged utilities and admin tools in your environment. Many OS have built-in utilities (like Powershell scripts, Linux binaries) that are powerful – document which are needed and approved.
- Restrict access: only system administrators or other authorized personnel should be able to execute these programs. This might involve file system permissions, central administration of who can log in with privileges, or using specialized PAM solutions to control usage.
- Log and monitor the use of such utilities (tie in with 8.15/8.16): any execution of a sensitive utility should be recorded, and consider alerts for their use on critical systems.
- If possible, disable or remove unnecessary utilities from production systems to reduce risk (for example, if a tool isn’t needed, uninstall it or restrict it via application control policies). Provide administrators with secure alternatives that have auditing.
Control 8.18 – Use of Privileged Utility Programs: If you’d like to dive deeper into controlling utility programs, visit our Use of Privileged Utility Programs page for comprehensive coverage of this control.
Control 8.19 Installation of Software on Operational
Regulate how new software or updates are installed on production (operational) systems. Uncontrolled installation can introduce malware or destabilize environments. This control ensures that only authorized, tested, and approved software is deployed in live systems.
Implementation Best Practices
- Establish a standard change and release management process (see control 8.32) for any software installations or updates in production. This includes requiring appropriate approvals, testing in a staging environment, and scheduling during maintenance windows.
- Least privilege principle: normal users should not have permissions to install or update software on their work computers or on servers. Use administrative rights carefully – for corporate PCs, consider using managed software deployment tools rather than giving users local admin.
- Maintain an approved software list for servers and workstations. Use application allow-listing where feasible to block any executables that are not on the approved list.
- Before installing new software, verify its source (download from official sites, check digital signatures or hashes to ensure it’s legitimate and unaltered). Also, ensure the software does not conflict with security policies (e.g., it’s configured securely post-installation).
Control 8.19 – Installation of Software on Operational Systems: To find out more about managing software installations securely, check our Installation of Software on Operational Systems page.
Control 8.32 Change Management
(Related to operations) Use a formal change management process for any significant changes to information systems, including software updates, configuration changes, or infrastructure modifications. The goal is to prevent uncontrolled changes from inadvertently introducing vulnerabilities or downtime. Every change should be evaluated for its impact on security, documented, tested, and approved before implementation.
Implementation Best Practices
- Set up a Change Advisory Board (CAB) or similar review team that assesses proposed changes (security team should be involved for assessing risks).
- Use a change request system to document each change: description, reason, expected impact, rollback plan, approvals, and results of testing.
- Categorize changes by risk: minor changes might follow a faster process, whereas major changes require full review and possibly scheduling outside business hours.
- After implementing changes, perform post-implementation testing and monitoring to ensure the change worked as intended and caused no security issues or regressions.
- Maintain an up-to-date network and system architecture documentation reflecting changes, and update operational procedures as needed when things change.
Control 8.32 – Change Management: More detailed information about managing changes can be found on our Change Management page, where we examine this control further.
Why Controls 8.18–8.19 & 8.32 strengthen your ISMS
Secure operational practices and change management maintain the integrity and stability of your production environment. By preventing unauthorized use of admin tools and by rigorously controlling software changes, you minimize the introduction of new risks during daily IT operations. These practices, especially when guided by Cyberzoni’s expertise, help your ISMS run smoothly – security is embedded into IT operations, not an afterthought.
Network Security Controls (Controls 8.20–8.23)
Network security is a major part of technological controls. Clause 8 dedicates several controls to safeguarding network infrastructure and usage, as breaches often begin with network-based attacks. These controls ensure your networks are well-defended, segmented, and that dangerous web content is filtered out.
Control 8.20 Network Controls
Implement baseline controls to secure your organization’s networks, including internal LANs, Wi-Fi, and connections to external networks. This general control covers protecting data as it moves across networks and making sure network infrastructure is hardened.
Implementation Best Practices
- Keep network equipment (routers, switches, wireless access points, firewalls) updated with the latest firmware and configured securely (change default passwords, disable unused services, etc.).
- Use network firewalls at key points (perimeter and between network segments) to filter traffic. Configure firewall rules following the least privilege approach – only allow necessary ports/protocols between authorized network zones.
- Encrypt sensitive network communications. For internal networks, this could mean using VPN tunnels or secure protocols (e.g. TLS, IPsec) especially when traversing untrusted segments.
- Implement network access control (NAC) to authenticate and control devices connecting to your networks (e.g., only allow company devices or known devices on the corporate LAN).
- Regularly monitor network traffic for anomalies (tie-in with monitoring in 8.16) and scan network devices for vulnerabilities (tie-in with 8.8).
Control 8.20 – Networks Security: We provide a deep dive on network security controls—see the Networks Security page for all the details on this control.
Control 8.21 Security of Network Services
Ensure that any network services your organization uses – whether provided internally or by third parties (ISP, cloud providers, etc.) – are securely managed and monitored. The objective is to protect the confidentiality and integrity of data as it transits networks and to maintain the reliability of the network services. This includes setting security requirements in contracts and verifying those are met.
Implementation Best Practices
- Identify security requirements for each network service (internet connectivity, leased lines, cloud networks, etc.). For example, require that the service provides encryption, DDoS protection, or meets certain uptime and security standards. Document these in Service Level Agreements (SLAs).
- If using external providers, ensure contracts give you the right to audit or review their security controls and incident reports. Obtain compliance attestations (e.g. SOC 2, ISO 27001 certificates) from critical network service providers.
- Internally, clearly define responsibilities for network security management – who manages firewalls, who monitors network traffic, etc. Ensure continuous network monitoring and periodic audits of the network service configuration (e.g., firewall rule reviews, penetration testing of network defense).
- Implement network usage guidelines for staff (acceptable use policy for internet, remote access rules) and provide training so users don’t inadvertently weaken network security (e.g. by misusing VPNs or installing unauthorized network devices).
Control 8.21 – Security of Network Services: Need more detail on securing network services? Our in-depth Security of Network Services page goes into greater depth on this control.
Control 8.22 Web Filtering
Reduce exposure to malicious or inappropriate websites by implementing web filtering controls. Many cyber threats (phishing, malware downloads) originate from user access to harmful web content. This control helps block access to known dangerous domains or categories of sites not needed for business. It also supports enforcement of organizational internet use policies.
Implementation Best Practices
- Use a secure web gateway or DNS filtering service that can automatically block access to websites categorized as malicious (malware, phishing), or other blacklisted categories (e.g. confirmed malicious IPs, botnet command-and-control servers).
- Configure browser settings or endpoint protection to prevent downloads from untrusted sources and to block or warn on visits to new or uncategorized domains.
- Maintain and update filtering lists: subscribe to threat intelligence feeds that provide up-to-date lists of bad domains. Also block newly seen domains which are often associated with phishing.
- Complement technical controls with user awareness: educate employees on acceptable web usage and how to recognize and avoid risky websites. Web filtering isn’t foolproof, so informed users add an extra layer of defense.
Control 8.22 – Segregation of Networks: For further reading on network segregation, visit our Segregation of Networks page, which offers detailed information and guidance.
Control 8.23 Segregation in Networks
Split your network into segmented zones or domains to control traffic and limit the impact of security incidents. Network segregation (or segmentation) means that different systems or user groups operate in isolated segments with controlled gateways between them. The purpose is to apply appropriate security levels to different areas (for example, isolating sensitive servers on a high-security subnet) and to prevent an intruder or malware from freely moving across the entire network.
Implementation Best Practices
- Design a network segmentation architecture based on business needs and data sensitivity. Typical segments could include: internal corporate network, production servers, DMZ for public-facing systems, development/test environment, guest Wi-Fi, etc. Each segment should have its own security controls and access rules.
- Use VLANs, subnetting, and firewalls to enforce segregation. For instance, put finance servers on a separate VLAN only accessible to finance staff network, protected by firewall rules that block other employees from reaching those servers.
- Limit connectivity between segments to only what’s necessary. For example, client PCs may need to reach a database server on a specific port, but they certainly don’t need to reach the hypervisor management network. By blocking all other connections, you contain threats.
- Monitor inter-segment traffic for any anomalies (an internal device trying to scan or connect to many hosts in another segment could indicate malware). Regularly review segmentation rules as systems and requirements evolve.
Control 8.23 – Web Filtering: To get the full picture of web filtering controls, check out our comprehensive Web Filtering page that explores this topic fully.
Why Controls 8.20–8.23 strengthen your ISMS
Network controls are fundamental preventive measures that guard the gates to your information. Proper network security (firewalls, segmentation, filtering) greatly reduces the attack surface and confines potential incidents to limited zones. This directly supports all three security principles – maintaining confidentiality and integrity by restricting unauthorized network access, and ensuring availability by protecting network services from widespread attacks.
Secure Development and System Lifecycle (Controls 8.25–8.31, 8.33 – 8.34)
A significant portion of Clause 8 covers controls for building and maintaining software and systems securely. These address incorporating security in every stage of development and deployment – from requirements and coding to testing and maintenance. For organizations that develop software or manage IT projects, these controls are vital to prevent vulnerabilities from being introduced during the system lifecycle.
Control 8.25 Secure Development Lifecycle
Integrate security activities into your system and software development lifecycle (SDLC). This control emphasizes that security should be considered at every phase – design, development, testing, deployment, and maintenance – rather than as an afterthought. Key aspects include separating development and production environments and following coding standards.
Implementation Best Practices
- Adopt a secure SDLC framework such as Microsoft SDL or OWASP SAMM. This provides guidelines like performing threat modeling during design, code review during development, and security testing before release.
- Ensure development, test, and production environments are separated (also see 8.31) to reduce risk of test activities affecting live systems and to protect live data. Developers should not be directly editing production code – changes should go through a controlled pipeline.
- Provide developers with secure coding training and guidelines (ties in with 8.28) so they are aware of common vulnerabilities (like SQL injection, XSS) and how to avoid them.
- Include security checkpoints in project workflows: e.g., security design review for new architectures, security sign-off before go-live. This makes security a built-in quality metric for every release.
Control 8.25 – Secure Development Life Cycle: If the secure development life cycle piques your interest, our detailed Secure Development Life Cycle page will provide more in-depth information about this control.
Control 8.26 Application Security Requirements
Identify and document specific security requirements for applications during their development or acquisition. Rather than retrofitting security, this control ensures that from the outset, an application’s needed protections are known (based on risk assessment) and implemented.
Implementation Best Practices
- Perform a risk assessment or threat modeling for each important application to uncover security risks (e.g., if an app processes credit card data, a requirement might be to encrypt that data and comply with PCI DSS).
- Derive clear security requirements from those risks – for example, “The application shall enforce password complexity and lockout after 5 failed attempts” or “All data in transit shall use TLS 1.2 or above.” Include requirements for access control, data validation, logging, input sanitation, etc.
- Make these security requirements part of the functional requirements/specifications that developers and testers use. This way, security is treated as equally important as other features.
- During testing, verify that each security requirement is met (through security test cases or checklist). If you use user stories (Agile), incorporate security acceptance criteria.
Control 8.26 – Application Security Requirements: Dive deeper into application security requirements by visiting our Application Security Requirements page, where every aspect of this control is explored.
Control 8.27 Secure System Architecture and Engineering Principles
Follow established security architecture principles when designing systems and services. This control is about high-level design – ensuring that systems are structured to be secure by design, leveraging concepts like defense-in-depth, least privilege, and resilience. The goal is to bake security into the architecture so that it’s robust against attacks throughout its lifecycle.
Implementation Best Practices
– Develop or adopt a set of security architecture principles (e.g., use layered defenses, minimize attack surface, fail-safe defaults, secure default configurations). Ensure solution architects are trained to apply these.
– When designing a new system or significant update, have a security architect review the design. Consider how data flows through the system and where security controls (e.g. encryption, validation, monitoring) should be applied.
– Ensure segregation of duties in architecture – e.g., separate components for different roles (client vs server logic), use network segmentation (tie to 8.23) as part of design, and segregate administration interfaces from user interfaces.
– Document the security architecture and keep it updated as systems evolve. This helps during audits and also as a reference for future improvements or incident response (knowing where critical assets and trust boundaries are).
Control 8.27 – Secure System Architecture and Engineering Principles: Our Secure System Architecture and Engineering Principles page contains an in-depth exploration of this control—check it out for more knowledge and best practices.
Control 8.28 Secure Coding
Emphasize secure coding practices in software development to minimize vulnerabilities in code. This control underlines that developers should consistently apply secure coding standards and techniques throughout development, not just during final testing. Given the prevalence of software in all organizations, implementing secure coding is crucial to prevent common flaws like injection attacks, buffer overflows, etc..
Implementation Best Practices
– Establish a secure coding standard for the programming languages and frameworks your organization uses. This could reference industry guides like OWASP Secure Coding Practices. Include rules for input validation, error handling, authentication, encryption usage, etc.
– Train developers on these standards and on common vulnerabilities (OWASP Top 10 for web apps, CWE/SANS Top 25, etc.). Ensure new developers get this training as part of onboarding.
– Use static application security testing (SAST) tools to scan source code for known insecure patterns or errors. Integrate these scans into the build process (CI pipeline) so issues are caught early.
– Perform code reviews with a security mindset. Peer reviews or automated pull request checks can catch insecure code snippets before they merge into the main codebase.
– Encourage a culture where developers proactively think about security “before, during, and after” coding – meaning they design securely, code with security in mind, and test for security as part of done criteria.
Control 8.28 – Secure Coding: For a comprehensive guide to secure coding, see our Secure Coding page, which delves into this control thoroughly.
Control 8.29 Security Testing in Development and Acceptance
Include dedicated security testing as part of the software testing life cycle, especially in development (unit/integration testing) and pre-release acceptance testing. This control ensures that beyond functional tests, you verify the system’s security controls and try to find vulnerabilities before going live.
Implementation Best Practices
– Develop security test cases or a security test plan for each project. This might involve testing secure configuration (e.g., ensuring default passwords are changed, unnecessary ports closed), testing access controls (can users access only what they should), and input fuzzing to see if the application can be broken.
– Use dynamic application security testing (DAST) tools or vulnerability scanners on applications in a test environment to find issues like SQL injection, XSS, insecure server configurations, etc.
– Conduct penetration testing for major releases or high-risk applications. Engage internal or external ethical hackers to simulate attacks on the system (in a non-production environment) and fix any weaknesses found.
– Ensure criteria for acceptance include “no critical/high security defects outstanding.” If testing uncovers serious vulnerabilities, those must be remediated or formally risk-accepted by management before go-live.
– For infrastructure changes, incorporate security checks as well – e.g., scanning a new server build for open ports or weak settings as part of acceptance.
Control 8.29 – Security Testing in Development and Acceptance: Want to explore testing processes in more detail? Visit our in-depth Security Testing in Development and Acceptance page for additional insights on this control.
Control 8.30 Outsourced Development
When outsourcing software development or working with third-party developers, ensure that security requirements and controls are extended to those external parties. This control covers establishing security expectations in contracts and monitoring the security of outsourced work.
Implementation Best Practices
– Include detailed security clauses in contracts with development vendors: they should adhere to your secure coding standards, possibly use your secure development environment or tools, and agree to security testing and code review processes. Also address IP rights and code ownership (to avoid dependencies that could become risks).
– Require confidentiality agreements and possibly background checks for the vendor’s developers if they will access sensitive data or systems.
– Request regular progress updates and access to review code or test results to ensure security is being taken seriously. Make security checkpoints part of the outsourcing project milestones.
– Upon delivery, treat outsourced code with the same rigor as internal code: run it through your security testing (8.29) and code review. If possible, audit the vendor’s development process or ask for evidence of their security practices (some organizations demand an ISO 27001 certification or similar from key suppliers).
Control 8.30 – Outsourced Development: We have a dedicated Outsourced Development article offering a deeper dive—visit it for more details on implementing this control.
Control 8.31 Separation of Development, Test, and Production Environments
Maintain strictly separated environments for development, testing, and production to reduce the risk of unauthorized changes reaching live systems and to protect live data. The idea is to prevent a scenario where testing or development activities accidentally disrupt production or where developers have unmonitored direct access to live systems.
Implementation Best Practices
– Set up physically or logically separate network zones for development, QA/test, and production. For instance, development and test servers should be on different VLANs or cloud accounts than production, with no direct connectivity unless through controlled deployment pipelines.
– Control access: Developers and testers should typically not have access to production environment credentials or data. If they need to troubleshoot, it should be through controlled procedures and with monitoring.
– Use anonymized or synthetic data in test environments whenever possible (tie to control 8.33 Test Data). Do not use real customer data for testing unless absolutely necessary and approved, and even then ensure it’s masked or protected.
– Ensure changes flow one-way: e.g., code moves from dev → test → prod through a release process. Prevent situations where production data is copied to dev without controls or where test code could accidentally deploy to prod.
– Clearly label and communicate environment differences so everyone understands where they are working. Enforce configuration differences (e.g., production has full logging and monitoring, debug modes off, while dev can have those on).
Control 8.31 – Separation of Development, Test and Production Environments: To find out more about environment separation, check our detailed Separation of Development, Test and Production Environments page on CyberZoni for an exhaustive overview of this control.
Control 8.33 Test Information
Protect data used in testing to ensure sensitive real data is not inadvertently exposed, and that testing does not violate privacy or confidentiality. The control calls for carefully selecting or sanitizing test data – ideally using dummy data or anonymized copies – and ensuring any live data used is safeguarded and purged after testing.
Implementation Best Practices
– Whenever possible, use synthetic (made-up) datasets for testing. This avoids any risk since the data is not real. Use data generation tools to create realistic but fake test data.
– If real data must be used (for example, production data to replicate a complex issue), apply techniques like data anonymization or masking (related to 8.11) before using it in test. Remove personal identifiers, shuffle values, or encrypt sensitive fields so that testers can do their job without seeing actual confidential info.
– Limit access to test data – only the test team or relevant developers should access it, and they should handle it as per its sensitivity (e.g., if using a subset of customer data, those team members should be authorized for that data and bound by confidentiality).
– Dispose of test data properly once testing is done. If you imported some production data into a test database, ensure it’s deleted or returned to secure storage after the tests. Don’t leave sensitive data lingering in lower environments indefinitely
Control 8.33 – Test Information: To see how to handle test data securely in greater detail, refer to our Test Information page for an in-depth explanation of this control.
Control 8.34 Protection of Information Systems during Audit and Testing
Ensure that security audits, penetration tests, or other technical reviews do not negatively impact production systems or expose data. In other words, when you conduct audits or tests on live systems, do so carefully to avoid disruptions or breaches.
Implementation Best Practices
– Plan audits and tests on production systems in advance. Schedule them for low-usage periods if possible and coordinate with IT operations so they are aware and on standby in case any issues arise. Define scope clearly to testers/auditors so they know what is off-limits or fragile.
– For audits, provide read-only access wherever possible. For example, if auditors need to review configurations or data, give them accounts that can view but not change anything. Monitor their access in real time.
– If running penetration tests on production, ensure the testing is done by trusted personnel under strict rules of engagement. Consider doing certain tests in a staging environment identical to prod to avoid downtime. Any aggressive testing on live systems should have explicit management approval and fail-safe measures.
– Backup critical systems or data before testing (especially penetration testing), so that if something goes wrong (e.g., a fuzz test crashes a server), you can recover quickly.
– After tests/audits, promptly revoke any special access that was given and have a debrief to capture any lessons or needed fixes.
Control 8.34 – Protection of Information Systems During Audit Testing: For a deep exploration of safeguarding systems during audits, our Protection of Information Systems During Audit Testing page provides extensive coverage—be sure to check it out.
Why Controls Controls 8.25 – 8.31, 8.33 – 8.34 strengthen your ISMS
Integrating security into the development lifecycle and operations means your organization is building security into its products and infrastructure from the ground up.
This dramatically reduces vulnerabilities and ensures long-term maintainability of security. Controls 8.25–8.31 and 8.33–8.34 contribute to a culture of “security by design and by default,” which not only prevents issues but also makes compliance repeatable.
Conclusion: Building a Strong ISMS with Clause 8 Controls
ISO/IEC 27001:2022 Clause 8 – Technological Controls – represents the “nuts and bolts” of information security.
These 34 measures collectively protect the CIA triad (Confidentiality, Integrity, Availability) of information, thereby reducing the likelihood and impact of security incidents.
Moreover, Clause 8 controls work in concert with organizational (Clause 5), people (Clause 6), and physical (Clause 7) controls to form a holistic ISMS that addresses risk from every angle.
For small businesses and enterprises alike, the key to success is not just checking off controls, but integrating them into everyday operations and culture.
A strong ISMS is a living program – Clause 8 provides the technical framework.