5 Reasons AWS or Azure Certification Doesn’t Cover Your Own ISO 27001 Needs

Why This Matters

European SMBs frequently assume that running systems on AWS or Azure certified infrastructure satisfies customer and regulator compliance requirements. This misconception stalls enterprise deals during procurement review when buyers discover the vendor cannot demonstrate internal security controls, documented policies, or evidence of risk management practices independent of cloud provider certifications.

ISO 27001 audits evaluate your organisation’s Information Security Management System, not the infrastructure you rent. Cloud provider certifications prove their datacentres are secure. They do not prove your company follows documented procedures for user access, data classification, employee training, or incident response. Enterprise procurement teams, insurance underwriters, and regulatory auditors require evidence of these controls from your organisation directly.

The gap becomes critical when pursuing contracts with regulated customers in finance, healthcare, or insurance. Buyers ask vendors to provide SOC 2 Type II reports, ISO 27001 certificates, or completed security questionnaires. Responses stating “we run on AWS” fail to address buyer concerns about data handling practices, employee access governance, and third party risk management. This results in deal delays of three to six months or outright procurement rejection.

For European SMBs targeting enterprise customers or selling into regulated markets, understanding the difference between infrastructure certification and organisational security management determines whether deals progress or stall at vendor security review.

1. Cloud Provider Certification Covers Infrastructure, Not Data Governance

Best for: Understanding scope boundaries between cloud provider responsibilities and your organisation’s compliance obligations.

AWS and Azure ISO 27001 certifications apply to physical datacentres, network infrastructure, and platform services they operate. These certifications prove the provider maintains secure facilities, access controls to their own systems, and operational procedures for infrastructure management. They do not extend to how your organisation uses those services, handles customer data, or implements security policies within your applications.

Why cloud provider certification stops at infrastructure:

• Data classification and handling: ISO 27001 requires organisations to classify data by sensitivity and document handling procedures. AWS does not classify your customer data. Your organisation must define what constitutes sensitive information, how it should be stored, who can access it, and retention policies.
• Application security: Cloud providers secure the infrastructure layer. Your organisation remains responsible for secure coding practices, authentication mechanisms, API security, and vulnerability management within applications you deploy.
• Business process controls: ISO 27001 audits assess processes like change management, access provisioning workflows, and separation of duties. These are organisational controls that exist independent of infrastructure location.

Concrete example:

A fintech SMB with 120 employees processes payment data on AWS. AWS’s ISO 27001 certification proves their datacentres are secure. It does not prove the fintech company:

• Restricts database access to authorised personnel only
• Logs all queries containing customer financial data
• Conducts background checks on employees with data access
• Has documented procedures for data breach notification under GDPR

Enterprise customers purchasing payment processing services require evidence of these controls from the fintech vendor, not AWS.

Tradeoff this addresses:

Relying solely on cloud provider certification optimises for infrastructure assurance but leaves data governance, application security, and organisational policy gaps unaddressed. Enterprise procurement identifies these gaps immediately during vendor security review.

When this matters most:

This becomes critical when pursuing contracts with banks, insurance companies, healthcare providers, or any customer subject to GDPR, DORA, or industry specific compliance requirements. These buyers cannot accept “we run on certified infrastructure” as proof of your data handling practices.

2. Procurement Teams Audit Your Policies, Not AWS’s

Best for: Understanding what enterprise procurement actually reviews during vendor security assessment.

Vendor security questionnaires and due diligence processes require evidence of your organisation’s documented policies, not references to your infrastructure provider’s certifications. Procurement teams assess whether you maintain an Information Security Management System that includes risk assessments, policy documentation, employee training records, and incident response procedures.

What procurement teams require from vendors:

• Information security policy documentation: Written policies covering data protection, acceptable use, access control, and incident management. Cloud provider certifications do not produce these documents for your organisation.
• Risk assessment records: Evidence that your organisation identifies, evaluates, and mitigates security risks specific to your business operations and customer data.
• Employee security training completion: Records showing staff understand data handling requirements, phishing awareness, and security incident reporting procedures.
• Third party vendor management: Documentation of how your organisation evaluates and monitors subcontractors or service providers with data access.

Why referencing AWS certification fails procurement review:

Enterprise buyers evaluate your organisation’s security maturity, not your hosting provider’s infrastructure security. A vendor questionnaire asks, “Do you conduct annual security awareness training for employees with access to customer data?” The correct response is documented evidence of training completion. Stating “our infrastructure is AWS ISO 27001 certified” does not answer the question.

Concrete procurement failure example:

A 200 employee SaaS company responding to a financial services procurement questionnaire referenced AWS compliance for infrastructure questions and left policy documentation sections incomplete. The buyer’s procurement team flagged 14 unanswered controls covering data retention policies, employee background checks, and change management procedures. The deal stalled for four months while the vendor developed missing documentation.

Operational burden consideration:

Maintaining organisational security policies requires ongoing governance. Policies must be reviewed annually, updated when business operations change, and communicated to employees. This ongoing effort exists regardless of infrastructure provider and cannot be outsourced to AWS or Azure.

When this becomes a deal blocker:

Procurement review occurs after technical evaluation completes and commercial terms are agreed. Security questionnaire failures at this stage create costly delays because contract signing cannot proceed until compliance gaps close. For European SMBs targeting enterprise contracts, incomplete policy documentation extends sales cycles by three to six months per deal.

3. Access Controls and User Management Remain Your Responsibility

Best for: Understanding the boundary between cloud platform security features and organisational access governance requirements.

AWS and Azure provide Identity and Access Management tools. They do not implement access control policies, monitor privileged user activity, or enforce separation of duties within your organisation. ISO 27001 requires documented procedures for granting, reviewing, and revoking user access to systems containing customer data. These are organisational controls your company must implement and audit.

Access control gaps cloud certification does not address:

• User provisioning and deprovisioning: Your organisation must document and enforce procedures for adding new employees to systems, adjusting permissions when roles change, and removing access when employment ends.
• Privileged access monitoring: Engineers or administrators with production system access require additional controls including approval workflows, session logging, and periodic access reviews.
• Separation of duties: ISO 27001 requires controls preventing single individuals from having unchecked authority over critical operations like financial transactions or data exports.

Why this creates audit failures:

ISO 27001 auditors examine evidence that access controls are documented, implemented consistently, and regularly reviewed. They ask for:

• Written access control policies specifying approval processes
• Records showing quarterly or annual access reviews were completed
• Logs demonstrating privileged actions are monitored
• Evidence that terminated employee access was revoked within documented timeframes

Cloud platform tools enable these controls but do not create the policies, perform the reviews, or generate audit evidence automatically.

Concrete example:

A 150 employee healthtech company uses AWS and implemented SSO with role based access. During ISO 27001 audit preparation, they discovered:

• No documented policy specifying who approves production database access
• No records showing quarterly access reviews were conducted
• Three former contractors still had active AWS accounts six months after contract end
• No audit trail showing who approved each employee’s initial access level

The audit identified these gaps despite AWS infrastructure being ISO 27001 certified. The company spent eight weeks remediating access control documentation before achieving certification.

Scalability consideration:

Access control governance burden increases with company size. A 20 person startup can manage user access informally. At 100 employees with multiple systems, manual access reviews become operationally expensive without documented procedures and tools for tracking approvals and periodic reviews.

Choose this option if:

• Your company has more than 50 employees or contractors with system access
• You operate in regulated industries requiring audit trails for privileged access
• Enterprise customers ask security questionnaires covering access control procedures
• Procurement teams require evidence of documented user access governance

4. GDPR and Data Processing Obligations Cannot Be Outsourced

Best for: Understanding legal obligations under European data protection regulations that remain with your organisation regardless of infrastructure location.

GDPR designates your organisation as data controller or data processor depending on how you handle EU resident data. These legal obligations include data subject rights, breach notification requirements, and lawful basis for processing. Cloud provider certifications prove infrastructure security but do not address your organisation’s GDPR compliance obligations or data processing agreements with customers.

GDPR obligations that remain organisational responsibilities:

• Data subject access requests: Your organisation must respond to EU residents requesting copies of their personal data within 30 days. AWS does not handle these requests on your behalf.
• Data breach notification: If customer data is compromised, your organisation must notify affected individuals and regulators within 72 hours under GDPR Article 33. This obligation exists regardless of where data is hosted.
• Data processing agreements: Your organisation must establish written agreements with customers defining processing scope, security measures, and subprocessor relationships. Cloud provider contracts do not substitute for customer facing data processing agreements.
• Records of processing activities: GDPR Article 30 requires organisations to maintain registers documenting what personal data is processed, why, and who has access. This is an organisational record, not an infrastructure log.

Why AWS certification does not prove GDPR compliance:

GDPR evaluates your organisation’s data protection practices, not infrastructure security. A data protection authority investigating a breach asks for evidence of:

• Your documented lawful basis for processing personal data
• Records showing data minimisation principles are followed
• Evidence that customers were informed about data processing activities
• Procedures ensuring data subject rights are upheld

These are business process and policy controls maintained by your organisation independent of hosting infrastructure.

Concrete GDPR gap example:

A 180 employee SaaS company selling HR software to EU customers assumed AWS’s ISO 27001 certification covered GDPR requirements. During a customer audit, the buyer requested:

• Data Processing Agreement specifying processing scope and subprocessors
• Evidence of data subject access request procedures
• Records showing personal data retention periods are documented and enforced

The vendor could not provide these documents because they relied on infrastructure certification rather than implementing organisational GDPR compliance controls. The deal was delayed eight weeks while GDPR documentation was created.

Legal liability consideration:

Under GDPR, organisations face fines up to 4% of global annual revenue or €20 million for compliance failures. Cloud provider certification does not transfer this legal liability. Your organisation remains accountable for data protection obligations regardless of where systems operate.

When this becomes non negotiable:

Any European SMB processing EU resident personal data or selling to EU based enterprise customers must demonstrate GDPR compliance independent of cloud provider certifications. Buyers with internal data protection teams identify GDPR gaps during procurement and require corrective action before contracts are signed.

5. Incident Response and Business Continuity Are Organisation Specific

Best for: Understanding operational resilience requirements that reflect your business operations rather than infrastructure capabilities.

Cloud providers maintain infrastructure level incident response and disaster recovery capabilities. They do not create your organisation’s incident response procedures, business continuity plans, or communication protocols for notifying customers during outages or security incidents. ISO 27001 requires documented plans tested annually that are specific to your business operations and customer commitments.

Incident response gaps cloud certification does not address:

• Incident escalation procedures: Your organisation must document who is notified during security incidents, escalation thresholds, and communication protocols. AWS does not define these for your company.
• Customer notification procedures: When security incidents affect customer data, your organisation must notify customers according to contractual commitments and regulatory requirements. This is an organisational process, not an infrastructure feature.
• Business impact analysis: ISO 27001 requires organisations to identify critical business functions, assess disruption impact, and define recovery time objectives. These are business decisions specific to your operations.
• Post incident reviews: Your organisation must conduct reviews after security incidents to identify root causes, document lessons learned, and implement preventive measures.

Why this matters for enterprise procurement:

Enterprise customers often require vendors to demonstrate:

• Documented incident response plans covering security breaches and service disruptions
• Evidence that plans are tested at least annually
• Service level commitments for incident notification and recovery timeframes
• Business continuity plans proving critical operations can continue during infrastructure disruptions

Referencing AWS infrastructure resilience does not prove your organisation can detect incidents, communicate effectively with customers, or continue operations during disruptions.

Concrete business continuity failure:

A 90 employee fintech company experienced a database misconfiguration that exposed customer transaction data for six hours. The company:

• Had no documented incident response procedure specifying who should be notified
• Took 14 hours to notify customers because communication protocols were undefined
• Had no post incident review process to identify preventive measures

During subsequent enterprise procurement review, buyers rejected the vendor due to absence of documented incident management procedures despite AWS infrastructure being ISO 27001 certified.

Operational maturity consideration:

Incident response and business continuity planning require upfront investment in documentation, training, and testing. A 30 person startup may operate with informal procedures. At 100 employees serving enterprise customers, documented and tested plans become non negotiable for procurement approval.

Choose this option if:

• Your company serves customers where downtime or data exposure carries material financial or reputational risk
• Enterprise buyers require evidence of incident response capabilities during procurement
• You operate in regulated industries with mandatory breach notification requirements
• Service level agreements commit to specific recovery time objectives or incident notification windows

When Lower Ranked Options Are Better

Very early stage startups with no enterprise customers: Companies with fewer than 20 employees selling exclusively to small businesses may defer organisational certification and rely on cloud provider infrastructure security for 12 to 18 months. This applies when target customers do not require vendor security questionnaires or procurement review. However, this creates technical debt that becomes expensive to remediate when pursuing first enterprise contract.

Pure infrastructure resellers with no data processing: Companies reselling cloud services without processing customer data or providing application level services may reference cloud provider certifications. This applies to pure managed service providers who operate customer owned infrastructure but do not access, store, or process customer application data. This scenario is rare for European SMBs building SaaS applications.

Organisations already holding SOC 2 Type II: European SMBs with valid SOC 2 Type II reports may satisfy some EU buyers initially. However, ISO 27001 becomes required as the customer base expands beyond US headquartered buyers to include European banks, insurance companies, or regulated entities. The 80% control overlap between SOC 2 and ISO 27001 reduces implementation effort, but both certifications assess organisational controls beyond cloud provider infrastructure certification.

Real World Decision Scenarios

Scenario: SaaS Company Pursuing First Enterprise Contract

Profile:

• Company size: 85 employees
• Revenue: €4.2 million annually
• Target market: 60% EU, 40% UK
• Current state: Running on AWS, no formal security policies documented
• Growth stage: Series A funded, targeting enterprise segment

Recommendation: Begin ISO 27001 implementation immediately regardless of AWS infrastructure certification.

Rationale: Enterprise procurement will require documented security policies, risk assessments, and evidence of security management system operation. Relying on AWS certification without organisational controls will stall this deal and all subsequent enterprise pursuits. Implementation takes six to nine months, meaning delayed action extends time to first enterprise contract closure.

Expected outcome: ISO 27001 certification achieved in eight months, enabling procurement approval with enterprise customers within same fiscal year.

Scenario: Healthtech Company Serving NHS and Private Healthcare

Profile:

• Company size: 140 employees
• Revenue: €8.1 million annually
• Target market: 70% UK NHS trusts, 30% private EU healthcare providers
• Current state: AWS hosted, basic access controls implemented
• Growth stage: Profitable, expanding to EU markets

Recommendation: Prioritise ISO 27001 over reliance on cloud provider certification.

Rationale: Healthcare buyers enforce strict vendor security requirements including documented access controls, GDPR compliance evidence, and incident response procedures. NHS procurement specifically requires ISO 27001 or equivalent. Expanding to EU healthcare market mandates GDPR compliance demonstration that AWS certification cannot provide.

Expected outcome: NHS procurement approval achieved within six months post certification. EU healthcare customer acquisition unlocked enabling 40% revenue growth over 18 months.

Scenario: Fintech Selling to Banks and Payment Processors

Profile:

• Company size: 200 employees
• Revenue: €15 million annually
• Target market: 80% EU banks, 20% payment processors
• Current state: AWS with documented policies but no external audit
• Growth stage: Growth stage, targeting tier 1 banks

Recommendation: Obtain ISO 27001 certification supplementing existing policy documentation.

Rationale: Banks require vendor ISO 27001 certificates as procurement gate. Documented internal policies are necessary but insufficient without third party audit validation. Deals with tier 1 banks involve six to 12 month procurement cycles where certification absence causes immediate rejection regardless of AWS infrastructure security.

Expected outcome: Bank procurement cycles reduced from 12 months to eight months post certification. Annual contract value with tier 1 banks increases from €2 million to €6 million within two years.

FAQ