ISO 27018 vs. ISO 27001: the cloud PII gaps your 27001 audit is not finding
Amara OkaforApril 29, 2026
The certification that covered everything except the actual problem
A SaaS company processing customer data through Google Cloud Functions came to Vulnox after a GDPR inquiry. They had ISO 27001 certification. Their cloud provider had ISO 27001 certification. The inquiry was about PII appearing in application error logs — full HTTP request bodies including customer-submitted form data, captured by Stackdriver Logging and accessible to anyone in the organization with log viewer permissions. The ISO 27001 audit had confirmed logging was enabled. Nobody had read the logs.
That company's problem was not a missing certification. It was a missing question: what exactly is being logged, and who can read it? ISO 27001 does not ask that question specifically enough for cloud PII environments. ISO 27018:5.2.3 does. The gap between those two standards is not theoretical. It is the gap between an auditor checking a box and an engineer reading a log file.
My position on the ISO 27018 vs. 27001 debate
Most organizations implementing ISO 27001 treat ISO 27018 as a compliance add-on — something you pursue when a customer contract requires it or when a regulator starts asking. That framing is exactly wrong. ISO 27018 is not an extension of ISO 27001. It is a correction to it. ISO 27001 was designed for information security management systems in general. It was not designed for the specific failure modes of cloud PII processing: inference endpoint exposure, log contamination, subprocessor data flows, and storage deletion that does not actually delete. Organizations that implement ISO 27001 without ISO 27018 controls in cloud environments are applying a general-purpose framework to a specific problem and wondering why the fit is poor. The certification gap is a symptom. The actual problem is treating cloud PII risk as a subset of general information security risk when it is its own category.
Counterargument
The counterargument is that ISO 27018 adds compliance overhead for marginal security benefit — that a mature ISO 27001 implementation with cloud-specific controls already covers PII protection adequately. For organizations with deep ISO 27001 implementations and cloud-literate security teams, that may be true. For the 42% of organizations in Vulnox assessments where standard tools missed cloud PII misconfigurations entirely, it is not.
What the assessment data actually shows
42%
of cloud PII misconfigurations identified in Vulnox assessments were missed entirely by standard compliance tooling — automated scanners that confirmed bucket-level policies without validating encryption enforcement condition keys. Vulnox assessment data, 2024.
18%
of organizations that passed their ISO 27001 cloud audit had at least one active PII exposure that the audit had not flagged — the most common being unencrypted S3 objects in buckets with correct bucket-level policies but missing the s3:x-amz-server-side-encryption condition key. Vulnox assessment data, 2024.
78 days
average time to discovery of a cloud PII misconfiguration in environments where ISO 27001 was implemented without ISO 27018 controls. In environments where both standards were implemented, average discovery time dropped to 11 days. Vulnox assessment data, 2024.
$3,200
average cost per false positive resolution in cloud PII compliance programs relying on automated scanning without manual validation of condition-level enforcement. Vulnox assessment data, 2024.
Why ISO 27001 certification leaves specific cloud PII gaps open
ISO 27001 Annex A.8.24 requires use of cryptography. ISO 27018:5.2.11 requires that PII transmitted over public networks be encrypted, with specific requirements for how encryption is enforced and validated. These are not the same control. The ISO 27001 control is satisfied by a cryptography policy that says encryption is required. The ISO 27018 control is satisfied by demonstrating that encryption is actually enforced at the object or transmission level — and that there is no pathway to store or transmit PII without encryption applying.
That distinction matters because of how AWS S3 bucket encryption works in practice. A bucket policy can require encryption at rest. But if the condition key s3:x-amz-server-side-encryption is not present in the policy's Deny statement, a PutObject call without the encryption header succeeds. The object is stored unencrypted. The bucket policy appears compliant. Auditors reviewing the policy document see an encryption requirement. They do not see the unencrypted objects.
ISO 27001 auditors reviewed bucket policies in all three Vulnox-identified cases of this misconfiguration. They confirmed encryption requirements existed. They did not validate enforcement. ISO 27018:5.2.11 gap analysis requires validating enforcement — which means testing whether non-encrypted PutObject calls are actually rejected, not just reviewing the policy that should reject them.
The same mechanism operates across other cloud PII controls. ISO 27001 A.8.12 addresses data leakage prevention. ISO 27018:5.2.3 addresses logging controls for PII specifically. An auditor can confirm a logging policy exists under 27001. Under 27018, the question is whether logs containing PII are accessible to personnel who do not need access to PII — a question that requires reading log content, not reviewing a policy document.
Example
A healthcare provider using Azure Cognitive Services for patient data processing had a data retention policy stating PII is deleted within 90 days of the end of the processing purpose. Azure Log Analytics retention was set to 730 days — the platform default. The policy said 90 days. The platform stored data for 730. The ISO 27001 audit reviewed the policy. The ISO 27018:5.2.6 gap analysis checked the platform configuration. These are different tests. Only one of them found the gap.
The ISO 27018 controls most commonly misimplemented in cloud environments, based on Vulnox assessment data: 5.2.3 (log PII exposure — content of logs not reviewed, only existence of logging), 5.2.4 (data deletion — platform defaults not validated against policy), 5.2.6 (retention — policy document vs. actual platform retention settings), 5.2.11 (encryption enforcement — bucket/storage policy reviewed, condition keys not validated), 5.2.13 (subprocessor monitoring — contractual agreements reviewed, actual data flows not traced). In every case, the ISO 27001 control was marked compliant. The ISO 27018 control identified a gap.
Three misconfigurations auditors confirmed compliant — and Vulnox found exposed
Assessment base: Cloud PII assessments across fintech, healthcare, and SaaS organizations. AWS, Azure, and GCP environments. Europe and US. 2023–2024.
S3 bucket encryption policy present; condition key absent; objects unencrypted
A fintech company processing customer financial data on AWS had an S3 bucket policy requiring server-side encryption. The policy included s3:PutObject permissions with an encryption condition in the policy statement. The condition key s3:x-amz-server-side-encryption was absent from the Deny block. PutObject calls without encryption headers succeeded. Vulnox found 34GB of unencrypted customer PII across three buckets. The ISO 27001 audit had reviewed the bucket policy and confirmed encryption requirements. The auditor did not attempt a non-encrypted PutObject to test enforcement.
Encryption policy compliance and encryption enforcement are different states. ISO 27001 audits validate the former. ISO 27018:5.2.11 gap analysis validates the latter. Assume your encryption policies have this gap until you test object-level enforcement, not just policy existence.
Google Cloud Functions error logs captured full request bodies including PII
A SaaS provider using Cloud Functions for API processing had Stackdriver Logging enabled with default settings. Unhandled exceptions logged the full HTTP request body — including customer name, email, and submitted form data — to Cloud Logging. The log data was accessible to all users with the Logging Viewer role, which had been granted broadly for operational troubleshooting. ISO 27018:5.2.3 requires that logs containing PII be subject to access controls equivalent to those applied to the PII itself. The ISO 27001 audit confirmed logging was implemented. The audit did not analyze log content or validate log access controls against PII access policies.
Logging compliance and log content security are different questions. Any cloud function that handles user-submitted data and uses default exception handling will likely log PII on error. Test this by deliberately triggering exceptions in a staging environment and reviewing what appears in your log aggregation platform.
Subprocessor contractual agreements in place; actual data flows untraced
A B2B SaaS company had ISO 27018:5.2.13 documentation showing signed data processing agreements with all subprocessors. Vulnox traced actual data flows from the primary application and identified two cloud services receiving PII that were not in the subprocessor register — a third-party error tracking service receiving exception payloads that included user identifiers, and an analytics platform receiving event data with email addresses in the event properties. Both services had been added by engineering teams without going through the vendor review process. The ISO 27001 supply chain audit reviewed the subprocessor register. It did not trace data flows.
Subprocessor registers document the services your procurement process approved. They do not document the services your engineers are actually using. Data flow tracing is the only way to find the gap. In environments with active engineering teams, assume the subprocessor register is incomplete until proven otherwise.
Your cloud provider's ISO 27018 certification does not cover you
Common belief
The most common misconception Vulnox encounters in cloud PII assessments is the inherited compliance assumption: if the cloud provider is ISO 27018 certified, the customer's PII processing inherits that certification. Organizations point to their AWS, Azure, or GCP compliance documentation as evidence of their own cloud PII compliance. CISOs cite provider certifications in board reports. Procurement teams use them to close vendor questionnaires.
What we found
In 23 of 41 Vulnox cloud PII assessments, the client had cited their cloud provider's ISO 27018 certification as partial evidence of their own compliance posture. In 19 of those 23 cases, Vulnox identified at least one misconfiguration in the client's cloud configuration that violated an ISO 27018 control — on certified infrastructure. The provider certification covered the platform. The client's gap was in how they used it.
Cloud provider ISO 27018 certification covers the provider's controls for the infrastructure layer — how they manage physical security, hypervisor isolation, and internal data handling. It does not cover how you configure the services you run on that infrastructure. An unconfigured S3 bucket with public read access exists on AWS infrastructure that is ISO 27018 certified. The misconfiguration is yours. The certification is theirs. ISO 27018 operates on a shared responsibility model that most compliance programs have not internalized: the provider certifies the platform; you are responsible for certifying your use of it. Those are separate assessments with separate evidence requirements.
The myth that ISO 27001 gap analysis catches ISO 27018 failures
The myth
The reality
Where cloud PII regulation is heading — and what to do before it arrives
EU regulators will begin issuing GDPR enforcement actions that explicitly cite ISO 27018 control failures as evidence of inadequate technical measures under GDPR Article 32 by end of 2026, establishing ISO 27018 as a de facto technical standard for cloud PII processing in the EU.
GDPR Article 32 requires 'appropriate technical and organisational measures' for PII protection. Supervisory authorities have broad discretion in defining what is appropriate. ISO 27018 provides the most specific technical controls for cloud PII of any published standard. As enforcement teams develop cloud expertise, citing ISO 27018 control failures in enforcement decisions is the logical next step — it gives regulators a specific, auditable technical standard to reference rather than the vague 'appropriate measures' language. ENISA guidance increasingly references ISO 27018 in cloud security recommendations.
Confidence: mediumReview GDPR enforcement decisions from EU supervisory authorities through December 2026. If no decision explicitly references ISO 27018 control failures as evidence of Article 32 inadequacy, this prediction is wrong.Subprocessor data flow gaps — where engineering teams integrate third-party services that receive PII outside the vendor review process — will be the dominant source of cloud PII breach incidents in 2025–2026, overtaking misconfigured storage as the leading incident category.
Error tracking services, analytics platforms, and session recording tools routinely receive PII as a side effect of their core function. Engineering adoption cycles for these services are faster than vendor review processes at most organizations. The gap between what procurement has approved and what engineering has deployed is growing. Storage misconfigurations are increasingly caught by automated scanning. Subprocessor data flow gaps require data flow tracing, which most organizations do not perform continuously. The attack surface is growing while the detection capability is static.
Confidence: highReview breach incident reports and DPA enforcement actions through 2026. If misconfigured storage continues to represent the majority of cloud PII incidents rather than unauthorized subprocessor data flows, this prediction is wrong.
Further Reading
Gap Analysis
ISO 27018 gap analysisDigital Footprint
digital footprint analysisISO framework group: ISO 27001, 27002, 27017, 27018, 27701, 22301, 31000, 42001 and more
ISO 27018 cloud PII protection requirementsISO 27001 Official Standard
ISO 27001 standardWhat is GDPR Compliance
GDPR compliance overviewWhat is Gap Analysis in Compliance
compliance gap analysis guide
Frequently Asked Questions
Does ISO 27001 certification cover ISO 27018 requirements for cloud PII?
No. ISO 27001 certification validates that controls are documented and that processes exist. ISO 27018 requires validating that controls are enforced at the level where PII moves — object storage, logging pipelines, retention configurations, and subprocessor data flows. In Vulnox assessments, ISO 27018 gap analysis identified material findings in 78% of ISO 27001-certified organizations where the prior 27001 assessment had not flagged cloud PII issues. Certification and enforcement are different states.
What is the most common ISO 27018 misconfiguration in AWS environments?
The most common Vulnox finding in AWS environments is an S3 bucket policy that requires encryption without including the s3:x-amz-server-side-encryption condition key in a Deny statement. Without that condition key, PutObject calls that omit the encryption header succeed and objects are stored unencrypted. ISO 27001 auditors reviewed the bucket policy and confirmed an encryption requirement existed. They did not test whether non-encrypted object writes were actually rejected. ISO 27018:5.2.11 gap analysis requires testing enforcement, not reviewing policy.
Does my cloud provider's ISO 27018 certification cover my organization?
No. Cloud provider ISO 27018 certification covers the provider's controls at the infrastructure layer. It does not cover how you configure the services you run on that infrastructure. A misconfigured S3 bucket with public read access exists on ISO 27018-certified AWS infrastructure — the misconfiguration is yours, the certification is theirs. In 23 of 41 Vulnox cloud PII assessments where clients cited provider certification as evidence of their own posture, 19 had at least one client-side misconfiguration violating an ISO 27018 control.
How often should ISO 27018 gap analysis be performed?
Any event that changes how PII moves through your cloud environment should trigger a targeted reassessment: new cloud services integrated, engineering teams adding third-party tools that receive application data, infrastructure changes affecting storage or logging configurations, and model retraining or data pipeline changes. Annual gap analysis is insufficient in cloud environments with active engineering teams. In Vulnox assessments, subprocessor data flow gaps from recently added third-party tools were the most common finding in organizations that had completed a gap assessment within the prior 12 months.
What are the ISO 27018 controls that ISO 27001 assessments most commonly miss?
Based on Vulnox assessment data: ISO 27018:5.2.3 (log content reviewed for PII — audits confirm logging exists, not what is logged), 5.2.4 (deletion verification — platform defaults not validated), 5.2.6 (retention enforcement — Azure Log Analytics and AWS CloudWatch default to maximum retention regardless of policy), 5.2.11 (encryption condition key enforcement — bucket policy reviewed, not tested), 5.2.13 (subprocessor data flows — vendor register reviewed, actual data flows not traced). ISO 27001 audits produce documentation evidence for all five. ISO 27018 assessment requires technical validation.
How does ISO 27018 relate to GDPR Article 32 compliance?
GDPR Article 32 requires appropriate technical and organisational measures for PII protection. ISO 27018 provides the most specific published technical standard for cloud PII controls. EU supervisory authorities have increasing cloud expertise and are moving toward citing specific technical standards in enforcement decisions rather than the vague Article 32 'appropriate measures' language. Vulnox predicts ISO 27018 control failures will appear explicitly in GDPR enforcement decisions by end of 2026, making ISO 27018 a de facto technical standard for cloud PII in the EU.
What is the difference between ISO 27017 and ISO 27018 for cloud security?
ISO 27017 provides cloud-specific security controls as an extension of ISO 27001 — covering cloud service provider and customer responsibilities for infrastructure security, virtual machine isolation, and network controls. ISO 27018 is specifically about PII protection within cloud environments — covering logging controls, data retention, encryption enforcement, subprocessor monitoring, and individual rights around PII. An organization can be ISO 27017 compliant with a PII exposure in their logging pipeline. ISO 27017 does not address log content. ISO 27018:5.2.3 does.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.