Instiq
Chapter 3 · Identity, privileged access, and compliance·v1.0.0·Updated 6/28/2026·~13 min

What's changed: Created SC-100 Chapter 3 (Domain 2 second-half: Entra ID/hybrid identity (Entra Connect, PHS/PTA/federation)/external identity (B2B/decentralized); Conditional Access/Entra ID Protection risk/CAE/protected actions/AD DS hardening/Key Vault/managed identity; enterprise access model/PIM/entitlement management/access reviews/CIEM (Entra Permissions Management)/PAW; regulatory compliance (requirements→controls)/Microsoft Purview/Microsoft Priva/Azure Policy/Defender for Cloud regulatory dashboard).

3.4Designing for regulatory compliance

Key points

Understand translating compliance requirements into security controls, addressing compliance via Microsoft Purview, privacy via Microsoft Priva, Azure Policy, and evaluating alignment with regulatory standards/benchmarks via Microsoft Defender for Cloud.

Compliance is not something to "scramble for at audit time"—it is woven into controls at design time. Architects translate legal/industry requirements into concrete security controls and into mechanisms that continuously prove them.

3.4.1Translate requirements into controls and evaluate

Map each regulatory requirement (e.g., ISO 27001, PCI DSS, national laws) to technical controls (encryption, access control, logging) and operational controls (procedures, reviews). Continuous evaluation of alignment is handled by the regulatory compliance dashboard in Microsoft Defender for Cloud, which auto-maps the environment to each standard’s controls and visualizes conformance (building on MCSB, adding multiple regulations). For "continuously evaluate/prove alignment to regulatory standards," start with Defender for Cloud.

3.4.2Purview (compliance) and Priva (privacy)

Microsoft Purview integrates data and compliance controls: data classification/labeling (information protection), data loss prevention (DLP), records management, insider risk, and Compliance Manager (improvement actions and score). Privacy-specific requirements (minimizing personal data, handling data-subject requests = DSR, risk assessment) are handled by Microsoft Priva. Architects design "regulator-required data protection and privacy" with Purview + Priva, and measure standard alignment with Defender for Cloud.

Exam point

Cues: "continuously evaluate/prove alignment to regulatory standards (regulatory dashboard)" = Defender for Cloud. "data classification/labels/DLP/compliance score" = Microsoft Purview. "privacy, personal data, data-subject requests (DSR)" = Microsoft Priva. "enforce/audit configuration compliance org-wide" = Azure Policy.

Warning

Watch the mix-ups: (1) Defender for Cloud (infra-config regulatory alignment), Purview (data/compliance controls), and Priva (privacy) have different roles—use together. (2) Azure Policy is a configuration guardrail, not data classification or DSR handling. (3) Design compliance through "proof (continuous evaluation)"—not a one-off audit response.

Diagram of translating requirements into technical/operational controls, continuous evaluation/proof via the Defender for Cloud regulatory dashboard, Purview (classification/DLP/compliance score), Priva (privacy/DSR), and Azure Policy.
Translate to controls and prove

3.4.3Section summary

  • Translate requirements into technical/operational controls; continuously evaluate alignment via Defender for Cloud’s regulatory dashboard
  • Purview = data classification/DLP/compliance score; Priva = privacy/personal data/DSR; Azure Policy = configuration guardrails
  • Design compliance through continuous proof (not a one-off audit response)

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To continuously evaluate/prove alignment to multiple standards (ISO 27001, PCI DSS) by auto-mapping the environment, which is best?

Q2. Which product handles data-subject requests (DSR) and privacy risk assessment?

Q3. Which product integrates data classification/labeling, DLP, and improvement scoring via Compliance Manager?

Q4. To enforce/audit org-wide resource configuration against specific regulatory requirements, which is best?

Q5. Which is the most appropriate way to think about compliance design?

Check your understandingPractice questions for Chapter 3: Identity, privileged access, and compliance