Cloud Security, Identity and Compliance

Cloud security divides work between the provider and customer. Assign tasks by the layer each party operates, including the settings the customer chooses.

Separate infrastructure from customer choices

AWS calls infrastructure protection security of the cloud. It covers facilities, physical servers, storage, network equipment and the hypervisor that separates virtual machines on a host. Customers handle security in the cloud: their data, identities and configuration. Azure and Google Cloud use the same basic division. Google’s shared fate approach adds secure defaults, guidance and tools to help customers secure their part.

Providers control physical entry, power, cooling, hardware maintenance and secure retirement of drives. Independent auditors examine these layers; customers use their reports to assess controls they do not operate themselves.

Keep customer duties assigned

Across service models, the customer retains responsibility for:

• Data: classification, access, protection decisions and retention.
• Accounts: creating, maintaining and removing identities.
• Access management: roles, MFA and sign-in policies.
• Client devices: protecting the laptops and phones used to connect.

Customer-chosen settings remain customer work. A public bucket, an internet-exposed database rule or an abandoned administrator account can expose a workload even while the provider’s infrastructure controls work correctly.

Some controls are shared because each party performs them on its own layers. The provider patches infrastructure; customers patch the operating systems and applications they manage. Each side configures its own systems and trains its own staff. Assign both sides of a shared control so neither is overlooked.

Apply the split to invoice storage

A company stores invoices in a cloud bucket. The provider patches the storage service, replaces failed drives and securely retires disks. The company makes the bucket private, gives its billing role the needed read access and requires MFA for those users. It also selects encryption settings, enables the needed access logs and chooses how long invoices remain.

If an employee makes the bucket public, the customer must correct the permission and investigate the exposure. The storage service can return readable content to a request the customer has permitted; physical protection cannot undo that access grant.

Cloud infrastructure and specialist security tools can give a small team protections it could not build alone. Optional features still need an owner to configure them and review findings. Check each service’s responsibility guidance when assigning those tasks.

More managed services transfer more operating work to the provider. Customer choices about identities, data and settings remain active across those changes.

Compare the layers

Application and network duties can be shared in PaaS. SaaS customers configure application features even though the provider operates the service; device management may also be shared. Check the individual service and feature for the precise boundary.

Work through the services

For a web server on Amazon EC2, Azure Virtual Machines or Google Compute Engine, the customer installs guest-OS security updates and maintains the web server. It restricts remote administration with AWS security groups, Azure network security groups or Google Cloud firewall rules, and chooses disk protection and backups.

With Amazon RDS, Azure SQL Database or Google Cloud SQL, the provider maintains the underlying OS and managed engine. The customer still selects permitted network paths, users, permissions, encryption settings, backup retention and available maintenance windows. Automated backup capability does not decide how long the business needs its records.

For AWS Lambda, Azure Functions or Google Cloud Run functions, provider-managed runtimes remove server and runtime patching from the customer’s list. Customers still update bundled dependencies, validate inputs, protect secrets and restrict execution and invocation permissions. Custom runtimes or containers bring additional maintenance duties.

In Microsoft 365 or Google Workspace, the provider patches the office application. Customers remove departed employees, control external sharing and set retention. Some organizations also maintain their own SaaS backups.

Assign an unfamiliar task

Name the layer, identify the service model, then consult its documented split. A failed physical disk is provider work in every model. A VM’s guest-OS update is customer work; an OS update beneath a managed database is provider work. A database user’s permission is still a customer choice. Keep a task list per service when an organization uses several models together.

Cloud access starts by identifying a person or application. It then checks that identity’s permissions. Keeping those decisions separate helps explain why a successful sign-in can still end in an access-denied message.

Prove identity, then check permission

Authentication establishes who or what is making a request. Authorization decides whether that identity may perform the requested action. Auditing records what happened. A password plus MFA can authenticate a user; a role can still refuse that user permission to delete a database.

In Azure and Google Cloud, role assignments connect people, groups or workloads to permissions. In AWS, assuming an IAM role produces temporary session credentials. A workload should use that supported identity mechanism instead of a person’s password copied into a configuration file.

Recognize the provider names

AWS IAM supplies users, groups and roles. IAM Identity Center supports workforce access across AWS accounts. Microsoft Entra ID, formerly Azure Active Directory, is Azure’s cloud directory, with users, groups, service principals and managed identities. Google Cloud uses accounts and groups in Cloud Identity or Google Workspace, plus service accounts for workloads.

An EC2 instance can receive an IAM role, an Azure resource a managed identity, and a Google Cloud VM an attached service account. The platform supplies short-lived credentials for supported access, avoiding a stored long-term password.

The AWS root user has account-wide power. Azure and Google Cloud distribute powerful access through roles such as Entra Global Administrator, subscription Owner and project Owner. These roles have different scopes: a directory administrator’s role is not interchangeable with a resource administrator’s role.

Sign in centrally

Single sign-on (SSO) lets a person use one sign-in across several applications. Federation is the trust that allows a cloud or application to accept identity information from another identity provider, commonly through SAML 2.0 or OpenID Connect.

A company uses Entra ID for 200 employees and federates access to AWS and Google Cloud. When an engineer leaves, disabling the central account stops new sign-ins. The company must also revoke active sessions and remove independent local accounts and access keys. Those paths may continue to work without a fresh central sign-in.

Partners can use external identities: Entra B2B guest access, an AWS cross-account role or Google Cloud roles granted to outside principals. Their employer manages their home identity; your organization controls their access to your resources.

Older applications may need domain join, Kerberos, NTLM or LDAP. Managed directory offerings include Entra Domain Services, AWS Directory Service and Google Cloud Managed Service for Microsoft Active Directory. These meet different application needs from a modern cloud sign-in alone.

A permission connects an action to a resource. “Read objects in this bucket” is more precise than “use storage.” Providers group permissions into roles or policy statements, then attach them to identities or resources.

Match who, what and where

Role-based access control (RBAC) assigns permissions through job roles. An Azure role assignment has three parts: the security principal, the role definition and the scope. Scopes run from management group to subscription, resource group and individual resource. Assignments flow down to resources inside their scope.

Priya has Reader on the Prod subscription and Contributor on its web-rg resource group. She can view resources throughout Prod and change resources in web-rg. She cannot change db-rg or grant another person access through Contributor. Azure permissions add across assignments; supported Azure features can create deny assignments that block otherwise permitted actions.

Google Cloud allow policies bind principals to roles on resources. Access is inherited through organization, folders, projects and resources. Broad basic Owner, Editor and Viewer roles should give way to suitable service-specific predefined or custom roles. Editing a child’s allow policy does not remove access granted at its parent. Change the parent grant, or apply a supported deny policy where appropriate.

Evaluate an AWS request

An AWS IAM policy is JSON containing statements with an Effect, an Action, a Resource ARN and optional conditions. Policies can attach to identities; a resource policy, such as a bucket policy, attaches to the resource. AWS managed policies are provider-maintained, customer managed policies are reusable customer documents, and inline policies belong to one identity.

For a basic request decision:

1. Start with implicit deny: there is no permission yet.
2. Find an applicable explicit allow and check every applicable permission limit.
3. Apply any explicit deny: it overrides allows.

An AWS Organizations service control policy (SCP) limits the maximum available permissions. It grants no permissions itself. A request outside the SCP’s permitted boundary fails even when an identity policy allows it.

Lena’s group may read sales-reports/*, and no guardrail restricts that read. A download is allowed. An upload fails because there is no s3:PutObject allow. A separate policy explicitly denies deletion; adding s3:* later still cannot authorize deletion. Reading an unrelated bucket also lacks an allow.

Separate resource management from data access

An administrator can manage a storage account through the control plane without receiving an Entra data role to read its blobs through the data plane. For that read, a role such as Storage Blob Data Reader is needed. Check the action and scope instead of assuming that a powerful resource-management title answers every data-access question.

Least privilege gives an identity the actions, resources and time its task needs. It reduces the blast radius: the amount of damage a mistake or stolen credential can cause.

Build a focused grant

List the work first, choose a narrow role or policy, set the smallest useful scope and manage people through groups or roles. Limit privileged access in time and review it regularly. A contractor uploading logs to one bucket for 30 days needs upload access there, not read access across storage or a permanent administrator identity.

Just-in-time access limits when someone can obtain elevated permissions. Entra Privileged Identity Management can require approval and MFA for timed activation. Google Privileged Access Manager provides requested temporary role grants. AWS roles issue time-limited credentials through Security Token Service, but a permanent right to assume an administrator role allows repeated new sessions. Short credentials alone do not remove standing privilege.

Separation of duties gives different people control over sensitive parts of a process. A change requester and approver should be distinct; key administration and data reading should also be separated.

Protect powerful identities

Enable MFA on the AWS root user, give it a strong unique password and create no root access keys. Use it only for root-required tasks. Examples include changing its own email or password, closing a standalone account, recovering from an IAM administrator lockout, activating IAM billing access, registering as an EC2 Reserved Instance Marketplace seller and enabling S3 MFA delete. Organizations can centrally remove member-account root credentials.

Keep high-privilege Entra and Google Cloud roles tightly limited. Microsoft recommends fewer than five Global Administrators. Administrators need separate daily and privileged identities and phishing-resistant MFA. Entra emergency access planning uses two securely held, monitored break-glass accounts so normal sign-in failure does not lock everyone out; emergency account design follows the provider’s own guidance.

Prefer short-lived access and managed secrets

Long-term access keys remain usable until disabled or deleted. Prefer workload identities, roles and SSO. Rotate unavoidable keys and keep them out of source code. If a key leaks, remove its usable access; deleting a visible code fragment does not revoke the credential.

Store database passwords, API keys and certificates in AWS Secrets Manager or Systems Manager Parameter Store, Azure Key Vault, or Google Cloud Secret Manager. Applications fetch needed secrets at run time through workload identities. Configure audit collection where required, such as Azure Key Vault diagnostic settings.

For remaining passwords, NIST’s 2025 guidance requires at least 15 characters for single-factor use, or at least 8 as part of MFA, and support for at least 64 characters. It calls for checks against common and breached passwords, rejects forced character mixes and routine scheduled changes, and requires change after suspected compromise.

Use evidence to prune access: AWS IAM Access Analyzer, credential reports and last-accessed data; Entra access reviews; and Google IAM role recommendations. If a role allows 40 services but used only 3 in 90 days, review the other 37 services’ permissions. Check upcoming legitimate tasks before removing them; inactivity identifies candidates, not a complete account of business need.

Multifactor authentication (MFA) requires at least two different factor categories: something known, held or inherent to a person. A password and security answer are both knowledge factors and remain single-factor authentication.

Compare authentication methods

NIST restricts phone-network delivery. A common TOTP setup uses six digits changing every 30 seconds: one million possible values give a blind single guess a one-in-one-million chance. Implementations can use other lengths or intervals.

A phishing page can forward a password and fresh code to the real site before expiry. A passkey’s domain-bound proof cannot be reused by the fake domain for the real service. Windows Hello for Business and supported certificate-based methods also offer phishing-resistant options.

MFA fatigue repeatedly sends push requests hoping someone accepts. Number matching links the approval to a sign-in screen, reducing accidental acceptance; it does not provide the same domain binding as a phishing-resistant method.

Check factors in passwordless sign-in

Passwordless removes the password. A device-held credential unlocked through a verified PIN or biometric combines possession with a second factor. The PIN is checked locally, not sent to the service. Check which factors the actual method verifies before classifying it as MFA. Google calls its MFA service 2-Step Verification.

Providers enforce MFA for some administrative access, including AWS root and Azure portal sign-in. Customers still set requirements for their own users and applications, with the strongest methods for privileged access.

Apply context and protect recovery

Entra Conditional Access evaluates the user, application, device health, location and sign-in risk. It can allow, require stronger authentication or a compliant device, or block. For payroll, require a managed device and phishing-resistant authentication; block high-risk sign-ins. AWS IAM conditions and Google context-aware access provide related controls with different service behavior.

Protect account recovery with similar care: a weak recovery route can replace a strong authenticator. Refuse unexpected approval prompts and report them through the organization’s process. Least privilege and monitoring still limit risk if an authenticated session is stolen.

Encryption changes readable plaintext into ciphertext using a key. The right key permits decryption. It protects confidentiality; authenticated encryption also detects tampering. It does not stop an authorized deletion or keep a failed application running.

Distinguish three transformations

Base64 text such as "aGVsbG8=" can be decoded to "hello" by anyone. It offers no confidentiality. Password storage needs a salted, deliberately slow password-hashing function such as Argon2, bcrypt, scrypt or PBKDF2. A single fast SHA-256 hash is unsuitable for that job.

Symmetric encryption uses the same key for encryption and decryption. AES-256 is common for bulk cloud data. Asymmetric cryptography uses a public and private key pair for operations such as key exchange and digital signatures; the supported operations depend on the algorithm. Public-key encryption lets a sender protect data for a recipient whose private key decrypts it. A digital signature lets others check a signature made with the private key.

A 256-bit symmetric key has $2^{256}\approx 1.16\times {10}^{77}$ possible values. Even at ${10}^{18}$ guesses per second, checking them all takes about $3.7\times {10}^{51}$ years. Protecting access to keys matters much more in practice than planning to defeat that search space.

Apply encryption to stored data

Data at rest includes objects, disks, databases, backups and snapshots. Encryption protects raw stored content if someone obtains a drive or copies storage without the required key. Server-side encryption occurs inside the service before writing data. Client-side encryption happens before upload, leaving the provider with ciphertext. Losing an irreplaceable client key makes the content unreadable.

Default settings vary by service. Amazon S3 has encrypted all new object uploads by default since January 5, 2023. Azure Storage encrypts stored data and this cannot be disabled. Google Cloud encrypts customer data at rest by default. Amazon EBS encryption by default is a customer-enabled account setting in each Region.

Follow a permitted read

An invoice object is encrypted on disk. A user requests it through the storage service. The service checks permissions, decrypts the object through its configured key mechanism and returns readable content to the permitted user. If the customer grants public reads, that process can also serve outsiders.

Encryption at rest therefore works with private access settings and activity logging. Start with data classification: public, internal, confidential or restricted. Classification guides who may read the content, the key-control requirements and retention. Backups need the same attention because a protected database can still have an exposed copy.

A record can be encrypted in storage and still be exposed while crossing a network or being processed. Follow its path to identify where each protection is needed.

Encrypt moving data with TLS

Data in transit moves between browsers, applications, databases, offices or regions. Transport Layer Security (TLS) protects a connection against reading and alteration and authenticates the server through a certificate. HTTPS is HTTP carried over TLS, usually on port 443. Use supported TLS 1.2 or 1.3 configurations; SSL and TLS 1.0 and 1.1 are obsolete.

A digital certificate associates a domain with a public key. A trusted certificate authority signs it so the browser can check the association. Certificate services include AWS Certificate Manager, Azure Key Vault or App Service certificate features, and Google Cloud Certificate Manager. Managed renewal reduces expiry risk when supported and configured. An expired certificate can break connections and interrupt a service.

A valid HTTPS connection confirms protection to that domain. A phishing site can also hold a valid certificate for its own domain, so the padlock alone says nothing about whether that business or page deserves trust.

Trace a browser request

1. The browser establishes HTTPS to a load balancer and checks its certificate.
2. The load balancer terminates that TLS connection and sees the request in plaintext.
3. A separate TLS connection protects the next hop to an application server.
4. The application uses an encrypted database connection, with the database configured to require it.

Front-end HTTPS protects only its own connection. Check every later hop. An S3 policy can deny requests when aws:SecureTransport is false; Azure Storage offers secure transfer required; Cloud SQL can require TLS. Internal networks also need traffic protection because an attacker may already have reached them.

Separate a private path from encryption

A site-to-site IPsec VPN encrypts traffic between an office network and a cloud network over the internet. Services include AWS Site-to-Site VPN, Azure VPN Gateway and Google Cloud VPN.

Dedicated links—AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect—avoid the public internet, but their private path alone supplies no default end-to-end encryption. Use appropriate TLS, IPsec or supported MACsec protection where needed. MACsec protects its supported link segment; check protection for the application’s full path as well.

Protect data during processing

Data in use is being processed, often in decrypted memory. Confidential computing adds hardware-backed isolation, with memory encryption in supported technologies. Azure confidential VMs and Google Confidential VMs encrypt memory using processor-held keys. AWS Nitro Enclaves isolates memory and CPUs from the parent instance and its administrators.

For a patient record, database encryption protects storage, TLS protects its delivery to a doctor, and a confidential VM can protect a sensitive analysis job while it runs. These controls cover different exposures. The application still needs permission to process the record and remains responsible for what it outputs.

Key ownership affects both security control and operational risk. A customer who gains the power to disable a key also gains a way to interrupt every service depending on it.

Compare control choices

Cloud key services include AWS KMS, Azure Key Vault and Google Cloud KMS. They control cryptographic operations and can log key use. Enable the required logs, including Azure diagnostic settings and Google Cloud KMS Data Access audit logging.

Customer-supplied examples include supported Amazon S3 SSE-C and Google CSEK workflows. External options include AWS KMS external key stores and Google Cloud External Key Manager. These features are service-specific; the chosen data service must support the option.

A hardware security module (HSM) protects keys in specialized hardware. AWS CloudHSM, Azure Managed HSM and Google Cloud HSM provide hardware protection. HSM describes how keys are protected; provider, customer or external control describes who governs their use. These are different choices.

Understand envelope encryption

Cloud storage often encrypts large content with a data key. It then encrypts that smaller key with a key encryption key held in a key service. The wrapped data key can be stored beside the ciphertext. This is envelope encryption: bulk data need not be sent to KMS for each cryptographic operation.

To read the content, the service needs permission to unwrap the data key. Disabling its protecting key blocks that path. Permanent key destruction can make all data that depends on it unreadable, including older backups.

Work through a hospital’s choice

A hospital chooses an AWS customer-managed KMS key for scans. Its application role can decrypt; the security team administers the key without routine permission to read scans. This separates data use from key administration. Audit evidence must show the intended permissions and key use.

The key rotates yearly. Rotation supplies new material for future encryption while retaining older versions needed to read existing content. It does not mean every old scan is immediately re-encrypted.

At the end of service, the hospital checks all remaining data and backup dependencies before scheduling key deletion. AWS KMS uses a waiting period of 7 to 30 days. After deletion, dependent ciphertext cannot be recovered through that key. Destroying access through key destruction is crypto-shredding.

Match control to a requirement

Choose customer-managed or external keys when a contract, regulation, revocation requirement, audit requirement or separation of duties calls for that control. The same encryption algorithm can protect data under any of these management models. Additional key control changes responsibility, availability planning and evidence; it does not make AES mathematically stronger.

Defense in depth combines independent controls. If one fails, another can block the next action, limit its damage or reveal the attack.

Put controls in layers

Microsoft’s seven-layer view runs from physical security through identity and access, perimeter, network, compute and application to data at the center.

Ownership follows shared responsibility. Providers run physical controls; customers control identities and data. Who maintains compute depends on whether it is a customer VM or a managed platform.

Follow an account takeover

An attacker obtains a shop developer’s password. MFA can block a new sign-in. Suppose the attacker instead steals an already authenticated session. The next controls must address what that session can do.

The developer’s role permits log reading but no database queries, so authorization refuses a direct customer-data request. Network rules separately restrict database connections to the application’s permitted path. Monitoring can flag unusual activity. Protected backups preserve recovery if an attacker later obtains destructive access.

Disk encryption protects raw storage without the key. It would not block readable content returned to a compromised identity with legitimate read and decryption permission. Evaluate the actual path before crediting a control with stopping it.

Combine blocking with detection

A preventive control stops a request, such as creation of public storage. A detective control reports an event or condition, such as unusual activity or excessive access. Assign a response that investigates, contains and corrects what it finds.

Two firewalls with the same mistaken rule can fail together. A separate identity check, application validation and narrow data role address different steps in the attack. Trace a request from user to data, identify controls along that route and assign owners for their settings and alerts.

Zero trust gives no automatic approval based on network location. An internal address does not establish permission to use an application or read its data.

Apply three principles

Verify explicitly: evaluate identity and context, including device health, location, the requested service, data sensitivity and unusual behavior.

Use least privilege: grant just enough access for the task, with time-limited elevation where needed. An authenticated user still needs permission for the action.

Assume breach: restrict movement, encrypt traffic and monitor activity so a compromised identity or device cannot freely reach everything.

NIST SP 800-207 describes the architecture approach. Microsoft expresses it through these three principles. Organizations implement the strategy through coordinated controls and can adopt it step by step.

Change the access boundary

A traditional perimeter model tends to trust devices after they enter the network. A broad VPN connection can then let an infected laptop reach many systems. Remote work, SaaS and multicloud make location alone a poor access boundary.

An identity-aware proxy evaluates access to a particular application. Google Identity-Aware Proxy, AWS Verified Access and Microsoft Entra Private Access provide related capabilities. Google’s BeyondCorp approach is an example of replacing automatic internal-network trust with evaluated access.

Segmentation and firewalls still limit reach after another control fails. Encrypt internal connections as well: an attacker may already be inside the environment.

Evaluate a nurse’s request

A nurse requests the staff scheduling app from home. An access service verifies identity with phishing-resistant authentication, checks that the laptop is managed and current, and confirms the scheduling role. It grants a session to that application.

A request to payroll requires its own permission decision. The scheduling session grants no payroll access. If monitoring later flags the laptop as infected, policy can block or revoke the affected access. Morning authentication does not settle the afternoon device-health question.

Identity services establish who is asking; device checks and conditional access evaluate context. Roles restrict actions, proxies and segments restrict reach, and TLS protects connections. Monitoring supplies new evidence for later decisions. Buying one product leaves these access rules and response decisions for the organization to establish.

Start with the job the control must do. The major providers offer overlapping security categories, and a single product can provide several kinds of finding. A detected software weakness calls for a different response from a traffic flood.

Block floods and web attacks

DDoS protection addresses traffic intended to overwhelm a service. AWS Shield Standard supplies automatic baseline protection; Shield Advanced adds paid capabilities and response support. Azure provides default infrastructure protection with paid Azure DDoS Protection tiers. Google Cloud Armor protects supported load-balanced applications.

A web application firewall (WAF) inspects web requests for attacks such as SQL injection, cross-site scripting and abusive bots. AWS WAF, Azure Web Application Firewall and Cloud Armor security policies provide this category. They can filter application requests or limit request rates. A network firewall controls network traffic at a different level: AWS Network Firewall, Azure Firewall and Google Cloud Next Generation Firewall are examples. AWS Firewall Manager helps apply supported protections across accounts.

Detect threats and known weaknesses

Threat detection examines activity for signs of compromise. A VM contacting a known mining service is a behavioral warning. GuardDuty analyzes sources including API, network-flow and DNS information. A SIEM, such as Microsoft Sentinel or Google Security Operations, brings security events from many sources together for analysis and investigation.

Vulnerability management identifies known weaknesses in installed software or images. Inspector assesses supported EC2, container and Lambda workloads. A vulnerable package can exist before any observed attacker activity; finding it should lead to an update or another appropriate mitigation.

Cloud security posture management (CSPM) checks configuration against practices and standards. A publicly reachable storage resource is a posture issue even if no malicious access has been detected. AWS Security Hub brings findings together; Security Hub CSPM supplies configuration controls. Defender for Cloud and Security Command Center also provide posture assessment.

Find sensitive data and act on findings

Macie can locate sensitive content in S3. Purview discovers, classifies and labels organizational data. Google Sensitive Data Protection can discover, classify and de-identify sensitive content. Finding passport numbers in a forgotten export tells the team where stronger access or retention controls are needed; discovery alone does not change every permission.

For an online service, map the symptom to the category. Use DDoS protection for a flood, a WAF for malicious web inputs, vulnerability assessment for an outdated library, threat detection for suspicious runtime activity and CSPM for risky resource settings. Several may be needed at once.

AWS Trusted Advisor, Azure Advisor and Google Recommender provide additional recommendations; available checks and paid plans differ. Provider marketplaces offer third-party products. Official security documentation, response centers, blogs and bulletins help teams keep up with changes. Assign owners to findings and enable the relevant service plans: a dashboard full of unreviewed alerts leaves the underlying exposure in place.

Logs answer questions about events; monitoring turns observations into action. Good evidence depends on collecting the right events early, retaining them long enough and protecting them from alteration.

Choose the evidence for the question

Audit or activity logs show who performed console or API actions. Configuration history shows how a resource’s settings changed. Metrics measure health and performance. Data access logs record relevant content access, and network flow logs describe traffic flows.

CloudTrail event history retains the latest 90 days of management events per Region. Create a trail to deliver records to S3 for longer retention, optionally also to CloudWatch Logs. CloudWatch performance metrics are different evidence from CloudTrail’s record of who changed a policy.

Azure’s activity log also keeps 90 days by default. Diagnostic settings can send records to storage, Log Analytics or Event Hubs. Google Admin Activity logs are always enabled and cannot be disabled. Data Access logs must be enabled for most services; BigQuery has important defaults that differ. Key Vault access logs and Google KMS data activity also need the relevant collection settings.

Preserve evidence before an investigation needs it

A bucket becomes public on March 2, 2026. Investigation begins July 1, 121 days later. The event is beyond a 90-day default window. A previously configured export may preserve who changed the setting, when and from which IP address; turning on an export now cannot recreate an expired record.

Configuration history can show the setting before and after the event. Use both records to understand the change, reverse the exposure and investigate data access through the appropriate enabled logs. A management event alone is not a complete list of files read.

Prevent changes and detect exceptions

Preventive guardrails block a disallowed action: Azure Policy Deny, supported SCP restrictions and Google organization constraints are examples. Detective guardrails identify a condition after it occurs: AWS Config rules, Azure Policy Audit and posture findings.

A location policy can block new resources in disallowed regions. A configuration check can report resources that violate a rule. The latter needs a response and does not undo a change merely by issuing a finding.

Restrict log access, collect evidence in a separate account or project, and use integrity or immutability controls where needed. CloudTrail log-file validation can reveal altered delivered files. Set retention to the applicable requirement; PCI DSS requires at least 12 months of audit history, with the latest 3 months readily available. Alert on events such as root sign-ins or powerful role changes, and assign someone to respond.

Compliance means meeting applicable requirements and showing evidence. A cloud provider’s audited controls can support your obligations, but your organization must also run and document the controls it owns.

Identify the kind of requirement

ISO/IEC 27001 addresses an information security management system, or ISMS. Accredited certification bodies issue certificates, normally on a three-year cycle with surveillance audits. ISO/IEC 27017 adds cloud security controls. ISO/IEC 27018 addresses personal-data protection for public-cloud processors; its current edition is 2025.

Choose the SOC report for the question

SOC 1 concerns controls relevant to customer financial reporting. SOC 2 addresses applicable Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. It is a detailed report usually shared under confidentiality terms. SOC 3 is a general-use report suitable for public distribution.

A Type 1 report assesses control design at a point in time. A Type 2 report also tests operating effectiveness over a stated period. For evidence that a supplier’s relevant controls operated over months, ask for a current SOC 2 Type 2 report and inspect its actual scope. SOC 2 is an attestation, not a certification.

Recognize industry and government needs

PCI DSS applies to organizations storing, processing or transmitting cardholder data. Cloud service scope matters alongside the customer’s payment design and controls.

HIPAA protects PHI in its scope: covered health organizations and their business associates. A provider maintaining electronic PHI on a covered entity’s behalf is a business associate, including when it stores encrypted data without the key. A Business Associate Agreement (BAA) must be in place. There is no official HIPAA certification that replaces these duties.

FedRAMP addresses assessment and ongoing oversight of cloud services for in-scope US federal agency use. Agency use cases and exclusions matter; selling installable software to an agency alone does not trigger it. Other assurance schemes include Germany’s C5, Spain’s ENS, Australia’s IRAP and Japan’s ISMAP. CSA STAR publishes cloud self-assessments and independent assurance information.

Check service scope before relying on evidence

A clinic checks both its BAA and the provider’s eligible-services list before putting electronic PHI into a service. A retailer processing cardholder data checks PCI DSS requirements and may also have GDPR duties for personal data. One obligation does not replace another.

A certificate or report names a boundary: services, locations and assessment dates. Record which provider controls your workload inherits, then implement your own permissions, configurations, procedures and evidence. A provider’s broad corporate badge cannot answer whether a particular new service or region is included.

Compliance evidence is useful when it matches the service, location and period you depend on. Downloading a document begins the review; its contents determine what assurance you can rely on.

Find the provider’s documents

Detailed SOC reports often require acceptance of confidentiality terms or a nondisclosure agreement. General-use SOC 3 reports and many certificates are public. Public compliance pages help identify the available programs and in-scope services.

Read a SOC 2 Type 2 report in order

1. Read the auditor’s opinion. An unqualified opinion gives clean assurance within its stated scope; a qualified opinion identifies a qualification to understand.
2. Match the system description and scope to your chosen services and locations.
3. Check the reporting period and how recently it ended.
4. Read the tested controls and exceptions, including how they affect your use.
5. Identify complementary user entity controls (CUECs): controls your organization must operate.
6. Review the role and treatment of subservice organizations on which the provider relies.

A report can be favorable and still require your organization to manage user access, review logs or configure a setting. Copy those duties into your own control plan and assign owners.

On March 15, 2026, a team reviews a report covering October 1, 2024 through September 30, 2025. The twelve-month testing period ended 166 days earlier. A bridge letter gives the provider’s statement about relevant changes since that end date. It is not a new independent audit of every day in the gap. Obtain the next report when available.

Keep contracts with the evidence

The GDPR requires an appropriate controller–processor contract, usually supplied as a data processing agreement or addendum. Provider examples include the AWS GDPR addendum, Microsoft’s Products and Services Data Protection Addendum and Google’s Cloud Data Processing Addendum. HIPAA business-associate relationships require a BAA.

A report describes assessed controls. An agreement creates the relevant contractual commitments. One document cannot do the other’s job. Keep the applicable agreements accepted and current for the services being used.

Track customer controls as well

Record provider controls as inherited, then collect your own access reviews, configuration results, logs, policies and training records as applicable. AWS Config conformance packs group technical configuration checks; they do not assess every policy or staff procedure. Purview Compliance Manager supplies improvement actions and a compliance score. Google Assured Workloads applies supported controls for regulated workloads, including location and access restrictions.

Treat scores and findings as a work list with evidence to inspect. Resolve gaps in scope or dates before presenting the documents to a buyer or auditor, and check whether a newly adopted service or region requires a fresh review.

Data protection combines decisions about purpose, access, location and people’s rights. Moving records to a chosen region answers only the location part.

Know the roles and obligations

The GDPR, applicable since May 25, 2018, governs personal-data processing in its scope across the EU and EEA. It also reaches organizations outside the EU that offer goods or services to people in the EU or monitor their behavior there. It is not limited to EU citizens.

The controller decides the purposes and means of processing. The processor acts on the controller’s behalf. For hosted customer records, the customer is commonly the controller and the cloud provider its processor. Article 28 requires a written processing contract. Roles follow the actual processing relationship, not simply the company’s cloud label.

Cloud-relevant duties include a lawful basis, collecting only needed data (data minimization), risk-appropriate security, people’s access and erasure rights, and applicable breach reporting. Article 32 names encryption and pseudonymization as examples of security measures.

Under Article 33, a controller reports a personal-data breach to its supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless it is unlikely to risk people’s rights and freedoms. A processor informs its controller without undue delay. If awareness is Monday at 09:00, 72 hours ends Thursday at 09:00; it is not permission to wait when earlier notice is possible. A late authority notice must explain the delay.

Article 83’s upper tier allows a maximum of €20 million or 4% of the preceding year’s worldwide annual turnover, whichever is higher. For €1.5 billion turnover, 4% is €60 million; for €300 million it is €12 million, so the €20 million ceiling is higher. Actual penalties depend on the infringement and assessment.

Distinguish location requirements

Check a service’s location commitments, backups, replicas and support access. A region choice is not a blanket promise for every service feature. Government and sovereign offerings, such as AWS GovCloud (US), Azure Government and European sovereign options, address particular requirements with defined eligibility and scope.

Transfers outside the EEA need an applicable legal route, such as adequacy, standard contractual clauses or binding corporate rules. The EU–US Data Privacy Framework adequacy route applies to covered transfers to participating certified organizations. Access by staff in another country can also require transfer analysis even when storage stays in an EU region.

An insurer keeping claims in the EU selects EU storage and backup regions, applies supported location guardrails, controls key access and reviews its DPA and transfer terms. Customer-managed keys alone do not settle residency or transfer duties.

Encrypted personal data stays personal data for a party able to decrypt it. Effective encryption may remove the duty to notify affected people under Article 34 when its conditions are met; authority reporting has its own test. Other laws, including California’s CCPA as amended by CPRA and Brazil’s LGPD, have their own scope and duties.