ISO 27001 Operational Security: Procedures and Responsibilities
ISO 27001 operational security, governed by Annex A.12, defines the procedures, responsibilities and controls for ensuring that information security operations run correctly, consistently and without interruption. This includes secure operating procedures, change and capacity management, malware defence, backups, logging, monitoring and software installation policies – all core to an effective ISMS.
Author: Mustafa Hasan · Published: 25 July 2026 · Last updated: 25 July 2026
What Is Operational Security Under ISO 27001?
Operational security in the ISO 27001 framework refers to the day-to-day controls and responsibilities that keep an information security management system (ISMS) functioning. Annex A.12 in ISO 27001:2022 consolidates the operational controls that organisations must implement to protect their information assets during normal business operations. Unlike strategic or design-phase activities, operational security is about what happens every hour of every working day – who does what, how changes are approved, how capacity is monitored, how malware is prevented, how data is backed up and how activity is logged.
Annex A.12 contains seven control objectives, each with specific controls that must be addressed in the Statement of Applicability (SoA).
Annex A.12 Requirements at a Glance
| Control ID | Control Name | Purpose |
|---|---|---|
| A.12.1 | Operational procedures and responsibilities | Document, approve and maintain operating procedures for all information processing facilities |
| A.12.2 | Protection from malware | Detect, prevent and recover from malware across the organisation |
| A.12.3 | Backup | Maintain retrievable copies of information and software in line with policy |
| A.12.4 | Logging and monitoring | Record user activities, exceptions and events; protect and review logs |
| A.12.5 | Control of operational software | Prevent unauthorised installation and modification of software |
| A.12.6 | Technical vulnerability management | Identify, evaluate and remediate technical vulnerabilities promptly |
| A.12.7 | Information systems audit considerations | Minimise the impact of audit activities on production systems |
Operating Procedures and Responsibilities (A.12.1)
Every information processing facility must have documented operating procedures. These are not optional policy documents – they are the step-by-step instructions that operators, administrators and support staff follow to carry out their duties consistently and securely.
Operating procedures under A.12.1 must cover:
- Start-up and close-down procedures for systems and equipment
- Backup and restoration steps
- Equipment maintenance schedules
- Incident handling procedures
- Media handling and disposal
- Physical and environmental controls for server rooms and network cabinets
- Contact escalation paths for operational failures
Procedures must be approved by management, reviewed at planned intervals and updated when processes change. A procedure that nobody follows or that references a retired system is worse than no procedure at all – it creates a false sense of control.
Separation of development, testing and operational environments
A.12.1 also requires that development, testing and production environments are separated to reduce the risk of unauthorised access or changes to the operational environment. This is one of the most frequently cited findings in certification audits, particularly in organisations where developers require production access to troubleshoot live issues.
Change Management (A.12.1.2)
Changes to information processing facilities must be controlled. A formal change management process ensures that every change – whether a server patch, a firewall rule update, a software upgrade or a configuration tweak – is assessed for security impact, approved by the appropriate authority, tested where possible, documented and implemented in a controlled manner.
The key elements of an ISO 27001-compliant change management process are:
- Change request submission with a clear description and business justification
- Security impact assessment before approval
- Approval by the designated change authority
- Testing in a non-production environment where feasible
- Implementation plan with rollback instructions
- Post-implementation review
- Record-keeping for audit purposes
Capacity Management (A.12.1.3)
Capacity management ensures that information processing facilities have sufficient resources to meet current and anticipated demand without degradation of security. This is not a pure IT operations concern – capacity exhaustion has direct security consequences. When a system runs out of disk space, memory or network bandwidth, logging stops, backups fail and security controls may be bypassed.
An effective capacity management process includes:
- Monitoring of CPU, memory, disk and network utilisation against baselines
- Trend analysis to predict when resources will be exhausted
- Capacity planning aligned with business growth projections
- Alerting at defined thresholds
- Annual capacity review as part of the management review process
| Resource Type | Typical Monitoring Metric | Alert Threshold | Review Frequency |
|---|---|---|---|
| Storage | Disk utilisation percentage | 80% utilised | Weekly |
| Compute | CPU utilisation | 75% sustained over 1 hour | Daily |
| Memory | RAM utilisation | 80% utilised | Daily |
| Network | Bandwidth utilisation | 70% of link capacity | Weekly |
| Backup media | Free space in backup repository | 20% remaining | Daily |
Malware Protection (A.12.2)
Protection from malware requires a combination of technical controls, user awareness and management oversight. Annex A.12.2 expects organisations to deploy malware detection and prevention controls across all endpoints, servers and email gateways, and to maintain current signatures and detection engines.
An effective malware protection programme includes:
- Anti-malware software on all endpoints and servers, centrally managed
- Email and web gateway filtering
- Signature updates deployed within 24 hours of release
- Regular full scans of systems
- User awareness training on phishing and social engineering
- Prohibition on installing unauthorised software (linked to A.12.5)
- Incident response procedures for confirmed infections
Organisations should also consider the use of application allow-listing and sandboxing for high-risk environments. Mobile device management (MDM) policies reduce the risk of malware entering through personal devices that access corporate resources.
Backup Policies and Procedures (A.12.3)
Annex A.12.3 requires that backup copies of information, software and system images are taken regularly in accordance with an agreed backup policy. Backup is not a one-size-fits-all control – the frequency, retention period and storage location depend on the criticality of the information and the recovery objectives of the business.
| Data Category | Backup Frequency | Retention | Storage Type |
|---|---|---|---|
| Critical business databases | Daily full + hourly transaction logs | 7 years (or as required by regulation) | Encrypted offsite + cloud |
| File servers and documents | Daily incremental, weekly full | 1 year | Encrypted offsite |
| Email systems | Daily | 90 days to 7 years (by policy) | Cloud or on-premises |
| System images and configurations | After every significant change, minimum monthly | 6 months | Local + offsite |
| Log data | Real-time streaming to SIEM | 12 months (active), 7 years (archived) | Immutable storage |
Backup restoration must be tested at least annually, and the results must be documented. Many organisations pass their certification audit on policy but fail on evidence of restoration testing. An untested backup is a hope, not a control.
Logging and Monitoring (A.12.4)
Logging and monitoring provide the audit trail that makes every other operational control enforceable. Without logs, you cannot detect an intrusion, investigate an incident, prove compliance or hold users accountable for their actions.
Annex A.12.4 requires organisations to:
- Produce and retain event logs for user activities, exceptions, faults and security events
- Protect logs against tampering and unauthorised access
- Review logs regularly, with automated alerting for critical events
- Synchronise system clocks across the organisation (using NTP or equivalent)
- Define log retention periods based on legal, regulatory and business requirements
At minimum, the following events should be logged across all production systems:
- Successful and failed logon attempts
- Privileged account usage
- Changes to user permissions and group memberships
- System startup and shutdown
- Configuration changes, especially to security controls
- Data export and transfer events
- Access to sensitive or classified information
- Error and warning events from security software
Logs should be sent to a centralised logging platform or SIEM with write-once, read-many (WORM) storage to prevent tampering. Log monitoring should be a 24/7 function for larger organisations, with defined escalation paths for security incidents.
Software Installation Policies (A.12.5)
Control of operational software under A.12.5 requires strict policies governing the installation of software on production systems. Unauthorised software is a leading cause of malware infections, compliance failures and system instability.
The key requirements are:
- A formal policy prohibiting installation of unauthorised software
- Technical controls to enforce the policy (application allow-listing, software restriction policies, or MDM)
- Approval process for new software requests, including a security review
- Inventory of all approved software titles and versions
- Regular audits of installed software against the approved inventory
- Removal of unapproved software found during audits
For organisations that use bring-your-own-device (BYOD) arrangements, A.12.5 must be addressed through containerisation or MDM profiles that separate corporate applications from personal ones. The policy should also cover software-as-a-service (SaaS) applications, which are increasingly the source of unapproved software use (shadow IT).
Technical Vulnerability Management (A.12.6)
Technical vulnerability management is the process of identifying, classifying, prioritising and remediating security vulnerabilities in software, firmware and hardware. A.12.6 requires organisations to maintain current information about technical vulnerabilities, evaluate organisational exposure and take appropriate action.
A mature vulnerability management programme includes:
- Regular vulnerability scanning of all networked assets (at least quarterly, ideally monthly)
- Patch management with defined SLAs by severity (critical within 14 days, high within 30 days)
- A risk-based prioritisation framework (CVSS scores alone are insufficient; consider exploitability, asset criticality and threat intelligence)
- Testing of patches in a non-production environment before deployment
- Reporting to management on vulnerability posture and remediation progress
Information Systems Audit Considerations (A.12.7)
A.12.7 addresses the delicate balance between audit requirements and production system stability. Audit activities – whether internal or external – must be planned and supervised to minimise the risk of disrupting business operations. This control is particularly relevant during ISO 27001 Stage 2 audits, certification body surveillance visits and internal audit campaigns.
The control requires:
- Audit planning that avoids peak operational periods where possible
- Read-only access for auditors to production systems, with segregation between audit tools and operational tools
- Supervision of audit activities by operational staff
- Formal approval before any audit tool is connected to a production environment
- Post-audit review to ensure no unauthorised changes were made
Implementing Annex A.12 Controls: A Practical Approach
Organisations implementing Annex A.12 controls for the first time should start with a gap analysis of existing operational procedures against each A.12 sub-control. Common gaps include:
| Common Gap | Typical Root Cause | Remediation Approach |
|---|---|---|
| No documented operating procedures | Relies on staff knowledge and verbal handover | Create role-specific procedure documents; involve process owners in writing them |
| Change management is informal | Small team with direct access to production | Implement a lightweight change workflow with mandatory security review |
| Backup restoration is not tested | No scheduled testing cycle | Schedule quarterly restoration tests for critical systems |
| Logs are collected but not reviewed | No monitoring resource or SIEM | Implement automated alerting for critical events as a minimum |
| No vulnerability scanning programme | No dedicated security resource | Start with monthly external and internal scans using an accredited scanning provider |
Frequently Asked Questions
What is the difference between Annex A.12 and other ISO 27001 operational controls?
Annex A.12 specifically addresses day-to-day operational security procedures and responsibilities. Other Annex A controls cover topics such as access control (A.9), cryptography (A.10), physical security (A.11) and supplier relationships (A.15). A.12 is the operational backbone that makes the other controls effective through documented procedures, change management, backups and monitoring.
Does ISO 27001 require a SIEM for logging and monitoring?
No. ISO 27001 does not mandate a specific technology for logging and monitoring. A.12.4 requires that event logs are produced, retained, protected and reviewed. A SIEM is one way to achieve this for larger environments, but smaller organisations can meet the requirement with centralised syslog, a basic log management tool and a defined schedule for manual log review. The key is that logs must be reviewed and the review must be evidenced.
How often must backup restoration be tested under ISO 27001?
Annex A.12.3 does not specify a frequency for restoration testing, but certification bodies and auditors expect at least annual testing, with quarterly testing for critical systems. The test results must be documented, and any failures must trigger corrective action. Best practice aligns backup testing with the organisation’s business continuity exercise schedule.
What software installation controls are required for BYOD environments?
For BYOD environments, A.12.5 requires that the organisation extend its software control policy to cover devices accessing corporate data. Technical controls such as mobile device management (MDM), containerisation and virtual desktop infrastructure (VDI) are typical methods. The policy should also require employees to affirm that they will not install unauthorised software on devices used for work.
How do you separate development, testing and production environments?
Separation can be physical (different servers and network segments), logical (virtual LANs and access control lists) or cloud-based (separate accounts or projects). The key requirement is that code and data cannot move from development to production without passing through a controlled change management process. Production credentials must never be used in non-production environments.
What is the auditor looking for during an A.12 review?
The auditor will examine documented operating procedures, a change management log with approved changes, backup records with restoration test evidence, log review records showing regular review, vulnerability scan reports with remediation tracking, and evidence that software installation is controlled. They will also interview operators to verify that documented procedures match actual practice.
How Bitrixme Can Help
Bitrixme provides consultancy, gap analysis, implementation support, internal auditing and training for ISO 27001 certification. Certification audits are conducted by an independent accredited certification body. We prepare you for that audit; we do not issue the certificate.
Our ISO 27001 operational security support includes:
- Gap analysis against Annex A.12 controls
- Documented operating procedure templates
- Change management process design
- Backup policy and schedule development
- Logging and monitoring architecture advice
- Software control policy development
- Internal audit services
- ISO 27001 internal auditor training
Contact Bitrixme for a free 30-minute consultation, or reach us on WhatsApp to discuss your ISO 27001 operational security requirements.
Related reading: ISO 27001 Annex A Controls: The Complete List · ISO 27001 Gap Analysis · ISO 27001 Risk Assessment
