1.1 Describe security and compliance concepts

More work now happens outside the traditional office network, with data stored on premises, in cloud services, and in AI tools. Organizations must therefore protect information wherever it is accessed and show that they handle it according to growing legal and industry rules. This page introduces the ideas behind Microsoft security and compliance: who secures what, how layered controls and core security goals work, why perimeter trust is insufficient, how encryption and hashing protect data, and how governance structures risk and compliance.

Who secures what in cloud services

When systems run only on an organization's own hardware, that organization controls every layer from the building and servers through networking, operating systems, applications, identities, and data. Cloud computing moves part of that work to the provider, and the exact split depends on the service model. The shared responsibility model makes the division explicit so each side can plan its controls.

• On-premises: the organization secures the full stack, including building, hardware, network gear, operating systems, applications, identities, and data.

• Infrastructure as a Service (IaaS): the provider secures the physical datacenter, network hardware, and host machines, while the customer secures operating systems, applications, configured network controls, and data.

• Platform as a Service (PaaS): the provider additionally secures the operating system and runtime, while the customer remains responsible for application code, configuration, access controls, and data.

• Software as a Service (SaaS): the provider manages the application and its infrastructure, while the customer controls who may use the service, the data itself, and tenant-level settings.

Higher-level services delegate more underlying work, but four duties never transfer. Customers always own data decisions such as classification, protection, encryption, retention, and governance, identity work such as authentication and least-privilege permissions, endpoint protection for laptops, phones, and desktops, and the secure configuration of tenant settings and policies. A misconfigured storage account or overly broad permission can expose data even when the platform underneath is sound.

Cloud use also brings large-scale advantages. Providers invest continuously in physical protection, hardware reliability, certifications, threat intelligence, and monitoring, so customers inherit strength in the provider-owned portion. That shift lets smaller teams concentrate limited time on data, identities, and configuration rather than on patching hosts and guarding buildings, where delays and aging hardware often create gaps on premises.

Shared responsibility for AI workloads

AI systems add oversight duties because user prompts and connected data shape behavior and because outputs can drive consequential choices. An AI solution can be viewed in three layers that clarify where those duties sit.

• AI platform: base infrastructure, hosted model, and built-in safety systems such as content filtering and access controls.

• AI application: the deployed assistant or app, including its configuration, data connectors, plug-ins, and logging.

• AI usage: how people employ the system, including inputs provided, acceptable-use rules, training, and oversight.

The provider generally secures physical infrastructure and model hosting, operates compute and service security, and supplies platform safety controls according to tier. Examples include a SaaS assistant such as Microsoft 365 Copilot and a PaaS environment such as Azure AI Foundry, where the platform contribution differs.

• Protect connected data by limiting which sensitive sources the assistant may reach and applying governance and access controls.

• Manage identity and access so only approved users and roles can use AI apps and features.

• Configure safely by restricting connectors, logging outputs, and setting retention.

• Address AI-specific abuse such as prompt injection, where hidden instructions in input or retrieved content steer outputs, through validation, least privilege, and monitoring.

• Train users and enforce acceptable-use policies because prompts directly influence behavior.

Layered protection with defense in depth

Defense in depth avoids depending on one perimeter. It overlaps several controls so a failure at one control does not immediately expose information. A campus archive illustrates the idea: a fenced building and badge reader, camera monitoring, login with multifactor checks, a firewall at the network edge, isolated subnets for reading rooms, hardened and patched workstations, vetted catalog software, and finally locked, encrypted files for the rarest manuscripts.

• Physical security: locked facilities, guards, badge readers, and cameras that block direct access to servers and storage.

• Identity and access: multifactor authentication, role-based access control, and conditional access that weighs location, device health, and risk before granting entry.

• Perimeter: distributed denial-of-service filtering and edge firewalls that inspect traffic entering and leaving.

• Network: segmentation into isolated zones and network security groups that limit which systems may communicate, containing lateral movement.

• Compute: patched virtual machines and containers, closed ports, limited administrator rights, and behavior monitoring.

• Application: secure coding, input validation against SQL injection and cross-site scripting, and testing before release.

• Data: classification, access limits, and encryption so the most valuable asset carries its own protection.

Layering buys time and visibility. Each barrier forces extra attacker effort and creates new chances to detect and respond, which matters because any single control can fail through bugs, mistakes, or necessary exceptions. Modern design therefore assumes outer defenses will eventually be tested and concentrates on limiting what an intruder can reach afterward.

Goals of protection: confidentiality, integrity, availability

Layered controls serve three enduring aims known as the CIA triad. Confidentiality, integrity, and availability together describe what security ultimately preserves.

The three aims can compete. Strong encryption aids confidentiality, yet lost keys can make data permanently unreadable and harm availability. Strict authentication aids confidentiality and integrity but can add friction for legitimate work. Teams therefore balance controls by data sensitivity, breach impact, and operational need, and they use the triad to diagnose attacks: theft targets confidentiality, alteration targets integrity, and outages target availability.

Zero Trust: verify everything

Zero Trust is a strategy, not a single product, summarized as trust no one, verify everything. Older perimeter thinking treated the internal network as implicitly safe once the edge was crossed. That assumption fit fixed offices and on-premises data, but it breaks when users work from homes and public places, use mixed devices, and move data across datacenters, clouds, and third-party apps. Attackers who phish credentials or exploit an application can then move freely if interior traffic is trusted by default.

• Verify explicitly: authenticate and authorize each request using all signals such as identity, location, device compliance, app, data sensitivity, and anomalies, not network position alone.

• Use least privileged access: grant only the minimum permissions needed for the shortest time, using just-in-time access that expires and just-enough-access that avoids broad standing rights, plus risk-based policies that tighten access on suspicious behavior.

• Assume breach: segment access, encrypt end to end, and monitor continuously so a compromised account or device cannot reach everything and intrusions are detected and contained quickly.

Implementation spans seven linked pillars. Six produce signals and enforce controls on resources, while the seventh integrates them.

• Identities for users, services, and devices, verified with strong authentication and limited by least privilege, forming the primary control plane.

• Devices, whose health and compliance determine whether access is allowed, limited, or blocked.

• Applications, including unsanctioned shadow IT, with visibility into requested permissions and user-granted data access.

• Data, classified, labeled, and encrypted so protection travels with the information itself.

• Infrastructure on premises and in cloud, checked for version currency, configuration compliance, and anomalous behavior, with just-in-time administrative access.

• Networks, segmented including micro-segmentation within zones, with encrypted traffic, real-time protection, and analytics.

• Visibility, automation, and orchestration, which correlates signals through security information and event management and triggers automated playbooks through security orchestration and automated response.

In practice the pillars are evaluated together. For example, a vendor engineer attempts to open a production control dashboard late at night from a borrowed tablet that missed security updates. Identity checks flag an unusual time, device checks find noncompliance, application policy requires a compliant device for that dashboard, network logging captures the attempt, data controls keep the underlying records encrypted, and infrastructure telemetry records the event. Correlation turns several low-severity hints into a high-confidence risk, prompting stepped-up authentication or a block and an alert without waiting for manual review.

Watch the video

Encryption, keys, and hashing

Encryption makes data unreadable without a secret key, so interception or theft yields unusable ciphertext. Decryption with the correct key restores readability.

Asymmetric keys also create digital signatures. Content signed with a private key can be checked with the matching public key to confirm the expected sender and to detect later modification. Signatures therefore support both authenticity and integrity for software, messages, and documents.

• Data at rest on disks, databases, or storage accounts: encryption keeps stolen drives or unauthorized account access from yielding readable data without keys.

• Data in transit across the internet or between services: Transport Layer Security for HTTPS and virtual private networks prevent eavesdropping on moving traffic.

• Data in use in memory or during processing: confidential computing uses protected enclaves so code can run without exposing data even to the operating system or hypervisor, important on shared hardware.

Protection depends on key management: how keys are created, stored, guarded, rotated, and retired. Leading practices keep keys separate from the data they protect, store them in tamper-resistant hardware security modules, rotate them regularly to bound exposure, and restrict access through strong authentication and least privilege. Managed vaults such as Azure Key Vault centralize keys, certificates, and secrets, support rotation, and integrate with services without exposing key material to code or administrators.

Hashing differs fundamentally. A hash algorithm maps any input to a fixed-length fingerprint called a hash or digest. The process is one way and uses no key: the same input always yields the same fingerprint, but the fingerprint cannot be reversed to recover the input.

Password systems exploit that property by storing only hashes. At sign-in the system hashes the entered password and compares fingerprints, never keeping plaintext. Because hashing is deterministic, attackers precompute hashes of common passwords for dictionary or rainbow-table lookups. Adding a unique random salt to each password before hashing ensures identical passwords produce different stored values, defeating shared precomputed tables.

Governing risk and meeting obligations

Privacy statutes, sector rules, and customer expectations now dictate how data must be protected, located, and accounted for, while cyberattacks, disasters, supplier issues, and insider mistakes threaten operations and trust. Governance, risk, and compliance (GRC) provides an integrated discipline for directing activity, understanding threats, and demonstrating adherence.

• Assign clear accountability for decisions and asset protection.

• Identify potential threats before they become incidents.

• Demonstrate alignment with laws, regulations, and standards.

• Build confidence with customers, partners, and regulators.

Governance is the system of rules and processes that directs and controls activity, often driven by external obligations. In security it covers data classification, handling, and retention policies, identity and access standards, approval for privileged access and its duration, ownership of controls, violation response, and overall security direction.

Risk management identifies, assesses, and responds to events that could harm objectives or trust. It addresses external sources such as attacks, natural disasters, economic shifts, regulatory change, and suppliers, and internal sources such as accidental exposure, insider misuse, fraud, and process gaps. The aim is informed choice, not elimination of all risk.

1. Identify: discover risks through interviews, vulnerability assessments, audit findings, and monitoring.

2. Assess: estimate impact and likelihood to score and prioritize risks.

3. Respond: accept low risks, mitigate with controls, transfer through insurance, or avoid by changing the process.

4. Monitor: track risks and control effectiveness and update assessments as conditions change.

Compliance means following the laws, regulations, standards, and policies that apply by industry, geography, and data type. Familiar examples include HIPAA for health information in the United States, ISO 27001 for information security management, and SOC 2 for service providers handling customer data. Compliance states minimum mandated requirements, while security is broader protection against threats, so a minimally compliant organization can still remain vulnerable.