MaRisk Compliance: Cybersecurity Requirements for Financial Institutions

Introduction

Your compliance team just received a call from one of your external vendors. They’ve been compromised. Data may have left their systems. Before you can even process what that means, you’re asking yourself the questions that keep you up at night: Did we know about this risk? Did we actually assess it? Was the vendor properly monitored under our MaRisk compliance requirements? And can we prove to BaFin that we had the risk under control?

This isn’t theoretical. In July 2026, Deutsche Bank’s data appeared on a leak site after attackers hit a third-party marketing platform used by sales partners in Germany. The attack wasn’t on Deutsche Bank’s infrastructure, but data related to the bank still left through a vendor connection. A few weeks earlier, V-Bank experienced something similar when an external IT service provider got compromised and customer data walked out the door.

What makes these incidents important isn’t that they happened. It’s that they expose something regulators now focus on constantly: third-party risk. Your data sitting on systems you don’t control. Your vendors holding customer information. The quiet assumption that checking a vendor’s security once a year is enough.

Why Smaller Financial Institutions Are Still at Risk

Many smaller financial institutions tell themselves they’re not interesting to attackers because they’re not big enough. The reality is different. Attackers don’t measure success by the size of your balance sheet. They follow the data and exploit whatever weakness gets them there fastest. A mid-sized bank with poor third-party risk management is just as vulnerable as a large one, sometimes more so because oversight is weaker.

This matters because MaRisk, after its 9th revision in June 2026, now requires you to know your third-party risks, assess them properly, and prove it. When the next vendor call comes (and it will), you need to be able to answer your board and your regulators with evidence, not scrambling.

This blog walks through what MaRisk actually requires on the cybersecurity side after the latest revision, where the compliance gaps typically are, and how to structure your approach so you’re ready when regulators ask.

Key Takeaways

• MaRisk requires knowing your material risks and proving it to regulators, not just having policies written down.
• Third-party and ICT risks belong in your operational risk visibility, tracked like any other material exposure.
• AT 7.2 expects ongoing system testing and suitability checks, not annual documentation exercises.
• MaRisk and DORA run together with no gaps between them, requiring deliberate mapping of your controls.
• Evidence that your controls actually work matters more to regulators than perfect implementation.

Minimum Requirements for Risk Management MaRisk: Complete BaFin Compliance Guide

MaRisk is basically BaFin’s way of telling financial institutions how to manage their risks properly. It comes from section 25a of the German Banking Act, which says banks need to have organized systems for identifying and controlling risks. The full name is Mindestanforderungen an das Risikomanagement, and the latest version came out on 30 June 2026.

The good news is that the new version is simpler than before, going from 122 pages down to about 80 pages. Instead of telling institutions exactly what to do step by step, it now focuses on principles, which means your bank can apply the rules in a way that makes sense for your size and your specific business rather than following one rigid playbook that doesn’t fit everyone. You have until 1 January 2027 to get your approach sorted out, giving you time to update your documentation and make sure everything is in place.

Who needs to follow MaRisk:

• Credit institutions that are not significant institutions under direct ECB supervision
• Certain investment firms and financial services companies that must apply §§ 25a/25b KWG
• CRD third-country branches
• Branches of German institutions abroad

Banks are split into three groups:

• Very small institutions (balance-sheet total of €1 billion or less on a four-year average)
• Small and non-complex institutions (SNCIs)
• Other less-significant institutions

The key thing for smaller banks is that you don’t have to do everything the same way a large bank does, and you get some flexibility based on how big you are and what risks you actually face. That said, flexibility doesn’t mean you can skip things. You need to explain why your approach is appropriate for your bank’s size and risks.

The basic rule stays the same regardless of size. If a risk matters to your bank, it needs to be in your risk management system, and this includes cyber and IT risks. You need to find them, understand them, decide what to do about them, and be ready to show regulators that you actually did this work.

Get CREST-Accredited Penetration Testing Services

Qualysec delivers CREST-accredited VAPT services with real-world attack simulations, validated findings, and actionable remediation reports.

Request a Quote

→

BaFin MaRisk vs DORA: Comparing Two Cybersecurity Compliance Frameworks for Banks

BaFin issues MaRisk and uses it as the main national standard for how financial institutions organize their risk management systems. When supervisors review your bank, they’re checking whether you’ve applied the framework in a way that actually fits your institution’s size, complexity, and the risks you actually face.

How MaRisk and DORA fit together:

DORA has been in force since January 17, 2025, as the European regulation setting detailed rules for ICT risk management and digital operational resilience testing. While MaRisk provides the governance structure and principles, DORA covers most of the technical ICT requirements in detail. They run side by side, with ICT services falling under DORA’s third-party risk articles removed from MaRisk’s outsourcing module to avoid duplication.

Key practical points:

• MaRisk gives you the framework principles for risk management
• DORA gives you the detailed technical requirements
• Both frameworks work together, not against each other
• You need controls mapped to both to avoid gaps
• Nothing should fall between the two regimes

BAIT, the older national IT requirements, no longer applies to institutions that must maintain an ICT risk-management framework under DORA. A residual group of entities still uses BAIT until the end of 2026, after which it will be fully repealed. The practical result is that your bank must map your controls to both MaRisk and DORA so nothing gets missed. Supervisors will check whether you’ve deliberately covered all the requirements in both frameworks rather than accidentally leaving something unaddressed because you assumed the other regulation covered it.

MaRisk Management: How to Implement AT 7.2 Cybersecurity Controls

This is where your bank’s actual cybersecurity work shows up in daily operations. The relevant section is AT 7.2, and it focuses on three main areas that regulators will examine.

What AT 7.2 actually requires:

• Your bank needs to have the right technical and organizational resources to manage the risks you face. A small savings bank doesn’t need the same infrastructure as an investment bank handling complex derivatives trading. What matters is that what you have is appropriate for your size, your business activities, and the risks you identified.
• Your IT systems (the hardware, the software, all of it) plus the processes around those systems need to protect four things: data integrity (information stays accurate), availability (systems stay accessible), authenticity (data comes from who it claims to come from), and confidentiality (sensitive information stays private). When you design these systems, you should follow recognized standards. BaFin specifically points to BSI IT-Grundschutz and the ISO 27000 series as examples of frameworks that work.
• Access rights need to follow the least-privilege principle, meaning people get access only to what they need for their job. Administrator accounts especially need regular review because they’re powerful and attractive to attackers. Your bank also needs to identify IT risks, assess how serious they are, decide what to do about them, and keep monitoring them. The suitability of your systems and processes should be checked regularly on a risk-based schedule by people who understand both the business side and the technology side.

What this looks like in practice:

Why this matters when things go wrong:

These requirements aren’t theoretical exercises. When a provider calls your bank to say data may have left their systems, your supervisors and board will ask three specific questions.

• Did your bank already know this provider was risky?
• Was that risk actually assessed through your formal risk process?
• Were protective measures actually in place and documented?

If you can answer yes to all three because you have records showing you assessed the provider, documented the risks, and verified the controls, you’re in a much stronger position. If you can’t find that documentation, regulators will assume you weren’t managing the risk properly and treat it as a compliance gap.

Risk Intelligence MaRisk: Knowing Your Bank’s Critical Cybersecurity Vulnerabilities

Risk intelligence under MaRisk means knowing your own risks well enough to make decisions about them. It’s the difference between having a policy document and actually being able to answer questions about where your bank’s vulnerabilities are.

Being able to answer without scrambling which of your systems and which of your providers could actually hurt the institution if they fail or get compromised is what risk intelligence looks like. That knowledge needs to live in three places: your risk inventory, the results of your technical checks, and the reports you send to management and the board. If the knowledge only exists in one person’s head, it’s not intelligence. It’s hope.

Both the Deutsche Bank third-party incident in July and the V-Bank case in June happened through external providers. These are exactly the situations your risk inventory and third-party mapping are supposed to identify before the provider calls. Having documentation on a shelf doesn’t help when things go wrong. What matters is your ability to prioritize and act on the material exposures you’ve already identified.

What risk intelligence actually includes:

• Knowing which systems handle sensitive customer data
• Knowing which providers could disrupt your core business if they went down
• Understanding what data sits on third-party systems
• Documenting how you assessed those providers
• Recording what protective measures you implemented
• Having proof that you checked suitability regularly

Let’s picture a mid-sized cooperative bank where the core banking systems are solid and well-maintained. The weak point is a cloud CRM or marketing tool used by relationship managers to track customer interactions. This tool holds customer contact data and transaction history that relationship managers need to do their jobs effectively. Most staff would consider it important but not critical.

One Monday morning, the provider calls your bank. They’ve been hit by attackers. Data may have left their systems. Before you can even get your incident response team together, your board is asking what you knew about this risk and when you knew it.

What regulators expect:

• The provider should already be classified as supporting a material process (not just “some marketing tool”)
• The risk should have been assessed through your formal risk process
• Protective measures and suitability checks should be documented
• The board should have been informed about this provider as a material risk

Under DORA, the reporting clock starts immediately. Your regulatory notifications kick in. But more importantly, the board will ask the same question that BaFin will ask weeks later: did your bank treat this provider as part of your risk management system, or did you assume the vendor was someone else’s problem to worry about?

Banks with good risk intelligence already have the answer documented. Banks without it spend the next month scrambling to build a case.

Implementing MaRisk Management: Step-by-Step Guide to Regulatory Compliance

Getting MaRisk compliance right doesn’t require perfection. It requires knowing where your bank stands and being able to prove it to regulators.

Step 1: Keep Your Risk Inventory Current

Make ICT and third-party risks visible in your operational risk management system, not buried in separate spreadsheets that nobody looks at regularly. Every material system and every material provider should show up in the inventory with a risk classification, assessment results, and current control status. When supervisors ask what risks your bank faces, they should be able to pull this document and see it immediately.

Step 2: Document Access Reviews and System Checks

Record when you reviewed administrator accounts and which systems got tested and when. Keep these on a risk-based rhythm, meaning critical systems might get reviewed quarterly while lower-risk systems get reviewed annually. Smaller institutions can use longer intervals, but you’ll need to explain why the interval matches your risk profile.

Step 3: Run Regular Technical Security Testing

Vulnerability assessments and penetration testing need to happen on the systems that matter most: customer-facing platforms, payment-related systems, data-holding applications, and critical outsourced services. Feed the results back into your risk cycle. This is how you show that the suitability requirements in AT 7.2 are actually operating in practice, not just written down in a policy manual.

Step 4: Map Every Provider Against Both Frameworks

Every material ICT provider needs to map cleanly against both MaRisk outsourcing rules and DORA third-party rules. Nothing should sit in the gap between them. Document which framework applies to which service and what controls you’ve implemented for each.

Step 5: Use Proportionality Thoughtfully

Smaller institutions have proportionality openings under the 9th revision, meaning you don’t need the same level of formality as larger banks. You still need to be able to explain why your approach is adequate for your specific risk profile and institution size. “We’re small” is not an explanation. “We’re small, this is our material risk, here’s why this testing frequency is appropriate for us” is.

MaRisk Management Testing With Qualysec: Professional Assessments for BaFin Compliance

When you need external eyes on your systems, the question isn’t just whether you can find vulnerabilities. It’s whether you can show regulators that your testing actually validates the controls MaRisk and DORA require.

The compliance problem you face:

• Automated scanning gives you a report that doesn’t align with regulatory requirements
• Penetration testing finds everything but doesn’t prove your specific controls work
• You need evidence that suitability checks are real and ongoing, not just checkbox compliance
• Regulators want proof, not promises

How Qualysec’s approach works:

What you get:

• Testing records mapped directly to AT 7.2 requirements
• Evidence of suitability checks on critical systems
• Real-time visibility into what’s being tested and found
• Documentation that shows controls are operating, not theoretical
• Reports structured so supervisors can see the link between testing, risk assessment and control effectiveness

When supervisors ask about your testing:

You can show testing records that align directly with your risk assessment, your control implementation, and your regulatory obligations. You have concrete evidence that your material systems were actually tested, vulnerabilities were found and fixed, findings were remediated and fed back into your risk cycle, and your controls hold up under scrutiny.

Conclusion

The incidents in July and June 2026 didn’t invent third-party cyber risk. They simply made the cost of ignoring it visible in a way that boards and regulators can’t dismiss anymore. When that vendor call comes to your institution, saying data may have left their systems, you’ll wish you had spent the time now to know your risks and document your controls.

MaRisk doesn’t ask your bank to be invulnerable or to catch every possible attack. It asks you to know your material risks, treat them with appropriate controls, and be able to demonstrate that you did this work when regulators ask. That ability to show your thinking and your evidence remains the clearest path through both BaFin scrutiny and the inevitable next supplier crisis.

The institutions handling this well are the ones that treated MaRisk compliance as part of their normal risk management cycle, not as a separate compliance project. They keep their risk inventory current. Qualysec run testing on a schedule. They document decisions and results. When something goes wrong, they can answer supervisors’ questions with evidence rather than scrambling to build a case.

That’s the difference between compliance that looks good on paper and compliance that actually protects your institution.

Prepare for Your Next Cybersecurity Audit with Qualysec

Choose a partner that helps you identify and fix real security risks before attackers do. We are here to help.

Talk to an Expert→

Frequently Asked Questions

1. What is MaRisk, and why is it important?

MaRisk is BaFin’s framework for managing material risks. It requires institutions to identify, assess, and control risks, including ICT and cyber threats. The 9th revision from June 2026 simplified requirements while keeping it the core standard for most less-significant German financial institutions.

2. Which banks does MaRisk apply to?

Credit institutions that are not significant institutions under direct ECB supervision, certain investment firms and financial services companies that must apply §§ 25a/25b KWG, and CRD third-country branches.

3. What are the key cybersecurity requirements under MaRisk?

AT 7.2 requires IT systems to protect data integrity, availability, authenticity, and confidentiality using recognized standards. Access rights follow least privilege with regular reviews. IT risks must be identified, assessed, treated, and monitored continuously.

4. How can financial institutions achieve MaRisk compliance?

Maintain current risk inventory including third-party risks. Document access controls and system suitability reviews on a risk-based schedule. Run regular technical testing. Map all providers against both MaRisk and DORA requirements. Keep evidence ready for supervisory review.

5. What are the consequences of non-compliance with MaRisk?

BaFin can issue findings, require remedial action, increase supervisory intensity, or take formal measures under the KWG. Serious or persistent gaps can lead to capital add-ons in the SREP process and additional regulatory requirements.

6. How do vulnerability assessments and penetration testing support MaRisk compliance?

Testing provides concrete evidence that AT 7.2 suitability checks and risk treatment are operating in practice. It surfaces real weaknesses in systems and third-party connections that documentation alone cannot prove are under control.