Control 1-5-3 of the Essential Cybersecurity Controls (ECC – 2 : 2024) requires organisations to perform a formal cybersecurity risk assessment prior to moving systems, services, or data to a cloud environment; this post explains how to design and execute that assessment in the context of the Compliance Framework so a small business can both mitigate technical risk and produce audit-ready evidence.
What the Control requires and why it matters
At a practical level the Compliance Framework expects a documented decision-making process that: (1) defines the scope of the migration, (2) identifies assets, data sensitivity and regulatory constraints, (3) assesses threats and vulnerabilities introduced or changed by the cloud move, and (4) records mitigations, residual risk and an approval or rejection decision. For small businesses, meeting Control 1-5-3 prevents common mistakes such as assuming the cloud provider covers all security responsibilities, or migrating regulated personal data without required contractual protections.
Step-by-step assessment process tailored to the Compliance Framework
Follow these steps to create a defensible assessment aligned to the Compliance Framework: 1) Scope and inventory: list applications, components (databases, storage, compute, networking), data classification (public/internal/confidential/regulated) and business owners; 2) Define acceptance criteria: maximum tolerable downtime, confidentiality impact levels, and acceptable residual risk thresholds; 3) Map the migration model (IaaS/PaaS/SaaS) and document the shared responsibility boundaries with the cloud service provider (CSP); 4) Threat and vulnerability analysis: use STRIDE threat categories and run vulnerability scans on current images/IaC; 5) Risk scoring: quantify likelihood and impact (e.g., 1–5 scale) and compute risk = likelihood × impact to prioritise mitigations; 6) Produce a migration risk register and remediation plan with timelines and owners, and 7) Gate the migration on completion of high-priority mitigations or documented risk acceptance by a designated approver.
Technical controls and implementation details
Translate risk findings into concrete technical controls that auditors will recognise: enforce least-privilege IAM policies (use roles, not long-lived keys), require MFA for privileged accounts, use KMS-managed keys with automatic rotation (AES-256 at rest), use TLS 1.2+ for data in transit, isolate workloads in VPCs/subscriptions with subnet segmentation and security groups / network security groups, enable CSP-native logging (AWS CloudTrail + VPC Flow Logs / Azure Monitor / GCP SCC) and ship logs to a tamper-resistant SIEM or cloud storage with retention that matches your policy. Run IaC scanning (Checkov, Terrascan) and container image scanning (Trivy, Clair) as part of a CI/CD pipeline so configuration issues are caught before deployment.
Real-world small business scenario
Example: a 50-employee SME wants to move its CRM and customer documents from an on-prem VM to a cloud-hosted IaaS setup. The assessment identifies that CRM data includes personal data and financial identifiers (moderate-high confidentiality impact). The team maps responsibilities: the CSP will secure the hypervisor and physical datacenter, while the SME must secure the VM images, OS patches, application access, backups, and encryption keys. Mitigations required before migration include enabling disk encryption with KMS, configuring a bastion host with restricted SSH (security group + MFA), applying a WAF for the CRM endpoints, and implementing role-based access controls in the application. The migration is gated: no production cutover until disk encryption, logging and MFA are verified and a rollback plan is documented and tested.
Tools, artefacts, and evidence for auditors
Produce artifacts that satisfy Compliance Framework reviewers and ECC auditors: the risk assessment report (scope, methodology, scoring matrix), migration risk register (with residual risk indicators), signed acceptance or remediation closure records, IaC and scan reports, CSP configuration snapshots (security group rules, IAM policies), log export proof (e.g., S3/Log Analytics storage with retention), and contract addenda such as Data Processing Agreements. Recommended tools for small teams: Cloud Provider native tools (AWS Well-Architected + Config + GuardDuty, Azure Secure Score, GCP Security Command Center), open-source scanners (Prowler, ScoutSuite), IaC scanners (Checkov), and simple spreadsheets based on NIST/ISO templates to record risk scoring if you lack a GRC platform.
Risks of skipping or doing a weak assessment
If Control 1-5-3 is not properly implemented the organisation risks misconfigured cloud permissions (leading to data exfiltration), inadequate encryption leading to breaches, failure to meet data residency or regulatory obligations with resulting fines, service outages from poor architecture decisions, and loss of audit evidence and trust. For small businesses the financial and reputational impact of a single cloud data leak or extended outage can be existential; auditors will flag the absence of a pre-migration risk assessment as a control deficiency under the Compliance Framework.
Compliance tips and best practices
Keep your assessment practical: adopt templates from the Compliance Framework, keep the scope tight (migrate critical assets in phases), automate evidence collection where possible, and use a migration gate checklist that includes mandatory items (data classification confirm, encryption proof, IAM proof, logging enabled, recovery test). Consider a third-party review for higher-risk migrations, and schedule a post-migration review (30–90 days) to validate that controls operate as intended and to update the risk register. Finally, embed continuous monitoring (CSPM/CWPP) so drift is detected and corrected after cutover.
Summary: To satisfy ECC – 2 : 2024 Control 1-5-3 under the Compliance Framework, implement a formal, documented pre-cloud-migration risk assessment that ties asset discovery, data classification, threat analysis, and quantified risk scoring to concrete technical mitigations and migration gates; produce evidence artifacts (risk report, remediation tracker, configuration snapshots and logs), automate checks where possible, and treat the assessment as a living process that continues after migration to maintain compliance and reduce real-world business risk.
