What the Shared Responsibility Model Actually Says
Every major cloud provider publishes a Shared Responsibility Model. AWS describes it as follows: AWS is responsible for the security of the cloud; customers are responsible for security in the cloud. Microsoft Azure uses nearly identical language. This is not a technicality — it is a fundamental architectural principle with direct implications for ISO 27001 compliance.
Think of it this way. When your company leases office space in a Grade-A commercial building in Hong Kong, the building management company is responsible for the structural integrity, fire suppression systems, lift maintenance, and lobby security. Those systems may hold valid safety certifications. But the locks on your office door, the classification of documents on your desks, who has access to your server room, and what happens when an employee resigns — none of that falls under the building manager's certification. It is entirely your responsibility.
The cloud is the building. Your ISMS is the office.
The table below maps the responsibility boundary in concrete technical terms:
| Security Layer | Cloud Provider Responsibility | Your Company's Responsibility |
|---|
| Physical data centres | Facilities, power, cooling, physical access | — |
| Network infrastructure | Core networking hardware and virtualisation | VPC configuration, security group rules, firewall policies |
| Managed services (e.g. RDS) | OS patching for managed services | Configuration, access control, backup policies |
| Virtual machines (IaaS) | Hypervisor layer | OS patching, hardening, application security |
| Data | — | Classification, encryption, retention, deletion policies |
| Identity & Access Management | IAM tooling provided | IAM configuration, least-privilege enforcement, MFA, access reviews |
| Logging & monitoring | Log tooling available (CloudTrail, Azure Monitor) | Enabling, configuring, retaining, and reviewing logs |
| Incident response | Infrastructure-level response | Business-level incident response plan and procedures |
| Employee security | — | Security awareness training, background checks, onboarding/offboarding |
| Policies & documentation | — | ISMS documentation, risk assessments, internal audits |
AWS's own ISO 27001 FAQ states explicitly that its certification "covers the AWS security management process over a specified scope of services and data centres." That scope is AWS's infrastructure. Your workloads, your data, and your organisational processes are outside it.
Five Scenarios Where This Misconception Creates Real Business Risk in Hong Kong
1. Enterprise and Government Procurement Requires Your Certificate, Not AWS's
When a bank, a listed company, or a government department in Hong Kong issues a vendor security questionnaire, they are asking about your information security management system. They want to see your ISO 27001 certificate — issued in your company's name, covering your operations. Responding with "we use AWS, which is ISO 27001 certified" will not satisfy the question. In practice, procurement teams in regulated industries treat this response as a failure to demonstrate internal controls, leading to deal delays of three to six months or outright rejection.
This risk is growing. Following the enactment of the Protection of Critical Infrastructures (Computer Systems) Ordinance on 1 January 2026, operators in Hong Kong's eight designated critical infrastructure sectors — including energy, banking, transport, and healthcare — face heightened scrutiny of their supply chain security. Vendors to these operators will increasingly be required to demonstrate their own ISO 27001 certification.
2. Your Data Governance Policies Cannot Be Outsourced to AWS
ISO 27001 requires organisations to establish and maintain a comprehensive Information Security Management System (ISMS). The ISMS must include a data classification policy (which data is confidential, which is public, and how each category is handled), a data retention and disposal policy, records of employee security awareness training, and a risk assessment that reflects your specific business context and threat landscape.
None of these documents exist in AWS's certification. They are inherently specific to your organisation — your business processes, your data types, your regulatory obligations, your people. An ISO 27001 auditor will request these documents as primary evidence. The absence of AWS's certificate from your audit pack will not be noticed; the absence of your own ISMS documentation will result in a major non-conformity.
3. Identity and Access Management Configuration Is Entirely Your Responsibility
AWS provides powerful IAM tooling, but the configuration of that tooling — and the governance processes around it — is your responsibility. An ISO 27001 auditor assessing a cloud environment will ask: Do your IAM roles follow the principle of least privilege? Are access rights reviewed at least annually? Are privileged accounts protected by multi-factor authentication? Are access rights revoked within 24 hours of an employee's departure?
These questions reflect your company's internal governance maturity, not AWS's infrastructure security. It is worth noting that the most common cause of cloud data breaches is not a failure of the cloud provider's infrastructure — it is customer-side misconfiguration. Publicly accessible S3 buckets, overly permissive IAM policies, and unrevoked credentials from former employees are consistently among the leading causes of cloud security incidents. ISO 27001 certification for your organisation provides the governance framework to prevent precisely these failures.
4. Incident Response and Business Continuity Are Unique to Your Organisation
When a security incident occurs — a ransomware attack, a data breach, or a service outage — AWS will protect its own infrastructure. But how your organisation detects the incident, contains it, notifies affected parties, and recovers operations is entirely defined by your own Incident Response Plan and Business Continuity Plan. ISO 27001 requires these plans to be documented, tested, and regularly updated.
These plans must be specific to your business. What is your Recovery Time Objective (RTO) for your core systems? Who is the designated incident response lead? What is your notification procedure under Hong Kong's Personal Data (Privacy) Ordinance (PDPO) in the event of a data breach? These answers are yours alone to provide, and an ISO 27001 auditor will verify that they exist and are operationally credible.
5. Hong Kong Regulators Assess Your Organisation's Controls, Not Your Provider's
The Hong Kong Monetary Authority's Cyber Resilience Assessment Framework (C-RAF 2.0), the Office of the Privacy Commissioner for Personal Data's guidance under PDPO, and the new Critical Infrastructure Ordinance all assess the security posture of your organisation directly. Regulatory examiners will request your risk assessment records, your security policies, your internal audit reports, and evidence of management review. A cloud provider's certification document is not a substitute for any of these.
What Cloud Provider Certification Does Offer You
Having clarified the misconception, it is important to acknowledge that your cloud provider's ISO 27001 certification is not without value — its value is simply specific and bounded.
When building your own ISMS, you can legitimately reference your cloud provider's certification as part of your supplier security assessment (a requirement under ISO 27001 Annex A, Control 5.19). This reduces the due diligence burden for the infrastructure layer and allows your risk assessment to focus on the application and organisational layers where your actual risks reside.
Furthermore, cloud providers offer a rich set of security tooling that directly supports ISO 27001 technical controls: AWS CloudTrail and Azure Activity Log for audit logging, AWS GuardDuty and Microsoft Defender for Cloud for threat detection, AWS KMS and Azure Key Vault for encryption key management, and AWS Config and Azure Policy for configuration compliance monitoring. Leveraging these tools can significantly accelerate the implementation of your ISMS and reduce the time and cost of achieving certification.
How to Achieve ISO 27001 Certification in a Cloud Environment: Four Practical Steps
- Step 1 — Define Your ISMS Scope Precisely
In a cloud environment, the scope statement must explicitly identify which AWS accounts and Azure subscriptions are in scope, which regions and services are used, what categories of data are processed, and which regulatory requirements apply (e.g. PDPO, C-RAF, the Critical Infrastructure Ordinance). Scope definition is the foundation of the entire certification process and is best undertaken with guidance from an accredited certification body.
- Step 2 — Conduct a Cloud-Specific Risk Assessment
Cloud environments carry risks that differ from traditional on-premise infrastructure. Your risk assessment must address misconfiguration risks, overly permissive access controls, insufficient logging, third-party integration risks, and data residency considerations. For Hong Kong-based organisations, data sovereignty — ensuring that personal data of Hong Kong residents is not transferred to jurisdictions without adequate protection — is a specific risk that must be assessed and documented.
- Step 3 — Implement Technical Controls Using Cloud-Native Tools
Map your cloud provider's security tooling to the relevant controls in ISO 27001 Annex A. Enable CloudTrail or Azure Activity Log across all accounts. Enforce MFA on all privileged accounts. Encrypt data at rest and in transit. Configure security group rules to enforce least-privilege network access. Set up automated alerts for anomalous activity. Document each control implementation as evidence for your audit.
- Step 4 — Build the Management and Documentation Layer
This is the layer most commonly underestimated by organisations approaching ISO 27001 for the first time — and the layer that auditors scrutinise most carefully. It includes your Information Security Policy, your asset inventory (which must include all cloud resources), your employee training records, your supplier management procedure (covering your cloud providers), your change management process, and your internal audit programme. These documents demonstrate that security is managed as a systematic organisational discipline, not merely a set of technical configurations.
Conclusion
Cloud computing has transformed the economics of enterprise technology, but it has not transferred the fundamental principle of information security accountability. The data you hold — your clients' data, your employees' data, your business intelligence — is your responsibility regardless of where it is stored.
AWS and Azure's ISO 27001 certifications represent those providers' commitment to the security of their own infrastructure. Your company's ISO 27001 certification represents your commitment to your clients, your partners, and the regulators who oversee your industry. In an increasingly security-conscious Hong Kong market, the two are not interchangeable.
Associated Services by DQS HK
