Why the 2022 Revision Matters for Cloud-First Enterprises

The transition from ISO 27001:2013 to ISO 27001:2022 reorganised 114 controls across 14 domains into 93 controls across four themes: organisational, personnel, physical, and technological. For enterprises running multi-cloud infrastructure, the practical impact is concentrated in the technological controls — particularly those governing cloud service usage, threat intelligence, and data masking.

Enterprises that had built their ISMS around the 2013 framework faced a transition deadline of October 2025. As of that date, all valid ISO 27001 certificates should reference the 2022 version. The transition is complete — but the operational implications of the new controls continue to surface in audit findings.

Cloud-Specific Controls in Annex A

ISO 27001:2022 introduced Control 5.23, “Information security for use of cloud services,” as a dedicated control addressing cloud service management. This replaces the 2013 approach of applying generic supplier management controls to cloud relationships — a critical gap that auditors had flagged in cloud-heavy organisations.

• Control 5.23 requires documented cloud acquisition, use, management, and exit procedures specific to each cloud service in scope
• Control 8.23 addresses web filtering, requiring policy controls on what cloud services staff can access — relevant for SaaS adoption governance
• Control 8.25 introduces secure development lifecycle requirements that directly affect DevOps and IaC pipelines

How CSPM Tooling Supports ISO 27001:2022 Compliance

Cloud Security Posture Management tools — including Microsoft Defender for Cloud, AWS Security Hub, and Google Security Command Center — provide automated control evidence that directly maps to ISO 27001:2022 Annex A controls. For enterprises operating across Azure, AWS, and GCP simultaneously, CSPM tooling is no longer optional — it is the primary mechanism through which control evidence is collected at scale.

Our Cloud Operations practice integrates CSPM tooling deployment as a standard component of every multi-cloud engagement, ensuring that the evidence required for ISO 27001 audit is produced continuously rather than assembled in the weeks before an assessment.

Operational Implications for DevOps and IaC Teams

The new Secure Development Lifecycle control (8.25) introduces requirements for security testing at each stage of the software development process. For enterprises using Infrastructure as Code, this means IaC pipelines must include policy-as-code checks — tools such as Checkov, tfsec, or OPA Conftest — that validate cloud resource configurations against security baselines before deployment. This aligns directly with our Infrastructure as Code practices for enterprise environments.

See also: Zine Consult's ISO 27001 Readiness Programme delivered in partnership with BSI Group and Bureau Veritas.

The Core Difference: Attestation vs Certification

SOC 2 is an attestation — a report issued by a CPA firm confirming that your controls were suitably designed (Type I) or operated effectively over a period of time (Type II). ISO 27001 is a certification — a third-party confirmation that your Information Security Management System meets an international standard. Both demonstrate security maturity, but they serve different audiences and different procurement contexts.

Enterprises selling into US markets, particularly to enterprise SaaS buyers, venture-backed technology companies, and healthcare organisations, will almost always face a SOC 2 requirement. Enterprises selling into European, Middle Eastern, or Asian markets — or operating under GDPR — are more likely to encounter ISO 27001 as a procurement requirement.

Trust Service Criteria vs Annex A Controls

SOC 2 is organised around the AICPA's Trust Service Criteria: Security (the Common Criteria, required), Availability, Confidentiality, Processing Integrity, and Privacy (optional categories). ISO 27001 is organised around 93 Annex A controls across organisational, personnel, physical, and technological themes.

• The Common Criteria (CC) in SOC 2 map closely to ISO 27001's organisational and technological controls
• ISO 27001 requires a full risk register and Statement of Applicability; SOC 2 does not
• SOC 2 Type II covers a specific observation period (typically 6–12 months); ISO 27001 is a three-year certification with annual surveillance audits

Decision Framework for Enterprise Buyers

If your primary market is North America and your buyers are enterprise software procurement teams: lead with SOC 2 Type II. If your primary market is EMEA and you operate under GDPR or handle government contracts: lead with ISO 27001. If you operate across both: run them in parallel, starting with ISO 27001 to establish the ISMS foundation, then layering SOC 2 controls on top.

Our Compliance Advisory practice delivers both SOC 2 readiness and ISO 27001 certification programmes, in partnership with PwC and BSI Group respectively. See also our article on ISO 27001:2022 for enterprise cloud operations.

The Post-Schrems II Landscape

The CJEU's Schrems II ruling in July 2020 invalidated the EU-US Privacy Shield and imposed transfer impact assessment requirements on all cross-border personal data transfers relying on Standard Contractual Clauses. Enterprises operating across our 15+ active markets — spanning the EU, Middle East, and Central Asia — must navigate an increasingly complex patchwork of data transfer restrictions, localisation requirements, and supervisory authority relationships.

The European Commission's June 2021 SCCs, which replaced the 2010 versions, introduced a modular structure covering four transfer scenarios: controller-to-controller, controller-to-processor, processor-to-controller, and processor-to-processor. Most enterprise cloud engagements require multiple modules deployed simultaneously.

Transfer Impact Assessments in Practice

A Transfer Impact Assessment (TIA) must evaluate whether the legal framework of the destination country provides equivalent protection to EU GDPR. For transfers to the UAE, this requires analysis of UAE Federal Law No. 45 of 2021 (PDPL), which took full effect in January 2024. For transfers to Kazakhstan or Uzbekistan, TIAs must address local data localisation mandates that require primary copies of citizen data to be stored domestically.

• Map every data flow by category of personal data, lawful basis, and destination country
• Conduct TIAs for each non-adequate country in the transfer chain
• Document supplementary measures where SCCs alone are insufficient
• Review DPAs with all processors to ensure 2021 SCCs are incorporated

GDPR Operations Across the Middle East

Enterprises with EU establishments processing personal data of individuals in the Middle East face a dual compliance obligation: GDPR governs the export of EU resident data to GCC processors; local PDPL frameworks govern the processing of local resident data by EU-based controllers. For enterprises engaged in international contractor onboarding across the UAE and Saudi Arabia, this means every HR data flow must be assessed against both frameworks simultaneously.

Our GDPR practice delivers data mapping, DPIA execution, DPA drafting, and TIA programmes across all 15+ of our active markets. Related reading: Operating in the UAE: Cloud Infrastructure and Data Localisation.

The Governance Problem Multi-Cloud Creates

Most enterprises adopt multi-cloud reactively — a business unit selects AWS for one workload, Azure for another, GCP because the data science team prefers it. The result is multi-cloud by accident rather than design: fragmented security postures, duplicated operational tooling, incompatible tagging schemas, and no unified visibility into spend or compliance status.

Building for sovereignty requires a deliberate architectural decision: what workloads go where, why, under what governance model, and how does the enterprise maintain portability if a provider relationship needs to change? These decisions must be made before provisioning begins — not after.

Platform-Agnostic Architecture Principles

• Abstract cloud-native services behind vendor-neutral interfaces wherever workload portability is a requirement
• Use Kubernetes as the compute abstraction layer for containerised workloads, with cluster configurations managed through IaC
• Implement a cloud management platform (CMP) — Morpheus, CloudBolt, or Apptio Cloudability — for unified governance and cost visibility
• Standardise on a single identity provider (Entra ID, Okta) federated across all cloud environments
• Define a network topology that governs cross-cloud connectivity, private peering, and data egress paths

Infrastructure as Code as the Governance Mechanism

At enterprise scale, the governance model for multi-cloud infrastructure is implemented through code. Terraform's provider-agnostic model, combined with a well-structured module library and policy-as-code checks via Sentinel or OPA, creates the enforcement mechanism that ensures every cloud resource conforms to the organisation's security, tagging, and architecture standards — regardless of which cloud it is provisioned in.

See our detailed article on Infrastructure as Code tooling for enterprise environments and our Cloud Operations practice page for how we implement these principles in client engagements.

Why GCC Misclassification Risk Is Disproportionate

In the UAE and Saudi Arabia, the legal distinction between an employee and an independent contractor is not simply a matter of contract terms — it is determined by the economic reality of the engagement, the degree of control exercised by the engaging entity, and in many cases the visa and residency status of the individual. A foreign enterprise engaging a UAE national as a “consultant” while exercising significant control over their working hours, tools, and deliverables is at material risk of a labour authority finding the relationship is employment — with retroactive consequences.

WPS and Wage Protection System Obligations

The UAE Wage Protection System (WPS) requires that wages be paid through an approved electronic transfer system within the statutory pay cycle. While WPS obligations apply primarily to employees, enterprises that structure contractor relationships in ways that resemble employment may find their engagements brought within scope of WPS enforcement. The consequences — fines, business licence suspension, blacklisting — are severe and rapidly imposed.

EOR as the Structural Solution

For enterprises that require a compliant engagement vehicle in GCC markets without establishing a local entity, an Employer of Record structure eliminates misclassification risk by placing the employment relationship with a locally licensed EOR entity that manages all statutory obligations. The engaging enterprise operates under a commercial services agreement with the EOR — a structure that is legally clean, commercially efficient, and audit-ready.

Our Contractor Onboarding practice provides EOR solutions across UAE, Saudi Arabia, Qatar, and Kuwait. See also: Global payroll compliance obligations and our Middle East market expertise.

The Seven Compliance Gaps

Enterprises expanding internationally consistently encounter the same seven payroll compliance failures — not because they are ignorant of the risks, but because the obligations are jurisdiction-specific, change frequently, and are not visible to finance teams operating general-purpose payroll platforms.

• Pension auto-enrolment: Poland's PPK programme and Estonia's second-pillar pension system have specific enrolment timelines and contribution rates that are missed when using non-local payroll systems
• Social insurance base caps: Several jurisdictions cap social insurance contributions at a wage ceiling that changes annually — miscalculations here create both over-payment and under-payment exposure
• Notice period statutory minimums: Romanian and Czech labour codes set statutory notice periods that differ from contractual notice periods — severance calculations that ignore statutory minimums generate dispute exposure
• Year-end employer filings: UAE end-of-service gratuity calculations use a specific formula tied to last basic salary — errors here are the most common source of individual labour disputes in the GCC
• Posted worker declarations: Enterprises seconding employees between EU member states must comply with the Posted Workers Directive — including A1 certificate applications in the home country
• HRIS data latency: Changes made in Workday or SAP SuccessFactors that do not flow to payroll within the same pay cycle create corrections that compound over time
• Currency exposure on payroll: Multi-currency payroll without FX management creates P&L exposure that finance teams in growth-phase international operations consistently underestimate

Our Global Payroll practice covers all 12+ of our active markets with dedicated in-country legal counsel. Related: HRIS integration for global payroll and contractor misclassification in GCC markets.

Why “Cost Optimisation” Is the Wrong Frame

Most cloud cost programmes begin reactively — triggered by a CFO discovering that the cloud bill has grown 40% year-over-year with no corresponding business value attribution. Cost optimisation as a reactive exercise produces short-term savings that erode within two quarters as teams provision resources without the visibility and accountability structures that would make cost-conscious behaviour sustainable.

FinOps as a discipline reframes cloud spend as a financial management problem: not “how do we spend less” but “how do we understand what we are spending, attribute it accurately, and make informed decisions about what is and is not generating business value.”

The Four Structural Requirements for Multi-Cloud FinOps

• Unified tagging taxonomy: A consistent, enforced tagging schema across all cloud providers that maps every resource to a cost centre, application, environment, and team — implemented through policy-as-code in IaC pipelines
• Showback before chargeback: Report cloud costs to teams before implementing chargeback to build cost awareness and identify tagging gaps
• Commitment coverage governance: Reserved instances and savings plans must be managed at the portfolio level, not the account level — a single account's RI purchasing decision creates enterprise-wide commitment exposure
• Anomaly detection with alert routing: Automated spend anomaly detection must route alerts to the team that provisioned the resource — not just the central platform team — to create distributed accountability

See how our Cloud Operations practice implements FinOps frameworks as a standard component of multi-cloud engagements. Related: Multi-cloud architecture principles and IaC governance for cloud environments.

Why the Framework Fails Without Discovery Data

The 6 R's framework — Rehost, Replatform, Repurchase, Refactor, Retire, Retain — is widely cited in cloud migration planning and frequently misapplied. The most common failure mode: applying the framework as a top-down classification exercise based on application names and descriptions rather than as a data-driven analysis of actual workload characteristics, dependencies, and business value.

Without a thorough discovery phase that produces dependency maps, utilisation profiles, technical debt assessments, and business criticality scores, the 6 R's exercise produces classifications that look reasonable in a spreadsheet and fail in execution — when the “Rehost” workload turns out to have an undocumented dependency on a physical hardware clock, or the “Refactor” application requires 18 months of development rather than three.

How Each Track Actually Works at Scale

• Rehost (lift-and-shift): Fastest to execute, lowest risk, lowest cloud benefit. Best for workloads where speed of migration outweighs optimisation value — not a permanent state
• Replatform (lift-tinker-and-shift): Minor modernisation without code changes — moving from self-managed databases to RDS, or from physical load balancers to ALB. High ROI for the effort invested
• Repurchase (drop-and-shop): Replacing on-premise software with a SaaS equivalent. The hidden cost is the data migration and integration rebuild — frequently underestimated
• Refactor: Re-architecting for cloud-native patterns — containerisation, microservices, serverless. Highest long-term value, highest execution risk, longest timeline
• Retire: Decomissioning applications that no longer serve a business purpose. Requires business stakeholder buy-in that technical teams underestimate
• Retain: Keeping on-premise workloads that have genuine technical, regulatory, or cost reasons to stay. Must be revisited at each migration wave

See our Cloud Migration practice for how we implement the full Assess → Plan → Migrate → Optimise lifecycle. Related: multi-cloud architecture principles and FinOps during and after migration.

Zero-Trust Is an Architecture, Not a Product

Zero-trust security — the principle that no user, device, or network connection should be trusted by default — is frequently marketed as a product category rather than an architectural approach. Enterprises that purchase a “zero-trust solution” without implementing the underlying architectural changes — identity-centric access controls, micro-segmentation, continuous verification — achieve vendor lock-in without security improvement.

NIST SP 800-207, the authoritative guidance on zero-trust architecture, defines seven tenets that describe the desired end state. Reaching that end state in a multi-cloud enterprise environment requires a phased implementation programme that begins with identity governance and progressively extends to network segmentation and device posture management.

Implementation Across Azure, AWS, and GCP

• Identity: Entra ID (formerly Azure AD) federated to AWS IAM Identity Center and Google Cloud Identity via SAML/OIDC creates a single pane for access governance across all three clouds
• Just-in-Time access: Privileged Identity Management (PIM) in Entra, AWS SSO with time-bound role assumption, and Google Cloud's JIT access manager enforce least-privilege in privileged access workflows
• Network micro-segmentation: NSGs, Security Groups, and VPC firewall rules enforced through IaC policy-as-code ensure workload-level network isolation without manual firewall management
• Device posture: Conditional Access policies that require device compliance (managed endpoint, MFA, OS patch level) before granting access to cloud management planes

Our Security Posture Management service implements zero-trust architecture as a standard component of enterprise cloud engagements. Related: ISO 27001:2022 technological controls and multi-cloud architecture design.

Why Estonia for Technology Contractors

Estonia's combination of digital infrastructure, EU membership, common law-influenced business environment, and e-Residency programme has made it the preferred incorporation jurisdiction for European technology contractors working with US and UK enterprises. For enterprises engaging Estonian contractors, the compliance landscape is significantly more favourable than most EU jurisdictions — but it is not without complexity.

Estonia's income tax system applies a flat rate to distributed profits rather than a corporate income tax on retained earnings — a structure that makes OÜ (private limited company) incorporation attractive for individual technology contractors. For engaging enterprises, this creates a contractor landscape where most individuals operate through their own OÜ entity, changing the contractual and tax compliance framework compared to direct individual engagement.

Compliance Obligations for Engaging Enterprises

• VAT treatment: Estonian OÜ entities with EU VAT registration create reverse-charge obligations for EU-based engaging enterprises
• Permanent establishment risk: Regular, supervised work by an Estonian contractor at an engaging enterprise's premises can create PE exposure under the Estonia-UK or Estonia-US double taxation treaty
• Data processing: Estonian contractors processing personal data of EU residents must comply with GDPR as data processors — DPAs are mandatory under GDPR Article 28

See our Contractor Onboarding practice and Eastern Europe market expertise. Zine Consult's headquarters in Tallinn provides in-country counsel for Estonian contractor engagements. Related: GDPR cross-border transfer compliance.

The UAE's Evolving Regulatory Landscape

The UAE has undergone significant regulatory development since 2021, with the enactment of the Personal Data Protection Law (Federal Law No. 45 of 2021, PDPL), which took full effect in January 2024. For enterprises with UAE operations, PDPL creates data processing obligations that run parallel to — and in some respects more stringently than — GDPR. The extraterritorial scope of PDPL applies to any processing of UAE residents' personal data, regardless of where the controller is located.

Cloud Sovereign Regions and Data Localisation

Both Azure (UAE North, UAE Central) and AWS (Middle East - UAE) operate sovereign cloud regions within the UAE, providing data residency for organisations with localisation requirements under PDPL or sector-specific regulations from the Central Bank of UAE (CBUAE) or the Telecommunications and Digital Government Regulatory Authority (TDRA). Google Cloud's UAE presence is structured through its Dammam region in Saudi Arabia, with specific latency and sovereignty considerations.

Wage Protection System and Payroll Obligations

The UAE Wage Protection System (WPS) mandates electronic salary transfers through Central Bank-approved financial institutions within the contractual pay date. Enterprises with UAE employees — whether engaged directly or through an EOR — must be enrolled in WPS. Non-compliance triggers tiered consequences: fines, new work permit suspension, and ultimately business licence cancellation for persistent non-compliance.

Our Global Payroll practice manages WPS enrollment and compliance across UAE, Saudi Arabia, Qatar, and Kuwait. See also: contractor misclassification in GCC markets and PDPL and GDPR cross-border transfer compliance.

RPO and RTO: The Governance Conversation Before the Architecture Conversation

Recovery Point Objective (RPO) — how much data loss is acceptable — and Recovery Time Objective (RTO) — how long systems can be unavailable — are business decisions, not technical ones. The most common failure in enterprise DR planning is allowing infrastructure teams to set these targets without business stakeholder input. A database team that sets RPO at 4 hours because that's achievable with their current backup infrastructure has made a business continuity decision that their CFO and legal counsel may not agree with.

DR Architecture Patterns for Cloud Environments

• Backup and restore: RPO in hours, RTO in hours to days. Lowest cost, appropriate for non-critical workloads. Cross-region backup with automated integrity testing
• Pilot light: Core infrastructure elements running in DR region, scaled up on activation. RPO in minutes to hours, RTO in hours. Appropriate for important but not mission-critical workloads
• Warm standby: Scaled-down replica running continuously in DR region, with automated traffic failover. RPO in minutes, RTO in minutes. Appropriate for business-critical workloads
• Multi-site active/active: Full production capacity in multiple regions simultaneously. Near-zero RPO and RTO. Required for mission-critical systems with zero-downtime SLAs

Audit Evidence for ISO 22301 and SLA Compliance

Annual DR test execution without documented results is insufficient for ISO 22301 alignment or enterprise SLA compliance evidence. Our DR programmes produce test execution reports, failure scenario logs, RTO/RPO measurement data, and corrective action tracking — the evidence package that boards and auditors require.

See our Cloud Operations practice for disaster recovery as a standard component of managed cloud operations. Related: multi-cloud architecture design and ISO 27001:2022 resilience controls.

The Root Cause of Global Payroll Errors

The majority of global payroll errors in enterprises operating Workday or SAP SuccessFactors do not originate in the payroll engine — they originate in the gap between HR system and payroll system. A hire recorded in Workday on the 15th of the month that does not reach the payroll processor until the 22nd misses the payroll cut-off. A salary change approved in SAP SuccessFactors that is not reflected in the downstream payroll system by period close creates an incorrect pay run that must be corrected in the following cycle — generating tax and statutory contribution corrections that compound over time.

Integration Architecture for Enterprise Payroll

• Bi-directional APIs between Workday and payroll systems (ADP, Ceridian, Sage People) using Workday's PICOF or Payroll Interface Toolkit
• Event-driven triggers: hire, termination, salary change, leave of absence, and organisation restructure events in Workday triggering immediate payroll system updates
• Automated reconciliation: payroll variance reports comparing HRIS headcount and compensation data against payroll run data before finalisation — with exception alerts routed to local payroll managers
• Audit log synchronisation: ensuring that changes to compensation in the HRIS are traceable through to the payroll record for statutory reporting and audit purposes

Our Global Payroll practice implements HRIS integration for Workday, SAP SuccessFactors, and BambooHR across all 12+ of our active markets. Related: 7 global payroll compliance obligations and contractor compliance in GCC markets.

Why AIFC Matters for Enterprise Entry into Central Asia

The Astana International Financial Centre (AIFC), established under Kazakhstan's constitutional amendment in 2018, operates under English common law administered by an independent court system staffed by international judges with English and Commonwealth legal backgrounds. For enterprises accustomed to common law contracting and dispute resolution, the AIFC provides a familiar legal environment within a jurisdiction that would otherwise require navigation of Kazakhstan's civil law framework.

The AIFC's FinTech regulatory sandbox, its investment management licensing framework, and its corporate law — based directly on English Companies Act principles — have made Astana the preferred structuring jurisdiction for enterprises entering Kazakhstan, Uzbekistan, and increasingly Azerbaijan and Georgia from a Central Asian base.

Uzbekistan's 2023 Labour Code and Contractor Engagement

Uzbekistan's revised Labour Code, effective January 2023, introduced significant changes to contractor engagement rules, including requirements for written agreements specifying deliverables, payment terms, and intellectual property ownership for all service contracts with individuals. Foreign enterprises engaging Uzbek contractors must comply with these requirements and with Uzbekistan's withholding tax regime for payments to non-residents of legal entities.

See our Central Asia & Caucasus market expertise and our Contractor Onboarding practice. Zine Consult's Tashkent headquarters provides in-country counsel for Uzbekistan and wider Central Asian engagements. Related: contractor misclassification risk.

The Governance Case for IaC

Infrastructure as Code is frequently positioned as a developer productivity tool — faster provisioning, reduced manual effort, consistent environments. The more significant enterprise argument is governance: IaC makes every infrastructure change reviewable, auditable, and reversible. In a multi-cloud enterprise environment where dozens of teams are provisioning cloud resources, IaC pipelines are the enforcement mechanism that ensures those resources conform to security, cost, and compliance baselines — regardless of which team provisioned them.

Tool Comparison: Terraform, Bicep, and CloudFormation

• Terraform (HashiCorp): Provider-agnostic, HCL-based, largest community, best suited for multi-cloud environments. The Terraform Cloud / Enterprise tier adds state management, team governance, and policy-as-code (Sentinel) features required at enterprise scale. BSL licence change in 2023 has driven some enterprises toward OpenTofu (CNCF fork)
• Bicep (Microsoft): Azure-native, type-safe, compiles to ARM. Superior Azure resource coverage and native integration with Azure Policy and Microsoft Defender for Cloud. The correct choice for enterprises with Azure-primary or Azure-exclusive environments
• CloudFormation (AWS): AWS-native, JSON/YAML, comprehensive AWS service coverage. AWS CDK (Cloud Development Kit) provides a more ergonomic programmatic interface for CloudFormation that is increasingly preferred for complex AWS-native environments

Policy-as-Code for Enterprise Compliance

IaC without policy enforcement is infrastructure visibility without infrastructure control. Checkov, tfsec, and OPA Conftest provide pre-deployment policy checks that validate resource configurations against security and compliance baselines before a Terraform apply or CloudFormation deployment executes. These tools integrate directly into CI/CD pipelines and produce the policy compliance evidence that ISO 27001:2022 Control 8.25 requires.

See our Cloud Operations practice for IaC implementation and governance. Related: multi-cloud architecture, zero-trust security, and FinOps governance.

The Checklist Audit Problem

The majority of internal audit findings that fail to produce management action share a common characteristic: they were generated by a compliance checklist rather than a risk-based assessment. A finding that “password rotation policy is not consistently enforced” tells management that a control is not operating effectively. A finding that “privileged access accounts in the production environment do not have password rotation enforced, creating material risk of undetected credential compromise in a system that processes 40,000 payment transactions daily” tells management what is at risk and why they should act.

The difference between these findings is not more auditor effort — it is a different audit methodology that starts with risk rather than controls.

Building a Risk-Based Internal Audit Programme

• Risk universe construction: Identify and assess the universe of risks relevant to the organisation's strategic objectives — not just compliance risks, but operational, financial, reputational, and technology risks
• Audit plan prioritisation: Allocate audit coverage based on risk ranking — highest inherent risk areas receive the most audit attention, regardless of whether they are easy to audit
• Control design vs operating effectiveness: Distinguish between controls that are poorly designed (will never work regardless of how well they are followed) and controls that are well-designed but not operating (a process problem)
• Root cause analysis: Every finding should be traced to its root cause — a missing control, an inadequately designed control, or a control that exists but is not understood or followed
• Management action plans: Findings without agreed management action plans and owners are observations, not audit findings. Track remediation to closure

Our Internal Audit practice is delivered in partnership with KPMG, aligned to IIA and COSO standards. Related: SOC 2 vs ISO 27001 and ISO 27001:2022 audit requirements.