Web development in the BaFin environment: what regulated companies actually demand.

Why "BaFin-compliant web development" officially does not exist

BaFin does not certify websites. What is regulated is the company - the bank, the crypto custodian, the leasing firm. But: as soon as your website becomes part of business processes (applications, customer data, document upload), it falls under that company's IT risk management. And that is strictly framed: MaRisk and BAIT set the baseline, and since January 2025 DORA applies on top - the EU regulation on digital operational resilience in the financial sector, which explicitly puts ICT third-party providers on the hook.

Translated: when a regulated company hires an agency, it does not just review the design portfolio. It reviews whether the provider can carry security and operations requirements that would otherwise apply internally. Those requirements are plannable - if you know them.

What regulated clients actually demand - 7 building blocks from practice

1. Traceability: the audit trail

Who changed which content, and when? For the Finoa platform we extended the CMS with a tamper-evident audit log: every change - create, edit, publish, delete - is recorded with timestamp, user and a full before/after comparison as a line-level diff. When compliance asks, the answer is one click, not an archaeology project.

2. Access control: 2FA is table stakes

CMS accounts are an attack vector. For Finoa we extended the CMS login with custom two-factor authentication - per user, no exceptions. At König Leasing, every administrative surface is additionally shielded at the network level - only what must be public is public.

3. Controlled releases instead of "just push it live"

Both platforms separate preview and production strictly: content is approved on an access-protected preview, and only a deliberate release step copies the approved state to production. Nothing goes live that nobody signed off - enforced technically, not as a process paper.

4. Encryption everywhere

Transport encryption without exception, encrypted databases and file systems, encrypted backups - at Finoa even traffic between internal services is encrypted. It sounds obvious - it still gets audited, item by item.

5. Availability and disaster scenarios

The Finoa infrastructure is built for failure: if one site goes down, a second takes over automatically. Add regular backups with defined retention, deletion protection on critical resources and the entire infrastructure as code - in an emergency the environment is reproducible, not reconstructable.

6. Least privilege down to the infrastructure

Every service gets exactly the permissions it needs - at Finoa permissions are strictly separated per service, and changes to them are specially protected. Internal systems never face the internet directly; access runs through defined, logged paths.

7. Sensitive data: as little as possible, as briefly as possible

The König Leasing application flow accepts ID and income documents - through a multi-layered, abuse-protected interface that hands the files straight into the company's CRM, where permissions and deletion policies are already governed. The website itself never becomes a document archive.

"The difference from a normal web project is not the technology - it is the burden of proof. Everything you should be doing anyway, here you must be able to demonstrate."

DUNA Engineering

Privacy: consent is a board-level topic in finance

Granular cookie consent (accept, reject, per category), scripts that only load after consent, revocation at any time - we built all of that for Finoa from scratch, without a third-party banner. Add clean statutory pages and per-page indexing control. In the financial sector these details are reviewed not just by the DPO, but by supervision.

And ISO 27001?

The standard financial companies most often ask their providers about is ISO/IEC 27001 - the management system for information security. An agency does not necessarily need the certificate; it must be able to show its processes withstand the controls: access management, change logs, encryption, contingency plans. The seven building blocks above are exactly that - lived 27001 controls inside a web project.

Checklist: questions for your agency

• How are CMS accounts secured - is there 2FA and role-based access?
• Is every content and system change logged? With a diff?
• What does the release process look like - is there an enforced preview approval?
• What happens when infrastructure fails - is there a tested failover?
• Does the infrastructure exist as code? Who may change it?
• Where do personal documents from forms end up - and deliberately not?
• Is the provider prepared to enter your DORA outsourcing agreements?

Frequently asked questions

Does BaFin audit our website?

Not the website as such - the company and its IT risk management are audited. If the website is part of regulated processes, its security, operations and providers flow into exactly that audit.

Does DORA apply to our web agency?

If the agency provides ICT services to a financial company (development, hosting, operations), it becomes part of DORA third-party risk management - with contractual duties on security, incident reporting and exit scenarios.

Do we strictly need AWS or a multi-region architecture?

No. What is required is appropriate availability and a credible contingency concept - the architecture follows the protection needs. For Finoa multi-region was appropriate; for other setups a solid backup-and-restart concept is enough.

How much longer does such a project take compared to a normal website?

The extra effort sits in alignment and evidence, less in code: realistically 15 to 30% on top - if the building blocks (audit log, 2FA, release process) are not being built for the first time.