Security Governance, Risk, and Compliance (GRC)

Implementation of Information Security Governance may be subject to multiple priorities and constraints, including financial constraints. To understand the situation for your organization specifically, consider the three major factors below:

Security Governance, Risk, and Compliance (GRC)

Governance: security for your organization must not only be correctly designed and applied but must also be tracked and audited.

Risk: your organization will have its own set of risks, determined by the different natures and levels of security threats that it must face and the consequences of such threats succeeding.

Compliance: while some regulations and requirements are applicable to all, others may only be relevant to certain industry sectors or business activities. You need to know which ones concern your organization.

Considering these factors allows you to define appropriate security standards for your business, and to manage them during their lifecycle:

  • Definition of your security standards according to internal factors (like the nature and objectives of your business) and external factors (like the threat environment and regulations).
  • Improvement of your security standards by continually working to shape them for lower risks and better return on investment.
  • Maintenance of your security standards by monitoring and auditing compliance, and ensuring your standards are properly respected.

Proactive investment in best practices

Ideally, your organization will fully implement best cloud security practices before its cloud computing activities start. In practice, circumstances may put pressure on you to balance security with business needs, for example, or complete security afterwards instead of before. However, certain best practices can and should always be observed from the start, including:

  • Prioritize security for all systems with high business impact and high exposure, including systems that attackers could use as stepping-stones to high-impact systems.
  • Identify relevant, valuable quick wins in which security is easily improved because your organization already has the necessary resources readily available.

Remember to consider all connected resources, such as Azure environments that link to your production network. You may need to use suitable IT tools to discover all such connected resources.

Clearly assign responsibility

Responsibilities for Azure functions may map onto existing teams in the following way:

  • Network security: network security team
  • Network management: network operations team
  • Server endpoint security: IT operations, security team, or both
  • Incident monitoring and response: security operations team
  • Policy management: GRC team, architecture team
  • Identify security and management: security and identity teams together.

The mapping of responsibilities for your business will depend on how your teams and IT personnel are organized.

Enterprise segmentation strategy

Isolating (segmenting) groups of resources to contain and detect attackers helps contain risk while enhancing business operations. However, bottom-up segmentations have often had a complex technical focus, causing them to fail to align with business needs. Instead, a unified enterprise segmentation strategy should be preferred, built simply and clearly around business goals and risks. Segments should be contained in a perimeter based on zero trust, i.e. with no assumption of security assurances. Any more detailed approach such as network micro-segmentation should only be done afterwards.

A viable enterprise segmentation strategy will enable operations, contain risk by isolating systems and workloads to prevent compromise of other assets, and allow monitoring of key parameters like unusual traffic or account usage to detect possible breach of segments.

Security team visibility

Granting privileges for your security teams is a balance between allowing team members to do their jobs and preventing possible misuse of power. Read-only access to the technical environment is one approach. Permission for this access can be assigned in Azure using the root management group for teams with overall risk management responsibility and segment management groups for teams with specific scopes of responsibilities.

Managing permissions

In general, permission should only be granted following the principle of least privilege required to meet operational needs. Clear guidance must be given to those implementing permissions.

Core services

These include shared services for the entire organization, such as Active Directory Domain Services, DNS/DHCP, and infrastructure level system management tools. The security team responsible for these services will need read-only access across technical domains.

Security policy management privileges will be granted on an as needed basis:

  • The central IT department will have privileges for the creation, modification, and deletion of resources at the infrastructure level, for example, virtual machines and storage.
  • Network resources responsibilities should be assigned to one central networking organization.
  • Note that privileges for managing a core service are often granted via the application itself: additional Azure resource privileges for DevOps teams, for example, are not needed.
  • Define a service admin role specifically for emergencies and possibly for initial set-up, but do not use this role for daily tasks.


In a similar way to security for core services, assign read-only access for security teams across the segment, while granting minimal policy management privileges only to those roles that need them.

  • When IT operations span resources, the corresponding segments can be managed by the central IT department or by the IT team of the independent business unit that is managing those resources.
  • Segment network resources should be managed as for core services, by the same central networking organization.
  • DevOps teams can manage resources via the applications that each team uses: sizes and complexities of your applications and teams will determine the appropriate roles and permissions, as will your overall team and organizational culture.
  • As for core services, a service admin account (“break-glass account”) can be defined for handling emergencies.

Permissions should be assigned using built-in roles where possible. You should only define custom roles if necessary. Permissions should also be assigned at management group level for a segment, instead of via individual subscriptions. Consider security manager group membership for smaller organizations where security teams may have responsibilities extending over several segments.

Management group segmentation

Management groups let you manage resources consistently and efficiently. However, the flexibility of management groups means a risk of creating an overly complex design that may create confusion and compromise security. In principle, structure your management groups in a simple way to drive your enterprise segmentation model. Use the root management group for consistency across your enterprise and test changes before implementation.

Virtual machine (VM) security

Prompt application of security updates is mandatory for virtual machines, as is operational discipline for avoiding open management ports, common passwords, and other favorite targets by hackers. The Azure Security Center can find exposed VMs and identify and apply necessary security updates.

Your VM security can also be improved by restricting and monitoring direct internet connectivity. You can ensure that traffic is directed via approved egress points and centralize the granting of new permissions, by using a model centered on enterprise-level networking and permissions. This also helps you to maintain security standards across the organization.

Designate an appropriate security contact to receive Azure incident notifications for VMs used by your organization. As roles change, remember to remove accounts from permissions accordingly, either manually or by automating the procedure with functionality such as Azure AD access reviews.

Azure Secure Score, part of Azure Security Center and available at no additional charge, checks the security posture of machines and associated resources. You can use its recommendations for remediation, starting with those of the highest priority.

Security automation

Automation frees up time for your security teams from basic, low-value manual tasks, as well as reducing the potential for human error. Azure has native automation capabilities. The Azure Blueprint Service enables resource deployment and governance using built-in configurations, your own custom configurations, or Resource Manager scripts.

Benchmarks and compliance

Benchmarks help you compare the security of your organization with that of other organizations, identify security gaps, and improve security posture.

Security compliance requirements can affect organizations of all sizes. Corresponding security policies will need to be audited and enforced. Azure Policy lets you create and manage policies to enforce compliance. This functionality is based on Azure Resource Manager capabilities in Azure, and it can be assigned via Azure Blueprints.

Identity risk

Stolen identities are prime causes of security incidents. Attackers may start with a low-level access to leverage access to identities with greater privileges. Azure Active Directory (AD) can detect suspicious activity related to your user accounts, enabling you to uncover potentially compromised identities and remediate the associated risks.

Reported risk events linked to identities can be reviewed as part of Azure AD’s security reports and as part of the reporting available from Azure Active Directory Identity Protection. For programmatic access to security detections using Microsoft Graph, you can use the Identity Protection risk events API. Whichever capability you use, you can then manually manage each reported account or define a user risk policy to force password change.

Additional security operations

Further activities to improve the security posture of your organization include:

  • Penetration testing through simulations of one-time attacks or of persistent threat actors.
  • Discovery and disablement of protocols with weak security, by using Azure Sentinel’s Insecure Protocol Dashboard or a similar third-party tool.
  • Consideration of specialized security capabilities, for example to meet specific regulatory requirements, via solutions like hardware security modules or confidential computing.

In Summary…

In determining the security priorities and constraints for your enterprise or organization, consider governance, risk, and compliance (GRC). Using these three factors, you can suitably define and manage security standards. Remember also to clearly assign security responsibilities, give appropriate guidance, and ensure that permissions are only granted as needed and following the principle of least privilege.

Azure offers a range of tools and capabilities for improving and maintaining security, including the Azure Security Center and Azure Active Directory. Azure also has native automation capabilities, with tools and services like Azure Blueprint Service. Suitable use of these different capabilities helps you to remediate or prevent exposed virtual machines, detect and remediate suspicious user activity, and improve overall security posture.

About the Author:

Jason is a 1st Vice President, Cloud Solutions Architect at City National Bank of Florida headquartered in Miami, Florida. Jason has been working with computers ever since he bought his first, a Timex/Sinclair 1000 in 6th grade and taught himself BASIC programming. Jason was educated at the University of Cincinnati and the Massachusetts Institute of Technology – Sloan School of Management. He is a Microsoft Azure MVP (2010-present), a young adult author, and a cellist.


Milgram, J. (2020). Security Governance, Risk, and Compliance (GRC). Available at: [Accessed: 20th May 2020].

Check out more great Azure content here

Share this on...

Rate this Post: