Does CloudArq make us GDPR compliant?

No — no tool can. GDPR compliance is a whole-of-organisation obligation covering lawful basis, data-subject rights, processor contracts, breach notification, DPIAs and more, most of which are people-and-process, not configuration. CloudArq is a read-only posture scanner: it shows where your live AWS configuration meets or misses the TECHNICAL security-of-processing measures under Art. 25 and Art. 32, and gives the exact remediation step for each gap. It evidences part of Art. 32; it does not certify you, and CloudArq the business holds no certification of its own.

Which GDPR articles can a scanner actually check?

Only the technically-observable ones: Art. 25 (data protection by design and by default) and Art. 32 (security of processing) — encryption at rest and in transit, restricting public access, confidentiality and integrity of systems, the ability to restore availability, and the logging that lets you test those measures. The organisational articles — lawful basis (Art. 5/6), data-subject rights (Art. 13-15, 17), processor agreements (Art. 28), breach notification (Art. 33-34), DPIAs (Art. 35) and the DPO role (Art. 37-39) — are not configuration and map zero checks. This page is honest about that boundary.

Does hosting on AWS in an EU region make my processing GDPR compliant?

No. AWS operates the platform under the shared-responsibility model and offers an EU Data Processing Addendum plus EU regions, but choosing eu-central-1 or eu-north-1 does not by itself satisfy Art. 25 or Art. 32. Whether your data is encrypted, whether a bucket is public, whether an RDS instance is reachable from the internet, and whether your AI workloads move personal data across regions are all your configuration — the "security in the cloud" half of the model. That in-cloud half is exactly what CloudArq inspects.

Where is CloudArq hosted, and does it store our personal data?

CloudArq is EU-hosted (Helsinki) and connects to your account through a read-only IAM role with an ExternalId. It reads configuration metadata only — it never stores your credentials, application data, database contents, or S3 objects, so running the scan does not itself create a new copy of your personal data to worry about. Data at rest in CloudArq is encrypted with AES-256-GCM.

How does CloudArq handle data residency for AI workloads?

The `ai_cross_region_residency` check inspects AI workload configuration (control-plane metadata only, never the data itself) for setups that move personal data across regions in a way that can break an EU-residency commitment under Art. 25(1). It is one of the AI Workload lens checks and, like every CloudArq check, it is read-only and reports the exact configuration to correct — it never touches or moves the data.

What are the most common Art. 25/32 technical gaps on AWS?

Public S3 buckets or publicly reachable RDS instances holding personal data (Art. 25(2)), unencrypted EBS volumes or S3 buckets with no server-side encryption (Art. 25(1)), CloudFront allowing plaintext HTTP (Art. 32(1)(a)), a root account without MFA and wildcard IAM policies (Art. 32(1)(b)), and CloudTrail disabled in a region so you cannot even test your measures (Art. 32(1)(d)). Each is a single misconfiguration CloudArq flags with a copy-paste fix.

frameworkgdpr

scopeaws

articles25 / 32

compliance guide · aws · gdpr

GDPR on AWS: the technical measures under Art. 25 & 32

A control-by-control map from the technically assessable GDPR obligations — data protection by design and by default (Art. 25) and security of processing (Art. 32) — to the AWS configuration facts that evidence each one. Every row names the article and the read-only CloudArq check behind it. This page shows posture on the technical measures only; it does not make you compliant, and the organisational duties are deliberately out of scope.

Updated 2026-07-20 · ~11 minute read

checks mapped to Art. 25/32

technical controls below

control groups below

agents installed

See CloudArq map these View pricing

audience

Who this is for

Teams processing EU personal data on AWS — controllers and processors alike — who need to show that the technical measures behind Art. 25 and Art. 32 are actually in place. If you own privacy or security, use the control groups below to see which measures your AWS account can already evidence and where the gaps are. If your DPO or counsel has handed you an Art. 32 requirement and asked “is this true of our infrastructure?”, read it as a translation layer: each article reference maps to a concrete AWS setting you can check today. It is not a substitute for legal advice or a full compliance programme.

definition

What a scanner can — and can't — tell you about GDPR

GDPR (Regulation (EU) 2016/679) is a broad regulation. Most of it — lawful basis, transparency, data-subject rights, records of processing, processor agreements, breach notification, DPIAs, the DPO role — is about people, contracts and process, and no scanner can evidence it. Two articles, however, describe measures that live in your infrastructure configuration: Article 25 (data protection by design and by default) and Article 32 (security of processing — encryption, confidentiality, integrity, availability and regular testing). Those are the parts CloudArq maps. Everything else on this page is honest about staying in its lane: the product shows technical posture, it does not certify you and it does not touch the organisational obligations.

shared responsibility

An EU region is not the same as GDPR compliance

AWS operates the platform under the shared-responsibility model and offers an EU Data Processing Addendum and EU regions — that is “security of the cloud.” But choosing an EU region does not, by itself, satisfy Art. 25 or Art. 32. Whether personal data is encrypted at rest and in transit, whether a bucket or database is public, whether an inference endpoint is exposed, whether you can restore data after an incident, and whether an AI workload moves data across regions are all your configuration — “security in the cloud.” That in-cloud half is exactly where CloudArq operates: it reads your account's configuration metadata (never your data) and tells you which of those technical measures currently hold.

art. 25 / 32 · technical measures

The technical measures, mapped to AWS checks

Each row below is one real, technically-assessable Art. 25 or Art. 32 measure and the CloudArq check IDs that evidence it. In total, 65 distinct checks map to these security-of-processing measures; the 7 highlighted here are the ones most teams are asked about first.

Data protection by design & by default (Art. 25)

Personal data protected at rest, and access restricted unless a bucket or database is deliberately public.

3 controls

Art 25(1)Protection by design — encryption at rest. CloudArq checks for unencrypted EBS volumes (`unencrypted_ebs`), S3 buckets without server-side encryption (`s3_no_sse`), and agent token vaults not backed by a customer-managed key (`token_vault_no_cmk`).
Art 25(2)Protection by default — data-minimising access. Checks for public S3 buckets (`public_s3`), publicly reachable RDS instances (`rds_public_access`), and self-hosted inference endpoints exposed to the internet (`exposed_self_hosted_inference_endpoint`) — the paths that expose personal data by default rather than only where intended.
Art 25(1) · AIProtection by design for AI processing — data residency. Checks whether AI workloads move personal data across regions in a way that can break an EU-residency commitment (`ai_cross_region_residency`).

Encryption in transit (Art. 32(1)(a))

Personal data protected as it crosses the network, using strong transport security.

1 controls

Art 32(1)(a)Encryption of personal data in transit. Checks for CloudFront distributions that allow plaintext HTTP (`cloudfront_no_https`) and S3 buckets that do not enforce TLS on every request (`s3_no_ssl_enforcement`).

Confidentiality & integrity of processing (Art. 32(1)(b))

The ongoing confidentiality and integrity of the systems that process personal data.

1 controls

Art 32(1)(b)Ongoing confidentiality and integrity of systems. Checks for a root account without MFA (`no_mfa_root`), wildcard IAM policies that grant far more than a workload needs (`iam_policy_wildcard`), and Lambda functions attached to an admin role (`lambda_admin_role`).

Availability, restore & regular testing (Art. 32(1)(c) & (d))

The ability to restore access to personal data after an incident, and a way to verify the measures keep working.

2 controls

Art 32(1)(c)Ability to restore availability and access in a timely manner. Checks for RDS instances without automated backups (`no_backups_rds`) and DynamoDB tables without point-in-time recovery (`dynamodb_no_pitr`).
Art 32(1)(d)A process for regularly testing and evaluating the measures — which starts with the telemetry to detect a problem. Checks that threat detection is on (`guardduty_disabled`) and that an audit trail exists in every region (`no_cloudtrail`).

scope · what this does & doesn't do

What CloudArq does

Maps 65 read-only checks to the technical security-of-processing measures in Art. 25 and Art. 32.
Shows, per measure, which live AWS settings currently pass or fail.
Ships an exact remediation step (CLI / IaC) and an evidence pointer for each gap.
Runs from a read-only IAM role with an ExternalId, EU-hosted (Helsinki), AES-256-GCM at rest — never stores your credentials, app data, database contents, or S3 objects.

What it does not do

It does not make you “GDPR compliant” and there is no GDPR certificate to issue — a scanner shows posture, not compliance.
It does not address the organisational duties: lawful basis (Art. 5/6), data-subject rights (Art. 13–15, 17), processor agreements (Art. 28), breach notification (Art. 33–34), DPIAs (Art. 35) or the DPO role (Art. 37–39). Those are people and process, not configuration.
It detects and gives you the fix — it never auto-fixes and never changes your account.
CloudArq the business holds no certification of its own; the product maps checks to controls, it does not confer compliance, and this is not legal advice.

product · output

How CloudArq groups the gaps by article

compliance-gaps · framework · gdprillustrative example

Critical2High2Medium1

Art 25(2)

Public S3 bucket (list + read)

arn:aws:s3:::example-user-uploads

fix →

Art 25(2)

RDS instance publicly accessible

db-example-orders · eu-north-1

fix →

Art 25(1)

EBS volume unencrypted at rest

vol-0example · eu-north-1

fix →

Art 32(1)(a)

CloudFront allows plaintext HTTP

dist-example · global

fix →

Art 32(1)(d)

CloudTrail disabled in a region

eu-west-1

fix →

Each failing measure ships with a copy-paste CLI / Terraform fix and its evidence pointer for your DPO or auditor.

faq

Frequently asked

01Does CloudArq make us GDPR compliant?: No — no tool can. GDPR compliance is a whole-of-organisation obligation covering lawful basis, data-subject rights, processor contracts, breach notification, DPIAs and more, most of which are people-and-process, not configuration. CloudArq is a read-only posture scanner: it shows where your live AWS configuration meets or misses the TECHNICAL security-of-processing measures under Art. 25 and Art. 32, and gives the exact remediation step for each gap. It evidences part of Art. 32; it does not certify you, and CloudArq the business holds no certification of its own.
02Which GDPR articles can a scanner actually check?: Only the technically-observable ones: Art. 25 (data protection by design and by default) and Art. 32 (security of processing) — encryption at rest and in transit, restricting public access, confidentiality and integrity of systems, the ability to restore availability, and the logging that lets you test those measures. The organisational articles — lawful basis (Art. 5/6), data-subject rights (Art. 13-15, 17), processor agreements (Art. 28), breach notification (Art. 33-34), DPIAs (Art. 35) and the DPO role (Art. 37-39) — are not configuration and map zero checks. This page is honest about that boundary.
03Does hosting on AWS in an EU region make my processing GDPR compliant?: No. AWS operates the platform under the shared-responsibility model and offers an EU Data Processing Addendum plus EU regions, but choosing eu-central-1 or eu-north-1 does not by itself satisfy Art. 25 or Art. 32. Whether your data is encrypted, whether a bucket is public, whether an RDS instance is reachable from the internet, and whether your AI workloads move personal data across regions are all your configuration — the "security in the cloud" half of the model. That in-cloud half is exactly what CloudArq inspects.
04Where is CloudArq hosted, and does it store our personal data?: CloudArq is EU-hosted (Helsinki) and connects to your account through a read-only IAM role with an ExternalId. It reads configuration metadata only — it never stores your credentials, application data, database contents, or S3 objects, so running the scan does not itself create a new copy of your personal data to worry about. Data at rest in CloudArq is encrypted with AES-256-GCM.
05How does CloudArq handle data residency for AI workloads?: The `ai_cross_region_residency` check inspects AI workload configuration (control-plane metadata only, never the data itself) for setups that move personal data across regions in a way that can break an EU-residency commitment under Art. 25(1). It is one of the AI Workload lens checks and, like every CloudArq check, it is read-only and reports the exact configuration to correct — it never touches or moves the data.
06What are the most common Art. 25/32 technical gaps on AWS?: Public S3 buckets or publicly reachable RDS instances holding personal data (Art. 25(2)), unencrypted EBS volumes or S3 buckets with no server-side encryption (Art. 25(1)), CloudFront allowing plaintext HTTP (Art. 32(1)(a)), a root account without MFA and wildcard IAM policies (Art. 32(1)(b)), and CloudTrail disabled in a region so you cannot even test your measures (Art. 32(1)(d)). Each is a single misconfiguration CloudArq flags with a copy-paste fix.

Where CloudArq helps

CloudArq maps 65 read-only checks to the technical Art. 25 and Art. 32 measures on this page. The compliance-gaps view groups every failing measure by its article reference, and each finding ships with a CLI command or Terraform block you can apply today — so your Art. 32 evidence-gathering becomes a diff instead of a screenshot hunt. It covers the technical measures; your DPO still owns the organisational duties.

Preparing for more than one framework? Most of this technical evidence is reusable. See the ISO 27001 on AWS mapping and the SOC 2 on AWS checklist, which draw on the same underlying checks.

See the demo View pricing