Skip to main content

Sector Playbooks: ISO 27001 for Cloud Providers and Critical Infrastructure

Playbook 3: Cloud Service Providers​

3.1 The Cloud Provider Threat Profile​

Cloud service providers occupy a unique position in the information security ecosystem - they are simultaneously security vendors (providing infrastructure and services that other organizations depend on) and security targets (holding vast quantities of customer data that makes them extraordinarily high-value targets). A breach at a hyperscale cloud provider is not a single-organization incident - it is a supply chain attack affecting every organization that relies on the compromised service.

Tenant isolation failures: Multi-tenancy is foundational to cloud economics. If tenant isolation fails - through hypervisor vulnerabilities, side-channel attacks, or misconfigurations - one customer's data becomes accessible to another. Cross-tenant data access is one of the most significant concerns for cloud customers handling sensitive data.

API and configuration vulnerabilities: The cloud control plane - the APIs and consoles through which customers configure their environments - is itself a major attack surface. Compromised management credentials, misconfigured IAM policies, and vulnerable APIs have been the direct cause of significant cloud data exposures. Misconfigured S3 buckets, overly permissive IAM roles, and exposed management consoles are consistently among the most exploited cloud vulnerabilities.

Insider threats with hyperscale access: Cloud provider employees in infrastructure operations, support, and security roles may have access to customer data that, if abused, could affect millions of end users. The insider threat risk for a hyperscale provider is qualitatively different from that of a single-tenant organization - a single privileged employee could potentially affect thousands of customer environments simultaneously.

Supply chain attacks on platform components: Cloud providers depend on their own supply chains - hardware manufacturers, firmware vendors, open-source software communities. Compromises in these chains can affect the platform integrity that every customer depends on.

DDoS targeting availability: Cloud service availability is critical infrastructure for dependent organizations. DDoS attacks targeting cloud platforms have motivated both opportunistic criminal groups and nation-state actors.

Cryptojacking and unauthorized resource use: Compromised cloud credentials are used to spin up computational resources for cryptocurrency mining at the victim's expense - unauthorized access that may not be detected without specific monitoring for abnormal resource consumption patterns.

3.2 Cloud Provider Regulatory and Contractual Obligations​

GDPR as a processor: Cloud providers processing EU personal data on behalf of customers are data processors under GDPR. They must have Data Processing Agreements (DPAs) with customers, process only on documented instructions, implement appropriate security measures under Article 32, and notify customers of personal data breaches without undue delay.

ISO 27001 as a commercial requirement: For cloud providers, ISO 27001 certification is not primarily a regulatory obligation - it is the commercial requirement for accessing the enterprise market. Enterprise customers treat it as the baseline security credential.

SOC 2 Type II as the transparency mechanism: The combination of ISO 27001 certification and SOC 2 Type II attestation is the effective minimum baseline for credibility in the enterprise cloud market. SOC 2 provides the detailed, customer-readable evidence that ISO 27001 certification complements.

Cloud-specific standards (ISO 27017, ISO 27018): ISO 27017 provides cloud-specific security guidance; ISO 27018 addresses protection of PII in public clouds. These are increasingly expected of cloud providers in enterprise procurement alongside the base ISO 27001 certification.

Sector-specific cloud requirements: Cloud providers serving regulated industries - financial services (DORA, FCA, FFIEC), healthcare (HIPAA, NHS), government (FedRAMP, UK G-Cloud) - must satisfy sector-specific requirements that sit above the baseline frameworks. The regulatory complexity for a multi-sector cloud provider is substantial and requires systematic management.

3.3 The Shared Responsibility Model and the ISMS​

The shared responsibility model - which divides security obligations between the cloud provider and the customer - has profound implications for ISMS design that are poorly understood on both sides of the relationship.

For the cloud provider's ISMS, the shared responsibility model must be explicitly documented: which controls are the provider's responsibility, which are the customer's, and which are shared. This documentation forms the foundation for DPA content, for SOC 2 Complementary User Entity Controls (CUECs), and for the security guidance the provider publishes for customers.

The ISMS scope must clearly reflect the shared responsibility boundary. Auditors assessing cloud provider ISMSs understand the model; scope statements that attempt to claim responsibility for customer-side controls are not credible and undermine audit confidence in the entire ISMS.

3.4 Priority ISO 27001 Controls for Cloud Providers​

8.9 (Configuration management): In cloud environments, security misconfigurations are the dominant vulnerability category. Configuration management must be automated, continuous, and capable of detecting deviations from security baselines in near-real-time. Manual configuration management is inadequate for cloud infrastructure operating at scale.

8.16 (Monitoring activities): Cloud providers must monitor their environments at a scale and sophistication requiring purpose-built tooling. Behavioral analytics, anomaly detection, and automated threat hunting are not optional enhancements - they are operational requirements for detecting sophisticated attacks against platform infrastructure.

5.23 (Information security for use of cloud services): Cloud providers must apply this control not just to their own use of third-party services but as the reference for what their customers should expect of them. Understanding the control from both directions is fundamental to cloud provider ISMS design.

5.19 to 5.22 (Supplier controls): Cloud providers are suppliers to their customers, but they are also customers of their own supply chain - hardware, hypervisors, networking equipment, operating systems, and specialist services. Managing this supply chain with the rigor expected of a critical ICT service provider is a foundational operational requirement.

8.14 (Redundancy): Cloud customers select providers specifically for distributed infrastructure resilience. The ISMS must reflect genuine, tested redundancy across availability zones, regions, and network paths - not just the architectural capability but the operational verification that redundancy functions under failure conditions.

5.28 (Collection of evidence): Cloud providers may be required to provide forensic evidence for customer incident investigations, regulatory proceedings, or law enforcement requests. The forensic capability - log retention, data preservation, chain of custody procedures - must be designed as a customer service, not just an internal security function.

3.5 Cloud Provider Implementation Traps​

Trap 1: Underscoping the asset inventory. Cloud providers managing infrastructure at scale may have millions of assets that change continuously. Traditional asset management approaches fail completely. Automated, infrastructure-as-code-driven asset management with continuous reconciliation against the provisioned environment is the only viable approach.

Trap 2: Treating customer environments as outside scope. The security of customer environments depends on platform capabilities that the provider operates - identity and access management, network controls, encryption services. The ISMS must address these shared capabilities even when customers are responsible for their configuration.

Trap 3: Underestimating insider threat at scale. A single cloud provider employee with elevated platform access could potentially affect thousands of customer environments. The controls for this risk - privileged access management, behavioral monitoring, access minimization, enhanced HR screening - must be scaled to this unique threat profile.

Trap 4: Inadequate security transparency mechanisms. Enterprise customers require evidence of security posture that goes beyond a certificate. Organizations that cannot provide SOC 2 reports, penetration test summaries, security whitepapers, and DPA templates lose procurement competitions to providers who can. Security transparency is a commercial capability, not just a compliance obligation.

Cloud Provider Implementation Checklist​

Governance and Leadership​

  • Shared responsibility model documented - clear delineation of provider and customer security obligations
  • Customer security commitments mapped to ISMS controls - DPA obligations have corresponding controls
  • SOC 2 audit scope aligned with ISO 27001 ISMS scope - evidence sharing maximized
  • ISO 27017 and ISO 27018 gap assessment completed - extension controls identified and planned
  • Security advisory board or customer security council established for external input
  • Vulnerability disclosure policy published - responsible disclosure program operational

Risk Management​

  • Platform-level risk assessment covers tenant isolation, API security, and supply chain risks
  • Customer data risk assessed by classification - provider obligations vary by data category
  • Supply chain risk assessment covers hardware, hypervisor, networking equipment, and software vendors
  • Insider threat risk specifically assessed for employees with elevated platform access
  • DDoS threat assessed - scrubbing capacity and traffic engineering capability documented
  • Regulatory risk assessed by customer jurisdiction - all markets where customers face specific requirements

Asset Management​

  • Infrastructure inventory automated - CMDB continuously reconciled with provisioned environment
  • Customer data asset tracking approach documented - logical separation verification mechanism defined
  • Software bill of materials (SBOM) maintained for platform software components
  • Open-source dependency inventory maintained - vulnerability monitoring automated
  • Hardware supply chain integrity controls documented - secure boot, firmware verification

Access Control​

  • Privileged access to production - just-in-time, session-recorded, behaviorally monitored
  • Customer environment access controls documented - support access requires customer approval
  • Access to customer data for support purposes - DPA-compliant process, customer notification capability
  • Internal IAM governance - role definitions, quarterly review, automated deprovisioning
  • Customer IAM best practice guidance published and kept current

Technical Controls​

  • Tenant isolation controls tested - penetration test scope includes cross-tenant attack scenarios
  • Configuration compliance monitoring automated - CSPM deployed across full platform
  • Vulnerability management at scale - automated scanning, prioritization by exploit likelihood, SLA enforced
  • Security monitoring at platform scale - SIEM capable of platform-wide telemetry ingestion and analysis
  • DDoS mitigation capability - scrubbing capacity, anycast routing, traffic engineering
  • Encryption key management - customer-managed key capability, key isolation verified
  • Log retention meets enterprise customer requirements - 12 months minimum, longer for regulated sectors

Incident Management​

  • Customer notification process documented - breach notification timeline by jurisdiction
  • Platform incident vs. customer incident distinction documented - scope of provider obligation clear
  • Major incident communication process - customer communications, status page, post-incident reports
  • Forensic support capability - log preservation and extraction in support of customer investigations
  • Multi-jurisdictional breach notification coordination where provider is GDPR processor

Customer Transparency​

  • ISO 27001 certificate publicly accessible
  • SOC 2 Type II report available under NDA to enterprise customers
  • Penetration test executive summary available to customers on request
  • Security whitepaper documenting platform security architecture published and current
  • Compliance documentation portal - DPA templates, sub-processor list, security addenda
  • Customer security notifications - process for notifying relevant customers of security events

Playbook 4: Critical Infrastructure​

4.1 The Critical Infrastructure Threat Profile​

Critical infrastructure operators - energy companies, water utilities, transportation networks, telecommunications providers - face a threat profile that is qualitatively different from commercial organizations. The consequence of a successful attack is not financial loss or data breach - it is physical harm to the public and disruption of services that populations depend on for basic safety and welfare.

Nation-state cyber operations: Critical infrastructure is a primary target for nation-state actors conducting offensive cyber operations. Pre-positioning - gaining persistent access for potential future activation - is a documented strategy of multiple nation-state threat actors. The 2021 Colonial Pipeline attack, attributed to a criminal group, disrupted fuel supplies across the US East Coast and illustrated the cascading consequences of critical infrastructure compromise.

Operational Technology (OT) exploitation: The convergence of IT and OT networks has dramatically expanded the attack surface for critical infrastructure. OT systems were designed for safety and reliability, not security - many run proprietary operating systems, cannot be patched, and were never intended to be connected to internet-accessible networks. The TRITON/TRISIS malware, which targeted safety instrumented systems at a Middle Eastern petrochemical facility, demonstrated that attacks against physical safety systems are not theoretical.

Supply chain attacks on industrial control systems: ICS vendors - manufacturers of PLCs, safety systems, and engineering workstations - have been specifically targeted by attackers who understand that compromising a widely-used ICS platform is a force-multiplier for attacks on multiple infrastructure operators simultaneously.

Physical-cyber attack combinations: Critical infrastructure attacks increasingly combine cyber and physical elements - using cyber access to disable physical security controls before a physical attack, or using physical access to introduce malware into air-gapped OT environments via infected USB drives or compromised maintenance equipment.

Ransomware targeting operational continuity: Criminal ransomware groups have demonstrated willingness to attack critical infrastructure because operational continuity pressure creates leverage for ransom payment even when organizations' stated policies prohibit it.

4.2 The IT/OT Convergence Problem​

The most significant and most frequently mismanaged aspect of critical infrastructure ISMS design is the treatment of OT systems. Three approaches are common, and only one is defensible:

Approach 1: Exclude OT from ISMS scope. Organizations argue that OT systems are managed by operational engineering and are outside the ISMS scope. This is dangerous - IT/OT network connections that exist in virtually every modern critical infrastructure environment mean that IT compromises can directly affect OT operations. An ISMS that excludes OT while IT/OT connections exist has a critical interface dependency gap that threat actors will exploit.

Approach 2: Apply standard IT controls to OT. Applying IT security controls to OT environments typically fails because OT systems cannot be patched, cannot run endpoint protection agents, have availability requirements that preclude maintenance windows, and must be managed by operational engineering staff who prioritize safety and continuity over security process.

Approach 3: Hybrid approach with OT-specific controls. The defensible approach acknowledges OT systems as within ISMS scope - because the risks to and from them are genuine information security risks - but applies OT-specific controls appropriate to the OT environment's unique constraints. ISA/IEC 62443 provides the OT-specific control framework; ISO 27001 provides the management system governance. The two standards are designed for integrated use.

4.3 The Critical Infrastructure Regulatory Overlay​

NIS2 - essential entities: Critical infrastructure operators in essential entity sectors face the most stringent NIS2 requirements - 24-hour early warning for significant incidents, enhanced supervisory authority powers, mandatory security measure implementation, and potential personal sanctions for management body members.

Sector-specific regulations:

  • Energy: EU Network Codes, UK National Grid ESO requirements, NERC CIP (US) for the electricity subsector
  • Transport: ICAO/IMO cybersecurity requirements, EU NIS sector implementation guidance
  • Water: EPA cybersecurity requirements (US), EU Drinking Water Security guidance
  • Telecommunications: BEREC guidelines, national telecom security regulations

ISA/IEC 62443: The primary ICS/OT security standard - a family of standards addressing industrial automation and control system security that is increasingly referenced in critical infrastructure regulation. Treated as the OT equivalent of ISO 27001 and increasingly expected alongside ISO 27001 certification for critical infrastructure operators.

4.4 Priority ISO 27001 Controls for Critical Infrastructure​

8.20 to 8.22 (Network security and segmentation): IT/OT segmentation is the single most critical control in critical infrastructure environments. The boundary must be enforced by technical controls - not just policy - with documented architecture, defined data flows, and active monitoring of all boundary traffic. A compromised administrative workstation must never have a network path to an operational control system.

5.30 (ICT readiness for business continuity): For critical infrastructure, business continuity is a public safety obligation. The ISMS must reflect the most demanding availability requirements and the consequences of unavailability measured in public harm - power loss, water contamination, transport disruption. Business continuity plans must include manual operating procedures tested against real disruption scenarios.

5.7 (Threat Intelligence): Nation-state actors targeting critical infrastructure are sophisticated, patient, and well-resourced. Sector-specific and threat-actor-specific intelligence - including intelligence about APT groups known to target the organization's specific infrastructure sector - is required. ICS-CERT, sector-specific ISACs, and government intelligence partnerships are essential, not optional.

7.1 to 7.6 (Physical security): For critical infrastructure, physical security of operational facilities is as important as cybersecurity. Physical access to control systems can enable attacks that bypass all cyber controls. Physical security perimeters, access controls, and monitoring must reflect the consequence severity of unauthorized physical access to operational areas - substations, pumping stations, control rooms, data centers.

8.8 (Technical vulnerabilities - adapted for OT): The standard vulnerability management process must be adapted for OT environments where patching may be impossible, require extended maintenance windows, or require validation by operational engineering. The OT vulnerability management process must address: vendor patch notifications, risk assessment with compensating controls for unpatched vulnerabilities, and mandatory operational engineering involvement before any changes to OT environments.

4.5 Critical Infrastructure Implementation Traps​

Trap 1: Treating OT security as an IT problem. OT security requires operational engineering expertise. An ISMS implemented by an IT security team without OT engineering involvement will produce controls that are technically correct but operationally unimplementable - and will be ignored by the people who must implement them.

Trap 2: Assuming air gaps are maintained. Many organizations believe their OT environments are air-gapped from IT networks. Investigation typically reveals USB drives, maintenance laptops, historian servers, remote access connections, and vendor support channels that cross the supposed boundary. Air-gap integrity requires active verification, not assumption.

Trap 3: Underestimating supply chain risk for ICS vendors. ICS vendors are prime targets for supply chain attacks affecting multiple critical infrastructure operators simultaneously. The TRITON/TRISIS case demonstrates that even safety instrumented systems are within scope for sophisticated attackers.

Trap 4: Physical-cyber siloing. Physical security and cybersecurity are managed by different teams with limited coordination. Physical access to OT environments enables attacks that are impossible from the network. The ISMS risk assessment must integrate physical and cyber risk analysis - not treat them as separate programs.

Critical Infrastructure Implementation Checklist​

Governance and Leadership​

  • IT and OT security governance integrated - information security committee includes operational engineering
  • OT security ownership defined - responsibility between IT security and operational engineering documented
  • Regulatory obligations mapped - sector-specific regulations, NIS2 essential entity requirements, national CIP requirements
  • Security budget includes OT security investment - separate line item, calibrated to OT threat profile
  • Government intelligence relationships established - sector ISAC membership, government liaison contacts
  • Board-level awareness of nation-state threat profile - specific APT actor briefing for the sector

Risk Management​

  • IT/OT convergence risk specifically assessed - all network connections documented and risk-assessed
  • OT system inventory complete - ICS/SCADA systems, PLCs, RTUs, engineering workstations, historian servers
  • Nation-state threat actor profiles maintained for actors known to target the sector
  • Physical-cyber combined attack scenarios included in risk assessment
  • Supply chain risk assessment covers ICS vendors - software integrity, remote access credentials, update mechanisms
  • Worst-case impact scenarios assessed - public safety consequences included in impact scoring

IT/OT Architecture and Segmentation​

  • IT/OT boundary architecture documented - all network connections, data flows, and protocols mapped
  • IT/OT boundary enforced by technical controls - firewalls, data diodes, or unidirectional gateways
  • Air-gap claims actively verified - scanning and physical inspection, not assumption
  • OT-specific network segments defined - safety systems isolated from operational, operational from corporate
  • Remote access to OT environments - specifically authorized, logged, monitored, minimized to necessity
  • Unauthorized wireless detection deployed in operational areas

OT-Specific Security Controls​

  • OT asset inventory maintained - vendor, model, firmware version, network connection, operational function
  • OT vulnerability management process documented - adapted for OT constraints and operational impact
  • ICS vendor patch notifications monitored - subscription to all relevant vendor security advisories
  • End-of-support OT systems inventoried - compensating controls or replacement plan formally documented
  • OT default credentials eliminated or documented with compensating controls
  • Removable media controls for OT environments - USB whitelisting or physical block where feasible
  • OT-specific behavioral monitoring deployed - ICS protocol-aware detection (Claroty, Dragos, or equivalent)
  • ISA/IEC 62443 gap assessment completed - alignment documented and gaps remediated

Physical Security​

  • Physical security perimeters defined for all critical operational sites
  • Physical access logs maintained for all critical operational areas - substation, control room, pumping station
  • Physical intrusion detection deployed at critical sites - monitoring to 24/7 response capability
  • Visitor and contractor management for operational sites - escort procedures, background screening for recurring access
  • Physical tamper detection for critical field devices - seals, sensors for unauthorized physical access
  • Supply chain physical security for ICS hardware - chain of custody from procurement to installation

Incident Management​

  • OT incident response playbook documented - distinct from IT incident response, operationally validated
  • OT incident response involves operational engineering - operational authority for safety decisions
  • NIS2 24-hour early warning capability - detection and escalation within 24 hours for significant incidents
  • Government/regulator notification contacts in playbook - sector ISAC emergency contact, national competent authority
  • Public safety impact assessment in incident severity classification - triggers specific escalation path
  • Ransomware playbook includes OT-specific recovery - control system restoration sequence documented
  • Annual tabletop exercises include OT scenarios - loss of control, loss of communications, physical-cyber combined

Business Continuity​

  • Manual operations procedures documented for each critical operational function
  • Manual operations tested - simulation exercise for loss of automation capability, results documented
  • Recovery time objectives reflect public safety requirements - regulator-approved RTOs where applicable
  • OT backup and recovery procedures - configuration backup, ICS image restoration, tested annually
  • Mutual aid agreements with peer operators - support framework for extended outages

Threat Intelligence​

  • Sector ISAC membership active - attending briefings, contributing to sharing, not just subscribing
  • Government threat intelligence relationship established - CISA (US), NCSC (UK), ANSSI (FR), BSI (DE), or national equivalent
  • APT actor profiles maintained for actors known to target the sector - TTPs documented and detection rules current
  • ICS-CERT and vendor security advisories monitored - automated notification subscription
  • Threat intelligence regularly fed into OT monitoring detection rules - IOCs updated at minimum quarterly

Part 5: Consolidated Cross-Sector Insights​

5.1 The Controls That Matter Everywhere​

Across all four sectors, four controls consistently appear in every critical risk treatment plan, every audit finding analysis, and every post-incident review.

Multi-factor authentication (8.5): Every significant credential-based attack - phishing, credential stuffing, BEC, account takeover - is made dramatically harder, and often infeasible, by universal MFA enforcement. The gap between organizations that have deployed phishing-resistant MFA universally and those that have not is one of the clearest predictors of breach likelihood in the current threat environment. Partial MFA deployment - external-only, selected systems only - consistently leaves the gaps that sophisticated attackers route through.

Privileged access management (8.2): In every sector, privileged accounts are the attacker's primary objective after initial access is achieved. Just-in-time access, session recording, quarterly review without exception, and behavioral monitoring of privileged account activity consistently reduce the blast radius of initial compromise.

Tested backup and recovery (8.13 and 5.30): Ransomware recovery capability is the single greatest determinant of whether a ransomware incident is a 24-hour disruption or a multi-week crisis. Untested backups provide false confidence - organizations that have never tested recovery from backup routinely discover that their backups are incomplete, their restoration procedures are undocumented, or their recovery time objectives are completely unrealistic.

Supply chain security (5.19 to 5.23): In every sector, the most significant incidents of the past five years have involved supplier compromise rather than direct attack. SolarWinds, Kaseya, MOVEit, Log4Shell - all were supply chain or third-party component attacks. Tiered supplier assessment, ongoing monitoring, contractual security requirements with enforcement mechanisms, and fourth-party risk awareness are core controls for any organization with meaningful third-party dependencies.

5.2 The Implementation Principles That Transcend Sector​

Risk proportionality over control completeness. The ISMS that addresses the organization's actual, specific risks in its specific context will outperform the ISMS that implements every control in Annex A without discriminating between what is relevant and what is not.

Operational embedding over documentation. The control that is operationally embedded - that staff understand, that is technically enforced, that produces evidence as a byproduct of normal operation - provides genuine security. The control that exists in a policy document without operational implementation provides compliance theater that satisfies an auditor once and then degrades until the next audit.

Threat intelligence as a continuous risk input. Generic threat assessments produce generic control selections. Sector-specific, current threat intelligence - consumed actively, analyzed systematically, and fed into risk register updates - produces risk assessments that reflect what is actually happening to organizations like yours.

Availability as a first-class risk dimension. Across all four sectors, availability risks have proven to be as consequential as confidentiality risks - and in healthcare and critical infrastructure, more consequential in terms of human harm potential. ISMSs designed primarily around confidentiality protection, with availability treated as a secondary concern, are misaligned with the actual risk landscape.

Leadership commitment as a non-negotiable prerequisite. Across all four sectors and across two decades of ISMS implementations, the single most reliable predictor of ISMS effectiveness is genuine leadership commitment - boards that understand the threat profile, executive teams that treat security as a strategic function, organizations where security investment is proportionate to the risk.

Part 6: Final Cross-Sector Implementation Checklist​

These items apply regardless of sector. Consider this the floor before any sector-specific checklist is applied.

Foundation​

  • Scope statement defines organizational, geographical, process, and technology boundaries precisely
  • Context analysis documented - internal and external issues, interested party requirements
  • Risk methodology documented - criteria, scales, methodology, review triggers
  • Risk register current - reviewed within the last 12 months minimum
  • Statement of Applicability complete - all 93 controls addressed with substantive justifications
  • Information security policy approved by top management and communicated to all in-scope personnel
  • Roles and responsibilities assigned - every significant ISMS activity has a named owner

Risk Management​

  • Risk assessment covers all significant information assets
  • Risk treatment plan complete - every risk is treated, accepted, avoided, or transferred with documentation
  • Risk owners identified for all significant risks
  • Residual risks formally accepted at appropriate organizational level
  • Information security objectives defined - SMART, measurable, with progress tracked

Operations​

  • Asset inventory maintained - current, complete, with owners and classification
  • Change management process operational - security review integrated, emergency change retrospective process defined
  • Supplier register maintained - tiered by risk, with review schedule current
  • Incident register operational - incidents recorded, classified, and post-reviewed
  • Vulnerability management process operational - scan, triage, remediate, SLA enforced

People​

  • Annual security awareness training completed by all in-scope staff
  • Role-specific training delivered for high-risk roles - privileged access, finance, development
  • Phishing simulation conducted - results used for targeted follow-up
  • Joiners/movers/leavers process integrates security - access provisioned, reviewed, and revoked systematically
  • Screening process defined for roles with access to sensitive information

Technical Controls​

  • MFA enforced - universal for external access, privileged access, and sensitive systems at minimum
  • Access reviews conducted on schedule - quarterly for privileged, semi-annually for all users
  • Backup tested - isolated backup verified with timed recovery exercise
  • Encryption deployed - at rest for sensitive data, in transit for all sensitive communications
  • Logging operational - coverage of critical systems, retention sufficient for incident investigation

Measurement and Improvement​

  • Security metrics reported monthly to security management
  • Security metrics reported quarterly to executive management
  • Internal audit program executed - covers full ISMS scope across certification cycle
  • Management review conducted - covers all Clause 9.3 inputs, produces specific decisions and actions
  • Nonconformity and corrective action process operational - root cause addressed, closure verified
  • Continual improvement register maintained - improvement opportunities tracked to completion

© ISO 27001 Wiki - For CISOs, Security Analysts, and GRC Professionals 10 Chapters | Complete Edition