AI Governance & Responsible AI — Operational Governance
Difficulty: Advanced. Regulation: General.
Key Points for AI Governance & Responsible AI
- AI governance is an engineering discipline, not a policy exercise. If your governance framework doesn't integrate into CI/CD, it's theater.
- The EU AI Act classifies AI systems by risk level, with documentation, testing, and human oversight requirements proportional to that risk
- Bias testing must be part of your model evaluation pipeline and must run before every deployment, not once a quarter by a separate team
- Explainability requirements vary by use case. A fraud detection system needs detailed reasoning, a playlist recommender does not.
- Maintain a model risk register that tracks every AI system in production, its risk classification, its data sources, and its last evaluation date
Common Mistakes with AI Governance & Responsible AI
- Treating responsible AI as a checkbox exercise handled entirely by the policy or legal team, with no engineering integration
- Deploying models to production without running bias testing across demographic groups and protected categories
- Assuming open-source models don't need governance because someone else built them. You deploy it, you own the risk.
- Not maintaining a centralized inventory of AI systems in production, making it impossible to respond to regulatory requests
Related to AI Governance & Responsible AI
Privacy by Design, Audit Logging Architecture
Audit Logging Architecture — Operational Governance
Difficulty: Intermediate. Regulation: General.
Key Points for Audit Logging Architecture
- Audit logs answer who did what, to which resource, when, and from where — every entry must include actor, action, target, timestamp, and source IP
- Immutability is non-negotiable: audit logs must be append-only and tamper-evident to satisfy regulatory requirements
- Separate audit logs from operational logs — they serve different audiences (auditors vs. engineers) and have different retention requirements
- Structured logging with consistent schemas enables efficient querying across millions of events
- Retention periods vary by regulation: SOC 2 requires 1 year, PCI DSS requires 1 year, HIPAA requires 6 years, GDPR has no fixed minimum but expects proportionality
Common Mistakes with Audit Logging Architecture
- Mixing audit logs with application debug logs in the same stream, making audit queries slow and unreliable
- Logging sensitive data (passwords, tokens, PII) in audit entries — audit logs themselves become a compliance liability
- Using mutable storage for audit logs where entries can be modified or deleted by administrators
- Not testing audit log completeness — running an audit and discovering gaps in coverage is a control failure
Related to Audit Logging Architecture
SOC 2 for Engineers, GDPR & CCPA Data Architecture
Data Residency & Sovereignty — Data Privacy
Difficulty: Advanced. Regulation: General.
Key Points for Data Residency & Sovereignty
- Data residency is about where data is physically stored; data sovereignty is about which country's laws govern that data — they overlap but are not the same thing
- After Schrems II, transferring EU personal data to the US requires Standard Contractual Clauses plus a Transfer Impact Assessment — Privacy Shield is dead
- China's PIPL requires personal data of Chinese citizens to be stored in China, with a security assessment required before any cross-border transfer
- Not all data needs localization — classify data by sensitivity and apply residency rules only where regulations actually require it
- CDN edge caches, analytics tools, and backup replication are the three most common ways data accidentally crosses borders
Common Mistakes with Data Residency & Sovereignty
- Assuming that using an EU AWS region means all data stays in the EU — control plane metadata, DNS queries, and some managed service telemetry may still route through US endpoints
- Forgetting that CDN edge caches replicate content globally by default, which can put personal data in jurisdictions you did not intend
- Using a US-headquartered analytics or logging provider without evaluating whether personal data flows to their US infrastructure
- Building a single-region architecture and trying to bolt on data residency later — retrofitting geo-partitioned data is an order of magnitude harder than designing for it upfront
Related to Data Residency & Sovereignty
GDPR & CCPA Data Architecture, Privacy by Design
GDPR & CCPA Data Architecture — Data Privacy
Difficulty: Advanced. Regulation: GDPR.
Key Points for GDPR & CCPA Data Architecture
- Right to erasure requires you to actually find and delete all copies of a user's data — including backups, logs, analytics, and third-party systems
- Consent must be granular, freely given, and withdrawable — a single 'I agree' checkbox is not GDPR-compliant
- Data lineage tracking is essential: you cannot delete what you cannot find
- Retention policies must be enforced automatically, not just documented
- CCPA gives California residents the right to know, delete, and opt out of data sales — with a 45-day response window
Common Mistakes with GDPR & CCPA Data Architecture
- Storing PII in unindexed log files where it cannot be found or deleted for erasure requests
- Treating consent as a one-time event rather than a mutable state that users can change at any time
- Building deletion logic that only removes data from the primary database but not from caches, search indices, or data warehouse
- Not distinguishing between data controller and data processor responsibilities when using third-party services
Related to GDPR & CCPA Data Architecture
Privacy by Design, Audit Logging Architecture
HIPAA Compliance for Engineers — Industry Regulations
Difficulty: Advanced. Regulation: HIPAA.
Key Points for HIPAA Compliance for Engineers
- HIPAA applies to covered entities (hospitals, insurers, clearinghouses) and their business associates — if your SaaS touches PHI, you are a business associate
- Protected Health Information (PHI) includes any individually identifiable health data: diagnoses, treatment records, billing info, even IP addresses if tied to a patient visit
- The Security Rule requires three safeguard categories: administrative, physical, and technical — all three must be addressed
- You need a signed Business Associate Agreement (BAA) with every vendor that can access PHI, including your cloud provider
- Breach notification must happen within 60 days of discovery, and breaches affecting 500+ individuals get reported to media and HHS publicly
Common Mistakes with HIPAA Compliance for Engineers
- Assuming HIPAA only applies to hospitals and insurance companies — any SaaS product that stores, processes, or transmits PHI on their behalf is a business associate
- Using AWS, GCP, or Azure services that are not HIPAA-eligible and storing PHI in them — not all cloud services are covered under the provider's BAA
- Treating encryption as the only technical safeguard — HIPAA also requires access controls, audit logging, integrity controls, and transmission security
- Not conducting a formal risk analysis — this is the single most cited HIPAA violation in enforcement actions
Related to HIPAA Compliance for Engineers
PCI DSS Compliance, Audit Logging Architecture, SOC 2 for Engineers
ISO 27001 & ISMS Implementation — Security Compliance
Difficulty: Advanced. Regulation: ISO27001.
Key Points for ISO 27001 & ISMS Implementation
- ISO 27001 is a certification, not an attestation like SOC 2 — an accredited auditor verifies your Information Security Management System (ISMS) against a defined standard
- The 2022 revision reorganized Annex A from 114 controls in 14 domains down to 93 controls in 4 themes: Organizational, People, Physical, and Technological
- You do not implement all 93 controls — the Statement of Applicability documents which controls apply to your organization and why any are excluded
- Certification requires two audit stages: Stage 1 reviews your documentation, Stage 2 tests whether you actually do what the docs say
- Surveillance audits happen annually; full recertification every three years — this is not a one-and-done effort
Common Mistakes with ISO 27001 & ISMS Implementation
- Writing an ISMS that describes how you want to operate rather than how you actually operate — auditors test reality, not aspirations
- Trying to implement all 93 Annex A controls regardless of relevance — the standard explicitly expects you to exclude controls that do not apply
- Treating the risk assessment as a paperwork exercise rather than using it to drive actual security investment decisions
- Underestimating the time between Stage 1 and Stage 2 — most organizations need 2-3 months to close gaps identified in the documentation review
Related to ISO 27001 & ISMS Implementation
SOC 2 for Engineers, Audit Logging Architecture
LLM Data Privacy & Security — Data Privacy
Difficulty: Expert. Regulation: General.
Key Points for LLM Data Privacy & Security
- Every LLM API call is a potential data leak. If you send customer data to a third-party model, you've transferred that data outside your control boundary.
- Prompt injection is the new SQL injection. Untrusted user input mixed with system prompts creates the same class of vulnerability that plagued web apps for decades.
- Data retention policies vary wildly by LLM provider. Some retain prompts for 30 days, some indefinitely. Read the terms before sending any data.
- PII detection and redaction must happen before data reaches the LLM, not after. Once you send it, you can't un-send it.
- Model outputs can contain memorized training data, including PII from other users or organizations that was present in the training corpus
Common Mistakes with LLM Data Privacy & Security
- Sending raw customer data to LLM APIs without PII stripping. GDPR still applies when the processor is an AI model.
- Not implementing input validation for prompt injection, treating LLM inputs as trusted when they contain user-supplied content
- Assuming enterprise tier agreements automatically prevent the provider from using your data for training. Read the actual DPA.
- Ignoring data residency implications of LLM API calls. If your users are in the EU and the LLM endpoint is in the US, that's a cross-border data transfer.
Related to LLM Data Privacy & Security
GDPR & CCPA Data Architecture, Software Supply Chain Security
PCI DSS Compliance — Industry Regulations
Difficulty: Advanced. Regulation: PCI.
Key Points for PCI DSS Compliance
- PCI DSS has 12 requirements organized into 6 goals — the core principle is to minimize the systems that touch cardholder data
- Tokenization replaces card numbers with non-sensitive tokens, dramatically reducing your PCI scope
- Network segmentation is the most effective way to shrink your Cardholder Data Environment (CDE)
- SAQ levels range from A (simplest, card-not-present with full outsourcing) to D (most complex, direct card handling)
- PCI DSS v4.0 introduces customized validation as an alternative to prescriptive controls
Common Mistakes with PCI DSS Compliance
- Processing raw card numbers through your own systems when a tokenization provider like Stripe or Braintree could handle it
- Flat network architecture where every server can reach the cardholder data environment
- Storing CVV/CVC codes after authorization — this is explicitly prohibited and an automatic audit failure
- Assuming PCI compliance only matters for large merchants — even small businesses processing cards must comply
Related to PCI DSS Compliance
SOC 2 for Engineers, Audit Logging Architecture
Privacy by Design — Data Privacy
Difficulty: Advanced. Regulation: General.
Key Points for Privacy by Design
- Privacy by Design means embedding privacy into system architecture from the start, not bolting it on after launch
- Data minimization is the most powerful privacy control — do not collect data you do not need
- Purpose limitation requires that data collected for one purpose is not repurposed without explicit consent
- Anonymization is irreversible and removes data from GDPR scope entirely; pseudonymization is reversible and data remains in scope
- Privacy impact assessments (PIAs) should be part of the design review process for any feature that handles personal data
Common Mistakes with Privacy by Design
- Collecting all available user data 'just in case' it becomes useful later — this violates data minimization and creates unnecessary risk
- Confusing pseudonymization with anonymization — hashing an email is pseudonymization (reversible with a lookup table), not anonymization
- Treating privacy as a legal team responsibility instead of an engineering design constraint
- Building analytics pipelines on raw PII when aggregated or anonymized data would serve the same purpose
Related to Privacy by Design
GDPR & CCPA Data Architecture, Software Supply Chain Security
SOC 2 for Engineers — Security Compliance
Difficulty: Intermediate. Regulation: SOC2.
Key Points for SOC 2 for Engineers
- SOC 2 has five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy
- Type I audits assess design at a point in time; Type II audits assess operating effectiveness over 6-12 months
- Most startups only need Security and Availability criteria to start
- Evidence collection is the hard part — automate it from day one with tools like Vanta or Drata
- SOC 2 is about proving you do what you say you do, not about being perfect
Common Mistakes with SOC 2 for Engineers
- Treating SOC 2 as a one-time project instead of an ongoing compliance program
- Waiting until the audit to gather evidence instead of automating collection continuously
- Writing policies that describe aspirational practices rather than actual practices
- Ignoring the shared responsibility model for cloud services
Related to SOC 2 for Engineers
Audit Logging Architecture, Privacy by Design
Software Supply Chain Security — Security Compliance
Difficulty: Expert. Regulation: General.
Key Points for Software Supply Chain Security
- An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software — it is the foundation of supply chain security
- The SLSA framework defines four levels of supply chain integrity, from basic build provenance (L1) to hermetic, reproducible builds (L4)
- Dependency confusion attacks exploit package managers that check internal registries before public ones — namespace your internal packages
- Artifact signing with Sigstore/cosign provides cryptographic proof that a container image was built by your CI pipeline
- Log4Shell proved that transitive dependencies are the real threat — you must scan the entire dependency tree, not just direct imports
Common Mistakes with Software Supply Chain Security
- Only scanning direct dependencies and ignoring transitive dependencies where most supply chain vulnerabilities hide
- Generating SBOMs as a one-time exercise instead of producing them automatically with every build
- Trusting container base images without verifying their signatures or scanning them for vulnerabilities
- Not pinning dependency versions, allowing silent updates that could introduce compromised packages
Related to Software Supply Chain Security
SOC 2 for Engineers, PCI DSS Compliance
Zero Trust & Access Governance — Security Compliance
Difficulty: Advanced. Regulation: General.
Key Points for Zero Trust & Access Governance
- Zero trust means no implicit trust based on network location — every request is authenticated and authorized, whether it comes from inside the VPN or outside
- RBAC works until you have 500+ roles and nobody knows what they all do; ABAC is flexible but complex to debug; ReBAC (Zanzibar model) handles hierarchical permissions cleanly
- Just-in-time (JIT) access with time-bounded credentials eliminates standing privileges, which are the root cause of most privilege escalation attacks
- Identity-aware proxies (Google IAP, Cloudflare Access, Pomerium) replace VPNs by authenticating every request at the application layer, not the network layer
- Service-to-service auth via mTLS and SPIFFE/SPIRE gives every workload a cryptographic identity, eliminating shared secrets and static API keys
Common Mistakes with Zero Trust & Access Governance
- Calling it zero trust because you added MFA to the VPN — that is still perimeter-based security with an extra factor, not zero trust
- Building a 200-role RBAC system where roles overlap, accumulate, and nobody remembers why half of them exist — role explosion defeats the purpose of access control
- Granting permanent admin access with a promise to 'review it later' — standing privileges are the number one cause of excessive access findings in audits
- Implementing mTLS between services but not rotating certificates automatically — expired or long-lived certs are just shared secrets with extra steps
Related to Zero Trust & Access Governance
SOC 2 for Engineers, Software Supply Chain Security