compliance-audit-readiness-engine

# Compliance & Audit Readiness Engine Your AI compliance officer. Guides startups and scale-ups through SOC 2, ISO 27001, GDPR, HIPAA, and PCI DSS — from zero to audit-ready. No consultants needed. --- ## Phase 1 — Compliance Discovery ### Framework Selection Matrix | Framework | Who Needs It | Trigger | Timeline | Cost Range | |-----------|-------------|---------|----------|------------| | **SOC 2 Type I** | Any B2B SaaS | Enterprise prospect asks | 3-6 months | $20K-$80K | | **SOC 2 Type II** | Established SaaS | After Type I, or direct | 6-12 months | $30K-$100K | | **ISO 27001** | Global/EU-facing SaaS | EU enterprise deals | 6-12 months | $40K-$120K | | **GDPR** | Anyone with EU users | Day 1 if EU data | 1-3 months | $5K-$30K | | **HIPAA** | Health data handlers | Before first PHI | 3-6 months | $20K-$60K | | **PCI DSS** | Payment processors | Before card data | 3-9 months | $15K-$50K | | **SOX** | Public companies | IPO prep | 12-18 months | $100K-$500K | ### Readiness Assessment Brief ```yaml company_profile: name: "" industry: "" employee_count: 0 annual_revenue: "" data_types_handled: - PII (names, emails, addresses) - Financial (payment cards, bank accounts) - Health (PHI, medical records) - Children (COPPA scope) - Biometric - Government/classified customer_segments: - SMB - Mid-market - Enterprise - Government geographic_scope: - US only - US + EU - Global current_state: existing_frameworks: [] security_team_size: 0 has_written_policies: false has_asset_inventory: false has_risk_assessment: false has_incident_response: false has_vendor_management: false previous_audits: [] known_gaps: [] drivers: - Customer requirement - Board/investor mandate - Regulatory obligation - Competitive advantage - Insurance requirement target_frameworks: [] target_date: "" budget_range: "" ``` ### Priority Decision Rules 1. **Customer asking for SOC 2?** → Start there (most requested in B2B SaaS) 2. **EU customers?** → GDPR is non-negotiable, do it alongside SOC 2 3. **Health data?** → HIPAA first, then layer SOC 2 4. **Payment data?** → PCI DSS is legally required, do immediately 5. **Multiple frameworks?** → Map common controls (40-60% overlap between SOC 2 and ISO 27001) --- ## Phase 2 — SOC 2 Deep Dive ### Trust Service Criteria (TSC) SOC 2 is built on 5 categories. **Security** is mandatory. Others are optional but often expected. #### CC1 — Control Environment (Foundation) - [ ] Board/management oversight of security - [ ] Organizational structure with clear security roles - [ ] Code of conduct / acceptable use policy - [ ] HR processes (background checks, onboarding, offboarding) - [ ] Performance evaluations include security responsibilities #### CC2 — Communication & Information - [ ] Security policies documented and accessible to all employees - [ ] External communication channels for security (status page, security@) - [ ] Whistleblower / anonymous reporting mechanism - [ ] Security awareness training program (annual + onboarding) - [ ] System description document maintained #### CC3 — Risk Assessment - [ ] Annual risk assessment process documented - [ ] Risk register maintained with likelihood × impact scoring - [ ] Risk treatment plans for high/critical risks - [ ] Risk appetite statement approved by management - [ ] Changes in business/technology trigger risk re-assessment #### CC4 — Monitoring Activities - [ ] Continuous monitoring of controls (not just annual) - [ ] Internal audit or self-assessment program - [ ] Deficiency tracking and remediation - [ ] Management review of monitoring results - [ ] Penetration testing (annual minimum) #### CC5 — Control Activities - [ ] Logical access controls (RBAC, least privilege) - [ ] Physical access controls (offices, data centers) - [ ] Change management process - [ ] System development lifecycle (SDLC) - [ ] Data backup and recovery procedures #### CC6 — Logical & Physical Access - [ ] User provisioning and deprovisioning process - [ ] MFA enforced on all critical systems - [ ] Password policy (12+ chars, complexity, rotation) - [ ] Access reviews (quarterly minimum) - [ ] Physical access logs for sensitive areas - [ ] Encryption at rest (AES-256) and in transit (TLS 1.2+) - [ ] Firewall rules reviewed quarterly - [ ] VPN or zero-trust network access #### CC7 — System Operations - [ ] Monitoring and alerting (uptime, errors, security events) - [ ] Incident detection and response procedures - [ ] Vulnerability management (scan weekly, patch critical <72h) - [ ] Anti-malware / endpoint protection - [ ] Capacity planning and performance monitoring #### CC8 — Change Management - [ ] Formal change request and approval process - [ ] Separation of duties (dev ≠ prod deploy) - [ ] Testing before production deployment - [ ] Rollback procedures documented - [ ] Emergency change process with post-hoc approval #### CC9 — Risk Mitigation (Vendors) - [ ] Vendor risk assessment before onboarding - [ ] Vendor inventory with criticality ratings - [ ] Annual vendor reviews - [ ] BAAs / DPAs with sub-processors - [ ] Vendor offboarding process ### Additional Criteria **Availability (A1):** - [ ] SLAs defined and monitored - [ ] Disaster recovery plan tested annually - [ ] Business continuity plan documented - [ ] RTO/RPO defined for critical systems - [ ] Redundancy for critical infrastructure **Confidentiality (C1):** - [ ] Data classification scheme (Public, Internal, Confidential, Restricted) - [ ] Handling procedures per classification level - [ ] Confidentiality agreements (NDA) with employees and vendors - [ ] Data retention and disposal policies - [ ] DLP controls for sensitive data **Processing Integrity (PI1):** - [ ] Input validation controls - [ ] Processing completeness and accuracy checks - [ ] Output reconciliation procedures - [ ] Error handling and correction processes **Privacy (P1):** - [ ] Privacy notice published - [ ] Consent mechanisms for data collection - [ ] Data subject rights procedures (access, deletion, portability) - [ ] Privacy impact assessments for new features - [ ] Data breach notification procedures ### SOC 2 Project Plan (16-Week Sprint) | Week | Phase | Key Activities | |------|-------|---------------| | 1-2 | **Scoping** | Define system boundaries, select TSC, choose auditor | | 3-4 | **Gap Assessment** | Audit current state against TSC, document gaps | | 5-6 | **Policy Writing** | Draft all required policies (see policy list below) | | 7-8 | **Control Implementation** | Deploy technical controls, configure tools | | 9-10 | **Process Implementation** | Establish operational processes, train team | | 11-12 | **Evidence Collection** | Gather evidence for all controls, test internally | | 13-14 | **Readiness Assessment** | Mock audit, remediate findings | | 15-16 | **Type I Audit** | Auditor fieldwork, management response, report | ### Required Policy Documents 1. **Information Security Policy** — Master policy, scope, objectives 2. **Access Control Policy** — Authentication, authorization, reviews 3. **Change Management Policy** — SDLC, deployment, emergency changes 4. **Incident Response Policy** — Detection, response, notification 5. **Risk Management Policy** — Assessment methodology, treatment, appetite 6. **Data Classification Policy** — Levels, handling, retention, disposal 7. **Acceptable Use Policy** — Employee responsibilities, prohibited actions 8. **Vendor Management Policy** — Assessment, monitoring, offboarding 9. **Business Continuity / DR Policy** — Plans, testing, RTO/RPO 10. **HR Security Policy** — Background checks, onboarding, offboarding, training 11. **Encryption Policy** — Standards, key management, certificate handling 12. **Physical Security Policy** — Office access, visitor management, clean desk 13. **Logging & Monitoring Policy** — What to log, retention, alerting 14. **Password & Authentication Policy** — Standards, MFA requirements 15. **Backup & Recovery Policy** — Schedule, testing, retention ### Policy Template ```markdown # [Policy Name] **Version:** 1.0 **Owner:** [Name, Title] **Approved by:** [Name, Title] **Effective date:** [Date] **Next review:** [Date + 1 year] **Classification:** Internal ## 1. Purpose [Why this policy exists — 2-3 sentences] ## 2. Scope [Who and what this policy applies to] ## 3. Policy Statements [Numbered, actionable requirements — not aspirational] ### 3.1 [Topic] - SHALL [requirement] - SHALL NOT [prohibition] - SHOULD [recommendation] ## 4. Roles & Responsibilities | Role | Responsibility | |------|---------------| | [Role] | [What they must do] | ## 5. Exceptions [Process for requesting exceptions — who approves, how long, documentation] ## 6. Enforcement [Consequences of non-compliance] ## 7. Definitions [Technical terms used in the policy] ## 8. Related Documents [Links to related policies, standards, procedures] ## 9. Revision History | Version | Date | Author | Changes | |---------|------|--------|---------| | 1.0 | [Date] | [Author] | Initial release | ``` --- ## Phase 3 — ISO 27001 Framework ### ISMS Implementation Roadmap #### Clause 4 — Context of the Organization - [ ] Define ISMS scope and boundaries - [ ] Identify interested parties and their requirements - [ ] Determine internal and external issues - [ ] Document scope statement #### Clause 5 — Leadership - [ ] Management commitment statement - [ ] Information security policy (signed by CEO/CTO) - [ ] Assign ISMS roles and responsibilities - [ ] Allocate resources (budget, people, tools) #### Clause 6 — Planning - [ ] Risk assessment methodology (ISO 27005 or custom) - [ ] Risk assessment execution - [ ] Risk treatment plan - [ ] Statement of Applicability (SoA) — map all 93 Annex A controls - [ ] Information security objectives (measurable, time-bound) #### Clause 7 — Support - [ ] Determine required competencies - [ ] Security awareness program - [ ] Internal and external communication plan - [ ] Document control process #### Clause 8 — Operation - [ ] Execute risk treatment plan - [ ] Implement controls from SoA - [ ] Manage operational changes - [ ] Conduct risk assessments on changes #### Clause 9 — Performance Evaluation - [ ] Monitoring and measurement program - [ ] Internal audit schedule and execution - [ ] Management review (at least annually) - [ ] Corrective action tracking #### Clause 10 — Improvement - [ ] Nonconformity and corrective action process - [ ] Continual improvement program - [ ] Lessons learned integration ### ISO 27001:2022 Annex A Control Categories | Category | Controls | Key Areas | |----------|----------|-----------| | A.5 Organizational | 37 | Policies, roles, threat intel, asset mgmt, access, supplier | | A.6 People | 8 | Screening, T&C, awareness, disciplinary, termination | | A.7 Physical | 14 | Perimeters, entry, offices, monitoring, utilities, cabling | | A.8 Technological | 34 | Endpoints, access rights, auth, malware, vuln mgmt, logging, crypto, SDLC | ### SOC 2 ↔ ISO 27001 Control Mapping (Save 40-60% effort) | SOC 2 TSC | ISO 27001 Annex A | Overlap | |-----------|------------------|---------| | CC1 Control Environment | A.5.1-5.6 (Org controls) | ~80% | | CC2 Communication | A.5.1, A.6.3 (Awareness) | ~70% | | CC3 Risk Assessment | Clause 6.1, A.5.7 (Threat intel) | ~90% | | CC5 Control Activities | A.8 (Technological) | ~75% | | CC6 Access | A.5.15-5.18, A.8.1-8.5 | ~85% | | CC7 Operations | A.8.7-8.16 (Monitoring) | ~80% | | CC8 Change Mgmt | A.8.25-8.33 (SDLC) | ~70% | | CC9 Vendors | A.5.19-5.23 (Supplier) | ~85% | **Strategy:** Build for one framework, extend to the other. SOC 2 first (faster) → ISO 27001 (adds clauses 4-10 management system). --- ## Phase 4 — GDPR Compliance Program ### 12 Core Requirements 1. **Lawful Basis for Processing** — Document legal basis for each data processing activity - Consent | Contract | Legal obligation | Vital interest | Public task | Legitimate interest - [ ] Data processing register (Article 30) - [ ] Legitimate Interest Assessments (LIAs) where applicable 2. **Data Subject Rights** — Respond within 30 days - [ ] Right of access (SAR) process - [ ] Right to rectification - [ ] Right to erasure ("right to be forgotten") - [ ] Right to data portability (machine-readable export) - [ ] Right to restrict processing - [ ] Right to object - [ ] Automated decision-making opt-out 3. **Privacy by Design & Default** — Build privacy into products - [ ] Privacy Impact Assessment (PIA/DPIA) template - [ ] Data minimization review for each feature - [ ] Default privacy settings (opt-in, not opt-out) 4. **Data Protection Officer (DPO)** — Required if: - Public authority, OR - Large-scale systematic monitoring, OR - Large-scale processing of special category data 5. **Consent Management**