Compliance Architecture and Controls Questions

Focuses on translating legal and regulatory obligations into technical architecture and operational controls. Candidates should demonstrate how to map requirements such as data handling rules, consent models, retention and deletion mechanisms, data subject rights workflows, breach notification processes, and processor agreement obligations into concrete design decisions and controls. Expected topics include data residency and sovereignty decisions, encryption and key management, access control and privileged access management, audit logging and tamper resistant audit trails, retention and immutability policies, backups and recovery, segmentation and isolation, change management and configuration baselining, and third party and vendor risk controls. Candidates should be able to explain trade offs between engineering feasibility and regulatory obligations, provide examples of systems or features designed or modified to meet compliance needs, describe interactions with legal, privacy, and compliance teams to interpret rules, and explain how testing, monitoring, incident response, and documentation support audit readiness and continuous compliance.

MediumTechnical

35 practiced

Design a key management model that supports tenant-owned keys (BYOK) and tenant-isolated master keys in a multi-tenant SaaS. Describe key lifecycle management (generation/import, rotation, revocation), envelope encryption patterns, KMS vs HSM choices, access control restrictions, and how you would handle data re-encryption, backup key management, and customer key revocation scenarios.

Sample Answer

**Design summary**Provide tenant-owned keys (BYOK) and tenant-isolated master keys using per-tenant Key Encryption Keys (KEKs) stored in a hardened KMS backed by HSMs. Data encrypted with per-tenant Data Encryption Keys (DEKs) using envelope encryption; DEKs wrapped by tenant KEKs.

**Key lifecycle**- Generation / Import: Allow tenants to import/export KEKs (PKCS#12/ JWK) or generate via HSM-backed KMS. Enforce HSM attestation, secure import API, and audit logging.- Rotation: Rotate DEKs regularly (application-triggered) and rotate KEKs on policy; rotation produces new KEK version, rewraps active DEKs; use lazy re-encryption for data blobs.- Revocation: Mark KEK as revoked in metadata, immediately deny wrap/unwrap. Track key states and retention window for recovery.

**Envelope encryption pattern**- DEK (symmetric AES-GCM) per object, stored encrypted as: ciphertext + wrapped_DEK + key_version metadata.- On read: unwrap DEK with tenant KEK in HSM/KMS, then decrypt. Avoid exposing plaintext keys outside HSM boundary.

**KMS vs HSM**- Use HSM-backed KMS for tenant KEKs for FIPS/PCI compliance and tamper resistance.- For lower-sensitivity tenants, managed KMS with strict tenancy isolation may be acceptable.- Prefer Bring-Your-Own-Key mapped to distinct KMS key resources per tenant; HSM for imported keys when requested.

**Access control & restrictions**- Enforce least privilege: service principals have wrap/unwrap only; app layer holds only wrapped DEKs.- RBAC + attribute-based policies: tie KEK access to tenant ID, environment, and per-operation MFA for key import/export.- Network restrictions: require requests from vetted service endpoints; use key access logs and alerts.

**Data re-encryption & backup key management**- Re-encryption: support online lazy re-encryption (on-write) and background bulk jobs for cold data. Use versioned metadata to support dual-read during migration.- Backup keys: back up KEKs encrypted under a secondary root-of-trust (separate HSM cluster) with strict custodial controls and multi-party authorization for restore.

**Customer key revocation scenarios**- If tenant revokes/requests deletion: stop future unwraps, schedule secure shredding of KEK material, and then either (a) delete wrapped DEKs making data unrecoverable, or (b) provide tenant opportunity to export DEKs within retention window. Log and notify tenant; for compliance, support legal holds and escrow policies.

**Operational controls**- Audit, alerting, periodic key use reviews, attestation, and tamper-evident logs. Provide SLA for key availability and documented incident playbooks for key compromise.

HardTechnical

22 practiced

You receive an external audit report identifying several high-severity control failures (improper change management, missing privileged access logs, incomplete processor agreements). Draft a remediation plan: list technical fixes, interim compensating controls, timelines, resource assignments, regression testing, communication with regulators/customers, and how you would ensure recurrence prevention and collect post-remediation evidence for auditors.

Sample Answer

**Situation & Objectives**Receive high-severity findings: improper change management, missing privileged access logs, incomplete processor agreements. Goal: remediate within risk-based timeline, provide evidence to auditors, and prevent recurrence.

**Remediation Plan (high level)**- Technical fixes - Change management: enforce CI/CD pipelines, implement code-reviews and signed approvals in ticketing (Jira), integrate gated deployments (feature flags, automated tests). - PAM & logging: deploy/extend Privileged Access Management (CyberArk/Thycotic), enable session recording, centralize logs to SIEM (Splunk/Elastic) with immutable storage and retention policies. - Processor agreements: legal to finalize Data Processing Agreements (DPAs) with standard contractual clauses; map data flows to ensure scope.- Interim compensating controls - Freeze high-risk deployments until approvals; require dual approvals for production changes. - Manual privileged session monitoring with live supervisor and increase logging verbosity; temporary vaulting of credentials. - Execute interim Memoranda of Understanding (MOUs) and add contractual statements of responsibility.

**Timelines & Resources**- Week 0–2: Triage, risk ranking, assign owners (Security Architect leads), remediation sprints (Infra, DevOps, Legal), weekly status.- Week 3–8: Implement PAM, SIEM ingestion, CI/CD gates; legal executes DPAs in parallel.- Week 9–12: Regression testing, documentation, auditor evidence package.

Owners: Security Architect (program lead), DevOps (CI/CD), Infra (PAM/logs), Legal/Procurement (DPAs), QA (testing).

**Regression & Validation**- Test plans: change workflow acceptance tests, PAM session replay review, SIEM alerting validation.- Use automation: run end-to-end deployment pipelines in staging; run integrity checks and random audits of logged sessions.- Pen-test / configuration audit post-remediation.

**Communication**- Regulators/customers: immediate notification of remediation plan, regular status updates, offer remediation timelines and attestations once complete.- Internal: executive summaries weekly; change advisory board approvals for scope.

**Recurrence Prevention**- Update policies: change management, privileged access, vendor risk.- Embed into architecture: enforce infrastructure-as-code, automated policy checks (OPA/Gatekeeper), continuous compliance scanning.- Training: role-based training for DevOps and approvers; quarterly audits.

**Evidence Collection for Auditors**- Signed change tickets, CI/CD audit logs, PAM session recordings, SIEM logs with checksum/timestamps, executed DPAs, policy updates, test results, meeting minutes. Store evidence in read-only evidence repository and provide index with chain-of-custody.

I would present this plan as a prioritized remediation roadmap, track via a Gantt and RASCI, and brief the board at completion.

EasyTechnical

23 practiced

Explain the purpose of Privileged Access Management (PAM) and identify five concrete technical and operational controls a Security Architect should deploy to manage and monitor privileged accounts across cloud and on-prem environments. Explain briefly how each control supports compliance obligations such as separation of duties and auditability.

Sample Answer

**Purpose of PAM (brief)** As a Security Architect I view Privileged Access Management as the set of controls and processes that secure, monitor, and govern high‑risk accounts (local admin, domain admin, cloud root, service accounts) to reduce attack surface, enforce least privilege, and provide forensic/audit evidence.

**Five technical & operational controls**

1. **Centralized credential vaulting & rotation** - Store secrets in a hardened vault (vault servers, HSM-backed) and automate ephemeral credential rotation. - Supports SoD: prevents long-lived shared passwords; different teams cannot reuse creds. Auditability: vault logs show who requested/issued secrets.

2. **Just‑In‑Time (JIT) provisioning / time‑bound elevation** - Grant temporary privileged roles only for the task window via workflow approval. - SoD: separates approver from executor. Auditability: issuance records include request, approver, duration.

3. **Role‑based least‑privilege access (RBAC / ABAC)** - Define minimal privilege roles (cloud IAM policies, local groups) and enforce via identity provider. - SoD: clear role boundaries reduce overlap of sensitive duties. Auditability: role assignment changes are logged.

4. **Session brokering and full session recording/keystroke capture** - Force privileged sessions through a broker that records video, commands, and enables live termination. - SoD: approvals and monitoring prevent unauthorized unilateral actions. Auditability: immutable session recordings and indexed transcripts for investigations.

5. **Continuous monitoring and alerting with SIEM integration** - Ingest vault, IAM, and session logs to detect anomalies (off‑hours use, privilege escalation) and trigger workflows. - SoD: enforces separation through automated policy enforcement; Auditability: centralized, tamper‑evident audit trail mapped to compliance reports.

Each control ties to compliance by providing enforced separation of duties, strong provenance of privileged actions, and immutable logs/evidence for audits and incident response.

HardTechnical

20 practiced

Your platform stores petabytes of tenant data encrypted with envelope encryption. A large customer requests a master-key rotation and full re-encryption of their data within 24 hours. Describe a scalable design to meet this request with minimal downtime and cost. Discuss eager versus lazy re-encryption, re-encryption proxies, indirection layers, metadata strategies, backup consistency during re-encryption, and how to verify and roll back if an error occurs.

Sample Answer

**Clarify requirements & constraints**- 24-hour SLA, multi‑petabyte tenant data, envelope encryption (data encrypted with DEKs, DEKs encrypted with KEKs), minimal downtime and cost, auditability and rollback.

**High-level design**- Introduce an indirection layer: store per-object metadata pointer to encrypted DEK (KMS-wrapped). Applications read DEK via a re-encryption-aware key service (proxy) that abstracts KEK versioning.- Deploy a scalable re-encryption fleet (stateless workers) that operate on object metadata and DEKs only — avoid touching object blobs where possible.

**Eager vs Lazy trade-offs**- Eager: re-encrypt all DEKs immediately (fastest to converge, strongest post-change assurance). Pros: simple verification, no lingering weaker keys. Cons: high peak I/O, cost, risk of throttling.- Lazy: re-encrypt on-access over time (low immediate cost, low downtime). Cons: prolonged exposure window, complex audit and backup consistency.- Recommendation: hybrid — eager re-encrypt all DEKs (small, faster than full data) immediately; if DEKs are embedded with blobs, use chunked parallel workers; if not, perform lazy blob re-encryption on first write/read.

**Re-encryption proxy & indirection**- Key service exposes GetDEK(object_id, desired_kek_version) which: - Returns DEK decrypted with new KEK if already re-encrypted. - Otherwise, will atomically re-wrap DEK (via worker or inline re-wrap) and return it.- Keep object encryption separate from blob storage so workers only update KMS‑wrapped DEKs in metadata store (low bandwidth).

**Metadata strategies**- Store: object_id, dek_wrapped_versions (list), current_kek_version, reencrypt_state (pending/in-progress/done), checksum of plaintext DEK fingerprint.- Use versioned metadata store with CAS to avoid races.

**Backup & consistency**- Snapshot metadata and object index prior to start; tag backups with KEK version.- Ensure backups include both old and new wrapped-DEKs or a migration manifest to allow restores under either KEK.- During re-encryption, write actions must atomically update object data + metadata (two-phase or transactional write) to avoid split-brain.

**Verification & rollback**- Verification: sample-driven integrity checks — for each rewrapped DEK, decrypt with new KEK and verify DEK fingerprint matches expected hash stored in metadata. Maintain a verification ledger.- Rollback: keep prior wrapped-DEK entries until new DEKs are fully verified and durable. If errors exceed threshold, pause workers, revert metadata current_kek_version pointers via atomic CAS to prior version, and use rollback script to re‑wrap or point reads to old KEK.- Implement automated throttling, backoff, and circuit-breakers; alerting & audit logs for every rewrap.

**Operational plan**- Pre-provision workers across zones; test on a canary subset (1% of tenant data), validate performance, correctness.- Run full re-encrypt DEKs eagerly (parallelism tuned to KMS/QPS limits), then lazy re-encrypt blobs on access or scheduled background for heavy objects.- Provide an SLA-conscious schedule, cost estimate (KMS API calls, metadata writes, compute), and post-migration attestation for compliance.

This approach minimizes downtime by focusing on small DEK objects, uses proxies/indirection for safe transition, balances eager guarantees with cost via hybrid strategy, ensures backup consistency, and provides verifiable rollback paths.

HardTechnical

22 practiced

You must architect backup storage for 1PB of regulated data with jurisdiction-specific retention policies (1 year, 7 years, indefinite under litigation). Propose a tiered storage and indexing architecture that meets retention and legal-hold needs while optimizing cost and enabling efficient e-discovery and auditability. Discuss immutability, metadata indexing, and migration strategy.

Sample Answer

**Approach overview**Design a three-tier immutable backup storage with a global metadata index and legal-hold layer to satisfy 1PB regulated data, jurisdictional retention (1yr, 7yr, indefinite), e-discovery and auditability while minimizing cost.

**Tiered storage**- Hot (short-term restore): SSD-backed object store or NAS for 0–30 days; encrypted, frequent integrity checks.- Warm (compliance): Cloud object storage (S3 Standard-IA / Azure Cool) for 30 days–7 years; lifecycle policies enforce transitions.- Cold/Archive (long-term & legal-hold): WORM-capable object lock + tape vault (AWS Glacier Vault Lock / offline LTO with managed index) for 7 years→indefinite.

**Immutability & legal hold**- Apply immutable retention (WORM/object-lock) at ingest per jurisdiction policy.- Separate legal-hold namespace: when litigation flag set, move pointer to legal-hold tier and extend retention to indefinite; prevent deletions until hold release with cryptographically signed retention records.

**Metadata indexing & e-discovery**- Global metadata catalog in a hardened search DB (Elasticsearch/OpenSearch with RBAC, snapshotting). Store: jurisdiction, retention class, checksum, encryption key ID, content hash, ingestion time, custodian, chain-of-custody events.- Index supports full-text (if permitted), tags, and time-range queries; audit logs for every access/change.

**Migration strategy**- Policy-driven lifecycle engine: rule engine evaluates jurisdiction + age + hold flag → executes secure copy then sets immutability on target and updates index atomically.- Validate via checksums and signed manifests; retain migration audit trail.

**Security & compliance controls**- Envelope encryption: per-tenant CMKs in KMS with key rotation; strict KMS access via IAM and key policies.- MFA & CA-signed requests for retention changes; SIEM integration for alerts and audit.- Regular retention and legal-hold audits; periodic DR restores and forensic-ready exports.

**Trade-offs**- Cost vs retrieval latency: tape/Glacier saves cost but increases e-discovery latency; mitigate with cached index and staged retrieval workflows.- Complexity: strong automation required to avoid human errors in retention/holds.

This architecture ensures regulatory retention, provable immutability, efficient e-discovery via indexed metadata, and cost optimization through tiering and policy-driven migration.

Unlock Full Question Bank

Get access to hundreds of Compliance Architecture and Controls interview questions and detailed answers.

Join thousands of developers preparing for their dream job.