Mapping Azure AKS platform to security frameworks

This report provides a mapping of an Azure Kubernetes Service (AKS) platform’s security and operational features to the requirements of four major cybersecurity frameworks and regulations: ISO/IEC 27001, NIS2 Directive, NIST Cybersecurity Framework (CSF) 2.0, and the EU Digital Operational Resilience Act (DORA). It is intended for CISOs and CIOs to understand how the platform’s technical and procedural controls support compliance with formal security controls and principles. The AKS platform under review is configured with robust security measures - including a private AKS API endpoint, strict network segmentation (using Azure Virtual Networks, Azure Firewall, and Network Security Groups), GitOps workflows with Argo CD, an integrated Web Application Firewall (WAF), secure secret management via Azure Key Vault, use of Azure SQL for protected data storage, comprehensive logging and monitoring, granular role-based access control (RBAC) tied to Azure AD, and managed identities for services. We will map these features to specific controls or articles in each framework, present a crosswalk matrix, and identify overlaps or gaps in compliance coverage. The analysis aligns with the formal language of each standard (e.g. ISO 27001 Annex A controls, NIS2 Article 21 measures, NIST CSF category IDs, DORA Articles) to ensure clarity and specificity.

ISO 27001 compliance mapping

ISO/IEC 27001 is an international standard for information security management systems (ISMS), with Annex A specifying a set of security controls. Below, we explain how the AKS platform’s features align with key ISO 27001 Annex A control domains (using ISO 27001:2013 control references for familiarity, e.g. A.9 for access control, A.12 for operations security):

• Access Control (Annex A.9) - The platform implements strong identity and access management for AKS. The Kubernetes API server is deployed as a private cluster endpoint, restricted to the organization’s Azure Virtual Network, rather than exposed publicly¹. This network-level access control ensures that only internal networks (or approved jump hosts) can reach the cluster API, supporting ISO requirements to protect access to systems (Annex A.13.1.1 on network controls and A.9.1.2 on secure access mechanisms). On the identity side, Azure AD integration with AKS provides centralized authentication and enables enforcing multi-factor authentication (MFA) for administrators via Azure AD conditional access policies (addressing Annex A.9.4.2 on secure log-on). Fine-grained Kubernetes RBAC and Azure RBAC are used to ensure users and service accounts have only the minimum privileges required², fulfilling Annex A.9’s principles of least privilege and authorized user access. Moreover, managed identities are used for AKS-managed components and applications, eliminating hard-coded credentials. Managed identities allow services to authenticate to Azure resources (e.g. Key Vault, SQL) without storing secrets, aligning with Annex A.9 and A.10 by removing the need to manage credentials in code³. Together, these measures meet ISO 27001’s access control objectives by strictly limiting and protecting both network and user access to the cluster.
• Cryptography and Key Management (Annex A.10) - The platform leverages Azure’s built-in encryption and key management to protect data. Azure Key Vault is used to securely store cryptographic keys, application secrets, and certificates, backed by hardware security modules (HSMs). This addresses ISO controls on cryptographic key management (Annex A.10.1.2) by ensuring keys are stored in a dedicated secure vault with strict access controls⁴. Sensitive data at rest in the AKS environment is encrypted: for example, Azure SQL Database used by the solution has Transparent Data Encryption (TDE) enabled by default to encrypt databases at rest, supporting Annex A.10.1 requirements for encryption of sensitive data. Microsoft’s guidance explicitly notes that TDE “should be enabled to protect data-at-rest and meet compliance requirements”⁵. The AKS cluster’s node disks (Azure Managed Disks) are also encrypted by Azure. In transit, all cluster management communication occurs over TLS, and the WAF/ingress ensures web traffic is protected via HTTPS. These measures fulfill ISO’s cryptography control objectives by ensuring confidentiality and integrity of data through strong encryption and secure key management practices.
• Operations Security (Annex A.12) - The AKS platform is configured to maintain a secure and controlled operational environment. Change management (Annex A.12.1.2) is enforced through a GitOps approach using Argo CD. All cluster configurations and application deployment manifests are stored as code in Git repositories, and changes are applied via pull requests that require review. This provides an audit trail of configuration changes and ensures that deployments are consistent with an approved, version-controlled desired state. The benefit is a clear audit log of all changes to the cluster’s configuration and applications, which simplifies compliance audits⁶ and satisfies ISO’s requirements for controlled change implementation and record-keeping. In terms of vulnerability management (Annex A.12.6.1), the platform takes advantage of Azure’s managed services to keep software up to date: the AKS service automatically applies security patches to node OS images and allows for automated Kubernetes version upgrades. Container image scanning (using tools like Microsoft Defender for Cloud or third-party scanners) can be integrated into the CI pipeline to detect known vulnerabilities in images before they are deployed, addressing Annex A.12.6 (technical vulnerability management). Logging and monitoring controls (Annex A.12.4) are robust: AKS control plane audit logs are enabled and sent to Azure Monitor, capturing every API call in the cluster for accountability⁷. These logs, along with Kubernetes guard logs (Azure AD/RBAC audit events), are archived in a Log Analytics workspace and can be reviewed to detect unauthorized activities or changes. Security and application logs can also be aggregated and monitored via Azure Monitor or Sentinel, ensuring that events are recorded and retained in compliance with Annex A.12.4.1 (event logging) and A.12.4.2 (protecting log integrity). The platform uses Azure Monitor and Defender for Cloud for continuous monitoring of configurations against Azure’s security benchmark and ISO controls - this helps assess ongoing compliance and generates alerts for deviations, in line with Annex A.12.7 (information systems audit considerations) and Annex A.15.2 (security in supplier agreements, by leveraging Azure’s audited services).
• Communications and Network Security (Annex A.13) - A cornerstone of the platform’s security is the strict network segmentation and perimeter security in place. The AKS cluster is deployed into a dedicated Azure Virtual Network subnet with no public IP addresses on nodes or the API server (the API uses a private endpoint)⁸. This contained network design meets Annex A.13.1.1’s requirement to segregate networks and control network traffic. An Azure Firewall is positioned in the hub network to inspect and filter traffic egressing from or destined for the AKS cluster. Azure Firewall provides a centralized, stateful network policy enforcement - it allows or denies traffic based on rules for IP, port, protocol and logs all network flows⁹. This supports ISO 27001’s objectives for secure communication networks and the ability to detect unauthorized network connections (Annex A.13.1.2). The firewall’s threat intelligence filtering can alert on or block traffic from known malicious sources¹⁰, aligning with Annex A.12.6.2 (monitoring for malicious activity). Additionally, a Web Application Firewall (such as Azure WAF on Application Gateway or Front Door) protects the application layer. The WAF is configured using OWASP Core Ruleset to actively safeguard web applications against common exploits like SQL injection and cross-site scripting¹¹. Deploying a WAF addresses Annex A.13.2.1 (security of network services) by providing an added layer of defense for external application traffic, and it supports Annex A.14.1.3 (secure application transactions) by mitigating web vulnerabilities without requiring code changes. Internal network segmentation can be further enforced via Kubernetes network policies to restrict pod-to-pod communications, ensuring that even within the cluster, only required traffic flows (supporting Annex A.13.1.3 on segregation in networks). All network communications between services can be encrypted (e.g. enforcing TLS for service APIs) to meet Annex A.13.2.3 (electronic messaging protection). These network controls collectively ensure that the AKS environment’s communications are secure and monitored per ISO 27001.
• System Acquisition, Development, Maintenance (Annex A.14) - The use of infrastructure-as-code and GitOps with AKS directly supports secure development practices. In alignment with Annex A.14.2.1 (secure development policy) and A.14.2.2 (system change control procedures), all changes to the cluster’s infrastructure (helm charts, Kubernetes manifests, etc.) are treated as code and go through automated pipelines and peer review. This not only prevents ad-hoc or untracked changes (reducing risk of misconfiguration) but also means security checks (linting, scanning) can be applied in the pipeline, enforcing compliance with internal secure coding guidelines. The platform also leverages Azure-managed services (AKS, Azure SQL, etc.) which come with secure default configurations and are maintained by Microsoft - this helps satisfy Annex A.14.1.1 (security requirements for new systems) because the services are certified and regularly updated by the supplier (Microsoft). For example, Azure SQL’s encryption and auditing capabilities are enabled to meet security requirements out-of-the-box. Moreover, container images are built through a CI process that can include code security scanning and using base images from trusted sources (reducing supply chain risk, relevant also to A.14.2.5 on secure system engineering principles). Argo CD’s declarative deployment model ensures the runtime environment mirrors the approved configurations in source control at all times, and can even automatically revert unauthorized changes in the cluster, thus maintaining integrity. These practices demonstrate compliance with ISO’s expectations for controlled, secure system development and change management.
• Supplier Security and Cloud Service Assurance (Annex A.15) - When using Azure AKS and related services, the organization is relying on Microsoft as a cloud service provider. ISO 27001 requires that supplier relationships be secured (Annex A.15.1) and that the organization ensure suppliers protect assets in line with the organization’s security requirements (A.15.1.1, A.15.1.2). In this case, Microsoft Azure’s compliance certifications (including ISO 27001 itself) and contractual commitments play a role in compliance. Microsoft undergoes regular independent audits for Azure services against ISO 27001:2022¹²¹³, and Azure’s ISO 27001 certificate and SOC reports can be used by the organization to demonstrate that the underlying platform meets those controls. However, it’s important to note (and ISO acknowledges) that using a certified cloud service does not automatically confer certification to the customer¹⁴. The organization must still ensure their configuration and use of the service is compliant. The AKS platform as configured addresses this by using Azure’s built-in compliance tools - for instance, Azure Policy and Defender for Cloud are used to continuously map the cluster’s configuration to ISO 27001 controls and other standards. This provides evidence of compliance for audits and helps catch any configuration drift that might violate a control. In supplier management terms, the organization should include clauses in its contract with Azure/Microsoft regarding security and compliance (Azure’s standard contractual terms cover data protection and security obligations, supporting Annex A.15.1.3). Azure being prepared to be designated as a critical ICT provider under regulations like DORA (as discussed later) further solidifies their commitment to meeting rigorous security requirements¹⁵. Thus, the combination of Azure’s compliance and the organization’s proper configuration of AKS supports ISO 27001’s supplier security controls.
• Incident Management and Business Continuity (Annex A.16 & A.17) - The platform’s design also contributes to incident response and operational resilience. For incident management (A.16), having centralized logging and alerting means security events in the AKS environment can be detected and responded to quickly. Azure Monitor and Microsoft Sentinel (if used) can generate real-time alerts for suspicious activities (e.g., anomalous admin access or pod deployments), which is essential for timely incident response. This supports Annex A.16.1.1 (reporting information security events) and A.16.1.5 (incident response planning and testing). The AKS platform can integrate with the organization’s incident response procedures - for example, if a container is compromised, responders can use Kubernetes controls to isolate or drop the pod, rotate credentials in Key Vault, and use Argo CD to redeploy clean images. All such actions should be playbooked and tested, as required by ISO. Regarding business continuity (A.17), the cloud-native architecture inherently provides high availability: Azure AKS can be configured with multiple node pools spread across Azure Availability Zones for resilience to datacenter failures. Azure Firewall and other components also support zone-redundancy¹⁶. Data persistence (in Azure SQL or other state stores) benefits from Azure’s geo-redundant backup capabilities - Azure SQL, for instance, offers automated backups with point-in-time restore, and can be configured for geo-replication to a secondary region. For cluster state, because all infrastructure is defined in Git (and container images are stored in a registry), the cluster can be recreated in a different region relatively quickly in a disaster scenario, which fulfills A.17.1 (planning information security continuity) and A.17.2 (redundancies). Regular backup testing and disaster recovery drills (e.g., restoring a database from backup, or simulating region failover for the AKS cluster) should be conducted to satisfy ISO’s requirements (as well as similar DORA requirements for operational resilience testing). In summary, the AKS platform’s resilient architecture and the processes around it (logging, alerting, backups, redeployment automation) align well with ISO 27001’s controls for incident handling and business continuity.

Summary: Through the above measures, the Azure AKS platform helps an organization satisfy numerous ISO 27001 Annex A controls, from technical measures like access control, encryption, and network security to process-oriented controls like change management and incident response. The platform’s features map to ISO control objectives as shown in the crosswalk table later in this report. It should be noted that while technology and configuration go a long way, ISO 27001 also demands policies, procedures, and evidence - for example, an Access Control Policy document (A.9.1.1) or an incident response plan (A.16.1.5). The organization should ensure that these documents reflect and govern the use of the platform’s security features. With that in place, the AKS platform can be a strong enabler of ISO 27001 compliance by providing security-by-design and built-in controls that correspond directly to the standard’s requirements.

NIS2 compliance mapping

The NIS2 Directive (EU Directive 2022/2555) imposes cybersecurity risk management requirements on essential and important entities in the EU. Article 21 of NIS2 outlines a set of minimum measures (points (a) through (j)) that organizations must implement¹⁷¹⁸. We map each of these NIS2 requirements to the corresponding features and configurations of the Azure AKS platform:

• (a) Policies on risk analysis and information system security: The AKS platform’s design is the result of a risk-based approach to secure cloud architecture. By choosing a private, well-segmented deployment and implementing strict controls, the organization is addressing identified risks (e.g., internet exposure of management interfaces, unauthorized access, data leakage). The platform supports the organization’s risk management policies by providing capabilities such as Azure Security Center (Defender for Cloud) and Secure Score to continuously assess risks in the environment¹⁹²⁰. Although the creation of risk analysis policies is primarily procedural, the presence of Azure Policy and compliance tooling allows the organization to enforce security policies in technical configurations (for example, ensuring that only approved container images are deployed, or that critical logging is always enabled). Thus, the AKS platform is aligned with NIS2’s requirement for having formal security and risk management policies, by offering the means to implement and monitor those policies in practice.
• (b) Incident handling: NIS2 requires capabilities for incident detection and response. The AKS platform contributes to this through comprehensive logging, monitoring, and alerting. Kubernetes audit logs and Azure diagnostics logs are collected, enabling prompt detection of anomalies or security events (such as unauthorized API calls or pod crashes). These detection mechanisms map directly to incident handling capabilities; for example, Azure Monitor can trigger alerts to operations teams when specific thresholds or patterns (possible incidents) occur, and Microsoft Sentinel or another SIEM can be used to aggregate signals and facilitate investigation. The platform’s RBAC and network controls also help contain incidents (limiting their spread). In the event of an incident, responders can leverage Azure’s tools (like Azure Service Health or Container Insights) to analyze impact. Using managed identities and Key Vault means that credential compromise is limited (an attacker who gets a hold of a pod cannot extract long-lived secrets, aiding containment). All these aspects support a robust incident handling process in line with NIS2 Article 21(2)(b). The organization should also integrate these technical capabilities with an incident response plan (who gets notified, how incidents are escalated, etc.), but the platform ensures the mechanisms (log collection, alerts, isolation options) are in place for effective incident management²¹²².
• (c) Business continuity and crisis management (including backup management and disaster recovery): The AKS platform architecture was built with resilience in mind. For business continuity, automated backups are configured for stateful components: Azure SQL databases have PITR backups and can be geo-redundant, and any other state (for example, files in Azure Blob Storage, if used) is replicated. The Kubernetes cluster itself is stateless (aside from config and container images) - leveraging the GitOps approach, the entire cluster configuration is stored in Git, effectively acting as a backup of the “infrastructure state.” In a disaster scenario (e.g., region-wide outage), a new AKS cluster could be rapidly provisioned from code and pointed to the same Git repo to restore all Kubernetes objects. This ability to restore services from code and backups addresses NIS2’s continuity requirements. Additionally, the AKS cluster can be deployed across Availability Zones to withstand localized failures. The platform uses Azure Front Door or Traffic Manager (if applicable) for failover of client traffic to a secondary site if one is available. Regular DR drills and backup tests are facilitated by Azure tools (e.g., Azure Backup reports) to meet the “backup management and disaster recovery” aspect of this control. Crisis management is supported by Azure Service Health alerts, which inform the team of any Azure-side incidents so they can enact contingency plans. Overall, the combination of redundancy, backups, and codified redeployment processes fulfills NIS2’s point (c) by ensuring that even if an incident occurs, services can be recovered and downtime minimized.
• (d) Supply chain security (including security of relationships with suppliers and service providers): Supply chain security is a multi-faceted requirement that the AKS platform addresses in several ways. First, by using Azure AKS (a managed service) and other Azure components, the organization is entrusting part of its supply chain to Microsoft. Microsoft’s adherence to security standards (e.g., DORA readiness and ISO certifications) and contractual SLAs help ensure that this supplier relationship is secure²³²⁴. On the technical front, GitOps with Argo CD and container image management practices mitigate supply chain risks in the software pipeline. Only approved repositories and registries are used for deployments; Argo CD can be configured with pull request approvals and even signed container images or manifests (e.g., using Sigstore Cosign and Argo CD’s manifest integrity verification) to ensure that the code running in AKS is coming from trusted sources. This provides integrity assurance for the CI/CD pipeline. All changes to the environment are tracked and auditable via Git commits, which helps in verifying that no unauthorized or unvetted changes (potentially injected by a malicious third party) are applied²⁵. Additionally, the platform likely employs container scanning (Azure Defender for Containers or a similar tool) to detect vulnerable components in images, and has policies to only use base images that are regularly patched. Dependency management for application code (though outside AKS itself) is handled in build pipelines with security scans (aligning with secure development best practices and covering upstream open-source components’ security). Finally, for relationships with service providers: all external services integrated with the AKS workload (e.g., a third-party API) are accessed over secure channels and with proper authentication, and such integrations are catalogued as part of the system’s asset management. NIS2’s emphasis on supply chain means the organization should maintain an inventory of suppliers (including cloud providers like Azure and open-source projects like Argo CD) and assess their security - the AKS platform’s use of widely trusted services and ability to enforce provenance on deployments significantly supports compliance in this area.
• (e) Security in network and information systems acquisition, development and maintenance (including vulnerability handling and disclosure): The AKS platform is aligned with modern DevSecOps practices that embody security throughout the system lifecycle. During acquisition and development, security requirements were clearly defined - for example, the requirement that the cluster API be private, or that all data be encrypted, guided the selection and configuration of Azure services. The use of Infrastructure as Code (IaC) (ARM/Bicep or Terraform templates for Azure infrastructure, Helm charts/YAML for Kubernetes resources) means that the environment is built from templates that can be security-reviewed and tested before deployment (fulfilling secure configuration of new systems). Vulnerability handling is addressed by multiple layers: Azure regularly patches AKS control plane and node components (with options to auto-upgrade node images), and the organization monitors vulnerability announcements (e.g., Kubernetes CVEs). Azure’s managed nature means critical patches are applied to the control plane by Microsoft, reducing the burden on the organization. On the application side, container images are rebuilt frequently to include the latest OS and library patches. If a zero-day vulnerability arises (say in a container base image or a library), the GitOps workflow allows rapid rollout of patched versions to all clusters. Disclosure of vulnerabilities in the open-source components (Kubernetes, Argo, etc.) is handled through their communities, but the organization subscribes to security advisories to stay informed. Moreover, Azure Defender for Cloud can assess the AKS cluster against known benchmarks and flag misconfigurations or outdated components (e.g., it could alert if the cluster is running an unsupported Kubernetes version or if a critical patch is missing). This continuous maintenance and vulnerability management process directly addresses NIS2 point (e) by ensuring the AKS platform is kept up-to-date and any security issues are promptly mitigated. The design also likely includes a web vulnerability disclosure process for the application (i.e., if an external researcher finds an issue in the app, how they report it), which is more of a policy, but the presence of a WAF and monitoring will help detect any exploitation attempts in the interim.
• (f) Policies and procedures to assess the effectiveness of cybersecurity measures: The AKS platform enables ongoing security effectiveness assessments through Azure’s governance tools. The organization can leverage Azure Policy initiatives mapped to standards (Azure provides built-in policy sets for benchmarks and even NIS2 requirements) to regularly evaluate if the AKS environment remains compliant. For instance, policies can check that Kubernetes Pods do not run with privileged permissions, or that Key Vault secrets are being rotated regularly. Azure Defender for Cloud’s Regulatory Compliance dashboard can map the platform’s configuration to controls from frameworks including NIST and ISO, which overlap with NIS2, highlighting any gaps. Additionally, the logging and audit trail provided (e.g., by GitOps and Azure AD logs) allow for periodic reviews and audits. The organization should conduct regular security audits of the AKS environment - e.g., quarterly reviews of RBAC assignments, network security rules, and container image vulnerabilities - to fulfill this control. The platform’s built-in reports (Secure Score, compliance reports) provide a quantifiable measure of security posture²⁶. If weaknesses are found (say, an excessive permission or an open port), the platform’s configuration can be adjusted and the policy updated to prevent recurrence. Furthermore, penetration tests or threat simulations can be run against the environment (with Microsoft’s approval if needed for certain Azure tests) to gauge its resilience; the results of those tests inform the effectiveness of the controls. In summary, NIS2’s requirement (f) is met by a combination of technical compliance checks (policies, Azure Secure Score) and governance processes that the platform data enables (internal audits, pen-testing).
• (g) Basic cyber hygiene practices and cybersecurity training: While many elements of cyber hygiene (like user training) are outside the scope of a technology platform, the AKS environment contributes by enforcing hygiene requirements by design. “Basic cyber hygiene” includes actions like using MFA, applying updates, removing unsupported software, least privilege access - all of which are inherently applied in this architecture. For example, no user can access the AKS cluster without going through Azure AD MFA (if enforced), and all admin actions are logged, which encourages accountability. The cluster’s nodes run only necessary services (container runtime, agents) and unnecessary ports are closed, aligning with hygiene principles of reducing attack surface. On the organizational side, administrators and developers who interact with AKS should be trained on secure Kubernetes practices (such as not running containers as root, understanding network policy, etc.). The platform’s GitOps approach helps here: developers primarily interact with Git, and Argo CD handles the cluster changes, meaning developers have fewer direct touchpoints with the live cluster, reducing chances of accidental misconfiguration (a hygiene benefit). Still, to meet NIS2 (g), the company must ensure its staff is trained on the secure use of Azure and AKS - for instance, training on Azure role management and Kubernetes security is provided. The presence of these platform controls can even be used in training material as examples of enforced best practices. In essence, the platform is a practical embodiment of many cyber hygiene best practices (secure config, principle of least privilege, regular updates), and combined with appropriate staff training, it helps fulfill this NIS2 requirement.
• (h) Policies and procedures regarding the use of cryptography and encryption: The AKS platform heavily utilizes encryption for data protection, which aligns with NIS2’s mandate to have policies on cryptography. Concretely, encryption in transit is enforced by using HTTPS for all external and internal APIs (Kubernetes API, application endpoints behind the WAF). Encryption at rest is ensured through Azure SQL TDE, Key Vault (which by design encrypts secrets in HSMs), and encrypted disks. The organization likely has a cryptography policy that states what data must be encrypted and how keys are managed - the platform provides the tools to implement that policy. For example, the policy might require that encryption keys for sensitive data be stored in a secure key management service; Azure Key Vault fulfills this by storing keys (perhaps even customer-managed keys for TDE) with controlled access²⁷. The use of TLS for all services can be enforced via Azure Application Gateway’s WAF (which can block non-TLS traffic) and Kubernetes ingress configurations. The platform also allows using modern cipher suites and protocols as required by policy (Azure TLS configurations are adjustable). If the policy requires regular rotation of keys, Key Vault’s key rotation feature can automate rotating keys or secrets on schedule. Additionally, managed identities and Azure AD integration ensure that encryption keys or secrets are not shared in plaintext with developers or admins - they get abstracted via identity-based access, reducing human exposure to sensitive cryptographic material. These technical measures satisfy the NIS2 point (h) by demonstrating that encryption is uniformly applied and managed under well-defined procedures in the AKS environment. Documentation should exist to describe these cryptographic controls (e.g., how TLS is configured, how keys are rotated) to fully meet the “policies and procedures” aspect.
• (i) Human resources security, access control policies, and asset management: This point combines a few areas. The access control policies portion is directly addressed by the RBAC and Azure AD controls described earlier - an organizational access control policy likely exists (fulfilling something like ISO A.9.1.1), and the AKS platform’s implementation (AAD RBAC, least privilege, just-in-time access possible via Privileged Identity Management) puts that policy into action. Human resources security typically involves background checks, clear definitions of admin roles, and revocation of access when personnel leave. Azure AD integration means that when an administrator’s Azure AD account is disabled (e.g. upon termination of employment), their access to the AKS cluster is automatically revoked as well, which is a critical link between HR processes and technical access control. The platform encourages use of Azure AD groups to manage cluster access, so that role changes or offboarding can be handled by group membership updates rather than static Kubernetes secrets or certificates. This tightly supports HR security policies by reducing the risk of orphaned accounts or rogue access. Regarding asset management, the AKS platform is part of the organization’s information assets, and assets within it (container images, data stores, configurations) are tracked. Azure provides tagging and inventory services (like Azure Resource Graph) to list all resources (the AKS cluster, node pools, firewall, etc.), contributing to asset management records. Within AKS, the team should maintain an inventory of what applications are running and what data they handle. GitOps helps here by serving as a manifest of deployed apps. Thus, the platform aids asset management by centralizing definitions of infrastructure and by leveraging Azure’s cloud inventory capabilities. In summary, NIS2 (i) is addressed through technical enforcement of access controls aligned to HR processes and maintaining clear visibility of assets. All cluster administrators must be formally authorized per company policy, and the platform ensures no shadow access methods exist (since everything funnels through AAD). Additionally, any contractor or third-party with access would be set up in AAD with proper controls, again bridging the HR and technical realms.
• (j) The use of multi-factor authentication or continuous authentication, secured communications, and secure emergency communication systems: The AKS platform inherently supports MFA by its integration with Azure AD. Administrators and developers accessing the cluster must authenticate via Azure AD, where MFA can be required for all user logins (Microsoft is in fact moving toward mandatory MFA for Azure AD tenants²⁸). This satisfies the MFA element of (j) - critical systems access is protected by at least two factors, mitigating phishing and unauthorized use of credentials. The platform also supports continuous authentication/authorization in the sense that Azure AD tokens used for AKS expire and can be revoked, and Kubernetes can enforce short-lived credentials. For secured voice, video, text communications, which NIS2 mentions for emergency comms, that is outside the scope of AKS itself, but the organization likely uses secure channels (e.g., Teams with E2E encryption for incident coordination). Nevertheless, within AKS, all communication channels are secured: the Kubernetes API uses TLS, application inter-service calls use secure protocols, and administrators connect to AKS nodes or API through secure methods (for instance, using az aks command invoke which goes through Azure pipelines, or via a VPN/Bastion host). Secure emergency communication systems could refer to out-of-band communications during an incident; while AKS does not directly address that, the resilience of the platform means that even during attacks, the monitoring and alerting (which might notify staff via secure apps or phone alerts) remain intact. It’s worth noting that by keeping the cluster API private and not accessible from the internet, the platform reduces the need for emergency takedowns of services - it’s less likely a critical admin interface would be compromised to necessitate emergency comms with law enforcement or regulators. However, if such communications were needed (say a major breach), the logs and audit trails from the platform provide the evidence required to share with authorities. In essence, the platform fully supports MFA and secure comms for system access, meeting the technical spirit of (j).

By fulfilling each of the points (a) through (j) as described above, the Azure AKS platform provides comprehensive coverage of NIS2’s cybersecurity risk management measures. Many of these measures overlap with ISO controls and NIST CSF categories, which the platform also addresses (as discussed elsewhere in this report). The next section will map the platform’s features to the NIST CSF 2.0 functions and subcategories, providing another perspective on the coverage.

NIST CSF 2.0 compliance mapping

The NIST Cybersecurity Framework (CSF) 2.0 organizes cybersecurity activities into five core functions - Identify, Protect, Detect, Respond, Recover (with an additional “Govern” function introduced in CSF 2.0 to emphasize governance). Within each function are categories and subcategories (control activities) labeled by IDs (e.g., PR.AC-1 for a Protect/Access Control subcategory). We map the Azure AKS platform’s controls to these CSF functions and highlight specific subcategory alignment:

• Identify (ID) - This function is about understanding the business context, assets, and risk. In the context of the AKS platform, asset management (ID.AM) is a critical piece. All Azure resources (AKS clusters, node pools, network components, etc.) are tracked in Azure Resource Manager, allowing the organization to maintain an up-to-date inventory (fulfilling CSF subcategory ID.AM-1: Physical devices and systems within the organization are inventoried and ID.AM-2: Software platforms and applications are inventoried for the platform). Kubernetes itself provides a view of running workloads (Pods, Deployments), and using GitOps, the “inventory” of applications and configurations is the Git repository - which provides a documented list of what is supposed to be running. ID.GV (Governance) is supported by the platform through Azure Policy and role definitions that ensure governance policies are enforced in the cloud environment. For example, who can create or alter cloud resources for AKS is strictly controlled by Azure RBAC roles, supporting ID.GV-2: Governance and risk management processes address cybersecurity risks. The organization can map business criticality to the AKS-hosted applications (ID.BE-3) and identify dependencies (like the fact that Azure Key Vault and Azure SQL are critical dependencies for the application). In fact, identifying supply chain risk (ID.SC) is enhanced by the platform’s use of known-good base images and Azure’s trusted services, aligning with CSF 2.0’s increased emphasis on supply chain. Overall, the platform provides the tooling to identify assets, identities, and risks - e.g., Azure AD identity management helps enumerate all users with access (supporting ID.AM-6: Identities are managed as part of CSF’s identify/govern scope). These identification capabilities form the foundation for targeted protection.

• Protect (PR) - This is the richest area of mapping, as the platform implements extensive protective controls across several categories:

  • PR.AC (Identity Management and Access Control): The AKS platform’s integration with Microsoft Entra ID (Azure AD) and use of RBAC directly addresses subcategories like PR.AC-1: Identities and credentials are managed for authorized devices and users. Every user accessing AKS is authenticated via Azure AD, with unique credentials and MFA - satisfying PR.AC-7: Users, devices, and accounts are authenticated (e.g., MFA) for access. The principle of least privilege is enforced (PR.AC-4) by fine-tuned role bindings in Kubernetes (for example, developers might only have access to deploy to specific namespaces, and ops personnel have admin rights, etc.). Network access control is also a part of PR.AC: the private cluster endpoint and network security groups ensure that only authorized networks can reach resources, aligning with PR.AC-5: Network integrity is protected (e.g., network segmentation, least functionality). These measures collectively demonstrate a strong identity and access management regime per NIST CSF.
  • PR.DS (Data Security): The platform protects data at rest and in transit. Encryption is ubiquitous - Azure SQL, Managed Disks, etc., all data stores are encrypted (mapping to PR.DS-1: Data-at-rest is protected²⁹). PR.DS-2: Data-in-transit is protected is met by enforcing TLS for all connections (Kubernetes API and app traffic via WAF). Access control to data (PR.DS-4) is achieved by using Azure AD identities for any service that needs to access sensitive data. For instance, an application pod uses a managed identity to fetch a secret from Key Vault; Key Vault’s access policy ensures only that identity (and authorized admins) can read the secret. Audit logs for data access (PR.DS-6) are available via Key Vault logging and SQL auditing (which is enabled to track database activities³⁰). Additionally, backups of data are protected (encrypted and access-controlled) in line with PR.DS-5: Protections against data leaks are implemented. The Azure Policy requiring TDE on SQL databases³¹ is an example of a protective control explicitly mapped to compliance.
  • PR.PT (Protective Technology): This category covers security solutions that safeguard systems and detect events. The AKS platform deploys multiple protective technologies: firewalls, WAFs, network segmentation, and endpoint security. The Azure Firewall in the architecture is a prime example, as it is a dedicated network protection service controlling traffic and blocking threats (addressing PR.PT-3: Least functionality - only necessary ports/protocols are allowed, and PR.PT-4: Communications and control networks are protected via firewall filtering³²). The Web Application Firewall is another protective tech that specifically guards the application layer by blocking common attacks³³ (this aligns with PR.PT and also with DE.CM for monitoring, but primarily it’s a protective measure). Kubernetes itself has protective features enabled: for example, pod security policies/standards (or the newer Pod Security Admission configurations) can be used to prevent privileged containers (ensuring the cluster is hardened). The cluster is also configured to auto-update node images and uses baseline Azure security benchmarks, which is part of PR.MA-1: Maintenance and repair of organizational assets is performed and logged - Azure’s platform automatically maintains the underlying VMs with patches, reducing attack surface. In addition, PR.PT-1: Audit/log records are determined, documented, implemented could be considered here - the platform’s design included decisions on what to log (API server audit, ingress logs, etc.), which is a protective and detective measure.
  • PR.IP (Policies, Processes, and Procedures): Although this CSF category is more process-focused, the AKS platform supports organizational policies like change management, incident management, and continuous improvement. The GitOps process maps to PR.IP-3: Configuration change control processes are in place - every change to the cluster is made through a controlled process with approvals. PR.IP-1: A baseline configuration is established and maintained is achieved by having the desired state in Git and using Azure Policy to enforce baseline settings (for example, ensuring that certain security contexts are always applied to pods). The use of infrastructure as code and Azure Blueprints/Policies means documentation of the environment’s configuration is effectively built-in (PR.IP-2 regarding a System Development Life Cycle in place - yes, secure DevOps lifecycle is in use). While training (PR.AT) is largely outside the platform, the presence of these tools means staff can be trained to rely on automation and not make out-of-band changes, strengthening procedural discipline.
  • PR.MA (Maintenance): This involves managing assets throughout their life. The AKS platform automates much of maintenance (node patching, etc.), but the organization should have a schedule for Kubernetes version upgrades (Kubernetes versions are supported for a finite period). This can be tied to PR.MA-2: Remote maintenance is approved, logged, and performed in a manner that prevents unauthorized access - in context, Azure handles the control plane maintenance (logged on Azure’s side), and if engineers ever need to access the cluster for support, it’s through Azure’s controlled channels. For the organization’s part, any maintenance scripts or diagnostics run on the cluster (like kubectl exec for debugging) should be done by authorized personnel and recorded (which ties back into RBAC and audit logs).

  • Detect (DE) - The detect function ensures that cybersecurity events are discovered quickly. The AKS platform has extensive monitoring which maps to NIST CSF Detect categories:

  • DE.AE (Anomalies and Events): The platform logs allow baselining normal behavior and identifying anomalies. For instance, an alert can be set if an unusual sequence of Kubernetes API calls is detected (e.g., mass pod creation or an admin account doing something at odd hours). Azure Monitor with Log Analytics can enable queries to find such outliers. The system also leverages Azure Security Center’s anomaly detection for AKS (which might detect suspicious container activity). This supports DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed - with known microservice communication patterns, any deviation could be flagged (especially if network policy is in place, deviations might be blocked). DE.AE-2: Detected events are analyzed to understand attack targets and methods - for example, if WAF logs show repeated SQL injection attempts, those events are analyzed by the SOC to see if it’s a targeted attack on a specific application.

  • DE.CM (Security Continuous Monitoring): The AKS platform enables continuous monitoring through multiple sources: Kubernetes audit logs, which capture all API requests (monitored for suspicious admin actions)³⁴; Azure AD sign-in logs, to watch for failed logins or unusual geolocations (tying into identity anomaly detection); container runtime security monitoring via Defender for Cloud (which can detect if a container spawns a shell or makes an unexpected outbound call); application and system metrics (CPU spikes could indicate crypto mining malware, for instance). These monitoring activities correspond to DE.CM-1: The network is monitored to detect potential cybersecurity events, DE.CM-3: Personnel activity is monitored (e.g., admin actions), and DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed. An example is the Azure Policy that ensures only approved container images run - if an unauthorized image appears, it’s a policy violation event that can be alerted on (detecting unapproved software). The use of Azure Sentinel could unify these logs and apply analytics (AI/ML) to spot threats that span across identity, network, and compute domains.
  • DE.DP (Detection Processes): The organization should have defined processes to respond to alerts from the above monitoring (which edges into Respond function). However, in terms of platform contribution: alerts from Azure (like Security Center recommendations or WAF threat alerts) are integrated into an incident tracking system. Automated playbooks can be set (for example, on a high-severity Azure Defender alert, automatically create a ticket and assign to on-call). This supports DE.DP-4: Event detection information is communicated to appropriate parties. The platform can also produce periodic compliance reports indicating if any security controls were out of compliance - which feeds into the detection of control failures (essential for governance). Notably, DE.DP-5: Detection processes are continuously improved - as the AKS platform runs, the organization will learn and refine which alerts are useful, maybe enabling new Azure Diagnostics (like enabling more verbose audit categories, or using new threat detection features as they become available). Thus, the platform is not static; it allows adaptability as threats evolve, which is consistent with NIST CSF’s iterative improvement philosophy.

  • Respond (RS) - The respond function covers activities to take action during or after a detected incident. While response is largely procedural, the AKS platform provides tools that can be used in the response:

  • RS.RP (Response Planning): The organization’s incident response plan should explicitly cover incidents in cloud/Kubernetes environments. The presence of the AKS platform means the plan can include steps like “quarantine a compromised pod” (which can be done by cordoning a node or scaling the deployment down), or “revoke access” (which can be done immediately in Azure AD). Because the platform is software-defined, some response actions can even be automated. For instance, if a container is detected running a disallowed process, a Logic App could automatically isolate that pod or node. These types of actions align with RS.RP-1: Response plan is executed during or after an event - here the plan is augmented by cloud automation.

  • RS.CO (Response Communications): Azure and AKS provide mechanisms to notify stakeholders. Service Health alerts will inform if the incident is related to an Azure outage. For security incidents, if integrated with Sentinel, automated emails or Teams messages can be sent to the incident response team. The platform’s logging ensures that if law enforcement or regulators need information (e.g., in a reportable incident under NIS2 or DORA), the team can quickly gather evidence. This maps to RS.CO-2: Events are reported to appropriate stakeholders (e.g., executives, authorities) - for example, using Azure’s tools to generate an incident summary for executive review within hours of detection. Moreover, Microsoft provides customer support and will communicate through secure channels if an incident involves the Azure platform itself (like a multi-tenant issue), ensuring coordination.
  • RS.AN (Analysis): The rich logs and telemetry from the AKS platform support forensic analysis. RS.AN-1: Notifications from detection systems are investigated - the SOC can use Azure Monitor logs to drill into an alert (e.g., if an alert says a pod made an unusual outbound connection, the team can examine container logs, the image hash, etc., all available in Azure log stores). RS.AN-3: Forensics are performed - if needed, the team could snapshot a compromised container’s disk or memory (Azure provides ways to dump VM memory if needed, or one could pause a pod and inspect it). The key point is that by design, audit trails are intact (e.g., Kubernetes API audit logs cannot be erased by an attacker in the cluster as they’re exported to Azure Monitor), which is crucial for trustworthy analysis.
  • RS.MI (Mitigation): Mitigation steps can be swiftly executed in a cloud environment. For example, if a particular container image is found to be malicious, the team can globally update Argo CD to pull that image out of rotation and redeploy all pods with a known good image. Or if a zero-day in the web framework is exploited, one could deploy a WAF custom rule within minutes to block a specific attack signature, thereby mitigating damage while a patch is developed (this aligns with RS.MI-1: Incidents are contained). The AKS platform’s scalability also aids mitigation - if an incident is DDoS in nature, Azure’s DDoS protection and the elasticity of AKS can absorb or mitigate the impact. In case of ransomware in a container (unlikely, but suppose an attacker encrypts some volume), having recent backups (and immutability of container images) allows quick recovery without paying ransom, which is a mitigation strategy.
  • RS.IM (Improvements): After an incident, lessons learned can inform improvements in both process and configuration. The modular nature of the platform means you can tighten a policy or add a new Azure Monitor alert as a direct follow-up action from an incident post-mortem (RS.IM-1: Response plans incorporate lessons learned). For instance, if an incident revealed that an admin had overly broad permissions, you can immediately adjust the RBAC role and Azure will propagate it. This tight feedback loop ensures continuous enhancement of the protective posture.

  • Recover (RC) - Recovery encompasses restoring capabilities or services after an incident and incorporating lessons into resilience strategies. The AKS platform inherently supports fast recovery due to its infrastructure-as-code and cloud-native setup:

  • RC.RP (Recovery Planning): There are documented recovery procedures for the AKS platform. For example, the runbook for a total loss of the primary region might include steps to deploy the AKS cluster in a secondary region from the GitOps repo, restore the database from backup, and switch over the DNS. Because these steps have been pre-defined and tested, RC.RP-1: Recovery plan is executed can be achieved with minimal delay when needed.

  • RC.CO (Recovery Communications): Throughout the recovery process, Azure’s tools provide status updates. The team can communicate internally the status of restoration (e.g., “database restored to X point, web app back online”). If certain data was lost or delayed, that may need to be communicated to customers per regulatory requirements. The platform’s design (with redundant logs and data) minimizes the chance of irrecoverable data loss, making external communication easier (“no customer data was lost, service was restored within RTO limits”).
  • RC.IM (Improvements): After recovery, the organization will analyze what went right or wrong. If, for instance, recovery took longer than expected because a manual step was needed, they might automate that step in the future (e.g., automate the redeployment of infrastructure). This continuous improvement aligns with RC.IM-1: Recovery planning and processes are improved by incorporating lessons learned. The AKS platform’s flexibility (infrastructure as code, modular design) allows the organization to strengthen the architecture over time - for example, after an incident, they might decide to implement multi-region active-active deployment for critical services to reduce recovery time to near zero, using AKS in multiple regions with Azure Front Door failover.

In summary, the Azure AKS platform maps very well to the NIST CSF core. It provides concrete technical controls for the Protect function (identity management, network security, data protection) which are often the most resource-intensive to implement from scratch. It also supplies ample data and capabilities for Detect and Respond (logging, monitoring, automation hooks). Identify and Recover are supported by the platform’s use of Azure services (for inventory and backups respectively) but also require organizational processes around them. By utilizing the platform’s features as described, an organization can satisfy many subcategories of the NIST CSF, such as PR.AC-1 (managed identities for access)³⁵, PR.DS-1 (encrypted data at rest)³⁶, PR.PT-1/PR.PT-3 (audit logs and least functionality)³⁷³⁸, DE.CM-1 (network monitored)³⁹, RS.MI-1 (containment through segmentation and rapid reconfiguration), and RC.RP-1 (tested recovery plan using infrastructure as code). The crosswalk table later in this report will explicitly map key platform features to CSF category examples.

DORA compliance mapping

The Digital Operational Resilience Act (DORA) is an EU regulation aimed at financial entities, focusing on ICT risk management, incident reporting, operational resilience (including disaster recovery and business continuity), and ICT third-party risk. Although DORA is primarily a regulatory framework rather than a technical standard, many of its requirements align with best practices that the AKS platform implements. We examine how the platform supports a financial organization’s compliance with DORA’s key pillars:

• ICT Risk Management Framework: DORA requires firms to have a comprehensive ICT risk management framework covering identification, protection, detection, response, and recovery (mirroring the NIST CSF functions)⁴⁰⁴¹. The Azure AKS platform, as described, provides capabilities across all these areas, thereby serving as a strong foundation for the organization’s ICT risk management. For instance, as part of risk identification, the organization can document how the AKS cluster supports critical business services, and use Azure tagging to classify resources by criticality (fulfilling the requirement to identify ICT assets, their roles, and dependencies⁴²). On the protection side, all the security controls (network isolation, encryption, etc.) implemented in AKS directly mitigate identified risks, which would be detailed in the risk register. The platform also aids ongoing risk monitoring - Azure Secure Score continuously evaluates risk posture (which can feed into the risk management framework to adjust controls as needed)⁴³. Essentially, by deploying workloads on a well-secured AKS cluster, the firm is addressing many of the technical risk scenarios DORA envisions (cyberattacks, system failures). The risk framework also extends to third-party risks, which in the context of AKS means risks from Azure as a provider and from any integrated tools (like Argo CD). Microsoft’s stance on DORA is clear: “Microsoft is prepared to be designated as a ‘critical ICT third-party service provider’ … and will help regulated financial institutions meet their own requirements.”⁴⁴. This assurance from Azure allows the organization to incorporate Azure’s controls and attestations into its risk management framework, addressing DORA’s expectation that firms consider the quality and robustness of critical ICT suppliers⁴⁵.
• Incident Reporting and Detection (Article 17 & Article 19 in DORA): DORA mandates that financial entities have the ability to detect ICT incidents promptly and report major incidents to regulators within tight timelines. The AKS platform’s enhanced detection mechanisms (through logging, Azure Defender alerts, etc.) enable the firm to identify incidents quickly, as required by DORA Article 10 on Detection (“Financial entities shall have in place mechanisms to promptly detect anomalous activities…”⁴⁶). For example, if a cyber-attack occurs on the AKS-hosted application, the combination of WAF alerts, unusual Kubernetes API activity, or spikes in error rates would be caught by the monitoring systems, generating immediate alerts. The incident response team can then assess the incident’s severity (using the rich data available) and determine if it meets DORA’s criteria for a major incident (e.g., significant impact on service availability or data integrity). The platform’s audit logs and tracking of user actions are invaluable in this analysis, as they provide evidence of what happened. When it comes to reporting, while the platform does not automatically report to regulators (that’s a process task), it facilitates compliance by providing the information needed to file an accurate and timely incident report. Firms must usually report within hours of detection - having all logs centralized means the team can quickly compile the sequence of events. Moreover, Azure’s compliance manager and DORA-specific guidance can help ensure that the organization’s incident taxonomy and impact metrics align with what needs to be reported under DORA. The AKS platform also supports continuous testing of detection controls - DORA expects firms to regularly test their detection (Article 25 requires regular testing of resilience, including detection tools). Security drills can be run on the AKS platform (for example, simulating an insider attack on the cluster) to verify that alerts fire as expected, and adjustments can be made based on results⁴⁷. This level of preparedness directly contributes to DORA compliance in the incident management domain.
• Response and Recovery (Operational Resilience): DORA places strong emphasis on not just responding to incidents but ensuring that critical functions can continue or be restored rapidly (Chapter III of DORA covers ICT-related incident response and recovery). The AKS platform’s high-availability and disaster recovery capabilities map to these requirements. Business continuity plans for important services running on AKS would leverage the multi-zone deployment of the cluster, backups of data, and the ability to redeploy via code. This satisfies DORA’s requirement that entities have “backup policies and recovery plans for all critical ICT systems” and that they test these plans⁴⁸⁴⁹. The platform allows for automated failover in certain cases - for example, using Azure Front Door to direct traffic to a backup instance if the primary is down - which aligns with the need to minimize service downtime. DORA Article 11 (Response and Recovery) likely stipulates that financial entities must have “response and recovery plans” and restore availability promptly; our platform’s design (with codified rebuild processes and cloud agility) is tailored to quick recovery, thus supporting those obligations. Additionally, post-incident analysis is facilitated by the platform (all actions taken during response are logged, which can feed into the lessons-learned that DORA would expect firms to document). DORA also requires that these plans be updated continuously - as we mentioned under NIST CSF, the platform’s adaptability allows the firm to refine recovery playbooks after simulations or real incidents. Thus, on the resilience front, the AKS platform is a strong asset for DORA compliance: it inherently provides redundancy and rapid restoration, and it enables the ongoing testing and improvement that DORA mandates.
• Threat-Led Penetration Testing (TLPT): For significant financial institutions, DORA will require periodic TLPT (essentially, advanced red-team exercises). Hosting applications on AKS does not exempt them from testing; instead, the platform should be part of the scope. The platform’s benefit is that it has well-defined interfaces and logs that make such testing more effective (the red team can be given a test Azure AD account with specific roles to see if they can escalate privileges, for example). After such tests, any identified weaknesses (maybe a misconfigured role or a container with a known exploit) can be swiftly remediated thanks to the IaC approach (update the config in Git and Argo CD will correct it). This agility helps meet DORA’s expectations that issues found in testing are promptly addressed. Moreover, the fact that Azure itself is prepared to undergo supervision by regulators⁵⁰ means the platform likely already meets high security standards - a well-configured AKS should fare well in TLPT, giving comfort to both the entity and regulators.
• ICT Third-Party Risk Management: DORA has specific requirements for managing risk from ICT third-party providers (like cloud services). The use of Azure (and its ecosystem) means the organization must comply with those by, for instance, maintaining a register of all ICT third-party contracts and ensuring certain clauses are in contracts (DORA Article 28-30 cover contractual provisions). Microsoft has provided a “contractual mapping for DORA”⁵¹ and ensures its cloud contracts include the necessary provisions (e.g., cooperation with regulators, access to security reports)⁵². By using Azure’s standard agreements and perhaps the special Financial Services Addendum, the organization likely meets these contract requirements. Technically, the AKS platform allows for exit strategies to be developed (a DORA requirement is to have plans if a third-party provider fails or needs replacement). Since everything is in code and data can be exported, the firm could, in theory, migrate workloads to another environment if needed - this portability is an important consideration in third-party risk. In terms of concentration risk, the platform’s ability to run in multiple regions (or even multiple clouds via Kubernetes’ abstraction) can be cited as a mitigating factor in the firm’s DORA ICT risk assessments. Finally, Azure’s commitment to direct oversight by EU regulators (for critical providers) means that by using Azure, the firm is indirectly under that oversight too, which should satisfy regulatory expectations. The AKS platform’s security posture - leveraging Azure’s strengths - will be a positive point in any regulatory examination of ICT third-party risk.

In conclusion, while DORA is regulatory (with articles rather than technical controls), the Azure AKS platform significantly aids compliance with its requirements. It provides the technical means to implement a robust ICT risk management and resilience framework, from preventing incidents with strong security controls to detecting and responding when they occur, and recovering systems quickly. The platform aligns with DORA’s core objectives: ensuring the firm can “withstand and adapt to disruptions, including cyberattacks”⁵³. Any overlaps between DORA and NIS2/NIST/ISO have been leveraged - for example, the same logging and incident processes that meet ISO/NIS2 also meet DORA. One area to highlight is that DORA also requires extensive governance oversight (e.g., board approval of ICT risk framework) - the existence of this secure AKS platform should be part of the firm’s ICT strategy presented to leadership for approval, thereby integrating with DORA’s governance expectations. The crosswalk table below will summarize how specific AKS platform features map to the various frameworks, including DORA articles where applicable.

Crosswalk of AKS platform features

The following table provides a high-level mapping of key Azure AKS platform features to the relevant control domains or specific control references in ISO 27001, NIS2, NIST CSF 2.0, and DORA:

KS Platform Feature	ISO/IEC 27001 (Annex A control)	NIS2 Directive (Article 21 measure)	NIST CSF 2.0 (Category/Subcategory)	DORA (Key Article/Requirement)
Private AKS API Endpoint AKS API server accessible only via internal network (no public IP).	A.13.1 - Network security controls (segregation of networks; reduce external exposure) A.9.4 - Secure log-on (restrict access channels)	(i) Access control policies & asset management - ensuring secure network access to critical systems	PR.AC-5 - Network integrity is protected (network segmentation) PR.PT-4 - Communications networks are protected (no unauthorized access)	Art. 10 (Detection) - Reduces attack surface for detection of anomalies ICT risk mgmt - “ensure security of networks and systems” by limiting exposure
Network Segmentation & Azure Firewall Isolated VNets, NSGs, and Azure Firewall controlling traffic.	A.13.1 - Network security (segmentation, controlled gateways) A.13.2 - Security of network services (firewalls, filtering)	(a) Risk mgmt policies - includes network security measures (d) Supply chain - secure network relationships with providers	PR.PT-3 - Least functionality (only required ports/protocols open) DE.CM-1 - Network monitored for events (firewall logging)	Art. 8 - ICT risk mgmt: use of appropriate network protection tools Art. 13 - Ensure integrity of network by preventing unauthorized flows (firewall as control)
Web Application Firewall (WAF) Protecting web apps against OWASP Top 10 attacks.	A.13.2.1 - Network service security (application-layer controls) A.14.2.5 - Secure system engineering (secure coding - WAF as compensating control)	(e) Secure development & maintenance - handles vulnerabilities (WAF shields against exploits)	PR.PT-1 - Audit/log records (WAF logs attacks)  PR.DS-6 - Integrity of system and data verified (WAF ensures input validation)  DE.CM-7 - Monitoring for unauthorized code (WAF identifies malicious inputs)	Art. 10 - Detection: promptly detect web attacks (WAF provides automated detection) Art. 11 - Response: WAF rules can be incident response measures to mitigate ongoing attacks
Azure AD RBAC & Managed Identities Azure AD for user auth, RBAC for authZ; managed identities for services.	A.9.2 - User access management (user provisioning via AD) A.9.3 - User responsibilities (unique IDs via AAD) A.9.4.1 - Restricted privileged access	(i) Access control policies - enforce least privilege, MFA (g) Basic hygiene - strong authentication for admins	PR.AC-1 - Identities and credentials managed (AAD integration) PR.AC-4 - Access permissions managed (RBAC least privilege)  PR.AC-7 - Users authenticated (MFA enforced)  PR.DS-5 - Protections against data leakage (no hard-coded creds)	Art. 5 - ICT risk mgmt: internal controls for access to ICT systems Art. 21(j) - Use of multi-factor authentication for access where appropriate (AAD MFA) ICT third-party risk - managed identities reduce need to share credentials with vendors
GitOps with Argo CD (Infrastructure as Code) Declarative config and automated deployment via Git.	A.12.1.2 - Change management (controlled via Git PRs) A.14.2.2 - System change control (version-controlled config) A.16.1.7 - Learning from incidents (post-mortem changes via code)	(d) Supply chain security - verifiable and auditable code deployment (e) Secure development - IaC enforces secure configs (f) Effectiveness assessment - easy auditing of changes	PR.IP-3 - Configuration change control in place (GitOps pipeline)  PR.IP-1 - Secure development lifecycle (code reviews in Git)  DE.CM-3 - Personnel activity monitored (all changes are logged in Git)	Art. 6 - Governance: change management as part of internal control Art. 8 - ICT tools: use of automation for consistency and quick recovery Art. 20 - ICT change management (implicitly satisfied by documented GitOps process)
Logging and Monitoring (Azure Monitor & Defender) Centralized collection of AKS logs, Azure activity logs, metrics; security alerts.	A.12.4.1 - Event logging (K8s audit, Azure logs collected) A.12.4.3 - Administrator log monitoring (Azure AD sign-in logs) A.16.1.2 - Incidents reported (via alerting tools)	(b) Incident handling - requires detection & monitoring (f) Assess effectiveness - continuous monitoring of control status (j) Secure communications - monitoring of comms systems for abuse	DE.CM-1 - Network monitored (Azure NSG/Firewall logs) DE.CM-8 - Vulnerability monitoring (Defender scans images/nodes)  RS.CO-2 - Incident notifications communicated (alerts to on-call)	Art. 10 - Detection: “mechanisms to promptly detect anomalous activities” (achieved via Azure Monitor alerts) Art. 11 - Response: monitoring triggers incident response processes Art. 15 - Logging requirements (complete and tamper-proof logs for critical systems)
Azure Key Vault (Secrets & Keys) Central secure storage for secrets, keys, certificates; supports key rotation.	A.10.1 - Cryptographic controls (secure key management) A.8.2.3 - Handling of secrets (Key Vault controls access and lifecycle) A.12.5.1 - Change control of assets (keys rotated per policy)	(h) Cryptography & encryption policies - centralized key management, encryption everywhere (d) Supply chain - safeguard CI/CD secrets (no plaintext secrets in code)	PR.DS-1 - Data-at-rest protected (via encryption keys in KV) PR.AC-1 - Credentials managed (no hard-coded passwords, use KV)  DE.CM-3 - Monitoring of privileged access (KV access logs track secret use)	Art. 8 - ICT risk mgmt: requires policies for crypto (KV enforces them) Art. 21(h) - Use of strong cryptography and encryption (KV enables HSM-backed crypto) Art. 10 - Detection: KV logs help detect misuse of credentials or keys
Azure SQL (Managed Database) Managed PaaS database with TDE, network isolation, and auditing enabled.	A.13.1.3 - Segregation in networks (DB accessible only via Private Link/authorized apps) A.12.4.1 - Logging (DB auditing of queries)(A.10.1.1 - Policy on crypto (TDE encryption of data)	(c) Business continuity - automated backups, geo-redundancy for DB (h) Encryption - TDE protects data at rest; TLS in transit (b) Incident handling - SQL threat detection alerts (Azure Defender)	PR.DS-1 - Data-at-rest protected (TDE) DE.CM-1 - Monitoring of networks (SQL logs and firewall)  PR.PT-1 - Audit logs implemented (SQL Auditing tracks access)	Art. 11 - Recovery: critical data stores have backups and rapid restore Art. 10 - Detection: DBms have mechanisms to detect anomalies (SQL Threat Detection) ICT third-party risk: relying on Azure SQL’s resilience and certs (Azure provides audit reports on SQL)
High Availability & Backup Multi-AZ AKS nodes, automated backups (DB and state), and DR plans.	A.17.2 - Redundancies (AZ redundancy for infrastructure) A.17.1 - Planning for continuity (documented AKS DR plan)	(c) Business continuity & DR - multi-zone cluster, backups, tested DR procedures	ID.BE-5 - Resilience requirements for critical services identified  RC.RP-1 - Recovery plan executed (IaC redeploy)  RC.IM-1 - Lessons learned improve recovery (after DR tests)	Art. 11 - “quickly recover and restore availability” - multi-AZ and backups satisfy this Art. 13 - Regular testing of BC plans (the firm conducts DR drills on AKS) Art. 5 - Risk mgmt: includes disaster recovery strategies in ICT framework
Continuous Compliance & Governance Azure Policy, Security Center benchmarks, compliance reporting.	A.5.1.1 - Policies for information security (translated into Azure Policy rules) A.15.2.1 - Compliance with security policies (monitored via Azure Secure Score)	(f) Effectiveness assessment - Azure Policy checks controls, reports compliance (a) Risk analysis - feed Secure Score results into risk process	GV.ME (Governance - Risk management evaluations) ID.GV-3 - Legal and regulatory requirements understood (Azure compliance offerings used)  PR.IP-8 - Vulnerability management plan (ASC recommendations used)	Art. 5 & 6 - Governance: board oversight using metrics (Azure Secure Score, etc.) Art. 14 - Ongoing monitoring: “track compliance of ICT systems” (Azure Compliance Manager provides DORA mapping) Oversight: evidence for regulators (Azure audit reports, etc.)

Notes: This matrix shows that each major feature of the Azure AKS platform contributes to multiple compliance objectives. For instance, “Private AKS API” helps satisfy ISO network security controls, NIS2 access control requirements, NIST CSF network protection subcategories, and DORA’s general principle of minimizing attack surfaces for critical ICT. Similarly, enabling logging and auditing is a cross-cutting control that underpins ISO Annex A.12 (logging), NIS2 incident handling, NIST Detect/Respond, and DORA’s incident detection and reporting mandates. The overlapping nature of these mappings means implementing one strong control often addresses several frameworks at once - an efficiency the AKS platform design leverages.

Overlap and gap analysis

Overlaps and synergies

As evidenced in the mapping above, there is significant overlap in the security principles demanded by ISO 27001, NIS2, NIST CSF, and DORA. Identity and access management, for example, is a common theme: a single configuration (Azure AD with RBAC and MFA) simultaneously addresses ISO Annex A.9, NIS2 point (i) and (j), NIST PR.AC subcategories, and DORA’s emphasis on access control in risk management. This consolidation is beneficial - the AKS platform’s unified IAM approach means the organization can meet multiple compliance obligations without duplicate effort. Another example is encryption and key management: by using Azure Key Vault and enforcing encryption everywhere, the organization ticks the box for ISO’s cryptography control, NIS2’s encryption policy, NIST’s data security category, and DORA’s requirement to protect data and ensure integrity of services. Logging and monitoring provide a similar synergy, feeding both NIST Detect/Respond and the reporting needs under NIS2/DORA. The use of frameworks like GitOps not only gives technical consistency but also inherently provides documentation and audit trails, satisfying both technical control requirements and governance needs. For the CISO/CIO, these overlaps mean investments in one area of the platform yield compliance dividends across all frameworks - a strong justification for the chosen architecture. It also simplifies audit preparation: evidence such as Azure AD access reviews or Azure Policy compliance scores can be presented to ISO auditors, NIS2 supervisory authorities, and internal audit for CSF maturity assessments alike. The mapping shows that the AKS platform, with its features, creates a harmonized control environment that aligns well with the shared goals of these standards: securing data, controlling access, ensuring resilience, and monitoring for threats.

Gaps and mitigation

While the AKS platform covers many technical controls, there are areas that require attention to fully satisfy all aspects of the frameworks, especially where requirements go beyond purely technical measures:

• Policy Documentation and Human Processes: Frameworks like ISO 27001 and DORA require formal policies, senior management oversight, and human-centric processes (e.g., security awareness training in NIS2, governance in DORA). The AKS platform itself cannot create policies or conduct trainings - those remain a gap for the organization to fill. Mitigation: The organization should develop and maintain policies (access control policy, incident response plan, crypto policy, etc.) that explicitly reference how the AKS platform’s configurations enforce those policies. Likewise, a training program should be in place to educate DevOps teams on secure use of Kubernetes and Azure (tying in platform specifics to general security training). These actions will complement the platform, ensuring that people and process controls keep up with the platform’s technical controls.
• Incident Response Drill and Reporting Practice: While the platform provides detection and data, practicing the incident response process is crucial to meet strict reporting timelines (especially under DORA’s 24-hour initial notification rule). If the team is not experienced in handling cloud-centric incidents, there’s a gap in operational readiness. Mitigation: Conduct regular incident response drills specifically on the AKS platform (e.g., a simulated container breach) to exercise end-to-end response - detection, containment, recovery, and reporting. This will highlight any toolset gaps (perhaps the need for faster log analysis tools or runbooks for isolating compromised pods) which can then be addressed. Additionally, establish clear procedures for assembling incident information from Azure (log exports, Azure Security Center incident reports) to speed up regulatory reporting if needed.
• Continuous Compliance Monitoring: Although Azure provides tools like Defender for Cloud and Policy, they must be properly configured to continuously check compliance against each framework’s requirements. Any lapse in these configurations could be a gap (for instance, if a new AKS cluster is created and the Policy assignments are not applied, it might drift from compliance). Mitigation: Use Azure Blueprints or Deployment Stamps to enforce that any new environment mirrors the security baseline of this platform. Enable Azure Arc or other multi-environment governance to ensure even if workloads extend beyond this one cluster, the same controls apply (relevant if the organization has multiple AKS clusters or hybrid setups). Regularly review the compliance dashboard for ISO 27001 and NIST CSF in Defender for Cloud⁵⁴⁵⁵ and ensure any “unavailable” or “red” controls are addressed promptly. Essentially treat compliance as a continuous process, not a point-in-time task.
• Supply Chain and Change Management Nuances: The GitOps approach covers infrastructure changes well, but the application development lifecycle (code quality, dependency vulnerabilities) also falls under compliance scrutiny (NIS2 and DORA expect software development to be secured). If not already in place, there’s a gap in demonstrating that the container images deployed to AKS are free of known vulnerabilities and that code is developed per secure coding guidelines. Mitigation: Integrate DevSecOps tools - e.g., static code analysis, dependency scanning (SCA), container image scanning - into the CI/CD pipeline. Use Azure Container Registry’s vulnerability scanning or third-party scanners to generate reports mapping to known CVEs. This will enhance supply chain security and provide evidence for NIS2 (e) and DORA’s expectations of secure development practices. In addition, implement signing of container images and perhaps verification in the cluster (e.g., using admission controllers) to further ensure only trusted artifacts run in AKS. These measures fill the gap in demonstrating end-to-end software supply chain integrity.
• Third-Party Services and Integrations: The AKS platform likely uses or will use other Azure services (e.g., App Gateway for WAF, Azure DevOps or GitHub for CI, possibly third-party OSS within containers). Each introduces potential compliance considerations (data residency, access logs, etc.). If not catalogued, it’s a gap in the asset management and third-party risk viewpoint. Mitigation: Maintain a central registry of all services the platform relies on (including external APIs, plugins, etc.), and for each, ensure there is a vendor risk assessment or at least confirmation of their compliance posture. For example, if using GitHub Actions for CI, confirm GitHub’s security measures and how code secrets are handled, as that could be a question under NIS2 supply chain security. For DORA, ensure contracts or terms of service with these providers include necessary clauses or that alternative controls are in place (if GitHub, not under direct contract, ensure data from GitHub is pulled into Azure for logging, etc., to maintain control).
• Physical and Environmental Security: One aspect of ISO 27001 (Annex A.11) and NIS2 (which mentions physical environment in Article 21(2)) is physical security of information processing facilities. In a pure Azure cloud deployment, physical security is managed by Microsoft’s data centers (with certifications and audits to ISO 27001, SOC1/2, etc.). This could be seen as a gap only in that the organization must document reliance on Azure for physical controls in their ISO scope and ensure that Azure’s compliance reports are obtained. Mitigation: Obtain Azure’s SOC and ISO audit reports and map Azure’s physical security controls to ISO A.11 controls in the organization’s compliance documentation. This demonstrates that while the org doesn’t control the data center, it has verified that adequate controls are in place (which in fact they are, given Azure’s certifications).
• Emerging Requirements (Continuous Authentication, etc.): NIS2 and modern frameworks hint at “continuous authentication” or advanced concepts (zero trust). The AKS platform as configured relies on point-in-time MFA but does not yet implement continuous monitoring of user behavior for session risk. Mitigation: Consider enabling Azure AD’s advanced features like Conditional Access with risk-based policies or Azure AD Identity Protection to continuously assess user risk during sessions. This can address the “continuous authentication” aspect by challenging users again if their risk level changes (for instance, if an admin’s credentials appear in a leak). Similarly, evaluate behavioral monitoring inside the cluster (tools that baseline process activity in containers) for continuous anomaly detection. While not explicitly mandated, these enhancements prepare the organization for future iterations of standards and further reduce risk.

Overall, the gaps identified are not so much failures of the AKS platform, but reminders that compliance is a combination of technology, people, and process. The AKS platform significantly narrows the gap on the technology front by providing strong security controls out-of-the-box, leaving fewer but important tasks for the organization to address through governance and process. By implementing the suggested mitigations - formalizing policies, enhancing DevSecOps, practicing IR, and leveraging Azure’s governance capabilities - the organization can close these gaps.

Assurance

From a CISO/CIO perspective, the current state of the AKS platform delivers a high degree of alignment with the required frameworks, meaning lower risk of non-compliance findings and, more importantly, a strong security posture for the organization’s cloud workloads. The overlaps across frameworks imply that the security investments are maximally utilized, and the remaining gaps are well-understood and being actively managed. It is also noteworthy that Microsoft, as the cloud provider, is undertaking significant compliance responsibilities (as indicated for DORA⁵⁶), thereby reducing the compliance burden on the organization - this partnership should be highlighted in discussions with regulators or auditors. The AKS platform and its surrounding controls can thus be presented as a key component of the organization’s ISMS (for ISO 27001), its NIS2 compliance program, its NIST CSF-based cybersecurity program, and its operational resilience strategy under DORA.

Compliance is “baked in”

In conclusion, the Azure AKS platform - configured with private networking, robust access control, secure deployment pipelines, comprehensive logging, and integrated Azure security services - maps exceptionally well to the control requirements of ISO 27001, NIS2, NIST CSF 2.0, and DORA. Each dedicated section above illustrates that the platform’s features are not just generic best practices but are directly traceable to formal control objectives: from ISO 27001 Annex A controls like access management, encryption, operations security and continuity, to NIS2’s mandated measures on risk management, incident response, and supply chain; from the granular subcategories of the NIST CSF spanning Identify through Recover, to the high-level resilience and governance expectations of DORA. The crosswalk table provided consolidates these mappings and demonstrates broad coverage.

For the security and IT leadership, this mapping provides assurance that the chosen technical architecture is aligned with international standards and regulations - a critical consideration in regulated industries and for maintaining trust with customers and regulators. The exercise of mapping also surfaces where the platform strengthens compliance (e.g., automatic encryption everywhere greatly simplifies meeting regulatory requirements), and where the organization must augment technology with policy (e.g., training, vendor management).

By leveraging Azure’s compliance-ready services and by adhering to infrastructure-as-code and zero-trust principles, the organization turns compliance from a paperwork challenge into an operational outcome of the system’s design. In effect, compliance is “baked in” to the Azure AKS platform. This integrated approach means that as the threat landscape evolves or as audits occur, the organization can be confident that its core platform is both secure and demonstrably compliant with the rigorous demands of ISO 27001, NIS2, NIST CSF 2.0, and DORA. The leadership should continue to support such architectural choices and ensure that governance processes keep pace, thereby maintaining a strong security posture and meeting all regulatory obligations in the digital operational environment.

---

1. https://learn.microsoft.com/en-us/azure/aks/concepts-security#:~:text=By%20default%2C%20the%20Kubernetes%20API,access%20to%20your%20virtual%20network ↩

2. https://learn.microsoft.com/en-us/azure/aks/concepts-security#:~:text=You%20can%20control%20access%20to,Microsoft%20Entra%20integration%20with%20AKS ↩

3. https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview-for-developers#:~:text=Azure%20resources%20with%20managed%20identities,an%20overview%20of%20managed%20identities ↩

4. https://learn.microsoft.com/en-us/azure/key-vault/keys/quick-create-portal#:~:text=Azure%20Key%20Vault%20is%20a,For%20more%20information%20on%20Key ↩

5. https://www.azadvertizer.net/azpolicyadvertizer/17k78e20-9358-41c9-923c-fb736d382a12.html#:~:text=Description%20Transparent%20data%20encryption%20should,Assessment%28s%29%20Assessments%20count%3A%201 ↩

6. https://www.armosec.io/blog/gitops-for-kubernetes-security-and-compliance/#:~:text=Audit%20trail ↩

7. https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AKS.AuditLogs/#:~:text=2021_09%20%C2%B7%20%20Important ↩

8. https://learn.microsoft.com/en-us/azure/aks/concepts-security#:~:text=By%20default%2C%20the%20Kubernetes%20API,access%20to%20your%20virtual%20network ↩

9. https://learn.microsoft.com/en-us/azure/firewall/basic-features#:~:text=Network%20traffic%20filtering%20rules ↩

10. https://learn.microsoft.com/en-us/azure/firewall/basic-features#:~:text=Threat%20intelligence ↩

11. https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview#:~:text=The%20Azure%20Web%20Application%20Firewall,site%20scripting ↩

12. https://learn.microsoft.com/en-us/azure/azure-local/assurance/azure-stack-iso27001-guidance?view=azloc-2504#:~:text=Azure%20Local%20provides%20deep%20integration,compliance%20offerings%20%E2%80%93%20ISO%2FIEC%2027001%3A2022 ↩

13. https://learn.microsoft.com/en-us/azure/azure-local/assurance/azure-stack-iso27001-guidance?view=azloc-2504#:~:text=the%20hybrid%20environment,compliance%20offerings%20%E2%80%93%20ISO%2FIEC%2027001%3A2022 ↩

14. https://learn.microsoft.com/en-us/azure/azure-local/assurance/azure-stack-iso27001-guidance?view=azloc-2504#:~:text=Important ↩

15. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=In%20addition%20to%20establishing%20clear,institutions%20meet%20their%20own%20requirements ↩

16. https://learn.microsoft.com/en-us/azure/firewall/basic-features#:~:text=Availability%20Zones ↩

17. https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html#:~:text=,and%20information%20system%20security ↩

18. https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html#:~:text=,and%20information%20system%20security ↩

19. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=,risk%20management ↩

20. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=Microsoft%20already%20provides%20a%20broad,in%20our%20services%20today%2C%20including ↩

21. https://www.digital-operational-resilience-act.com/Article_10.html#:~:text=1,material%20single%20points%20of%20failure ↩

22. https://www.digital-operational-resilience-act.com/Article_10.html#:~:text=2,related%20incident%20response ↩

23. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=In%20addition%20to%20establishing%20clear,institutions%20meet%20their%20own%20requirements ↩

24. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=1,laws%20and%20regulations%20applicable%20to ↩

25. https://www.armosec.io/blog/gitops-for-kubernetes-security-and-compliance/#:~:text=Audit%20trail ↩

26. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=Microsoft%20already%20provides%20a%20broad,in%20our%20services%20today%2C%20including ↩

27. https://learn.microsoft.com/en-us/azure/key-vault/keys/quick-create-portal#:~:text=Azure%20Key%20Vault%20is%20a,For%20more%20information%20on%20Key ↩

28. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication#:~:text=%28MFA%29%20learn,requirement%2C%20see%20our%20blog%20post ↩

29. https://www.azadvertizer.net/azpolicyadvertizer/17k78e20-9358-41c9-923c-fb736d382a12.html#:~:text=Description%20Transparent%20data%20encryption%20should,Assessment%28s%29%20Assessments%20count%3A%201 ↩

30. https://learn.microsoft.com/en-us/azure/governance/policy/samples/iso-27001#:~:text=Regulatory%20Compliance%20details%20for%20ISO,them%20in%20an%20audit%20log ↩

31. https://www.azadvertizer.net/azpolicyadvertizer/17k78e20-9358-41c9-923c-fb736d382a12.html#:~:text=Description%20Transparent%20data%20encryption%20should,Assessment%28s%29%20Assessments%20count%3A%201 ↩

32. https://learn.microsoft.com/en-us/azure/firewall/basic-features#:~:text=Network%20traffic%20filtering%20rules ↩

33. https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview#:~:text=The%20Azure%20Web%20Application%20Firewall,site%20scripting ↩

34. https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AKS.AuditLogs/#:~:text=2021_09%20%C2%B7%20%20Important ↩

35. https://learn.microsoft.com/en-us/azure/aks/concepts-security#:~:text=You%20can%20control%20access%20to,Microsoft%20Entra%20integration%20with%20AKS ↩

36. https://www.azadvertizer.net/azpolicyadvertizer/17k78e20-9358-41c9-923c-fb736d382a12.html#:~:text=Description%20Transparent%20data%20encryption%20should,Assessment%28s%29%20Assessments%20count%3A%201 ↩

37. https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AKS.AuditLogs/#:~:text=2021_09%20%C2%B7%20%20Important ↩

38. https://learn.microsoft.com/en-us/azure/firewall/basic-features#:~:text=Network%20traffic%20filtering%20rules ↩

39. https://azure.github.io/PSRule.Rules.Azure/en/rules/Azure.AKS.AuditLogs/#:~:text=2021_09%20%C2%B7%20%20Important ↩

40. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=The%20Digital%20Operational%20Resilience%20Act,provided%20by%20third%20party%20providers ↩

41. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=,the%20competent%20authorities%20as%20required ↩

42. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=,and%20criteria%20to%20trigger%20and ↩

43. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=,risk%20management ↩

44. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=In%20addition%20to%20establishing%20clear,institutions%20meet%20their%20own%20requirements ↩

45. https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html#:~:text=3,1 ↩

46. https://www.digital-operational-resilience-act.com/Article_10.html#:~:text=1,material%20single%20points%20of%20failure ↩

47. https://www.digital-operational-resilience-act.com/Article_10.html#:~:text=single%20points%20of%20failure ↩

48. https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html#:~:text=,disaster%20recovery%2C%20and%20crisis%20management ↩

49. https://www.nis-2-directive.com/NIS_2_Directive_Article_21.html#:~:text=,and%20information%20system%20security ↩

50. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=DORA%20provides%20European%20Supervisory%20Authorities,institutions%20meet%20their%20own%20requirements ↩

51. https://learn.microsoft.com/en-us/compliance/assurance/assurance-fsi-resilience#:~:text=Strengthening%20operational%20resilience%20and%20reducing,In ↩

52. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=5,such%20guidance%20itself%20serves%20as ↩

53. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=DORA%20aims%20to%20provide%20a,stock%20exchanges%2C%20and%20trading%20platforms ↩

54. https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-regulatory-compliance-standards#:~:text=The%20following%20standards%20are%20available,in%20Defender%20for%20Cloud ↩

55. https://learn.microsoft.com/en-us/azure/defender-for-cloud/concept-regulatory-compliance-standards#:~:text=CIS%20Azure%20Kubernetes%20Service%20,27001%3A2022%20%20Azure%2C%20AWS%2C%20GCP ↩

56. https://learn.microsoft.com/en-us/compliance/dora/dora-what-is-dora#:~:text=In%20addition%20to%20establishing%20clear,institutions%20meet%20their%20own%20requirements ↩