Why a profile comes before any product
In Level 1 you saw the whole Azure security and identity map on one page. The usual mistake now is to pick a service from that map because it sounds right. Experienced architects work the other way round. They first write down what the workload needs, then let those needs rule services in or out.
Think of it as a doctor's intake form. Nobody gets a prescription before their blood pressure, allergies and history are on record. The standard security profile is that intake form for a workload. You fill it in once and reuse it in every later service lesson and in the final scorecard.
The golden rule is to write concrete values, not adjectives. "Highly sensitive data" rules nothing in or out. "Contains UK customer bank details; PCI DSS applies; keys must sit in a single-tenant HSM we control" rules things out straight away.
The ten dimensions
| # | Dimension | Concrete question to answer |
|---|---|---|
| 1 | Identities | How many workforce users, customer users (monthly active), workload identities? |
| 2 | Privilege model | Who holds standing admin rights today? Which roles must be just-in-time? |
| 3 | Data classification | Which labels exist, and which data stores hold each label? |
| 4 | Encryption and key control | Platform-managed keys, customer-managed keys, or HSM-backed keys you alone control? |
| 5 | Compliance and residency | Which frameworks (by name and version)? Which regions may hold data? |
| 6 | Detection and response | Who answers an alert at 3 a.m., and how fast must they respond? |
| 7 | Logging and audit | GB per day by source, and how many days must logs be kept and searchable? |
| 8 | Zero trust posture | Is MFA enforced everywhere? Are device compliance and network location checked? |
| 9 | Team skills | Who knows KQL, Bicep/Terraform, Entra administration? How many hours a week? |
| 10 | Cost model | Budget per month, and who pays: per user, per resource, per GB, per operation? |
Worked example: a claims portal
Here is a filled-in profile for a sample workload, kept as YAML in the repo next to the infrastructure code so it is versioned and reviewed like code.
# security-profile.yaml: Contoso Claims Portal (profile v0.3, 2026-10-29)
identities:
workforce: 420 # staff with Entra accounts
customer_mau: 30000 # policyholders signing in each month (forecast)
workload: 14 # apps/functions needing identities (no secrets in code)
privilege:
standing_global_admins: 6 # today; target is 2 break-glass accounts only
jit_required: [Owner, User Access Administrator]
data_classification:
labels: [Public, Internal, Confidential, Restricted]
restricted_stores: [sql-claims-prod, st-claimdocs-prod]
encryption:
at_rest: customer-managed keys for Restricted stores
key_custody: single-tenant HSM, FIPS 140-3 Level 3, our admins only
compliance:
frameworks: [ISO/IEC 27001:2022, PCI DSS v4.0, UK GDPR]
residency: [uksouth, ukwest]
detection_response:
soc: in-house, business hours; MSSP out of hours
sev1_ack_minutes: 30
logging:
daily_gb: UNKNOWN # <- gap, see below
searchable_days: 90
total_retention_days: 365 # audit requirement
zero_trust:
mfa_all_users: true
device_compliance_required: staff only
team_skills:
kql: 1 engineer
terraform: 3 engineers
cost:
security_tooling_budget_month_usd: 9000
Turning answers into requirements
Each value becomes a short testable requirement, written as MUST or SHOULD. Here is how three of the values above translate:
R-04 MUST: Restricted-data keys live in a single-tenant HSM validated to
FIPS 140-3 Level 3, with administration limited to our staff.
-> Rules IN: Key Vault Managed HSM (single-tenant, FIPS 140-3 L3).
-> Rules OUT: Key Vault Standard (software-protected keys only).
R-01 SHOULD: Customer sign-in costs nothing at the forecast 30,000 MAU.
-> Entra External ID: first 50,000 MAU free (dated Oct 2026).
R-07 MUST: Security logs searchable for 90 days, retained for 365.
-> Sentinel-enabled workspace: first 90 days of analytics retention
included in the ingestion price; days 91-365 billed per GB-month.
Best practice: give every requirement an ID. Later lessons and the scorecard refer to R-04, not to "the key thing". When an auditor asks why you chose Managed HSM, the ID gives you the trail.
Spotting gaps before they cost you
A blank or UNKNOWN field is not a failure. A hidden gap is. The two gaps that most often turn later decisions into guesswork are log volume and key custody rules.
Log volume decides Sentinel cost almost on its own, because the analytics tier is billed per GB ingested. Commitment tiers start at 100 GB/day and save up to 52% on pay-as-you-go. So 20 GB/day and 200 GB/day lead to very different designs. Don't guess. Measure from an existing workspace:
# Billable GB per day by table over the last 30 days
az monitor log-analytics query \
--workspace "<workspace-customer-id-guid>" \
--analytics-query "Usage
| where TimeGenerated > ago(30d) and IsBillable == true
| summarize GB = sum(Quantity) / 1000 by DataType // Quantity is in MB
| extend GBPerDay = round(GB / 30, 2)
| top 10 by GB desc" \
--output table
Realistic output:
DataType GB GBPerDay
---------------- ------ --------
SigninLogs 96.0 3.20
AzureDiagnostics 540.0 18.00
SecurityEvent 312.0 10.40
That is about 32 GB/day, well under the first commitment tier. It also shows that AzureDiagnostics is the table to filter first.
Gotcha: key custody rules often live in a contract or a regulator letter, not in anyone's head. If nobody can say "must the provider be technically unable to reach our keys?", record it as a gap with an owner and a due date. The answer separates Key Vault Premium from Managed HSM, and it can change cost by an order of magnitude.
Record gaps the same way every time:
gaps:
- field: logging.daily_gb
owner: platform-team
due: 2026-11-12
method: Usage query on law-shared-prod, 30-day window
Trade-off: a perfect profile is never finished. Aim for "good enough to rule services in or out" and version it. v0.3 with two open gaps is more useful than v1.0 next quarter.
How the profile is used next
The steps always run in the same order. Fill in concrete values, then turn each into an ID'd requirement, then record gaps with owners, then feed the requirements into each service lesson and the weighted scorecard. From the next level on, every service will be checked against this file.
Key takeaways
- The profile has ten dimensions: identities, privilege, data classification, encryption and keys, compliance and residency, detection and response, logging, zero trust, team skills and cost model.
- Write numbers, names and versions, never adjectives. "30,000 MAU" rules services in or out; "lots of customers" does not.
- Turn each answer into a MUST/SHOULD requirement with an ID that can rule services in or out.
- Measure log volume with the
Usagetable instead of guessing; it drives SIEM cost. - Record unknowns as gaps with an owner and a date. Key custody and log volume are the classic ones.