Cloud Security Hardening for a Digital Bank: What DORA's Secure Configuration Baseline Requires

The short answer

Article 11(2)(b) of Commission Delegated Regulation (EU) 2024/1774, DORA's regulatory technical standard (RTS) on ICT risk management, turns cloud security hardening for a digital bank into a naming and verification task: identify a secure configuration baseline for every AWS account, Azure subscription and GCP project, apply it, and verify regularly that the deployed state still matches it. The clause names no benchmark and no cadence. The bank picks one versioned control-plane benchmark, records the version, and keeps the scorecards that show the state held.

Who this is for

This is for the Head of Infrastructure, CISO or DORA programme owner at an EU digital bank, a credit institution in DORA scope, who has done the Article 8(1) ICT asset classification and must now answer, per account, subscription and project: which baseline do we name, and what proves it is deployed and verified regularly.

Card-data scoping and the DORA/PCI split are in hardening a fintech payment platform. DORA's network-severability requirement is in when segmented is not severable. The host layer and the CIS profile per host role are in server hardening services: scan, script, or engagement. Here, cloud security hardening means the control plane only.

What the RTS actually says

Commission Delegated Regulation (EU) 2024/1774 places a data and system security procedure inside the ICT security policies that Article 9(2) of DORA already requires; that is Article 11(1). Article 11(2)(b) is the baseline clause. It requires the procedure to identify a secure configuration baseline for ICT assets, chosen so that it minimises those assets' exposure to cyber threats, together with measures that verify regularly that the baselines in use are the ones effectively deployed. The clause adds that the baseline should take into account leading practices and appropriate techniques referred to in standards, in the sense of Regulation (EU) No 1025/2012, which is the hook for naming a published benchmark rather than writing your own. Absent from the text: any named benchmark, and any number attached to regularly.

What the baseline must contain

Read as engineering, the clause has three parts: a declared state, a live state that matches it, and a comparison that runs more than once with its output kept. The clause asks for both halves, a named baseline and a measure that shows it is deployed; a benchmark PDF in a policy folder is only the first. Because the RTS names no benchmark and no tool, the entity records which benchmark and version it holds each asset class to, and keeps the output of every verification run as the evidence that the state held.

Where the baseline lives: the cloud control plane

The cloud control plane is the set of provider APIs that decide who can do what in an account before any workload runs: IAM and its roles; audit logging and its retention; network defaults (AWS security groups, Azure network security groups, GCP VPC firewall rules); storage exposure, including public-access settings on buckets; key management; and the defaults a managed database or queue inherits when created. All of these are reachable through misconfiguration alone: an over-broad role, a logging trail switched off, a bucket with public read. None needs an exploit; the provider is doing what it was told.

The operating system and the application above it are separate baselines with their own benchmarks and owners. In security hardening terms they are different engagements, and a hardening engagement keeps them separate; the five-category order is in cloud hardening for an online casino: what comes first.

The word regularly in Article 11(2)(b) exists because a baseline is a state and states move: a new account built from a template that predates the baseline, a security group opened in an emergency change and never reverted, an administrator role granted for a migration that stays. That movement is configuration drift, and none of it shows up until the comparison runs again, which is why the verification half of the clause is not optional paperwork.

Which baseline to name, per cloud

The naming question has a published answer per provider; the version column and the right-hand column are what the baseline document also has to carry.

Cloud	Baseline to name	Version and source (verified 2026-10-08)	Where the deployed state can be checked	What the check does not prove
AWS	CIS AWS Foundations Benchmark	v5.0.0 — announced for AWS Security Hub CSPM (cloud security posture management) on 16 October 2025, with 40 controls that perform automated checks (AWS What's New; AWS Security Hub documentation)	The Security Hub CSPM standard for v5.0.0, a CIS-CAT run, or a policy-as-code evaluation	Workload and OS state; whether a permission should exist at all; anything outside the 40 controls
Azure	CIS Microsoft Azure Foundations Benchmark	v6.0.0 — published 19 April 2026 (NIST National Checklist Program); per the CIS May 2026 benchmarks update, this release migrated the Entra ID recommendations to the CIS Microsoft 365 Foundations Benchmark	Defender for Cloud regulatory-compliance standards where they map to this version (confirm the mapping in your tenant), a CIS-CAT run, or a policy-as-code evaluation	Entra ID: identity now needs its own named baseline
GCP	CIS Google Cloud Platform Foundation Benchmark	v5.0.0 — published May 2026 (NIST National Checklist Program; CIS benchmark page)	Security Command Center where it maps to this version (confirm), a CIS-CAT run, or a policy-as-code evaluation	Organisation policy and workload identity, handled separately

Each Foundations benchmark ships with two profiles, which the CIS Benchmarks FAQ describes as Level 1, the base recommendation that can be implemented fairly promptly without an extensive performance impact, and Level 2, a "defense in depth" profile for environments where security is paramount that CIS warns can have an adverse effect if implemented without due care. The baseline document has to say which profile each account is held to, because a scorecard against the wrong profile proves nothing. Which profile a host gets is a server-side question, covered in the server hardening services post linked above.

What "verify regularly" means in practice

The RTS attaches no number to regularly in Article 11. The weekly figure people quote is Article 10's vulnerability-scanning cadence, a separate obligation; see how often a digital bank should run a vulnerability assessment. For cloud security hardening, verification means re-evaluating each account's deployed state against the named benchmark version, recording the result as verification evidence, and re-checking after any change that could have moved the state. A dated scorecard with a version and an exception list is what an assessor can read.

Do these first:

Name the benchmark and version per account, subscription or project in the baseline document.
Express the baseline as policy-as-code, or an equivalent re-runnable check, so the same state applies to a new account on creation.
Run the first scorecard and record the exceptions.
Re-check after every change window and on a documented cadence.
Keep an exceptions register with an owner, a reason and an expiry.
Store scorecards, drift re-checks and the register with the DORA evidence set.

What counts as verification evidence

The first entry in the evidence set is a dated scorecard tied to a benchmark version, followed by an exceptions register that lists each accepted finding with its owner, reason and expiry, and then the output of every later re-check. The thing that keeps the bank's evidence set alive is the baseline expressed as code: the same policy-as-code that produced the first scorecard is what new accounts are built from and what the next check for configuration drift runs against, so the evidence is a series rather than a one-off report.

If an external Security Hardening engagement produces that first scorecard, what matters for Article 11 is what it hands back: the baseline in a re-runnable form, the scorecard with its version, and the exceptions recorded rather than silently accepted. For cloud security hardening, the handover of the code is the deliverable that keeps working after the engagement ends.

What this does not replace

Three obligations sit beside this one and are not met by a control-plane hardening engagement. Article 10 scanning and patching find and fix known vulnerabilities; a hardened account can still run an unpatched service, which is a Vulnerability Assessment question. DORA's network-severability requirement is a different clause with its own test, covered in the segmented-versus-severable post linked above; a control-plane scorecard says nothing about it. Penetration testing of the workloads is a third thing: a baseline limits exposure, a test shows what an attacker can do with what remains.

Limitations

This is not legal advice; how a named baseline reads to your competent authority is between your entity and its examiner. Benchmark versions and provider control counts change; re-check them when you write your baseline document. This post states no verification cadence, because the RTS states none. The AWS figure is Security Hub's own statement of its automated checks, not the whole benchmark. Defender for Cloud and Security Command Center mappings to a given version must be confirmed in your tenant before either is cited as the verification measure.

What to do next

If you have the Article 8(1) classification but no named baseline version against each account, the gap is a document and a first scorecard. To start a cloud security hardening review, request a baseline review and tell us which cloud providers you use, how many accounts, subscriptions or projects are in scope, and whether a DORA Article 8(1) classification exists.

Frequently asked questions

Does DORA require CIS Benchmarks for cloud accounts? No. Article 11(2)(b) of Commission Delegated Regulation (EU) 2024/1774 requires a secure configuration baseline that minimises exposure to cyber threats and regular verification that it is deployed, but it names no benchmark. The CIS Foundations benchmarks are the usual choice for the cloud control plane because they are published, versioned and have provider-side checks, which is what makes the verification evidence readable.

What does DORA require for a secure configuration baseline? Article 11(2)(b) of Commission Delegated Regulation (EU) 2024/1774 requires financial entities to identify a secure configuration baseline for ICT assets that minimises their exposure to cyber threats, together with measures to verify regularly that the baselines in use are the ones effectively deployed. The clause adds that the baseline should take into account leading practices and techniques referred to in standards. It names no benchmark; the entity has to name one and keep the verification evidence.

Which CIS Benchmark applies to cloud security hardening on AWS, Azure, or GCP? The provider Foundations benchmarks: CIS AWS Foundations Benchmark v5.0.0, CIS Microsoft Azure Foundations Benchmark v6.0.0 and CIS Google Cloud Platform Foundation Benchmark v5.0.0 at the time of writing. Name the version in the baseline document, because the recommendations change between versions.

How often does a digital bank have to verify its cloud security baseline under DORA? The RTS says regularly for Article 11 and attaches no number to it; the weekly figure people quote belongs to Article 10's automated vulnerability scanning, a separate obligation. A common practice is a documented cadence plus a re-check after every change window, with the results stored as evidence.

Is cloud security hardening the same as patching or vulnerability scanning? No. Scanning finds known vulnerabilities and patching fixes them, which Article 10 addresses. Hardening sets and keeps a configuration state that minimises exposure whether or not a vulnerability exists, which Article 11(2)(b) addresses. An account can be fully patched and still expose a storage bucket or an over-broad IAM role.

Sources and review

Article 11 of the RTS is cited to the Official Journal text on EUR-Lex, cross-checked against the article reproductions at Advisera and Better Regulation; the clause is paraphrased, not quoted, apart from the term secure configuration baseline. The Level 1 and Level 2 profile wording is from the CIS Benchmarks FAQ; the original profile definition is in the CIS post Making Security Happen. The AWS version, support date and control count are from the AWS What's New announcement and the AWS Security Hub documentation for the CIS standard. The Azure and GCP versions and dates are from the NIST National Checklist Program entries for the Azure and GCP benchmarks, the CIS May 2026 benchmarks update and the CIS Google Cloud Platform benchmark page. The description of what an engagement hands back follows the published Security Hardening service page. No AnySec-original numbers, case results or SLA figures are used. Author: AnySec Engineering. Published 2026-10-08; last reviewed 2026-10-08.