GDPR vs ISO 27001: what each framework validates and what each misses technically
Amara OkaforApril 29, 2026
Key takeaways
GDPR Article 32 requires ''appropriate technical and organisational measures'' but does not specify what those measures are — ISO 27001 specifies controls but does not require that those controls protect personal data in the ways GDPR demands. Running both frameworks simultaneously does not close the gap between them.
The control neither framework technically validates is encryption key management: GDPR Article 44 data residency requirements are defeated by encryption keys stored in a different jurisdiction, and ISO 27001 Annex A.10 cryptography controls address key policy but do not require testing of where keys are physically held or who can access them under foreign legal process.
In Vulnox assessments of organizations dual-certified under GDPR and ISO 27001, the most common finding was Redis instances and object storage buckets accessible without authentication from public IP addresses — a technical configuration gap that passes both GDPR compliance reviews and ISO 27001 audits because neither framework''s assessment methodology tests for it specifically.
SOC 2 Type II adds operational effectiveness testing that GDPR and ISO 27001 audits lack — but SOC 2 scope is defined by the organization, and most SOC 2 engagements exclude the infrastructure components where unauthenticated external access is most common.
The processor agreement gap is the compliance control most likely to pass documentation review and fail technical reality: Article 28 DPAs that reference ISO 27001 certification as the processor''s security baseline are legally sound and technically uninformative — ISO 27001 certification does not tell you whether the processor''s environment is actually secure.
Prediction: within 24 months, GDPR enforcement decisions will begin citing ISO 27001 certification as insufficient evidence of Article 32 compliance in specific technical areas, producing a precedent that controllers cannot rely on processor certification as a substitute for independent technical validation.
TL;DR
GDPR tells you what outcomes to achieve with data protection. ISO 27001 tells you what controls to implement to achieve security. The two frameworks overlap enough that organizations assume running both means they are covered. The assumption is wrong in specific, testable ways. This article is about where each framework stops short technically and what the gap between them looks like in actual environments.
The certified environment with the open cache
A SaaS company operating under GDPR with ISO 27001 certification processes customer personal data on AWS infrastructure. The ISO 27001 audit reviewed their security policy, access control documentation, and incident response procedures. The GDPR compliance review confirmed their ROPA, privacy notices, lawful basis documentation, and processor agreements. Both reviews were clean.
During a Vulnox external assessment, a Redis instance running on a publicly accessible IP was found with no authentication enabled. The instance contained session tokens, user preference data, and cached API responses that included customer email addresses and account identifiers. The Redis instance was not in the ISO 27001 asset inventory — it had been provisioned by a developer for a new feature and had not been formally registered. It was not referenced in the GDPR data flow map for the same reason.
Neither GDPR nor ISO 27001 assessment methodology tested for this specifically. The GDPR review confirmed that documented processing activities had appropriate controls. The ISO 27001 audit reviewed the controls that were in scope. An unregistered infrastructure component with no authentication protecting personal data is not found by either framework''s standard assessment approach. It is found by scanning the actual external attack surface — which is a different thing from reviewing the documentation about it.
What each framework actually tests and why the gap is predictable
GDPR is a principles-based regulation. Article 32 requires ''appropriate technical and organisational measures'' to ensure a level of security appropriate to the risk — but it does not define what those measures are. The determination of appropriateness is left to the controller, with reference to ''the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing.'' This flexibility is intentional. It is also the reason GDPR compliance reviews are documentation assessments: auditors confirm that the organization has assessed the risk and has documented controls they believe are appropriate. They do not independently verify that the controls work.
ISO 27001 is a management system standard. It requires that organizations implement controls from Annex A, maintain documentation, conduct internal audits, and demonstrate continual improvement. The certification audit tests whether the management system is operating — whether policies are documented, whether reviews are conducted, whether nonconformities are tracked. It tests implementation intent and process, not technical control effectiveness.
SOC 2 is the framework that comes closest to testing operational effectiveness. A Type II report covers a six- to twelve-month period and tests whether controls were operating effectively throughout that period, not just at the audit date. But SOC 2 scope is defined by the service organization, and the system description — which defines what is in scope — is written by the organization seeking certification. Infrastructure components not included in the system description are not tested.
The pattern that produces the Redis finding above is not a failure of any single framework. It is the predictable consequence of three frameworks that each test a different thing: GDPR tests whether personal data processing is documented and justified, ISO 27001 tests whether a security management system is operating, and SOC 2 tests whether the controls described in the system description were effective. None of them test what is actually running in the environment against what the documentation describes.
Example
In one Vulnox engagement with a healthcare SaaS company dual-certified under ISO 27001 and operating under GDPR, the ISO 27001 asset register contained 47 systems. Technical enumeration of the environment found 61 active systems, including three that were internet-accessible. Of the three externally accessible systems not in the asset register, one was running software with a published RCE vulnerability. The ISO 27001 audit had found no nonconformities. The GDPR compliance review had found no gaps. The asset register was complete and accurate for 47 systems. The 14 systems it did not list were not reviewed by either framework.
The technical controls most reliably missed across GDPR and ISO 27001 assessments in Vulnox engagements: unauthenticated cache and message queue instances (Redis, Memcached, RabbitMQ) on public IPs or accessible from shared network segments; object storage buckets without access policy validation (ACLs confirmed at provisioning, not re-validated); encryption key jurisdiction — where keys are actually held versus where data is stored; and third-party processor environments tested only by self-attestation rather than by independent technical review.
The gap in numbers from actual environments
Unauthenticated cache instances
Across Vulnox external and internal assessments of GDPR-scoped organizations with ISO 27001 certification, unauthenticated Redis or Memcached instances accessible from outside the application''s intended network boundary were found in the majority of engagements involving microservice or containerized architectures. In every case, the instance was absent from the ISO 27001 asset register. In every case, the GDPR data flow map did not include the processing activity using that instance. Both frameworks had been reviewed recently. Neither had found the gap. (Vulnox assessment data, 2024-2025)
Processor agreement technical gap
In Vulnox engagements involving GDPR Article 28 processor agreement review, the majority of DPAs referenced the processor''s ISO 27001 certification as the contractual security baseline. In none of those cases had the controller performed independent technical validation of the processor''s environment. ISO 27001 certification tells you the processor has a management system. It does not tell you whether the processor''s infrastructure is currently configured securely. The DPA was legally sound. The security assurance it provided was certification-based, not evidence-based. (Vulnox assessment data, 2024-2025)
Encryption key jurisdiction
In GDPR Article 44 data residency assessments, organizations storing personal data within the required jurisdiction while managing encryption keys through a key management service operated in a different jurisdiction were found in three of the last five engagements where key management architecture was reviewed. GDPR Article 44''s transfer restriction applies to personal data. Data encrypted with a key held in a jurisdiction subject to FISA 702 or equivalent compelled disclosure authority is accessible to that authority regardless of where the encrypted data is stored. The data residency compliance documentation was accurate. The key residency gap was not documented.
What technical assessment found that framework audits had not
Assessment base: Vulnox GDPR, ISO 27001, and multi-framework gap analysis engagements, 2024-2025, primarily EU and Southeast Asia-based organizations in SaaS, healthcare technology, and financial services.
Asset inventory gaps that produced compliance blind spots in both frameworks simultaneously
ISO 27001 requires an asset inventory. GDPR requires a record of processing activities. Both documents are created and maintained deliberately. Both reflect the systems and processing activities the organization knows about and has registered. Infrastructure provisioned outside the formal registration process — developer-created instances, temporary environments that became permanent, microservices deployed without infrastructure review — appears in neither document. The ISO 27001 audit reviews the asset inventory. The GDPR review reviews the ROPA. A system not in either document receives no scrutiny from either framework. In Vulnox assessments, the gap between registered and actual systems was present in every engagement where we compared enumerated infrastructure against formal asset registers.
Running both GDPR and ISO 27001 does not produce double coverage for unregistered assets. It produces double blind spots. Neither framework''s assessment methodology independently discovers infrastructure the organization has not declared. Technical discovery — actually scanning the network boundary and enumerating running services — is not a component of either audit process.
Encryption key management that satisfied both frameworks'' documentation requirements and failed the underlying security objective
GDPR Article 32 lists encryption as an example of an appropriate technical measure for protecting personal data. ISO 27001 Annex A.10 requires a cryptography policy and key management procedures. Both frameworks review the policy and confirm that encryption is in use. Neither framework''s standard assessment tests where the keys are held, who can access them under what authority, or whether the key management architecture satisfies the data residency and access control objectives that encryption is supposed to achieve. In the FISA 702 scenario described earlier, the encryption was AES-256, the policy was documented, and the ISO 27001 certification was current. The security objective — keeping data inaccessible to foreign government access — was not met by any of those things.
Encryption implementation that satisfies both frameworks'' documentation requirements can fail the underlying security objective the encryption is supposed to achieve. The technical question — where are the keys, under whose legal authority, and what compelled disclosure obligations apply — is not answered by confirming that encryption is enabled and that a key management policy exists.
SOC 2 scope exclusions creating assessment gaps in shared infrastructure
In three Vulnox engagements involving organizations that held GDPR compliance documentation, ISO 27001 certification, and SOC 2 Type II reports, the SOC 2 system description excluded shared infrastructure components — monitoring systems, CI/CD pipelines, developer access environments — that were in scope for GDPR processing and nominally covered by the ISO 27001 management system. The SOC 2 report tested the controls in the declared system and found them effective. The components outside the declared system were not tested. The GDPR-relevant processing that ran through those components was covered by two compliance frameworks and validated by zero technical assessments.
Three compliance frameworks covering the same environment do not produce three times the coverage. They produce the union of their respective scopes, which for most organizations is smaller than the total environment. The gap is not between frameworks — it is between the frameworks'' collective scope and the actual technical footprint.
ISO 27001 certification makes GDPR Article 28 processor risk assessments less rigorous, not more
Common belief
An ISO 27001-certified processor is a lower-risk processor for GDPR Article 28 purposes. Requiring ISO 27001 certification from processors is a reasonable and sufficient security assurance requirement.
What we found
In Vulnox processor security assessments — technical reviews of processor environments conducted as part of GDPR Article 28 due diligence — security gaps were found in the majority of ISO 27001-certified processors reviewed. The gaps were not in the management system. They were in infrastructure components that the certification scope did not fully cover or that had been provisioned since the last audit.
ISO 27001 certification means the processor has a documented security management system and that a certification body confirmed it was operating at the time of the last audit. It does not mean the processor''s current infrastructure configuration is secure. It does not mean the controls in scope for the certification cover all the processing they do for your organization. It does not mean the certification scope includes the specific systems and data flows relevant to your personal data.
The problem is that requiring ISO 27001 certification as a GDPR Article 28 security assurance mechanism produces a paper-based check that closes down further scrutiny. Once a processor provides their certification, the controller''s due diligence process typically treats that as satisfying the security assessment requirement. The processor agreement references the certification. The annual review confirms the certification is current. No one looks at the processor''s actual infrastructure.
A processor can hold current ISO 27001 certification and simultaneously have an unauthenticated database accessible from the public internet if that database was provisioned after the last certification audit, or if it is on a network segment outside the certification scope. The certification does not continuously validate the environment. It validates the management system at a point in time, within a defined scope.
Controllers who use ISO 27001 certification as their primary processor security assurance mechanism are substituting certification status for technical evidence. Those are different things.
What each framework actually tests: a technical breakdown
GDPR (principally Articles 5, 25, 28, 32, 44)
Principles-based. Requires appropriate technical and organisational measures, data protection by design and default, and processor accountability — but defines none of these prescriptively. Assessment is documentation-based: auditors review policies, ROPA entries, DPIAs, and processor agreements. Article 32 compliance is determined by the controller''s own risk assessment, not by independent technical testing. Article 44 data residency compliance is confirmed by data location documentation, not by testing the key management architecture that determines actual data accessibility.
GDPR compliance confirms that the organization has documented its processing, justified its legal bases, and described its security measures. It does not confirm that the security measures work as described. The gap between documented security and operational security is not examined by standard GDPR compliance assessment.
ISO 27001 (Annex A controls, management system requirements)
Management system standard. Certifies that the organization has implemented Annex A controls within the defined scope, maintains the management system, and conducts internal audits. The certification scope is defined by the organization. Controls are assessed for implementation and documentation, not for technical effectiveness against specific threat scenarios. The asset inventory, upon which control coverage depends, is self-reported.
ISO 27001 certification confirms the management system is operating and that documented controls exist within the certification scope. It does not confirm that all assets processing personal data are within scope, that controls are technically effective, or that the environment matches what the asset register describes. Assets provisioned outside the formal registration process receive no coverage.
SOC 2 Type II
Operational effectiveness testing over a defined period. The strongest of the three for testing whether controls actually work — Type II covers 6-12 months and tests operating effectiveness, not just design. The critical constraint is scope: the system description is written by the service organization, and components excluded from the system description are not tested. Sub-service organizations (processors'' processors) are covered by carve-out or inclusive method, and inclusive method coverage requires cooperation from the sub-service organization.
SOC 2 Type II is the most technically meaningful of the three for the components it covers. For components excluded from the system description, it provides no assurance. Organizations using SOC 2 reports for GDPR processor due diligence need to confirm that the system description covers the specific processing relevant to their personal data — which in practice is rarely verified.
What all three frameworks consistently miss
Shadow infrastructure with personal data processing
Developer-provisioned instances, temporary environments, microservices deployed without infrastructure review, third-party integrations added outside the formal vendor management process. These appear in neither the ISO 27001 asset register nor the GDPR ROPA. GDPR compliance reviews and ISO 27001 audits both operate on declared scope. Neither independently discovers undeclared infrastructure. Technical discovery — scanning the actual network boundary — is the only method that finds what the frameworks do not.
Encryption key jurisdiction and compelled disclosure exposure
GDPR Article 44 restricts transfer of personal data to third countries. Encryption is treated as a protective measure. Neither GDPR nor ISO 27001 assessment methodology specifically tests whether encryption keys are held in a jurisdiction subject to compelled disclosure authorities that could provide government access to the underlying data. The FISA 702 scenario — data in the EU, keys in a US KMS — is not addressed by either framework''s standard compliance review.
Real-time access control state versus documented access control policy
Both frameworks review access control policies and configurations. Neither continuously validates whether the current access state matches the documented policy. Overly permissive IAM roles, expired service account credentials that were not revoked, shared credentials for system accounts, and privilege escalation paths in cloud environments are all access control failures that documentation-based reviews do not find. They require testing the actual permissions against the principle of least privilege.
Inter-processor data flows without controller visibility
Article 28 processor agreements address the direct controller-processor relationship. Sub-processor agreements require controller authorization. In practice, processor sub-processor lists change more frequently than controllers review them. Data flows from processor to sub-processor to sub-sub-processor can involve jurisdictions, data types, and processing activities the controller has never reviewed. The DPA chain is documented. The actual data flow topology is not typically validated.
Where framework overlap enforcement is heading
GDPR enforcement decisions will begin citing ISO 27001 certification as insufficient evidence of Article 32 compliance in specific technical areas — specifically key management and network access control — within 24 months, creating precedent that controllers cannot satisfy Article 32 obligations by referencing processor certification status.
The pattern of breaches involving ISO 27001-certified processors has produced enough enforcement history that data protection authorities have the evidence base to distinguish between certification-based assurance and technical security assurance. The Italian DPA and the Irish DPC have both issued guidance distinguishing documented security measures from effective ones. A formal enforcement decision citing ISO 27001 certification as insufficient for Article 32 specific controls is the structural next step. The observable signal is an enforcement decision that explicitly states certification status does not satisfy Article 32 for the control category at issue.
Confidence: highNo GDPR enforcement decision cites ISO 27001 certification as insufficient for Article 32 within 24 months of publication.SOC 2 system description scope requirements will be tightened by the AICPA to require explicit justification for excluded components within 18 months, reducing the frequency with which organizations use narrow system descriptions to avoid testing infrastructure that processes customer data.
The practice of writing narrow SOC 2 system descriptions to reduce audit scope is well-documented in the assurance community. As organizations use SOC 2 reports for GDPR processor due diligence and other compliance purposes, the gap between what the report covers and what the organization actually operates is producing reliance failures. AICPA has been updating SOC 2 guidance incrementally. A requirement to justify scope exclusions rather than simply declare them is a natural continuation of that direction. The observable signal is an AICPA update to the SOC 2 guide requiring documented rationale for excluded infrastructure components.
Confidence: mediumNo AICPA SOC 2 guidance update requires justification for excluded components within 18 months.
What multi-framework compliance actually produces
Running GDPR compliance and ISO 27001 certification simultaneously is better than running one. The combination produces better documentation, more structured risk assessment, and clearer accountability than either framework alone. That is real value, and I am not arguing against it.
What I am arguing is that organizations treat the combination as coverage when it is actually structured documentation. The two frameworks together tell you that you have documented your processing, that you have a security management system, and that both have been reviewed by someone. They do not tell you whether an unauthenticated Redis instance is accessible from the public internet, whether your encryption keys are held in a jurisdiction that can compel access to them, or whether a processor you trust your personal data to has infrastructure that matches their certification.
Those questions require testing the environment, not reviewing the documentation about it. A network scan of the external attack surface, a comparison of the asset register against enumerated infrastructure, a technical review of encryption key architecture, an independent assessment of a processor''s environment rather than a review of their certification — these are the checks that find what frameworks miss. They are not complicated. They are just not part of standard GDPR or ISO 27001 assessment methodology.
The organizations that are actually protected are the ones that run the frameworks for the documentation and governance value they provide, and then separately test the technical controls that the frameworks document but do not validate.
Counterargument
The counterargument is that technical testing of every component in a complex environment is expensive and operationally disruptive, and that the risk-based approach both frameworks endorse is supposed to prioritize testing effort toward the highest-risk areas. An organization cannot test everything continuously. The frameworks provide a risk-based structure for deciding what to test. This is a sound argument. What it requires is that the risk assessment input — the list of what exists in the environment — is accurate. If the asset inventory is incomplete, the risk-based prioritization is applied to a subset of the actual risk. The framework provides good structure. The structure is applied to incomplete data.
One technical check that cuts across both frameworks
Run a scan of your external attack surface and compare the results against your ISO 27001 asset register and your GDPR ROPA simultaneously.
For every service found in the scan that does not appear in both documents: confirm whether it processes personal data. If it does, you have a GDPR ROPA gap and an ISO 27001 asset register gap in the same finding. That is the category of exposure neither framework''s standard assessment methodology reliably finds, and it is the category most consistently present in Vulnox assessments of organizations with clean GDPR and ISO 27001 records.
The scan takes hours. The comparison takes a day. The gap it finds would have taken an attacker less time to discover than either of those.
Further Reading
Gap Analysis
integrated gap analysisDigital Footprint
digital footprint analysisISO 27001 Official Standard
ISO 27001 official standardSOC 2 Framework Complete Guide
SOC 2 framework guideGDPR Compliance Guidelines
GDPR compliance guidelines
Frequently Asked Questions
What does GDPR compliance confirm that ISO 27001 certification does not?
GDPR compliance confirms that personal data processing is documented, lawful basis is established, and processor agreements exist. ISO 27001 certification confirms that a security management system is operating within the defined certification scope. GDPR does not independently validate technical security controls. ISO 27001 does not require that all personal data processing assets are within certification scope. Neither framework confirms that security controls work as documented — they confirm that security measures are described and that a management system exists.
Why is ISO 27001 certification insufficient for GDPR Article 28 processor due diligence?
ISO 27001 certification confirms the processor had a functioning management system at the time of the last audit, within the defined certification scope. It does not confirm the processor's current infrastructure configuration, whether assets provisioned since the last audit are secure, or whether the certification scope covers the specific systems processing your personal data. In Vulnox processor assessments, technical security gaps were found in the majority of ISO 27001-certified processors reviewed. The gaps were in infrastructure components the certification scope did not fully cover.
What technical controls do GDPR and ISO 27001 both miss in combined compliance assessments?
Infrastructure provisioned outside formal asset registration processes appears in neither the ISO 27001 asset register nor the GDPR ROPA — and receives no scrutiny from either framework. Encryption key jurisdiction — where KMS keys are held relative to where personal data is stored, and what compelled disclosure obligations apply — is confirmed by policy documentation in both frameworks but not technically validated. Real-time access control state versus documented access policy is not tested by either framework's standard assessment methodology.
How does SOC 2 Type II add coverage that GDPR and ISO 27001 lack?
SOC 2 Type II tests whether controls were operating effectively over a 6-12 month period, not just whether they are documented. This operational effectiveness testing is stronger than the documentation-based assessments of GDPR and ISO 27001. The critical constraint is scope: components excluded from the SOC 2 system description are not tested. Most SOC 2 system descriptions are written by the organization seeking certification and exclude infrastructure components that process customer data. The coverage SOC 2 provides is meaningful for what it covers and absent for what it excludes.
What is the encryption key jurisdiction problem in GDPR data residency compliance?
GDPR Article 44 restricts transfer of personal data to third countries. Organizations store personal data within the required jurisdiction but manage encryption keys through a key management service operated in a different jurisdiction — often a US-based KMS subject to FISA 702 compelled disclosure. Data encrypted with a key held in a FISA 702-accessible jurisdiction is accessible to US government process regardless of where the encrypted data is stored. Both GDPR and ISO 27001 assess whether encryption is in use and whether a key management policy exists. Neither typically tests where the keys are held.
How do you find the security gaps that GDPR and ISO 27001 assessments miss?
Scan the external attack surface and compare results against the ISO 27001 asset register and GDPR ROPA simultaneously. Any service found in the scan that does not appear in both documents is a combined gap in both frameworks. In Vulnox assessments of organizations with clean GDPR and ISO 27001 records, gaps between enumerated infrastructure and formal asset registers were present in every engagement reviewed. The scan finds what documentation-based frameworks cannot: infrastructure that exists and has not been declared.
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.