Handbook
Compliance
Reusable, **project-agnostic** blueprint for **Compliance** — the discipline of ensuring digital products meet **regulatory and legal obligations** (privacy, accessibility, sector rules, algorithmic a
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) through scoping, control design, evidence, and continuous assurance.
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.md | 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: SDLC blueprint (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. |
| SDLC blueprint | Compliance requirements become acceptance criteria, design constraints, test cases, and release evidence (A–F). |
| Product development lifecycle (PDLC) | P3 (Strategize) 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.
Canonical source
Edit https://github.com/autowww/blueprints/blob/main/disciplines/compliance/README.md first; regenerate with docs/build-handbook.py.