Governance, risk and compliance concepts

A week after the incident review, Dana Whitcombe, Harrow & Finch's chief financial officer, asked Sunil Rao for something the security team had never been asked for in writing: a one-page summary of the company's top security risks, what was being done about each one and who was accountable. The board's audit committee wanted it before its December meeting. Sunil sat down with Ama Boateng on November 10, 2026, and said, "This is the part of the job people forget is part of the job. Firewalls are easy to explain. Governance, risk and compliance are what let the board decide how much to spend on them."

Governance, risk and compliance, usually shortened to GRC, is the set of practices an organization uses to set its rules, understand its risks and show that it meets its obligations. The SC-900 outline asks candidates to describe GRC concepts, and Microsoft's compliance products in Purview, covered in MSAZ-131, are built around them. This lesson explains each part and the related ideas of data residency, data sovereignty and data privacy.

Governance: rules and accountability

Governance is the system of rules, practices and processes an organization uses to direct and control its activities. In security, governance answers questions such as: Who decides which risks are acceptable? Which policies must every system follow? Who approves exceptions? How are decisions recorded and reviewed? Good governance turns security from a collection of individual opinions into decisions the organization has made deliberately and can explain.

At Harrow & Finch, governance for Project Skylight already existed in pieces. The board had approved the program in August 2026. A steering group met every two weeks. Renata Kowal had written cloud standards, such as which regions to use and how resources must be tagged, and some of them were enforced automatically with Azure Policy, as described in MSAZ-102. What was missing was a written information security policy approved by leadership and a clear owner for each major risk. Sunil's first governance action was to draft both for the steering group.

Governance usually takes the form of a hierarchy of documents. Policies state what must happen and why, in broad terms, and are approved by senior leadership: for example, "All access to company systems requires multifactor authentication." Standards describe specific requirements that implement a policy: for example, which authentication methods are acceptable. Procedures give the step-by-step instructions people follow, such as how the service desk resets a user's MFA registration. Guidelines offer recommended practice where flexibility is allowed.

Risk: understanding and treating threats

A risk is the possibility that a threat will exploit a weakness and cause harm. Three terms are worth separating. A threat is something that could cause harm, such as a phishing campaign or a ransomware group. A vulnerability is a weakness that a threat could exploit, such as accounts protected only by passwords. Impact is the harm that results if it happens, such as financial loss, disruption to stores or damage to customer trust. Risk combines how likely the event is with how severe its impact would be.

Risk management is the ongoing process of identifying risks, assessing them, deciding what to do about them and monitoring them. Many organizations keep a risk register, a list of risks with their likelihood, impact, owner and treatment. Sunil and Ama started Harrow & Finch's register with the risks the October incident had made obvious, plus a few the team had worried about for years.

Once a risk is assessed, there are four broad ways to treat it. Mitigate means reducing likelihood or impact with controls, for example adding MFA. Transfer means shifting some of the impact to another party, for example through cyber insurance or a contract. Accept means deciding, deliberately and with the right approval, to live with a risk because the cost of treating it outweighs the benefit. Avoid means stopping the activity that creates the risk, for example retiring an old system rather than exposing it to the internet. Accepting a risk is a legitimate choice, but only when the right person makes it knowingly; a risk nobody looked at is not accepted, it is ignored.

Ama wrote a small script to score the draft register. Each risk gets a likelihood and an impact from 1 to 5, and the product gives a simple score for ranking. Real risk methods are often more nuanced, but this scoring is common and easy to explain to a board.

register = [
    # (risk, likelihood 1-5, impact 1-5, owner)
    ("Account takeover through phishing", 5, 4, "Sunil Rao"),
    ("Ransomware on head office servers", 3, 5, "Renata Kowal"),
    ("Customer data exposed by a misconfigured storage account", 2, 5, "Renata Kowal"),
    ("Supplier payment fraud by email", 4, 4, "Dana Whitcombe"),
    ("Lost store tablet with cached data", 3, 2, "Grace Oduya"),
]
def level(score):
    return "high" if score >= 15 else "medium" if score >= 8 else "low"

for risk, like, imp, owner in sorted(register, key=lambda r: r[1] * r[2], reverse=True):
    score = like * imp
    print(f"{score:2d} {level(score):6s} {risk}  (owner: {owner})")

20 high   Account takeover through phishing  (owner: Sunil Rao)
16 high   Supplier payment fraud by email  (owner: Dana Whitcombe)
15 high   Ransomware on head office servers  (owner: Renata Kowal)
10 medium Customer data exposed by a misconfigured storage account  (owner: Renata Kowal)
 6 low    Lost store tablet with cached data  (owner: Grace Oduya)

Account takeover through phishing came out on top, with a score of 20. Supplier payment fraud, which depends on account takeover or a spoofed sender, came close behind. Seeing both near the top made it easy for Dana to support funding the identity work: the same controls reduce both risks. The register also gave each risk a named owner, which is a governance decision as much as a risk one. An owner is accountable for making sure the risk is treated, even if other people do the technical work.

Compliance: meeting obligations

Compliance means meeting the laws, regulations, contracts and standards that apply to the organization, and being able to show that you do. Obligations come from several directions. Laws and regulations are set by governments. Industry standards, such as the Payment Card Industry Data Security Standard (PCI DSS) for organizations that handle card payments, are required by contracts. Internal policies are set by the organization itself. Failing to comply can lead to fines, lawsuits, lost contracts and damaged reputation, but compliance is not the same as security: an organization can tick every box on a checklist and still be breached, and a secure organization still needs evidence to prove its compliance.

For Harrow & Finch, the most important obligations involve personal information about customers and staff, and card payments in stores and online. In the United States there is no single general federal privacy law for private companies. Instead, sector laws apply, such as HIPAA for health information held by health plans, health care providers and their business associates, along with state laws. Iowa's Consumer Data Protection Act, in force since 2025, is one of a growing number of state consumer privacy laws, and every state has a law requiring notice to people affected by certain data breaches. PCI DSS applies to card data in both countries.

Compliance work usually involves four activities: knowing which obligations apply, mapping each obligation to controls, collecting evidence that the controls work, and reporting the results to the people who need them, such as auditors, regulators and the board. Microsoft Purview Compliance Manager, covered in MSAZ-131, helps with all four by providing assessments mapped to common regulations and standards and tracking the actions needed to meet them.

Data residency, sovereignty and privacy

Three related terms often appear together in cloud compliance discussions, and the exam expects you to tell them apart. Data residency is about where data is physically stored. Some laws, contracts or company policies require certain data to stay in a particular country or region. Harrow & Finch's own policy is to keep customer and employee personal information in US Azure regions, Central US and East US 2. No general federal law requires this, but the company chose it to keep its compliance picture simple and to match commitments in some partner contracts.

Data sovereignty is the idea that data is subject to the laws of the country where it is collected, stored or processed. It explains why residency matters: data stored in another country may be reachable by that country's legal processes. Sovereignty questions can be complex because a cloud provider may be subject to laws in its home country even when data is stored elsewhere, which is one reason providers publish commitments about how they respond to government requests.

Data privacy is about how personal information is collected, used, shared and kept, and about people's rights over their own information. Privacy laws set rules on consent, transparency, purpose limits, retention and the rights of individuals to access or correct their data. Privacy depends on security, since you cannot keep information private if you cannot protect it, but it goes further, into questions of whether the organization should collect or use the data at all.

Roles in GRC

GRC is shared across the organization, not owned only by the security team. The board and senior leaders set the organization's appetite for risk and approve the main policies. Risk owners, usually business leaders such as Dana Whitcombe for financial risks or Grace Oduya for store operations, are accountable for the risks in their areas. The security and IT teams design and run controls and provide evidence. Internal audit and external auditors check, independently, that controls work as described. Keeping these roles separate matters: the people who run a control should not be the only ones who check it.

Sunil asked Ama to add a column to the register for the date each risk was last reviewed. A risk score that is a year old may no longer be true, and the column made stale entries easy to spot.

Bringing GRC together

The one-page summary Sunil and Ama sent to Dana on November 12 had three columns: the five highest risks with their scores and owners, the treatment chosen for each, and the policy or obligation it related to. Identity was the first line. The planned treatment was to mitigate it with MFA for every account, Conditional Access, privileged access controls and better monitoring, all of which are covered in the rest of this course. Dana forwarded it to the audit committee with a note: "This is the first time we can see the risks, the plan and who owns them on one page."

Sunil told Ama that the summary was not finished, and never would be. Risks change, new laws arrive, systems move to the cloud and controls drift. GRC is a cycle: set the rules, assess the risks, apply controls, check and report, then review and adjust. The team booked a quarterly risk review, starting in March 2027.