top of page

C2SEC

Prepare for DORA Part 6 – Compliance & Security Best Practices for Cloud & SaaS Service Providers

  • Writer: Chenyun Chu
    Chenyun Chu
  • Mar 27
  • 7 min read

As cloud and SaaS adoption continues to accelerate, they have become critical dependencies in the ICT supply chain of financial institutions. From core banking systems hosted on hyperscale cloud providers to specialized SaaS applications for customer engagement, risk management, and AI-driven analytics, these technologies now power nearly every aspect of modern financial operations.


DORA extends ICT risk governance to cloud and SaaS providers

However, while cloud and SaaS solutions offer scalability, cost-efficiency, and operational agility, they also introduce unique security, compliance, and resilience challenges:

  • Cloud and SaaS services redefine third-party risk – Unlike traditional outsourcing, where financial institutions retain more direct control, cloud and SaaS models rely on a shared responsibility model, where both the service provider and the financial institution have roles to play in securing systems, managing incidents, and ensuring compliance.

  • The complexity of modern cloud and SaaS architectures makes risk governance more challenging – Financial institutions must continuously assess security controls, enforce contractual compliance, and monitor evolving risks across multiple cloud providers, API integrations, and SaaS applications.

  • Cloud service failures or misconfigurations can lead to significant regulatory and operational consequences – Without proper oversight, security controls, and resilience strategies, financial institutions may be exposed to third-party disruptions, data breaches, and regulatory non-compliance under DORA.


DORA extends ICT risk governance to cloud and SaaS providers (DORA Articles 8, 28, and 30), requiring financial institutions to: 

  • Assess cloud and SaaS providers as critical ICT third parties (DORA Article 28) 

  • Ensure contracts with ICT providers meet strict security & compliance requirements (DORA Article 30) 

  • Implement continuous security monitoring & resilience testing (DORA Article 8) 

  • Maintain control over data processing, access, and service continuity (DORA Article 30(2))


Given the increasing reliance on cloud and SaaS and the unique regulatory challenges they pose, we’ve dedicated this special installment of our DORA series to:

  • Discovering and identifying and cloud and SaaS providers as critical ICT third parties under DORA.

  • Defining the shared responsibility model for security and resilience between financial institutions and cloud/SaaS providers.

  • Enforcing security and compliance in cloud and SaaS contracts to meet DORA Article 30(2).

  • Implementing continuous cloud and SaaS security monitoring using modern automation tools


1. Discovering and Identifying Cloud & SaaS Providers as Critical ICT Third Parties (DORA Article 28)


One of the biggest challenges in cloud security and compliance is understanding all your cloud and SaaS dependencies.


Why is this difficult?

Unlike traditional IT procurement, where vendors go through extensive security and compliance reviews, cloud services and SaaS tools often enter an organization without formal approval, leading to shadow IT and shadow SaaS risks.

  • Easy sign-ups: Many cloud and SaaS services allow instant self-registration with just an email—bypassing IT approval.

  • No waiting period: Employees can access cloud tools immediately, leading to unauthorized data storage and processing outside of IT oversight.

  • Freemium models: Free trials make it easy to start using a cloud service without involving procurement or compliance teams.

  • Hidden dependencies: Many cloud-based applications rely on third-party APIs and infrastructure that financial institutions are unaware of, increasing risk exposure.


Examples of Shadow IT & Shadow SaaS in Financial Institutions

  • Example 1: Unapproved File Storage & Collaboration Tools A group of financial analysts starts using Dropbox and Google Drive to share investment research. Since this data contains market-sensitive and client information, storing it in a non-approved cloud service creates data leakage and compliance risks under GDPR and DORA.

  • Example 2: Unvetted AI-Powered SaaS Tools A risk management team begins using ChatGPT or another AI-powered SaaS service for financial modeling. The AI model processes proprietary banking data, but since the tool is hosted on a third-party cloud, there is no guarantee that the data is securely stored or deleted after use.

  • Example 3: Unauthorized API Integrations A fintech division within a bank integrates third-party financial APIs into its application without security approval. These APIs connect to external data sources, increasing the risk of data breaches, API abuse, and regulatory violations.

  • Example 4: Marketing & Sales Teams Using Unapproved CRM & Email Service. A sales team signs up for a cloud-based CRM platform outside of the bank’s approved vendor list. Since this platform stores sensitive client details, its security practices may not meet DORA compliance requirements, creating a major third-party risk.


To effectively detect and manage cloud and SaaS dependencies, financial institutions can leverage automated external and internal asset discovery and posture management tools. These solutions provide continuous visibility into cloud applications, API integrations, and third-party services, helping organizations map their entire cloud and SaaS ecosystem and enforce compliance with DORA’s ICT third-party risk requirements.


2. Cloud and SaaS Security: The Shared Responsibility Model

A common misconception about cloud and SaaS security is that once a financial institution moves its systems to the cloud and SaaS, the provider is responsible for everything.


Reality: Security and resilience in the cloud and SaaS follow a shared responsibility model—the cloud provider secures the infrastructure, but the financial institution is responsible for securing applications, configurations, and access control.

Responsibility

Financial Institution

Cloud Provider (AWS, Azure, GCP, Swisscom)

SaaS Provider (e.g., CRM, AI, collaboration tools)

Physical security

❌ No control

✅ Full responsibility

✅ Full responsibility

Data security

✅ Must enforce data security configuration such as data encryption

✅ Shared (CSP typically provides encryption support)

✅ Shared (depends on SaaS model)

Application security

✅ Must enforce application security policies

✅ Shared (but to a less extent especially in IaaS)

✅ Shared (depends on SaaS integration)

Identity & Access Management (IAM)

✅ Must enforce MFA, RBAC, and security policies

✅ Shared (Cloud provides IAM)

✅ Shared (SaaS provides IAM)

Incident response & resilience

✅ Must implement disaster recovery & backup strategies

✅ Shared (depends on Cloud service availability)

✅ Shared (depends on SaaS service availability)


However, not all cloud and SaaS providers are the same, and financial institutions must differentiate between hyperscale providers and midsize SaaS vendors when assessing risk and compliance.


For Hyper-Scale Providers (Azure, AWS, GCP, etc.)


These providers offer high availability, security, and compliance support, but financial institutions must configure and utilize the cloud correctly to enhance resilience. The focus should be on how to use the platform more effectively, such as:

  • Using multiple availability zones to prevent downtime from a single data center failure.

  • Implementing strong identity & access management (IAM) policies to reduce the risk of unauthorized access.

  • Encrypting financial data both at rest and in transit to meet compliance standards.


Example: A European bank migrates its core banking system to AWS but does not properly configure multi-zone replication. When an AWS availability zone experiences downtime, the bank’s online services are temporarily unavailable. This failure highlights the need for financial institutions to proactively architect resilience when using hyperscale cloud providers.


For Mid-Size & Niche SaaS Providers


Smaller SaaS vendors often do not provide the same level of security maturity as hyperscale providers. Contracts with mid-size providers must explicitly define security and resilience responsibilities (DORA Article 30(2)). Vendor risk assessments must verify compliance with operation security best practices.


Example: A Swiss private bank uses a smaller SaaS-based document management system for internal financial reports. Since the service is hosted by a lesser-known provider, the bank must verify encryption policies, audit vendor risk assessments, and ensure contractual compliance with DORA’s resilience requirements.


Key takeaway: Financial institutions must classify their cloud & SaaS providers based on regulatory risk, business impact, and resilience maturity. Large cloud providers offer more built-in security features, while smaller SaaS vendors require deeper contractual and operation security oversight to ensure compliance.


3. Enforcing Security & Compliance in Cloud Contracts (DORA Article 30(2))


DORA Article 30(2) mandates that financial institutions ensure contractual obligations with ICT providers clearly define security, compliance, and resilience requirements. This requirement is especially important for mid-size SaaS providers. Unlike large cloud vendors, mid-size SaaS providers may not have predefined compliance commitments. Financial institutions must explicitly define their security expectations in contracts, such as:

  • Implement strong security controls (access control, encryption, authentication policies). 

  • Provide audit rights for compliance verification.

  • Follow DORA’s mandatory incident response and breach notification timelines. 

  • Ensure resilience and operational continuity.


For more information, please refer to Part 2: Contracting with ICT Service Providers for DORA Compliance.


4. Implementing Continuous Cloud & SaaS Security Monitoring (DORA Article 8)


DORA Article 8 mandates that financial institutions continuously monitor cloud and SaaS services to ensure compliance with security policies, regulatory requirements, and operational resilience. Cloud and SaaS security must be continuously monitored and tested due to:

  • Frequent software updates and changes that could introduce security misconfigurations.

  • Third-party integrations (APIs, plugins, connectors) that expand the attack surface.

  • Evolving user access controls, where permissions may be granted but never reviewed.


Without continuous monitoring, organizations may unknowingly violate DORA’s security and resilience requirements.


Example 1: Automating Microsoft 365 Security Compliance (Large SaaS Provider)


Scenario: A financial institution relies on Microsoft 365 for business-critical functions, including email, document storage, and collaboration tools. Microsoft provides built-in security controls, but the institution is responsible for: 

  • Configuring security settings correctly (e.g., enforcing MFA, blocking legacy authentication). 

  • Ensuring regulatory compliance (e.g., preventing unencrypted email transmission). 

  • Monitoring real-time security events (e.g., detecting unauthorized data access).


Solution: The institution deploys M365 security posture management tools to continuously scan Microsoft 365 settings for things like: 

  • Misconfigured access controls (e.g., excessive admin permissions). 

  • Unsecured file sharing settings (e.g., documents shared outside the organization). 

  • Failed security policies (e.g., MFA not enforced on all privileged accounts).


The system automatically generates compliance reports for regulators, reducing manual security audits.


Key takeaway: Even in well-established SaaS platforms like Microsoft 365, misconfigurations can create compliance gaps. Continuous automated monitoring ensures adherence to DORA and security best practices.


Example 2: Continuous API Penetration Testing for Mid-Size SaaS Provider Integrations


Scenario: A financial institution integrates a mid-size SaaS-based payment reconciliation platform via APIs. While the SaaS provider follows basic security controls, API connections introduce new attack surfaces, including: 

  • Weak authentication tokens (risk of stolen session hijacking). 

  • Lack of rate limiting (risk of API abuse). 

  • Unsecured data transmission (risk of man-in-the-middle attacks).


Solution: The institution implements continuous API penetration testing tools that: 

  • Automatically scan API endpoints for vulnerabilities every week. 

  • Perform simulated attacks (e.g., injecting malformed requests to detect broken access controls). 

  • Check security configuration settings against DORA security standards (e.g., ensuring encryption during data transmission).


Key takeaway: Mid-size SaaS providers may lack robust security testing practices. Continuous automated API penetration testing helps detect vulnerabilities before they are exploited.


5. Final Thoughts


DORA increases regulatory scrutiny over cloud & SaaS providers, making security, resilience, and compliance an ongoing priority.


Key Takeaways: 

  • Automated tools can be used to discover and manage cloud and SaaS dependencies.

  • Not all cloud/SaaS providers are the same—financial institutions must differentiate between hyperscale cloud providers and mid-size SaaS vendors. 

  • Financial institutions remain responsible for their own security posture, even when using external cloud/SaaS vendors. 

  • Contracts play a critical role in ensuring security, compliance, and resilience. 

  • Continuous security monitoring and automated testing are essential to ensure cloud and SaaS services remain secure and compliant over time.


What’s Next?


Part 7: Long-Term Strategy – How to Build Continuous Resilience

DORA compliance isn’t just a one-time effort. How can financial institutions build a sustainable cyber resilience strategy beyond 2025?



Comments

bottom of page