Complex enterprise governance: Best practices explained

The governance guide begins with a set of initial corporate policies. These policies establish a minimum viable product (MVP) for governance that reflects best practices.

This article describes the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the Deployment Acceleration discipline. At this stage, the tools and patterns that you apply can support incremental improvements to expand governance in the future.

Governance MVP (initial governance foundation)

You can achieve rapid adoption of governance and corporate policy, thanks to a few principles and cloud-based governance tooling. The following disciplines are the first of the three governance disciplines to use in any governance process. Each discipline is then explored further on in this article.

To establish the starting point, you'll learn about the high-level strategies behind the Security Baseline, Identity Baseline, and Deployment Acceleration disciplines that are required to create a governance MVP. The MVP serves as the foundation for all cloud adoption.

Diagram showing an example of an incremental governance MVP.

Implementation process

Implementing the governance MVP has dependencies on identity, security, and networking. After you resolve the dependencies, the cloud governance team decides on several aspects of the governance. The decisions from the cloud governance team and from other supporting teams result in a single package of enforcement assets.

Diagram showing the implementation process of a governance MVP.

The following checklist describes the implementation process:

  1. Solicit decisions regarding core dependencies: identity, network, and encryption.
  2. Determine the pattern to use during corporate policy enforcement.
  3. Determine the appropriate governance patterns for resource consistency, resource tagging, and logging and reporting.
  4. Implement the governance tools aligned to the chosen policy enforcement pattern to apply the dependent decisions and governance decisions.

Dependent decisions

The following decisions come from teams outside of the cloud governance team. The implementation of each will come from those same teams. However, the cloud governance team is responsible for implementing a solution to validate that those implementations are consistently applied.

Identity Baseline

Identity Baseline is the fundamental starting point for all governance. Before attempting to apply governance, identity must be established. The established identity strategy will then be enforced by the governance solutions. In this governance guide, the Identity Management team implements the Directory Synchronization pattern:

  • RBAC will be provided by Microsoft Entra ID, using the directory synchronization or "same sign-on" that was implemented during company's migration to Microsoft 365. For implementation guidance, see Reference Architecture for Microsoft Entra Integration.
  • The Microsoft Entra tenant will also govern authentication and access for assets deployed to Azure.

In the governance MVP, the governance team will enforce application of the replicated tenant through subscription governance tooling, discussed later in this article. In future iterations, the governance team could also enforce rich tooling in Microsoft Entra ID to extend this capability.

Security Baseline: Networking

Software Defined Network is an important initial aspect of the Security Baseline. Establishing the governance MVP depends on early decisions from the Security Management team to define how networks can be safely configured.

Given the lack of requirements, IT security is playing it safe and requires a Cloud DMZ pattern. That means governance of the Azure deployments themselves will be very light.

  • Azure subscriptions may connect to an existing datacenter via VPN, but must follow all existing on-premises IT governance policies regarding connection of a perimeter network to protected resources. For implementation guidance regarding VPN connectivity, see On-premises network connected to Azure using a VPN gateway.
  • Decisions regarding subnet, firewall, and routing are currently being deferred to each application/workload lead.
  • Additional analysis is required before releasing of any protected data or mission-critical workloads.

In this pattern, cloud networks can only connect to on-premises resources over an existing VPN that is compatible with Azure. Traffic over that connection will be treated like any traffic coming from a perimeter network. Additional considerations may be required on the on-premises edge device to securely handle traffic from Azure.

The cloud governance team has proactively invited members of the networking and IT security teams to regular meetings, in order to stay ahead of networking demands and risks.

Security Baseline: Encryption

Encryption is another fundamental decision within the Security Baseline discipline. Because the company currently does not yet store any protected data in the cloud, the Security Team has decided on a less aggressive pattern for encryption. At this point, a cloud-native pattern for encryption is suggested but not required of any development team.

  • No governance requirements have been set regarding the use of encryption, because the current corporate policy does not permit mission-critical or protected data in the cloud.
  • Additional analysis will be required before releasing any protected data or mission-critical workloads.

Policy enforcement

The first decision to make regarding Deployment Acceleration is the pattern for enforcement. In this narrative, the governance team decided to implement the Automated Enforcement pattern.

  • Azure Security Center will be made available to the security and identity teams to monitor security risks. Both teams are also likely to use Security Center to identify new risks and improve corporate policy.
  • RBAC is required in all subscriptions to govern authentication enforcement.
  • Azure Policy will be published to each management group and applied to all subscriptions. However, the level of policies being enforced will be very limited in this initial Governance MVP.
  • Although Azure management groups are being used, a relatively simple hierarchy is expected.
  • Azure Blueprints will be used to deploy and update subscriptions by applying RBAC requirements, Resource Manager Templates, and Azure Policy across management groups.

Apply the dependent patterns

The following decisions represent the patterns to be enforced through the policy enforcement strategy above:

Identity Baseline. Azure Blueprints will set RBAC requirements at a subscription level to ensure that consistent identity is configured for all subscriptions.

Security Baseline: Networking. The cloud governance team maintains a Resource Manager template for establishing a VPN gateway between Azure and the on-premises VPN device. When an application team requires a VPN connection, the cloud governance team will apply the gateway Resource Manager template via Azure Blueprints.

Security Baseline: Encryption. At this point, no policy enforcement is required in this area. This will be revisited during later iterations.

Application of governance-defined patterns

The cloud governance team is responsible for the following decisions and implementations. Many decisions require input from other teams, but the cloud governance team likely owns both the decisions and implementation. The following sections outline the decisions to make for this use case and details of each decision.

Subscription design

The decision on what subscription design to use determines how Azure subscriptions are structured and how to use Azure management groups to efficiently manage the access, policies, and compliance for the subscriptions. Refer to the subscription organization and governance recommendations for a thorough review of subscription design recommendations.

  • As new requests for Azure resources arise, establish a department for each major business unit in each operating geography. Within each of the departments, create subscriptions for each application archetype.

  • An application archetype is a means of grouping applications with similar needs. Common examples include:

    • Applications with protected data and governed applications (such as HIPAA or FedRAMP)
    • Low-risk applications
    • Applications with on-premises dependencies
    • SAP or other mainframe applications in Azure
    • Applications that extend on-premises SAP or mainframe applications

    Each organization has unique needs based on data classifications and the types of applications that support the business. Dependency mapping on the digital estate helps define your organization's application archetypes.

  • Adopt a common naming convention as part of the subscription design, based on the previous information.

Resource consistency

Your resource consistency decisions determine the tools, processes, and efforts required to ensure you configure, deploy, and manage Azure resources consistently within a subscription. In this narrative, deployment consistency is the primary resource consistency pattern.

  • Create resource groups for applications using the lifecycle approach. Everything that's created, maintained, and retired together should reside in a single resource group. For more information, see the resource consistency decision guide.
  • Apply Azure Policy to all subscriptions from the associated management group.
  • As part of the deployment process, store Azure resource consistency templates for the resource group in source control.
  • Each resource group is associated with a specific workload or application based on the lifecycle approach described previously.
  • Azure management groups let you update governance designs as corporate policy matures.
  • Extensive implementation of Azure Policy could exceed the team's time commitments and might not provide a great deal of value at this time. Create a default policy and apply it to each management group to enforce the small number of current cloud governance policy statements. This policy defines the implementation of specific governance requirements. You can apply those implementations across all deployed assets.

Important

Any time a resource in a resource group no longer shares the same lifecycle, move it to another resource group. Examples include common databases and networking components. While they might serve the application being developed, they might also serve other purposes and should therefore exist in other resource groups.

Resource tagging

Resource tagging decisions determine how metadata applies to Azure resources within a subscription to support operations, management, and accounting purposes. In this narrative, the accounting pattern is chosen as the default model for resource tagging.

  • Tag deployed assets with values for:
    • Department or billing unit
    • Geography
    • Data classification
    • Criticality
    • SLA
    • Environment
    • Application archetype
    • Application
    • Application owner
  • These values, along with the Azure management group and subscription associated with a deployed asset, drive governance, operations, and security decisions.

Logging and reporting

Logging and reporting decisions determine how you store log data. They also determine how the monitoring and reporting tools that keep IT staff informed on operational health are structured. In this narrative a hybrid monitoring pattern for logging and reporting is suggested, but not required for any development team at this point.

  • No governance requirements are currently set regarding the specific data points to be collected for logging or reporting purposes. It's specific to this fictional narrative and should be considered an antipattern. Determine and enforce logging standards as soon as possible.
  • More analysis is required before the release of any protected data or mission-critical workloads.
  • Before you support protected data or mission-critical workloads, you must grant the existing on-premises operational monitoring solution access to the workspace you use for logging. Applications must meet security and logging requirements associated with the use of that tenant, if the application is to be supported with a defined SLA.

Incremental governance processes

Some of the policy statements can't or shouldn't be controlled by automated tooling. Other policies require periodic effort from IT security and on-premises identity baseline teams. The cloud governance team needs to oversee the following processes to implement the last eight policy statements:

Corporate policy changes: The cloud governance team makes changes to the governance MVP design to adopt the new policies. The value of the governance MVP is that it lets you automatically enforce the new policies.

Adoption acceleration: The cloud governance team reviews deployment scripts across multiple teams. They maintain a set of scripts that serve as deployment templates. The cloud adoption and DevOps teams use the templates to more quickly define deployments. Those scripts contain the necessary requirements to enforce a set of governance policies with no extra effort from cloud adoption engineers. As the curators of these scripts, the cloud governance team can more quickly implement policy changes. As a result of script curation, the cloud governance team is the source of adoption acceleration, which creates consistency among deployments, without strictly forcing adherence.

Engineer training: The cloud governance team offers bimonthly training sessions and has created two videos for engineers. Both resources help engineers get up to speed quickly on the governance culture and learn how to do the deployments. The team is adding training assets to demonstrate the difference between production and nonproduction deployments, which helps engineers understand how the new policies affect adoption. The training ensures consistent deployments without strictly enforcing adherence.

Deployment planning: Before you deploy any asset containing protected data, the cloud governance team reviews deployment scripts to validate governance alignment. Existing teams with previously approved deployments are audited using programmatic tooling.

Monthly audit and reporting: Each month, the cloud governance team runs an audit of all cloud deployments to validate continued alignment to policy. When deviations are discovered, they're documented and shared with the cloud adoption teams. When enforcement doesn't risk a business interruption or data leak, the policies are automatically enforced. At the end of the audit, the cloud governance team compiles a report for the cloud strategy team and each cloud adoption team to communicate overall adherence to policy. The report is also stored for auditing and legal purposes.

Quarterly policy review: Each quarter, the cloud governance and cloud strategy teams meet to review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and observing usage patterns. The teams integrate approved policy changes into governance tooling during subsequent audit cycles.

Alternative patterns

If any of the patterns in this governance guide don't align with your requirements, you can explore the alternatives:

Next steps

After your cloud adoption team implements this guidance, they can proceed with a solid governance foundation. At the same time, the cloud governance team works to continually update the corporate policies and governance disciplines.

Both teams use the tolerance indicators to identify the next set of improvements required to continue supporting cloud adoption. The next step for the company is to do incremental improvements of their governance baseline in support of applications with legacy or third-party multifactor authentication requirements.