Handbook
Compliance
Reusable, project-agnostic blueprint for Compliance — the discipline of ensuring digital products meet regulatory and legal obligations (privacy, accessibility, sector rules, algorithmic accountability, certifications)…
Compliance answers "does the product meet regulatory and legal obligations?" — a question that spans every SDLC phase (from requirements through operations) and every PDLC phase where markets, data categories, and business models are chosen.
| Document | Purpose |
|---|---|
| Compliance body of knowledge | Body of knowledge — principles, lifecycle, domains (privacy, accessibility, healthcare, financial, AI, minors), certification, compliance-as-code, vendor assurance, competencies |
| Compliance ↔ SDLC ↔ PDLC bridge | How Compliance maps across SDLC phases A–F and PDLC phases P1–P6 — front-loaded in P3, continuous through delivery |
| frameworks/ | Index of framework-specific guides (GDPR, HIPAA, PCI-DSS, WCAG, EU AI Act, SOC 2, ISO 27001, and related regimes) |
Cross-cutting nature
Compliance is not owned by a single family of disciplines. It cuts across:
| Family / area | Typical compliance touchpoints |
|---|---|
| Engineering | Technical and organizational controls — encryption, logging, access enforcement, secure configuration, change management, segregation of duties in systems |
| Data | Lawful processing, retention, minimization, subject rights fulfillment, cross-border mechanisms, lineage for audits, model/AI documentation |
| Product | Lawful basis and consent UX, accessibility of journeys, notices and transparency, feature scope vs. purpose limitation, minors’ experiences |
| Governance | Regulatory calendars, DPIA/PIA programs, policy ownership, vendor due diligence, audit and certification roadmaps, board/legal escalation |
Canonical lifecycles: Software delivery (build and operate right) · Product development lifecycle (PDLC) (build the right product in the right markets). Bridge concept and index: blueprints/BRIDGES.md.
Relationship to other packages
| Package | How Compliance relates |
|---|---|
| Security / Cybersecurity | Overlapping but distinct. Security centers on threats, vulnerabilities, and resilience (confidentiality, integrity, availability against adversaries). Compliance centers on legal and regulatory obligations — which may require security controls but also privacy rights, accessibility, sector rules, and documentation/evidence. A system can be “secure” yet non-compliant (e.g., strong access control without a lawful basis for processing), or compliant-in-letter yet fragile to attack — both disciplines should be integrated. |
| Software delivery | Compliance requirements become acceptance criteria, design constraints, test cases, and release evidence (A–F). |
| Product development lifecycle (PDLC) | P3 (Plan & Commit) is the primary place to scope jurisdictions, data categories, and certification needs; compliance constraints flow back into roadmap and sunset (P6). |
| Software architecture | Architecture carries privacy-by-design boundaries, auditability, data residency patterns, and separation of duties. |
| DevOps | CI/CD, IaC, and observability enable compliance-as-code, automated control checks, and continuous evidence. |
| Testing & quality assurance | Accessibility testing, control validation, and evidence from automated suites support audits and regressions. |
| UX / UI Design | Consent, notices, accessible UI, and age-appropriate design are compliance-shaped UX problems. |
| Big data & data engineering | Large-scale processing intensifies minimization, retention, DPIA, and transfer analysis obligations. |
| Data science & machine learning | Model governance intersects AI Act, automated decision-making rules, and fairness/transparency expectations. |
blueprints/disciplines/documentation/ |
Compliance requires extensive documentation (DPIAs, ROPA, privacy notices, accessibility statements, policy suites, audit evidence). The Documentation discipline provides methodology for creating, versioning, and maintaining these artifacts. |
Scope
This package addresses Compliance as a discipline for digital products — not a single law checklist. Framework domains include:
- Privacy and data protection — EU/UK GDPR-style and US state privacy (e.g. CCPA/CPRA), LGPD, lawful basis, rights, transfers, breaches, DPO
- Accessibility — WCAG 2.x, ADA, European Accessibility Act, EN 301 549, VPAT/ACR
- Healthcare — HIPAA (and adjacent health regulations by jurisdiction)
- Financial — PCI-DSS, SOX ITGC (where applicable to product and engineering)
- AI and algorithmic systems — EU AI Act risk classes, NIST AI RMF, employment and consumer-facing algorithmic rules (e.g. NYC LL144-class regimes)
- Children and minors — COPPA, GDPR Article 8, UK Age Appropriate Design Code
- Assurance and certification — ISO 27001, SOC 2, IEC 61508 / functional safety where software is safety-related
- Operational compliance — vendor/subprocessor governance, DPAs/BAAs, supply chain due diligence
- Automation — policy-as-code, continuous control monitoring, evidence pipelines
Reference bodies of knowledge and authorities: IAPP (CIPP / CIPM / CIPT), ISACA (CISA, CRISC, privacy and audit practice), NIST (Privacy Framework, AI RMF, cybersecurity and engineering publications where they support compliance), W3C WAI (WCAG, WAI-ARIA), EU regulatory bodies and EDPB guidance (for GDPR interpretation), plus primary legal texts for each regime.
Keep project-specific compliance documentation in docs/security/compliance/, DPIAs in docs/security/, and compliance decisions in docs/adr/, not in this file.