Cloud Compliance and Auditing: From MLPS, GDPR to SOC2 – How to Prepare for Security Reviews
Create Time:2026-03-27 11:18:04
浏览量
1008

Cloud Compliance and Auditing: From MLPS, GDPR to SOC2 – How to Prepare for Security Reviews

微信图片_2026-03-27_105959_808.png

Last year, a SaaS client received an email that made their stomach drop. A European customer demanded proof of GDPR compliance. Two weeks. Or the contract—worth €300,000 annually—would be terminated.

Their engineering team pulled ten all-nighters. They scrambled logs, patched configurations, and pieced together evidence. The auditor glanced at their submission and sent it back: “Your audit logs only cover 30 days, violating GDPR. And the logs can be modified—no integrity proof.”

The deal died. €300,000 gone.

The client told me afterward: “I thought compliance was buying a certificate and hanging it on the wall. Now I know it’s something you design into how you run things, not something you patch up at the last minute.”

Today, let’s talk about cloud compliance and auditing. Not the “compliance is important” fluff, but the real stuff: what do frameworks like MLPS, GDPR, and SOC2 actually require? How do you configure audit trails in the cloud? How do you build an evidence chain? And what do you do when an auditor knocks?

01 Compliance Is Not a Certificate—It’s a Living Proof

Many people treat compliance like a one‑time project: spend money on an ISO certificate, frame it, forget it.

That’s a dangerous misunderstanding.

Compliance isn’t about having a piece of paper. It’s about continuously proving that you do what you say you do. Auditors don’t care about your framed certificate; they care about:

  • Do you periodically review access controls?

  • Can logs be tampered with?

  • Are vulnerabilities patched on time?

  • When employees leave, are their permissions revoked?

Compliance is not a project. It’s part of daily operations.

If your team’s approach is “we’ll fix it when the auditor comes,” you’re setting yourself up for failure. Real audits dig into history. They demand evidence chains. They don’t accept “we’ll turn it on now.”

02 Common Cloud Compliance Frameworks: What They Actually Require

Let’s walk through the frameworks you’ll most likely encounter. Not an exhaustive list, but enough to understand their core logic.

MLPS 2.0 (China – Multi‑Level Protection Scheme)

The baseline for operating in China. It focuses on physical security, network boundaries, secure computing environments, and centralized management. In the cloud, this means the platform itself must be MLPS‑certified, and tenants must implement controls like security groups, encryption, and audit logging.

GDPR (EU)

Protects personal data. Core principles: data minimization, user consent, data portability, right to be forgotten, and breach notification within 72 hours. For tech teams: data classification, encryption, audit logs, and a mechanism to delete user data on request.

SOC2 (International)

Based on the trust services criteria: security, availability, processing integrity, confidentiality, privacy. Auditors examine whether your claimed controls actually operate. They’ll sample logs, change records, and approval histories from the last 12 months.

PCI DSS (Payment Card Industry)

Mandatory if you handle credit card data. Requirements include firewalls, encryption in transit, strict access control, audit logging, vulnerability scanning, and penetration testing.

The specifics differ, but they share a common thread: all require complete, tamper‑proof audit logs retained for a defined period, and a clear evidence chain.

03 Audit Logs: The Only Proof You Did What You Said

Audit logs are the bedrock of compliance. They answer the auditor’s most fundamental question: “You claim you have these controls. Prove it.”

In the cloud, audit logs fall into three categories:

  • Control plane logs: Who created a server, modified a security group, or deleted a bucket. (CloudTrail, Azure Activity Log, Alibaba Cloud ActionTrail)

  • Data plane logs: Who accessed a database, read an object in storage, or called an API. (RDS logs, S3 access logs, API Gateway logs)

  • System logs: Operating system, middleware, and application logs. You must collect and centralize these yourself.

What auditors look for:

  • Completeness: Is there any gap? Any logs deleted?

  • Integrity: Can logs be altered? If someone with root access can modify them, they’re not acceptable.

  • Retention: Do you keep logs for the required period (e.g., 1 year for GDPR)?

  • Centralization: Are logs scattered across servers where they could be lost, or aggregated in a tamper‑proof store?

Many companies fail because they store logs on regular EC2 instances where anyone with root can edit or delete them. The compliance answer is immutable storage—object storage with WORM (Write Once, Read Many) enabled, or a dedicated log service that enforces immutability.

Counter‑intuitive truth: Audit logs aren’t primarily for troubleshooting. They’re for proving you didn’t do anything wrong. Integrity matters more than searchability.

04 Building Your Cloud Evidence Chain

Using AWS as an example, here’s a baseline audit configuration:

Step 1: Enable CloudTrail

Log all API calls to an S3 bucket. Enable “log file validation” to cryptographically verify integrity. Apply an S3 bucket policy with WORM to prevent deletion.

Step 2: Enable AWS Config

Track configuration changes over time. Who changed a security group, opened a port, terminated an instance? Every change is recorded.

Step 3: Enable GuardDuty and Security Hub

Continuous threat detection and compliance reporting. Auditors will ask: “How do you detect security incidents?” These are your answer.

Step 4: Centralize application and system logs

Use Fluentd, Logstash, or a cloud-native agent to ship OS, middleware, and app logs to S3 or OpenSearch. Apply the same WORM retention policies.

Step 5: Periodic export to a separate account/region

Copy critical logs to another account or region. If your main account is compromised, the logs survive.

Azure and Alibaba Cloud offer equivalent services: Activity Log, Azure Policy, Log Analytics, and OSS with compliance retention.

Set this up once. When an auditor comes, you give them a read‑only account and let them query. No more all‑nighters digging through logs.

05 Automated Compliance Checks: Make Auditing Boring

Beyond logs, auditors will check whether your security configurations stay compliant. Are all S3 buckets encrypted? Do all admins have MFA enabled? Are there unused security group rules?

If you rely on manual checks, you’ll miss things. Cloud providers offer automated compliance tools:

  • AWS Config: Write rules to check resource configurations. Non‑compliant resources can trigger alerts or even auto‑remediation.

  • Azure Policy: Similar—enforce rules at resource creation.

  • Alibaba Cloud Config: Monitors compliance against standards.

One SaaS client wrote about 20 AWS Config rules covering MLPS and SOC2 requirements. They run weekly. Non‑compliant resources automatically alert owners. When an auditor came, they exported the Config compliance report. The auditor said: “I rarely see this level of automation from companies your size.”

06 The Auditor Knocks: Three Steps to Survive

If you get an audit notice, don’t panic. Follow this three‑step process.

Step 1: Clarify scope

Ask: Which framework? Which systems? What time period? What specific evidence does the auditor need? Don’t guess—ask directly.

Step 2: Assemble evidence

Gather:

  • Org charts and role definitions

  • Security policies and operational runbooks

  • Audit logs, change records, approval histories for the requested period

  • Vulnerability scans and penetration test reports

  • Employee training records

Step 3: Dry run

Run a mock audit internally or with a consultant. Identify gaps before the real auditor arrives. Fix them.

The client who lost the €300,000 contract rebuilt their compliance program. Now they run quarterly mock audits. When a European prospect requested a GDPR review recently, they delivered the full evidence package in three days. The lead told me: “Now we don’t fear audits. We know exactly what to prepare—and it’s already in place.”

The Bottom Line

Compliance feels overwhelming. Different frameworks, countless requirements. But the core is simple: you must prove you do what you claim.

Instead of treating compliance as a burden, treat it as a forcing function to get your operational house in order. Centralized logs. Immutable storage. Automated checks. Clear evidence chains. These are things you should be doing anyway.

That client who lost the contract? They now say: “I used to think compliance was a cost. Now I see it’s a moat. Once you cross it, customers trust you with their data.”

Is your compliance a framed certificate on the wall—or a daily practice embedded in how you run things? If it’s the latter, an audit won’t keep you up at night.