Cybersecurity Audit Specialist
Run a structured cybersecurity audit of an organization, prioritizing risks and producing an actionable remediation roadmap.
// prompt
Act as a **senior cybersecurity audit specialist** with deep experience in risk-based assessments, penetration testing, and regulatory compliance. Conduct a structured security audit for the scope below and deliver findings I can act on, not generic advice.
## Engagement Context
- **Organization Type:** {{organization_type}}
- **Industry / Sector:** {{industry_sector}}
- **Infrastructure in Scope:** {{infrastructure_scope}}
- **Compliance Frameworks:** {{compliance_frameworks}}
- **Top Security Concerns:** {{primary_security_concerns}}
- **Audit Depth:** {{audit_depth}}
## How to Proceed
1. **Clarify scope first.** Ask up to 5 targeted questions only if a gap would change your findings; otherwise state reasonable assumptions and continue.
2. **Map the attack surface.** Identify external, internal, cloud, and human entry points relevant to the scope above.
3. **Assess by domain.** Evaluate network and endpoint security, web/application security (reference OWASP Top 10), identity and access management, data protection, logging/monitoring, and incident response readiness.
4. **Test methodically.** For each domain, describe what to check, why it matters, and the likely real-world impact if exploited.
5. **Score the risk.** Rate every finding by Likelihood x Impact (Low / Medium / High / Critical) and explain the rating.
6. **Check compliance.** Flag concrete gaps against {{compliance_frameworks}} and map each to the requirement it affects.
## Deliverables
Produce:
- **Executive summary** — top risks in plain language for leadership.
- **Findings table** — columns: Finding | Domain | Risk Rating | Evidence/Indicator | Recommended Fix.
- **Remediation roadmap** — quick wins (under 30 days), mid-term, and strategic, with owners suggested.
- **Compliance gap analysis** — gaps and the control that closes each.
## Rules
- Be specific and prioritized; lead with the highest-risk items.
- Recommend controls and tooling generically — do **not** generate working exploit code or instructions to attack systems you do not own.
- Note any assumptions and what additional data would sharpen the assessment.
Fill in the variables
Example run
Generated by Claude Opus 5.5 on September 23, 2026
Inputs used
- Organization type
- Mid-sized fintech company, Series C funded, ~180 employees, headquartered in Austin, TX with a remote engineering team across the US and Canada
- Industry sector
- Financial services — digital consumer lending platform (personal installment loans and BNPL products)
- Infrastructure scope
- AWS multi-account setup (prod, staging, dev via AWS Organizations); customer-facing web app (React/Node.js) and mobile apps (iOS/Android) behind CloudFront + ALB; Kubernetes (EKS) hosting ~25 microservices; PostgreSQL (RDS) and Redis (ElastiCache); Kafka for event streaming; Okta for workforce SSO; Auth0 for customer identity; third-party integrations with Plaid (bank data), Stripe (payments), and a credit bureau API; internal admin tools accessed via corporate VPN (WireGuard); ~150 employee laptops (mix of macOS/Windows) enrolled in Jamf/Intune
- Compliance frameworks
- SOC 2 Type II (in progress, audit scheduled Q1 2027), PCI DSS v4.0 (SAQ D, due to card data touchpoints via Stripe), GLBA Safeguards Rule, and GDPR/CCPA for EU and California customer data
- Primary security concerns
- Recent phishing attempt against finance team (Aug 2026, no breach confirmed but credential reset triggered); concern over overly broad IAM roles in AWS prod account; uncertainty about whether Auth0-issued customer session tokens are properly invalidated on logout; lack of centralized logging/SIEM (currently just scattered CloudWatch logs); unclear incident response plan ownership after CISO departure in July 2026; third-party risk exposure from Plaid and credit bureau API integrations handling sensitive financial data
- Audit depth
- Comprehensive assessment — full architecture and configuration review plus authenticated control testing (no live exploitation), targeting a report ready for the Q1 2027 SOC 2 Type II audit and board risk committee review
Security Audit Report: Digital Consumer Lending Platform
Engagement: Comprehensive risk-based security assessment (architecture and configuration review plus authenticated control testing, no live exploitation) Prepared for: Executive leadership, Board Risk Committee, SOC 2 Type II readiness (Q1 2027) Report date: 23 September 2026 Classification: Confidential. Contains security-sensitive information.
Important framing: This report is built from the engagement brief. I have not seen your configurations, logs, or policies. Each finding is marked:
- Indicated: the brief directly signals the issue.
- Probable: the issue is common in this architecture and profile, and must be confirmed.
Every finding includes the evidence needed to confirm or close it. Ratings will change after fieldwork. Treat this as the audit baseline and working plan, not a final attestation.
0. Scope Assumptions and Open Questions
I proceeded on the assumptions below rather than blocking on questions. The questions that follow are the ones whose answers would change a rating or a compliance conclusion.
Assumptions
| # | Assumption | If wrong, what changes |
|---|---|---|
| A1 | SAQ D was self-selected. Stripe is likely integrated via Elements, Checkout, or mobile SDKs, but the company may call Stripe APIs server-side in some flows. | If no PAN ever touches your systems, you may qualify for SAQ A or A-EP. That would sharply reduce PCI scope (see F-06). |
| A2 | Nobody has been formally designated as the GLBA "Qualified Individual" since the CISO left in July 2026. | If someone was designated in writing, F-01 drops from Critical to High. |
| A3 | A CloudTrail organization trail may exist, but logs are not centralized, correlated, or reviewed. | If an org trail to a locked log-archive account exists, F-03 impact narrows to detection and response. |
| A4 | Workforce email is Google Workspace or Microsoft 365, federated to Okta. | Affects the phishing investigation steps and log retention windows. |
| A5 | The ~30-person gap between 180 employees and ~150 enrolled laptops represents contractors, BYOD, or unmanaged devices. | If all 180 people have managed devices, F-11 drops to Low. |
| A6 | Kafka is Amazon MSK; RDS and ElastiCache are in private subnets. | Self-managed Kafka on EC2 or EKS adds a patching and ACL surface. |
| A7 | The SOC 2 Type II observation window starts in Q4 2026 or has already started. | See the timing note in §1. It is the most time-sensitive governance issue. |
Clarifying questions (answers would change findings)
- Stripe integration pattern. Do raw card numbers ever transit your backend, logs, Kafka, or mobile app memory outside Stripe's SDK or iframe? This decides SAQ D versus SAQ A or A-EP and changes roughly 40% of the PCI workload.
- SOC 2 observation window. What are the exact start and end dates, and which Trust Services Criteria are in scope (Security only, or also Availability, Confidentiality, Privacy)?
- EU customers. Do you actually lend to EU residents, or is GDPR exposure limited to marketing, site visitors, or employees? Lending to EU residents triggers Art. 22 automated credit-decision obligations and possibly an EU representative (Art. 27).
- State licensing. Are you licensed in New York (NYDFS Part 500) or lending through a bank partner? Either adds binding cybersecurity obligations beyond GLBA.
- Phishing incident artifacts. For the August 2026 incident: which platform, which users, did the attacker obtain a valid session or MFA approval, and was an incident ticket created? This decides whether F-04 is Critical.
1. Executive Summary
Overall posture: Elevated risk. The architecture is modern, but governance and detection are not yet audit-ready.
The engineering foundation is sound: AWS Organizations, managed Kubernetes, SSO, and delegated payments and identity providers. The risk sits in the gaps between those tools. There is no accountable security owner, no reliable way to detect or reconstruct an intrusion, and privileged cloud access that is probably broader than the business needs. For a lender holding bank-account links, credit reports, and identity data on consumers, these gaps create regulatory exposure (FTC/GLBA, state attorneys general, PCI, EU regulators) as well as breach risk.
Top risks in plain language
- Nobody is formally accountable for security (Critical). The GLBA Safeguards Rule legally requires a named "Qualified Individual" who reports to the board in writing at least annually. Since July, that seat and the incident response plan have had no owner. In a breach, nobody has clear authority to coordinate, and regulator deadlines still apply: FTC notification within 30 days for events affecting 500+ consumers, and GDPR within 72 hours. SOC 2 auditors will cite this under CC1.
- We cannot reliably say whether we have been breached (Critical). Logs are scattered across CloudWatch with no central correlation or alerting. The August phishing attempt was closed as "no breach confirmed," but without centralized logs that conclusion cannot be defended to an auditor or regulator. Key identity and cloud logs from August age out around November 2026 if not exported. This is a deadline.
- Cloud admin access is probably too broad (Critical, pending validation). If one over-permissioned role or credential is compromised (a phished engineer, a leaked CI key, a vulnerable pod), an attacker may be able to read the entire production customer database, disable logging, or delete backups.
- Customers may stay logged in after they log out (High). If Auth0 tokens remain valid after logout, a stolen or shared-device session could be used to view loan data, change bank details, or redirect disbursements.
- Third-party integrations carry our most sensitive data (High). The credentials used to call Plaid and the credit bureau are effectively keys to customers' bank data and credit files. We need proof that they are vaulted, rotated, scoped, and monitored, and that we review each vendor's security.
SOC 2 timing warning
A Type II report tests whether controls operated consistently across the whole observation window, not only whether they exist on audit day. Any control put in place mid-window will show as an exception for the earlier months. Recommendations:
- Close governance, logging, and access-review gaps before the window starts.
- If the window has already started, consider resetting it (for example, a 3-month window of Jan–Mar 2027), or issuing a Type I report now as a bridge for customers and partners.
What leadership should approve this month
| Action | Why |
|---|---|
| Appoint an interim Qualified Individual (internal lead or fractional vCISO) in a written board resolution | Legal requirement; unblocks everything else |
| Fund centralized logging/SIEM | Regulatory necessity, not optional |
| Sponsor a 30-day IAM least-privilege sprint on the production AWS account | Largest single breach-risk reduction |
| Authorize a retroactive compromise assessment of the August phishing event | Must complete before logs expire |
2. Risk Rating Methodology
Rating = Likelihood × Impact
| Impact: Low | Impact: Medium | Impact: High | |
|---|---|---|---|
| Likelihood: High | Medium | High | Critical |
| Likelihood: Medium | Low | Medium | High |
| Likelihood: Low | Low | Low | Medium |
- Likelihood considers exposure (internet-facing or internal), attacker interest (fintech is heavily targeted), known precedents (the August phishing), and existing compensating controls.
- Impact considers consumer financial harm, regulatory exposure (GLBA/FTC, PCI, GDPR fines, state AG), direct fraud loss, and SOC 2 opinion risk.
- Regulatory certainty: where a gap is a near-certain audit exception regardless of attacker activity, likelihood is treated as High.
3. Attack Surface Map
External (internet-facing)
| Entry point | Key threats | Priority |
|---|---|---|
| React web app via CloudFront → ALB | Broken access control, injection, client-side script tampering on payment pages, credential stuffing | High |
| iOS/Android apps and their APIs | Broken object-level authorization (BOLA), insecure token storage, hardcoded keys, API abuse | High |
| Auth0 customer login | Credential stuffing, account takeover, session persistence after logout, MFA fatigue | High |
| Public API endpoints (loan application, repayment) | Business-logic abuse (rate/amount tampering, race conditions on disbursement), synthetic identity fraud | High |
| Webhook receivers (Stripe, Plaid) | Forged webhooks if signatures are not verified; replay | Medium-High |
| EKS API endpoint (if public) | Credential abuse; exposure of cluster control | Medium |
| DNS, email domain | Spoofing and BEC if DMARC is weak; subdomain takeover from dangling CloudFront/S3 records | Medium |
| Okta workforce login | Adversary-in-the-middle phishing, MFA push fatigue, session token theft | High (demonstrated in Aug 2026) |
| WireGuard VPN endpoint | Stolen peer keys, no MFA, stale peers from departed staff | High |
Internal and cloud
- AWS control plane: IAM roles and users, cross-account trust, CI/CD deploy roles, break-glass/root accounts.
- EKS: node instance roles, pod IAM (IRSA / Pod Identity), Kubernetes RBAC, secrets, east-west traffic between ~25 services.
- Data stores: RDS PostgreSQL (PII, loan and bank data), ElastiCache Redis (sessions, possibly tokens), Kafka topics (events that may carry PII or financial data), S3 (documents, KYC images, exports), snapshots and backups.
- Admin tools behind the VPN: often the weakest internal apps, with broad data access, weak authorization, and poor audit trails.
- Non-production: staging/dev containing production data copies; weaker controls with shared credentials.
Human and supply chain
- Finance team (BEC, payment redirection), engineers (cloud and code credentials), support staff (admin tools, social engineering by "customers").
- Offboarded staff, including the departed CISO's accounts, keys, and VPN peers.
- Third parties: Plaid, Stripe, the credit bureau, Okta, Auth0, CI/CD provider, open-source dependencies, container base images.
4. Domain Assessments and Test Procedures
Each domain lists what to check, why it matters, and the realistic impact. All testing is authenticated and read-only against systems you own. Suggested tooling is generic and defensive: CSPM (Prowler, ScoutSuite, AWS Security Hub), IAM Access Analyzer, kube-bench and kubescape, DAST/SAST, and dependency scanners.
4.1 Identity and Access Management: Cloud (AWS)
| Check | Why it matters | Impact if exploited |
|---|---|---|
Enumerate every principal in prod with *:*, AdministratorAccess, iam:*, iam:PassRole on *, or sts:AssumeRole on * |
These paths lead directly to full account takeover | Full prod compromise: read/export all customer data, destroy backups |
| Run IAM Access Analyzer "unused access" findings; compare granted versus used permissions over 90 days | Quantifies overprivilege objectively and becomes SOC 2 evidence | Shrinks blast radius |
| Long-lived IAM user access keys (age, last used, owner) | Leaked static keys are a top cloud breach vector | Persistent attacker access |
| Root account: hardware MFA, no access keys, usage alerts, per-account root management | Root bypasses most controls | Catastrophic |
| SCPs and Resource Control Policies: deny disabling CloudTrail/GuardDuty/Config, deny leaving the org, region restrictions, deny public RDS/S3 | Guardrails hold even when IAM is misconfigured | Prevents defense evasion |
| CI/CD deploy roles: OIDC federation (no static keys), trust policy scoped to repo, branch, and environment | CI is a favored lateral path | Supply-chain compromise leading to prod |
| Human access to prod: via IAM Identity Center + Okta, time-bound, just-in-time elevation, no standing admin | Standing admin plus phishing leads to breach | Account takeover |
| Cross-account trust between dev/staging and prod | A compromised dev account must not be able to reach prod | Pivot into prod |
| Departed CISO (July 2026): Okta, AWS, VPN peer, GitHub, SaaS admin, API keys all removed? | Common leftover access | Unauthorized persistent access |
4.2 Identity and Access Management: Workforce (Okta) and Phishing Resilience
| Check | Why | Impact |
|---|---|---|
| MFA factor types in use; whether phishing-resistant factors (FIDO2/WebAuthn, Okta FastPass with device binding) are enforced for finance, admins, and engineers | Push, SMS, and TOTP are defeated by adversary-in-the-middle phishing kits | Credential and session theft despite MFA |
| August incident: was the response only a password reset, or also session clearing, OAuth token revocation, and a MFA factor reset? | A password reset alone does not kill stolen session cookies or OAuth grants | Attacker keeps access after the "fix" |
| Mailbox forwarding and inbox rules, and OAuth app consents, for affected users (Aug 2026 to now) | Standard BEC persistence technique | Silent exfiltration, payment fraud |
| Okta admin roles (count and least privilege), ThreatInsight, new-device/geo-velocity policies, session lifetime | Okta admin equals the keys to every app | Tenant-wide takeover |
| Device trust in Okta sign-on policy (managed devices only for sensitive apps) | Blocks token use from attacker infrastructure | Reduces session replay |
DMARC p=reject, SPF, DKIM, lookalike-domain monitoring |
Spoofed internal and vendor emails drive BEC | Wire fraud |
| Finance payment-change procedure (out-of-band callback verification, dual approval) | Process control that stops BEC even when email is compromised | Direct monetary loss |
4.3 Customer Identity and Session Management (Auth0)
Why this concern is well founded: Auth0's logout endpoint ends the Auth0 session (SSO cookie). It does not invalidate JWT access tokens already issued, which stay valid until they expire. It also does not revoke refresh tokens unless you do so explicitly. Many implementations assume logout means tokens are dead. That is often not true.
| Check (authenticated, own test accounts) | Why | Impact |
|---|---|---|
| Log in, capture your test account's access token, log out, then send an authorized API request with the old token | Confirms whether APIs accept tokens after logout | Session hijack persists on shared or stolen devices |
| Access token lifetime (target 5–15 minutes for financial APIs) | Long lifetimes widen the replay window | Same as above |
| Refresh tokens: rotation enabled, reuse detection on, absolute and idle lifetimes set, revoked on logout (Auth0 revoke endpoint or Management API) | Refresh tokens are the long-lived credential | Indefinite account access |
| Mobile: tokens in iOS Keychain / Android Keystore (not AsyncStorage or SharedPreferences); biometric gating for high-risk actions | Device compromise or backup extraction | ATO via device |
Web: tokens not in localStorage (XSS-exposed); cookies HttpOnly, Secure, SameSite |
XSS leads to token theft | ATO |
| Password change, email change, or "log out all devices" revokes all sessions and refresh tokens server-side | Standard ATO recovery expectation | Attacker survives the customer's remediation |
| OIDC back-channel logout or a server-side session store / denylist for high-risk APIs | Enables real revocation | Closes the gap |
| Step-up authentication for bank-account change, disbursement destination change, payoff, and profile changes | These are the monetization points for ATO | Funds redirected to the attacker |
| Attack protection: breached-password detection, brute-force protection, bot detection on login and signup | Credential stuffing is constant against lenders | Mass ATO, fraudulent applications |
4.4 Web, Mobile, and API Security (OWASP Top 10 2021 / OWASP API Security Top 10 2023)
| OWASP category | Lending-specific checks | Impact |
|---|---|---|
| A01 Broken Access Control / API1 BOLA | Can user A view or change user B's loan, statement, bank link, or document by changing an ID? Test across ~25 microservices, including service-to-service calls that trust the gateway | Mass PII/financial data exposure. Top-ranked risk. |
| API3 Broken Object Property Level Auth / Mass assignment | Can a client set apr, loan_amount, status, approved, credit_limit, or kyc_verified? |
Fraudulent loan terms |
| API6 Unrestricted Access to Sensitive Business Flows | Race conditions on disbursement, BNPL limit checks, promo codes; rate limits on applications | Direct financial loss |
| A02 Cryptographic Failures | TLS 1.2+ everywhere including internal service mesh, Redis, and Kafka; PII field-level encryption; no sensitive data in URLs | Data exposure |
| A03 Injection | ORM/raw SQL review, NoSQL/Redis command construction, log injection | DB compromise |
| A04 Insecure Design | Threat models exist for disbursement, repayment, and bank-link flows? | Systemic logic flaws |
| A05 Security Misconfiguration | CloudFront/ALB headers (CSP, HSTS), verbose errors, debug endpoints, S3 origin access control, WAF rules | Recon, XSS |
| A06 Vulnerable Components | SCA on npm dependencies, mobile SDKs, base images; SBOM | RCE via dependency |
| A07 Identification & Auth Failures | See §4.3 | ATO |
| A08 Software & Data Integrity | CI/CD pipeline integrity, signed images, third-party scripts on payment pages (PCI 6.4.3), webhook signature verification (Stripe signing secret, Plaid webhook verification) | Supply-chain compromise, forged payment events |
| A09 Logging & Monitoring | See §4.7 | Undetected breach |
| A10 SSRF | Any service fetching user-supplied URLs (document upload by URL, webhooks) that could reach instance metadata | Cloud credential theft |
Mobile-specific checks: certificate pinning strategy, no hardcoded secrets in binaries, jailbreak/root and emulator signals feeding fraud scoring, deep-link hijacking, screenshot and backup exclusion for sensitive screens.
4.5 Kubernetes (EKS), Network, and Infrastructure
| Check | Why | Impact |
|---|---|---|
| IMDSv2 required with hop limit 1 on nodes; pods use IRSA or EKS Pod Identity rather than the node role | A compromised pod otherwise inherits node credentials | Pod escape leads to AWS compromise |
| EKS API endpoint private (or public with a tight CIDR allowlist); cluster access via access entries tied to Okta groups | Control-plane exposure | Cluster takeover |
Kubernetes RBAC: no cluster-admin for humans day-to-day; no wildcard ClusterRoles for service accounts |
Lateral movement | Full cluster compromise |
Pod Security Standards restricted / admission policy (no privileged pods, hostPath, or root) |
Container-escape vectors | Node compromise |
| NetworkPolicies default-deny between the ~25 services | Flat east-west network means one bug exposes everything | Lateral movement to payment and bureau services |
| Secrets: KMS envelope encryption; External Secrets / Secrets Manager rather than plaintext ConfigMaps | Secret sprawl | Credential theft |
| Image scanning in CI plus admission-time signature verification; runtime threat detection (e.g., GuardDuty EKS Runtime Monitoring) | Supply chain and runtime attacks | Undetected cryptominer or backdoor |
Security groups: RDS, Redis, and Kafka reachable only from specific workloads; nothing 0.0.0.0/0 except ALB 443 |
Exposure | Direct DB attack |
| Kafka: TLS, SASL/IAM auth, per-topic ACLs, no PII in topic payloads unless encrypted | Kafka is often a "trusted" internal bus with weak ACLs | Bulk data exfiltration |
| WireGuard VPN: key inventory versus current staff, no SSO or MFA at connect, full network access versus per-app | WireGuard is key-based only; a stolen laptop key equals network access with no MFA | Direct path to admin tools |
| Admin tools: authorization per role, audit trail of every customer record viewed or changed, bulk export controls | Insider threat and social-engineering path | Mass data exposure, fraud |
4.6 Endpoint Security
| Check | Why | Impact |
|---|---|---|
| Reconcile HR roster (180) against the Jamf/Intune inventory (~150) | Unmanaged devices accessing Okta, AWS, or GitHub | Malware or infostealer leads to session theft |
| EDR deployed and reporting on 100% of managed devices | Infostealers are the #1 source of stolen SaaS sessions | Credential and session theft |
| Full-disk encryption, OS patch SLAs, local admin removed, screen lock, firewall | Baseline hygiene; PCI/GLBA evidence | Data loss from lost or stolen laptops |
| Browser controls: extension allowlist, managed browser profiles | Malicious extensions steal session cookies | ATO of workforce SaaS |
| Okta device trust ties access to compliant, managed devices | Stops stolen credentials from being used on attacker machines | Contains phishing impact |
4.7 Logging, Monitoring, and Detection
| Check | Why | Impact |
|---|---|---|
| Organization CloudTrail (all regions, management + S3/Lambda data events for sensitive buckets) into a dedicated log-archive account with S3 Object Lock | Tamper-proof audit trail | Attacker erases tracks |
| GuardDuty (org-wide, incl. EKS, RDS, S3, Malware protection), Security Hub with CIS/AWS FSBP/PCI standards, AWS Config | Native detection baseline | Undetected compromise |
| VPC Flow Logs, EKS control plane audit logs, RDS/Postgres audit logs (pgaudit), ALB/CloudFront/WAF logs | Needed for investigations | Can't scope a breach |
| Okta System Log, Auth0 logs, Google/M365 audit logs, EDR, GitHub audit log streamed to SIEM | Identity is the new perimeter | Can't detect ATO or insider activity |
| Retention: 12 months minimum, 3 months hot (PCI 10.5.1); Okta retains only ~90 days natively | Regulatory and investigative | August 2026 evidence expires ~November |
| Detection use cases and on-call alert routing with documented triage | Logs no one reads are not a control (PCI 10.4.1.1 requires automated review) | Dwell time measured in months |
| Application audit logs for admin actions, bank-account changes, and disbursement changes | Fraud investigation and GLBA 314.4(c)(8) | Can't prove who did what |
4.8 Data Protection
| Check | Why | Impact |
|---|---|---|
| Data inventory and classification (SSN, DOB, bank account/routing, Plaid access tokens, credit reports, KYC images, card data) | GLBA 314.4(c)(2), GDPR Art. 30; can't protect what isn't mapped | Unknown exposure |
| RDS, ElastiCache, MSK, S3, EBS, and snapshot encryption with customer-managed KMS keys and restrictive key policies | Separation of duties over data access | Bulk data exposure |
| Field-level or application-level encryption (or tokenization) for SSN, bank account numbers, and Plaid access tokens | Limits the blast radius of SQL injection or DB credential theft | Most sensitive data exposed |
| Production data in staging/dev; PII in logs, Kafka, error trackers, analytics tools | Common silent leak path; PCI 12.10.7 for PAN | Data in weakly controlled environments |
| RDS snapshot sharing, public S3, cross-account backup copies | Misconfiguration leaks | Mass exposure |
| Retention and disposal (GLBA: dispose of customer info no later than 2 years after last use unless there is a business/legal need); GDPR/CCPA deletion workflows | Legal requirement; reduces breach impact | Over-retention liability |
| Backups: AWS Backup with vault lock in a separate account; tested restores | Ransomware and destructive-attacker resilience | Unrecoverable data loss |
4.9 Third-Party Risk (Plaid, Stripe, Credit Bureau, IdPs)
| Check | Why | Impact |
|---|---|---|
Plaid access_token storage: encrypted, access limited to one service, deleted on customer unlink or account closure |
These tokens grant ongoing access to customers' bank data | Mass bank-data exposure |
| Credit bureau API credentials: vaulted, rotated, IP-allowlisted/mTLS; permissible-purpose enforcement and logging (FCRA) | Bureau contracts require specific security controls; misuse leads to contract termination and FCRA liability | Loss of bureau access (business-critical) |
| Webhook verification for Stripe and Plaid; idempotency and replay protection | Forged "payment succeeded" or "account verified" events | Fraud |
| Current SOC 2 reports on file for Plaid, Stripe, the bureau, Okta, Auth0, and CI/CD; complementary user entity controls (CUECs) mapped to your own controls | SOC 2 CC9.2; GLBA 314.4(f); PCI 12.8 | Audit exception; blind reliance |
| Contracts: security requirements, breach notification SLAs, DPAs (GDPR Art. 28), right to audit, PCI responsibility matrix (Stripe) | Legal requirement | Regulatory gap |
| Scope of data sent to each vendor (minimization) | Least data shared, least exposure | Excess exposure |
4.10 Incident Response Readiness
| Check | Why | Impact |
|---|---|---|
| Written IR plan with a named owner, roles (IC, legal, comms, engineering), and severity matrix | GLBA 314.4(h), PCI 12.10.1, SOC 2 CC7.3–7.5 | Chaotic response, missed deadlines |
| Regulatory clock matrix: FTC 30 days (≥500 consumers), GDPR 72h, state breach laws, card brands/acquirer via Stripe, bureau contractual notice, cyber insurer | Multiple overlapping deadlines | Fines, contract breach |
| Retainers: IR firm, outside breach counsel, cyber insurance with panel vendors confirmed | Speed in the first 24 hours | Cost and severity escalate |
| Playbooks: workforce ATO, customer ATO wave, cloud credential leak, ransomware, vendor breach (e.g., Plaid incident) | Most likely scenarios | Improvised response |
| Tabletop in the last 12 months, including executives | SOC 2 and PCI 12.10.2 evidence | Untested plan |
| Was the August phishing event handled as a documented incident (ticket, timeline, root cause, lessons learned)? | Auditors will ask for this | SOC 2 CC7.4 exception |
5. Findings Table (prioritized)
Status legend: [I] Indicated by the brief; [P] Probable, requires validation.
| ID | Finding | Domain | Risk Rating | Evidence / Indicator | Recommended Fix |
|---|---|---|---|---|---|
| F-01 | No designated GLBA Qualified Individual; incident response plan has no owner since CISO departure (Jul 2026) [I] | Governance / IR | Critical (L: High, certain audit/regulatory gap; I: High, uncoordinated breach response and missed notification deadlines) | Brief states IR ownership unclear. Validate: board minutes, written designation, IR plan version history, last annual board report | Board resolution appointing an interim Qualified Individual (internal senior engineer/CTO with vCISO support, or fractional vCISO) within 14 days; assign IR plan owner and deputy; begin CISO search; schedule the annual written board report |
| F-02 | No centralized logging/SIEM; detection relies on ad hoc CloudWatch review [I] | Logging / Monitoring | Critical (L: High; I: High, breaches go undetected and cannot be scoped) | Brief states scattered CloudWatch logs. Validate: org trail config, GuardDuty/Security Hub status, Okta/Auth0 log streaming, retention settings | Org CloudTrail to an Object Lock log-archive account; GuardDuty + Security Hub org-wide; SIEM or security data lake ingesting AWS, EKS, Okta, Auth0, email, EDR, GitHub; 12-month retention; 15–20 priority detections with on-call routing |
| F-03 | August phishing incident closure unverifiable; response may not have revoked sessions or OAuth grants; evidence at risk of expiring [I] | IAM / IR | Critical pending Q5 (L: Medium-High, AiTM kits routinely steal sessions; I: High, finance team access means payment fraud or data theft) | "No breach confirmed" plus "credential reset triggered" plus no SIEM. Validate: Okta System Log for affected users, session and token revocation records, mailbox rules, OAuth consents, payment-change records | Immediately export Okta, email, and CloudTrail logs for Jul–Sep 2026; conduct a documented retroactive compromise assessment; clear all sessions and revoke tokens for affected users; write a formal incident record with root cause |
| F-04 | Overly broad IAM permissions in AWS prod; probable standing admin, wildcard policies, long-lived keys [I] | IAM (Cloud) | Critical (L: High, overprivilege plus phishing plus CI exposure; I: High, full prod data and backup compromise) | Brief concern. Validate: Access Analyzer unused access, IAM credential report, policy review for * actions/resources, SCP inventory |
Remove standing admin; IAM Identity Center with Okta groups and just-in-time elevation; right-size roles from 90-day usage data; eliminate IAM user keys; SCP/RCP guardrails; permission boundaries for CI roles; quarterly access review |
| F-05 | Workforce MFA is likely not phishing-resistant, especially for finance and admins [P] | IAM (Workforce) | High (L: High, already targeted; I: Medium-High) | The Aug phishing attempt reached a credential reset stage. Validate: Okta authenticator enrollment report and policies | Enforce FIDO2/WebAuthn or FastPass with device binding for finance, IT, engineering, and admins (all staff by Q1); Okta device trust; ThreatInsight; shorter admin session lifetimes |
| F-06 | PCI scope likely misclassified or over-broad (SAQ D with Stripe); cardholder data environment (CDE) boundary undefined [P] | Data Protection / Compliance | High (L: Medium; I: High, PCI noncompliance, card brand fines, or wasted effort) | SAQ D is unusual when a Stripe tokenized integration is used. Validate: data-flow diagrams, code paths calling Stripe, PAN discovery scan across DBs, logs, Kafka, S3 | Confirm the integration pattern; run a PAN discovery scan; if PAN never touches your systems, re-platform all flows to Stripe Elements/Checkout/mobile SDK and requalify as SAQ A or A-EP; otherwise define and segment the CDE and get a Stripe responsibility matrix |
| F-07 | Auth0 customer tokens may remain valid after logout; refresh token revocation unverified [I] | App / Customer IAM | High (L: Medium; I: High, ATO leading to data exposure and disbursement redirection) | Brief concern plus a known Auth0 behavior (stateless JWTs). Validate: authenticated logout-replay test on own test accounts; tenant token settings | Access token TTL ≤15 min; refresh token rotation plus reuse detection; revoke refresh tokens on logout and password/email change; back-channel logout or server-side session denylist; step-up auth for bank-account and disbursement changes |
| F-08 | Third-party integration secrets and oversight (Plaid access tokens, bureau credentials, webhook verification, vendor SOC 2 review) not evidenced [I] | Third-Party / Data | High (L: Medium; I: High, bank and credit data exposure, bureau contract breach) | Brief concern. Validate: secret storage locations, rotation logs, webhook handler code, vendor file (SOC 2, DPAs, contracts) | Store in Secrets Manager with per-service IAM; field-level encryption for Plaid tokens; rotation schedule; verify webhook signatures and enforce idempotency; vendor risk register with annual SOC 2 review and CUEC mapping |
| F-09 | WireGuard VPN gives network-level access to admin tools with static keys and no per-session MFA; stale peers likely [P] | Network / IAM | High (L: Medium; I: High, direct path to customer data via admin tools) | WireGuard has no native SSO/MFA. Validate: peer list versus active staff, AllowedIPs scope, admin tool authentication | Short term: rotate all keys, remove stale peers (incl. departed CISO), restrict AllowedIPs per role. Mid term: replace with an Okta-integrated identity-aware proxy / ZTNA with per-app access and device posture |
| F-10 | Internal admin tools likely lack granular authorization, bulk-export controls, and immutable audit logs [P] | App / Data | High (L: Medium; I: High, insider and social-engineering data exfiltration or fraud) | Typical for internal tooling at this stage. Validate: RBAC model, audit logs, export functions | Role-based, least-privilege views with SSN/bank data masked by default; reason codes for sensitive lookups; immutable audit logs to SIEM; alerts on bulk access |
| F-11 | Possible BOLA / IDOR and business-logic flaws across ~25 microservices (loan, statement, bank-link, disbursement endpoints) [P] | App (OWASP A01/API1/API6) | High (L: Medium, the most common API flaw; I: High) | Microservice sprawl with implicit gateway trust. Validate: authenticated API testing with two test accounts; code review of authorization middleware | Centralize object-level authorization (policy library or engine); enforce authorization in each service rather than only at the gateway; add authorization unit tests; engage a third-party app pen test before the audit window |
| F-12 | EKS hardening gaps: pods may reach the node IAM role via IMDS, flat pod network, RBAC and Pod Security not enforced [P] | Cloud / K8s | High (L: Medium; I: High, one vulnerable service leads to AWS and data compromise) | Common EKS defaults. Validate: kube-bench, kubescape, launch template IMDS settings, NetworkPolicy inventory | IMDSv2 with hop limit 1; IRSA/Pod Identity per service; default-deny NetworkPolicies; Pod Security restricted; private API endpoint; KMS secrets encryption; runtime detection |
| F-13 | Sensitive data probably sprawls into non-prod, logs, Kafka topics, and analytics tools; no data inventory [P] | Data Protection | High (L: Medium-High; I: Medium-High) | No central data governance function indicated. Validate: DLP/discovery scan across S3, RDS (staging), log groups, topics | Data inventory and classification; synthetic or masked data in non-prod; log redaction middleware; Kafka payload encryption for PII topics; retention and disposal schedule |
| F-14 | Customer account-takeover and fraud controls (credential stuffing, bot, breached-password detection) unverified [P] | App / Customer IAM | High (L: High, lenders are constant targets; I: Medium-High) | Not mentioned in brief. Validate: Auth0 Attack Protection settings, WAF bot rules, login failure metrics | Enable Auth0 breached-password detection, brute-force and bot protection; WAF rate limiting and bot control; risk-based step-up; alert on login anomaly spikes |
| F-15 | Endpoint coverage gap (~150 managed devices versus ~180 staff); EDR coverage unverified [I] | Endpoint | Medium-High (L: Medium; I: Medium-High, infostealers lead to session theft) | Headcount/device delta in brief. Validate: HR, MDM, and EDR reconciliation; Okta device-trust logs | Enroll or replace unmanaged devices; require managed device for Okta access to sensitive apps; EDR on 100%; VDI/browser-isolation for contractors |
| F-16 | Email authentication and BEC process controls unverified (DMARC, payment-change verification) [P] | Human / Email | Medium-High (L: High, finance already targeted; I: Medium, financial loss) | Aug phishing against finance. Validate: DNS records, finance SOPs | DMARC p=reject on all domains incl. parked domains; external sender banners; mandatory callback verification plus dual approval for vendor bank changes and wires |
| F-17 | Offboarding of departed CISO and other leavers not verified across all systems [P] | IAM | Medium-High (L: Medium; I: High, privileged residual access) | CISO departure July 2026. Validate: access audit across Okta, AWS, GitHub, VPN, SaaS admin consoles, shared secrets known to the leaver | Complete leaver audit; rotate secrets the CISO knew (break-glass, root, vendor admin); automated SCIM deprovisioning; offboarding checklist as a SOC 2 control |
| F-18 | Vulnerability management and pen testing cadence not evidenced (GLBA biannual scans + annual pen test; PCI 11.3/11.4) [P] | Vuln Mgmt | Medium (L: Medium; I: Medium, certain audit exception if absent) | No mention in brief. Validate: scan reports, pen test reports, remediation SLAs | Continuous cloud, container, and dependency scanning with SLAs (critical 15 days, high 30); ASV scans if in PCI scope; annual external pen test (app, API, cloud, mobile) |
| F-19 | Backup immutability and restore testing not evidenced [P] | Resilience | Medium (L: Low-Medium; I: High) | Validate: AWS Backup config, vault lock, cross-account copy, restore test records | AWS Backup with vault lock in an isolated account; quarterly restore tests; documented RTO/RPO |
| F-20 | Privacy program gaps: records of processing, DPIA for automated credit decisions, DSAR workflow, vendor DPAs [P] | Privacy / Compliance | Medium (High if EU lending is confirmed) | GDPR/CCPA in scope. Validate: RoPA, DPIAs, privacy notices, DSAR logs | Build RoPA; DPIA for credit decisioning (Art. 22 safeguards: human review, explanation); DSAR tooling; DPAs with all processors; confirm GLBA–CCPA interplay with counsel |
| F-21 | Payment-page script integrity controls absent or unverified (PCI 6.4.3 / 11.6.1, or SAQ A eligibility criteria) [P] | App / PCI | Medium (High if SAQ D or A-EP applies) | React SPA plus third-party scripts. Validate: script inventory on pages rendering Stripe components; CSP | Script inventory with authorization and justification; strict CSP with SRI where feasible; change and tamper detection on payment pages |
| F-22 | CI/CD and software supply chain controls unverified (branch protection, secrets in CI, OIDC to AWS, image signing) [P] | SDLC | Medium (L: Low-Medium; I: High) | Remote engineering team, ~25 services. Validate: repo settings, CI secrets inventory, deploy role trust policies | Branch protection and mandatory review; OIDC-only cloud auth from CI; secret scanning; signed images with admission verification; SBOMs |
6. Remediation Roadmap
Suggested owners are role-based. With no CISO, the interim Qualified Individual (QI) coordinates everything.
Phase 1: Quick Wins (0–30 days, by ~23 Oct 2026)
| # | Action | Closes | Suggested owner | Effort |
|---|---|---|---|---|
| 1 | Board resolution appointing interim QI; name IR plan owner and deputy; engage a vCISO if internal capacity is lacking | F-01 | CEO + Board Risk Committee | Low |
| 2 | Export and preserve Okta, email, and CloudTrail logs for Jul–Sep 2026 now (before 90-day expiry) | F-03, F-02 | Interim QI + IT lead | Low |
| 3 | Retroactive compromise assessment of the August phishing event (sessions, OAuth grants, mailbox rules, payment changes, AWS activity) with a documented incident record | F-03 | Interim QI + external IR firm (retainer) | Medium |
| 4 | Enable GuardDuty, Security Hub, and AWS Config org-wide; confirm the org CloudTrail goes to a log-archive account with Object Lock | F-02 | Cloud/Platform lead | Low |
| 5 | Remove standing AdministratorAccess from humans in prod; deactivate unused IAM keys; confirm root MFA; add SCPs denying CloudTrail/GuardDuty disablement | F-04 | Cloud/Platform lead | Medium |
| 6 | Enforce phishing-resistant MFA for finance, IT admins, Okta admins, and AWS prod access; enable ThreatInsight | F-05 | IT lead | Low-Medium |
| 7 | Leaver audit: departed CISO and all 2026 leavers across Okta, AWS, GitHub, VPN, SaaS; rotate break-glass and shared secrets | F-17 | IT lead + Cloud lead | Low |
| 8 | Rotate all WireGuard keys; remove stale peers; restrict AllowedIPs by role | F-09 | IT / Network owner | Low |
| 9 | Run the Auth0 logout-replay test; set access token TTL ≤15 min; enable refresh token rotation and reuse detection; revoke on logout | F-07 | Identity/Auth engineering lead | Low-Medium |
| 10 | Enable Auth0 breached-password, brute-force, and bot protection | F-14 | Identity/Auth engineering lead | Low |
| 11 | DMARC to p=reject; implement a finance callback/dual-approval SOP for bank-detail changes |
F-16 | IT lead + CFO | Low |
| 12 | Confirm the Stripe integration pattern and run a PAN discovery scan; decide on SAQ type | F-06 | VP Engineering + Compliance lead | Low-Medium |
| 13 | Sign IR retainer and outside breach counsel; confirm cyber insurance panel requirements | F-01 | CFO + General Counsel | Low |
| 14 | Confirm the SOC 2 observation window and decide whether to reset it or issue a Type I bridge | All | Compliance lead + auditor | Low |
Phase 2: Mid-Term (30–90 days, by ~end of Dec 2026, ahead of the SOC 2 window)
| # | Action | Closes | Suggested owner |
|---|---|---|---|
| 15 | Deploy SIEM or security data lake ingesting AWS, EKS, Okta, Auth0, email, EDR, and GitHub; 12-month retention; 15–20 priority detections; documented triage and on-call | F-02 | Interim QI + Platform lead (or MDR provider) |
| 16 | IAM least-privilege program: Identity Center + Okta groups, just-in-time elevation, Access Analyzer-driven rightsizing, permission boundaries for CI, quarterly access reviews (SOC 2 evidence) | F-04, F-22 | Cloud/Platform lead |
| 17 | EKS hardening: IMDSv2 hop limit 1, Pod Identity/IRSA per service, default-deny NetworkPolicies, Pod Security restricted, private endpoint, runtime detection |
F-12 | Platform/SRE lead |
| 18 | Rewrite, approve, and tabletop the IR plan with executives; include a regulatory-clock matrix and playbooks (workforce ATO, customer ATO, cloud key leak, ransomware, vendor breach) | F-01 | Interim QI + General Counsel |
| 19 | Third-party risk program: vendor inventory and tiering, SOC 2 report review with CUEC mapping, DPAs, PCI responsibility matrix with Stripe, bureau contract security obligations | F-08 | Compliance lead + Legal |
| 20 | Secrets hardening: Plaid tokens and bureau credentials in Secrets Manager with field-level encryption; rotation; webhook signature verification audit | F-08 | Backend/Payments engineering lead |
| 21 | Third-party pen test: web, API (BOLA focus), mobile, and cloud config; remediate criticals and highs before the window | F-11, F-18 | Interim QI + VP Engineering |
| 22 | Step-up authentication for bank-account changes, disbursement destination changes, and payoff | F-07, F-14 | Product + Identity engineering |
| 23 | Endpoint reconciliation: all devices enrolled, EDR at 100%, Okta device trust enforced for sensitive apps | F-15 | IT lead |
| 24 | Admin tool hardening: RBAC, data masking, audit logs to SIEM, bulk-export alerts | F-10 | Internal tools lead |
| 25 | Vulnerability management SLAs, scanning cadence, and (if in PCI scope) quarterly ASV scans | F-18 | Platform lead |
| 26 | Immutable backups (vault lock, isolated account) and first documented restore test | F-19 | Platform/SRE lead |
| 27 | Written GLBA risk assessment (314.4(b)) and first QI report to the board | F-01 | Interim QI |
Phase 3: Strategic (3–12 months)
| # | Action | Closes | Suggested owner |
|---|---|---|---|
| 28 | Hire a permanent CISO (or Head of Security) reporting to the CEO, with a board reporting line | F-01 | CEO + Board |
| 29 | Replace WireGuard with ZTNA / identity-aware proxy (Okta-integrated, per-app, device posture) | F-09 | IT + Platform |
| 30 | Data governance program: inventory, classification, masked non-prod data, log redaction, retention and disposal automation | F-13, F-20 | Data engineering lead + Privacy lead |
| 31 | Centralized authorization service or policy engine across microservices; threat modeling in SDLC for money-movement flows | F-11 | VP Engineering / Principal architect |
| 32 | Supply-chain security: signed images with admission enforcement, SBOMs, OIDC-only CI, secret scanning | F-22 | Platform lead |
| 33 | Privacy program maturity: RoPA, DPIAs (credit decisioning), DSAR automation; assess CCPA cybersecurity-audit and risk-assessment regulations with counsel | F-20 | Privacy lead + General Counsel |
| 34 | PCI scope reduction to SAQ A (if feasible) with payment page script integrity controls | F-06, F-21 | Payments engineering lead |
| 35 | Phishing-resistant MFA for all workforce users; passkeys offered to customers | F-05, F-14 | IT + Identity engineering |
| 36 | Security metrics program for the board: MTTD/MTTR, access review completion, vuln SLA adherence, phishing-resistant MFA coverage | Governance | CISO |
7. Compliance Gap Analysis
7.1 GLBA Safeguards Rule (16 CFR Part 314)
| Requirement | Gap | Closing control | Findings |
|---|---|---|---|
| 314.4(a): Designate a Qualified Individual | Seat vacant since July 2026 | Written board designation of interim QI; permanent CISO hire | F-01 |
| 314.4(b): Written risk assessment | Likely outdated or owned by the departed CISO | Refreshed written risk assessment covering all systems and vendors | F-01 |
| 314.4(c)(1): Access controls / least privilege | Broad prod IAM; VPN full-network access | IAM least-privilege program; ZTNA | F-04, F-09 |
| 314.4(c)(2): Data and systems inventory | No data inventory evident | Data inventory and classification | F-13 |
| 314.4(c)(3): Encryption in transit and at rest | Unverified for Redis, Kafka, field-level SSN/bank data | Encryption baseline plus field-level encryption | F-13, F-08 |
| 314.4(c)(5): MFA for anyone accessing information systems | WireGuard lacks MFA; MFA not phishing-resistant | Phishing-resistant MFA; ZTNA with MFA | F-05, F-09 |
| 314.4(c)(6): Secure disposal (≤2 years after last use unless needed) | No retention schedule evident | Retention and disposal schedule plus automation | F-13 |
| 314.4(c)(8): Monitor and log authorized user activity | No centralized logging | SIEM with user-activity monitoring; admin tool audit logs | F-02, F-10 |
| 314.4(d)(2): Continuous monitoring, or annual pen test plus vulnerability assessment every 6 months | Not evidenced | Scanning cadence plus annual pen test | F-18 |
| 314.4(e): Security awareness training | Phishing success suggests gaps | Role-based training (finance/BEC) plus phishing simulations | F-05, F-16 |
| 314.4(f): Service provider oversight | Vendor reviews not evidenced | Third-party risk program | F-08 |
| 314.4(h): Written incident response plan | No owner; untested | Approved IR plan plus tabletop | F-01 |
| 314.4(i): QI reports in writing to the board at least annually | No QI means no report | QI board report (target Q4 2026) | F-01 |
| 314.4(j): Notify FTC within 30 days of discovering a notification event involving ≥500 consumers | No regulatory-clock process; weak detection | IR regulatory matrix plus SIEM | F-01, F-02 |
7.2 PCI DSS v4.0.1 (assessed as SAQ D pending scope confirmation)
Note: v4.0 was retired at the end of 2024. v4.0.1 is the current standard, and the formerly future-dated requirements have been mandatory since 31 March 2025.
| Requirement | Gap | Closing control | Findings |
|---|---|---|---|
| 12.5.2: Scope documented and confirmed annually | CDE boundary undefined; SAQ type uncertain | Data-flow diagrams, PAN discovery, scope confirmation | F-06 |
| 1.x / 11.4.5: Network security controls and segmentation testing | Flat EKS network; segmentation untested | NetworkPolicies, security groups, segmentation testing | F-12 |
| 3.x / 12.10.7: Protect stored account data; respond to PAN found in unexpected places | Unknown whether PAN exists in logs, Kafka, or DB | PAN discovery scan plus log redaction | F-06, F-13 |
| 5.4.1: Anti-phishing mechanisms | Phishing reached credential stage | DMARC, email security, phishing-resistant MFA | F-05, F-16 |
| 6.4.3 / 11.6.1: Payment page script management and tamper detection (or SAQ A eligibility criteria) | Unverified | Script inventory, CSP, tamper detection | F-21 |
| 7.2.x: Least privilege; periodic access reviews (7.2.4, every 6 months) | Broad IAM; reviews not evidenced | IAM program with documented reviews | F-04 |
| 8.4.2 / 8.4.3: MFA for all CDE access and remote network access | WireGuard lacks MFA | ZTNA/MFA on remote access | F-09 |
| 8.2.6 / 8.6.x: Inactive accounts; system/application account management | Leavers and static keys unverified | Leaver audit; key rotation; secrets management | F-17, F-08 |
| 10.2 / 10.4.1.1 / 10.5.1: Audit logs, automated review, 12-month retention | No centralized logging or automated review | SIEM with 12-month retention and automated alerting | F-02 |
| 10.7.2: Detect failures of critical security controls | No monitoring of logging/security tool health | SIEM health alerts; Config rules | F-02 |
| 11.3.1 / 11.3.2 / 11.4.1: Internal and ASV scans, annual pen test | Not evidenced | Vuln management program plus pen test | F-18 |
| 12.3.1: Targeted risk analyses | Not evidenced | TRA documentation for flexible-frequency requirements | F-01 |
| 12.4.1: Executive responsibility for PCI compliance | Unclear after CISO departure | Named executive owner | F-01 |
| 12.8.x: Third-party service provider management | Stripe responsibility matrix and vendor monitoring not evidenced | TPSP inventory, responsibility matrix, annual review | F-08 |
| 12.10.1 / 12.10.2: IR plan in place and tested annually | No owner; untested | IR plan plus tabletop | F-01 |
7.3 SOC 2 Type II (Trust Services Criteria: Security / Common Criteria)
| Criterion | Gap | Closing control | Findings |
|---|---|---|---|
| CC1.3 / CC1.4: Structure, authority, responsibility; competence | No security leader | Interim QI, then CISO; documented security org chart | F-01 |
| CC2.2 / CC2.3: Internal and external communication of security matters | No board reporting since July | Quarterly board risk updates | F-01 |
| CC3.1–CC3.4: Risk assessment, including fraud risk | Risk assessment likely stale; BEC and fraud risk not formalized | Annual risk assessment including fraud scenarios | F-01, F-16 |
| CC4.1: Monitoring activities | No continuous control monitoring | Security Hub/Config plus control monitoring cadence | F-02 |
| CC6.1: Logical access (least privilege, encryption) | Broad IAM; token handling | IAM program; encryption baseline | F-04, F-13 |
| CC6.2 / CC6.3: Provisioning, deprovisioning, periodic access review | Leaver verification; review evidence | SCIM deprovisioning; quarterly reviews with evidence | F-17, F-04 |
| CC6.6: Protection against external threats | VPN without MFA; ATO controls | ZTNA; Auth0 attack protection; WAF | F-09, F-14 |
| CC6.7: Restrict data transmission and movement | PII sprawl to non-prod and logs | Data governance; DLP | F-13 |
| CC6.8: Prevent or detect malicious software | EDR coverage gap | 100% EDR plus device trust | F-15 |
| CC7.1: Vulnerability and configuration monitoring | Scanning cadence not evidenced | Vuln management program | F-18, F-12 |
| CC7.2: Monitor for anomalies | No SIEM | SIEM plus detections | F-02 |
| CC7.3–CC7.5: Evaluate, respond to, and recover from incidents | Aug incident may lack documentation; IR plan unowned | Incident record for August; IR plan plus tabletop | F-01, F-03 |
| CC8.1: Change management | CI/CD controls unverified | Branch protection, review, deploy approvals | F-22 |
| CC9.1: Business disruption risk mitigation | Backup/restore unverified | Immutable backups plus restore tests | F-19 |
| CC9.2: Vendor and business partner risk | Vendor program not evidenced | Third-party risk program with CUEC mapping | F-08 |
7.4 GDPR (if EU residents are customers or data subjects)
| Article | Gap | Closing control | Findings |
|---|---|---|---|
| Art. 5(1)(e) / 17: Storage limitation; erasure | No retention schedule; deletion workflow unverified | Retention schedule; DSAR/erasure workflow | F-13, F-20 |
| Art. 22: Automated decision-making (credit decisioning) | Safeguards not evidenced | Human review path, explanation, contest mechanism | F-20 |
| Art. 28: Processor contracts | DPAs with Plaid, Stripe, Auth0, Okta, etc. not evidenced | DPAs executed and tracked | F-08 |
| Art. 30: Records of processing | Not evidenced | RoPA | F-20 |
| Art. 32: Security of processing | Logging, IAM, and encryption gaps | Controls in this roadmap | F-02, F-04, F-13 |
| Art. 33 / 34: 72-hour breach notification | No IR owner or regulatory clock | IR regulatory matrix | F-01 |
| Art. 35: DPIA for high-risk processing (credit scoring, financial profiling) | Not evidenced | DPIAs for credit decisioning and bank-data processing | F-20 |
| Art. 44–49: International transfers | US hosting of EU data; transfer mechanism unverified | EU-US Data Privacy Framework reliance or SCCs plus a transfer impact assessment | F-20 |
7.5 CCPA/CPRA
| Requirement | Gap | Closing control | Findings |
|---|---|---|---|
| GLBA exemption scope (Cal. Civ. Code 1798.145) | Data covered by GLBA is largely exempt, but the exemption is data-level, not entity-level. Marketing, website, and employee data remain in scope. | Map which data falls under GLBA versus CCPA with counsel | F-20 |
| 1798.150: Private right of action for breaches from failure to maintain reasonable security | Applies even to GLBA-covered data. This is the main CCPA litigation exposure. | Reasonable security program (this roadmap) | F-02, F-04, F-13 |
| Consumer rights (access, deletion, correction, opt-out) for non-GLBA data | Workflow unverified | DSAR tooling | F-20 |
| CPPA cybersecurity audit and risk assessment regulations | Obligations phase in based on revenue thresholds | Assess applicability and timeline with counsel | F-20 |
7.6 Other obligations to confirm (outside stated scope)
- FCRA: permissible-purpose controls and credit bureau contractual security requirements. Bureaus audit these, and failure can cut off bureau access.
- NYDFS Part 500: applies if licensed in New York. It has stricter CISO, MFA, and 72-hour notification requirements.
- Bank partner requirements: if lending through a sponsor bank, their third-party risk management exams impose controls on you.
- Canadian privacy law (PIPEDA / provincial): applies at least to Canadian-resident employee data.
8. Evidence Request List (to confirm and finalize ratings)
| Area | Evidence needed |
|---|---|
| Governance | Board minutes since July 2026; any QI designation; current IR plan; last risk assessment; org chart |
| AWS | IAM credential report per account; Access Analyzer findings; SCP/RCP export; CloudTrail/GuardDuty/Security Hub/Config status; Prowler or Security Hub benchmark report |
| EKS | kube-bench / kubescape output; launch template IMDS settings; NetworkPolicies; RBAC bindings; admission policies |
| Identity | Okta authenticator enrollment and policy export; admin role list; Auth0 tenant settings (token lifetimes, rotation, attack protection); logout implementation code |
| Phishing incident | Okta System Log export for affected users; email audit logs; ticket/timeline; mailbox rule and OAuth consent review |
| Data | Data-flow diagrams (including Stripe/Plaid/bureau); PAN and PII discovery results; encryption configs; retention policy |
| Third parties | Vendor inventory; SOC 2 reports and CUEC mappings; contracts and DPAs; Stripe PCI responsibility matrix; bureau security addendum |
| Endpoint | MDM and EDR inventory versus HR roster; compliance policies |
| Network | WireGuard peer list and AllowedIPs; admin tool architecture and authentication |
| SDLC | Repo protection settings; CI secrets inventory; latest pen test and scan reports |
Once this evidence is available, I can:
- convert indicated and probable findings into confirmed findings with final ratings,
- produce a board-ready slide summary, and
- build a SOC 2 control matrix (control ID, owner, frequency, evidence artifact) mapped to the roadmap.
Related prompts
IT & Administration
Cloud Infrastructure Architect
Design a scalable, secure, cost-optimized cloud architecture with IaC, diagrams, and a phased rollout plan.
IT & Administration
DevOps Automation Specialist
Acts as a DevOps engineer to design, optimize, and troubleshoot CI/CD pipelines, infrastructure as code, and cloud automation.
IT & Administration
Docker Container Builder
Generates production-ready, optimized Dockerfiles with multi-stage builds, caching, and tagging for any application.
IT & Administration
Ansible Automation Playbook Creator
Generates production-ready, idempotent Ansible playbooks and roles for any infrastructure automation or configuration task.