afrexai-compliance-engine（afrexai 合规引擎）

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

Readiness Assessment Brief

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)

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

# [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

SOC 2 ↔ ISO 27001 Control Mapping (Save 40-60% effort)

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

1. 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

1. 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)

1. Data Protection Officer (DPO) — Required if:

- Public authority, OR - Large-scale systematic monitoring, OR - Large-scale processing of special category data

1. Consent Management

- [ ] Granular consent mechanisms (not bundled) - [ ] Easy withdrawal (as easy as giving consent) - [ ] Consent records with timestamp, version, scope - [ ] Cookie consent banner (ePrivacy)

1. Data Processing Agreements (DPAs)

- [ ] DPA template for sub-processors - [ ] Article 28 requirements checklist - [ ] Sub-processor notification process - [ ] Sub-processor register

1. International Transfers

- [ ] Transfer mechanism (SCCs, adequacy decision, BCRs) - [ ] Transfer Impact Assessment - [ ] Supplementary measures where needed

1. Breach Notification

- [ ] 72-hour notification to supervisory authority - [ ] "Undue delay" notification to affected individuals - [ ] Breach register with risk assessment - [ ] Breach response team and escalation path

1. Records of Processing Activities (ROPA)

processing_activity:
  name: ""
  purpose: ""
  lawful_basis: ""
  data_categories: []
  data_subjects: []
  recipients: []
  retention_period: ""
  transfers_outside_eea: false
  transfer_mechanism: ""
  technical_measures: []
  organizational_measures: []
  dpia_required: false
  last_reviewed: ""

1. Privacy Notice — Must include:

- Identity of controller - DPO contact (if applicable) - Purposes and lawful basis - Categories of data - Recipients / transfers - Retention periods - Data subject rights - Right to complain to supervisory authority - Whether providing data is statutory/contractual requirement

1. Data Retention Schedule

1. Training & Awareness

- [ ] Mandatory GDPR training for all employees (annual) - [ ] Role-specific training (developers, support, marketing, HR) - [ ] Training records with completion tracking

Phase 5 — HIPAA Compliance (Health Data)

HIPAA Security Rule — 3 Safeguard Categories

Administrative Safeguards

• [ ] Security Management Process (risk analysis, risk management)
• [ ] Assigned Security Responsibility (HIPAA Security Officer)
• [ ] Workforce Security (authorization, clearance, termination)
• [ ] Information Access Management (access authorization, establishment, modification)
• [ ] Security Awareness Training (reminders, malware, login monitoring, password mgmt)
• [ ] Security Incident Procedures (response, reporting)
• [ ] Contingency Plan (backup, DR, emergency mode, testing)
• [ ] Evaluation (periodic technical/non-technical)
• [ ] BAAs with all business associates

Physical Safeguards

• [ ] Facility Access Controls (contingency ops, facility security plan, access control, maintenance records)
• [ ] Workstation Use (policies, restrictions)
• [ ] Workstation Security (physical safeguards)
• [ ] Device and Media Controls (disposal, re-use, accountability, data backup)

Technical Safeguards

• [ ] Access Control (unique user ID, emergency access, automatic logoff, encryption)
• [ ] Audit Controls (hardware, software, procedural mechanisms)
• [ ] Integrity Controls (authentication of ePHI, transmission security)
• [ ] Person or Entity Authentication (verify identity)
• [ ] Transmission Security (integrity controls, encryption)

HIPAA Breach Rule

• ≤500 individuals: Annual batch notification to HHS (within 60 days of year end)
• >500 individuals: Notify HHS within 60 days + media notification
• All breaches: Notify affected individuals without unreasonable delay (≤60 days)
• Penalties: $100-$50,000 per violation, up to $1.5M per year per category

Phase 6 — PCI DSS 4.0 (Payment Data)

12 Requirements Summary

Scope Reduction Strategy

• Use tokenization — Replace card data with tokens (Stripe, Braintree handle PCI for you)
• Use hosted payment pages — Never touch raw card data (SAQ A instead of SAQ D)
• Network segmentation — Isolate cardholder data environment
• Cloud provider compliance — Leverage AWS/GCP/Azure PCI certifications

SAQ Decision:

• Fully outsourced (Stripe Checkout) → SAQ A (22 controls, simplest)
• API-based (Stripe Elements) → SAQ A-EP (~140 controls)
• You store/process card data → SAQ D (300+ controls, avoid this)

Phase 7 — Compliance Tooling Stack

Essential Tools by Category

Automation-First Compliance

What to automate (saves 70%+ of audit prep):

• Evidence collection (screenshots of configs → API pulls)
• Access reviews (quarterly manual → continuous monitoring)
• Vulnerability scanning (manual → scheduled + auto-ticket)
• Policy acknowledgment (email → onboarding workflow)
• Vendor assessments (spreadsheets → intake forms with scoring)
• Training tracking (manual → LMS with auto-reminders)

Compliance-as-Code Patterns

# Infrastructure compliance
- Terraform with Sentinel policies (enforce encryption, tagging)
- OPA/Rego for Kubernetes admission control
- AWS Config Rules / Azure Policy for cloud compliance
- GitHub branch protection rules as change management evidence

# Application compliance
- Automated dependency scanning in CI (Snyk, Dependabot)
- SAST in PR pipeline (Semgrep, CodeQL)
- Container scanning (Trivy, Grype)
- License compliance (FOSSA, Licensee)

Phase 8 — Audit Preparation

90-Day Audit Prep Checklist

Days 90-60: Foundation

• [ ] Confirm audit scope with auditor
• [ ] Complete system description document
• [ ] Verify all policies are current (reviewed within 12 months)
• [ ] Confirm all employees completed security training
• [ ] Run vulnerability scan and remediate critical/high findings
• [ ] Schedule penetration test (results needed before audit)

Days 60-30: Evidence Gathering

• [ ] Collect evidence for each control (organized by TSC/clause)
• [ ] Access review documentation (screenshots of reviews, action items)
• [ ] Change management evidence (sample of tickets showing approval flow)
• [ ] Incident response test evidence (tabletop exercise minutes)
• [ ] DR test evidence (recovery test results, RTO achieved)
• [ ] Vendor review evidence (assessment records, DPAs)
• [ ] Risk assessment and treatment plan (current year)
• [ ] Board/management meeting minutes discussing security

Days 30-0: Final Prep

• [ ] Internal mock audit — walk through every control
• [ ] Remediate any mock audit findings
• [ ] Brief team on auditor interviews (what to expect, who answers what)
• [ ] Prepare management assertion letter
• [ ] Set up auditor access (read-only to evidence repository)
• [ ] Confirm all monitoring/alerting is functioning
• [ ] Verify offboarding was completed for all departed employees

Evidence Organization

/compliance-evidence/
  /SOC2-2026/
    /CC1-control-environment/
      org-chart.pdf
      code-of-conduct-signed.pdf
      background-check-process.pdf
    /CC2-communication/
      security-training-completion.csv
      security-policy-acknowledgments.pdf
    /CC3-risk-assessment/
      risk-assessment-2026.xlsx
      risk-treatment-plan.pdf
    /CC6-access/
      access-review-Q1.pdf
      access-review-Q2.pdf
      mfa-enforcement-screenshot.png
      offboarding-checklist-samples/
    /CC7-operations/
      vulnerability-scan-reports/
      pentest-report-2026.pdf
      incident-log-2026.csv
    /CC8-change-management/
      sample-change-tickets/
      deployment-pipeline-config.png
    /CC9-vendors/
      vendor-inventory.xlsx
      vendor-assessments/
      dpas-and-baas/

Auditor Interview Prep

Common questions and who should answer:

Phase 9 — Continuous Compliance

Monthly Compliance Dashboard

compliance_dashboard:
  month: ""
  
  control_health:
    total_controls: 0
    controls_passing: 0
    controls_failing: 0
    controls_not_tested: 0
    health_percentage: 0
    
  action_items:
    open: 0
    overdue: 0
    closed_this_month: 0
    
  key_metrics:
    mean_time_to_patch_critical: ""
    access_reviews_completed: "X/X"
    security_training_completion: ""
    incidents_this_month: 0
    vendor_reviews_due: 0
    policies_due_for_review: 0
    
  risk_register:
    high_risks: 0
    risks_without_treatment: 0
    new_risks_identified: 0
    
  upcoming:
    next_pen_test: ""
    next_dr_test: ""
    next_audit: ""
    next_access_review: ""

Compliance Calendar

Compliance Debt Tracker

compliance_debt:
  - id: "CD-001"
    framework: "SOC 2"
    control: "CC6.1"
    finding: "MFA not enforced on staging environment"
    severity: "High"
    identified: "2026-01-15"
    owner: ""
    target_remediation: "2026-02-15"
    status: "In Progress"
    compensating_control: "VPN + IP allowlisting"

When Controls Fail

Severity-based response:

Phase 10 — Multi-Framework Management

Common Control Framework (CCF)

Build controls ONCE, map to MULTIPLE frameworks:

control:
  id: "CCF-AC-001"
  title: "Multi-Factor Authentication"
  description: "MFA required for all access to production systems and sensitive data"
  owner: "Security Team"
  
  framework_mapping:
    soc2: ["CC6.1", "CC6.6"]
    iso27001: ["A.8.5"]
    gdpr: ["Article 32"]
    hipaa: ["§164.312(d)"]
    pci_dss: ["Req 8.4"]
    
  evidence:
    - type: "Configuration screenshot"
      source: "Okta MFA policy"
      frequency: "Quarterly"
    - type: "Access review"
      source: "Okta user report"
      frequency: "Quarterly"
      
  test_procedure: "Verify MFA policy is enforced, test with non-MFA login attempt"
  last_tested: ""
  result: ""
  next_test: ""

Framework Expansion Strategy

Year 1: SOC 2 Type I → establishes baseline Year 1-2: SOC 2 Type II → proves sustained operation Year 2: + GDPR → covers EU expansion Year 2-3: + ISO 27001 → international credibility As needed: + HIPAA / PCI DSS → industry-specific

Audit Fatigue Prevention

• Single evidence repository — collect once, map to all frameworks
• Continuous monitoring — evidence auto-collected, not scrambled at audit time
• Control owner accountability — each control has ONE owner, not "security team"
• Compliance sprints — 2-week sprints dedicated to compliance work, not crammed before audit
• Auditor relationship — same firm for multiple frameworks if possible (they know your environment)

Phase 11 — Scoring & Quality

Compliance Readiness Score (0-100)

Scoring guide:

• 0-2: Not started / major gaps
• 3-4: In progress / significant gaps
• 5-6: Partially implemented / some gaps
• 7-8: Implemented / minor improvements needed
• 9-10: Mature / audit-ready

Interpretation:

• < 40: Not ready — significant work needed (3-6 months)
• 40-60: Getting there — focus on gaps (1-3 months)
• 60-80: Nearly ready — polish and evidence gathering (2-6 weeks)
• 80+: Audit-ready — schedule the audit

Edge Cases & Special Situations

Startup with Zero Compliance

• Start with security basics (MFA, encryption, access control, backups) before any framework
• Use a GRC platform from Day 1 (Vanta/Drata cost $10-15K/yr but save 100+ hours)
• Don't wait for perfect — "documented and improving" beats "undocumented and perfect"
• Budget $20-40K for first SOC 2 Type I (auditor + tools + time)

Multi-Cloud / Hybrid Infrastructure

• Map shared responsibility model for each provider
• Ensure consistent controls across environments
• Consider cloud-specific compliance tools (AWS Audit Manager, Azure Compliance Manager)
• Network segmentation especially important

Acquired Company Integration

• Conduct compliance gap assessment within 30 days of close
• Identify highest-risk gaps (access control, data handling)
• 90-day integration plan to bring to baseline
• Don't assume their compliance posture matches claims

International (Multi-Jurisdiction)

• Map all jurisdictions where you operate or store data
• GDPR applies if you have EU *users* — not just EU office
• Data residency requirements (Russia, China, India, Brazil)
• Consider local DPA registrations

Regulated Industries (FinTech, HealthTech)

• Layer industry regulations ON TOP of SOC 2/ISO
• FinTech: SOC 2 + PCI DSS + potentially banking regs (state MTLs, FinCEN)
• HealthTech: SOC 2 + HIPAA + potentially FDA (SaMD)
• EdTech: SOC 2 + FERPA + COPPA (if under 13)

Natural Language Commands