-
-
Large Enterprise
-
A governance journey for enterprises that own more than five datacenters and manage costs across multiple business units.
+
+
+
+
+
+
+
+
+
Large Enterprise
+
A governance guide for enterprises that own five or more datacenters and manage costs across multiple business units.
+
-
-
-
+
+
@@ -59,7 +59,7 @@ To start down an adoption path, choose one of the following journeys. Each journ
Adopting the cloud is a journey, not a destination. Along the way, there are clear milestones and tangible business benefits. However, the final state of cloud adoption is unknown when a company begins the journey. Cloud governance creates guardrails that keep the company on a safe path throughout the journey.
-These governance journeys describe the experiences of fictional companies, based on the journeys of real customers. Each journey follows the customer through the governance aspects of their cloud adoption.
+These governance guides describe the experiences of fictional companies, based on the journeys of real customers. Each journey follows the customer through the governance aspects of their cloud adoption.
### Establishing an end state
@@ -67,7 +67,7 @@ A journey without a target destination is just wandering. It’s important to es
![Infographic of the Cloud Adoption Framework governance model](../../_images/operational-transformation-govern-highres.png)
-The Cloud Adoption Framework governance model identifies key areas of importance during the journey. Each area relates to different types of risks the company must address as it adopts more cloud services. Within this framework, the governance journey identifies required actions for the Cloud Governance team. Along the way, each principle of the Cloud Adoption Framework governance model is described further. Broadly, these include:
+The Cloud Adoption Framework governance model identifies key areas of importance during the journey. Each area relates to different types of risks the company must address as it adopts more cloud services. Within this framework, the governance journey identifies required actions for the cloud governance team. Along the way, each principle of the Cloud Adoption Framework governance model is described further. Broadly, these include:
**Corporate policies:** Corporate policies drive cloud governance. The governance journey focuses on specific aspects of corporate policy:
@@ -91,18 +91,18 @@ Because governance requirements will evolve throughout the cloud adoption journe
An **incremental governance** approach empowers these traits. Incremental governance relies on a small set of corporate policies, processes, and tools to establish a foundation for adoption and governance. That foundation is called a **minimum viable product (MVP)**. An MVP allows the governance team to quickly incorporate governance into implementations throughout the adoption lifecycle. An MVP can be established at any point during the cloud adoption process. However, it’s a good practice to adopt an MVP as early as possible.
-The ability to respond rapidly to changing risks empowers the Cloud Governance team to engage in new ways. The Cloud Governance team can join the Cloud Strategy team as scouts, moving ahead of the cloud adoption teams, plotting routes, and quickly establishing guardrails to manage risks associated with the adoption plans. These just-in-time governance layers are known as **governance evolutions**. With this approach, governance strategy evolves one step ahead of the cloud adoption teams.
+The ability to respond rapidly to changing risks empowers the cloud governance team to engage in new ways. The cloud governance team can join the cloud strategy team as scouts, moving ahead of the cloud adoption teams, plotting routes, and quickly establishing guardrails to manage risks associated with the adoption plans. These just-in-time governance layers are known as **governance evolutions**. With this approach, governance strategy evolves one step ahead of the cloud adoption teams.
The following diagram shows a simple governance MVP and three governance evolutions. During the evolutions, additional corporate policies are defined to remediate new risks. The Deployment Acceleration discipline then applies those changes across each deployment.
![Example of Incremental Governance evolutions](../../_images/governance/incremental-governance-example.png)
> [!NOTE]
-> Governance is not a replacement for key functions such as security, networking, identity, finance, DevOps, or operations. Along the way, there will be interactions with and dependencies on members from each function. Those members should be included on the Cloud Governance team to accelerate decisions and actions.
+> Governance is not a replacement for key functions such as security, networking, identity, finance, DevOps, or operations. Along the way, there will be interactions with and dependencies on members from each function. Those members should be included on the cloud governance team to accelerate decisions and actions.
## Choosing a governance journey
-The journeys demonstrate how to implement a governance MVP. From there, each journey shows how the Cloud Governance team can work ahead of the cloud adoption teams as a partner to accelerate adoption efforts. The Cloud Adoption Framework governance model guides the application of governance from foundation through subsequent evolutions.
+The journeys demonstrate how to implement a governance MVP. From there, each journey shows how the cloud governance team can work ahead of the cloud adoption teams as a partner to accelerate adoption efforts. The Cloud Adoption Framework governance model guides the application of governance from foundation through subsequent improvements.
To begin a governance journey, choose one of the two options below. The options are based on synthesized customer experiences. The titles are based on the size of the enterprise for ease of navigation. However, the reader's decision may be more complex. The following tables outline the differences between the two options.
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md b/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md
index 133d6309f58..766ad14e5e4 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/best-practice-explained.md
@@ -15,9 +15,9 @@ ms.custom: governance
The governance journey starts with a set of initial [corporate policies](./initial-corporate-policy.md). These policies are used to establish a minimum viable product (MVP) for governance that reflects [best practices](./index.md).
-In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental evolutions needed to expand governance in the future.
+In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental improvements needed to expand governance in the future.
-## Governance MVP (Cloud Adoption Foundation)
+## Governance MVP (initial governance foundation)
Rapid adoption of governance and corporate policy is achievable, thanks to a few simple principles and cloud-based governance tooling. These are the first of the three governance disciplines to approach in any governance process. Each discipline will be explained further on in this article.
@@ -27,7 +27,7 @@ To establish the starting point, this article will discuss the high-level strate
## Implementation process
-The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the Cloud Governance team will decide a few aspects of governance. The decisions from the Cloud Governance team and from supporting teams will be implemented through a single package of enforcement assets.
+The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the cloud governance team will decide a few aspects of governance. The decisions from the cloud governance team and from supporting teams will be implemented through a single package of enforcement assets.
![Example of an incremental governance MVP](../../../_images/governance/governance-mvp-implementation-flow.png)
@@ -42,7 +42,7 @@ This implementation can also be described using a simple checklist:
## Application of governance-defined patterns
-The Cloud Governance team will be responsible for the following decisions and implementations. Many will require inputs from other teams, but the Cloud Governance team is likely to own both the decision and implementation. The following sections outline the decisions made for this use case and details of each decision.
+The cloud governance team will be responsible for the following decisions and implementations. Many will require inputs from other teams, but the cloud governance team is likely to own both the decision and implementation. The following sections outline the decisions made for this use case and details of each decision.
### Subscription design
@@ -88,19 +88,19 @@ Logging and reporting decisions determine how your store log data and how the mo
## Evolution of governance processes
-Some of the policy statements cannot or should not be controlled by automated tooling. Other policies will require periodic effort from IT Security and on-premises Identity Baseline teams. The Cloud Governance team will need to oversee the following processes to implement the last eight policy statements:
+Some of the policy statements cannot or should not be controlled by automated tooling. Other policies will require periodic effort from IT Security and on-premises Identity Baseline teams. The cloud governance team will need to oversee the following processes to implement the last eight policy statements:
-**Corporate policy changes:** The Cloud Governance team will make changes to the governance MVP design to adopt the new policies. The value of the governance MVP is that it will allow for the automatic enforcement of the new policies.
+**Corporate policy changes:** The cloud governance team will make changes to the governance MVP design to adopt the new policies. The value of the governance MVP is that it will allow for the automatic enforcement of the new policies.
-**Adoption acceleration:** The Cloud Governance team has been reviewing deployment scripts across multiple teams. They've maintained a set of scripts that serve as deployment templates. Those templates can be used by the cloud adoption teams and DevOps teams to more quickly define deployments. Each script contains the requirements for enforcing governance policies, and additional effort from cloud adoption engineers is not needed. As the curators of these scripts, they can implement policy changes more quickly. Additionally, they are viewed as accelerators of adoption. This ensures consistent deployments without strictly enforcing adherence.
+**Adoption acceleration:** The cloud governance team has been reviewing deployment scripts across multiple teams. They've maintained a set of scripts that serve as deployment templates. Those templates can be used by the cloud adoption teams and DevOps teams to more quickly define deployments. Each script contains the requirements for enforcing governance policies, and additional effort from cloud adoption engineers is not needed. As the curators of these scripts, they can implement policy changes more quickly. Additionally, they are viewed as accelerators of adoption. This ensures consistent deployments without strictly enforcing 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 how deployments are performed. 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. This ensures consistent deployments without strictly enforcing 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 how deployments are performed. 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. This ensures consistent deployments without strictly enforcing adherence.
-**Deployment planning:** Before deploying any asset containing protected data, the Cloud Governance team will be responsible for reviewing deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling.
+**Deployment planning:** Before deploying any asset containing protected data, the cloud governance team will be responsible for reviewing deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be 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 are 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.
+**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 are 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 team and Cloud Strategy team to review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles.
+**Quarterly policy review:** Each quarter, the cloud governance team and the cloud strategy team to review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles.
## Alternative patterns
@@ -117,9 +117,9 @@ If any of the patterns chosen in this governance journey don't align with the re
## Next steps
-Once this guidance is implemented, each cloud adoption team can proceed with a solid governance foundation. The Cloud Governance team will work in parallel to continually update the corporate policies and governance disciplines.
+Once this guidance is implemented, each cloud adoption team can proceed with a solid governance foundation. The cloud governance team will work in parallel to continually update the corporate policies and governance disciplines.
-Both teams will use the tolerance indicators to identify the next evolution needed to continue supporting cloud adoption. The next step for the company in this journey is to evolve their governance baseline to support applications with legacy or third-party multi-factor authentication requirements.
+Both teams will use the tolerance indicators to identify the next set of improvements needed to continue supporting cloud adoption. The next step for the company in this journey is to evolve their governance baseline to support applications with legacy or third-party multi-factor authentication requirements.
> [!div class="nextstepaction"]
> [Identity Baseline evolution](./identity-baseline-evolution.md)
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md
index b5d48ef7a02..f2d7db52257 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/cost-management-evolution.md
@@ -17,7 +17,7 @@ This article evolves the narrative by adding cost controls to the minimum viable
## Evolution of the narrative
-Adoption has grown beyond the tolerance indicator defined in the governance MVP. The increases in spending now justifies an investment of time from the Cloud Governance team to monitor and control spending patterns.
+Adoption has grown beyond the tolerance indicator defined in the governance MVP. The increases in spending now justifies an investment of time from the cloud governance team to monitor and control spending patterns.
As a clear driver of innovation, IT is no longer seen primarily as a cost center. As the IT organization delivers more value, the CIO and CFO agree that the time is right to evolve the role IT plays in the company. Amongst other changes, the CFO wants to test a direct pay approach to cloud accounting for the Canadian branch of one of the business units. One of the two retired datacenters was exclusively hosted assets for that business unit’s Canadian operations. In this model, the business unit’s Canadian subsidiary will be billed directly for the operating expenses related to the hosted assets. This model allows IT to focus less on managing someone else’s spending and more on creating value. However, before this transition can begin Cost Management tooling needs to be in place.
@@ -49,7 +49,7 @@ This business risk can be expanded into a few technical risks:
The following changes to policy will help remediate the new risks and guide implementation.
-1. All cloud costs should be monitored against plan on a weekly basis by the Cloud Governance team. Reporting on deviations between cloud costs and plan is to be shared with IT leadership and finance monthly. All cloud costs and plan updates should be reviewed with IT leadership and finance monthly.
+1. All cloud costs should be monitored against plan on a weekly basis by the cloud governance team. Reporting on deviations between cloud costs and plan is to be shared with IT leadership and finance monthly. All cloud costs and plan updates should be reviewed with IT leadership and finance monthly.
2. All costs must be allocated to a business function for accountability purposes.
3. Cloud assets should be continually monitored for optimization opportunities.
4. Cloud Governance tooling must limit Asset sizing options to an approved list of configurations. The tooling must ensure that all assets are discoverable and tracked by the cost monitoring solution.
@@ -62,7 +62,7 @@ This section of the article will evolve the governance MVP design to include new
1. Changes in the Azure Enterprise Portal to bill the Department administrator for the Canadian deployment.
2. Implement Azure Cost Management.
- 1. Establish the right level of access scope to align with the subscription pattern and resource grouping pattern. Assuming alignment with the governance MVP defined in prior articles, this would require **Enrollment Account Scope** access for the Cloud Governance team executing on high-level reporting. Additional teams outside of governance, like the Canadian procurement team, will require **Resource Group Scope** access.
+ 1. Establish the right level of access scope to align with the subscription pattern and resource grouping pattern. Assuming alignment with the governance MVP defined in prior articles, this would require **Enrollment Account Scope** access for the cloud governance team executing on high-level reporting. Additional teams outside of governance, like the Canadian procurement team, will require **Resource Group Scope** access.
2. Establish a budget in Azure Cost Management.
3. Review and act on initial recommendations. It's recommended to have a recurring process to support the reporting process.
4. Configure and execute Azure Cost Management Reporting, both initial and recurring.
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md
index 4f385c4f5ac..d246449526b 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/identity-baseline-evolution.md
@@ -26,9 +26,9 @@ The business justification for the cloud migration of the two datacenters was ap
The first two roadblocks are being managed in parallel. This article will address the resolution of the third and fourth roadblocks.
-### Evolution of the Cloud Governance team
+### Evolution of the cloud governance team
-The Cloud Governance team is expanding. Given the need for additional support regarding identity management, a systems administrator from the Identity Baseline team now participates in a weekly meeting to keep the existing team members aware of changes.
+The cloud governance team is expanding. Given the need for additional support regarding identity management, a systems administrator from the Identity Baseline team now participates in a weekly meeting to keep the existing team members aware of changes.
### Evolution of the current state
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/index.md b/docs/cloud-adoption/governance/journeys/large-enterprise/index.md
index daefc2f5574..2817744fd93 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/index.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/index.md
@@ -13,7 +13,7 @@ ms.custom: governance
# Large enterprise governance journey
-## Best practice overview
+## Overview of best practices
This governance journey follows the experiences of a fictional company through various stages of governance maturity. It is based on real customer journeys. The suggested best practices are based on the constraints and needs of the fictional company.
@@ -22,9 +22,9 @@ As a quick starting point, this overview defines a minimum viable product (MVP)
> [!WARNING]
> This MVP is a baseline starting point, based on a set of assumptions. Even this minimal set of best practices is based on corporate policies driven by unique business risks and risk tolerances. To see if these assumptions apply to you, read the [longer narrative](./narrative.md) that follows this article.
-### Governance best practice
+### Governance best practices
-This best practice serves as a foundation that an organization can use to quickly and consistently add governance guardrails across multiple Azure subscriptions.
+These best practices serve as a foundation for an organization to quickly and consistently add governance guardrails across multiple Azure subscriptions.
### Resource organization
@@ -32,7 +32,7 @@ The following diagram shows the governance MVP hierarchy for organizing resource
![Resource Organization diagram](../../../_images/governance/resource-organization.png)
-Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the Cloud Governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams.
+Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the cloud governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams.
1. A management group for each business unit with a detailed hierarchy that reflects geography then environment type (for example, Production or Nonproduction).
2. A subscription for each unique combination of business unit, geography, environment, and "Application Categorization."
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md b/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md
index 9130f419d87..4da0d6ad4ca 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/initial-corporate-policy.md
@@ -18,11 +18,11 @@ The following corporate policy defines the initial governance position, which is
> [!NOTE]
>The corporate policy is not a technical document, but it drives many technical decisions. The governance MVP described in the [overview](./index.md) ultimately derives from this policy. Before implementing a governance MVP, your organization should develop a corporate policy based on your own objectives and business risks.
-## Cloud Governance team
+## Cloud governance team
The CIO recently held a meeting with the IT Governance team to understand the history of the PII and mission-critical policies and review the effect of changing those policies. She also discussed the overall potential of the cloud for IT and the company.
-After the meeting, two members of the IT Governance team requested permission to research and support the cloud planning efforts. Recognizing the need for governance and an opportunity to limit shadow IT, the Director of IT Governance supported this idea. With that, the Cloud Governance team was born. Over the next several months, they will inherit the cleanup of many mistakes made during exploration in the cloud from a governance perspective. This will earn them the moniker of _cloud custodians_. In later evolutions, this journey will show how their roles change over time.
+After the meeting, two members of the IT Governance team requested permission to research and support the cloud planning efforts. Recognizing the need for governance and an opportunity to limit shadow IT, the Director of IT Governance supported this idea. With that, the cloud governance team was born. Over the next several months, they will inherit the cleanup of many mistakes made during exploration in the cloud from a governance perspective. This will earn them the moniker of _cloud custodians_. In later evolutions, this journey will show how their roles change over time.
[!INCLUDE [business-risk](../../../includes/governance/business-risks.md)]
@@ -39,7 +39,7 @@ The current risk tolerance is high and the appetite for investing in cloud gover
## Next steps
-This corporate policy prepares the Cloud Governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP.
+This corporate policy prepares the cloud governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP.
> [!div class="nextstepaction"]
> [Best practice explained](./best-practice-explained.md)
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md b/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md
index fd1a913e0d1..5d7b50f74c5 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/multiple-layers-of-governance.md
@@ -13,7 +13,7 @@ ms.custom: governance
# Multiple layers of governance in large enterprises
-When large enterprises require multiple layers of governance, there are greater levels of complexity that must be factored into the governance MVP and later governance evolutions.
+When large enterprises require multiple layers of governance, there are greater levels of complexity that must be factored into the governance MVP and later governance improvements.
A few common examples of such complexities include:
@@ -29,9 +29,9 @@ Large established enterprises often have teams or employees who focus on the dis
In many large enterprises, the Five Disciplines of Cloud Governance can be blockers to adoption. Developing cloud expertise in identity, security, operations, deployments, and configuration across an enterprise takes time. Holistically implementing IT governance policy and IT security can slow innovation by months or even years. Balancing the business need to innovate and the governance need to protect existing resources is delicate.
-The inherent capabilities of the cloud can remove blockers to innovation but increase risks. In this governance journey, we showed how the example company created guardrails to manage the risks. Rather than tackling each of the disciplines required to protect the environment, the Cloud Governance team leads a risk-based approach to govern what could be deployed, while the other teams build the necessary cloud maturities. Most importantly, as each team reaches cloud maturity, governance applies their solutions holistically. As each team matures and adds to the overall solution, the Cloud Governance team can open stage gates, allowing additional innovation and adoption to thrive.
+The inherent capabilities of the cloud can remove blockers to innovation but increase risks. In this governance journey, we showed how the example company created guardrails to manage the risks. Rather than tackling each of the disciplines required to protect the environment, the cloud governance team leads a risk-based approach to govern what could be deployed, while the other teams build the necessary cloud maturities. Most importantly, as each team reaches cloud maturity, governance applies their solutions holistically. As each team matures and adds to the overall solution, the cloud governance team can open stage gates, allowing additional innovation and adoption to thrive.
-This model illustrates the growth of a partnership between the Cloud Governance team and existing enterprise teams (Security, IT Governance, Networking, Identity, and others). The journey starts with the governance MVP and grows to a holistic end state through governance evolutions.
+This model illustrates the growth of a partnership between the cloud governance team and existing enterprise teams (Security, IT Governance, Networking, Identity, and others). The journey starts with the governance MVP and grows to a holistic end state through governance evolutions.
## Requirements to supporting such a team sport
@@ -51,4 +51,4 @@ The important aspect of each of these tools is the ability to apply multiple blu
- **Regional or Business Unit IT:** Various IT teams can apply an additional layer of governance by creating their own blueprint. Those blueprints would create additive policies and standards. Once developed, Corporate IT could apply those blueprints to the applicable nodes within the management group hierarchy.
- **Cloud adoption teams:** Detailed decisions and implementation about applications or workloads can be made by each cloud adoption team, within the context of governance requirements. At times the team can also request additional Azure Resource Consistency templates to accelerate adoption efforts.
-The details regarding governance implementation at each level will require coordination between each team. The governance MVP and governance evolutions outlined in this journey can aid in aligning that coordination.
+The details regarding governance implementation at each level will require coordination between each team. The governance MVP and governance improvements outlined in this journey can aid in aligning that coordination.
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md
index 46848fd0672..b7bf88e25cf 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/resource-consistency-evolution.md
@@ -54,7 +54,7 @@ This business risk can be expanded into several technical risks:
The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but the adoption of these policies may be easier than it would appear.
-1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud.
+1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud.
2. Subnets containing mission-critical applications must be protected by a firewall solution capable of detecting intrusions and responding to attacks.
3. Governance tooling must audit and enforce network configuration requirements defined by the Security Baseline team.
4. Governance tooling must validate that all assets related to mission-critical applications or protected data are included in monitoring for resource depletion and optimization.
@@ -62,13 +62,13 @@ The following changes to policy will help remediate the new risks and guide impl
6. Governance process must validate that backup, recovery, and SLA adherence are properly implemented for mission-critical applications and protected data.
7. Governance tooling must limit virtual machine deployment to approved images only.
8. Governance tooling must enforce that automatic updates are **prevented** on all deployed assets that support mission-critical applications. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT operations.
-9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the Cloud Governance team.
+9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the cloud governance team.
10. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets.
11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to Security Baseline tooling used in the cloud.
12. Before release into production, all mission-critical applications and protected data must be added to the designated operational monitoring solution. Assets that cannot be discovered by the chosen IT operations tooling cannot be released for production use. Any changes required to make the assets discoverable must be made to the relevant deployment processes to ensure assets will be discoverable in future deployments.
13. When discovered, asset sizing is to be validated by operational management teams to validate that the asset meets performance requirements.
-14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets.
-15. Deployment scripts must be maintained in central repository accessible by the Cloud Governance team for periodic review and auditing.
+14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets.
+15. Deployment scripts must be maintained in central repository accessible by the cloud governance team for periodic review and auditing.
16. Governance review processes must validate that deployed assets are properly configured in alignment with SLA and recovery requirements.
## Evolution of the best practices
@@ -79,8 +79,8 @@ Following the experience of this fictional example, it is assumed that the Prote
**Corporate IT subscription:** Add the following to the Corporate IT subscription, which acts as a hub.
-1. As an external dependency, the Cloud Operations team will need to define operational monitoring tooling, business continuity and disaster recovery (BCDR) tooling, and automated remediation tooling. The Cloud Governance team can then support necessary discovery processes.
- 1. In this use case, the Cloud Operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications.
+1. As an external dependency, the cloud operations team will need to define operational monitoring tooling, business continuity and disaster recovery (BCDR) tooling, and automated remediation tooling. The cloud governance team can then support necessary discovery processes.
+ 1. In this use case, the cloud operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications.
2. The team also chose Azure Site Recovery as the primary BCDR tooling.
2. Azure Site Recovery implementation.
1. Define and deploy Azure Vault for backup and recovery processes.
@@ -107,7 +107,7 @@ Adding these processes and changes to the governance MVP helps remediate many of
## Next steps
-As cloud adoption continues to evolve and deliver additional business value, the risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 1,000 assets to the cloud or monthly spending exceeds $10,000 USD per month. At this point, the Cloud Governance team adds Cost Management controls.
+As cloud adoption continues to evolve and deliver additional business value, the risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 1,000 assets to the cloud or monthly spending exceeds $10,000 USD per month. At this point, the cloud governance team adds Cost Management controls.
> [!div class="nextstepaction"]
> [Cost Management evolution](./cost-management-evolution.md)
diff --git a/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md
index 6d1b02fb480..4c72168bf57 100644
--- a/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/large-enterprise/security-baseline-evolution.md
@@ -21,9 +21,9 @@ The CIO has spent months collaborating with colleagues and the company’s legal
For the past 12 months, the cloud adoption teams have cleared most of the 5,000 assets from the two datacenters to be retired. The 350 incompatible assets were moved to an alternate datacenter. Only the 1,250 virtual machines that contain protected data remain.
-### Evolution of the Cloud Governance team
+### Evolution of the cloud governance team
-The Cloud Governance team continues to evolve along with the narrative. The two founding members of the team are now among the most respected cloud architects in the company. The collection of configuration scripts has grown as new teams tackle innovative new deployments. The Cloud Governance team has also grown. Most recently, members of the IT Operations team have joined Cloud Governance team activities to prepare for cloud operations. The cloud architects who helped foster this community are seen both as cloud guardians and cloud accelerators.
+The cloud governance team continues to evolve along with the narrative. The two founding members of the team are now among the most respected cloud architects in the company. The collection of configuration scripts has grown as new teams tackle innovative new deployments. The cloud governance team has also grown. Most recently, members of the IT Operations team have joined cloud governance team activities to prepare for cloud operations. The cloud architects who helped foster this community are seen both as cloud guardians and cloud accelerators.
While the difference is subtle, it is an important distinction when building a governance-focused IT culture. A cloud custodian cleans up the messes made by innovative cloud architects, and the two roles have natural friction and opposing objectives. A cloud guardian helps keep the cloud safe, so other cloud architects can move more quickly with fewer messes. A cloud accelerator performs both functions but is also involved in the creation of templates to accelerate deployment and adoption, becoming an innovation accelerator as well as a defender of the Five Disciplines of Cloud Governance.
@@ -43,8 +43,8 @@ Since then, some things have changed that will affect governance:
- Early experiments from the application development and BI teams have shown potential improvements in customer experiences and data-driven decisions. Both teams would like to expand adoption of the cloud over the next 18 months by deploying those solutions to production.
- IT has developed a business justification to migrate five more datacenters to Azure, which will further decrease IT costs and provide greater business agility. While smaller in scale, the retirement of those datacenters is expected to double the total cost savings.
-- Capital expense and operating expense budgets have approved to implement the required security and governance policies, tools, and processes. The expected cost savings from the datacenter retirement are more than enough to pay for this new initiative. IT and business leadership are confident this investment will accelerate the realization of returns in other areas. The grassroots Cloud Governance team became a recognized team with dedicated leadership and staffing.
-- Collectively, the cloud adoption teams, Cloud Governance team, IT Security team, and IT Governance team will implement security and governance requirements to allow cloud adoption teams to migrate protected data into the cloud.
+- Capital expense and operating expense budgets have approved to implement the required security and governance policies, tools, and processes. The expected cost savings from the datacenter retirement are more than enough to pay for this new initiative. IT and business leadership are confident this investment will accelerate the realization of returns in other areas. The grassroots cloud governance team became a recognized team with dedicated leadership and staffing.
+- Collectively, the cloud adoption teams, the cloud governance team, the IT security team, and the IT governance team will implement security and governance requirements to allow cloud adoption teams to migrate protected data into the cloud.
## Evolution of tangible risks
@@ -69,24 +69,24 @@ This business risk can be expanded into a few technical risks:
The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but the adoption of these policies may be easier than it would appear.
-1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application before deployment to the cloud.
+1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application before deployment to the cloud.
2. Applications that store or access protected data are to be managed differently than those that don’t. At a minimum, they should be segmented to avoid unintended access of protected data.
3. All protected data must be encrypted when at rest.
-4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the Cloud Governance team and audited regularly.
+4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the cloud governance team and audited regularly.
5. Network subnets containing protected data must be isolated from any other subnets. Network traffic between protected data subnets will be audited regularly.
6. No subnet containing protected data can be directly accessed over the public internet or across datacenters. Access to these subnets must be routed through intermediate subnets. All access into these subnets must come through a firewall solution that can perform packet scanning and blocking functions.
7. Governance tooling must audit and enforce network configuration requirements defined by the Security Management team.
8. Governance tooling must limit VM deployment to approved images only.
9. Whenever possible, node configuration management should apply policy requirements to the configuration of any guest operating system. Node configuration management should respect the existing investment in Group Policy Object (GPO) for resource configuration.
10. Governance tooling will audit that automatic updates are enabled on all deployed assets. When possible, automatic updates will be enforced. When not enforced by tooling, node-level violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations.
-11. Creation of new subscriptions or management groups for any mission-critical applications or protected data requires a review from the Cloud Governance team to ensure proper blueprint assignment.
+11. Creation of new subscriptions or management groups for any mission-critical applications or protected data requires a review from the cloud governance team to ensure proper blueprint assignment.
12. A least-privilege access model will be applied to any subscription that contains mission-critical applications or protected data.
13. The cloud vendor must be capable of integrating encryption keys managed by the existing on-premises solution.
14. The cloud vendor must be capable of supporting the existing edge device solution and any required configurations to protect any publicly exposed network boundary.
15. The cloud vendor must be capable of supporting a shared connection to the global WAN, with data transmission routed through the existing edge device solution.
16. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to Security Baseline tooling used in the cloud.
-17. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets.
-18. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing.
+17. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets.
+18. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing.
19. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets.
20. Deployment of any applications that require customer authentication must use an approved identity provider that is compatible with the primary identity provider for internal users.
21. Cloud Governance processes must include quarterly reviews with Identity Baseline teams to identify malicious actors or usage patterns that should be prevented by cloud asset configuration.
@@ -97,7 +97,7 @@ This section of the article will evolve the governance MVP design to include new
The new best practices fall into two categories: Corporate IT (hub) and Cloud Adoption (spoke).
-**Establishing a corporate IT hub and spoke subscription to centralize the Security Baseline:** In this best practice, the existing governance capacity is wrapped by a [hub and spoke topology with shared services][shared-services], with a few key additions from the Cloud Governance team.
+**Establishing a corporate IT hub and spoke subscription to centralize the Security Baseline:** In this best practice, the existing governance capacity is wrapped by a [hub and spoke topology with shared services][shared-services], with a few key additions from the cloud governance team.
1. Azure DevOps repository. Create a repository in Azure DevOps to store and version all relevant Azure Resource Manager templates and scripted configurations.
2. Hub and spoke template.
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md
index 1207a57c14c..4bf62a0181c 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/best-practice-explained.md
@@ -17,7 +17,7 @@ The governance journey starts with a set of initial [corporate policies](./initi
In this article, we discuss the high-level strategies that are required to create a governance MVP. The core of the governance MVP is the [Deployment Acceleration](../../deployment-acceleration/index.md) discipline. The tools and patterns applied at this stage will enable the incremental evolutions needed to expand governance in the future.
-## Governance MVP (Cloud Adoption Foundation)
+## Governance MVP (initial governance foundation)
Rapid adoption of governance and corporate policy is achievable, thanks to a few simple principles and cloud-based governance tooling. These are the first three disciplines to approach in any governance process. Each discipline will be further described in this article.
@@ -27,7 +27,7 @@ To establish the starting point, this article will discuss the high-level strate
## Implementation process
-The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the Cloud Governance team will decide a few aspects of governance. The decisions from the Cloud Governance team and from supporting teams will be implemented through a single package of enforcement assets.
+The implementation of the governance MVP has dependencies on Identity, Security, and Networking. Once the dependencies are resolved, the cloud governance team will decide a few aspects of governance. The decisions from the cloud governance team and from supporting teams will be implemented through a single package of enforcement assets.
![Example of an incremental governance MVP](../../../_images/governance/governance-mvp-implementation-flow.png)
@@ -42,7 +42,7 @@ This implementation can also be described using a simple checklist:
## Application of governance-defined patterns
-The Cloud Governance team is responsible for the following decisions and implementations. Many require inputs from other teams, but the Cloud Governance team is likely to own both the decision and the implementation. The following sections outline the decisions made for this use case and details of each decision.
+The cloud governance team is responsible for the following decisions and implementations. Many require inputs from other teams, but the cloud governance team is likely to own both the decision and the implementation. The following sections outline the decisions made for this use case and details of each decision.
### Subscription design
@@ -85,17 +85,17 @@ Logging and reporting decisions determine how your store log data and how the mo
## Evolution of governance processes
-As governance evolves, some policy statements can’t or shouldn’t be controlled by automated tooling. Other policies will result in effort by the IT Security team and the on-premises Identity Management team over time. To help manage new risks as they arise, the Cloud Governance team will oversee the following processes.
+As governance evolves, some policy statements can’t or shouldn’t be controlled by automated tooling. Other policies will result in effort by the IT Security team and the on-premises Identity Management team over time. To help manage new risks as they arise, the cloud governance team will oversee the following processes.
-**Adoption acceleration:** The Cloud Governance team has been reviewing deployment scripts across multiple teams. They maintain a set of scripts that serve as deployment templates. Those templates are used by the cloud adoption and DevOps teams to define deployments more quickly. Each of those scripts contains the necessary requirements to enforce a set of governance policies with no additional 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 seen as a source of adoption acceleration. This creates consistency among deployments, without strictly forcing adherence.
+**Adoption acceleration:** The cloud governance team has been reviewing deployment scripts across multiple teams. They maintain a set of scripts that serve as deployment templates. Those templates are used by the cloud adoption and DevOps teams to define deployments more quickly. Each of those scripts contains the necessary requirements to enforce a set of governance policies with no additional 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 seen as a source of adoption acceleration. This 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. These materials help engineers quickly learn the governance culture and how things are done during deployments. The team is adding training assets that show the difference between production and nonproduction deployments, so that engineers will understand how the new policies will affect adoption. This 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. These materials help engineers quickly learn the governance culture and how things are done during deployments. The team is adding training assets that show the difference between production and nonproduction deployments, so that engineers will understand how the new policies will affect adoption. This creates consistency among deployments, without strictly forcing adherence.
-**Deployment planning:** Before deploying any asset containing protected data, the Cloud Governance team will review deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be audited using programmatic tooling.
+**Deployment planning:** Before deploying any asset containing protected data, the cloud governance team will review deployment scripts to validate governance alignment. Existing teams with previously approved deployments will be 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 are 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.
+**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 are 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 team and the Cloud Strategy team will review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles.
+**Quarterly policy review:** Each quarter, the cloud governance team and the cloud strategy team will review audit results and suggest changes to corporate policy. Many of those suggestions are the result of continuous improvements and the observation of usage patterns. Approved policy changes are integrated into governance tooling during subsequent audit cycles.
## Alternative patterns
@@ -112,7 +112,7 @@ If any of the patterns selected in this governance journey don't align with the
## Next steps
-Once this guide is implemented, each cloud adoption team can go forth with a sound governance foundation. The Cloud Governance team will work in parallel to continuously update the corporate policies and governance disciplines.
+Once this guide is implemented, each cloud adoption team can go forth with a sound governance foundation. The cloud governance team will work in parallel to continuously update the corporate policies and governance disciplines.
The two teams will use the tolerance indicators to identify the next evolution needed to continue supporting cloud adoption. For the fictional company in this journey, the next step is evolving the Security Baseline to support moving protected data to the cloud.
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md
index f021ac97fe6..4857450fd33 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/cost-management-evolution.md
@@ -17,7 +17,7 @@ This article evolves the narrative by adding cost controls to the governance MVP
## Evolution of the narrative
-Adoption has grown beyond the cost tolerance indicator defined in the governance MVP. This is a good thing, as it corresponds with migrations from the "DR" datacenter. The increase in spending now justifies an investment of time from the Cloud Governance team.
+Adoption has grown beyond the cost tolerance indicator defined in the governance MVP. This is a good thing, as it corresponds with migrations from the "DR" datacenter. The increase in spending now justifies an investment of time from the cloud governance team.
### Evolution of the current state
@@ -62,7 +62,7 @@ The following changes to policy will help remediate the new risks and guide impl
This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements.
1. Implement Azure Cost Management
- 1. Establish the right scope of access to align with the subscription pattern and the Resource Consistency discipline. Assuming alignment with the governance MVP defined in prior articles, this requires **Enrollment Account Scope** access for the Cloud Governance team executing on high-level reporting. Additional teams outside of governance may require **Resource Group Scope** access.
+ 1. Establish the right scope of access to align with the subscription pattern and the Resource Consistency discipline. Assuming alignment with the governance MVP defined in prior articles, this requires **Enrollment Account Scope** access for the cloud governance team executing on high-level reporting. Additional teams outside of governance may require **Resource Group Scope** access.
2. Establish a budget in Azure Cost Management.
3. Review and act on initial recommendations. Have a recurring process to support reporting.
4. Configure and execute Azure Cost Management Reporting, both initial and recurring.
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md
index f4aeb08ea79..98808b54e28 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/index.md
@@ -22,9 +22,9 @@ As a quick starting point, this overview defines a minimum viable product (MVP)
> [!WARNING]
> This MVP is a baseline starting point, based on a set of assumptions. Even this minimal set of best practices is based on corporate policies driven by unique business risks and risk tolerances. To see if these assumptions apply to you, read the [longer narrative](./narrative.md) that follows this article.
-## Governance best practice
+## Governance best practices
-This best practice serves as a foundation that an organization can use to quickly and consistently add governance guardrails across multiple Azure subscriptions.
+These best practices serve as a foundation for an organization to quickly and consistently add governance guardrails across multiple Azure subscriptions.
### Resource organization
@@ -32,7 +32,7 @@ The following diagram shows the governance MVP hierarchy for organizing resource
![Resource Organization diagram](../../../_images/governance/resource-organization.png)
-Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the Cloud Governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams.
+Every application should be deployed in the proper area of the management group, subscription, and resource group hierarchy. During deployment planning, the cloud governance team will create the necessary nodes in the hierarchy to empower the cloud adoption teams.
1. A management group for each type of environment (such as Production, Development, and Test).
2. A subscription for each "application categorization".
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md
index 5869ca2889b..3ce79e62d67 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/initial-corporate-policy.md
@@ -18,9 +18,9 @@ The following corporate policy defines an initial governance position, which is
> [!NOTE]
>The corporate policy is not a technical document, but it drives many technical decisions. The governance MVP described in the [overview](./index.md) ultimately derives from this policy. Before implementing a governance MVP, your organization should develop a corporate policy based on your own objectives and business risks.
-## Cloud Governance team
+## Cloud governance team
-In this narrative, the Cloud Governance team is comprised of two systems administrators who have recognized the need for governance. Over the next several months, they will inherit the job of cleaning up the governance of the company’s cloud presence, earning them the title of _cloud custodians_. In subsequent evolutions, this title will likely change.
+In this narrative, the cloud governance team is comprised of two systems administrators who have recognized the need for governance. Over the next several months, they will inherit the job of cleaning up the governance of the company’s cloud presence, earning them the title of _cloud custodians_. In subsequent evolutions, this title will likely change.
[!INCLUDE [business-risk](../../../includes/governance/business-risks.md)]
@@ -36,7 +36,7 @@ The current tolerance for risk is high and the appetite for investing in cloud g
## Next steps
-This corporate policy prepares the Cloud Governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP.
+This corporate policy prepares the cloud governance team to implement the governance MVP, which will be the foundation for adoption. The next step is to implement this MVP.
> [!div class="nextstepaction"]
> [Best practice explained](./best-practice-explained.md)
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md
index 438f0ab0bfe..874e9ff00b2 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/multicloud-evolution.md
@@ -59,7 +59,7 @@ The following changes to policy will help remediate the new risks and guide impl
This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements.
-1. Connect the networks. This step is executed by the Networking and IT Security teams, and supported by the Cloud Governance team. Adding a connection from the MPLS/leased-line provider to the new cloud will integrate networks. Adding routing tables and firewall configurations will control access and traffic between the environments.
+1. Connect the networks. This step is executed by the Networking and IT Security teams, and supported by the cloud governance team. Adding a connection from the MPLS/leased-line provider to the new cloud will integrate networks. Adding routing tables and firewall configurations will control access and traffic between the environments.
2. Consolidate identity providers. Depending on the workloads being hosted in the secondary cloud, there are a variety of options to identity provider consolidation. The following are a few examples:
1. For applications that authenticate using OAuth 2, users from Active Directory in the secondary cloud can simply be replicated to the existing Azure AD tenant. This ensures all users can be authenticated in the tenant.
2. At the other extreme, federation allows OUs to flow into Active Directory on-premises, then into the Azure AD instance.
@@ -80,4 +80,4 @@ As multicloud adoption grows, the design evolution above will continue to mature
## Conclusion
-This series of articles outlined the evolution of governance best practices, aligned with the experiences of this fictional company. By starting small, but with the right foundation, the company could move quickly and yet still apply the right amount of governance at the right time. The MVP by itself did not protect the customer. Instead, it created the foundation to manage risks and add protections. From there, layers of governance were applied to remediate tangible risks. The exact journey presented here won't align 100% with the experiences of any reader. Rather, it serves as a pattern for incremental governance. The reader is advised to mold these best practices to fit their own unique constraints and governance requirements.
+This series of articles described the incremental development of governance best practices, aligned with the experiences of this fictional company. By starting small, but with the right foundation, the company could move quickly and yet still apply the right amount of governance at the right time. The MVP by itself did not protect the customer. Instead, it created the foundation to manage risks and add protections. From there, layers of governance were applied to remediate tangible risks. The exact journey presented here won't align 100% with the experiences of any reader. Rather, it serves as a pattern for incremental governance. The reader is advised to mold these best practices to fit their own unique constraints and governance requirements.
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md
index d3b25dc8ff0..492f7f484ff 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/resource-consistency-evolution.md
@@ -57,7 +57,7 @@ This business risk can be expanded into several technical risks:
The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but adopting these policies may be easier than it appears.
-1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud.
+1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud.
2. Subnets containing mission-critical applications must be protected by a firewall solution capable of detecting intrusions and responding to attacks.
3. Governance tooling must audit and enforce network configuration requirements defined by the Security Management team.
4. Governance tooling must validate that all assets related to mission-critical apps or protected data are included in monitoring for resource depletion and optimization.
@@ -67,18 +67,18 @@ The following changes to policy will help remediate the new risks and guide impl
8. Governance tooling must enforce that automatic updates are prevented on all deployed assets that support mission-critical applications. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations.
9. Governance tooling must validate tagging related to cost, criticality, SLA, application, and data classification. All values must align to predefined values managed by the governance team.
10. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets.
-11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the Security team to provide updates to security management tooling used in the cloud.
+11. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to security management tooling used in the cloud.
12. Before release into production, all mission-critical apps and protected data must be added to the designated operational monitoring solution. Assets that cannot be discovered by the chosen IT operations tooling, cannot be released for production use. Any changes required to make the assets discoverable must be made to the relevant deployment processes to ensure assets will be discoverable in future deployments.
13. When discovered, operational management teams will size assets, to ensure that assets meet performance requirements.
-14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets.
-15. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing.
+14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets.
+15. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing.
16. Governance review processes must validate that deployed assets are properly configured in alignment with SLA and recovery requirements.
## Evolution of the best practices
This section of the article will evolve the governance MVP design to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements.
-1. The Cloud Operations team will define operational monitoring tooling and automated remediation tooling. The Cloud Governance team will support those discovery processes. In this use case, the Cloud Operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications.
+1. The cloud operations team will define operational monitoring tooling and automated remediation tooling. The cloud governance team will support those discovery processes. In this use case, the cloud operations team chose Azure Monitor as the primary tool for monitoring mission-critical applications.
2. Create a repository in Azure DevOps to store and version all relevant Resource Manager templates and scripted configurations.
3. Azure Vault implementation:
1. Define and deploy Azure Vault for backup and recovery processes.
@@ -88,7 +88,7 @@ This section of the article will evolve the governance MVP design to include new
2. Audit and enforce the use of approved images only.
5. Azure Monitor implementation:
1. Once a mission-critical subscription is identified, create an Azure Monitor workspace using PowerShell. This is a predeployment process.
- 2. During deployment testing, the Cloud Operations team deploys the necessary agents and tests discovery.
+ 2. During deployment testing, the cloud operations team deploys the necessary agents and tests discovery.
6. Update Azure Policy for all subscriptions that contain mission-critical applications.
1. Audit and enforce the application of an NSG to all NICs and subnets. Networking and IT Security define the NSG.
2. Audit and enforce the use of approved network subnets and VNets for each network interface.
@@ -111,7 +111,7 @@ These additional processes and changes to the governance MVP help remediate many
## Next steps
-As cloud adoption continues to evolve and deliver additional business value, risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 100 assets to the cloud or monthly spending exceeds $1,000 per month. At this point, the Cloud Governance team adds Cost Management controls.
+As cloud adoption continues to evolve and deliver additional business value, risks and cloud governance needs will also evolve. For the fictional company in this journey, the next trigger is when the scale of deployment exceeds 100 assets to the cloud or monthly spending exceeds $1,000 per month. At this point, the cloud governance team adds Cost Management controls.
> [!div class="nextstepaction"]
> [Cost Management evolution](./cost-management-evolution.md)
diff --git a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md
index f346e9ea92d..af6772c0270 100644
--- a/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md
+++ b/docs/cloud-adoption/governance/journeys/small-to-medium-enterprise/security-baseline-evolution.md
@@ -19,9 +19,9 @@ This article evolves the narrative by adding security controls that support movi
IT and business leadership have been happy with results from early stage experimentation by the IT, App Development, and BI teams. To realize tangible business values from these experiments, those teams must be allowed to integrate protected data into solutions. This triggers changes to corporate policy, but also requires an evolution of the cloud governance implementations before protected data can land in the cloud.
-### Evolution of the Cloud Governance team
+### Evolution of the cloud governance team
-Given the effect of the changing narrative and support provided so far, the Cloud Governance team is now viewed differently. The two system administrators who started the team are now viewed as experienced cloud architects. As this narrative develops, the perception of them will shift from being Cloud Custodians to more of a Cloud Guardian role.
+Given the effect of the changing narrative and support provided so far, the cloud governance team is now viewed differently. The two system administrators who started the team are now viewed as experienced cloud architects. As this narrative develops, the perception of them will shift from being Cloud Custodians to more of a Cloud Guardian role.
While the difference is subtle, it’s an important distinction when building a governance- focused IT culture. A Cloud Custodian cleans up the messes made by innovative cloud architects. The two roles have natural friction and opposing objectives. On the other hand, a Cloud Guardian helps keep the cloud safe, so other cloud architects can move more quickly, with less messes. Additionally, a Cloud Guardian is involved in creating templates that accelerate deployment and adoption, making them an innovation accelerator as well as a defender of the Five Disciplines of Cloud Governance.
@@ -40,7 +40,7 @@ Since then, some things have changed that will affect governance:
Early experiments by the App Dev and BI teams show potential improvements in customer experiences and data-driven decisions. Both teams want to expand adoption of the cloud over the next 18 months by deploying those solutions to production.
-During the remaining six months, the Cloud Governance team will implement security and governance requirements to allow the cloud adoption teams to migrate the protected data in those datacenters.
+During the remaining six months, the cloud governance team will implement security and governance requirements to allow the cloud adoption teams to migrate the protected data in those datacenters.
The changes to current and future state expose new risks that require new policy statements.
@@ -64,21 +64,21 @@ This business risk can be expanded into a few technical risks:
The following changes to policy will help remediate the new risks and guide implementation. The list looks long, but adopting these policies may be easier than it appears.
-1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the Cloud Governance team and the application owner before deployment to the cloud.
+1. All deployed assets must be categorized by criticality and data classification. Classifications are to be reviewed by the cloud governance team and the application owner before deployment to the cloud.
2. Applications that store or access protected data are to be managed differently than those that don’t. At a minimum, they should be segmented to avoid unintended access of protected data.
3. All protected data must be encrypted when at rest.
-4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the Cloud Governance team and audited regularly.
+4. Elevated permissions in any segment containing protected data should be an exception. Any such exceptions will be recorded with the cloud governance team and audited regularly.
5. Network subnets containing protected data must be isolated from any other subnets. Network traffic between protected data subnets will be audited regularly.
6. No subnet containing protected data can be directly accessed over the public internet or across datacenters. Access to those subnets must be routed through intermediate subnets. All access into those subnets must come through a firewall solution that can perform packet scanning and blocking functions.
7. Governance tooling must audit and enforce network configuration requirements defined by the security management team.
8. Governance tooling must limit VM deployment to approved images only.
9. Whenever possible, node configuration management should apply policy requirements to the configuration of any guest operating system.
10. Governance tooling must enforce that automatic updates are enabled on all deployed assets. Violations must be reviewed with operational management teams and remediated in accordance with operations policies. Assets that are not automatically updated must be included in processes owned by IT Operations.
-11. Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the Cloud Governance team, to ensure that the proper blueprint is assigned.
+11. Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the cloud governance team, to ensure that the proper blueprint is assigned.
12. A least-privilege access model will be applied to any management group or subscription that contains mission-critical apps or protected data.
13. Trends and exploits that could affect cloud deployments should be reviewed regularly by the security team to provide updates to security management tooling used in the cloud.
-14. Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets.
-15. Deployment scripts must be maintained in a central repository accessible by the Cloud Governance team for periodic review and auditing.
+14. Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets.
+15. Deployment scripts must be maintained in a central repository accessible by the cloud governance team for periodic review and auditing.
16. Governance processes must include audits at the point of deployment and at regular cycles to ensure consistency across all assets.
17. Deployment of any applications that require customer authentication must use an approved identity provider that is compatible with the primary identity provider for internal users.
18. Cloud governance processes must include quarterly reviews with identity management teams. These reviews can help identify malicious actors or usage patterns that should be prevented by cloud asset configuration.
@@ -87,8 +87,8 @@ The following changes to policy will help remediate the new risks and guide impl
The governance MVP design will evolve to include new Azure policies and an implementation of Azure Cost Management. Together, these two design changes will fulfill the new corporate policy statements.
-1. The Networking and IT Security teams will define network requirements. The Cloud Governance team will support the conversation.
-2. The Identity and IT Security teams will define identity requirements and make any necessary changes to local Active Directory implementation. The Cloud Governance team will review changes.
+1. The Networking and IT Security teams will define network requirements. The cloud governance team will support the conversation.
+2. The Identity and IT Security teams will define identity requirements and make any necessary changes to local Active Directory implementation. The cloud governance team will review changes.
3. Create a repository in Azure DevOps to store and version all relevant Azure Resource Manager templates and scripted configurations.
4. Azure Security Center implementation:
1. Configure Azure Security Center for any management group that contains protected data classifications.
diff --git a/docs/cloud-adoption/governance/policy-compliance/index.md b/docs/cloud-adoption/governance/policy-compliance/index.md
index beadb643bf6..f49d6406ac7 100644
--- a/docs/cloud-adoption/governance/policy-compliance/index.md
+++ b/docs/cloud-adoption/governance/policy-compliance/index.md
@@ -44,7 +44,7 @@ In the image above, the governance strategy (risk, policy and compliance, monito
An incremental approach to cloud governance assumes that it is unacceptable to exceed the [business' tolerance for risk](risk-tolerance.md). Instead, it assumes that the role of governance is to accelerate business change, help engineers understand architecture guidelines, and ensure that [business risks](understanding-business-risk.md) are regularly communicated and remediated. Alternatively, the traditional role of governance can become a barrier to adoption by engineers or by the business as a whole.
-With an incremental approach to cloud governance, there is sometimes a natural friction between teams building new business solutions and teams protecting the business from risks. However, in this model those two teams can become peers working in increments or sprints. As peers, the Cloud Governance team and the cloud adoption teams begin to work together to expose, evaluate, and remediate business risks. This effort can create a natural means of reducing friction and building collaboration between teams.
+With an incremental approach to cloud governance, there is sometimes a natural friction between teams building new business solutions and teams protecting the business from risks. However, in this model those two teams can become peers working in increments or sprints. As peers, the cloud governance team and the cloud adoption teams begin to work together to expose, evaluate, and remediate business risks. This effort can create a natural means of reducing friction and building collaboration between teams.
## Minimum viable product (MVP) for policy
@@ -58,6 +58,6 @@ Policy MVP attempts to define a required foundation for policies needed to deplo
Incremental policy growth is the key mechanism to growing policy and cloud governance over time. It is also the key requirement to adopting an incremental model to governance. For this model to work well, the governance team must be committed to an ongoing allocation of time at each sprint, in order to evaluate and implement changing governance disciplines.
-**Sprint time requirements:** At the beginning of each iteration, each cloud adoption team creates a list of assets to be migrated or adopted in the current increment. The Cloud Governance team is expected to allow sufficient time to review the list, validate data classifications for assets, evaluate any new risks associated with each asset, update architecture guidelines, and educate the team on the changes. These commitments commonly require 10-30 hours per sprint. It's also expected for this level of involvement to require at least one dedicated employee to manage governance in a large cloud adoption effort.
+**Sprint time requirements:** At the beginning of each iteration, each cloud adoption team creates a list of assets to be migrated or adopted in the current increment. The cloud governance team is expected to allow sufficient time to review the list, validate data classifications for assets, evaluate any new risks associated with each asset, update architecture guidelines, and educate the team on the changes. These commitments commonly require 10-30 hours per sprint. It's also expected for this level of involvement to require at least one dedicated employee to manage governance in a large cloud adoption effort.
-**Release time requirements:** At the beginning of each release, the cloud adoption teams and the Cloud Strategy team should prioritize a list of applications or workloads to be migrated in the current iteration, along with any business change activities. Those data points allow the Cloud Governance team to understand new business risks early. That allows time to align with the business and gauge the business's tolerance for risk.
+**Release time requirements:** At the beginning of each release, the cloud adoption teams and the cloud strategy team should prioritize a list of applications or workloads to be migrated in the current iteration, along with any business change activities. Those data points allow the cloud governance team to understand new business risks early. That allows time to align with the business and gauge the business's tolerance for risk.
diff --git a/docs/cloud-adoption/governance/policy-compliance/processes.md b/docs/cloud-adoption/governance/policy-compliance/processes.md
index 8fe31fd3b19..1eec0d884cb 100644
--- a/docs/cloud-adoption/governance/policy-compliance/processes.md
+++ b/docs/cloud-adoption/governance/policy-compliance/processes.md
@@ -19,7 +19,7 @@ ms.custom: governance
I've defined policies, I've provided an architecture guide. Now how do I monitor adherence to policy? If there is a violation, how do I enforce the policy?
--->
-After establishing your cloud policy statements and drafting a design guide, you'll need to create a strategy for ensuring your cloud deployment stays in compliance with your policy requirements. This strategy will need to encompass your Cloud Governance team's ongoing review and communication processes, establish criteria for when policy violations require action, and defining the requirements for automated monitoring and compliance systems that will detect violations and trigger remediation actions.
+After establishing your cloud policy statements and drafting a design guide, you'll need to create a strategy for ensuring your cloud deployment stays in compliance with your policy requirements. This strategy will need to encompass your cloud governance team's ongoing review and communication processes, establish criteria for when policy violations require action, and defining the requirements for automated monitoring and compliance systems that will detect violations and trigger remediation actions.
See the corporate policy sections of the [actionable governance journeys](../journeys/index.md) for examples of how policy adherence process fit into a cloud governance plan.
@@ -31,19 +31,19 @@ For small deployments consisting of development and test resources, policy requi
As a first step in defining your policy adherence strategy, evaluate how the processes discussed below can support your policy requirements. Determine how much effort is worth investing in these processes, and then use this information to establish realistic budget and staffing plans to meet these needs.
-## Establish Cloud Governance team processes
+## Establish cloud governance team processes
-Before defining triggers for policy compliance remediation, you need establish the overall processes that your team will use and how information will be shared and escalated between IT staff and the Cloud Governance team.
+Before defining triggers for policy compliance remediation, you need establish the overall processes that your team will use and how information will be shared and escalated between IT staff and the cloud governance team.
-### Assign Cloud Governance team members
+### Assign cloud governance team members
-Your Cloud Governance team will provide ongoing guidance on policy compliance and handle policy-related issues that emerge when deploying and operating your cloud assets. When building this team, invite staff from your organization that have expertise in areas covered by your defined policy statements and identified risks.
+Your cloud governance team will provide ongoing guidance on policy compliance and handle policy-related issues that emerge when deploying and operating your cloud assets. When building this team, invite staff from your organization that have expertise in areas covered by your defined policy statements and identified risks.
For initial test deployments this can be limited to a few system administrators responsible for establishing the basics of governance. As your governance processes mature, review the cloud guidance team's membership regularly to ensure that you can properly address new potential risks and policy requirements. Identify members of your IT and business staff with relevant experience or interest in specific areas of governance and include them in your teams on a permanent or ad-hoc basis as-needed.
### Reviews and policy iteration
-As additional resources and workloads are deployed, the Cloud Governance team will need to ensure that new workloads or assets comply with policy requirements. Evaluate new requirements from workload development teams to ensure their planned deployments will align with your design guides, and update your policies to support these requirements when appropriate.
+As additional resources and workloads are deployed, the cloud governance team will need to ensure that new workloads or assets comply with policy requirements. Evaluate new requirements from workload development teams to ensure their planned deployments will align with your design guides, and update your policies to support these requirements when appropriate.
Plan to evaluate new potential risks and update policy statements and design guides as needed. Work with IT staff and workload teams to evaluate new Azure features and services on an ongoing basis. Also schedule regular review cycles each of the five governance disciplines to ensure policy is up-to-date and being met.
@@ -55,11 +55,11 @@ As policy changes, regularly update documentation and training materials, and en
### Establish escalation paths
-If a resource goes out of compliance, who gets notified? If IT staff detect a policy compliance issue, who do they contact? Make sure the escalation process to the Cloud Governance team is clearly defined. Ensure these communication channels are kept updated to reflect staff and organization changes.
+If a resource goes out of compliance, who gets notified? If IT staff detect a policy compliance issue, who do they contact? Make sure the escalation process to the cloud governance team is clearly defined. Ensure these communication channels are kept updated to reflect staff and organization changes.
## Violation triggers and actions
-After defining your Cloud Governance team and its processes, you need to explicitly define what qualifies as compliance violations that will triggers actions, and what those actions should be.
+After defining your cloud governance team and its processes, you need to explicitly define what qualifies as compliance violations that will triggers actions, and what those actions should be.
### Define triggers
@@ -70,7 +70,7 @@ For each of your policy statements, review requirements to determine what consti
### Define actions
-Each violation trigger should have a corresponding action. Triggered actions should always notify an appropriate IT staff or Cloud Governance team member when a violation occurs. This notification can lead to a manual review of the compliance issue or kickoff a predefined remediation process depending on the type and severity of the detected violation.
+Each violation trigger should have a corresponding action. Triggered actions should always notify an appropriate IT staff or cloud governance team member when a violation occurs. This notification can lead to a manual review of the compliance issue or kickoff a predefined remediation process depending on the type and severity of the detected violation.
Some examples of violation triggers and actions:
diff --git a/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md b/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md
index 034f40ad45e..41ee6093f85 100644
--- a/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md
+++ b/docs/cloud-adoption/governance/policy-compliance/risk-tolerance.md
@@ -31,7 +31,7 @@ True business risks are based on the details of specific transformations. Severa
- **Budget control:** Cost models change in the cloud. This change can create risks associated with cost overruns or increases in the cost of goods sold (COGS), especially directly attributed operating expenses. When business works closely with IT, it is feasible to create transparency regarding costs and services consumed by various business units, programs, or projects. [Cost Management](../cost-management/index.md) provides examples of ways business and IT can partner on this topic.
-The above are a few of the most common risks mentioned by customers. The Cloud Governance team and the cloud adoption teams can begin to develop a risk profile, as workloads are migrated and readied for production release. Be prepared for conversations to define, refine, and manage risks based on the desired business outcomes and transformation effort.
+The above are a few of the most common risks mentioned by customers. The cloud governance team and the cloud adoption teams can begin to develop a risk profile, as workloads are migrated and readied for production release. Be prepared for conversations to define, refine, and manage risks based on the desired business outcomes and transformation effort.
## Understanding risk tolerance
@@ -77,7 +77,7 @@ These basic questions will lead to many more. After exploring a healthy dialogue
These questions over simplify the technical solutions needed to manage or remove risks. However, these questions communicate those solutions in ways the business can quickly integrate into a decision process.
-**Probability of loss:** Questions to determine how likely it is that the risk will become a reality. This is the most difficult area to quantify. Instead it is suggested that the Cloud Governance team create categories for communicating probability, based on the supporting data. The following questions can help create categories that are meaningful to the team.
+**Probability of loss:** Questions to determine how likely it is that the risk will become a reality. This is the most difficult area to quantify. Instead it is suggested that the cloud governance team create categories for communicating probability, based on the supporting data. The following questions can help create categories that are meaningful to the team.
- Has any research been done regarding the likelihood of this risk being realized?
- Can the vendor provide references or statistics on the likelihood of an impact?
@@ -85,7 +85,7 @@ These questions over simplify the technical solutions needed to manage or remove
- Look further, are there other companies in general that have been hit by this risk?
- Is this risk unique to something this company has done poorly?
-After answering these questions along with questions as determined by the Cloud Governance team, groupings of probability will likely emerge. The following are a few grouping samples to help get started:
+After answering these questions along with questions as determined by the cloud governance team, groupings of probability will likely emerge. The following are a few grouping samples to help get started:
- **No indication:** Not enough research has been completed to determine probability.
- **Low risk:** Current research indicates realizing the risk is unlikely.
diff --git a/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md b/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md
index a4e00faecae..c03d67dd22b 100644
--- a/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md
+++ b/docs/cloud-adoption/governance/policy-compliance/understanding-business-risk.md
@@ -41,9 +41,9 @@ During a cloud transformation, both the business and IT teams have an opportunit
## What is a business risk MVP?
-A **minimum viable product** is commonly used to define to define the smallest unit of something that can produce tangible value. In a business risk MVP, the Cloud Governance team starts with the assumption that some assets will be deployed to a cloud environment at some point in time. It's unknown what those assets are at the time, and the team may be unsure what types of data will be stored on those assets.
+A **minimum viable product** is commonly used to define to define the smallest unit of something that can produce tangible value. In a business risk MVP, the cloud governance team starts with the assumption that some assets will be deployed to a cloud environment at some point in time. It's unknown what those assets are at the time, and the team may be unsure what types of data will be stored on those assets.
-When planning for business risk, the Cloud Governance team could build for the worst case scenario and map every possible policy to the cloud. However, identifying all potential business risks for all cloud usage scenarios can take considerable time and effort, potentially delaying the implementation of governance to your cloud workloads. This is not advised, but is an option.
+When planning for business risk, the cloud governance team could build for the worst case scenario and map every possible policy to the cloud. However, identifying all potential business risks for all cloud usage scenarios can take considerable time and effort, potentially delaying the implementation of governance to your cloud workloads. This is not advised, but is an option.
Conversely, an MVP approach can allow the team to define an initial starting point and set of assumptions that would be true for most/all assets. This business risk MVP will support initial small scale or test cloud deployments, and then be used as a base for gradually identifying and remediating new risks as business needs arise or additional workloads are added to your cloud environment. This process allows you to apply governance throughout the cloud adoption process.
@@ -63,11 +63,11 @@ Once the Business Risk MVP is established, they can be converted to [policies](i
As your organization deploys more workloads to the cloud, development teams will make use of increasing amounts of cloud resources. At each iteration, new assets are created and staged. At each release, workloads are readied for production promotion. Each of these cycles has the potential to introduce previously unidentified business risks.
-Assuming a business risk MVP is the starting point for your initial cloud adoption efforts, governance can mature in parallel with your increasing use of cloud resources. When the Cloud Governance team operates in parallel with cloud adoption teams, the growth of business risks can be addressed as they are identified, providing a stable ongoing model for developing governance maturity.
+Assuming a business risk MVP is the starting point for your initial cloud adoption efforts, governance can mature in parallel with your increasing use of cloud resources. When the cloud governance team operates in parallel with cloud adoption teams, the growth of business risks can be addressed as they are identified, providing a stable ongoing model for developing governance maturity.
Each asset staged can easily be classified according to risk. Data classification documents can be built or created in parallel with staging cycles. Risk profile and exposure points can likewise be documented. Over time an extremely clear view of business risk will come into focus across the organization.
-With each iteration, the Cloud Governance team can work with the Cloud Strategy team to quickly communicate new risks, mitigation strategies, tradeoffs, and potential costs. This empowers business participants and IT leaders to partner in mature, well-informed decisions. Those decisions then inform policy maturity. When required, the policy changes produce new work items for the maturity of core infrastructure systems. When changes to staged systems are required, the cloud adoption teams have ample time to make changes, while the business tests the staged systems and develops a user adoption plan.
+With each iteration, the cloud governance team can work with the cloud strategy team to quickly communicate new risks, mitigation strategies, tradeoffs, and potential costs. This empowers business participants and IT leaders to partner in mature, well-informed decisions. Those decisions then inform policy maturity. When required, the policy changes produce new work items for the maturity of core infrastructure systems. When changes to staged systems are required, the cloud adoption teams have ample time to make changes, while the business tests the staged systems and develops a user adoption plan.
This approach minimizes risks, while empowering the team to move quickly. It also ensures that risks are promptly addressed and resolved before deployment.
diff --git a/docs/cloud-adoption/governance/resource-consistency/business-risks.md b/docs/cloud-adoption/governance/resource-consistency/business-risks.md
index fdbc42563a1..03ea980fbdd 100644
--- a/docs/cloud-adoption/governance/resource-consistency/business-risks.md
+++ b/docs/cloud-adoption/governance/resource-consistency/business-risks.md
@@ -31,7 +31,7 @@ Initial test deployments may not require much beyond adopting some cursory namin
The Resource Consistency discipline attempts to address core operational business risks. Work with your business and IT teams to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments.
-Risks will differ between organization, but the following serve as common risks that you can use as a starting point for discussions within your Cloud Governance team:
+Risks will differ between organization, but the following serve as common risks that you can use as a starting point for discussions within your cloud governance team:
- **Unnecessary operational cost.** Obsolete or unused resources, or resources that are overprovisioned during times of low demand, add unnecessary operational costs.
- **Underprovisioned resources.** Resources that experience higher than anticipated demand can result in business disruption as cloud resources are overwhelmed by demand.
diff --git a/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md b/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md
index 4edf75a8fc4..a3c8ca93a29 100644
--- a/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md
+++ b/docs/cloud-adoption/governance/resource-consistency/compliance-processes.md
@@ -25,17 +25,17 @@ The following is a set of example processes commonly involved in the Resource Co
**Deployment planning:** Before deploying any asset, perform a review to identify any new operational risks. Establish resource requirements and expected demand patterns, and identify scalability needs and potential usage optimization opportunities. Also ensure backup and recovery plans are in place.
-**Deployment testing:** As part of deployment, the Cloud Governance team, in cooperation with your cloud operations teams, will be responsible for reviewing the deployment to validate Resource Consistency policy compliance.
+**Deployment testing:** As part of deployment, the cloud governance team, in cooperation with your cloud operations teams, will be responsible for reviewing the deployment to validate Resource Consistency policy compliance.
**Annual planning:** On an annual basis, perform a high-level review of Resource Consistency strategy. Explore future corporate expansion plans or priorities and update cloud adoption strategies to identify potential risk increase or other emerging Resource Consistency needs. Also use this time to review the latest best practices for cloud Resource Consistency and integrate these into your policies and review processes.
**Quarterly review and planning:** On a quarterly basis perform a review of operational data and incident reports to identify any changes required in Resource Consistency policy. As part of this process, review changes in resource usage and performance to identify assets that require increases or decreases in resource allocation, and identify any workloads or assets that are candidates for retirement.
-This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to Resource Consistency as a discipline. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team.
+This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to Resource Consistency as a discipline. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team.
**Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest Resource Consistency policy requirements and guidance. As part of this process review and update any documentation or other training assets to ensure they are in sync with the latest corporate policy statements.
-**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with Resource Consistency policy. Review related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the Cloud Strategy team and each cloud adoption team to communicate overall performance and adherence to policy. The report is also stored for auditing and legal purposes.
+**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with Resource Consistency policy. Review related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is a report for the cloud strategy team and each cloud adoption team to communicate overall performance and adherence to policy. The report is also stored for auditing and legal purposes.
## Ongoing monitoring processes
@@ -45,7 +45,7 @@ Ensure that your IT teams have implemented automated monitoring systems for your
## Violation triggers and enforcement actions
-Because Resource Consistency policy compliance can lead to critical service disruption or significant cost overruns risks, the Cloud Governance team should have visibility into noncompliance incidents. Ensure IT staff have clear escalation paths for reporting these issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected.
+Because Resource Consistency policy compliance can lead to critical service disruption or significant cost overruns risks, the cloud governance team should have visibility into noncompliance incidents. Ensure IT staff have clear escalation paths for reporting these issues to the governance team members best suited to identify and verify that policy issues are mitigated once detected.
When violations are detected, you should take actions to realign with policy as soon as possible. Your IT team can automate most violation triggers using the tools outlined in the [Resource Consistency toolchain for Azure](toolchain.md).
@@ -54,7 +54,7 @@ The following triggers and enforcement actions provide examples you can referenc
- **Overprovisioned resource detected.** Resources detected using less than 60% of CPU or memory capacity should automatically scale down or deprovisioning resources to reduce costs.
- **Underprovisioned resource detected.** Resources detected using more than 80% of CPU or memory capacity should automatically scale up or provisioning additional resources to provide additional capacity.
- **Untagged resource creation.** Any request to create a resource without required meta tags will be rejected automatically.
-- **Critical resource outage detected.** IT staff are notified on all detected outages of mission-critical outages. If outage is not immediately resolvable, staff will escalate the issue and notify workload owners and the Cloud Governance team. The Cloud Governance team will track the issue until resolution and update guidance if policy revision is necessary to prevent future incidents.
+- **Critical resource outage detected.** IT staff are notified on all detected outages of mission-critical outages. If outage is not immediately resolvable, staff will escalate the issue and notify workload owners and the cloud governance team. The cloud governance team will track the issue until resolution and update guidance if policy revision is necessary to prevent future incidents.
## Next steps
diff --git a/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md b/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md
index d9ea3e56871..7ee6ad27a18 100644
--- a/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md
+++ b/docs/cloud-adoption/governance/resource-consistency/discipline-improvement.md
@@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better
*Figure 1 - Adoption phases of the incremental approach to cloud governance.*
-It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Resource Consistency governance capabilities.
+It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your cloud governance team will need to decide how much to invest in these activities to improve your Resource Consistency governance capabilities.
> [!CAUTION]
> Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model.
@@ -115,7 +115,7 @@ Once the transformation is complete, governance and operations must live on for
- Automatically apply and enforce governance requirements during future deployments.
- Evaluate underused resources and determine if they're worth continuing.
- Detect misalignments and anomalies between planned and actual resource usage.
-- Assist the cloud adoption teams and the Cloud Strategy team in understanding and resolving these anomalies.
+- Assist the cloud adoption teams and the cloud strategy team in understanding and resolving these anomalies.
- Determine if changes need to be made to Resource Consistency for billing and SLAs.
- Evaluate logging and monitoring tools to determine whether your on-premises, cloud gateway, or hybrid solution needs adjusting.
- For business units and geographically distributed groups, determine if your organization should consider using additional cloud management features such as [Azure management groups](/azure/governance/management-groups) to better apply centralized policy and meet SLA requirements.
diff --git a/docs/cloud-adoption/governance/resource-consistency/index.md b/docs/cloud-adoption/governance/resource-consistency/index.md
index 77977adee14..3b4aec392ef 100644
--- a/docs/cloud-adoption/governance/resource-consistency/index.md
+++ b/docs/cloud-adoption/governance/resource-consistency/index.md
@@ -19,7 +19,7 @@ Resource Consistency is one of the [Five Disciplines of Cloud Governance](../gov
> [!NOTE]
> Resource Consistency governance does not replace the existing IT teams, processes, and procedures that allow your organization to effectively manage cloud-based resources. The primary purpose of this discipline is to identify potential business risks and provide risk-mitigation guidance to the IT staff that are responsible for managing your resources in the cloud. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes.
-This section of the Cloud Adoption Framework outlines how to develop a Resource Consistency discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's Resource Consistency solutions.
+This section of the Cloud Adoption Framework outlines how to develop a Resource Consistency discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of the IT teams responsible for implementing and managing your organization's Resource Consistency solutions.
If your organization lacks in-house expertise in Resource Consistency strategies, consider engaging external consultants as a part of this discipline. Also consider engaging [Microsoft Consulting Services](https://www.microsoft.com/enterprise/services), the [Microsoft FastTrack](https://azure.microsoft.com/programs/azure-fasttrack) cloud adoption service, or other external cloud adoption experts for discussing how best to organize, track, and optimize your cloud-based assets.
@@ -32,7 +32,7 @@ Actionable policy statements and the resulting architecture requirements serve a
## Developing Resource Consistency governance policy statements
-The following six steps offer examples and potential options to consider when developing Resource Consistency governance. Use each step as a starting point for discussions within your Cloud Governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage Resource Consistency risks.
+The following six steps offer examples and potential options to consider when developing Resource Consistency governance. Use each step as a starting point for discussions within your cloud governance team and with affected business, and IT teams across your organization to establish the policies and processes needed to manage Resource Consistency risks.
diff --git a/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md b/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md
index c1ec772e828..0b23420fbe5 100644
--- a/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md
+++ b/docs/cloud-adoption/governance/resource-consistency/metrics-tolerance.md
@@ -61,7 +61,7 @@ Once you have a baseline, establish minimum benchmarks representing an unaccepta
- **Backup coverage trigger.** A company with _x%_ of mission-critical assets without up-to-date backups in place would benefit from an increased investment in the Resource Consistency discipline to ensure a consistent backup strategy.
- **Backup health trigger.** A company experiencing more than _x%_ failure of restore operations should invest in the Resource Consistency discipline to identify problems with backup and ensure important resources are protected.
-The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Resource Consistency discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your Cloud Governance team.
+The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Resource Consistency discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team.
## Next steps
diff --git a/docs/cloud-adoption/governance/resource-consistency/policy-statements.md b/docs/cloud-adoption/governance/resource-consistency/policy-statements.md
index f37c9dde84c..192475520c9 100644
--- a/docs/cloud-adoption/governance/resource-consistency/policy-statements.md
+++ b/docs/cloud-adoption/governance/resource-consistency/policy-statements.md
@@ -40,7 +40,7 @@ The following sample policy statements address common business risks related to
**Technical risk:** Arbitrary creation of subscriptions and management groups can lead to isolated sections of your cloud estate that are not properly subject to your governance policies.
-**Policy statement:** Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the Cloud Governance team. Approved changes will be integrated into a proper blueprint assignment.
+**Policy statement:** Creation of new subscriptions or management groups for any mission-critical applications or protected data will require a review from the cloud governance team. Approved changes will be integrated into a proper blueprint assignment.
**Potential design options:** Lock down administrative access to your organizations [Azure management groups](/azure/governance/management-groups) to only approved governance team members who will control the subscription creation and access control process.
@@ -54,12 +54,12 @@ The following sample policy statements address common business risks related to
## Deployment compliance
-**Technical risk:** Deployment scripts and automation tooling that is not fully vetted by the Cloud Governance team can result in resource deployments that violate policy.
+**Technical risk:** Deployment scripts and automation tooling that is not fully vetted by the cloud governance team can result in resource deployments that violate policy.
**Policy statement:** The following policies will be implemented:
-- Deployment tooling must be approved by the Cloud Governance team to ensure ongoing governance of deployed assets.
-- Deployment scripts must be maintained in central repository accessible by the Cloud Governance team for periodic review and auditing.
+- Deployment tooling must be approved by the cloud governance team to ensure ongoing governance of deployed assets.
+- Deployment scripts must be maintained in central repository accessible by the cloud governance team for periodic review and auditing.
**Potential design options:** Consistent use of [Azure Blueprints](/azure/governance/blueprints) to manage automated deployments allows consistent deployments of Azure resources that adhere to your organization's governance standards and policies.
diff --git a/docs/cloud-adoption/governance/security-baseline/business-risks.md b/docs/cloud-adoption/governance/security-baseline/business-risks.md
index 9de43d44945..3a640f28484 100644
--- a/docs/cloud-adoption/governance/security-baseline/business-risks.md
+++ b/docs/cloud-adoption/governance/security-baseline/business-risks.md
@@ -34,7 +34,7 @@ The Security Baseline discipline covers the corporate policies and manual proces
The Security Baseline discipline attempts to address core security-related business risks. Work with your business to identify these risks and monitor each of them for relevance as you plan for and implement your cloud deployments.
-Risks will differ between organization, but the following serve as common security-related risks that you can use as a starting point for discussions within your Cloud Governance team:
+Risks will differ between organization, but the following serve as common security-related risks that you can use as a starting point for discussions within your cloud governance team:
- **Data breach:** Inadvertent exposure or loss of sensitive cloud-hosted data can lead to losing customers, contractual issues, or legal consequences.
- **Service disruption:** Outages and other performance issues due to insecure infrastructure interrupts normal operations and can result in lost productivity or lost business.
diff --git a/docs/cloud-adoption/governance/security-baseline/compliance-processes.md b/docs/cloud-adoption/governance/security-baseline/compliance-processes.md
index 8a897b63ddf..309f524990e 100644
--- a/docs/cloud-adoption/governance/security-baseline/compliance-processes.md
+++ b/docs/cloud-adoption/governance/security-baseline/compliance-processes.md
@@ -13,7 +13,7 @@ ms.custom: governance
# Security Baseline policy compliance processes
-This article discusses an approach to policy adherence processes that govern [Security Baseline](./index.md). Effective governance of cloud security starts with recurring manual processes designed to detect vulnerabilities and impose policies to remediate those security risks. This requires regular involvement of the Cloud Governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation.
+This article discusses an approach to policy adherence processes that govern [Security Baseline](./index.md). Effective governance of cloud security starts with recurring manual processes designed to detect vulnerabilities and impose policies to remediate those security risks. This requires regular involvement of the cloud governance team and interested business and IT stakeholders to review and update policy and ensure policy compliance. In addition, many ongoing monitoring and enforcement processes can be automated or supplemented with tooling to reduce the overhead of governance and allow for faster response to policy deviation.
## Planning, review, and reporting processes
@@ -23,17 +23,17 @@ The best Security Baseline tools in the cloud are only as good as the processes
**Deployment planning:** Before deploying any workload or asset, perform a security review to identify any new risks and ensure all access and data security policy requirements are met.
-**Deployment testing:** As part of the deployment process for any workload or asset, the Cloud Governance team, in cooperation with your corporate security teams, will be responsible for reviewing the deployment to validate security policy compliance.
+**Deployment testing:** As part of the deployment process for any workload or asset, the cloud governance team, in cooperation with your corporate security teams, will be responsible for reviewing the deployment to validate security policy compliance.
**Annual planning:** On an annual basis, perform a high-level review of Security Baseline strategy. Explore future corporate priorities and updated cloud adoption strategies to identify potential risk increase and other emerging security needs. Also use this time to review the latest Security Baseline best practices and integrate these into your policies and review processes.
**Quarterly review and planning:** On a quarterly basis perform a review of security audit data and incident reports to identify any changes required in security policy. As part of this process, review the current cybersecurity landscape to proactively anticipate emerging threats, and update policy as appropriate. After the review is complete, align design guidance with updated policy.
-This planning process is also a good time to evaluate the current membership of your Cloud Governance team for knowledge gaps related to new or evolving policy and risks related to security. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team.
+This planning process is also a good time to evaluate the current membership of your cloud governance team for knowledge gaps related to new or evolving policy and risks related to security. Invite relevant IT staff to participate in reviews and planning as either temporary technical advisors or permanent members of your team.
**Education and training:** On a bimonthly basis, offer training sessions to make sure IT staff and developers are up-to-date on the latest security policy requirements. As part of this process review and update any documentation, guidance, or other training assets to ensure they are in sync with the latest corporate policy statements.
-**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with security policy. Review security related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is 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.
+**Monthly audit and reporting reviews:** On a monthly basis, perform an audit on all cloud deployments to assure their continued alignment with security policy. Review security related activities with IT staff and identify any compliance issues not already handled as part of the ongoing monitoring and enforcement process. The result of this review is 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.
## Ongoing monitoring processes
@@ -43,7 +43,7 @@ Ensure that your security and IT teams have implemented automated monitoring sys
## Violation triggers and enforcement actions
-Because security noncompliance can lead to critical and data exposure and service disruption risks, the Cloud Governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting security issues to the governance team members best suited to identify and verify that policy issues are mitigated.
+Because security noncompliance can lead to critical and data exposure and service disruption risks, the cloud governance team should have visibility into serious policy violations. Ensure IT staff have clear escalation paths for reporting security issues to the governance team members best suited to identify and verify that policy issues are mitigated.
When violations are detected, you should take actions to realign with policy as soon as possible. Your IT team can automate most violation triggers using the tools outlined in the [Security Baseline toolchain for Azure](toolchain.md).
diff --git a/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md b/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md
index 3d85afb4734..839bd4a093d 100644
--- a/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md
+++ b/docs/cloud-adoption/governance/security-baseline/discipline-improvement.md
@@ -21,7 +21,7 @@ This article outlines some potential tasks your company can engage in to better
*Figure 1 - Adoption phases of the incremental approach to cloud governance.*
-It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your Cloud Governance team will need to decide how much to invest in these activities to improve your Security Baseline governance capabilities.
+It's impossible for any one document to account for the requirements of all businesses. As such, this article outlines suggested minimum and potential example activities for each phase of the governance maturation process. The initial objective of these activities is to help you build a [Policy MVP](../journeys/index.md#an-incremental-approach-to-cloud-governance) and establish a framework for incremental policy evolution. Your cloud governance team will need to decide how much to invest in these activities to improve your Security Baseline governance capabilities.
> [!CAUTION]
> Neither the minimum or potential activities outlined in this article are aligned to specific corporate policies or third-party compliance requirements. This guidance is designed to help facilitate the conversations that will lead to alignment of both requirements with a cloud governance model.
diff --git a/docs/cloud-adoption/governance/security-baseline/index.md b/docs/cloud-adoption/governance/security-baseline/index.md
index 7ea821966fb..54b1c2b3fcc 100644
--- a/docs/cloud-adoption/governance/security-baseline/index.md
+++ b/docs/cloud-adoption/governance/security-baseline/index.md
@@ -14,12 +14,12 @@ layout: LandingPage
# Security Baseline discipline overview
-Security Baseline is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). Security is a component of any IT deployment, and the cloud introduces unique security concerns. Many businesses are subject to regulatory requirements that make protecting sensitive data a major organizational priority when considering a cloud transformation. Identifying potential security threats to your cloud environment and establishing processes and procedures for addressing these threats should be a priority for any IT Security or Cybersecurity team. The Security Baseline discipline ensures technical requirements and security constraints are consistently applied to cloud environments, as those requirements mature.
+Security Baseline is one of the [Five Disciplines of Cloud Governance](../governance-disciplines.md) within the [Cloud Adoption Framework governance model](../index.md). Security is a component of any IT deployment, and the cloud introduces unique security concerns. Many businesses are subject to regulatory requirements that make protecting sensitive data a major organizational priority when considering a cloud transformation. Identifying potential security threats to your cloud environment and establishing processes and procedures for addressing these threats should be a priority for any IT security or cybersecurity team. The Security Baseline discipline ensures technical requirements and security constraints are consistently applied to cloud environments, as those requirements mature.
> [!NOTE]
> Security Baseline governance does not replace the existing IT teams, processes, and procedures that your organization uses to secure cloud-deployed resources. The primary purpose of this discipline is to identify security-related business risks and provide risk-mitigation guidance to the IT staff responsible for security infrastructure. As you develop governance policies and processes make sure to involve relevant IT teams in your planning and review processes.
-This article outlines the approach to developing a Security Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your Cloud Governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your IT and security teams, especially those technical leaders responsible for implementing networking, encryption, and identity services.
+This article outlines the approach to developing a Security Baseline discipline as part of your cloud governance strategy. The primary audience for this guidance is your organization's cloud architects and other members of your cloud governance team. However, the decisions, policies, and processes that emerge from this discipline should involve engagement and discussions with relevant members of your IT and security teams, especially those technical leaders responsible for implementing networking, encryption, and identity services.
Making the correct security decisions is critical to the success of your cloud deployments and wider business success. If your organization lacks in-house expertise in cybersecurity, consider engaging external security consultants as a component of this discipline. Also consider engaging [Microsoft Consulting Services](https://www.microsoft.com/enterprise/services), the [Microsoft FastTrack](https://azure.microsoft.com/programs/azure-fasttrack) cloud adoption service, or other external cloud adoption experts to discuss concerns related to this discipline.
@@ -32,7 +32,7 @@ Actionable policy statements and the resulting architecture requirements serve a
## Developing Security Baseline governance policy statements
-The following six steps offer examples and potential options to consider when developing Security Baseline governance. Use each step as a starting point for discussions within your Cloud Governance team and with affected business, IT, and security teams across your organization to establish the policies and processes needed to manage security-related risks.
+The following six steps offer examples and potential options to consider when developing Security Baseline governance. Use each step as a starting point for discussions within your cloud governance team and with affected business, IT, and security teams across your organization to establish the policies and processes needed to manage security-related risks.
diff --git a/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md b/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md
index 3bc3d06e030..bac12372334 100644
--- a/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md
+++ b/docs/cloud-adoption/governance/security-baseline/metrics-tolerance.md
@@ -25,7 +25,7 @@ Every organization has different security environments and requirements and diff
- **Number of sensitive data stores:** Number of storage end points or databases that contain sensitive data and should be protected.
- **Number of unencrypted data stores:** Number of sensitive data stores that are not encrypted.
- **Attack surface:** How many total data sources, services, and applications will be cloud-hosted. What percentage of these data sources are classified as sensitive? What percentage of these applications and services are mission-critical?
-- **Covered standards:** Number of security standards defined by the Security team.
+- **Covered standards:** Number of security standards defined by the security team.
- **Covered resources:** Deployed assets that are covered by security standards.
- **Overall standards compliance:** Ratio of compliance adherence to security standards.
- **Attacks by severity:** How many coordinated attempts to disrupt your cloud-hosted services, such as through Distributed Denial of Service (DDoS) attacks, does your infrastructure experience? What is the size and severity of these attacks?
@@ -50,7 +50,7 @@ Once you have a baseline, establish minimum benchmarks representing an unaccepta
- **Patching trigger.** A company where deployed virtual machines or services where OS or software patches have not been applied in the last _x_ days. A Security Baseline discipline can be used to ensure patching is kept up-to-date within a required schedule.
- **Security-focused.** Some companies will have strong security and data confidentiality requirements even for test and experimental workloads. These companies will need to invest in the Security Baseline discipline before any deployments can begin.
-The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Security Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your Cloud Governance team.
+The exact metrics and triggers you use to gauge risk tolerance and the level of investment in the Security Baseline discipline will be specific to your organization, but the examples above should serve as a useful base for discussion within your cloud governance team.
## Next steps
diff --git a/docs/cloud-adoption/governance/security-baseline/policy-statements.md b/docs/cloud-adoption/governance/security-baseline/policy-statements.md
index f1e0310f9a1..66cb93e5979 100644
--- a/docs/cloud-adoption/governance/security-baseline/policy-statements.md
+++ b/docs/cloud-adoption/governance/security-baseline/policy-statements.md
@@ -25,7 +25,7 @@ The following sample policy statements address common security-related business
**Technical risk:** Assets that are not correctly identified as mission-critical or involving sensitive data may not receive sufficient protections, leading to potential data leaks or business disruptions.
-**Policy statement:** All deployed assets must be categorized by criticality and data classification. Classifications must be reviewed by the Cloud Governance team and the application owner before deployment to the cloud.
+**Policy statement:** All deployed assets must be categorized by criticality and data classification. Classifications must be reviewed by the cloud governance team and the application owner before deployment to the cloud.
**Potential design option:** Establish [resource tagging standards](../../decision-guides/resource-tagging/index.md) and ensure IT staff apply them consistently to any deployed resources using [Azure resource tags](/azure/azure-resource-manager/resource-group-using-tags).
diff --git a/docs/cloud-adoption/includes/governance/implementation-process.md b/docs/cloud-adoption/includes/governance/implementation-process.md
index 2ab1a2aa341..d6467775dcb 100644
--- a/docs/cloud-adoption/includes/governance/implementation-process.md
+++ b/docs/cloud-adoption/includes/governance/implementation-process.md
@@ -3,7 +3,7 @@
## 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.
+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
@@ -27,7 +27,7 @@ Given the lack of requirements, IT security is playing it safe and has required
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 demilitarized zone. 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.
+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
@@ -53,6 +53,6 @@ The following decisions represent the patterns to be enforced through the policy
**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: 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 in the journey, no policy enforcement is required in this area. This will be revisited during later evolutions.
\ No newline at end of file
diff --git a/docs/cloud-adoption/includes/governance/policy-statements.md b/docs/cloud-adoption/includes/governance/policy-statements.md
index 5d152d6c5be..f1edec7d9b5 100644
--- a/docs/cloud-adoption/includes/governance/policy-statements.md
+++ b/docs/cloud-adoption/includes/governance/policy-statements.md
@@ -8,7 +8,7 @@ The following policy statements establish the requirements needed to remediate t
Cost Management:
- For tracking purposes, all assets must be assigned to an application owner within one of the core business functions.
-- When cost concerns arise, additional governance requirements will be established with the Finance team.
+- When cost concerns arise, additional governance requirements will be established with the finance team.
Security Baseline:
@@ -34,7 +34,7 @@ Deployment Acceleration:
## Processes
-No budget has been allocated for ongoing monitoring and enforcement of these governance policies. Because of that, the Cloud Governance team has some ad hoc ways to monitor adherence to policy statements.
+No budget has been allocated for ongoing monitoring and enforcement of these governance policies. Because of that, the cloud governance team has some ad hoc ways to monitor adherence to policy statements.
-- **Education:** The Cloud Governance team is investing time to educate the cloud adoption teams on the governance journeys that support these policies.
-- **Deployment reviews:** Before deploying any asset, the Cloud Governance team will review the governance journey with the cloud adoption teams.
+- **Education:** The cloud governance team is investing time to educate the cloud adoption teams on the governance journeys that support these policies.
+- **Deployment reviews:** Before deploying any asset, the cloud governance team will review the governance journey with the cloud adoption teams.
diff --git a/docs/cloud-adoption/index.md b/docs/cloud-adoption/index.md
index df28db72104..9b7ad186e5c 100644
--- a/docs/cloud-adoption/index.md
+++ b/docs/cloud-adoption/index.md
@@ -1,8 +1,8 @@
---
title: "Microsoft Cloud Adoption Framework for Azure"
description: An overview of the Microsoft Cloud Adoption Framework for Azure.
-ms.service: architecture-center
-ms.subservice: enterprise-cloud-adoption
+ms.service: cloud-adoption-framework
+ms.subservice: overview
ms.custom: homepage
layout: LandingPage
ms.topic: landing-page
@@ -12,19 +12,19 @@ ms.date: 07/04/2019
# Microsoft Cloud Adoption Framework for Azure
-The Microsoft Cloud Adoption Framework for Azure is the One Microsoft voice for cloud adoption, consolidating and sharing best practices from Microsoft employees, partners, and customers. The framework gives enterprise customers tools, guidance, and narratives that help shape technology, business, and people strategies for driving desired business outcomes during their adoption effort. This lifecycle "product" aligns guidance to various stages and iterations of the typical cloud adoption lifecycle, ensuring easy access to the right guidance at the right time.
+The Cloud Adoption Framework is the One Microsoft approach to cloud adoption in Azure, consolidating and sharing best practices from Microsoft employees, partners, and customers. The framework gives enterprise customers a set of tools, guidance, and narratives that help shape technology, business, and people strategies for driving desired business outcomes during their adoption effort. This guidance aligns to various stages and iterations of the typical cloud adoption lifecycle, ensuring easy access to the right guidance at the right time.
![Cloud Adoption Framework overview](./_images/cloud-adoption-framework-overview.png)
## Getting started: Executive summaries
-To customers who are new to the Cloud Adoption Framework, we offer three introductory articles: [Migrate](./getting-started/migrate.md), [Innovate](./getting-started/innovate.md), and [Enable](./getting-started/enable.md). Each article provides an executive summary and a high-level journey through an enterprise's adoption lifecycle.
+For customers who are new to the Cloud Adoption Framework, we offer three introductory articles: [Migrate](./getting-started/migrate.md), [Innovate](./getting-started/innovate.md), and [Enable](./getting-started/enable.md). Each article provides an executive summary and a high-level journey through an enterprise's adoption lifecycle.
-For more specific guidance, see the following section, which lists and provides links to each of the various stages of the adoption lifecycle.
+For more specific guidance, continue reading for links to each stage of the adoption lifecycle.
-## Cloud Adoption Framework throughout the adoption lifecycle
+## Use the Cloud Adoption Framework throughout the adoption lifecycle
-Each section of the Cloud Adoption Framework maps to the preceding overview diagram. The list here can help you align to the section of the Cloud Adoption Framework that best matches your current stage in the cloud adoption lifecycle.
+Each section of the Cloud Adoption Framework maps to the overview diagram above. This list will help you align to the section that best matches your current stage in the cloud adoption lifecycle.
@@ -98,7 +98,7 @@ Each section of the Cloud Adoption Framework maps to the preceding overview diag