ISO 27001 and Security Operations Centers (SOC)
ISO 27001 is the international benchmark for information security management systems (ISMS). A Security Operations Center (SOC) – whether built in-house or outsourced – is one of the most effective operational mechanisms for meeting the standard’s requirements around monitoring, detection, analysis, and response. Organisations pursuing ISO 27001 certification often underestimate the operational capability required to sustain the logging, monitoring, and incident response controls in Annex A. This article examines the relationship between ISO 27001 and SOC operations in depth, covering Annex A.12 logging and monitoring controls, core SOC functions, SIEM architecture, threat intelligence, incident response, SOC maturity models, and the critical considerations around outsourcing your SOC.
SOC Requirements Under ISO 27001
ISO 27001 does not explicitly mandate a SOC, but the controls in Annex A create a clear operational need for one. Organisations seeking certification must demonstrate that they monitor, detect, analyse, and respond to information security events in a systematic and repeatable manner. A SOC provides the dedicated capability to deliver these outcomes at scale, with defined processes, skilled personnel, and appropriate technology.
The standard’s requirements that directly drive SOC capability include:
- A.12.4.1 – Event logging: production of records of user activities, exceptions, faults, and security events
- A.12.4.2 – Protection of log information: ensuring logs are protected against tampering and unauthorised access
- A.12.4.3 – Administrator and operator logs: privileged user activity monitoring
- A.12.6.1 – Management of technical vulnerabilities: timely identification and remediation of vulnerabilities
- A.16.1.1 – Responsibilities and procedures for incident response: documented and assigned roles
- A.16.1.5 – Response to information security incidents: effective containment and recovery
- A.16.1.7 – Collection of evidence: forensic readiness and chain of custody
Without a SOC, organisations often struggle to meet these controls effectively. Logs are collected but not analysed. Alerts are generated but not triaged. Incidents are documented but root causes are never established. A SOC bridges the gap between the standard’s requirements and operational reality.
Annex A.12: Logging and Monitoring in Detail
Annex A.12 of ISO 27001 is the most directly relevant clause for SOC operations. It addresses operational security with a specific focus on logging and monitoring. Understanding each control and its SOC implementation is essential for audit readiness.
| Control | Requirement | SOC Implementation | Evidence for Auditor |
|---|---|---|---|
| A.12.4.1 | Event logs recording user activities, exceptions, faults, and security events | Centralised log collection and correlation via SIEM (syslog, Windows Event Collection, cloud API ingestion) | Log source inventory, SIEM architecture diagram, log retention policy |
| A.12.4.2 | Logging facilities and log information protected against tampering and unauthorised access | Log integrity monitoring, write-once-read-many (WORM) storage, role-based access controls for log repositories | Access control lists, log integrity verification reports |
| A.12.4.3 | Activities of system administrators and operators are logged | Privileged access management (PAM) integration, user and entity behaviour analytics (UEBA) | Privileged user activity reports, session recordings |
| A.12.4.4 | Clock synchronisation across systems | Network Time Protocol (NTP) infrastructure with authenticated time sources and monitoring | NTP configuration, time synchronisation audit reports |
A SOC that aligns with ISO 27001 must ensure that logging is complete, tamper-proof, time-synchronised, and retained in accordance with the organisation’s documented retention policy. Each of these elements should be verifiable by an external auditor.
Core SOC Functions
A fully functioning SOC delivers a set of interconnected capabilities that map directly to ISO 27001 requirements. These functions must be documented, resourced, and tested as part of the ISMS scope.
| SOC Function | ISO 27001 Alignment | Description | Key Metrics |
|---|---|---|---|
| Monitoring & Detection | A.12.4, A.12.6 | Continuous monitoring of logs, network traffic, endpoints, cloud environments, and identity systems for security events | Time to detect (TTD), alert volume, false positive rate |
| Triage & Analysis | A.16.1.1, A.16.1.2 | Initial assessment of alerts to determine validity, severity, scope, and priority for escalation | Triage time, escalation rate, mean time to triage |
| Incident Response | A.16.1.5, A.16.1.6 | Containment, eradication, recovery, evidence preservation, and post-incident reporting | Mean time to respond (MTTR), containment time, incident closure rate |
| Threat Intelligence | A.6.1.1, A.12.6 | Collection, analysis, and operationalisation of threat data to inform detection rules and defensive posture | Threat feed coverage, intelligence-driven detections |
| Forensic Investigation | A.16.1.7 | Digital forensic evidence collection, chain of custody, analysis, and reporting | Evidence integrity rate, forensic case closure time |
| Reporting & Improvement | A.16.1.6, Clause 9, Clause 10 | SOC performance metrics, management reporting, trend analysis, and continuous improvement of the ISMS | Report timeliness, improvement action closure rate |
ISO 27001 auditors will expect to see evidence that each of these functions operates effectively and is subject to defined management review and continual improvement processes. SOC leadership should maintain a function-by-function mapping to the ISMS scope.
SIEM and ISO 27001 Compliance
The Security Information and Event Management (SIEM) system is the technical backbone of any ISO 27001-aligned SOC. It aggregates logs from across the organisation, correlates events using defined rules, generates actionable alerts, and retains evidence for audit and forensic purposes.
For ISO 27001 compliance, the SIEM must be configured and operated to meet the following requirements:
- Collect logs from all in-scope systems (servers, network devices, security appliances, applications, cloud services, identity providers)
- Normalise log formats to enable cross-system correlation
- Apply correlation rules aligned with the organisation’s risk assessment and threat model
- Generate alerts with defined severity levels and clear escalation paths
- Retain logs for the period specified in the organisation’s retention policy (typically six months to two years for operational logs, longer for forensic purposes)
- Protect log integrity through immutability controls and access restrictions
- Synchronise clocks across all log sources using authenticated NTP
SIEM tuning is an ongoing activity, not a one-time deployment. A poorly tuned SIEM generates excessive noise that overwhelms analysts and obscures genuine security events. SOC leadership should ensure that use cases are regularly reviewed against the organisation’s risk register and threat intelligence feeds. Tuning should be documented as part of the SIEM change management process.
Threat Intelligence in the SOC
ISO 27001’s risk-based approach requires organisations to understand the threat landscape in which they operate. A SOC consumes threat intelligence to stay ahead of adversaries and to ensure that detection and response capabilities remain relevant. Intelligence sources include open-source feeds, commercial threat intelligence platforms, industry Information Sharing and Analysis Centers (ISACs), and government computer emergency response teams (CERTs).
For ISO 27001 compliance, threat intelligence must be integrated into the SOC in a structured way:
- Indicators of compromise (IoCs) ingested into SIEM correlation rules
- Threat actor intelligence used to inform vulnerability management prioritisation
- Intelligence sources documented as inputs to the risk assessment process
- Relevant intelligence fed into incident response playbooks and tabletop exercises
- Intelligence quality and relevance subject to regular review
The ISO 27001 auditor will look for evidence that threat intelligence drives tangible security improvements, not just that a feed is being consumed. Organisations should be able to demonstrate specific detection rules or process changes that resulted from threat intelligence analysis.
Incident Response and ISO 27001
Incident response is a mandatory capability under ISO 27001. Annex A.16 requires organisations to establish responsibilities, procedures, and communication plans for handling information security incidents. The SOC operationalises these requirements through defined playbooks, trained personnel, and integrated tooling.
Key incident response compliance areas include:
- Incident classification and severity levels aligned to business impact
- Documented response playbooks for each incident type (ransomware, data breach, denial of service, insider threat, etc.)
- Clearly assigned roles: SOC analyst, incident commander, communications lead, legal liaison, executive sponsor
- Escalation procedures for major incidents, including criteria for invoking the crisis management team
- Forensic evidence collection and chain-of-custody procedures compliant with A.16.1.7
- Post-incident reviews with root cause analysis and corrective action tracking (Clause 10.1)
ISO 27001 requires that incidents are not just responded to, but that lessons are learned and systematically fed back into the ISMS. This aligns with the Plan-Do-Check-Act (PDCA) cycle at the heart of the standard. Incident data should drive updates to risk assessments, security controls, and awareness training.
SOC Maturity Model
Not all SOCs are equal. A maturity model helps organisations assess their current SOC capability and plan a structured improvement roadmap aligned with ISO 27001 requirements and business risk appetite.
| Maturity Level | Characteristics | ISO 27001 Readiness | Typical Features |
|---|---|---|---|
| Level 1 – Initial | Ad-hoc monitoring, basic log collection, no formal processes, reactive only | Unlikely to pass certification audit | Basic syslog, email alerts, no defined roles |
| Level 2 – Defined | Documented procedures, SIEM deployed with basic correlation, scheduled reporting, defined shift coverage | Partial compliance; gaps in incident response and forensic evidence | Standard SIEM, basic playbooks, weekly reporting |
| Level 3 – Managed | Integrated threat intelligence, formal incident response lifecycle, regular testing (tabletop, purple team), performance metrics | Good alignment with Annex A.12 and A.16 | UEBA, SOAR, threat intel platform, monthly exercises |
| Level 4 – Optimised | Automated response for known scenarios, proactive threat hunting, continuous improvement metrics, full integration with ISMS | Strong position for certification and ongoing compliance | Automated IR, hunting team, real-time dashboards, quarterly reviews |
Organisations pursuing ISO 27001 certification should target at least Level 2 maturity, with a documented roadmap to Level 3 within a defined timeframe. Anything below Level 2 will make it difficult to sustain the logging, monitoring, and response controls required by the standard through an audit cycle.
Outsourcing the SOC
Many organisations choose to outsource SOC functions to managed security service providers (MSSPs) or managed detection and response (MDR) providers. ISO 27001 permits this arrangement, provided that the outsourcing is managed in accordance with Annex A.15 (supplier relationships). The organisation remains fully responsible for ISMS compliance, even when SOC operations are performed by a third party.
Key compliance considerations when outsourcing the SOC include:
- Supplier due diligence and security assessment, including review of the MSSP’s own certifications (ISO 27001, SOC 2)
- Contractual service level agreements (SLAs) for alert triage, incident notification, and reporting
- Data protection obligations, particularly when log data crosses international borders
- Right-to-audit clauses permitting the organisation to verify the MSSP’s controls
- Exit strategy and data repatriation provisions, including log data transfer and playbook handover
- Regular supplier performance reviews and service improvement plans
The organisation must ensure that outsourced SOC services are included in the ISMS scope and that the supplier’s performance is monitored as part of the management review process (Clause 9.3). The ISO 27001 certificate belongs to the organisation, not the MSSP, and audit findings related to SOC performance will be attributed to the organisation regardless of who performed the work.
Building an ISO 27001-Aligned SOC: Practical Steps
For organisations that have decided to build or mature a SOC in support of ISO 27001, a structured implementation approach is essential. The following steps provide a practical roadmap.
Step 1 – Define SOC scope and objectives. Align the SOC mandate with the ISMS scope and the organisation’s risk appetite. Determine which assets, systems, and locations will be monitored, and define the SOC’s operating hours (24/7, business hours, or follow-the-sun).
Step 2 – Identify applicable ISO 27001 controls. Map Annex A controls to SOC functions as described in this article. Use the mapping to identify gaps between current capability and certification requirements. This gap analysis forms the basis of the implementation plan.
Step 3 – Select and deploy SIEM technology. Choose a SIEM platform that meets the organisation’s log collection, correlation, alerting, and retention requirements. Ensure the SIEM is configured to collect logs from all in-scope systems and that correlation rules are aligned with the risk register and threat model.
Step 4 – Develop incident response procedures. Create or update incident response playbooks covering the scenarios most relevant to the organisation. Test playbooks through tabletop exercises and use lessons learned to refine them. Ensure that forensic evidence collection procedures comply with A.16.1.7.
Step 5 – Establish reporting and governance. Define SOC metrics and reporting cadence aligned with the ISO 27001 management review process (Clause 9.3). Create dashboards for both operational SOC management and strategic ISMS governance.
Step 6 – Plan for continual improvement. SOC capability must evolve as the threat landscape changes and the organisation grows. Schedule regular reviews of SOC effectiveness, SIEM tuning, threat intelligence integration, and incident response testing. Document improvements as part of the ISMS continual improvement process (Clause 10.1).
Organisations that follow this structured approach will be well positioned to achieve and maintain ISO 27001 certification with their SOC as a core component of their ISMS.
Frequently Asked Questions
Does ISO 27001 require a SOC?
No, ISO 27001 does not explicitly mandate a Security Operations Center as a named entity. However, the logging, monitoring, and incident response controls in Annex A (particularly A.12 and A.16) are difficult to implement effectively without dedicated SOC capability. Most certification bodies expect organisations to demonstrate some form of structured security monitoring and response function, whether in-house or outsourced.
Which ISO 27001 controls are most relevant to SOC operations?
Annex A.12 (operational security) and Annex A.16 (incident management) are the most directly applicable. Within Annex A.12, controls A.12.4.1 through A.12.4.4 address event logging and monitoring. Annex A.16 covers incident response responsibilities, procedures, communication, and evidence collection. Clause 6.1 (risk assessment) and Clause 9.3 (management review) are also relevant to SOC governance.
Can an outsourced SOC support ISO 27001 certification?
Yes. Many organisations achieve and maintain ISO 27001 certification using outsourced SOC services. The key is to manage the supplier relationship in accordance with Annex A.15, including thorough due diligence, contractual SLAs, right-to-audit provisions, and regular performance reviews. The organisation must retain overall responsibility for ISMS effectiveness and compliance.
What is the minimum SOC maturity needed for ISO 27001?
At least Level 2 on the SOC maturity model (defined processes, documented procedures, SIEM deployment with basic correlation) is recommended. Organisations at Level 1 (ad-hoc, reactive) will struggle to demonstrate effective monitoring and response to an auditor. A documented roadmap to Level 3 should be in place as part of the ISMS continual improvement plan.
How does SIEM support ISO 27001 compliance?
SIEM systems directly support Annex A.12 controls by centralising log collection, correlating events across disparate systems, generating alerts, and retaining evidence in a tamper-proof manner. They enable the systematic monitoring and analysis that ISO 27001 requires, and provide auditors with the log review and reporting capabilities needed to verify control effectiveness.
What should be included in SOC reporting for ISO 27001 management review?
SOC reporting to management should include metrics on alerts detected, triaged, and resolved; mean time to detect and respond; incident trends; threat intelligence consumption and impact; log coverage and SIEM health; vulnerability management status; and improvement actions from post-incident reviews. These reports feed directly into Clause 9.3 management review and Clause 10.1 continual improvement.
Ready to align your SOC with ISO 27001? Whether you are building a new SOC or maturing an existing one, our consultants can help you design, implement, and certify. Contact us today to discuss your requirements.