Key Takeaways
- Operations security focuses on how systems are run and maintained day to day.
- Annex A.12 was the Operations Security domain in ISO/IEC 27001:2013. Its controls were redistributed in ISO/IEC 27001:2022.
- Operational procedures ensure systems are managed consistently.
- Change management protects systems from risky updates.
What Is ISO 27001 Operations Security?
Operations security in ISO 27001 refers to the controls that ensure an organization’s information systems operate securely daily. It addresses how systems are actually run, monitored, and maintained once they are deployed.
Even very well-designed systems are at risk of becoming vulnerable during normal operations. Operations security ISO 27001 manages this risk by introducing structured operational processes. These processes help ensure that systems remain stable.
Where Is Operations Security in ISO 27001:2022?
Operations Security” was a control domain in ISO/IEC 27001:2013, where it appeared as Annex A.12. ISO/IEC 27001:2022 no longer includes Annex A.12 or a separate domain called Operations Security. However, the underlying controls remain relevant and are now distributed across the 2022 Annex A structure, primarily among the Technological controls.
These safeguards cover areas such as:
- documenting operating procedures
- managing system changes
- protecting systems from malware
- maintaining backups
- logging and monitoring system activity
- managing technical vulnerabilities
- controlling software installation
- separating development, testing, and production environments
ISO 27001:2022 Operations Security Controls
The controls associated with day-to-day operations are no longer grouped under a single Operations Security domain. In ISO/IEC 27001:2022, they appear across the Organizational and Technological themes.
Documented operating procedures (5.37)
Organizations should document the procedures used to operate their information systems. These procedures should be reviewed when needed and made available to the people responsible for system operations.
Documented procedures support consistent system management, simplify staff training, and preserve operational knowledge when personnel change.
Change management (8.32)
IT environments change as systems are updated, applications are deployed, and infrastructure evolves.
Changes to information-processing facilities and systems should follow established change-management procedures. Changes should be assessed, authorized, tested, documented, and reviewed to reduce the risk of vulnerabilities or service disruption.
Capacity management (8.6)
Capacity management focuses on ensuring that systems have sufficient resources to operate reliably.
Organizations should monitor resource use and adjust capacity to meet current and expected requirements. This can include storage, computing power, memory, and network bandwidth.
Separation of development, test, and production environments (8.31)
Development, testing, and production environments should be separated and secured.
This separation reduces the risk that experimental code or configuration changes will affect operational systems. It also protects production information from unnecessary exposure during development and testing.
Protection against malware (8.7)
Organizations should implement measures to protect systems against malware.
Malware protection commonly includes endpoint security tools, user awareness, detection and recovery processes, and restrictions on unauthorized software installation.
Information backup (8.13)
Backup copies of information, software, and systems should be maintained and regularly tested in accordance with an established backup policy.
Backups help protect organizations from data loss caused by system failures, cyberattacks, or accidental deletion. Testing confirms that information and systems can be restored when needed.
Logging (8.15)
Systems should produce logs that record activities, exceptions, faults, and other relevant events.
Logs should be stored, protected against unauthorized access or modification, and analyzed when appropriate. Logging should include relevant administrator and operator activity.
Monitoring activities (8.16)
Networks, systems, and applications should be monitored for anomalous behavior.
Potential information security incidents should be evaluated and addressed through the organization’s incident management process.
Clock synchronization (8.17)
The clocks used by information-processing systems should be synchronized with approved time sources.
Consistent timestamps help organizations correlate logs and reconstruct events during incident investigations.
Installation of software on operational systems (8.19)
Software installation on operational systems should follow established procedures and authorization processes.
Organizations should limit users’ ability to install software on corporate systems. Approved software catalogs, deployment tools, testing, and rollback procedures can reduce the risk of unauthorized or vulnerable applications entering the environment.
Management of technical vulnerabilities (8.8)
Organizations should obtain information about technical vulnerabilities affecting their systems, evaluate their exposure, and take appropriate action.
Security teams commonly use vulnerability scanning, risk-based prioritization, patching, mitigation, and remediation tracking to manage identified vulnerabilities.
Protection of information systems during audit testing (8.34)
Audit tests and other assurance activities involving operational systems should be planned and agreed upon in advance.
Testing should be authorized and coordinated with relevant teams to prevent service disruption, unauthorized access, or unintended changes to operational systems.
Start Getting Value With
Centraleyes for Free
See for yourself how the Centraleyes platform exceeds anything an old GRC
system does and eliminates the need for manual processes and spreadsheets
to give you immediate value and run a full risk assessment in less than 30 days
FAQs
What kind of evidence do auditors usually request for operations security controls?
Auditors typically request operational records rather than ISO 27001 operations security policy documents. Examples include change approval tickets, backup test results, vulnerability remediation reports, system monitoring alerts, and administrator activity logs. These records demonstrate that operational controls are functioning as intended.
How do organizations apply operations security controls in cloud environments?
Many organizations extend their operational monitoring tools into cloud platforms. Logs, vulnerability data, and system metrics are aggregated into centralized monitoring platforms so security teams can maintain visibility across both traditional infrastructure and cloud services.
What operational mistakes commonly lead to security incidents?
Common issues include unapproved system changes, delayed patching of critical vulnerabilities, failure to review security logs, and poorly tested backup procedures. These issues often arise when operational processes are informal or inconsistently followed.
How do organizations handle urgent system fixes without bypassing change management?
Most organizations implement emergency change procedures. These allow urgent updates to be deployed quickly while still requiring documentation and retrospective approval after the change has been made.
Start Getting Value With
Centraleyes for Free
See for yourself how the Centraleyes platform exceeds anything an old GRC
system does and eliminates the need for manual processes and spreadsheets
to give you immediate value and run a full risk assessment in less than 30 days
