Cloud Compliance Specialist

Cloud Compliance Specialist

When to Use

• Scope cloud workloads for SOC 2, ISO 27001, HIPAA, PCI, FedRAMP, or regional privacy rules
• Map framework controls to cloud-native evidence (Config, org trails, IAM reports, KMS)
• Build evidence collectors from cloud APIs and central log archive
• Prepare auditor walkthroughs for multi-account landing zones and SaaS on IaaS/PaaS
• Respond to customer security questionnaires with cloud control proof
• Design continuous cloud compliance dashboards (CIS conformance, posture rules)
• Document data residency — regions, replication, cross-border transfers (technical facts)
• Track cloud gap remediation before observation period or assessor visit
• Interpret provider shared responsibility and inheritance in audit narratives

When NOT to Use

• Enterprise-wide GRC program, policies, audit prep (non-cloud) → compliance-specialist
• Org-wide technical evidence automation → compliance-engineer
• Implement SCPs, IAM hardening, CSPM rules → cloud-security-engineer
• Landing zone architecture without compliance lens → cloud-architect, enterprise-cloud-architect
• Cloud program strategy and migration portfolio governance → vp-of-cloud
• Legal advice, DPAs, regulatory interpretation → commercial-counsel, corporate-counsel
• SOX financial controls and journal testing → senior-revenue-accountant
• Pipeline SAST/SBOM configuration → devsecops
• AI model regulatory classification → ai-risk-governance

Related skills

Core Workflows

1. Scope and shared responsibility

Cloud in-scope boundaries and provider vs customer duties for audits.

See `references/cloud_compliance_scope.md`.

2. Framework mapping in cloud

SOC 2, ISO, HIPAA, PCI, FedRAMP control patterns on cloud.

See `references/framework_cloud_mapping.md`.

3. Cloud evidence collection

API sources, samples, retention for assessors.

See `references/cloud_evidence_collection.md`.

4. Residency and sovereignty

Regions, replication, cross-border technical documentation.

See `references/residency_sovereignty.md`.

5. Continuous cloud monitoring

CSPM, Config rules, drift and exceptions.

See `references/continuous_cloud_monitoring.md`.

6. Audit readiness and customer assurance

Walkthroughs, CAIQ/SIG, gap closure.

See `references/audit_readiness_cloud.md`.

Outputs

• Cloud compliance scope memo — accounts, services, data classes, inherited controls
• Control-to-evidence matrix — framework ID, cloud check, source, cadence, owner
• Evidence package — exports with timestamps and population notes
• Residency diagram — regions, backups, DR, subprocessors (technical)
• CCM dashboard spec — rules, thresholds, exception register
• Assessor FAQ — shared responsibility, logging, encryption, access

Principles

• Inherit explicitly — document what the hyperscaler attests vs what you must prove
• Evidence from systems of record — APIs and logs, not screenshots alone
• Scope narrow — exclude out-of-scope accounts and legacy unless required
• Continuous over point-in-time — drift detection before the auditor finds it
• Partner with security — compliance defines what; cloud-security-engineer implements how

Audit readiness and customer assurance

Table of contents

1. Pre-audit checklist 2. Assessor walkthrough 3. Customer questionnaires 4. Gap remediation

Pre-audit checklist

4–6 weeks before observation end:

• [ ] Scope memo current (accounts, regions, services)
• [ ] Control-evidence matrix complete; owners assigned
• [ ] CCM critical findings at zero or excepted
• [ ] CloudTrail/org logs retained full period
• [ ] Access reviews completed with sign-off
• [ ] Backup/restore test evidence for in-scope data
• [ ] Provider SOC/BAA/AOC artifacts versioned
• [ ] Sample populations defined and dry-run collected
• [ ] Narratives drafted for inherited vs customer controls

Assessor walkthrough

Agenda (60–90 min technical session):

1. Architecture and scope (diagram, data flow) 2. Shared responsibility matrix 3. IAM and access (live console read-only or exports) 4. Logging and monitoring (trail query demo) 5. Encryption (KMS, default encryption) 6. Change management link to CI (devsecops evidence) 7. CCM dashboard and recent remediations 8. Q&A log with follow-up owners

Prepare read-only role; no production changes during session.

Customer questionnaires

CAIQ, SIG, VSA responses:

• Reuse control library answers mapped to cloud evidence
• Attach latest Config/Security Hub summary (redacted)
• Reference provider compliance artifacts where allowed under NDA
• Do not overclaim inherited controls — state customer configuration explicitly
• Align answers with actual regions and services sold

Legal review for contractual commitments → commercial-counsel.

Gap remediation

Gap lifecycle:

1. Identify — internal assessment, CCM, or assessor draft 2. Classify — observation vs finding; severity 3. Remediate — cloud-security-engineer implements; compliance verifies evidence 4. Validate — re-run rule or assessor re-test 5. Close — evidence attached to control ID

Track open gaps in shared register with due dates before report issuance.

For org-wide gaps spanning non-cloud → escalate to compliance-engineer.

Cloud compliance scope

Table of contents

1. Role boundary 2. Shared responsibility for audits 3. Scoping dimensions 4. Provider artifacts

Role boundary

Do not provide legal conclusions; document technical scope and artifacts.

Shared responsibility for audits

Prepare a responsibility matrix per workload type:

Auditors will ask: What did you configure vs what does the SOC report cover? Cite provider compliance reports (e.g., SOC 2 Type II for service) plus your customer responsibility evidence.

Scoping dimensions

Define in-scope:

• Cloud accounts/subscriptions and OUs
• Regions (residency)
• Services — EC2/RDS vs Lambda vs SaaS; PCI often excludes unmanaged IaaS unless in scope
• Data classes — PHI, PCI CHD, PII
• Environments — prod only vs prod+staging
• Subprocessors — list with cloud region and contract reference (legal owns contracts)

Document exclusions with risk acceptance and approver.

Provider artifacts

Collect and index (do not substitute for customer evidence):

Maintain version and review date; map to services you actually use.

Cloud evidence collection

Table of contents

1. Evidence principles 2. Source catalog 3. Collection cadence 4. Population sampling

Evidence principles

• Primary artifacts from APIs or immutable log store
• Timestamp and collector version in metadata
• Tamper-evident storage (WORM bucket, object lock)
• Redact customer data in shared audit folders
• Link to control ID and framework requirement

Broader non-cloud sources (HRIS, ticketing) → compliance-engineer evidence catalog.

Source catalog

Automate collectors where possible; manual export only with named owner and checksum.

Collection cadence

Align cutoff dates with observation period start/end.

Population sampling

For Type II populations (e.g., all prod changes):

• Define population query (date range, account filter)
• Document sample size and selection method (random, risk-based)
• Retain seed and script for reproducibility
• Note exceptions removed from population with reason

Auditors prefer repeatable selection over ad-hoc picks.

Continuous cloud monitoring

Table of contents

1. CCM architecture 2. Rule baselines 3. Exceptions 4. Metrics for leadership

CCM architecture

cloud APIs / Config / CSPM → rules engine → findings → ticket → remediate → re-test

Integrate with cloud-security-engineer for rule implementation and compliance-engineer for control ID mapping.

Org-wide:

• Delegated admin security account for centralized findings
• Suppress only with documented exception
• Route critical findings to SLA-based remediation

Rule baselines

Align rules to frameworks:

Map each rule to SOC/ISO control ID for auditor traceability.

Exceptions

Exception register fields:

• Control/rule ID
• Resource ARN and justification
• Compensating control
• Approver and expiry date
• Re-review trigger

Expired exceptions fail CCM dashboard; no silent renewals.

Metrics for leadership

Weekly/monthly:

• % accounts passing critical rules
• Mean time to remediate by severity
• Open exceptions by age
• Trend vs prior observation period

Use for pre-audit readiness—not as sole security KPI (cybersecurity program metrics separate).

Framework mapping in cloud

Table of contents

1. SOC 2 and ISO on cloud 2. HIPAA 3. PCI DSS 4. FedRAMP and government cloud 5. CIS and Well-Architected

SOC 2 and ISO on cloud

Common Trust Services Criteria → cloud evidence:

ISO 27001 Annex A: map same technical checks; add supplier evidence for cloud provider SOC.

HIPAA

Technical safeguards (customer responsibility on cloud):

• BAA executed with provider for in-scope services
• Encryption at rest and in transit for PHI stores
• Access controls — least privilege, MFA, audit logs
• Backup and DR — encrypted, access-controlled
• No PHI in unapproved regions or public resources

Evidence: Config rules for public exposure, KMS usage, log retention ≥ org policy.

Legal BAA scope → commercial-counsel; technical proof → this skill.

PCI DSS

Cloud scoping pitfalls:

• CHD environment boundary — network segmentation proof (SG/NSG, private subnets)
• No CHD on shared multi-tenant without compensating controls
• Logging and time sync for in-scope components
• Scanning — ASV for external; internal for in-scope CDE

Map each PCI requirement to specific account/VNet and service; exclude out-of-scope accounts from assessment boundary diagram.

FedRAMP and government cloud

• Use authorized services only (FedRAMP marketplace / GovCloud boundaries)
• Impact level (Low/Moderate/High) drives control baseline
• Leverage provider FedRAMP package for inherited controls; document customer configuration for remainder
• Change management and continuous monitoring align with ConMon expectations

Implementation of technical controls → cloud-security-engineer + enterprise-cloud-architect.

CIS and Well-Architected

Use as operational baselines mapped to audit controls:

• CIS AWS/GCP/Azure Benchmarks → Config conformance packs / SCC
• AWS Well-Architected Security pillar — gap input for remediation backlog

CIS pass ≠ SOC pass; use as continuous hygiene feeding CCM.

Residency and sovereignty

Table of contents

1. Technical documentation 2. Region and replication 3. Cross-border transfers 4. Subprocessors in cloud

Technical documentation

Provide engineers and assessors factual diagrams (not legal opinions):

• Primary region per workload and data store
• DR/backup regions and replication direction
• CDN/edge locations if customer data cached
• Logging and support personnel access regions (provider docs)

Update when architecture changes (cloud-architect sign-off).

Region and replication

Controls to verify:

• Resource policies restricting regions (SCPs, org policies, policy assignments)
• Default region in IaC and CI
• RDS/GCS/SQL cross-region replica documented
• S3/GCS/Blob replication rules and destination buckets
• KMS keys regional and not unintentionally multi-region where prohibited

Evidence: Config rules “approved regions only”; export of resource inventory by region.

Cross-border transfers

Document technical paths when data may leave jurisdiction:

• Replication to DR region in another country
• Global services (support, logging aggregation) per provider data processing terms
• Third-party SaaS integrated with cloud data

Legal mechanism (SCCs, adequacy) → legal/commercial; engineering documents what flows where.

Subprocessors in cloud

Maintain table:

Refresh when enabling new cloud marketplace integrations or regions.