Azure security is a set of responsibilities, not one product
Microsoft Azure provides platform security capabilities, but the customer still owns important responsibilities for identities, data, configuration, access, workloads, and operating processes depending on the service model. Microsoft’s shared responsibility guidance is a useful starting point because it prevents a common assumption that moving to cloud transfers all security responsibility to the provider.
A practical Azure security program crosses Microsoft Entra, Azure networking, resource configuration, Microsoft Defender for Cloud, monitoring and SIEM, data protection, secrets, backup and recovery, vulnerability management, incident response, policy, and governance. The exact scope should follow the organization’s risk and workload profile.
| Security domain | Question to answer | Representative evidence |
|---|---|---|
| Identity and privilege | Who can access Azure and how is privilege controlled? | Role assignments, PIM, MFA/Conditional Access, service principals |
| Cloud posture | Which configurations create material exposure? | Defender recommendations, policy, secure score context, asset inventory |
| Workload protection | Which workloads need runtime threat protection? | Defender plan coverage, alerts, vulnerability findings |
| Network exposure | Which paths are public or overly broad? | NSGs, firewalls, private endpoints, routes, internet exposure |
| Logging and detection | Can important activity be detected and investigated? | Activity logs, diagnostic settings, Sentinel/Defender telemetry |
| Data and secrets | How are sensitive data and credentials protected? | Key Vault, encryption, data classification, secret lifecycle |
| Resilience | Can destructive or ransomware events be recovered from? | Backup, restore tests, immutability/protection settings, RPO/RTO |
| Incident response | Who coordinates containment and recovery? | Runbooks, escalation, roles, evidence retention |
Assessment, roadmap, remediation, and operations are different services
Security engagements become confusing when these stages are blended. An assessment reviews evidence and identifies findings. A roadmap prioritizes recommended work and dependencies. Remediation changes the environment. Ongoing security operations monitor, investigate and maintain controls. A customer may need one stage or all four, but the scope should use precise verbs.
| Stage | Purpose | Typical output | What it does not prove |
|---|---|---|---|
| Assessment | Identify security gaps and risk | Evidence-backed findings and priorities | That the gap is fixed |
| Roadmap | Sequence the response | Workstreams, dependencies, owners | That funding or implementation is approved |
| Remediation | Implement agreed changes | Configured/tested controls | That the control will stay effective forever |
| Operations | Maintain and respond | Monitoring, review cadence, incident process | That architecture no longer needs improvement |
Decision rule: never treat the number of security findings as the priority list. Prioritize by exploitability, exposure, asset criticality, business impact, and the control dependencies that unlock the most risk reduction.
Start with identity because control-plane access changes everything
Azure administrative access deserves early attention because a highly privileged identity can bypass many resource-level protections. Review permanent role assignments, emergency accounts, privileged activation, MFA, Conditional Access, service principals, managed identities, secrets, and the joiner-mover-leaver process.
Least privilege should be practical. The goal is not to make every administrative task slow; it is to reduce standing privilege, separate duties where risk justifies it, and make elevation auditable. Microsoft Entra Privileged Identity Management can support just-in-time and time-bound privileged access where the licensing and environment support it.
Use Defender for Cloud posture data as evidence, not as the whole assessment
Microsoft Defender for Cloud continuously assesses cloud resources and generates security recommendations. Microsoft’s current Defender for Cloud recommendation guidance describes risk prioritization that considers factors such as internet exposure, sensitive data, lateral movement and attack paths when the applicable Defender CSPM capabilities are enabled. That context can make remediation more meaningful than a flat severity list.
Defender for Cloud is a strong source of evidence, but a cloud security assessment should also examine architecture, identity, operational history, logging, backup, network design, business criticality and organizational standards. A secure-score improvement is not the same as proof that the organization’s most important business risks are controlled.
Security baseline decisions should be explicit
A baseline defines the minimum controls that workloads inherit or must implement. It can include identity and privileged access, approved regions, network exposure rules, logging, vulnerability management, encryption, secrets handling, backup, resource configuration, tagging/ownership, and incident response expectations.
The baseline should distinguish mandatory controls from workload-specific controls. A development sandbox and a regulated production workload may share a minimum foundation but require different depth. The exception process is part of the baseline: who can approve deviation, what compensating controls are required, and when the exception is reviewed.
Prioritize network exposure by attack path and business need
Public access is not automatically wrong; many applications must serve internet users. The security question is whether each exposed path is intentional, minimized, protected, and monitored. Review public IPs, load balancers, application gateways, firewalls, NSGs, API endpoints, management ports, private connectivity and DNS assumptions.
A common failure pattern is to create “temporary” broad access for troubleshooting or migration and never remove it. Security remediation should distinguish required ingress, controlled egress, administrative access, and accidental exposure. Network controls should also be operationally supportable so engineers do not bypass them during incidents.
Logging is a control only if someone uses it
Enabling diagnostic settings and sending data to a workspace is not enough. Teams need to know which events matter, how long evidence must be retained, which detections exist, who receives alerts, and how investigation works. Logging that has no consumer can become expensive data exhaust; logging that is too sparse creates blind spots.
The security roadmap should link telemetry sources to detection or investigation use cases. For higher-maturity environments, Microsoft Sentinel can centralize SIEM use cases across Microsoft and other data sources. For smaller estates, the design may start with Defender and Azure-native monitoring while defining an escalation path.
Vulnerability and configuration remediation need different owners
A vulnerability may require patching an operating system, updating a container image, changing application dependencies, upgrading a database, or rebuilding an immutable artifact. A configuration recommendation may require policy, network, identity, or service settings. Those actions rarely belong to one security team.
The assessment should therefore assign remediation ownership by control domain. Security can prioritize and validate risk; workload and platform teams often implement the change. This prevents a backlog where thousands of findings are “owned by security” even though security cannot fix them.
Backup and recovery are security controls when destructive events matter
Ransomware, compromised credentials, accidental deletion and malicious administrative actions make recoverability part of security. Review whether critical workloads are protected, whether recovery points are isolated appropriately for the threat model, whether restore procedures are tested, and who can alter or delete protection.
A successful backup job is not proof of recoverability. The security and continuity teams should understand what can be restored, in what sequence, within which business objective, and under what identity assumptions if normal administrative accounts are compromised.
Incident response should be designed before the alert
| Incident question | What should be defined |
|---|---|
| Who declares severity? | Business impact criteria and authority |
| Who can contain? | Preapproved actions for accounts, network paths and workloads |
| Who investigates? | Security operations and technical owners |
| Who communicates? | Executive/business/customer communication roles |
| Who engages Microsoft or vendors? | Support entitlement and escalation owner |
| How is evidence preserved? | Logs, snapshots, retention and chain-of-custody needs where applicable |
| How are lessons converted to work? | Post-incident actions, owners and due dates |
A tabletop exercise can validate the operating model without waiting for a real incident. The exercise should test identity compromise, public exposure, data access or ransomware-style scenarios that are relevant to the organization.
A practical remediation sequence
- Close urgent exposure. Address credible paths to critical assets, excessive privilege and missing essential controls.
- Stabilize the control plane. Strengthen identity, privileged access, policy and security ownership.
- Improve visibility. Fix logging, detection coverage and alert routing.
- Protect high-value workloads. Apply workload protection, vulnerability remediation and network controls based on risk.
- Validate resilience. Confirm backup, recovery and incident procedures.
- Automate repeatable controls. Use policy, infrastructure as code and governance after the standard is understood.
- Operate and measure. Track risk reduction, exceptions, aging findings and incident lessons.
A security service catalog should show boundaries
Buyers should be able to tell which security activities are assessment, which are implementation, and which are ongoing operations. For example, reviewing Defender for Cloud recommendations is different from enabling paid Defender plans; designing Sentinel detections is different from operating a SOC; reviewing Conditional Access is different from changing production access policy. Each activity has different prerequisites, change risk, and ownership.
| Workstream | Possible scope | Customer decision still required |
|---|---|---|
| Identity security | Privilege review, MFA/Conditional Access design, PIM recommendations | Risk tolerance, user impact and rollout authority |
| Posture management | Defender for Cloud coverage, recommendations, policy and priorities | Which plans/controls to fund and which risks to accept |
| Network security | Exposure review, segmentation and control recommendations | Application connectivity and business exceptions |
| Detection / SIEM | Log-source, use-case and alert-quality design | Data retention, SOC ownership and response model |
| Security deployment | Implement approved controls | Change windows, application validation and rollback |
| Security operations | Monitoring, triage and escalation within agreed scope | Business severity, containment authority and risk acceptance |
Do not use secure score as the only executive KPI
Microsoft Defender for Cloud now has a newer risk-based Cloud Secure Score experience in the Microsoft Defender portal while the classic secure score remains available in the Azure portal. Microsoft’s June 2026 guidance notes that the newer model incorporates asset risk factors and criticality. That is useful context for prioritization, but no single score should replace risk discussion.
A score can move because the assessed environment changes, new recommendations appear, or coverage expands. Executives should pair posture scores with high-risk exposure, aging critical recommendations, exception status, workload criticality and remediation ownership. The question is not “Did our score go up?” but “Which meaningful attack paths or business risks did we reduce?”
Common security-program failure patterns
- Tool-first delivery: products are enabled before the threat, data, ownership and operating model are defined.
- Score chasing: teams remediate easy recommendations to improve a metric while higher-risk exposures remain.
- Security owns every finding: platform and workload teams never receive accountable remediation ownership.
- Logging without detections: telemetry is collected but no one can explain which incidents it helps detect or investigate.
- Permanent exceptions: temporary migration or application constraints become long-lived security architecture.
- Remediation without validation: tickets close when configuration changes rather than when the control outcome is tested.
- Operations added last: new tools produce alerts with no triage, severity, escalation or runbook model.
A phased security roadmap can keep risk and change manageable
| Phase | Focus | Exit condition |
|---|---|---|
| 1. Establish control-plane safety | Privileged access, emergency access, ownership and critical exposure | High-risk administrative paths are understood and governed |
| 2. Establish posture visibility | Inventory, baseline, Defender recommendations, network exposure, logging gaps | Material findings can be prioritized by asset/business context |
| 3. Remediate high-value controls | Identity, network, workload protection, vulnerability, secrets and data controls | Priority changes are implemented and validated |
| 4. Improve detection and response | Use cases, SIEM/SOC workflow, incident and containment model | Important alerts have owners and tested escalation paths |
| 5. Institutionalize governance | Policy, exceptions, review cadence, metrics, automation | Controls remain effective as the environment changes |
Executive questions before funding the roadmap
- Which risks can lead to a material business event, and what evidence supports that view?
- Which recommendations require product licensing versus configuration or process change?
- Who owns remediation after security identifies the issue?
- Which controls could disrupt applications or users and therefore need staged rollout?
- What evidence will prove that a high-priority risk was reduced?
- Which ongoing operational responsibilities begin after implementation?
What BI Cloud Tech needs from the customer
Security work requires access to evidence and decision makers. Inputs can include Azure subscription scope, Microsoft Entra context, architecture diagrams, security policies, Defender for Cloud posture, Sentinel or logging configuration, incident history, regulatory requirements, data classifications, recovery expectations, and named workload owners.
Read-only review access is appropriate for assessment. Remediation access should be separately scoped, least-privileged, and aligned with the customer’s change process. The customer remains responsible for business risk acceptance, application priorities and policy decisions.
How to judge whether remediation is complete
A change should have an acceptance condition. MFA policy should be tested against intended users and emergency paths. A network restriction should be validated against application flows. A logging fix should demonstrate that expected events arrive. A backup recommendation should be closed with recovery evidence appropriate to the workload. A policy control should be tested with both compliant and noncompliant deployment cases.
This prevents the remediation register from becoming a list of tickets closed because configuration changed. The goal is to reduce the underlying risk without breaking the workload.
When an Azure security service is not the first step
If the organization does not know which Azure subscriptions exist, has no workload ownership, or is in the middle of a major tenant or platform redesign, the first engagement may need to establish inventory and architecture context before deep remediation. Likewise, if the primary concern is a live incident, incident response takes priority over a broad maturity assessment.
The service should fit the blocked decision. Security maturity improves faster when scope is tied to a clear business question rather than an open-ended promise to “secure Azure.”
Where BI Cloud Tech can help
BI Cloud Tech can support the lifecycle through Cloud Security Assessment, Security Deployments, and broader Security and Identity expertise. Scope can focus on posture, identity, Defender for Cloud, Sentinel, network controls, governance, remediation or operational readiness depending on need.
Assessment findings should remain distinct from implementation. BI Cloud Tech can identify and recommend changes during assessment, but controls are considered implemented only when separately approved, configured and validated.
A practical next step
List the ten Azure security decisions that would matter most during a serious incident: privileged access, public exposure, logging, data access, backup, containment authority, application owners, support escalation, risk acceptance and communications. If several have no owner or evidence, those are strong candidates for the first security workstream. Contact BI Cloud Tech to scope an Azure security review.