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

Regulated companies must be able to reconstruct changes to content and systems. We therefore design versioning, approvals and auditable change histories from the outset. Which events are recorded, and how, depends on each client's protection needs and governance.

2. Access control: 2FA is table stakes

Administrative access requires strong authentication, role-based permissions and safeguards proportionate to the risk. The exact controls are agreed with the client and reviewed regularly.

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

Content and technical changes pass through defined review and approval steps before publication. What matters is a demonstrable separation between creation, review and approval, not a particular tool.

4. Encryption everywhere

Data must be protected appropriately in transit and at rest. The required controls follow from the data classification, threat model and regulatory obligations, and must be documented in an auditable way.

5. Availability and disaster scenarios

Availability requires a tested contingency and recovery plan. Targets, redundancy and retention are set according to protection needs; what matters is that recovery is demonstrated regularly, not merely described.

6. Least privilege down to the infrastructure

Access and permissions follow least privilege. People and services receive only what they need for their task; administrative paths are restricted and controlled in a traceable way.

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

Sensitive documents belong in the designated, controlled business process and should not remain unnecessarily in the presentation layer. We plan data minimisation, permissions and deletion together with the client.

Privacy: consent is a board-level topic in finance

Granular consent, optional scripts that activate only after approval, and revocation at any time are baseline requirements. Whether a bespoke or established solution is appropriate depends on the legal context, system landscape and operating model. What matters is verifiable behaviour and complete documentation.

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 plan. Whether that needs redundancy across locations or a tested backup and recovery approach depends on the protection needs of the specific system.

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

There is no responsible one-size-fits-all percentage. The effort depends mainly on protection needs, evidence requirements, existing processes and integrations. Clarifying these early avoids costly rework and allows a defensible estimate during scoping.