Regulatory Compliance and Data Sovereignty

The Architect’s Role in Compliance

A critical distinction for SC-100: you are NOT the compliance officer or the lawyer. You are the security architect who translates compliance requirements into technical architecture.

The workflow:

1. Compliance team identifies requirements — “We must comply with GDPR Article 17 (right to erasure)”
2. Architect translates to capabilities — “We need data discovery, classification, and a deletion workflow for personal data across M365 and Azure”
3. Architect designs the solution — “Deploy Purview Data Map for discovery, sensitivity labels for classification, and a content search + eDiscovery workflow for deletion requests”
4. Architect validates the implementation — “Compliance Manager shows improvement actions complete, and we can demonstrate the capability during an audit”

The exam tests step 2 and 3 — can you map a regulatory requirement to the right Microsoft capability?

Microsoft Purview Compliance Manager

Compliance Manager is the central dashboard for assessing and managing compliance posture. It provides:

Compliance Score

A numeric score (0-100%) representing your organization’s compliance posture. Higher is better. The score is based on how many improvement actions you’ve completed across your assessments.

How it’s calculated:

• Microsoft-managed controls (actions Microsoft takes — infrastructure encryption, physical security) contribute to your score automatically
• Customer-managed controls (actions YOU must take — configuring DLP policies, enabling audit logging) contribute when you mark them complete
• Shared controls (where both Microsoft and the customer share responsibility) contribute partially

Assessments

An assessment maps a specific regulation to your Microsoft 365 environment. Out-of-the-box assessments are available for major frameworks (GDPR, HIPAA, ISO 27001, PCI DSS, NIST 800-53).

Each assessment contains:

• Controls — specific requirements from the regulation
• Improvement actions — what you need to do to satisfy the control
• Testing status — whether the action has been implemented and tested
• Evidence — documentation and proof of implementation

Improvement Actions

Concrete steps you can take to improve compliance. Each action shows:

• Which regulations it satisfies (one action may satisfy controls across multiple frameworks)
• Implementation status (not implemented, in progress, implemented)
• Test status (not assessed, passed, failed)
• Points value (how much it contributes to the compliance score)

Architect’s insight: Improvement actions that satisfy controls across MULTIPLE regulations should be prioritized — they give you the most compliance coverage per implementation effort.

Translating Compliance to Security Capabilities

The core skill for SC-100: given a regulatory requirement, recommend the right Microsoft capability.

Common Translations

“We must encrypt data at rest” → Azure Storage Service Encryption (automatic), Azure Disk Encryption, SQL TDE, Microsoft 365 service encryption with Customer Key (for additional control)

“We must control who accesses personal data” → Entra ID RBAC, Conditional Access, sensitivity labels with encryption, Azure RBAC for storage accounts

“We must detect and prevent data leakage” → Microsoft Purview DLP policies (Exchange, SharePoint, OneDrive, Teams, Endpoint), endpoint DLP for devices

“We must retain data for 7 years” → Microsoft Purview retention policies and retention labels, Azure Immutable Blob Storage for archival

“We must be able to find and delete personal data on request” → Microsoft Purview Content Search, eDiscovery, Data Subject Access Requests (DSAR), Purview Data Map for data estate discovery

“We must audit all administrative actions” → Microsoft 365 Unified Audit Log, Azure Activity Log, Sentinel for centralized audit log collection and long-term retention

“We must classify sensitive data” → Microsoft Purview sensitivity labels (manual + automatic classification), trainable classifiers, exact data matching

Data Residency vs Data Sovereignty

These terms are related but distinct, and the SC-100 exam tests the difference.

Data Residency vs Data Sovereignty

Aspect	Data Residency	Data Sovereignty
Definition	Data is stored at rest in a specified geographic location (country or region)	Data is stored in AND subject to the laws and governance of a specific jurisdiction
Scope	Where the data physically lives — its storage location	Where the data lives PLUS which government's laws apply to it, who can access it, and under what authority
Example	EU customer data is stored in Azure West Europe (Netherlands) — satisfies GDPR data residency	Government classified data must be in a sovereign cloud operated by cleared personnel under national jurisdiction — not just in the right country
Microsoft Solution	Azure region selection, Multi-Geo for M365, EU Data Boundary	Azure Government (US), Azure China (operated by 21Vianet), national/specialized sovereign cloud environments
Key Difference	About LOCATION of data storage	About LEGAL JURISDICTION and GOVERNANCE over the data

Azure Regions and Data Residency

When you create Azure resources, you select a region. Data stored in that resource stays in that region (with documented exceptions for some services). For Microsoft 365, Multi-Geo allows you to specify which region stores each user’s mailbox and OneDrive data.

EU Data Boundary: Microsoft’s commitment that customer data for EU customers is stored and processed within the EU for in-scope services. This covers Microsoft 365, Azure, Dynamics 365, and Power Platform core services. Note: the EU Data Boundary applies to defined in-scope services and is subject to documented limited exceptions/transfers (e.g., for security operations, support scenarios). It is an important residency commitment but not an unconditional guarantee that no data ever leaves the EU.

Sovereign Clouds

For the highest data sovereignty requirements, Microsoft operates isolated cloud environments:

Azure Government (US): Physically and logically separated from commercial Azure. Operated by screened US persons. Meets FedRAMP High, DoD IL2-5, CJIS, IRS 1075. Government agencies that cannot use commercial cloud use this environment.

Azure China (21Vianet): Operated by a Chinese company (21Vianet) in compliance with Chinese regulations. Physically and logically separated from global Azure. Chinese data sovereignty requirements mandate this for many organisations.

Architecture implication: Sovereign clouds are NOT connected to commercial Azure. You cannot seamlessly replicate data between commercial Azure and Azure Government. If an organization operates in both, this is a significant architecture constraint.

---

💰 Ingrid Maps PCI DSS + GDPR to Unified Controls

Ingrid Svensson at Nordic Capital Partners faces a common challenge: multiple overlapping regulatory frameworks. As a financial services firm handling European clients’ credit card data, they must comply with both PCI DSS (payment card industry) and GDPR (EU data protection).

“The compliance team gave me 847 control requirements across both frameworks,” Ingrid tells Harald Eriksen. “If we treat each one independently, we’ll be implementing the same control twice under different names.”

Ingrid’s approach:

1. Map overlapping controls: Both PCI DSS and GDPR require encryption of personal/cardholder data at rest and in transit. One implementation satisfies both.
2. Use Compliance Manager assessments: Add both PCI DSS and GDPR assessments. Compliance Manager shows which improvement actions satisfy controls in BOTH frameworks.
3. Prioritize high-impact actions: DLP policies that prevent credit card numbers from being shared externally satisfy the need to prevent unauthorized data exfiltration AND GDPR Article 5 (data minimization). Storage encryption (Azure Storage Encryption, SQL TDE) satisfies PCI DSS Requirement 3/3.4 (render stored cardholder data unreadable) AND GDPR Art 32 (security of processing). One encryption strategy, two frameworks satisfied.

Ingrid’s unified control mapping:

• Data encryption (Azure Storage encryption, SQL TDE, M365 encryption) → PCI DSS Req 3.4 + GDPR Art 32
• Access control (RBAC, Conditional Access, PIM) → PCI DSS Req 7 + GDPR Art 25 (data protection by design)
• Audit logging (Unified Audit Log, Sentinel retention) → PCI DSS Req 10 + GDPR Art 30 (records of processing)
• Data loss prevention (Purview DLP for credit card numbers and personal data) → prevents unauthorized exfiltration/sharing + GDPR Art 5
• Vulnerability management (Defender for Endpoint TVM, Azure Defender) → PCI DSS Req 6 + GDPR Art 32 (security of processing)

“By mapping the overlap, we reduced 847 unique requirements to 340 unique controls,” Ingrid reports. “The implementation effort dropped by 60% because most controls satisfy both frameworks simultaneously.”

---

🏛️ Torres Tackles Government Data Sovereignty

Commander Torres faces the strictest data sovereignty requirements. The Department of Federal Systems processes data classified at multiple levels, and regulations require that classified data never leaves sovereign jurisdiction.

“We can’t use commercial Azure for our classified workloads,” Torres explains to Colonel Reeves. “The data must reside in Azure Government, operated by cleared US persons, in data centres with physical security controls that meet our classification requirements.”

Torres’s sovereign architecture:

• Azure Government for IL4-5 workloads — all classified processing and storage in Azure Government regions
• Commercial Azure for unclassified workloads — public-facing websites, recruitment systems, and general IT
• NO connectivity between the environments — no VPN, no peering, no data replication. The air gap is intentional and regulatory.
• Separate Entra ID tenants — one in Azure Government for classified users, one in commercial for unclassified. Users who need both have two identities.
• Separate Sentinel instances — one in each cloud for log collection and incident response. No cross-cloud correlation (classified logs cannot leave the sovereign environment).

“What about our staff who work on both classified and unclassified systems?” Specialist Diaz asks.

“They have two accounts, two devices,” Torres replies. “Their classified PAW connects to Azure Government only. Their unclassified laptop connects to commercial Azure only. The tiered access model we designed in the privileged access module enforces this separation. There’s no shortcut — sovereignty means complete isolation.”

Security and Compliance Policy Enforcement

Two complementary policy engines enforce compliance at different layers:

Azure Policy (Infrastructure Compliance)

Azure Policy evaluates Azure resources against rules and enforces compliance at the infrastructure level.

What Azure Policy enforces:

• Allowed resource types and locations (prevent resources from being created outside approved regions)
• Required encryption settings (deny storage accounts without encryption)
• Required network configurations (deny public endpoints)
• Required tagging (all resources must have owner and cost centre tags)
• Configuration standards (VMs must have backup enabled, SQL must have TDE)

Enforcement modes:

• Deny: Prevent non-compliant resource creation or modification
• Audit: Allow the resource but flag it as non-compliant in the compliance dashboard
• DeployIfNotExists: Automatically deploy a remediation (e.g., automatically enable diagnostic settings)
• Modify: Automatically modify resources to add or change properties (e.g., add required tags)

Purview Policies (Data Governance)

Microsoft Purview extends policy enforcement to the data layer — sensitivity labels, DLP, retention, and information barriers.

What Purview policies enforce:

• Sensitivity label requirements (auto-label documents containing credit card numbers)
• Data loss prevention (block emails containing health records sent externally)
• Retention (retain financial records for 7 years, then auto-delete)
• Information barriers (prevent investment banking from sharing data with trading)
• Insider risk management (detect unusual data access patterns)

Major Regulatory Frameworks (What the Architect Needs to Know)

You don’t need to memorize regulation articles, but you must understand the architectural implications of each framework.

GDPR (General Data Protection Regulation):

• Applies to organizations processing EU residents’ personal data, regardless of where the organization is based
• Key architectural implications: data residency in EU, right to erasure (data discovery + deletion capability), data protection impact assessments, breach notification within 72 hours, data processing agreements with processors
• Microsoft tools: EU Data Boundary, Purview DSAR, Purview DLP, Compliance Manager GDPR assessment

HIPAA (Health Insurance Portability and Accountability Act):

• Applies to organizations handling Protected Health Information (PHI) in the US
• Key architectural implications: encryption of PHI, access controls with audit trails, minimum necessary access, business associate agreements (BAAs) with cloud providers, incident response procedures
• Microsoft tools: Purview sensitivity labels for PHI, DLP policies for health data, Defender for Cloud regulatory compliance assessment

PCI DSS (Payment Card Industry Data Security Standard):

• Applies to organizations handling credit card data
• Key architectural implications: network segmentation, encryption of cardholder data, strong access control, regular vulnerability scanning, penetration testing, audit logging
• Microsoft tools: Azure network security, Azure Key Vault, Defender for Endpoint TVM, Sentinel for audit, Compliance Manager PCI DSS assessment

SOX (Sarbanes-Oxley Act):

• Applies to publicly traded companies in the US — focuses on financial reporting integrity
• Key architectural implications: audit trails for financial systems, access controls with separation of duties, change management, data retention for financial records
• Microsoft tools: Purview audit, PIM for separation of duties, Azure DevOps for change management

ISO 27001 (Information Security Management System):

• International standard for information security management — not legally mandated but often contractually required
• Key architectural implications: risk assessment methodology, security controls across 14 domains, continuous improvement cycle, annual audits
• Microsoft tools: Compliance Manager ISO 27001 assessment (maps all 114 controls to Microsoft capabilities)

SC-100 Exam Strategy: Regulatory Compliance

Question

Click or press Enter to reveal answer

Answer

Click to flip back

Knowledge Check

A multinational company has customers in the EU and processes their personal data in Microsoft 365 and Azure. GDPR requires that personal data of EU residents be stored within the EU. The company also has US operations using the same Microsoft 365 tenant. What is the BEST architectural approach?

AA. Deploy a separate Microsoft 365 tenant for EU operations with Azure resources in EU regionsBB. Use a single tenant with Multi-Geo for Microsoft 365 (EU users' data in EU regions) and select EU Azure regions for EU workloads, leveraging the EU Data BoundaryCC. Migrate all company data to EU Azure regions to satisfy the strictest requirement globallyDD. Deploy Azure Government for all EU data since it provides the highest compliance level

Check Answer

Knowledge Check

Torres needs to ensure that Azure resources for classified government workloads are ONLY created in Azure Government regions and ONLY with approved configurations (encryption enabled, no public endpoints). Which enforcement mechanism should the architect recommend?

AA. Microsoft Purview sensitivity labels that auto-classify government dataBB. Azure Policy with deny effect — restrict allowed resource locations and enforce configuration standardsCC. Conditional Access policies that block access from non-approved locationsDD. Azure Blueprints with pre-approved resource templates only

Check Answer

Knowledge Check

Ingrid discovers that PCI DSS requires encryption of stored cardholder data (Req 3.4), access logging for cardholder data access (Req 10), and protection against unauthorized data sharing (Req 3). GDPR similarly requires encryption of personal data (Art 32), audit logging of processing activities (Art 30), and protection against unauthorized data transfers (Art 5). What should the architect recommend?

AA. Implement separate controls for each framework to ensure complete compliance with eachBB. Map overlapping requirements and implement unified controls — one encryption strategy, one logging strategy, one DLP strategy that satisfies both frameworks simultaneouslyCC. Focus on PCI DSS first since it has specific technical requirements, then add GDPR controls laterDD. Use Compliance Manager for PCI DSS only and manual controls for GDPR

Check Answer

🎬 Video coming soon

---

Next up: Security Posture Management — We move to Domain 3, where we’ll design security posture strategies using Microsoft Defender for Cloud, Secure Score, and cloud security posture management across multi-cloud environments.