面试准备一些资料

Interview/SOC2 Audit in Practice - Interview Prep (EN).md

@@ -0,0 +1,327 @@
+---
+title: SOC 2 in Practice — Interview-Ready Experience Notes
+source: "[[SOC2 Audit in Practice]]"
+tags: [soc2, compliance, audit, interview, cloud-devops]
+---
+
+# SOC 2 in Practice — Interview-Ready Experience Notes
+
+Interview-oriented rewrite of my hands-on SOC 2 notes: what I owned, how each control actually ran, what evidence it produced, and how to tell the story in English in 30 seconds, 2 minutes, or 20 minutes depending on the room.
+
+## 0. Contents
+
+1. Fast facts (the fact sheet I keep in my head)
+2. 30-second pitch (say it verbatim)
+3. 2-minute STAR narrative
+4. Control deep dives by Trust Services Category
+5. The evidence model (why the controls survive an audit)
+6. Numbers to quote
+7. Likely interview questions and short answers
+8. Gaps and what I would improve (say this — it signals seniority)
+9. Vocabulary bank (English phrasing for this domain)
+10. Transcription corrections vs. the raw notes
+
+---
+
+## 1. Fast facts
+
+- **Role:** Cloud Service Delivery Manager, and designated **account owner** for the AWS account estate.
+- **Scope:** approximately **23 AWS accounts**, shared across Operations, DevOps domain teams (Network, CCOE) and Architecture.
+- **Access model:** AWS access is federated with the corporate **single sign-on** (email-based authentication), so the authoritative list of who can reach a given account lives with the IT organisation at a higher level — I request it, I do not own it.
+- **Platform:** multi-tenant B2B SaaS application running on **AWS EKS** (Kubernetes), **RDS** and **EFS**.
+- **Regulatory landscape:** SOC 2 across all five Trust Services Categories, plus **FedRAMP** for the US instance and **GDPR** for the EU environment.
+- **Recurring cadence:** quarterly access reviews · monthly hardened-AMI/patch cycle · backups every 6 hours · 7-day retention · two DR tests per year.
+- **Committed service levels:** **RPO 6 hours / RTO 24 hours**, published in the SaaS Service Description.
+
+---
+
+## 2. 30-second pitch (say it verbatim)
+
+> "I'm the Cloud Service Delivery Manager for a multi-tenant SaaS platform on AWS, and I'm the account owner for about 23 AWS accounts. A large part of my job is being the **control owner** for our SOC 2 programme rather than just a participant in it: I run the quarterly access recertification across every account, I own the segregation rule that keeps Operations out of the product source code, I run vulnerability management at the OS layer through Qualys and our hardened AMI baseline, and I own cross-region backup and twice-yearly disaster recovery testing against a published 6-hour RPO and 24-hour RTO. What I really built is the evidence trail — so that when the auditor samples any quarter, the source list, the decision, the action and the sign-off are already there."
+
+Why this works: it names the domain, the scale, the controls owned, the numbers, and the differentiator (evidence-by-default, not audit-by-fire-drill).
+
+---
+
+## 3. 2-minute STAR narrative
+
+**Situation.** A B2B SaaS business running on AWS with customers who require a SOC 2 Type II report before they will sign. Five Trust Services Categories in scope. The cloud estate spans ~23 AWS accounts with several engineering groups — Operations, DevOps (Network team, Cloud Center of Excellence), Architecture — plus product engineering teams that own the application. Compliance had to be produced by people who were already running the platform, across regions with different regulatory regimes (FedRAMP in the US, GDPR in the EU).
+
+**Task.** I owned the recurring operational controls and the evidence they generate: access control and recertification, source-code segregation, vulnerability management, backup and disaster recovery, the non-production data rule, and the customer-exit data-deletion process — each with a named approver and a retained record.
+
+**Action.** I turned each one into a documented, repeatable loop rather than an annual scramble: role-based IAM personas with least privilege (Operations broadest, DevOps domain teams scoped to their domain, read-only for Architecture); a quarterly six-step access review driven off the SSO access list with escalation to peer managers and immediate revocation for leavers; a permissions check against GitLab proving Operations cannot reach product source code; a severity-filtered vulnerability pipeline that splits OS-level findings (fixed via the monthly CCOE hardened AMI) from library-level findings (routed to product teams, re-scanned and diffed against the previous review); AWS-native backup every 6 hours with cross-region replication and two tiers of restore strategy; two DR tests a year — one integrity-only, one full production failover; and a staging environment that is provably free of customer data and PII.
+
+**Result.** The controls run on cadence, each producing a raw list → decision record → action record → management sign-off chain that the auditor can sample. The audit becomes a reporting exercise over evidence that already exists, instead of a project that consumes a quarter of engineering time. *(Fill in your own closing metrics here — e.g. number of findings closed per cycle, audit outcome, deals unblocked. The raw notes do not record them; do not invent them in an interview.)*
+
+---
+
+## 4. Control deep dives by Trust Services Category
+
+### 4.1 Security
+
+#### A. AWS account access review — quarterly access recertification
+
+**Control objective.** Only authorised, currently-employed, appropriately-scoped people can reach production AWS accounts, and that is revalidated on a fixed cadence.
+
+**Design — three IAM persona tiers, least privilege by default:**
+
+- **Operations** — broadest privilege. They operate and upgrade resources on AWS and make network changes.
+- **DevOps domain teams** (Network team, CCOE) — narrower, scoped to their area. CCOE owns the OS-level AMI update pipeline.
+- **Architecture** — read-only. They need to pull information out of the environment but must never modify anything in the accounts.
+
+**Execution — the repeatable six-step loop:**
+
+1. Every three months, obtain the **account access list for the trailing three months** from the primary account owner / IT organisation (access is SSO-backed, so the authoritative user list sits at that higher IT level).
+2. **Classify** every identity in the list by group: Operations, DevOps, Architecture.
+3. **Re-validate the permission set** each identity actually holds against the IAM role baseline for that group.
+4. **Verify employment status** for my own Operations team; for identities I neither recognise nor own, escalate to the relevant DevOps or Architecture group manager for confirmation.
+5. **Revoke immediately** — anyone who has left the company, or who no longer needs the access, is cut off at once. This is the remediation step: access revocation.
+6. **Produce a summary report** and obtain sign-off from my Director/Manager and senior management, confirming the review was performed.
+
+**Evidence retained:** the raw access lists, the revocation record, and the confirmation emails exchanged with peer managers.
+
+**Interview line:** *"The control isn't the review — the control is the paper trail. Pulling the list and reclassifying it takes a day; what takes discipline is capturing the source list, the exception decision and the sign-off so that a sample from any quarter tells the same story to the auditor."*
+
+#### B. Segregation — Operations must not touch product source code
+
+**Control objective.** Operations admins must not be able to read or commit to the product source code repositories, so they cannot alter product logic or security-relevant behaviour.
+
+**Check:**
+- The Product Team owner/manager is the **repository owner** and holds the authoritative list of identities permitted on those repos. I request that list.
+- I then verify our **Operations identities against the GitLab permission set** — the expected result is that no Operations identity appears in the authorised list.
+
+**Exception handling.** If an Operations engineer is found with access, the permission is revoked. The raw list, the revocation record and the summary report are retained and signed off by senior management.
+
+#### C. Vulnerability management (Qualys + Prisma/Defender)
+
+**Sources.** Qualys scans the **cloud application runtime OS** (Linux) and surfaces risks and vulnerabilities at the OS layer; Prisma/Defender provides additional scanning. As account owner I receive the periodic policy reports — they are very large and cover many facets of the OS.
+
+**The remediation pipeline:**
+
+1. **Filter by severity**, then separate **OS-level findings** from **application/library-level findings**.
+2. **OS-level** — remediate through the **CCOE hardened standard Linux AMI**. We started on AWS-native Linux hardening and later adopted the CCOE standard AMI to meet specific customer and security requirements. CCOE publishes roughly **monthly**, with the latest patches, and tests before release; we consume the tested image and schedule the upgrade.
+3. **Library-level** — findings that will not be fixed by an OS upgrade route to the **product/development team** as a request to upgrade the affected library version.
+4. **Define the plan** — which findings are fixed in the next cycle, prioritised by severity.
+5. **Re-scan and diff** — after the AMI upgrade and the product patches land, compare the new policy report against the previous review: mark what is fixed, highlight what is not, and re-plan the remainder by severity.
+6. **Document the whole chain** — findings, filtering, review, fix, testing, sign-off — for the audit.
+
+**Worked example to tell in an interview:** Qualys surfaced findings caused by an **out-of-date Kubernetes version**; the remediation was planned as an **EKS version upgrade** in the next release cycle.
+
+#### D. Risk assessment — *not yet written up in the source notes*
+
+The raw notes leave this empty. Prepare to speak to whatever you actually have: a dated annual risk assessment, a risk register with owner and treatment decision, and evidence that the register fed the control set. If that does not exist, treat it as a gap (§8) rather than claiming it.
+
+---
+
+### 4.2 Availability
+
+#### A. Backup strategy — roughly 90% AWS cloud-native
+
+- **What is not backed up:** container images. They are build artifacts published by R&D to GitHub on every release, so backing them up adds no recovery value.
+- **What is backed up:** the **Kubernetes configuration** — the YAML manifests that describe the web application, its pod layout and worker-node distribution. Restoring those lets us rebuild the containerised application quickly and consistently.
+- **Data tier:** **RDS and EFS** are backed up through **AWS Backup** with defined backup plans; the cadence is **every 6 hours**.
+- **Cross-region:** additional scripts replicate RDS backups into a second remote region — **Oregon → North Virginia**, and **Frankfurt → Ireland**.
+- **Retention:** **7 days**.
+- **Driver:** the disaster-recovery commitments published in the **SaaS Service Description**; the objective is to keep data exposure within roughly **6 hours**.
+
+#### B. Replication and restore strategy — two tiers, cost-driven
+
+- **Tier 1 — cold / remote backup (default).** Cross-region snapshots. Cheap, slower to activate. Chosen for cost reasons.
+- **Tier 2 — warm standby (faster RTO).** Periodically **restore** the RDS and EFS snapshots directly into a live database in the secondary (North Virginia) environment, rather than leaving them as snapshots. This does **not** run a full runtime instance, but it materially shortens the time needed to bring the cloud service back in the second region. It costs more.
+- **Selection:** the tier is chosen per customer according to their requirements — a deliberate cost-versus-RTO trade-off.
+
+#### C. Disaster recovery testing — twice a year (DR integrity testing)
+
+**Test 1 — lightweight, no impact on production.** A data-integrity validation. We take the backup data — device configuration files plus the RDS data backup — and restore it into a **backup environment in the same region as production but isolated from it**. We measure how long the restore takes. There is no cutover and no customer impact.
+
+**Test 2 — full DR / production failover.** This one exercises the **remote-region backups**. It typically runs as a weekend cutover:
+
+1. Stop the production environment.
+2. Restore the remote-region instance using the latest backup delta.
+3. Cut production traffic over to the remote-region environment and resume data flow so customers are served.
+4. Roughly **one week later**, replicate the data back to the original production environment.
+5. Run a **service load/pressure test**, then fail back to the original environment.
+
+This test is materially more demanding — it is a real failover and failback, run against a real customer commitment.
+
+**Acceptance criteria.** The RPO and RTO committed to customers in the SaaS Service Description: **RPO 6 hours, RTO 24 hours**. The strategy exists to satisfy that commitment, not an internal preference.
+
+#### D. Processing capacity and multi-location strategy — *not yet written up in the source notes*
+
+---
+
+### 4.3 Confidentiality
+
+#### A. Confidential information in non-production environments
+
+- We maintain a **dedicated staging environment** used for application upgrades, patch and hotfix deployment, cloud-infrastructure changes and automated testing.
+- **The assertion we have to prove:** staging contains no production or customer confidential data, and no **PII**.
+- **How it is evidenced:** provide the staging environment's **tenant names**, plus a live walkthrough/demonstration for the auditor, showing that only synthetic test data is in use and that real customer data never reaches staging.
+
+#### B. Data deletion and removal practices — the customer exit process
+
+**The contractual promise (Service Decommissioning, per the SaaS Service Description):** on expiry or termination of the order term, the provider may disable all customer access to the SaaS, and the customer shall promptly return or destroy any provider materials. The provider makes available any SaaS data in its possession in the format generally provided, within the **Termination Data Retrieval Period SLO**. After that period the provider has no obligation to maintain or provide the data, which is deleted in the ordinary course.
+
+**Communication and coordination**
+- Notify all relevant internal teams — support, billing, account management, cloud service.
+- Designate a **single point of contact** to manage the transition and answer queries promptly; in practice this is usually the CSM.
+
+**Data management**
+- Ensure the customer can export their data easily, and assist where needed.
+- Plan **secure deletion** of customer data after the agreed period, in line with data-protection regulation and the data-retention policy.
+- Give a clear timeline for how long data remains accessible after service termination.
+
+**Security and compliance**
+- **Revoke access** — disable all user accounts associated with the customer.
+- **Compliance check** — confirm the termination process satisfies relevant legal and regulatory requirements such as **GDPR** or **CCPA**.
+
+**Detailed steps**
+
+1. **Customer raises a service request** — the exit project is triggered by a request in **PCS**, and all related communication stays in PCS until every task is complete and the user account is closed there. The request must state: whether the customer wants existing **ESM/SMAX transaction data exported**; the date they want all tenant data completely emptied; the exact date by which the provider commits all relevant data — **including backups** — is cleaned out; and the date the PCS support channel is to be closed.
+2. **Assist with data export.**
+   - **SMAX** — customers can use **OData export**; Cloud Ops helps by running the existing out-of-the-box OData export script to export SMAX transaction data per tenant.
+   - **CMS / HCMX / OO** — not supported at the time.
+   - **PCS data** — not supported at the time.
+3. **Plan data deletion.**
+   - Notify the customer when the tenant will be terminated and all data deleted; Cloud Ops drives this notification from PCS.
+   - **Scope of deletion:** tenant data, user data, account data (in BO) and inactive PCS entitlements.
+   - **Retention:** farm-level data retention is **7 days** — after 7 days, customer data is permanently removed from the cloud environment.
+
+---
+
+### 4.4 Processing Integrity
+
+*(from the linked process notes: `[[Major Incident Management Process]]`, `[[Cloud Change Management Process]]`)*
+
+#### A. Cloud change management
+
+- **Definition of a change:** anything — hardware, software, system components, services or processes — deliberately introduced into production that may affect an SLA or the functioning of the environment or one of its components. Drivers include user requests, vendor-recommended changes, regulatory changes, upgrades, failures, infrastructure modifications, unforeseen events and periodic changes.
+- **Planned change:** scheduled **at least 2 weeks in advance** when customer action is required, or **at least 4 days in advance** otherwise.
+- **Emergency change:** a critical change to prevent loss of service functionality or availability. Requires approval from the **Cloud Delivery Manager, TO Manager or CS Manager**, and is scheduled at least 1 day ahead unless it is critical to resolve a major incident immediately.
+- **Change record:** every change is recorded in the **Essentials** system.
+- **CAB review:**
+  - *No CAB required* — routine, frequently executed, pre-approved by an executive, low likelihood of disruption (e.g. monthly patch upgrade, routine EKS upgrade).
+  - *CAB required* — non-exempt changes, typically maintenance-window changes involving more than one executor (e.g. major product version upgrade, AWS infrastructure change, landing-zone migration).
+- **Customer notification:** a centralised notification system and Service Health portal publish current availability, upcoming planned maintenance, outage reports and historical SLO data.
+
+#### B. Major incident management
+
+- **Detection:** automated monitoring for anomalies and performance issues, plus user reports through designated channels.
+- **Definition of a major incident:** service outage (users cannot access the application at all), performance degradation (evident in monitoring or user feedback), or major functionality impact (tracked through APM).
+- **Response:** rapid triage by a cross-functional team spanning development, operations and support; impact analysis across users, systems and business operations; structured communication and tracking until closure.
+
+---
+
+### 4.5 Privacy
+
+#### A. Data controller and region-restricted personnel access
+
+Two environments in the estate carry hard residency and personnel constraints, and the control is enforced on **who may touch the data**, not just on network boundaries:
+
+- **United States instance (FedRAMP).** Only **US citizens physically located in the US** may touch any data in that environment. Engineers in China, India and Europe are deliberately excluded. Only US-based Operations engineers are authorised to operate, access and maintain that environment.
+- **European environment (GDPR).** Only **European engineers** may access those specific environments; engineers from other regions have no access.
+
+**How this shows up in the control set:** the regional restriction is designed into the access model, and the quarterly access review is where it is verified — the "who" has to keep matching the "where".
+
+**Reference notes:** `[[GDPR]]`, `[[FedRAMP Basics Understanding Federal Cloud Security Standards]]`.
+
+---
+
+## 5. The evidence model — why these controls survive an audit
+
+Every recurring control I ran produces the same **four-artifact chain**. This is the part worth explaining in an interview, because it is what distinguishes an operator from a control owner:
+
+1. **Source of truth (raw input)** — the three-month account access list; the GitLab authorised-user list; the Qualys/Defender policy report.
+2. **Decision record** — my classification and triage with the rationale: who stays, who is revoked, which findings are deferred and why.
+3. **Action record** — the revocation; the permission removal; the AMI upgrade; the remediation plan and the re-scan diff.
+4. **Sign-off** — the summary report signed by Director/Manager/senior management, plus the confirmation emails from peer managers for identities I do not own.
+
+The auditor does not need to reconstruct the quarter; the quarter is already on file.
+
+---
+
+## 6. Numbers to quote
+
+- **~23 AWS accounts** owned and reviewed as account owner.
+- **Quarterly** access recertification; each review covers a **3-month** access window.
+- **3 IAM persona tiers** — Operations, DevOps domain teams, read-only Architect.
+- **Monthly** hardened-AMI release cadence from CCOE; **2 scanning platforms** (Qualys, Prisma/Defender).
+- Backups **every 6 hours** for RDS/EFS; **7-day** retention; **2 cross-region pairs** (Oregon→N. Virginia, Frankfurt→Ireland).
+- **2 DR tests per year** — one integrity-only, one full failover with a weekend cutover and a ~1-week failback.
+- Committed **RPO 6 hours / RTO 24 hours**.
+- Change management: planned changes **≥2 weeks** (when customer action is needed) or **≥4 days**; emergency changes **≥1 day** with named approvers.
+- Customer exit: farm-level data retention **7 days**, then permanent removal.
+
+---
+
+## 7. Likely interview questions and short answers
+
+**"How did you keep quarterly access reviews across 23 accounts from becoming a rubber stamp?"**
+Two things. First, I never reviewed only my own team — unknown identities were escalated to the owning manager for confirmation, which forced a real answer rather than a default approval. Second, every review had to end with a revocation decision or an explicit "no change", signed off by senior management. The output is a report, not a checkbox.
+
+**"What is the most common finding in an access review?"**
+Stale access — people who have left, or moved roles, but whose identity still appears on the list. Because AWS access is federated to corporate SSO, the identity can still exist in the list even when the person is gone. That is exactly why the review cross-checks the list against current employment rather than trusting the list.
+
+**"How did you implement least privilege?"**
+Role-based IAM personas rather than per-person grants: Operations broadest because they operate and upgrade the platform and make network changes; DevOps domain teams scoped to their area, like CCOE with the OS/AMI pipeline; read-only for architects who need visibility but must not modify anything.
+
+**"How did you prove your staging environment held no production data?"**
+We gave the auditor the staging tenant names and walked them through the environment live, showing that only test data was in use — no customer data and no PII.
+
+**"What happens when a vulnerability can't be fixed in the current cycle?"**
+It doesn't disappear; it gets re-planned by severity and stays visible. After remediation we re-run the scan and diff it against the previous review, so anything still open is highlighted and carries into the next plan. A finding caused by an out-of-date Kubernetes version, for example, became a planned EKS upgrade in the following cycle.
+
+**"How did you trade off cost against recovery time?"**
+Two restore tiers: a cold cross-region backup as the default because it is cheap, and a warm option where snapshots are periodically restored into a live database in the secondary region — no full runtime, but a much shorter restore. Which one a customer gets is decided by their requirements and their RTO commitment, not by a blanket policy.
+
+**"How do you test a DR plan without hurting customers?"**
+Two different tests. A lightweight integrity test restores into an isolated environment in the same region as production and only measures the restore — zero customer impact. The full test is a real weekend cutover to the remote region, running for about a week before a load-tested failback. Both are measured against the published 6-hour RPO and 24-hour RTO.
+
+**"What is a Type II report and what does it mean for your day job?"**
+Type II is an opinion over an observation period, not a point-in-time snapshot — the auditor samples evidence from the whole window. That changes behaviour: evidence has to be produced contemporaneously at the moment the control runs, because it cannot be reconstructed later.
+
+**"How did you handle FedRAMP and GDPR residency requirements?"**
+As a personnel control, not just a technical boundary. For the US instance, only US citizens physically in the US could touch the data — engineers in China, India and Europe were excluded. For the EU environments, only European engineers had access. The quarterly review is where the "who" gets checked against the "where".
+
+**"What would you do differently?"** — go straight to §8. Answering this with specifics is usually the strongest part of the interview.
+
+---
+
+## 8. Gaps and what I would improve
+
+Saying these out loud is a credibility play — it shows you know where the control set is thin:
+
+- **Risk assessment is the weakest link.** A formal, dated annual risk assessment with a risk register — owner, treatment decision, and a traceable link from each risk to a control — would tighten the CC3 area far more than another access review.
+- **Access recertification is still manual and email-driven.** Tooling the campaign (automated attestation workflow with the owning managers) would remove the peer-manager round trips and shrink the review cycle.
+- **Processing capacity and multi-location strategy are documented far less rigorously than backup and DR**, even though availability depends on all of them.
+- **Confidential information classification** is implied by the staging-data rule but never written as a standalone classification policy — an easy win.
+- **Customer-exit data export was unsupported for CMS/HCMX/OO and PCS at the time.** That is a real gap in the exit promise and deserves a documented compensating process rather than an implicit "we'll handle it".
+
+---
+
+## 9. Vocabulary bank — English phrasing for this domain
+
+**Access control:** access recertification · quarterly access review · access revocation · least privilege · role-based IAM personas · read-only access · privileged access · federated identity / single sign-on · segregation of duties · leaver access · stale entitlement · escalation to the owning manager.
+
+**Source code control:** segregation from the source code repositories · no commit rights · authorisation list · repository owner · permission removal.
+
+**Vulnerability management:** vulnerability scan · severity-based triage · hardened AMI baseline · patch cadence · remediation plan · re-scan and diff against the previous review · risk acceptance · outstanding finding · compensating control.
+
+**Availability:** RPO (recovery point objective) · RTO (recovery time objective) · cold backup · warm standby · cross-region replication · failover and failback · DR integrity test · production cutover · load/pressure test · retention window.
+
+**Confidentiality and privacy:** data classification · non-production environment · synthetic test data · PII · data retention and disposal · decommissioning · customer exit · data export (OData) · entitlement · data controller · data residency.
+
+**Process integrity:** change record · CAB (change advisory board) · emergency change · planned maintenance window · service health portal · incident triage · impact analysis · cross-functional response.
+
+**Audit language:** Trust Services Criteria (TSC) · Type I vs Type II · observation period · control owner · evidence retention · management sign-off · sampling · subservice organisation (AWS) · user entity · service auditor.
+
+---
+
+## 10. Transcription corrections relative to the raw notes
+
+- "calibrate access write" / "cataloger" → **revoke access rights** (the remediation action in the access review and the GitLab check).
+- "Processor Integrity" → **Processing Integrity** (the fifth Trust Services Category).
+- "Recovery product objective" → **Recovery Point Objective (RPO)**; RPO **6 hours**, RTO **24 hours**.
+- "抵押的标准" → **the standard we committed to** in the SaaS Service Description, i.e. the published RPO/RTO.
+- "Prisma Defender" → written as **Prisma / Defender** here; confirm the exact product name you cite in an interview.
+- Indicative mapping to SOC 2 criteria (CC6.x access, CC7.x operations/vulnerability, CC8.1 change management, A1.2/A1.3 backup and recovery testing, C1.1/C1.2 confidentiality, P4.x privacy) is my own reading — verify against the actual audit report before quoting criteria numbers to an interviewer.